[Openid-specs-ab] Whether to allow http redirection URIs for confidential clients
Torsten Lodderstedt
torsten at lodderstedt.net
Mon Oct 28 06:41:06 UTC 2013
I agree.
I just wanted to point out the different protection goals of TLS and the ID token.
John Bradley <ve7jtb at ve7jtb.com> schrieb:
>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/20131028/b8aaf081/attachment.html>
More information about the Openid-specs-ab
mailing list