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

[Mike Jones <[e-mail]>]

Hi Eric,

Replies are inline below, prefixed by “Mike>”.  In summary, unless you want to see additional text added giving examples of substitution attacks, I believe that -04 addressed all of your review comments.  Let us know, and if so, we’ll turn the crank and publish an -05 doing so.

                                                                Thanks again,
                                                                -- Mike

From: OAuth <[e-mail]> On Behalf Of Eric Rescorla
Sent: Saturday, December 22, 2018 6:42 AM
To: oauth <[e-mail]>
Subject: [OAUTH-WG] Fwd: AD Review of draft-ietf-oauth-jwt-bcp

CCing the WG because I was wrong about the aliases.
---------- Forwarded message ---------
From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date: Sun, Aug 26, 2018 at 2:02 PM
Subject: AD Review of draft-ietf-oauth-jwt-bcp
To: oauth <[e-mail]<mailto:[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.

Mike> This was done in https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-04.

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> In an OAuth context, an attacker can perform a substitution attack by obtaining a JWT access token for a resource that it legitimately has access to and presenting it to a different resource that it is not entitled to access.  If the audience is not present or not checked and/or the issuer is not validated, this kind of attack can succeed.

Mike> Similarly, in an OpenID Connect context if the implicit flow is being used, the attacker can obtain a legitimate ID Token (which is a JWT) when the Identity Provider redirects to its redirection URI, with the ID Token passed as a fragment value.  The attacker than then redirect to a different redirection URI for a different relying party that does not belong to the attacker.  This can succeed if the signature isn’t checked or if the issuer isn’t checked.

Mike> Does this now make sense as-is or do you want additional text to be added to the specification – for instance, maybe something based on the descriptions above?

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> Yes

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> Draft -04 added these statements in response to your comment:
“The "none" algorithm should only be used when the JWT is cryptographically protected by other means.”
“JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly requested to do by the caller.”.  (Reading this now, I see that we need to change “to do” to “to do so”.)

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> Draft -04 adds this statement:
“Likewise, if the "X25519" or "X448" {{RFC8037}} algorithms are used, then the security considerations in {{RFC8037}} apply.”

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> Draft -04 adds this text in response to this comment:
“In particular, passwords should only be used to perform key encryption, rather than content encryption, as described in Section 4.8 of {{RFC7518}}. Note that even when used for key encryption, password-based encryption is still subject to 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.

Mike> Draft -04 adds this text in response to this comment:
“For new JWT applications, the use of explicit typing is RECOMMENDED.”