Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Vladimir Dzhuvinov]

On 29/07/16 06:09, Jim Manico wrote:
> Thank you Justin, comments inline.
>
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really). 
> This still sounds like sensitive data, and I don't understand the relevance 
> of "human memorable". If time allows can you tell me more?
>
>> Also, this needs to be used over TLS. 
> Sure, but the problems of HTTP Basic are well established and go beyond TLS 
> (no timeout, included in each request, cached by the browser for that window 
> session, etc).
The browser is not involved in the token request.

One alternative to HTTP Basic (and its POST variant) is for the client
to authenticate by submitting a JWT hashed with the client secret, or a
JWT signed with an RSA or EC key that was previously registered with the AS:

https://tools.ietf.org/html/rfc7523#section-2.2

I find JWT auth the more secure method, as it mitigates against some
attacks previously discussed here. And it also lessens the potential
security damage if the client accidentally makes a plain HTTP request to
the token endpoint (the client_secret itself is not leaked).

>
>> The connection requires TLS anyway because the tokens returned (or the token 
>> keys in the OAuth PoP case) also need to be protected, regardless of how you 
>> hash the client’s secret. With that in mind, Digest doesn’t buy you much.
> So this looks like a way to transport the client id and secret. Wouldn't some 
> form of "strong authentication" like mutual TLS or similar be a better 
> default standard? The OAuth 2 threat model makes this exact recommendation.
>
> Respectfully,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
>
>> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>>
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really). Also, this needs 
>> to be used over TLS. The connection requires TLS anyway because the tokens 
>> returned (or the token keys in the OAuth PoP case) also need to be 
>> protected, regardless of how you hash the client’s secret. With that in 
>> mind, Digest doesn’t buy you much.
>>
>> — Justin
>>
>>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>>
>>> Please forgive me if this comment is out of order or inappropriate in any 
>>> way...
>>>
>>> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
>>> security properties at multiple levels; shouldn't we at least move to HTTP 
>>> Digest if not something stronger?
>>>
>>> Regards.
>>> --
>>> Jim Manico
>>> @Manicode
>>>
 On Jul 26, 2016, at 4:48 PM, RFC Errata System  
 wrote:

 The following errata report has been submitted for RFC6749,
 "The OAuth 2.0 Authorization Framework".

 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6749=4749

 --
 Type: Technical
 Reported by: Phil Hunt 

 Section: 2.3.1

 Original Text
 -
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password.  The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.

 Corrected Text
 --
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password. The url encoded values are then encoded as defined in
 [RFC2617]. The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.

 Notes
 -
 It was not clear to some implementers that the intention is a 2-step 
 encoding. First for special characters and second the 2617 base 64 
 encoding.  Implementers thought 6749 was in conflict with 2617.

 To avoid inter-op issues, a new clarifying sentence is proposed.
 "The url encoded values are then encoded as defined in [RFC2617]."

 Instructions:
 -
 This erratum is currently posted 

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Phil Hunt (IDM)]

This is off topic for the errata process. This is not the place to propose a 
re-write. 

As one of the authors of the threat model and sec considerations I think we 
covered this to too much. :-) Justin's comments are spot on. 

This has nothing to do with user authentication. 

Phil

