Hi Hannes, I'm glad to hear that you're interest to work on this. The approach in the Trier report was really enlightening to me. I'm still digesting it.
OAuth 2 was created with the promise to be developer friendly and extensible, but compared with some other security protocols, doesn't extend security guarantees to profiles / usages of it. Consider for example TLS, which allows other protocols to ride on top of it, without having to worry about breaking TLS security the way we now do now when thinking of more dynamic use cases of OAuth :) I wish we would come up with some simple recipe that will be easy to explain to developers, and at the same time will guarantee the security in all dynamic use cases. E.g. if you do dynamic discovery then make sure A,B,C... Cheers, Vladimir On 25/02/16 09:43, Hannes Tschofenig wrote: > Vladimir, > > yes, we could do a formal analysis and it would be a very good idea. > It would even go faster if a few of us work together on it. Anyone > interested? > > This would be a good contribution for the workshop in July, btw. > > Ciao > Hannes > > On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote: >> Hi Mike, >> >> You mention that you spent considerable time in research. I wonder if >> there is existing theory, in communications or information theory, that >> can be used to formally establish and prove (or disprove) the security >> of the proposed OAuth measures? Perhaps some work that is totally >> unrelated to identity and the web protocols, but could well apply here? >> >> My reasoning is that we have a closed system that is fairly simple, so >> formal analysis must be entirely possible. >> >> 1. We have 5 parties (client, AS, RS, user, user agent). >> >> 2. The OAuth protocol follows a simple and well-defined pattern of >> messages between the parties. >> >> 3. The points and the number of ways by which an adversary may break >> into OAuth must therefore be finite. >> >> 4. The security requirement is essentially to guarantee the precedence >> and authenticity of the messages from discovery endpoint to RS, and the >> preferred way to do that is by establishing a binding between the >> messages, which can be forward or backward binding. >> >> >> Right now the WG concern is whether all possible attacks have been >> recognised, and then taken care of. If we can have a formal model that >> can reliably reveal and prove that, this will be a huge breakthrough. >> >> Cheers, >> >> Vladimir >> >> >> >> On 20/02/16 12:41, Mike Jones wrote: >>> Suggesting that they be read is of course, the right long-term approach. >>> But as someone who spent 20+ years as a researcher before switching to >>> digital identity, I was sensitive to not wanting to upstage their work by >>> copying too much of their material into our draft before their publications >>> were widely known. I'll of course commit to working the researchers and >>> the working group to create a self-contained concise description of the >>> threats and mitigations in the working group document. >>> >>> Cheers, >>> -- Mike >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >>> Sent: Saturday, February 20, 2016 2:25 AM >>> To: Mike Jones <michael.jo...@microsoft.com>; William Denniss >>> <wdenn...@google.com>; Phil Hunt (IDM) <phil.h...@oracle.com> >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for >>> Adoption >>> >>> Hi Mike, >>> >>> On 02/20/2016 10:52 AM, Mike Jones wrote: >>>> Have you read both of their publications? If not, do yourself a favor >>>> and do. They're actually both very readable and quite informative. >>> I have read both documents. In context of this discussion the question is >>> whether we >>> >>> (a) require them to be read (in which case they should be a normative >>> reference), or >>> (b) suggest them to be read (since they provide additional background >>> information). In this case they are an informative reference. >>> >>> I believe believe we want (b) for the OAuth WG document. While I encourage >>> everyone to read the publications I also believe that there is lots of >>> material in there that goes beyond the information our audience typically >>> reads (such as the text about the formal analysis). >>> >>> There is probably also a middle-ground where we either copy relevant text >>> from the papers into the draft or reference specific sections that are >>> "must-read". >>> >>> One other issue: I actually thought that the threat that is outlined in the >>> research paper is sufficiently well described but the second threat, which >>> is called 'cut-and-paste attack', requires more work. >>> I noted this in my summary mail to the list, see >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >>> >>> 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
