Re: Should we recommend that return_to url is always HTTPS? What about realm?
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 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? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs smime.p7s Description: S/MIME cryptographic signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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.
Re: Should we recommend that return_to url is always HTTPS? What about realm?
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 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
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: Should we recommend that return_to url is always HTTPS? What about realm?
John, By PPID do you mean the InfoCard unique User:RP identifier? Or are you referring to the use of pseudonymous identifiers within OpenID? If the latter, I didn't see the thread that was suggesting that the pseudonymous identifiers match the realm. I would be against that suggestion. The spec requires the RP to do discovery on the pseudonymous identifier to prove that the OP that returned the response is authoritative for the pseudonymous identifier. With this mechanism, the realm should not need to match the identifier. Thanks, George John Bradley 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 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_;
Re: Should we recommend that return_to url is always HTTPS? What about realm?
The realm and return_to URL matching is the most bone-headed part of the whole 2.0 spec. If discovery on the realm were to produce an XRDS document that contains a return_to URL and the return_to URL discovered matches the one present in the authentication request, than this should be considered a match. Prefix matching should be optional in general (MAY) and only mandatory (MUST) _if_ the realm does not support XRDS discovery. We can then separate algorithmic considerations of correctness from security considerations. The current approach in OpenID discovery is not particularly secure and very inflexible. Opening up this issue for discussion by making the above-suggested minimal change can only be a good thing. On Thu, May 14, 2009 at 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 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;
Re: Should we recommend that return_to url is always HTTPS? What about realm?
George, By PPID I am referring to a pairwise pseudonymous identifier like PPID in info-card or the IDs Google uses. The 2.0 spec talks about OP identifiers being used to allow the user to select an identity at the OP. (badly and in a confusing way) No place in 2.0 talks about pseudonymous identifiers of any sort. So the question is if the user doesn't want there activity correlated, or a RP for PII legal reasons doesn't want a correlatable identifier for the user how should the OP produce such an identifier. Further if that type of identifier is required by the RP how would they indicate that. The realm would only be used by the OP to produce the private personal identifier. Doing this raises additional questions about how to normalize the Realm. Do you want to produce the same PPID for all of these? http://example.com http://www.example.com https://www.example.com http://www.example.com:80 http://www.example.com:443 https://www.example.com:443 http://www.example.com/ The RP might so to make it at least predictable there should be some normalization rule. I am sure Breno will jump in I know this is one of his issues. So while all openIDs are on some sense pseudonymous, I was referring to the pairwise ones. Regards John B. On 14-May-09, at 1:17 PM, George Fletcher wrote: John, By PPID do you mean the InfoCard unique User:RP identifier? Or are you referring to the use of pseudonymous identifiers within OpenID? If the latter, I didn't see the thread that was suggesting that the pseudonymous identifiers match the realm. I would be against that suggestion. The spec requires the RP to do discovery on the pseudonymous identifier to prove that the OP that returned the response is authoritative for the pseudonymous identifier. With this mechanism, the realm should not need to match the identifier. Thanks, George John Bradley 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
Re: Should we recommend that return_to url is always HTTPS? What about realm?
OK, thanks. I think I understand how you are relating realm to PPID. I agree that we probably have to generate the PPIDs on the user:realm pair (note, it would be very nice if realm were included in the association request; but that's a different discussion). Even this causes some problems if a set of RPs share the same realm... but it's the best that can be done right now with the current spec. While realm normalization isn't required for PPIDs to work and be unique, practically we'll have to do something so that users have a least a chance of a consistent experience. Note that this will pretty much require an RP to never change their realm because if they do, all the PPIDs will regenerate and the user's data will be lost. Thanks, George John Bradley wrote: George, By PPID I am referring to a pairwise pseudonymous identifier like PPID in info-card or the IDs Google uses. The 2.0 spec talks about OP identifiers being used to allow the user to select an identity at the OP. (badly and in a confusing way) No place in 2.0 talks about pseudonymous identifiers of any sort. So the question is if the user doesn't want there activity correlated, or a RP for PII legal reasons doesn't want a correlatable identifier for the user how should the OP produce such an identifier. Further if that type of identifier is required by the RP how would they indicate that. The realm would only be used by the OP to produce the private personal identifier. Doing this raises additional questions about how to normalize the Realm. Do you want to produce the same PPID for all of these? http://example.com http://www.example.com https://www.example.com http://www.example.com:80 http://www.example.com:443 https://www.example.com:443 http://www.example.com/ The RP might so to make it at least predictable there should be some normalization rule. I am sure Breno will jump in I know this is one of his issues. So while all openIDs are on some sense pseudonymous, I was referring to the pairwise ones. Regards John B. On 14-May-09, at 1:17 PM, George Fletcher wrote: John, By PPID do you mean the InfoCard unique User:RP identifier? Or are you referring to the use of pseudonymous identifiers within OpenID? If the latter, I didn't see the thread that was suggesting that the pseudonymous identifiers match the realm. I would be against that suggestion. The spec requires the RP to do discovery on the pseudonymous identifier to prove that the OP that returned the response is authoritative for the pseudonymous identifier. With this mechanism, the realm should not need to match the identifier. Thanks, George John Bradley 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
Re: Should we recommend that return_to url is always HTTPS? What about realm?
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.comc62fb26e.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? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
