Hi Phil, 

thanks for reviewing it. We incorporated the respective changes in the upcoming 

best regards,

> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

OAuth mailing list

Reply via email to