On Mon, Nov 5, 2018 at 12:39 AM Mike Jones <michael.jo...@microsoft.com> wrote:
> 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. > Is there a reason this isn't a MUST? 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. > This doesn't seem to have made it in. -Ekr > 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