> On Jul 28, 2016, at 8:09 PM, Jim Manico  wrote:
> 
> Thank you Justin, comments inline.
> 
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really).
> 
> This still sounds like sensitive data, and I don't understand the relevance 
> of "human memorable". If time allows can you tell me more?
> 
>> Also, this needs to be used over TLS.
> 
> Sure, but the problems of HTTP Basic are well established and go beyond TLS 
> (no timeout, included in each request, cached by the browser for that window 
> session, etc).
> 
>> The connection requires TLS anyway because the tokens returned (or the token 
>> keys in the OAuth PoP case) also need to be protected, regardless of how you 
>> hash the client’s secret. With that in mind, Digest doesn’t buy you much.
> 
> So this looks like a way to transport the client id and secret. Wouldn't some 
> form of "strong authentication" like mutual TLS or similar be a better 
> default standard? The OAuth 2 threat model makes this exact recommendation.
> 
> Respectfully,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
>> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
>> 
>> These are client secrets, not user passwords, so they’re supposed to be high 
>> entropy and not human-memorable (or human-typable really). Also, this needs 
>> to be used over TLS. The connection requires TLS anyway because the tokens 
>> returned (or the token keys in the OAuth PoP case) also need to be 
>> protected, regardless of how you hash the client’s secret. With that in 
>> mind, Digest doesn’t buy you much.
>> 
>> — Justin
>> 
>>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>>> 
>>> Please forgive me if this comment is out of order or inappropriate in any 
>>> way...
>>> 
>>> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
>>> security properties at multiple levels; shouldn't we at least move to HTTP 
>>> Digest if not something stronger?
>>> 
>>> Regards.
>>> --
>>> Jim Manico
>>> @Manicode
>>> 
 On Jul 26, 2016, at 4:48 PM, RFC Errata System  
 wrote:
 
 The following errata report has been submitted for RFC6749,
 "The OAuth 2.0 Authorization Framework".
 
 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
 
 --
 Type: Technical
 Reported by: Phil Hunt 
 
 Section: 2.3.1
 
 Original Text
 -
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password.  The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.
 
 Corrected Text
 --
 Clients in possession of a client password MAY use the HTTP Basic
 authentication scheme as defined in [RFC2617] to authenticate with
 the authorization server.  The client identifier is encoded using the
 "application/x-www-form-urlencoded" encoding algorithm per
 Appendix B, and the encoded value is used as the username; the client
 password is encoded using the same algorithm and used as the
 password. The url encoded values are then encoded as defined in
 [RFC2617]. The authorization server MUST support the HTTP Basic
 authentication scheme for authenticating clients that were issued a
 client password.
 
 Notes
 -
 It was not clear to some implementers that the intention is a 2-step 
 encoding. First for special characters and second the 2617 base 64 
 encoding.  Implementers thought 6749 was in conflict with 2617.
 
 To avoid inter-op issues, a new clarifying sentence is proposed.
 "The url encoded values are then encoded as defined in [RFC2617]."
 
 Instructions:
 -
 This erratum is currently posted as "Reported". If necessary, please
 use "Reply All" to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Jim Manico]

Thank you Justin, comments inline.

> These are client secrets, not user passwords, so they’re supposed to be high 
> entropy and not human-memorable (or human-typable really). 

This still sounds like sensitive data, and I don't understand the relevance of 
"human memorable". If time allows can you tell me more?

> Also, this needs to be used over TLS. 

Sure, but the problems of HTTP Basic are well established and go beyond TLS (no 
timeout, included in each request, cached by the browser for that window 
session, etc).

> The connection requires TLS anyway because the tokens returned (or the token 
> keys in the OAuth PoP case) also need to be protected, regardless of how you 
> hash the client’s secret. With that in mind, Digest doesn’t buy you much.

So this looks like a way to transport the client id and secret. Wouldn't some 
form of "strong authentication" like mutual TLS or similar be a better default 
standard? The OAuth 2 threat model makes this exact recommendation.

Respectfully,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jul 28, 2016, at 4:25 PM, Justin Richer  wrote:
> 
> These are client secrets, not user passwords, so they’re supposed to be high 
> entropy and not human-memorable (or human-typable really). Also, this needs 
> to be used over TLS. The connection requires TLS anyway because the tokens 
> returned (or the token keys in the OAuth PoP case) also need to be protected, 
> regardless of how you hash the client’s secret. With that in mind, Digest 
> doesn’t buy you much.
> 
> — Justin
> 
>> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
>> 
>> Please forgive me if this comment is out of order or inappropriate in any 
>> way...
>> 
>> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
>> security properties at multiple levels; shouldn't we at least move to HTTP 
>> Digest if not something stronger?
>> 
>> Regards.
>> --
>> Jim Manico
>> @Manicode
>> 
>>> On Jul 26, 2016, at 4:48 PM, RFC Errata System  
>>> wrote:
>>> 
>>> The following errata report has been submitted for RFC6749,
>>> "The OAuth 2.0 Authorization Framework".
>>> 
>>> --
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
>>> 
>>> --
>>> Type: Technical
>>> Reported by: Phil Hunt 
>>> 
>>> Section: 2.3.1
>>> 
>>> Original Text
>>> -
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password.  The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>> 
>>> Corrected Text
>>> --
>>> Clients in possession of a client password MAY use the HTTP Basic
>>> authentication scheme as defined in [RFC2617] to authenticate with
>>> the authorization server.  The client identifier is encoded using the
>>> "application/x-www-form-urlencoded" encoding algorithm per
>>> Appendix B, and the encoded value is used as the username; the client
>>> password is encoded using the same algorithm and used as the
>>> password. The url encoded values are then encoded as defined in
>>> [RFC2617]. The authorization server MUST support the HTTP Basic
>>> authentication scheme for authenticating clients that were issued a
>>> client password.
>>> 
>>> Notes
>>> -
>>> It was not clear to some implementers that the intention is a 2-step 
>>> encoding. First for special characters and second the 2617 base 64 
>>> encoding.  Implementers thought 6749 was in conflict with 2617.
>>> 
>>> To avoid inter-op issues, a new clarifying sentence is proposed.
>>> "The url encoded values are then encoded as defined in [RFC2617]."
>>> 
>>> Instructions:
>>> -
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --
>>> RFC6749 (draft-ietf-oauth-v2-31)
>>> --
>>> Title   : The OAuth 2.0 Authorization Framework
>>> Publication Date: October 2012
>>> Author(s)   : D. Hardt, Ed.
>>> Category: PROPOSED STANDARD
>>> Source  : Web Authorization Protocol
>>> Area: Security
>>> Stream  : IETF
>>> Verifying Party : IESG
>>> 
>>> 

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Justin Richer]

