Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp

[Mike Jones <[e-mail]>]

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 <[e-mail]> On Behalf Of Eric Rescorla
Sent: Monday, August 27, 2018 4:03 AM
To: oauth <[e-mail]>
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