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

Discussion:

Torsten Lodderstedt

2016-04-23 11:47:06 UTC

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.

Nat Sakimura

2016-04-29 08:08:15 UTC

Permalink

Post by Torsten Lodderstedt
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 specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)
Anyone having an opinion?
best regards,
Torsten.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Torsten Lodderstedt

2016-04-30 17:57:30 UTC

Permalink

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.

Post by 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
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 specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)
Anyone having an opinion?
best regards,
Torsten.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

John Bradley

2016-04-30 18:22:24 UTC

Permalink

The attacks we are talking about (other than cut and paste) are not compromising the integrity of the response.

They rely on the response not containing enough information about the request that is received by the AS for the client to detect tampering with the request, or tricking the client into creating a new client_id based on bad information that includes the token or RS endpoint of the attacker.

As we discussed at IIW we need to do a better job creating a taxonomy for the parts of the attacks.

At the moment when we say mixup that may mean quite different things to people.

Signing the response on itâs own is not much help. The reason the connect id_token helps is not so much the signature, but rather that it contains the issuer and client_id as proposed in the draft Mike and I worked on.

If we wanted to sign something it would be better to sign the request to prevent a authorization request sent to one AS from being modified and sent to another AS.

It is also worth noting that the per AS redirect URI are not effective on there own agains all of the things in the bucket of mix up attacks.

I personally prefer that OpenID Connect not add anything new to mitigate this, however education on how to use the existing features for people who are concerned, or at risk is a responsible thing to do.

John B.

Post by Torsten Lodderstedt
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.

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?
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 <https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00>
proposes reasonable mitigations for both attacks. There are alternatives
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5>)
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)
Anyone having an opinion?
best regards,
Torsten.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

t***@lodderstedt.net

2016-04-30 18:42:41 UTC

Permalink

So what's your proposal for OAuth?

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

Post by John Bradley
The attacks we are talking about (other than cut and paste) are not compromising the integrity of the response.
They rely on the response not containing enough information about the request that is received by the AS for the client to detect tampering with the request, or tricking the client into creating a new client_id based on bad information that includes the token or RS endpoint of the attacker.
As we discussed at IIW we need to do a better job creating a taxonomy for the parts of the attacks.
At the moment when we say mixup that may mean quite different things to people.
Signing the response on itâs own is not much help. The reason the connect id_token helps is not so much the signature, but rather that it contains the issuer and client_id as proposed in the draft Mike and I worked on.
If we wanted to sign something it would be better to sign the request to prevent a authorization request sent to one AS from being modified and sent to another AS.
It is also worth noting that the per AS redirect URI are not effective on there own agains all of the things in the bucket of mix up attacks.
I personally prefer that OpenID Connect not add anything new to mitigate this, however education on how to use the existing features for people who are concerned, or at risk is a responsible thing to do.
John B.

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

John Bradley

2016-04-30 18:59:45 UTC

Permalink

I made it in the draft.

Adding a identifier for the AS and the client_id to the response allows the client to detect if the request has been misdirected.

I did have another proposal for integrity protecting the the request by having the client and AS calculate a HMAC over parts of the request and the code from the response. That was the least crypto solution I could come up with for integrity protecting the request in a way the client can validate.

The problem is that not every client has a secret to sign the request with, so that leaves the AS effectively signing what it received in the request.

The other option is for OAuth clients not to talk to multiple AS, and not allow XSRF to trigger login requests.

The impression I have from the work group is that they are not comfortable enough understanding the attacks and there implications to work on mitigations yet.

I would be happy if someone else has a better idea on how to close these holes that requires minimal extra work by the client and AS.

At the moment I am trying to focus on Token binding and other things that people are interested in making progress on.

John B.

Post by t***@lodderstedt.net
So what's your proposal for OAuth?
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection
The attacks we are talking about (other than cut and paste) are not compromising the integrity of the response.
They rely on the response not containing enough information about the request that is received by the AS for the client to detect tampering with the request, or tricking the client into creating a new client_id based on bad information that includes the token or RS endpoint of the attacker.
As we discussed at IIW we need to do a better job creating a taxonomy for the parts of the attacks.
At the moment when we say mixup that may mean quite different things to people.
Signing the response on itâs own is not much help. The reason the connect id_token helps is not so much the signature, but rather that it contains the issuer and client_id as proposed in the draft Mike and I worked on.
If we wanted to sign something it would be better to sign the request to prevent a authorization request sent to one AS from being modified and sent to another AS.
It is also worth noting that the per AS redirect URI are not effective on there own agains all of the things in the bucket of mix up attacks.
I personally prefer that OpenID Connect not add anything new to mitigate this, however education on how to use the existing features for people who are concerned, or at risk is a responsible thing to do.
John B.

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Justin Richer

