Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 1 May 2016 09:54:04 +0200

Hi Nat,

please explain the attack. I assume the attacker would need to control network transmission or client device.

kind regards,
Torsten.

> Am 01.05.2016 um 07:36 schrieb Nat Sakimura <[email-masked]>:
> 
> It actually depends on what risk level the transaction is at. For low risk transactions, just having separate redirection endpoint may be adequate. On the other hand, I can easily think of an attack that replaces iss on the authz response making the control invalid posing questions on whether it is worth introducing it. 
>> On Sun, May 1, 2016 at 14:21 Justin Richer <[email-masked]> wrote:
>> I agree that we’re getting dangerously close to recommending signed assertions at every step of the process, thereby bypassing HTTP. This was the same mistake that WS-* and SOAP made, let’s not repeat it if we can.
>> 
>>  — Justin
>> 
>>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <[email-masked]> wrote:
>>> 
>>> Hi Nat,
>>> 
>>> sure, one could also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part. 
>>> I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well. 
>>> Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms. 
>>> I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.
>>> kind regards,
>>> Torsten.
>>>> Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
>>>> As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it. 
>>>> 
>>>> Any concrete ideas? 
>>>> 
>>>>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <[email-masked]> wrote:
>>>>> Hi all,
>>>>> 
>>>>> discussion about Mix-Up and CnP seems to have stopped after the session
>>>>> in BA - at least in the OAuth WG. There is a discussion about
>>>>> mitigations in OpenId Connect going on at the OpenId Connect mailing list.
>>>>> 
>>>>> I'm very much interested to find a solution within the OAuth realm as
>>>>> I'm not interested to either implement two solutions (for OpenId Connect
>>>>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
>>>>> in the front channel). I therefore would like to see progress and
>>>>> propose to continue the discussion regarding mitigations for both threats.
>>>>> 
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
>>>>> proposes reasonable mitigations for both attacks. There are alternatives
>>>>> as well:
>>>>> - mix up:
>>>>> -- AS specific redirect uris
>>>>> -- Meta data/turi
>>>>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
>>>>> - CnP:
>>>>> -- use of the nonce parameter (as a distinct mitigation beside state for
>>>>> counter XSRF)
>>>>> 
>>>>> Anyone having an opinion?
>>>>> 
>>>>> best regards,
>>>>> Torsten.
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Denniss <[email-masked]>
Date: Sun, 1 May 2016 19:07:57 -0700

I'm inclined to think that Nat's comment is right: "As I look at it more
and more, it started to look like the problem of accepting tainted values
without message authentication. To fix the root cause, we would have to
authenticate response. ID Token was designed to also serve as a solution
anticipating it."

Even if we workaround the current issue with more unbound plain text
params, will it solve the *next* issue?  Personally I'm not convinced.

I also wonder at what level of risk is the right solution "code id_token",
which the researchers note *will* mitigate the attacks (when implemented
correctly).

If we absolutely must solve this without "id_token", I know John has a few
ideas for lightweight binding of the request & response by hashing the
request URL and some config. I wonder if a "lightweight crypto" approach is
superior to "more unbound params" as the best non-id_token option.

On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura <[email-masked]> wrote:

> It actually depends on what risk level the transaction is at. For low risk
> transactions, just having separate redirection endpoint may be adequate. On
> the other hand, I can easily think of an attack that replaces iss on the
> authz response making the control invalid posing questions on whether it is
> worth introducing it.
>> I agree that we’re getting dangerously close to recommending signed
>> assertions at every step of the process, thereby bypassing HTTP. This was
>> the same mistake that WS-* and SOAP made, let’s not repeat it if we can.
>>
>>  — Justin
>>
>> sure, one could also authenticate and cryptographically protect the
>> redirect response. Leveraging OIDC concepts is an idea worth considering
>> but they should be adopted to the OAuth philosophy. The id token as used in
>> the hybrid flows mixes an identity assertion with elements of transport
>> security measures. A OAuth AS does not provide identity data to clients, so
>> we only need the transport security part.
>>
>> I personally would prefer a OAuth response object (similar to request
>> object you have proposed) over the id token. Such a response object could
>> contain (and directly protect) state, code and other response values. I
>> consider this the more elegant design and it is easier to implement then
>> having detached signatures over hash values of codes or access tokens.
>> Moreover, it would allow to encrypt the response as well.
>>
>> Generally, our threat analysis so far does not have provided
>> justification for cryptographically protected redirect responses. All
>> proposals currently on the table stop mix up and code injection using
>> simpler mechanisms.
>>
>> I think OAuth 2.0 is a huge success due to its balance of versatility,
>> security and _simplicity_. We definitely need to keep it secure, but we
>> should also keep it as simple as possible.
>>
>> kind regards,
>> Torsten.
>> As I look at it more and more, it started to look like the problem of
>> accepting tainted values without message authentication. To fix the root
>> cause, we would have to authenticate response. ID Token was designed to
>> also serve as a solution anticipating it.
>>
>> Any concrete ideas?
>>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 2 May 2016 08:11:45 +0200

