Hi Eric. Thanks again for your review. https://github.com/yaronf/I-D/pull/24 is intended to address your review comments. Text changes made to address each of your comments are listed below.
From: OAuth <oauth-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Monday, August 27, 2018 4:03 AM To: oauth <oauth@ietf.org> Subject: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4649 COMMENTS S 1.2. > 1.2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. You will want to cite 8174 here. < The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", < "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be < interpreted as described in {{RFC2119}}. --- > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they > appear in all capitals, as shown here. S 2.6. > > 2.6. Substitution Attacks > > There are attacks in which one recipient will have a JWT intended for > it and attempt to use it at a different recipient that it was not > intended for. If not caught, these attacks can result in the I don't understand this attack. Can you go into more detail? > For instance, if an OAuth 2.0 {{RFC6749}} access token is presented to an > OAuth 2.0 protected resource > that it is intended for, that protected resource might attempt to gain access > to a different > protected resource by presenting that same access token to the different > protected resource, > which the access token is not intended for. S 3.2. > Therefore, applications MUST only allow the use of cryptographically > current algorithms that meet the security requirements of the > application.. This set will vary over time as new algorithms are > introduced and existing algorithms are deprecated due to discovered > cryptographic weaknesses. Applications must therefore be designed to > enable cryptographic agility. Is this must normative? < Applications must therefore be designed to enable cryptographic agility. --- > Applications MUST therefore be designed to enable cryptographic agility. S 3.2. > may be no need to apply another layer of cryptographic protections to > the JWT. In such cases, the use of the "none" algorithm can be > perfectly acceptable. JWTs using "none" are often used in > application contexts in which the content is optionally signed; then > the URL-safe claims representation and processing can be the same in > both the signed and unsigned cases. I think you probably need to have a clearer "don't use none by default" statement here. > The "none" algorithm should only be used when the JWT is cryptographically > protected by other means. S 3.4. > ECDH-ES ephemeral public key (epk) inputs should be validated > according to the recipient's chosen elliptic curve. For the NIST > prime-order curves P-256, P-384 and P-521, validation MUST be > performed according to Section 5.6.2.3.4 "ECC Partial Public-Key > Validation Routine" of NIST Special Publication 800-56A revision 3 > [nist-sp-800-56a-r3]. Is there an X25519 specification for JWE? If so, you should probably specify the appropriate checks. > Likewise, if the "X25519" or "X448" {{RFC8037}} algorithms are used, > then the values MUST be validated according {{RFC7748}}. S 3.5. > 3.5. Ensure Cryptographic Keys have Sufficient Entropy > > The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] > and the Password Considerations in Section 8.8 of [RFC7518] MUST be > followed. In particular, human-memorizable passwords MUST NOT be > directly used as the key to a keyed-MAC algorithm such as "HS256". If you can't use them "directly" than how should you use them? Do you want to say anything about password hashing (argon, etc.)? > Rather, the principles from {{RFC2898}} SHOULD be used > to derive cryptographic keys from user-supplied passwords. S 3.12. > of JWTs. > > Given the broad diversity of JWT usage and applications, the best > combination of types, required claims, values, header parameters, key > usages, and issuers to differentiate among different kinds of JWTs > will, in general, be application specific. I get that this is the state we find ourselves in, but it seems like it's unfortunate. This might be a good time to re-emphasize the recommendation for explicit types in 3.11. > For new JWT applications, the use of explicit typing is RECOMMENDED. Thanks again, -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
