Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07

I *don't thin**k* it's normal to have normative text in the Security 
Considerations, hence I support Samuel's position.

Let us look at the first MUST from RFC 6749 in the Security 
Considerations section:

    The authorization server*_MUST_ *authenticate the client_*whenever possible*_.

This sentence is incorrect. The right sentence should be :

    The authorization server*should *authenticate the client whenever possible.

RFC 6749 is not an example to follow.

Denis

> I do think it's normal to have normative text in the Security 
> Considerations.  RFC6749 has a lengthy Security Considerations section 
> <https://tools.ietf.org/html/rfc6749#section-10> with a lot of 
> normative text.
>
> Think of it this way: Sections 4 to 7 describe how to use native app 
> URI schemes to perform OAuth flows from the app to browser and back. 
> If you only read those sections, you could have a functioning (but 
> potentially insecure) OAuth flow in a native app. The security section 
> adds some security requirements and clarifications for implementing 
> Sections 4-7, like using PKCE, and more.
>
> Reviewing sub-section by sub-section:
>
> 8.1 Definitely belongs here, as the the whole BCP is about native-app 
> URI schemes, whereas doing OAuth in a WebView doesn't need those (as 
> the client can just pluck out the code from any redirect URI)
> 8.2 Requires that servers who want to follow the native apps BCP 
> support PKCE, and recommends that they reject requests from clients 
> who don't.  This *could* be in the main doc, but since PKCE is an 
> existing thing, and is purely additive from a security perspective, I 
> think this reference works fine. Originally I talked about PKCE more 
> in the doc body, but some reviewers thought it was then a little 
> duplicative of the PKCE doc itself.
> 8.3 This reads like classic security considerations to me, clarifying 
> some details of 7.3
> 8.4 Part of this reads a little new-ish, regarding distinguishing 
> native clients from web ones. But on review, I think could just be 
> re-worded to reference RFC6749 Section 2.1.
> 8.5 This one belongs where it is since the body of the BCP is talking 
> about the code flow.
> 8.6 Totally belongs.
> 8.7 to 8.11 belong IMO, they are security clarifications of 
> long-standing topics.
>
> My methodology when reviewing this was: is the text introducing a new 
> topic directly related to native apps or sections 4-7, or does it 
> discuss an old security topic in the context of native apps, or add 
> security related discussions of the content in 4-7. Of all those, I 
> really only see a bit of new topic related to native apps in 8.4, and 
> in actual fact it that sub-section should probably be reworded since 
> RFC6749 already establishes the public client type, which native apps 
> are and a reference would be more appropriate (which would reduce it 
> to just clarifying an old topic).
>
> What do you think of this analysis? Do you have any specific sections 
> or text you feel are better suited in the document body?  I will take 
> an action item to revise section 8.4.
>
> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman <samuel@erdtman.se 
> <mailto:samuel@erdtman.se>> wrote:
>
>     Hi,
>
>     I just had a question on best practice. In this document a large
>     part of the normative text is located under Security Considerations.
>
>     I had previously seen Security Considerations as things to think
>     about when implementing not so much as MUSTs and MUST NOTs.
>
>     I think it is okay to have it this way but it surprised me a bit
>     and wanted to ask if there is any best practice for the Security
>     Considerations section saying what type of information it should
>     include.
>
>     Best Regards
>     Samuel Erdtman
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth