Re: Should we recommend that return_to url is always HTTPS? What about realm?
So, RP delegation sounds like a very general solution to the problem, and seems okay to push for. But I think there's a much simpler solution that solves the specific problem I described below: RULE: If the realm is http, then the return_to can be either http or https. So this would be legal: realm: http://open.lukeshepard.com/ return_to: https://open.lukeshepard.com/openid/receiver.php This would NOT be legal - you can't go the other way. realm: https://open.lukeshepard.com/ return_to: http://open.lukeshepard.com/openid/receiver.php So, the receiver should be allowed to INCREASE its security level from the realm, but not decrease. This is analogous to wildcards for the protocol instead of just subdomain. Another alternative would be to have explicit wildcards for the protocol, or to allow realms with relative protocols, like: explicit wildcard: *://open.lukeshepard.com relative protocol: //open.lukeshepard.com On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote: I agree that RP delegation should be possible and even desirable. To do that safely the OP needs to do RP discovery over SSL or discover a XRD with detached sig for the RP. Otherwise you open up Man in the Middle attacks. My point was that in the existing spec to prevent interception of tokens and attributes, the Realm that is displayed by the OP to the user needs to match where the assertion is sent. I agree that this is something that should be addressed in openID 2.1 ether for XRD with dsig or via XRDS with TLS. John B. On 14-May-09, at 12:24 AM, Dirk Balfanz wrote: I don't see why a realm shouldn't be able to delegate to a return_to URL the same way that a user id can delegate to an OP endpoint. This includes delegating from http to https, or even to a different domain altogether. Over on the XRI TC we've been talking about how to do this securely, e.g., by signing the XRD that does the delegation: http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile Dirk. On Wed, May 13, 2009 at 7:43 PM, John Bradley jbrad...@mac.com wrote: Luke, Realm was called trust_root in 1.1, and is a bit like audience restriction in SAML. It is the display version of the return_to, and also used for RP discovery by the OP. I am not certain what the problem is with it being https: if the return_to is https:. There is explicitly no connection to be inferred by DNS authority between URI differing in scheme. Differentiating TLS by its own scheme is a decision we have to live with. The user should consent to authentication for the site they are logging into. http://open.lukesheppard.com and https://open.lukesheppard.com could be different sites. If the RP has both HTTP and HTTPS the best practice would be to always use the https: version for realm so that RP discovery cant be spoofed via DNS. Regards John B. On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote: Date: Tue, 12 May 2009 23:10:38 -0700 From: Luke Shepard lshep...@facebook.com Subject: Should we recommend that return_to url is always HTTPS? What about realm? To: OpenID Specs Mailing List specs@openid.net Message-ID: c62fb26e.bce7%lshep...@facebook.com mailto:c62fb26e.bce7%25lshep...@facebook.com Content-Type: multipart/related; boundary=_004_C62FB26EBCE7lshepardfacebookcom_; type=multipart/alternative --_004_C62FB26EBCE7lshepardfacebookcom_ Content-Type: multipart/alternative; boundary=_000_C62FB26EBCE7lshepardfacebookcom_ --_000_C62FB26EBCE7lshepardfacebookcom_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In testing my relying party, it seems clear that the return_to url SHOULD a= lways be HTTPS. Therefore, then, the realm will always need to be HTTPS as = well. If the return_to is HTTP, then if the response comes in the form of a POST = from a provider that supports SSL, then the user will see a browser warning= for posting to an insecure form. Here's an example: - realm: http://open.lukeshepard.com/ - return_to: http://open.lukeshepard.com/openid/receiver.php - provider endpoint: https://www.google.com/accounts/o8/ud Let's suppose that the response is too long for a GET redirect, so the prov= ider chooses to POST (as Google and others sometimes do). The user would see a warning like this: [cid:3325014638_6495490] To preserve the user experience and avoid that popup, relying parties would= want to make sure their receiver is HTTPS. Alternative What do you think about loosening the realm/return_to protocol/domain match= requirements? This kinda sucks though, since it means the REALM also must be HTTPS, even = though the HTTP version would seem to be canonical. I wonder, would we al= low an HTTPS return_to if the realm was HTTP? It seems that the HTTP versio= n of the realm would be better, and should be able to mean accept either p= rotocol. Or better yet, you should be able to specify a realm without a pr= otocol at all. Thoughts
Re: Should we recommend that return_to url is always HTTPS? What about realm?
Thanks for your feedback John. From a URI point of view the two URI are different and it can't be considered steeping up security. I understand that is what would normally happen but it violates some basic principals. I'd like to see if we can find a compromise between the core principals and how those are actually applied in the real world. Frankly, this rule of protocol matching has been a royal pain when coding my OpenID relying party, making it more difficult than it needs to be. For Facebook apps, we configure apps based on their domain, and don't care about the protocol. Similarly, I'd like to enable RPs that just don't care to be able to say I just don't care - either protocol is fine. What are the attack vectors that you worry would be exposed with this rule change, that aren't allowed in the current spec? It also compromises RP discovery. How come? The OP can still perform discovery against the realm, the return_to doesn't really matter. A wildcard in the realm may be the better solution. Though you may not want to include matching all protocols. Maybe the spec could declare that a wildcard only applies to HTTP and HTTPS. Are there others we care about? PPID like identifiers. I'm not familiar with PPID, do you mind explaining how this affects the proposal? On 5/14/09 9:29 AM, John Bradley jbrad...@mac.com wrote: Luke, From a URI point of view the two URI are different and it can't be considered steeping up security. I understand that is what would normally happen but it violates some basic principals. It also compromises RP discovery. A wijldcard in the realm may be the better solution. Though you may not want to include matching all protocols. In the other thread we are discussing PPID like identifiers. If they are based on the realm as people are discussing, introducing wildcards etc introduces the question of realm normalization on that side. John Bradley On 14-May-09, at 11:25 AM, Luke Shepard wrote: So, RP delegation sounds like a very general solution to the problem, and seems okay to push for. But I think there's a much simpler solution that solves the specific problem I described below: RULE: If the realm is http, then the return_to can be either http or https. So this would be legal: realm: http://open.lukeshepard.com/ return_to: https://open.lukeshepard.com/openid/receiver.php This would NOT be legal - you can't go the other way. realm: https://open.lukeshepard.com/ return_to: http://open.lukeshepard.com/openid/receiver.php So, the receiver should be allowed to INCREASE its security level from the realm, but not decrease. This is analogous to wildcards for the protocol instead of just subdomain. Another alternative would be to have explicit wildcards for the protocol, or to allow realms with relative protocols, like: explicit wildcard: *://open.lukeshepard.com relative protocol: //open.lukeshepard.com On 5/14/09 7:19 AM, John Bradley jbrad...@mac.com wrote: I agree that RP delegation should be possible and even desirable. To do that safely the OP needs to do RP discovery over SSL or discover a XRD with detached sig for the RP. Otherwise you open up Man in the Middle attacks. My point was that in the existing spec to prevent interception of tokens and attributes, the Realm that is displayed by the OP to the user needs to match where the assertion is sent. I agree that this is something that should be addressed in openID 2.1 ether for XRD with dsig or via XRDS with TLS. John B. On 14-May-09, at 12:24 AM, Dirk Balfanz wrote: I don't see why a realm shouldn't be able to delegate to a return_to URL the same way that a user id can delegate to an OP endpoint. This includes delegating from http to https, or even to a different domain altogether. Over on the XRI TC we've been talking about how to do this securely, e.g., by signing the XRD that does the delegation: http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile Dirk. On Wed, May 13, 2009 at 7:43 PM, John Bradley jbrad...@mac.com wrote: Luke, Realm was called trust_root in 1.1, and is a bit like audience restriction in SAML. It is the display version of the return_to, and also used for RP discovery by the OP. I am not certain what the problem is with it being https: if the return_to is https:. There is explicitly no connection to be inferred by DNS authority between URI differing in scheme. Differentiating TLS by its own scheme is a decision we have to live with. The user should consent to authentication for the site they are logging into. http://open.lukesheppard.com and https://open.lukesheppard.com could be different sites. If the RP has both HTTP and HTTPS the best practice would be to always use the https: version for realm so that RP discovery cant be spoofed via DNS. Regards John B. On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote: Date: Tue, 12 May 2009 23:10:38 -0700
Re: Requiring Pseudonymous Identifier
Agreed. If all you want is a group, then I'd think that the response would just not include an identifier. You could use an extension, perhaps AX, to request information about the group a user belongs to. For example, if you wanted to understand company membership, you could request and return only http://axschema.org/company/name. On 5/12/09 11:08 PM, Martin Atkins m...@degeneration.co.uk wrote: Chris Messina wrote: So, imagine I use directed identity in a school application... when I sign in to the OP, it will return something like schoolname.edu/student as the identifier. Overloading our existing concept of an identifier to support identifying a group worries me. Most consumers expect an identifier to be for a person and are designed around this principle. I think if groups are useful their design should be different such that consumers are able to distinguish between a user and a group. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?
As I suggested, an OP may want to give an updated session via checkid-immediate. Facebook Connect does this, and it seems like a legit use case to me. From: Andrew Arnott andrewarn...@gmail.com To: Allen Tom a...@yahoo-inc.com Cc: Luke Shepard; OpenID Specs Mailing List specs@openid.net Sent: Wed May 13 17:05:00 2009 Subject: Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid? I would expect a decent OP to consider that it goes without saying that checkid_immediate wouldn't have a reasonable OAuth token authorizing scenario and block it. So I agree it's good to call it out in the spec. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre On Tue, May 12, 2009 at 10:06 PM, Allen Tom a...@yahoo-inc.commailto:a...@yahoo-inc.com wrote: Hi Luke, I don't think there's a session fixation issue with Hybrid, but I believe that several individuals raised concerns regarding auto-approval of OAuth tokens using regular OAuth, which is essentially the same thing as checkid_immediate mode in Hybrid. Is there really a reason why an RP would need the OAuth token returned in a checkid_immediate response if the user had previously authorized one on an earlier visit? Allen Luke Shepard wrote: (hijacking thread a bit) Allen- If I understand it correctly, the OAuth security issue doesn’t affect the hybrid spec in the same way. With the OAuth session fixation vulnerability, the problem comes if the attacker does the following: 1. Request a request token by pretending to request access 2. Force the user to go to a url using that request token 3. Muah! Calculate what the return_to url would have been, and use the pre-known request token to gain access to the user’s account info. In the OAuth hybrid flow, there is no pre-registered request token; instead, the token is returned, securely, in the URL. It is protected by the fact that OpenID requires the realm to match the return_to, and many providers can require that the Oauth request realm also match the OpenID realm. In this flow, there’s no way for the attacker to intercept the request_token before it makes its way back to the correct user. Perhaps the problem is more subtle than I understood, but I just want to make sure I’m clear on the issues. On 5/12/09 9:48 PM, Allen Tom a...@yahoo-inc.comhttp://a...@yahoo-inc.com wrote: Hi Nat, Here you go: http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html We might need to revise the spec to not support checkid_immediate for the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a bad thing, in light of the recent OAuth security issue. Allen Nat Sakimura wrote: Hi. Where can I find the most current version of OpenID / OAuth hybrid spec draft? I would like to look at it to see if I can borrow as much from the draft for what I am thinking right now. ___ specs mailing list specs@openid.nethttp://specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.netmailto:specs@openid.net http://openid.net/mailman/listinfo/specs attachment: winmail.dat___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Defining how OpenID should behave with fragments in the return_to url
This thread has been really useful - thanks for the responses everyone. I have a few inline responses to a few different emails, bear with me while I try to unify the thread. From Breno: The very legitimate question here is whether it is acceptable for the OpenID spec to define that the query can be encoded in the fragment if a fragment is present in the return_to URL. If the spec were to say it is valid, then there is no incorrect behavior (as no other spec is otherwise violated). Yup, great point. We can just say that it is valid (as Google and Yahoo have implemented it today) thus blessing this as a potential optimization going forward. From Allen: Given that this fragment technique is intended to improve the user experience, especially in the context of a popup window, I think that we may be able to document the correct behavior this in the forthcoming UI Extension. After thinking a bit more on this, I realized that while performance of the checkid_setup call in the popup is important, it's a one-time cost so not that big of a deal. A much bigger issue is the performance of checkid_immediate in an iframe. For Connect, we do the equivalent of that on every single page. For OpenID, I can see a case where a relying party would run a checkid_immediate on every page (to make sure the user was still logged in). In fact, a relying party might want to check multiple OpenID providers on a page load - maybe even dozens or hundreds, potentially. If they did that, then the performance of each call would definitely be a much bigger issue, and this HTTP load would become more important. From James: Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. The POST response is a good point and clearly a valid use case, and I think it's supported no matter what we decide to do. It's possible to build a receiver that handles POST params if they are present, but otherwise serves up the correct cache headers and Javascript to handle the GET. That would provide a performance boost in the common case, while still being fully compatible with the spec. From Martin: To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Maybe having the fragment is a clue, but I'd prefer an even more explicit clue- like what if the RP could say don't send POST requests back, just send no more than X chars in the GET no matter what. Then the OP could just drop data if it went over the limit ... or something. On 3/25/09 9:26 PM, James Henstridge ja...@jamesh.id.au wrote: On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote: James Henstridge wrote: On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote: One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that sounds hackish and I'd love to hear feedback on a better way to do this. How would this interact with OpenID providers that respond via a POST request instead of a GET? This is something they are permitted to do according to the spec, and may decide to do so even if the authentication request was started with a GET if the response is large enough. This is a good point, but it seems like again it can be worked around by making openid_reciever.html accept POST requests. Unlike the query string, this can't be done completely client side, but it ought to be reasonably simple to set up some kind of rewriterule or other indirection trick to make POST requests to openid_reciever.html actually get served by a non-static endpoint. Any intermediate caches would also drop their cached versions when they see a POST request too (assuming they follow the standards), but I suppose it'd still be a win if the POST requests are infrequent. This is starting to become a lot more complicated than the simple static return_to page from the initial proposal though. To be honest, I'd be surprised if POST requests from OP to RP worked interoperably today, but the trick of using the # on the end of the return_to URL to signal to a supporting OP I'm trying to do this completely client-side, so don't do a POST request works here too. Disallowing post responses limits the use of the more verbose extensions (e.g. attribute exchange). While this might be acceptable for Luke's particular use case, it might leave it unsolved for others. It might be worth going back to basics and considering whether there are other solutions. The stated aim was to provide the best user experience
Re: Defining how OpenID should behave with fragments in the return_to url
Ha - thanks Breno :) I'm basically saying that the spec is ambiguous, which is proven by the fact that multiple major providers have different interpretations of how to handle this case. When given a return_to url of http://open.domain.com/openid_receiver.html?query#hash, there are two options for how to return the response: 1. http://open.domain.com/openid_receiver.html?queryopenid.ns=#hash 2. http://open.domain.com/openid_receiver.html?query#hashopenid.ns= Section 4.1.2 of the spec says: When a message is sent to an HTTP server, it MUST be encoded using a form encoding specified in Section 17.13.4 of [HTML401] (W3C, HTML 4.01 Specification, .). According to the URI spec, the fragment portion is explicitly undefined, so the right way to do this is Option #1, which is to include it in the query string Option #2 is therefore technically wrong. However, it has the nice side effect of allowing this performance optimization. So we should have a way for the RP to specify that they want the return in the fragment, not the query, for performance reasons. I don't think this is something super urgent, but it should be clarified in the next version of the spec. We can probably work it out next time we're in person. On 3/24/09 4:28 PM, Breno de Medeiros br...@google.com wrote: I must confess that Google's support is also accidental :) Thanks for pointing it out to us, though, we will keep in mind not to ever fix it. On Tue, Mar 24, 2009 at 3:12 PM, Dirk Balfanz balf...@google.com wrote: Wait - isn't Luke saying that Yahoo! is currently supporting this just fine? What are you fixing? Dirk. On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom a...@yahoo-inc.com wrote: Hi Luke, I have to confess that I was not aware of technique of passing parameters after the fragment to take advantage of browser caching, until you blogged about it. Since then, we've noticed that developers have been doing this, and in fact, we fixed the same bug on our OAuth service just last week. We will update our OP to support return_to URLs with a fragment. I'll let you know when it's fixed. Thanks Allen Luke Shepard wrote: Hi- I've noticed an ambiguity with the way URLs are handled that exists in the current spec. I'm hoping we can resolve it for OpenID 2.1. When we move the OpenID transaction into a popup window, we need a way for the popup to communicate back with the parent. The way to do this is to set a return_to URL that, when loaded, reads the parameters and communicates with the parent window somehow. Here's a description of a technique: http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/ A simple way to do this is to have a simple receiver. The response will append query parameters: http://open.lukeshepard.com/openid_receiver.php?openid.ns=.. However, there is a small performance problem with this approach. The user will see a blank-looking popup for a moment while the server processes the OpenID arguments. An optimization is to put up a simple, cacheable static HTML file that chucks the OpenID params back to the parent frame. The parent can then provide some visual feedback to the user while it sends the OpenID parameters off for processing. This results in a snappier experience. If the static HTML file has no parameters and sends out long-lived cache headers, then the response won't even trigger a server load, and the whole process can appear faster to the user. In this case, the response would look like this: http://open.lukeshepard.com/openid_receiver.html#openid.ns=.. Note that the hash appears instead of a question-mark. That tells the browser that it doesn't need to load an extra file, and it can save perhaps a quarter or half second of latency for the user on average. Okay, so the point is that different OpenID providers currently interpret the hash differently. I think we should explicitly define a behavior that makes sense and accomodates the above suggestion. Here's how they currently behave. When given a return_to of http://open.lukeshepard.com/openid_receiver.html?query#hash Google: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns= Yahoo: http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns= MySpaceID: http://open.lukeshepard.com/openid_receiver.html?queryopenid.ns=#hash MyOpenID: fails outright - invalid return_to By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. But the correct way doesn't allow the performance optimization listed above. I'd like to see a way to accommodate the hash url. One crude way to do it would be to have the caller specify that they want the return_to args simply appended instead of integrated into the URL- perhaps an argument like openid.append_return_to_params=true. But that sounds hackish and I'd love to hear feedback on a better way to do this. Also, let me know if this is the wrong
