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

Torsten Lodderstedt torsten at lodderstedt.net
Fri Oct 25 17:25:28 UTC 2013


Am 25.10.2013 14:56, schrieb John Bradley:
>>
>>>      A confidential client needs to be required to use http
>>
>
> That sentence can have two meanings in english.   What was intended was:
> Servers MUST NOT allow http for clients that are not confidential, and 
> MAY allow registration of http redirect URI for confidential clients 
> using the code response type.

Much better wording. Can we use it instead of the current wording??

>
> So the intent was not to force confidential clients to use http though 
> the sentence can also be read that way.
>
>
> On 2013-10-24, at 10:37 PM, Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>> Hi,
>>
>> Why should connect support deployments with a bad security setup? I 
>> don't want our codes to leak and to be abused by attackers.
>>
>> Furthermore: I don't get the intention of " confidential client needs 
>> to be required to use http". Does it mean confidential clients are 
>> forced to use http?
>>
>> Regards,
>> Torsten.
>>
>>
>>
>> John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> schrieb:
>>
>>     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
>>     <mailto: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>[mailto:openid-specs-ab-bounces at lists.openid.net
>>>     <mailto: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
>>>     <mailto: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 <mailto: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  <mailto: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/20131025/8c3759b3/attachment-0001.html>


More information about the Openid-specs-ab mailing list