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