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 <tony...@microsoft.com> > 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
