<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 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0cm;
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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</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-AU" link="blue" vlink="purple">
<div class="Section1">
<p class="MsoNormal">Breno said: “Another approach that has been suggested is two preserve the identifier formats, but assign different security levels depending on how they were authenticated (assuming that the RP is security-sensitive at all).”<o:p></o:p></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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">That might work, at the cost of some complexity. It means an RP’s account database (that records an OpenID identifier + level) will be more explicit about
the security for each account – though this is unlikely to be visible to users.<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 don’t think you can say, in general, that discovery involving a signed XRD[S] has a “higher security level” than current (OpenID 2.0) discovery. Current
discovery of an HTTPS OpenID involves digital signatures & certificates. Even discovery of an HTTP OpenID might involve verifying DNSSEC digital signatures for part of the process. The widely-accepted trust roots for HTTPS certificates, the trust roots for
DNS resolution, and any future widely-accepted trust roots for signing XRD[S] are 3 schemes with different security – but trying to order that security (eg low, medium, high) is likely to be a subjective call.<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">OpenID currently avoids confronting this “variable security level” issue. It can get away with this because the security of an HTTP or HTTPS URI used as an
OpenID identifier is basically the same as the security of using the URI as a normal web address. Normal web use gives us a (hopefully realistic) understanding of this security. Whatever the wider web “decides” for security (when DNSSEC is deployed; which
new root CAs are widely accepted; how routing protocols are secured …) effectively defines the security you get from OpenID.<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">A separate discovery path – unrelated to web browsing – breaks the link between web security and OpenID security.<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">If the separate discovery path requires at least 1 request to the site associated with an OpenID identifier (and at least 1 https request if an https OpenID
is used) then the link to web security (as a minimum) is preserved.<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D">If an RP notes whether signed XRDS or direct connections were used during an OpenID authentication exchange, perhaps it should also note: whether a domain-validated
or extended-validation (EV) certificate was used; or which specific CA was used; or the key lengths and algorithms used; or if DNSSEC was used. All these facets (and more) affect the security level of the authentication.
<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">Perhaps forcing OpenID to explicitly address this issue is good for OpenID in the long-term. However, I suspect moving away from “OpenID security = web security”
will hurt OpenID: it will miss the sweet spot; few people will understand the security.<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="FR" style="font-family:"Arial","sans-serif";
color:#1F497D">James Manger</span></b><span style="color:#1F497D">
<br>
<a href="mailto:James.H.Manger@team.telstra.com"><span lang="FR" style="font-size:10.0pt;font-family:"Arial","sans-serif"">James.H.Manger@team.telstra.com</span></a>
<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";
color:#1F497D">Identity and security team</span><span style="color:#1F497D">
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D">—</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"> Chief Technology Office</span><span style="color:#1F497D">
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D">—</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D"> Telstra</span><span style="color:#1F497D">
</span><span style="font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:
"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;
font-family:"Tahoma","sans-serif""> Breno de Medeiros [mailto:breno@google.com]
<br>
<b>Sent:</b> Friday, 17 July 2009 6:29 AM<br>
<b>To:</b> Manger, James H<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] Google discovery prototype: dual discovery paths<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is an interesting topic.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Another approach that has been suggested is two preserve the identifier formats, but assign different security levels depending on how they were authenticated (assuming that the RP is security-sensitive at all).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One level could be assigned to http identifiers and https identifiers based on discovery without signatures.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A higher security level could be assigned to http and https identifiers where discovery was validated via signatures.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, if an RP notices that an account is usually logged in through a higher security mechanism but now it is following a lower security one, then this could be considered a downgrade of security level. Typically one would employ a suitable
account recovery process to validate that this is a legitimate login attempt as opposed to a possible hijacking.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jul 16, 2009 at 7:21 AM, Manger, James H <<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p>If we do end up with dual discovery paths:<o:p></o:p></p>
<p style="text-indent:-18.0pt">1.<span style="font-size:7.0pt"> </span>making a GET request directly to an OpenID identifier; or<o:p></o:p></p>
<p style="text-indent:-18.0pt">2.<span style="font-size:7.0pt"> </span>following a decoupled discovery path (eg request to Google) backed by trusted signatures on the resultant XRDS files;<o:p></o:p></p>
<p>then an OpenID login can be compromised by either path.<o:p></o:p></p>
<p> <o:p></o:p></p>
<p>A motivation for path #2 was that it is hard for a small business to make its website extremely secure from attacks that could modify web pages. However, even RPs that try path #2 will also try path #1 (unless we totally ditch OpenID 1.1 & 2.0 support!)
so attacks modifying a small business’s web pages can still compromise their OpenID logins.<o:p></o:p></p>
<p> <o:p></o:p></p>
<p> <o:p></o:p></p>
<p>One way to prevent dual paths reducing security for each other would be if each path applied to different OpenID identifiers. That is, only use path #1 for http & https OpenID identifiers; and use some other form of OpenID identifier for path #2.<o:p></o:p></p>
<p> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>