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 <jric...@mit.edu> 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 <j...@manicode.com> 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 <rfc-edi...@rfc-editor.org> >>>> 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&eid=4749 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Phil Hunt <phil.h...@oracle.com> >>>> >>>> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
