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

[Samuel Erdtman]

Thanks Denis!

On Fri, Mar 3, 2017 at 7:37 AM, William Denniss  wrote:

> 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  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  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 
>>> 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  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
  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 

Re: [OAUTH-WG] Conclusion of 'OAuth Security Topics' Call for Adoption

[John Bradley]

A BCP is still assigned a RFC number.  

The intent is to have BCP number as well.  

EG BCP195’s current instance is RFC 7525.

The intent is to have a BCP series but the process is largely the same as I 
understand it.

John B.


> On Mar 4, 2017, at 3:10 PM, Torsten Lodderstedt  
> wrote:
> 
> Hi Hannes,
> 
> just for clarification: as far as I remember the proposal in Seoul was to 
> turn the document into a BCP. 
> 
> Is this consistent with your expectation?
> 
> kind regards,
> Torsten.
> 
>> Am 20.02.2017 um 12:02 schrieb Hannes Tschofenig :
>> 
>> Hi all,
>> 
>> earlier this month we issued a call for adoption of the OAuth security
>> topics draft, see draft-lodderstedt-oauth-security-topics-00, and the
>> response was quite positive on the list (as well as during the last f2f
>> meeting).
>> 
>> For this reason, we ask the authors to submit a WG version of the
>> document and to discuss new content for the document in preparation for
>> the next meeting.
>> 
>> Note that the intention of the document is to discuss security topics as
>> they relate to the work in the OAuth working group. As this initial
>> document already does, it describes a problem statement and outlines
>> various ways to mitigate the problems. I expect the working group to
>> decide which solution approach is most appropriate and to detail it (at
>> a specification level) in a separate document (some of those documents
>> already exist in the working group). This should help us make decisions
>> that are not just point solutions for specific problems but rather
>> consider the big picture.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> 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