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

Fri Oct 25 05:37:23 UTC 2013

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> 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>
>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/20131025/e7f869a4/attachment.html>