These are client secrets, not user passwords, so they’re supposed to be high 
entropy and not human-memorable (or human-typable really). Also, this needs to 
be used over TLS. The connection requires TLS anyway because the tokens 
returned (or the token keys in the OAuth PoP case) also need to be protected, 
regardless of how you hash the client’s secret. With that in mind, Digest 
doesn’t buy you much.

 — Justin

> On Jul 26, 2016, at 8:08 PM, Jim Manico  wrote:
> 
> Please forgive me if this comment is out of order or inappropriate in any 
> way...
> 
> ...but why is HTTP Basic even being discussed in 2016? It has horrific 
> security properties at multiple levels; shouldn't we at least move to HTTP 
> Digest if not something stronger?
> 
> Regards.
> --
> Jim Manico
> @Manicode
> 
>> On Jul 26, 2016, at 4:48 PM, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC6749,
>> "The OAuth 2.0 Authorization Framework".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
>> 
>> --
>> Type: Technical
>> Reported by: Phil Hunt 
>> 
>> Section: 2.3.1
>> 
>> Original Text
>> -
>> Clients in possession of a client password MAY use the HTTP Basic
>> authentication scheme as defined in [RFC2617] to authenticate with
>> the authorization server.  The client identifier is encoded using the
>> "application/x-www-form-urlencoded" encoding algorithm per
>> Appendix B, and the encoded value is used as the username; the client
>> password is encoded using the same algorithm and used as the
>> password.  The authorization server MUST support the HTTP Basic
>> authentication scheme for authenticating clients that were issued a
>> client password.
>> 
>> Corrected Text
>> --
>> Clients in possession of a client password MAY use the HTTP Basic
>> authentication scheme as defined in [RFC2617] to authenticate with
>> the authorization server.  The client identifier is encoded using the
>> "application/x-www-form-urlencoded" encoding algorithm per
>> Appendix B, and the encoded value is used as the username; the client
>> password is encoded using the same algorithm and used as the
>> password. The url encoded values are then encoded as defined in
>> [RFC2617]. The authorization server MUST support the HTTP Basic
>> authentication scheme for authenticating clients that were issued a
>> client password.
>> 
>> Notes
>> -
>> It was not clear to some implementers that the intention is a 2-step 
>> encoding. First for special characters and second the 2617 base 64 encoding. 
>>  Implementers thought 6749 was in conflict with 2617.
>> 
>> To avoid inter-op issues, a new clarifying sentence is proposed.
>> "The url encoded values are then encoded as defined in [RFC2617]."
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC6749 (draft-ietf-oauth-v2-31)
>> --
>> Title   : The OAuth 2.0 Authorization Framework
>> Publication Date: October 2012
>> Author(s)   : D. Hardt, Ed.
>> Category: PROPOSED STANDARD
>> Source  : Web Authorization Protocol
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> 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

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

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (4749)

[Jim Manico]

Please forgive me if this comment is out of order or inappropriate in any way...

...but why is HTTP Basic even being discussed in 2016? It has horrific security 
properties at multiple levels; shouldn't we at least move to HTTP Digest if not 
something stronger?

Regards.
--
Jim Manico
@Manicode

> On Jul 26, 2016, at 4:48 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6749=4749
> 
> --
> Type: Technical
> Reported by: Phil Hunt 
> 
> Section: 2.3.1
> 
> Original Text
> -
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password.  The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
> 
> Corrected Text
> --
> Clients in possession of a client password MAY use the HTTP Basic
> authentication scheme as defined in [RFC2617] to authenticate with
> the authorization server.  The client identifier is encoded using the
> "application/x-www-form-urlencoded" encoding algorithm per
> Appendix B, and the encoded value is used as the username; the client
> password is encoded using the same algorithm and used as the
> password. The url encoded values are then encoded as defined in
> [RFC2617]. The authorization server MUST support the HTTP Basic
> authentication scheme for authenticating clients that were issued a
> client password.
> 
> Notes
> -
> It was not clear to some implementers that the intention is a 2-step 
> encoding. First for special characters and second the 2617 base 64 encoding.  
> Implementers thought 6749 was in conflict with 2617.
> 
> To avoid inter-op issues, a new clarifying sentence is proposed.
> "The url encoded values are then encoded as defined in [RFC2617]."
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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