2016-05-01 05:21:52 UTC

Permalink

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

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Nat Sakimura

2016-05-01 05:36:32 UTC

Permalink

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.

Post by Justin Richer
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
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.
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?

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Torsten Lodderstedt

2016-05-01 07:54:04 UTC

Permalink

Hi Nat,

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

kind regards,
Torsten.

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.

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Nat Sakimura

2016-05-09 03:43:34 UTC

Permalink

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.

Post by Torsten Lodderstedt
Hi Nat,
please explain the attack. I assume the attacker would need to control
network transmission or client device.
kind regards,
Torsten.
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.

Post by Justin Richer
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 <
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.
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 <

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

t***@lodderstedt.net

2016-05-09 05:45:51 UTC

Permalink

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

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

Post by Nat Sakimura
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.

Post by Justin Richer
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 <
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.
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 <

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

Nat Sakimura

2016-05-09 19:26:25 UTC

Permalink

Hi Torsten,

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

Nat

Post by t***@lodderstedt.net
Are you suggesting OAuth should defeat maleware? So far, this was
considered to be handled by OS/Anti-Virus/other measures.
-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection
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.

Post by Torsten Lodderstedt
Hi Nat,
please explain the attack. I assume the attacker would need to control
network transmission or client device.
kind regards,
Torsten.
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.

Post by Justin Richer
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 <
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.
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 <

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

t***@lodderstedt.net

2016-05-10 05:53:32 UTC

Permalink

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.

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

Post by Nat Sakimura
Hi Torsten,
No, not defeating, but being able to find out if the input is tainted or
not.
Nat

Post by Torsten Lodderstedt
Hi Nat,
please explain the attack. I assume the attacker would need to control
network transmission or client device.
kind regards,
Torsten.
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.

Post by Justin Richer
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 <
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.
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 <

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

William Denniss

2016-05-02 02:07:57 UTC

Permalink

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.

Post by Nat Sakimura
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.

Post by Justin Richer
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 <
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.
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 <

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Dominick Baier

2016-05-02 06:11:45 UTC

Permalink

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 (***@google.com) 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.

On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura <***@gmail.com> 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.
On Sun, May 1, 2016 at 14:21 Justin Richer <***@mit.edu> 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 <***@lodderstedt.net> 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 <***@lodderstedt.net> 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
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2016-05-04 16:29:44 UTC

Permalink

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 <

Post by Torsten Lodderstedt
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.
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?

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Daniel Fett

2016-05-05 14:20:43 UTC

Permalink

Post by 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 specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)
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

Nat Sakimura

2016-05-09 03:45:00 UTC

Permalink

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

Post by Torsten Lodderstedt

threats.

Post by Torsten Lodderstedt
https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

Daniel Fett

2016-05-10 08:23:40 UTC

Permalink

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

Post by Nat Sakimura
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

Post by 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

Post by Torsten Lodderstedt
and OAuth) or adopt a OpenId-specific solution to OAuth (use id!

tokens

Post by Torsten Lodderstedt
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both

threats.

Post by Torsten Lodderstedt
https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are

alternatives

Post by Torsten Lodderstedt
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside

state for

Post by Torsten Lodderstedt
counter XSRF)
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

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

Antonio Sanso

2016-05-17 06:34:20 UTC

Permalink

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 <***@uni-trier.de<mailto:***@uni-trier.de>> wrote:

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:
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

2016å¹Ž5æ5æ¥(æš) 23:28 Daniel Fett <***@uni-trier.de<mailto:***@uni-trier.de>
<mailto:***@uni-trier.de>>:

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)

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

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative

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

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

Nat Sakimura

2016-05-17 06:37:43 UTC

Permalink

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.

Post by Antonio Sanso
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
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
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
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 specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
-- use of the nonce parameter (as a distinct mitigation beside
state for
counter XSRF)
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
--
Informationssicherheit und Kryptografie
UniversitÃ€t Trier - Tel. 0651 201 2847 - H436
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative