[OpenID] Google discovery prototype: dual discovery paths

[Manger, James H]

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).”





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.



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.



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.



A separate discovery path – unrelated to web browsing – breaks the link between web security and OpenID security.



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.





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.



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.





James Manger
James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>
Identity and security team — Chief Technology Office — Telstra

From: Breno de Medeiros [mailto:breno at google.com]
Sent: Friday, 17 July 2009 6:29 AM
To: Manger, James H
Cc: general at openid.net
Subject: Re: [OpenID] Google discovery prototype: dual discovery paths



This is an interesting topic.



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).



One level could be assigned to http identifiers and https identifiers based on discovery without signatures.



A higher security level could be assigned to http and https identifiers where discovery was validated via signatures.



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.



On Thu, Jul 16, 2009 at 7:21 AM, Manger, James H <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>> wrote:

If we do end up with dual discovery paths:

1.       making a GET request directly to an OpenID identifier; or

2.       following a decoupled discovery path (eg request to Google) backed by trusted signatures on the resultant XRDS files;

then an OpenID login can be compromised by either path.



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.





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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090717/3daefd7c/attachment.htm>