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

[Eric Rescorla <[e-mail]>]

CCing the WG because I was wrong about the aliases.

---------- Forwarded message ---------
From: Eric Rescorla <[e-mail]>
Date: Sun, Aug 26, 2018 at 2:02 PM
Subject: AD Review of draft-ietf-oauth-jwt-bcp
To: oauth <[e-mail]>


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.


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?


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?


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.


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.


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.)?


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.