The id_token is a validatable protocol response - OAuth on its own cannot provide this and i doubt it is worth teaching teaching it new tricks. 

I personally have moved on to always add id_token as a response type - together with OIDC discovery, in my mind OIDC is a superset of OAuth and I always use them together - or put differently - I recommend against using OAuth on its own without OIDC (besides client_creds/extension grants scenarios of course).

— 
cheers
Dominick Baier

On 2 May 2016 at 04:08:25, William Denniss ([email-masked]) wrote:

I'm inclined to think that Nat's comment is right: "As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it."

Even if we workaround the current issue with more unbound plain text params, will it solve the next issue?  Personally I'm not convinced.

I also wonder at what level of risk is the right solution "code id_token", which the researchers note will mitigate the attacks (when implemented correctly).

If we absolutely must solve this without "id_token", I know John has a few ideas for lightweight binding of the request & response by hashing the request URL and some config. I wonder if a "lightweight crypto" approach is superior to "more unbound params" as the best non-id_token option.

 — Justin

Hi Nat,

kind regards,
Torsten.

Any concrete ideas?

best regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 4 May 2016 10:29:44 -0600

Sorry to chime in late but I wanted to say that I strongly agree with
Torsten's characterization of things.

On Sat, Apr 30, 2016 at 11:57 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Generally, our threat analysis so far does not have provided justification
> for cryptographically protected redirect responses. All proposals currently
> on the table stop mix up and code injection using simpler mechanisms.
>

---

From: Daniel Fett <[email-masked]>
Date: Thu, 5 May 2016 16:20:43 +0200

>From our formal analysis of OAuth we are pretty confident that the
mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be
sufficient against the Mix-Up attack.

Cheers,
Daniel

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 09 May 2016 03:43:34 +0000

Yes, and unfortunately, that is a rather common attack these days.
Infesting a user device with a malware is probably easier than having the
client developer register its client to unknown server.

>>> Anyone having an opinion?
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 09 May 2016 03:45:00 +0000

Hi Daniel,

May I ask again why separate redirect uri would not work for mix-up?
(I know, it does not work for cut-n-paste.)

Thanks,

Nat

---

From: [email-masked]
Date: Mon, 09 May 2016 07:45:51 +0200

Are you suggesting OAuth should defeat maleware? So far, this was considered to be handled by OS/Anti-Virus/other measures.

---

From: [email-masked]
Date: Mon, 09 May 2016 07:45:51 +0200

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 09 May 2016 19:26:25 +0000

Hi Torsten,

No, not defeating, but being able to find out if the input is tainted or
not.

Nat
On Mon, May 9, 2016 at 07:46 <[email-masked]> wrote:

> Are you suggesting OAuth should defeat maleware? So far, this was
> considered to be handled by OS/Anti-Virus/other measures.
>
>
>> It actually depends on what risk level the transaction is at. For low
>> risk transactions, just having separate redirection endpoint may be
>> adequate. On the other hand, I can easily think of an attack that replaces
>> iss on the authz response making the control invalid posing questions on
>> whether it is worth introducing it.

---

From: [email-masked]
Date: Tue, 10 May 2016 07:53:32 +0200

Hi Nat,

wouldn't a maleware steal the response and the cookies from the device and replay it somewhere else. Or just steal the password? So no need to tweak the response?

best regards,
Torsten.

---

From: Daniel Fett <[email-masked]>
Date: Tue, 10 May 2016 10:23:40 +0200

It does not work if the AS does not check the redirect URI completely.
Facebook being the main example here, and I guess they won't change this
soon (for backwards compatibility). Adding the iss parameter won't break
things.

-Daniel

Am 09.05.2016 um 05:45 schrieb Nat Sakimura:
> 2016年5月5日(木) 23:28 Daniel Fett <[email-masked]
> <mailto:[email-masked]>>:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 17 May 2016 06:34:20 +0000

hi,

FWIW Facebook is not the only one here.
Many OAuth provider do not do exact matching redirect uri validation. Github for example is another….

regards

antonio

On May 10, 2016, at 10:23 AM, Daniel Fett <[email-masked]<mailto:[email-masked]>> wrote:

-Daniel

Thanks,

Nat

2016年5月5日(木) 23:28 Daniel Fett <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>:

   Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt:
I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId
   Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id!
   tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both
   threats.

https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are
   alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside
   state for
counter XSRF)

   Cheers,
   Daniel

   _______________________________________________
   OAuth mailing list
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 17 May 2016 06:37:43 +0000

We knew that's a bad practice and causes woes that OIDC mandated exact
match before the completion of OAuth. I wish we have insisted more on it.
Oh, well.
On Tue, May 17, 2016 at 15:34 Antonio Sanso <[email-masked]> wrote:

> On May 10, 2016, at 10:23 AM, Daniel Fett <[email-masked]> wrote:
>
> <mailto:[email-masked] <[email-masked]>>>:
>
>    [email-masked] <mailto:[email-masked] <[email-masked]>>