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 <[email protected]> On Behalf Of Eric Rescorla
Sent: Saturday, December 22, 2018 6:42 AM
To: oauth <[email protected]>
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 <[email protected]<mailto:[email protected]>>
Date: Sun, Aug 26, 2018 at 2:02 PM
Subject: AD Review of draft-ietf-oauth-jwt-bcp
To: oauth <[email protected]<mailto:[email protected]>>
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.”
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
