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

From: William Denniss <[email-masked]>
Date: Thu, 2 Mar 2017 22:37:24 -0800

Thanks all for the great discussion. I tweaked the discussion on
public/confidential clients to rely more on the OAuth2 definition (it was a
bit duplicative), and I reordered the security considerations so it flows
better, but have kept the normative language for now. Let's see how it pans
out during the finalization process.

On Mon, Feb 27, 2017 at 8:47 AM, Samuel Erdtman <[email-masked]> wrote:

> Thanks for the replies.
>
> If there are no formal guidelines from IETF I think we should just proceed
> it is a good and informative spec, it was just to me it felt slightly of.
>
> Based on the conversation I have no objections taking this draft to RFC.
>
> //Samuel
>
> On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer <[email-masked]> wrote:
>
>> When I brought RFCs 7591, 7592, and 7662 up through the finalization
>> process, I learned that there are two camps out there on normative
>> requirements in the security considerations section. Some like them, as
>> long as they don’t contradict requirements/advice in previous sections, and
>> some don’t like them, preferring all normative material be in the “body” of
>> the spec itself. I was given the impression that it was more of a stylistic
>> choice than anything, but I can only speak from my personal experience.
>>
>>  — Justin
>>
>> On Feb 21, 2017, at 3:17 PM, William Denniss <[email-masked]> wrote:
>>
>> The only real requirement in that section I guess is the use of PKCE
>> (8.2).  That requirement could be moved to the body of the doc, while
>> keeping the longer discussing around code interception in the security
>> considerations.  To me the remaining text are indeed security best
>> practices / clarifications.
>>
>> Other OAuth WG RFCs have requirement level capitalization in the Security
>> Section like RFC7591. I always assumed these were best-practice security
>> requirements. But if the style is really not to do this, the requirement
>> level capitalization could be dropped from that section in the native apps
>> BCP.
>>
>> On Tue, Feb 21, 2017 at 12:50 AM, Denis <[email-masked]> wrote:
>>
>>>
>>> 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 <[email-masked]>
>>> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 6 Mar 2017 07:13:43 +0100

Thanks Denis!

On Fri, Mar 3, 2017 at 7:37 AM, William Denniss <[email-masked]> wrote:

>> If there are no formal guidelines from IETF I think we should just
>> proceed it is a good and informative spec, it was just to me it felt
>> slightly of.
>>
>>> Other OAuth WG RFCs have requirement level capitalization in the
>>> Security Section like RFC7591. I always assumed these were best-practice
>>> security requirements. But if the style is really not to do this, the
>>> requirement level capitalization could be dropped from that section in the
>>> native apps BCP.
>>>
>>>> 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
>>>> 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.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.
>>>> 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