Thanks for your review, Radia. I've added the working group to the thread so
that they're aware of your comments.
From: Radia Perlman [mailto:radiaperl...@gmail.com]
Sent: Monday, September 29, 2014 4:46 PM
To: sec...@ietf.org; The IESG; draft-ietf-oauth-jwt-bearer@tools.ietf.org
Subject: Secdir Review of draft-ietf-oauth-jwt-bearer-10
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document is one of a set of documents specifying how to use JSON
formatted OAuth bearer tokens in the context of HTTP requests.
It specifies two contexts in which these JSON tokens can be used: as
Authorization Grants or for Client Authentication. It specifies the
to-be-IANA-registered parameters used to specify that the type of token
presented is a JSON token (within the HTTP header). It also specifies the
checks to be done to validate that the JSON token is valid (though I would
expect this information would also be specified in the JSON token
specification itself).
You're right that some of the validation rules are in
draft-ietf-oauth-json-web-token, which defines the basic JWT token format,
however this specification adds some additional validation rules because it
requires that some fields be present that are optional in the JWT spec, and it
specifies that they be used in a particular way.
There are security considerations and privacy considerations sections, but
they are very light. That is because it refers to
draft-ietf-oauth-assertions-17, which has a more complete security
considerations section. I guess it's appropriate to have more detailed
security considerations there, since all this specification adds is some
labels.
Yes, this was the intent. Most of the security considerations are independent
of the token type.
Would it make sense to merge this document with the other specs, rather than
having this be so redundant with the others?
No, because while there's semantic commonality, the syntax of the SAML profile
and the JWT profile are different. Merging them would make it much harder to
read because it would be full of conditionals depending upon which token format
was being described.
Some details:
On page 3 para 2, it says “The format and processing rules for the JWT
defined in this specification are intentionally similar, though not
identical, to those in the closely related SAML 2.0 Profile for OAuth.” It
would be good if they specified what the differences are, and why they
couldn't be identical.
That's a fair point. I'll look into this with the other editors and the
working group. The following comments in the JWT profile spec record SAML
features used for which no equivalent JWT feature exists. This might be good
material to put into an appendix.
!-- No equivalent to SubjectConfirmation Method
urn:oasis:names:tc:SAML:2.0:cm:bearer at present --
!-- No equivalent to SubjectConfirmationData Recipient at present --
!-- No equivalent to SubjectConfirmationData Address at present --
!-- No equivalent to AuthnStatement at present --
Some background guidance on when you would want to use a token for client
authentication vs. when you would want to use one for an authorization grant
would be useful. In practice, the distinction between the two is subtle. It
is common for a token to contain the caller’s identity as well as group
memberships and perhaps roles. I suspect the reality is that the client has
to figure out which protocol slot the server wants to get the token in and
provide it there, where service designers make the decision more or less
arbitrarily.
This guidance really belongs in the generic assertions specification
draft-ietf-oauth-assertions. I'll plan on reviewing that spec with the other
editors and the working group to see whether the guidance provided there needs
to be improved.
Page 6 item 4: “The authorization server MAY reject JWTs with an “expiration”
claim that is unreasonably far in the future.” This is saying that the
validator of the token might choose to reject tokens that are long lived.
It’s not clear what the user of this spec can do with this information. It
calls for some out-of-band communication between the token issuer and the
token validator on what is an acceptable expiration period. Unless the
protocol has some way of reporting this back so that the caller can get a
shorter-lived token, it seems like a fragile design.
What you write is true, but it' also a consequence of the fact that
applications are free to impose additional requirements on the usage of this
specification, provided their usage is still conforming. I believe that the
text above should
