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

John Bradley ve7jtb at ve7jtb.com
Mon Oct 28 00:44:39 UTC 2013


That's true.  However if an attacker can firesheep the user nothing is safe.

While I personally think giving every RP a free cert is the best solution to this issue, that probably won't happen (though startssl certs are free, I don't know what would happen if everyone asked for one.)  The financial argument is weak, it is mostly a lazy RP argument and verry small hosted guys who cant run TLS on some free services.

Allowing http: to be an exception AS can make is not totally unreasonable,  however Caution needs to be taken by the IdP not to be too loose about it.  Offer a free cert first.

If they won't do TLS connect using the code flow and a confidential client is still better than a password.

John B.



 

On Oct 27, 2013, at 1:29 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:

> 
> Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> schrieb:
>> 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.
> 
> The ID token won't prevent an attacker to steal a code on the wire and use it to login with the victim's identity at the legitimate website (client). The Id token prevents a rough client from impersonating a user.
> 
>> 
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131027/aee1b447/attachment-0001.html>
-------------- 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/20131027/aee1b447/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list