<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi Paul,<br><br>Thanks for the reply, and sorry for my late reply.<br><br>> I took a brief look at your paper and it seemed to suggest<br>> that users might be duped by similar-looking domain names,<br>> but that is human error, not protocol error. Is that the<br>> point?<br><br>Actually there are two problems.<br><br>The first problem is what you say, users may be duped by<br>similar-looking domain names. This may not be a protocol<br>error, but it is an exploitable security weakness, and one<br>that can be addressed: there are better ways of identifying<br>the relying party to the user than a domain name. <br><br>This is not user error, users are not required to study<br>domain name syntax before using the Web. And some OpenID<br>products rely on users misinterpreting domain names. The<br>free version of Janrain
Engage identifies the RP as<br>example.rpx.com after being redirected from example.com. A<br>user who understands domain name syntax should refuse to<br>continue, but apparently nobody does!<br><br>The second problem is that the spec does not seem to require<br>nor even recommend the use of SSL by the RP for the<br>return_to URL. Section 15.1.2 "strongly recommends" the use<br>of SSL, but it is only talking about the OP.<br><br>Without using SSL for the return_to URL, an attacker can set<br>up a man-in-the-middle attack on the connection between the<br>browser and the RP. After user authentication with the OP,<br>the attacker can intercept the positive assertion, terminate<br>the connection with the legitimate user, and impersonate the<br>user vis-a-vis the RP using the positive assertion.<br><br>Man-in-the-middle attacks are easy to set up using<br>ready-to-use tools, judging from <a
href="http://www1.cse.wustl.edu/%7Ejain/cse571-07/ftp/cafecrack/index.html">instructions</a> available on<br>the Web.<br><br>Francisco<br><br>--- On <b>Fri, 1/14/11, Paul E. Jones <i><paulej@packetizer.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Paul E. Jones <paulej@packetizer.com><br>Subject: RE: [OpenID] security weakness regarding authentication of the relying party<br>To: fcorella@pomcor.com, openid-general@lists.openid.net<br>Date: Friday, January 14, 2011, 11:39 PM<br><br><div id="yiv790705516"><style><!--
#yiv790705516
_filtered #yiv790705516 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
_filtered #yiv790705516 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
#yiv790705516
#yiv790705516 p.yiv790705516MsoNormal, #yiv790705516 li.yiv790705516MsoNormal, #yiv790705516 div.yiv790705516MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"serif";}
#yiv790705516 a:link, #yiv790705516 span.yiv790705516MsoHyperlink
{color:blue;text-decoration:underline;}
#yiv790705516 a:visited, #yiv790705516 span.yiv790705516MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv790705516 span.yiv790705516EmailStyle17
{font-family:"sans-serif";color:#1F497D;}
#yiv790705516 .yiv790705516MsoChpDefault
{font-family:"sans-serif";}
_filtered #yiv790705516 {margin:1.0in 1.0in 1.0in 1.0in;}
#yiv790705516 div.yiv790705516WordSection1
{}
--></style><div class="yiv790705516WordSection1"><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Late to reply to this, but I didn’t see other replies…</span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">It does not “authenticate” the realm, but if a request arrives for realm good_site.example.com, then a positive assertion will only be provided if the return URL is properly is a part of that that realm (i.e., same name or perhaps a sub-domain thereof). So, there is some checking. A positive assertion will not be returned to bad_site.example.org, for example.</span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt;
font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">So, exactly what is the security issue? I’ll not deny there is one, but it is not clear to me.</span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">I took a brief look at your paper and it seemed to suggest that users might be duped by similar-looking domain names, but that is human error, not protocol error. Is that the point?</span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv790705516MsoNormal"><span
style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Paul</span></p><p class="yiv790705516MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><div style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; padding: 0in 0in 0in 4pt;"><div><div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;"><p class="yiv790705516MsoNormal"><b><span style="font-size: 10pt; font-family: "sans-serif";">From:</span></b><span style="font-size: 10pt; font-family: "sans-serif";"> openid-general-bounces@lists.openid.net [mailto:openid-general-bounces@lists.openid.net] <b>On Behalf Of </b>Francisco
Corella<br><b>Sent:</b> Wednesday, December 22, 2010 2:13 PM<br><b>To:</b> openid-general@lists.openid.net<br><b>Subject:</b> [OpenID] security weakness regarding authentication of the relying party</span></p></div></div><p class="yiv790705516MsoNormal"> </p><table class="yiv790705516MsoNormalTable" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="padding: 0in;" valign="top"><p class="yiv790705516MsoNormal" style="margin-bottom: 12pt;">Hi all,<br><br>There is a security weakness in OpenID which may be already<br>known but is not discussed in the security considerations<br>section of the specification. It hinges on the fact that<br>the OpenID provider does not authenticate the relying party.<br>I discuss the issue in detail in a <a rel="nofollow" target="_blank" href="http://www.pomcor.com/whitepapers/PKAuth.pdf">paper</a>.<br><br>OAuth solves this problem in theory by requiring the OAuth<br>client (the relying party) to
register with the OAuth<br>server. But Google and Yahoo allow unregistered<br>applications, so the problem remains. Btw compulsory<br>registration is a bad idea: imagine a situation where<br>a social site becomes dominant, social login via that site<br>becomes the de facto authentication standard on the Web,<br>every application has to register with the site, and the<br>site can kill any application by revoking its registration.<br><br>The <a rel="nofollow" target="_blank" href="http://www.pomcor.com/whitepapers/PKAuth.pdf">paper</a> proposes a solution to all this. Thanks in<br>advance for any comments.<br><br>-- Francisco</p></td></tr></tbody></table><p class="yiv790705516MsoNormal"><span style="font-size: 10pt; font-family: "sans-serif";"> </span></p></div></div></div></blockquote></td></tr></table>