Hi Phil, thanks for reviewing it. We incorporated the respective changes in the upcoming -06.
best regards, Torsten. > Am 22.03.2018 um 10:52 schrieb Phil Hunt <phil.h...@oracle.com>: > > Torsten, > > Great document! > > Some minor nits and comments: > > Abstract - double period after first sentence. > >> It updates and extends the OAuth 2.0 Security Threat Model to >> incorporate practical experiences gathered since OAuth 2.0 was >> published and cover new threats relevant due to the broader >> application of OAuth 2.0. > > When I first read, it sounds like this is a replacement for the threat model > or at least could be read that way. I think you mean readers still need to > read 6819. How about... > > "This specification uses the OAuth 2.0 Security Threat Model and supplements > it to incorporate practical experiences gathered"... > > Section 1. > > The paragraph starting “OAuth initially assumed a static…” appears to > continue the previous bullet point. Should the paragraph be indented? > > Last paragraph 3.1.1 >> This kind of injections is covered in >> Section Code Injection. > > Should this say Section 3.5? > > Section 3.1.5 > This paragraph seems unfinished... >> >> Question: Does redirect uri validation solve any problem for >> native apps? Effective against impersonation when used in >> conjunction with claimed HTTPS redirect URIs only. >> For Windows token broker exact redirect URI matching is important >> as the redirect URI encodes the app identity. For custom scheme >> redirects there is a question however it is probably a useful part >> of defense in depth. > > Section 3.4 >> AS returns client_id and its iss in the response. Client compares >> this data to AS it believed it sent the user agent to. > “client_id” and “iss” attributes do not appear to have any marking (<spanx > style=“verb”>) in multiple locations in the document. > > Section 3.5 >> How does an attack look like? > How about: > "An attack looks like:” > > Writing style of the following comment seems like an editors note rather than > a comment for the reader. Rephrase? > >> But this approach conflicts with the idea to enforce exact redirect >> URI matching at the authorization endpoint. Moreover, it has been >> observed that providers very often ignore the redirect_uri check >> requirement at this stage, maybe, because it doesn't seem to be >> security-critical from reading the spec. > > Is this appropriate for a BCP (seems like a WG discussion item)? >> The authors therefore propose to the working group to drop this >> feature in favor of more effective and (hopefully) simpler approaches >> to code injection prevention as described in the following section. > > Section 3.5.1 > > This seems a bit tentatively worded… >> PKCE seem to be the most obvious solution for OAuth clients as it >> available and effectively used today for similar purposes for OAuth >> native apps whereas "nonce" is appropriate for OpenId Connect >> clients. > > Formatting problem (missing line between paragraphs)? >> Note on pre-warmed secrets: An attacker can circumvent the >> countermeasures described above if he is able to create or capture >> the respective secret or code_challenge on a device under his >> control, which is then used in the victim's authorization request. >> Exact redirect URI matching of authorization requests can prevent the >> attacker from using the pre-warmed secret in the faked authorization >> transaction on the victim's device. >> Unfortunately it does not work for all kinds of OAuth clients. It is >> effective for web and JS apps and for native apps with claimed URLs. >> Attacks on native apps using custom schemes or redirect URIs on >> localhost cannot be prevented this way, except if the AS enforces >> one-time use for PKCE verifier or Nonce values. > > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> > _______________________________________________ > 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
