Re: [OAUTH-WG] OAuth Security -- Next Steps
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 On 28/07/16 00:53, Brian Campbell wrote: > 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 > wrote: > >> 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:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig >> Sent: Monday, July 25, 2016 3:59 AM >> To: oauth@ietf.org >> 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. >> >> 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 >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Security -- Next Steps
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 wrote: > 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:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Monday, July 25, 2016 3:59 AM > To: oauth@ietf.org > 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. > > 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 > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Security -- Next Steps
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:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, July 25, 2016 3:59 AM To: oauth@ietf.org 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. 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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. 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 signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
