Hannes Tschofenig
2016-06-29 13:57:37 UTC
Hi Nat, Hi John,
thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the
document ready for the IESG and have therefore reviewed it.
Despite some minor issues I believe the document is in good shape.
Here are my comments:
** Introduction
The example request in the introduction is longer than 72 characters.
s/textaual nature/textual nature
s/The request may be encrypted so that end-to-end confidentiality
may be obtained even if in the case TLS connection is terminated
at a gateway or a similar device.
/The request may be encrypted so that end-to-end confidentiality
can be provided even if the TLS connection is terminated
at a gateway.
FROM:
1. The request can be signed so that an integrity check can be
implemented. If a suitable algorithm is used for the signing,
then it will provide verification of the client making the
request.
TO:
1. The request may be signed so that the signer can be authenticated
and the integrity of the request can be checked.
There are a few cases that request by reference are useful such as:
FROM:
1. When it is desirable to reduced the size of transmitted request.
Since we are using application layer security, it may
substantially increase the size of the request particulary in the
case of using public key cryptography.
TO:
1. When it is desirable to reduce the size of transmitted request.
The use of application layer security increases the size of the request,
particularly when public key cryptography is used.
You write:
2. Static signature: The client can make a signed Request Object and
put it at a place that the Authorization Server can access. This
may just be done by a client utility or other process, so that
the private key does not have to reside on the client,
simplifying programming. Downside of it is that the signed
portion just become a token.
The downside is that there is that there is no indication of freshness
and I believe this is what you mean by "just became a token". I am not
sure that the term 'static signature' is the right term here. Just
delete the 'Static Signature:'.
Is the JWT a good match to encode the parameters of the request? Why
don't you just use a regular JSON object and apply the JOSE security
mechanisms to it.
Section 3: Request Object
You write:
"
To encrypt, JWE [RFC7516] is used. Note that JWE is always integrity
protected, so if only integrity protection is desired, JWS signature
is not needed.
"
I think the last sentence should say: "... if only integrity protection
is desired then JWE is not needed."
You write:
"
It can also be signed then encrypted. This is sometimes desired to
reduced the repudiation risk from the point of view of the receiver.
In this case, it MUST be signed then encrypted, with the result being
a Nested JWT, as defined in JWT [RFC7519].
"client_secret
What do you mean by "reduced the repudiation risk"?
It may help if you reference the example in Appendix A.2 of RFC 7519
regarding a nest JWT.
You write:
"
REQUIRED OAuth 2.0 Authorization Request parameters that are not
included in the Request Object MUST be sent as query parameters. If
a required parameter is missing from both the query parameters and
the Request Object, the request is malformed.
"
s/REQUIRED/Required
That's a bit unfortunate that you have to send parameters twice -- once
as query parameters and then again in the request object.
Is there no better way to design this?
Section 4: Authorization Request
You write:
"
The authorization request object MAY be signed AND/OR encrypted.
"
Why is this sentence needed when you have extensively spoken about this
topic already in earlier chapters?
If you include it then write "The authorization request object MAY be
signed and/or encrypted."
For the entire document I believe it is worthwhile to state in the
terminology section that your usage of the term "signed" means digitally
signing with asymmetric crypto system as well as using a MAC (which is a
symmetric key primitive).
You write:
"
Servers MAY cache the contents of the resources referenced by Request
URIs. If the contents of the referenced resource could ever change,
the URI SHOULD include the base64url encoded SHA-256 hash as defined
in FIPS180-2 [FIPS180-2] of the referenced resource contents as the
fragment component of the URI. If the fragment value used for a URI
changes, that signals the server that any cached value for that URI
with the old fragment value is no longer valid.
"
I am not sure what this means. Can you provide an example?
You list a couple of restrictions of the request URI below"
"
The entire Request URI MUST NOT exceed 512 ASCII characters. There
are three reasons for this restriction.
1. Many WAP / feature phones do not accept large payloads. The
restriction are typically either 512 or 1024 ASCII characters.
2. The maximum URL length supported by older versions of Internet
Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and using such is not advisable
from the user experience point of view.
"
I wonder how relevant they are (given that the size of the URI is
substantially increased due to the use of JWT & the JOSE work).
For example, are there still many WAP phones around that want to use
this mechanism? Are old versions of the Internet Explorer still an issue?
Is a request by value even an option for a 2g mobile phone?
Section 5. Validating JWT-Based Requests
You write: "The Authorization Server MUST return an error if decryption
fails." and "The Authorization Server MUST return an error if signature
validation fails." Could you be a bit more precise about the error
message that is returned? From Section 6 I don't see what the right
error response would be.
Section 8. Security Considerations:
FROM:
In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the following security considerations SHOULD be taken
into account.
TO:
In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the following security considerations should be taken
into account.
You write:
"
When sending the authorization request object through "request"
parameter, it SHOULD be signed with then considered appropriate
algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such
a case.
"
The use cases presented in the document talk about end-to-end security
and signed / encrypted requests.
Now, in the security consideration section it almost appears if there is
the possibility that the request object would not experience any
security protection at all.
That does not appear right. It does not make sense to just send the
parameters in a different encoding only, or does it? I would only see a
disadvantage doing that, namely the much larger size.
You write:
"
If the request object contains personally identifiable or sensitive
information, the "request_uri" MUST be of one-time use and MUST have
large enough entropy deemed necessary with applicable security
policy. For higher security requirement, using [RFC7516] is
client_secretstrongly
recommended.
"
Why is this so? Today, we send the same request in OAuth over TLS.
Why is there only a problem with the request_uri and not with sending
the request object?
I believe the biggest issue that should be discussed in the security
consideration section is the possibility that the request object may not
be fresh. This introduces the possibility for replay attacks and lowers
the quality of the end-to-end security protection.
It may also be good to motivate the application layer security
mechanisms a bit more. For example, what information is in the request
itself that requires encryption?
When I looked at the example I noticed the client_id and the absence of
the client_secret. I wonder how the mechanism intersects with the
client_id and the client_secret. If a client has, for example, a public
/ private key pair configured then the use of JWS (with those
credentials) would provide much better security than a client_id and a
client_secret.
** Section 11: References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Could you reference the TLS BCP instead?
https://tools.ietf.org/html/rfc7525
[FIPS180-2]
U.S. Department of Commerce and National Institute of
Standards and Technology, "Secure Hash Signature
Standard", FIPS 180-2, August 2002.
Defines Secure Hash Algorithm 256 (SHA256)
Could you reference RFC 6234 instead?
https://tools.ietf.org/html/rfc6234
Ciao
Hannes
thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the
document ready for the IESG and have therefore reviewed it.
Despite some minor issues I believe the document is in good shape.
Here are my comments:
** Introduction
The example request in the introduction is longer than 72 characters.
s/textaual nature/textual nature
s/The request may be encrypted so that end-to-end confidentiality
may be obtained even if in the case TLS connection is terminated
at a gateway or a similar device.
/The request may be encrypted so that end-to-end confidentiality
can be provided even if the TLS connection is terminated
at a gateway.
FROM:
1. The request can be signed so that an integrity check can be
implemented. If a suitable algorithm is used for the signing,
then it will provide verification of the client making the
request.
TO:
1. The request may be signed so that the signer can be authenticated
and the integrity of the request can be checked.
There are a few cases that request by reference are useful such as:
FROM:
1. When it is desirable to reduced the size of transmitted request.
Since we are using application layer security, it may
substantially increase the size of the request particulary in the
case of using public key cryptography.
TO:
1. When it is desirable to reduce the size of transmitted request.
The use of application layer security increases the size of the request,
particularly when public key cryptography is used.
You write:
2. Static signature: The client can make a signed Request Object and
put it at a place that the Authorization Server can access. This
may just be done by a client utility or other process, so that
the private key does not have to reside on the client,
simplifying programming. Downside of it is that the signed
portion just become a token.
The downside is that there is that there is no indication of freshness
and I believe this is what you mean by "just became a token". I am not
sure that the term 'static signature' is the right term here. Just
delete the 'Static Signature:'.
Is the JWT a good match to encode the parameters of the request? Why
don't you just use a regular JSON object and apply the JOSE security
mechanisms to it.
Section 3: Request Object
You write:
"
To encrypt, JWE [RFC7516] is used. Note that JWE is always integrity
protected, so if only integrity protection is desired, JWS signature
is not needed.
"
I think the last sentence should say: "... if only integrity protection
is desired then JWE is not needed."
You write:
"
It can also be signed then encrypted. This is sometimes desired to
reduced the repudiation risk from the point of view of the receiver.
In this case, it MUST be signed then encrypted, with the result being
a Nested JWT, as defined in JWT [RFC7519].
"client_secret
What do you mean by "reduced the repudiation risk"?
It may help if you reference the example in Appendix A.2 of RFC 7519
regarding a nest JWT.
You write:
"
REQUIRED OAuth 2.0 Authorization Request parameters that are not
included in the Request Object MUST be sent as query parameters. If
a required parameter is missing from both the query parameters and
the Request Object, the request is malformed.
"
s/REQUIRED/Required
That's a bit unfortunate that you have to send parameters twice -- once
as query parameters and then again in the request object.
Is there no better way to design this?
Section 4: Authorization Request
You write:
"
The authorization request object MAY be signed AND/OR encrypted.
"
Why is this sentence needed when you have extensively spoken about this
topic already in earlier chapters?
If you include it then write "The authorization request object MAY be
signed and/or encrypted."
For the entire document I believe it is worthwhile to state in the
terminology section that your usage of the term "signed" means digitally
signing with asymmetric crypto system as well as using a MAC (which is a
symmetric key primitive).
You write:
"
Servers MAY cache the contents of the resources referenced by Request
URIs. If the contents of the referenced resource could ever change,
the URI SHOULD include the base64url encoded SHA-256 hash as defined
in FIPS180-2 [FIPS180-2] of the referenced resource contents as the
fragment component of the URI. If the fragment value used for a URI
changes, that signals the server that any cached value for that URI
with the old fragment value is no longer valid.
"
I am not sure what this means. Can you provide an example?
You list a couple of restrictions of the request URI below"
"
The entire Request URI MUST NOT exceed 512 ASCII characters. There
are three reasons for this restriction.
1. Many WAP / feature phones do not accept large payloads. The
restriction are typically either 512 or 1024 ASCII characters.
2. The maximum URL length supported by older versions of Internet
Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and using such is not advisable
from the user experience point of view.
"
I wonder how relevant they are (given that the size of the URI is
substantially increased due to the use of JWT & the JOSE work).
For example, are there still many WAP phones around that want to use
this mechanism? Are old versions of the Internet Explorer still an issue?
Is a request by value even an option for a 2g mobile phone?
Section 5. Validating JWT-Based Requests
You write: "The Authorization Server MUST return an error if decryption
fails." and "The Authorization Server MUST return an error if signature
validation fails." Could you be a bit more precise about the error
message that is returned? From Section 6 I don't see what the right
error response would be.
Section 8. Security Considerations:
FROM:
In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the following security considerations SHOULD be taken
into account.
TO:
In addition to the all the security considerations discussed in OAuth
2.0 [RFC6819], the following security considerations should be taken
into account.
You write:
"
When sending the authorization request object through "request"
parameter, it SHOULD be signed with then considered appropriate
algorithm using [RFC7515]. The "alg=none" SHOULD NOT be used in such
a case.
"
The use cases presented in the document talk about end-to-end security
and signed / encrypted requests.
Now, in the security consideration section it almost appears if there is
the possibility that the request object would not experience any
security protection at all.
That does not appear right. It does not make sense to just send the
parameters in a different encoding only, or does it? I would only see a
disadvantage doing that, namely the much larger size.
You write:
"
If the request object contains personally identifiable or sensitive
information, the "request_uri" MUST be of one-time use and MUST have
large enough entropy deemed necessary with applicable security
policy. For higher security requirement, using [RFC7516] is
client_secretstrongly
recommended.
"
Why is this so? Today, we send the same request in OAuth over TLS.
Why is there only a problem with the request_uri and not with sending
the request object?
I believe the biggest issue that should be discussed in the security
consideration section is the possibility that the request object may not
be fresh. This introduces the possibility for replay attacks and lowers
the quality of the end-to-end security protection.
It may also be good to motivate the application layer security
mechanisms a bit more. For example, what information is in the request
itself that requires encryption?
When I looked at the example I noticed the client_id and the absence of
the client_secret. I wonder how the mechanism intersects with the
client_id and the client_secret. If a client has, for example, a public
/ private key pair configured then the use of JWS (with those
credentials) would provide much better security than a client_id and a
client_secret.
** Section 11: References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Could you reference the TLS BCP instead?
https://tools.ietf.org/html/rfc7525
[FIPS180-2]
U.S. Department of Commerce and National Institute of
Standards and Technology, "Secure Hash Signature
Standard", FIPS 180-2, August 2002.
Defines Secure Hash Algorithm 256 (SHA256)
Could you reference RFC 6234 instead?
https://tools.ietf.org/html/rfc6234
Ciao
Hannes