[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.html>
More information about the Openid-specs-ab
mailing list