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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 5, 2018 at 12:39 AM Mike Jones <[e-mail]>
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 <[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.
>

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



>