Should we recommend that return_to url is always HTTPS? What about realm?

Thu May 14 17:35:50 UTC 2009

Breno,

I agree completely RP discovery over https:  or with dsig is the best  
option.
I have been pushing people to take RP discovery seriously for some time.

Some day we should stop talking about 2.1 and start work.

Until then we have to live with a number of "bone-headed"  things in  
2.0.

John B.
On 14-May-09, at 1:18 PM, Breno de Medeiros wrote:

> 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 <jbradley at 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" <jbradley at 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 <jbradley at 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-request at openid.net wrote:
>>  >
>>> Date: Tue, 12 May 2009 23:10:38 -0700
>>> From: Luke Shepard <lshepard at facebook.com>
>>> Subject: Should we recommend that return_to url is always HTTPS?  
>>> What
>>  > about realm?
>>> To: OpenID Specs Mailing List <specs at openid.net>
>>> Message-ID: <C62FB26E.BCE7%lshepard at facebook.com
>>> <mailto:C62FB26E.BCE7%25lshepard at 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 at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>  >
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
>
>
> -- 
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090514/5c508609/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1722 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090514/5c508609/attachment-0002.bin>