Thanks for your review, Watson. We've published a new version of the draft addressing your and others' feedback.
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html You can also see the more detailed commits and discussion on GitHub: https://github.com/oauth-wg/oauth-browser-based-apps/issues/70 Responses inline: Reviewer: Watson Ladd > Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by theIESG. These > comments > were written primarily for the benefit of thesecurity area directors. > Document > editors and WG chairs should treat these comments just like any other last > call > comments. The summary of the review is Has Issues. I wish it didn't have to be: it's a > thoroughly written, and a model in many respects for carefully analyzing > the > security properties of a number of choices. However, I think that given the > importance of the document it needs to be more accessible to people who > are not > experts, and there's a number of analysis choices I don't understand. I'm > also > not sure the title is quite right: it sounds like a big replacement, rather > than a detailed guide to the security of OAuth in browser apps. I hope that the abstract and first sentence of the introduction accurately represent the scope of the document, and that it doesn't come across as a big replacement for OAuth. The title is meant to mirror the older draft "OAuth 2.0 for Native Applications". As a reader I did not understand much of the scenario being discussed until > the > very end: the resource server is not on the same domain as the application > is > being retrieved from, and the oauth server might be a third domain from > both. I > had to wait until Section 7 to figure that out. For those of us unused to > Oauth > it might be worth spelling that out: typically my interactions with it are > SSO > where the resource and application are the same. Certain key acronyms like > PCKE > are not defined when first introduced, and used for quite some time, which > also > makes it difficult to understand some sections until getting to them. I > think > these can be straightened out without too much text. We've updated all the acronyms to be referenced on first use and added them to the terminology section. There is a new paragraph in the introduction that should make the cross-domain aspects of common OAuth deployments more clear. I do have some concerns about the analysis. The attacks seem to be centered > around Javascript injection. This gives the attacker incredible power. > However, > the capabilities of the attacker are then centered on 5 specific attacks. > It is > not clear to me why this is justified. Similarly, the presence of the > relaying > server does simplify the story around Oauth token management, but > introduces a > deputy that can be confused. While there are a bunch of security > considerations > added in 6.1.3, this one isn't there. There's a lot about cookies, but > little > about session fixation or other attacks that confuse the link between > clients. > This also affects the token mediating backend. We updated section 5 to clarify why these attacks in particular are relevant to the document, essentially because it focuses on what is unique about javascript injection in the context of OAuth flows. We also added a mention of the relevance to session fixation. Overall I think this is in pretty good shape. Thank you for the feedback. --- Aaron Parecki
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
