Subject: [OAUTH-WG] OAuth Security -- Next Steps

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jul 2016 12:59:21 +0200

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am
happy about the progress on many of the subjects. We managed to progress
token exchange, native apps, AMR, and authorization server meta-data. We
also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding
functionality, which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make
some progress on the mix-up mitigation and on the wider range of
security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack
(only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs
to be modified to reflect the preference of the working group. My
impression (from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require
protocol changes but rather relies on configuration. This may include a
combination of exact redirect_URI matching + per-AS redirect_URI +
session state checking. There are also other attacks
described in draft-ietf-oauth-mix-up-mitigation-01, which need to be
moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a
high-level write-up describing various security issues with OAuth that
points to the mostly existing documents for those who want to read the
background information. Torsten has posted a mail to the list providing
one possible outline of such a document.

How does this sound?

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 25 Jul 2016 17:43:31 +0000

Sounds about right, but I would imagine that the BCP would cover any issue that arises not just mix-up

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, July 25, 2016 3:59 AM
To: [email-masked]
Subject: [OAUTH-WG] OAuth Security -- Next Steps

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am happy about the progress on many of the subjects. We managed to progress token exchange, native apps, AMR, and authorization server meta-data. We also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding functionality, which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make some progress on the mix-up mitigation and on the wider range of security documents.

1) It seems that the solution approach to deal with the mix-up attack (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to be modified to reflect the preference of the working group. My impression (from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require protocol changes but rather relies on configuration. This may include a combination of exact redirect_URI matching + per-AS redirect_URI + session state checking. There are also other attacks described in draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a high-level write-up describing various security issues with OAuth that points to the mostly existing documents for those who want to read the background information. Torsten has posted a mail to the list providing one possible outline of such a document.

How does this sound?

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2016 15:53:35 -0600

Agree. The BCP would be larger in scope than just mix-up. And given that
approach, I don't know if it makes sense to have a document specific to
mix-up.

On Mon, Jul 25, 2016 at 11:43 AM, Anthony Nadalin <[email-masked]>
wrote:

> We also did a call for adoption of the OAuth token binding functionality,
> which still needs to be confirmed on the mailing list.
> There are, however, aspects I am not happy with. I was hoping to make some
> progress on the mix-up mitigation and on the wider range of security
> documents.
>
> (only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs to
> be modified to reflect the preference of the working group. My impression
> (from speaking with participants at the meeting last week
> combination of exact redirect_URI matching + per-AS redirect_URI + session
> state checking. There are also other attacks described in
> draft-ietf-oauth-mix-up-mitigation-01, which need to be moved elsewhere to
> avoid confusion.
>
> 2) We need a new document, ideally a BCP, that serves as a high-level
> write-up describing various security issues with OAuth that points to the
> mostly existing documents for those who want to read the background
> information. Torsten has posted a mail to the list providing one possible
> outline of such a document.
>
> How does this sound?
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 28 Jul 2016 10:56:03 +0300

I congratulate the idea for a BCP.

Ideally that would be a document written with the developer in mind,
easy to consume, and outlining all necessary steps to take in order to
harden / patch up an OAuth 2.0 implementation / app. The individual
attacks could be referenced or described in an appendix.

Working from documents that describe an individual attack, or a class of
attacks, where a matching countermeasure is suggested, is harder for
developers (the typical format of security research papers). In
conversations with developers I found out that many of them have indeed
read about the recently discovered problems, but don't have a good
picture of the overall situation, and how to react. Therefore, putting
together a clear course for action, sanctioned by the OAuth WG, would be
really useful.

I also imagine the BCP could suggest two variants for action:

1. For those people who have existing apps in the field, and mostly 3rd
party client developers. They will probably be looking for the minimum
amount of measures to secure their OAuth 2.0 stuff, to minimise
disruption and all sorts of hassle related to updating APIs, clients,
libraries, etc.

2. For people who want to have additional protections to OAuth 2.0 in
place, e.g. JWT assertions for client auth, bound tokens, etc. Typically
companies that are in control of their clients and apps, or those that
consider introducing OAuth 2.0 for the first time.

Thanks,

Vladimir

--