[Openid-specs-ab] Whether to allow http redirection URIs for confidential clients

John Bradley ve7jtb at ve7jtb.com
Fri Oct 25 13:14:03 UTC 2013


To allow http redirect URI for confidential clients we are finessing the fact that the id_token is used for authentication and not the token.
It is not a particularly good argument more of a technicality, however.

The bottom line is that if the client is not using TLS then people are going to fall victim to fire sheep and have codes intercepted.  
That allows a sophisticated attacker to delay the real connection and present the code first.

It is probably easier for the attacker to just clone the session cookies and get in as the user that way, rather than the more complicated theft of a one time code.

In Connect a single session is compromised in this way.

If the user logs in with user name and password over that same connection the attacker has there credentials for that site and possibly others.

Given password reuse, it is better to allow a site to take connect even if one session can be compromised than compromise all sessions with the disclosure of a username and password.

The problem for the IdP is policing who should legitimately be allowed off the hook and who is just being lazy. 

Large IdP could just offer free TLS certs as part of client registration, as a better way to solve the problem.  The current text would allow that.   The IdP is not required to allow http registrations.

John
On 2013-10-25, at 5:39 AM, Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> wrote:

> Here is the sentence you refer to:
> 
> "Therefore, if the client relies on the authorization code for its own
> resource owner authentication, the client redirection endpoint MUST
> require the use of TLS."
> 
> That note was meant for general OAuth 2.0. With OIDC we have the signed
> ID token, so clients will be using that instead to authenticate the
> resource owner.
> 
> I read the entire section carefully, and it's fully in line with section
> 3.1.2.1 that I quoted in my previous email, as well as with what Connect
> has now specified. I.e. there is a strong recommendation to use TLS, but
> there's also the understanding that TLS wouldn't be practical for a
> number of clients and that's taken into account too.
> 
> 
> Vladimir
> 
> 
> On Fri, 2013-10-25 at 07:41 +0200, Torsten Lodderstedt wrote:
>> What about 
>> 
>> http://tools.ietf.org/html/rfc6749#section-10.5
>> 
>> second paragraph, last sentence? 
>> 
>> We explicitly added this statement/requirement in order to address the
>> specific risk associated with code theft when OAuth is used for
>> authentication.
>> 
>> 
>> 
>> Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> schrieb:
>>        Hi John, hi guys,
>> 
>>        It looks like my previous email didn't get through.
>> 
>>        The current OIDC spec doesn't actually relax the TLS requirement in
>>        regard to the redirection endpoint:
>> 
>>        http://tools.ietf.org/html/rfc6749#section-3.1.2.1
>> 
>>        3.1.2.1. [Redirection] Endpoint Request Confidentiality
>> 
>>        The redirection endpoint SHOULD require the use of TLS as described
>>        in Section 1.6 when the requested response type is "code" or "token",
>>        or when the redirection request will result in the transmission of
>>        sensitive credentials over an open network.  This specification does
>>        not mandate the use of TLS because at the time of this writing,
>>        requiring clients to deploy TLS is a significant hurdle for many
>>        client developers.  If TLS is not available, the authorization server
>>        SHOULD warn the resource owner
>>        about the insecure endpoint prior to
>>        redirection (e.g., display a message during the authorization
>>        request).
>> 
>>        So we're actually fine with that.
>> 
>> 
>>        This is the OIDC core redirect_uri spec for the "code" flow:
>> 
>>        http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest
>> 
>>        redirect_uri
>>        REQUIRED. .... When using this flow, the Redirection URI MAY use the
>>        http scheme, provided that the Client Type is confidential, as defined
>>        in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https scheme. 
>>        state
>> 
>> 
>>        And here for the "implicit" flow:
>> 
>>        http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest
>> 
>>        redirect_uri
>>        REQUIRED. ... When using this flow,
>>        the Redirection URI MUST NOT use
>>        the http scheme unless the Client is a native application, in which case
>>        it MAY use the http: scheme with localhost as the hostname. 
>> 
>> 
>>        --
>>        Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
>> 
>> 
>> 
>>        -------- Original Message --------
>>        Subject: Re: Whether to allow http redirection URIs for confidential
>>        clients
>>        From: John Bradley <ve7jtb at ve7jtb.com>
>>        Date: Thu, October 24, 2013 7:54 pm
>>        To: Mike Jones <Michael.Jones at microsoft.com>
>>        Cc: Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com>,
>>        "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net>
>> 
>>        Sorry yes it went back and forth.  
>> 
>>        The question is if we should override the OAuth RFC's requirement for
>>        TLS on the client in favour of allowing adoption of connect by those web
>>        sites that don't implement TLS for login
>>        and session cookies.
>> 
>> 
>>        If a site has no TLS and can have it's cookies and passwords leaked,
>>        then Connect without TLS is arguably no worse than the current situation
>>        and arguably better because at-least the user is not leaking the
>>        password.
>> 
>> 
>>        So do we allow the bad thing to prevent the worse thing?
>> 
>> 
>>        This makes code more likely to leak, and there is no real protection
>>        possible other than using a hmac of the device fingerprint as the nonce,
>>        but a TLS cert for the client is much simpler.
>> 
>> 
>>        John B.
>> 
>>        On 2013-10-24, at 11:37 AM, Mike Jones <Michael.Jones at microsoft.com>
>>        wrote:
>> 
>>        John, you wrote: “At the IIW F2F we took a decision that we should
>>        match the RFC and require the client to have a TLS endpoint if using a
>>        http redirect.(not a custom scheme)”.  While the working group was
>>        leaning that way early in the discussion, Naveen and others pushed back,
>>        and that doesn’t actually match the decision that we recorded in the
>>        notes, which say:
>>        OP may prevent registration of redirect_uris that do not use
>>        https
>>        A confidential client needs to be required to use http
>>        We will discuss this further on the list
>> 
>>        Consider this the start of the further discussion on the list.  What do
>>        people think?
>> 
>>        -- Mike
>> 
>>        From: openid-specs-ab-bounces at lists.openid.net
>>        [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John
>>        Bradley
>>        Sent: Thursday, October 24, 2013 5:42 AM
>>        To: Vladimir Dzhuvinov / NimbusDS
>>        Cc: openid-specs-ab at lists.openid.net
>>        Subject: Re: [Openid-specs-ab] First Release Candidates for final OpenID
>>        Connect specifications
>> 
>> 
>> 
>>        Snip
>>        On 2013-10-24, at 1:36 AM, "Vladimir Dzhuvinov / NimbusDS"
>>        <vladimir at nimbusds.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>>        "When using this flow, the redirection URI
>>        MAY use the http scheme,
>>        provided that the Client Type is confidential, as defined in Section 2.1
>>        of OAuth 2.0; otherwise, it MUST use the https scheme" - This,
>>        surprisingly enough, is relaxed in comparison
>>        tohttp://tools.ietf.org/html/rfc6749#section-10.5.
>> 
>>        RFC 6749 states: "Authorization codes operate as plaintext bearer
>>        credentials, used to verify that the resource owner who granted
>>        authorization at the authorization server is the same resource owner
>>        returning to the client to complete the process.  Therefore, if the
>>        client relies on the authorization code for its own resource owner
>>        authentication, the client redirection endpoint MUST require the use of
>>        TLS."
>> 
>>        Why is Connect, in this particular case, less restrictive than OAuth?
>> 
>> 
>> 
>>        John, can you speak to why we’re allowing http redirect_uri values
>>        when apparently OAuth
>>        doesn’t?
>> 
>>        I had some questions on this point as well. I believe the thinking is
>>        that since the client is protecting the secret and the code is sent to
>>        the /token endpoint with client authentication, even if someone was able
>>        to hijack the code value they couldn't exchange it for the access (and
>>        possibly refresh) tokens. If we are trying to make things simpler, then
>>        just moving all of it to TLS makes sense. To me, the only exception is
>>        localhost. 
>> 
>>        The attacker could inject the authorization code into the same
>>        application as used by the victim in order to impersonate her/him.
>> 
>> 
>>        For this to happen the attacker should also have gained control over the
>>        RP (the application), i.e. have the RPs' authentication credentials.
>> 
>> 
>> 
>> 
>> 
>> 
>>        Early OAuth 2 inherited the idea from OAuth 1 that the client didn't
>>        need to have a TLS cert.  We were matching that.  At the IIW F2F we took
>>        a
>>        decision that we should match the RFC and require the client to have a
>>        TLS endpoint if using a http redirect.(not a custom scheme)
>> 
>> 
>> 
>>        Earlier in this thread there is also a question about exact redirect_uri
>>        matching and if it is required for confidential clients.   In the code
>>        flow if the token is leaked through an open redirector then it can be
>>        presented to the real client and the attacker gets in as the user.
>> 
>> 
>> 
>>        The OAuth AS side mitigation of this is the confidential client passing
>>        the redirect URI to the AS in the token request and the AS performing an
>>        exact match on the redirect URI, and failing if it is different.   In
>>        the wild it appears AS are also not being sufficiently strict  on
>>        matching that and causing some problems in deployments.
>> 
>> 
>> 
>>        The client side mitigation for this is using nonce in the signed token
>>        to allow the client to check on its own if it initiated the
>>        request
>>        through the same browser that presented the code. However that was left
>>        as optional for code.
>> 
>> 
>> 
>>        At the end of the day the reality is that some of the large IdP only
>>        allow exact matching of redirect_uri.   If some are strict and some
>>        allow query parameters then clients using query parameters to carry
>>        state will fail and not be interoperable.
>> 
>> 
>> 
>>        The WG decided that the strict matching of the redirect_uri by those IDP
>>        is allowed by the RFC,  rather than forcing them to change and do
>>        pattern matching for interoperability we precluded clients from hiding
>>        state in the query parameters and forced them to use the "state"
>>        parameter.
>> 
>> 
>> 
>>        So yes for a fully RFC compliant OAuth server with a client that is
>>        truly confidential and not just pretending, it would be secure for the
>>        AS to relax the matching for the redirect_uri in the request to the
>>        authorization server as
>>        long as it records that URI and is doing an
>>        exact string match on it aginst the one sent to the token endpoint.   It
>>        is not however safe for a client to assume all AS are going to act that
>>        way.  The only safe thing for the client is to assume exact string
>>        match.
>> 
>> 
>> 
>>        So while this relates to security issues the final decision was taken
>>        for interoperability of the client.
>> 
>> 
>> 
>>        John B.
>> 
>>        ______________________________________________________________
>> 
>>        Openid-specs-ab mailing list
>>        Openid-specs-ab at lists.openid.net
>>        http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131025/7d2679a4/attachment.p7s>


More information about the Openid-specs-ab mailing list