Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 15 Apr 2018 18:44:45 +0200

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 <[email-masked]>:
> 
> 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/>[email-masked] <mailto:[email-masked]>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth