Thanks again for the review, Eric. The resolutions published in https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04 are as follows...
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. Mike> Done. 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? Mike> Added an example starting with “For instance, if an OAuth 2.0 access token…” to hopefully make this attack clearer. 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? Mike> Now it’s a “MUST”. 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. Mike> Added two sentences to this effect – one about cryptographic protection of the JWT and one about “none” not being a library default. 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. Mike> Cited [RFC8037] security considerations for X25519 and X448. 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.)? Mike> Added a sentence about only using password-based encryption for key encryption, rather than content encryption. Also added a sentence about brute force attacks. 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. We now explicitly say that explicit typing is RECOMMENDED for new JWT applications. Thanks again, -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
