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

Discussion:

Samuel Erdtman

2017-02-21 05:57:19 UTC

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

William Denniss

2017-02-21 06:44:27 UTC

Permalink

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.

Post by Samuel Erdtman
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

Denis

2017-02-21 08:50:08 UTC

Permalink

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

Post by William Denniss
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.
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.
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
https://www.ietf.org/mailman/listinfo/oauth

William Denniss

2017-02-21 20:17:47 UTC

Permalink

Post by Denis
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
The authorization server *MUST *authenticate the client *whenever possible*.
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.
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.

_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Justin Richer

2017-02-21 23:09:03 UTC

Permalink

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

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.
I don't think it's normal to have normative text in the Security Considerations, hence I support Samuel's position.
The authorization server MUST authenticate the client whenever possible.
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.
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.
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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Samuel Erdtman

2017-02-27 16:47:49 UTC

Permalink

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

Post by Justin Richer
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
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.

Post by Denis
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
The authorization server *MUST *authenticate the client *whenever possible*.
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.
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.

_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

William Denniss

2017-03-03 06:37:24 UTC

Permalink

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.

Post by Samuel Erdtman
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

Post by Denis
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
The authorization server *MUST *authenticate the client *whenever possible*.
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.
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.

Post by Samuel Erdtman
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
https://www.ietf.org/mailman/listinfo/oauth

Samuel Erdtman

2017-03-06 06:13:43 UTC

Permalink

Thanks Denis!

Post by William Denniss
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.

Post by Samuel Erdtman
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

Post by Justin Richer
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
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.

Post by Denis
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
The authorization server *MUST *authenticate the client *whenever possible*.
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.
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.

Post by Samuel Erdtman
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
https://www.ietf.org/mailman/listinfo/oauth