<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.yiv790705516msonormal, li.yiv790705516msonormal, div.yiv790705516msonormal
{mso-style-name:yiv790705516msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.yiv790705516msochpdefault, li.yiv790705516msochpdefault, div.yiv790705516msochpdefault
{mso-style-name:yiv790705516msochpdefault;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.yiv790705516msohyperlink
{mso-style-name:yiv790705516msohyperlink;}
span.yiv790705516msohyperlinkfollowed
{mso-style-name:yiv790705516msohyperlinkfollowed;}
span.yiv790705516emailstyle17
{mso-style-name:yiv790705516emailstyle17;}
p.yiv790705516msonormal1, li.yiv790705516msonormal1, div.yiv790705516msonormal1
{mso-style-name:yiv790705516msonormal1;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.yiv790705516msohyperlink1
{mso-style-name:yiv790705516msohyperlink1;
color:blue;
text-decoration:underline;}
span.yiv790705516msohyperlinkfollowed1
{mso-style-name:yiv790705516msohyperlinkfollowed1;
color:purple;
text-decoration:underline;}
span.yiv790705516emailstyle171
{mso-style-name:yiv790705516emailstyle171;
font-family:"Arial","sans-serif";
color:#1F497D;}
p.yiv790705516msochpdefault1, li.yiv790705516msochpdefault1, div.yiv790705516msochpdefault1
{mso-style-name:yiv790705516msochpdefault1;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Arial","sans-serif";}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:785925276;
mso-list-type:hybrid;
mso-list-template-ids:147727788 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Francisco,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m not entirely sure how the Janrain code works, as I’ve not really looked at it. I’m pretty sure, though, that the OP code I wrote would complain if the “return to” URL is not a sub-domain of the specified realm. It even checks to ensure that the scheme matches (e.g., HTTPS or HTTP must be used in both places). So, I would assume that the example you give below would fail on my server. Not sure, of course… there’s always opportunity for a bug ;-)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I do agree that HTTPS ought to be used everywhere. There are two issues with meeting that requirement. Some argue that these issues are weak arguments, but they are truly an impediment to getting wide adoption:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>TLS certificates are still more expensive than they ought to be. We’re talking about something that can be cranked out entirely automatically and in a fraction of a second and some people believe this “work” is worth more than $100. The cheapest price I’ve seen is $13 per certificate, which is getting close to reasonable, but still too high. The domain name cost less than the certificate! This rip-off needs to end.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Many, many web servers still do not support Server Name Indication (SNI). So, many web sites cannot even provide proper support for TLS. It was for this reason that I wrote my OP server code such that the only piece of software that absolutely, really should be placed behind HTTPS was the one that handles password checks and cookies for checkid_immediate.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Many client libraries still do not support SNI, including those running OpenID RP code. The stock browser on Android and other browsers do not support SNI.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anyway, your statement is correct, but I think there are practical reasons why the standard did not mandate HTTPS.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Let’s assume we mandated use of HTTPS. What are the other issues? I’m still not sure what they are. The example you gave with the return_to URL would not be accepted by my server, I believe. I’d be willing to test that theory :)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Paul<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Francisco Corella [mailto:fcorella@pomcor.com] <br><b>Sent:</b> Tuesday, January 18, 2011 2:10 PM<br><b>To:</b> openid-general@lists.openid.net; Paul E. Jones<br><b>Cc:</b> Karen P. Lewison<br><b>Subject:</b> RE: [OpenID] security weakness regarding authentication of the relying party<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0><tr><td valign=top style='padding:0in 0in 0in 0in'><p class=MsoNormal>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><<a href="mailto:paulej@packetizer.com">paulej@packetizer.com</a>></i></b> wrote:<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><br>From: Paul E. Jones <<a href="mailto:paulej@packetizer.com">paulej@packetizer.com</a>><br>Subject: RE: [OpenID] security weakness regarding authentication of the relying party<br>To: <a href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>, <a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a><br>Date: Friday, January 14, 2011, 11:39 PM<o:p></o:p></p><div id=yiv790705516><div><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Late to reply to this, but I didn’t see other replies…</span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'>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><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'>So, exactly what is the security issue? I’ll not deny there is one, but it is not clear to me.</span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'>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><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Paul</span><o:p></o:p></p><p class=yiv790705516msonormal><span style='font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid windowtext 1.5pt;padding:0in 0in 0in 4.0pt;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color blue'><div><div style='border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:-moz-use-text-color -moz-use-text-color'><p class=yiv790705516msonormal><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Arial","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><o:p></o:p></p></div></div><p class=yiv790705516msonormal> <o:p></o:p></p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0><tr><td valign=top style='padding:0in 0in 0in 0in'><p class=yiv790705516msonormal style='margin-bottom:12.0pt'>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 href="http://www.pomcor.com/whitepapers/PKAuth.pdf" target="_blank">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 href="http://www.pomcor.com/whitepapers/PKAuth.pdf" target="_blank">paper</a> proposes a solution to all this. Thanks in<br>advance for any comments.<br><br>-- Francisco<o:p></o:p></p></td></tr></table><p class=yiv790705516msonormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p></div></div></div></td></tr></table><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p></div></div></body></html>