Nat Sakimura
2017-01-30 10:13:58 UTC
Hi OAuthers:
I have finally pushed -10 and -11 which hopefully resolved all the comments provided by Jan 17.
Changes are as follows.
#20: KM1 -- some wording that is awkward in the TLS section.
Accepted the suggested edit.
#21: KM2 - the additional attacks against OAuth 2.0 should also have a pointer
Accepted.
Added the references to the security considerations in RFC7515, 7516, 7518.
#22: KM3 -- Nit: in first line of 10.4:
Accepted.
s/researchs/research/
#23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100
Accepted in principle.
Added a paragraph on RFC6973.
#24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt
Accepted in principle. Modified as follows:
- JWS signature should also be applied.
- In this case, it MUST be signed then encrypted,
- with the result being a Nested JWT, as defined in
- <xref target="RFC7519">JWT</xref>.
+ JWS signature SHOULD also be applied so that the source authentication
+ can be done.
+ When both signature and encryption are being applied,
+ the JWT MUST be signed then encrypted as advised in
+ the section 11.2 of <xref target="RFC7519" />.
+ The result is a Nested JWT, as defined in
+ <xref target="RFC7519" />.
- <t>The Authorization Request Object may be sent by value as
+ <t>The Authorization Request Object MAY be sent by value as
#36: DP - More precise qualification on Encryption needed.
Accepted in principle.
- <t>JWE encrypted; or </t>
+ <t>JWE encrypted (when symmetric keys are being used); or </t>
#25: SECDIR review: Section 6 -- authentication and integrity need not be provided if the requestor encrypts the token?
Superseded by #36
#26: SECDIR Review: Section 10 -- why no reference for JWS algorithms?
Accepted by modifying as:
- JWS signed with then considered appropriate algorithm
- or encrypted using <xref target="RFC7516"/>. </t>
+ signed using <xref target="RFC7515">JWS</xref>
+ or encrypted using <xref target="RFC7516">JWE</xref>
+ with then considered appropriate algorithm. </t>
#27: SECDIR Review: Section 10.2 - how to do the agreement between client and server "a priori"?
Accepted. Resolved by adding the following:
+ Note that the such agreement needs to be done in a
+ secure fashion. For example, the developers from the
+ server side and the client side can have a face to face
+ meeting to come to such an agreement.
#28: SECDIR Review: Section 10.3 - Indication on "large entropy" and "short lifetime" should be indicated
Accepted. Resolved by adding:
+ The adequate shortness of the validity and
+ the entropy of the Request Object URI depends
+ on the risk calculation based on the value
+ of the resource being protected. A general guidance
+ for the validity time would be less than a minute
+ and the Request Object URI is to include a cryptographic
+ random value of 128bit or more at the time of the
+ writing of this specification.
#29: SECDIR Review: Section 10.3 - Typo
Accepted.
- applies. In addition, the Authorization Server
+ apply. In addition, the Authorization Server
#30: SECDIR Review: Section 10.4 - typos and missing articles
Fixed several. According to grammarly.com, there is no errors left, but there may be more...
#31: SECDIR Review: Section 10.4 - Clearer statement on the lack of endpoint identifiers needed
Accepted. Resolved by modifying as:
- An extension specification should be created.
+ An extension specification should be created
+ as a preventive measure to address
+ potential vulnerabilities that has not yet been identified.
#32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative reference
Accepted.
#33: SECDIR Review: Section 11 - Better English & Entropy language needed
Accepted. Modified as:
- of one-time use and MUST have large enough entropy
+ used only once, have short validity period, and MUST have large enough entropy
+ The adequate shortness of the validity and
+ the entropy of the Request Object URI depends
+ on the risk calculation based on the value
+ of the resource being protected. A general guidance
+ for the validity time would be less than a minute
+ and the Request Object URI is to include a cryptographic
+ random value of 128bit or more at the time of the
+ writing of this specification.
#34: Section 4: Typo
Fixed the errors spotted by grammarly.com
#35: More Acknowledgement
Added Denis Pinkas, Kathleen Moriarty (as AD), and Steve Kent (as SECDIR).
Please let me know if there are other changes needed.
Best,
Nat Sakimura
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
I have finally pushed -10 and -11 which hopefully resolved all the comments provided by Jan 17.
Changes are as follows.
#20: KM1 -- some wording that is awkward in the TLS section.
Accepted the suggested edit.
#21: KM2 - the additional attacks against OAuth 2.0 should also have a pointer
Accepted.
Added the references to the security considerations in RFC7515, 7516, 7518.
#22: KM3 -- Nit: in first line of 10.4:
Accepted.
s/researchs/research/
#23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100
Accepted in principle.
Added a paragraph on RFC6973.
#24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt
Accepted in principle. Modified as follows:
- JWS signature should also be applied.
- In this case, it MUST be signed then encrypted,
- with the result being a Nested JWT, as defined in
- <xref target="RFC7519">JWT</xref>.
+ JWS signature SHOULD also be applied so that the source authentication
+ can be done.
+ When both signature and encryption are being applied,
+ the JWT MUST be signed then encrypted as advised in
+ the section 11.2 of <xref target="RFC7519" />.
+ The result is a Nested JWT, as defined in
+ <xref target="RFC7519" />.
- <t>The Authorization Request Object may be sent by value as
+ <t>The Authorization Request Object MAY be sent by value as
#36: DP - More precise qualification on Encryption needed.
Accepted in principle.
- <t>JWE encrypted; or </t>
+ <t>JWE encrypted (when symmetric keys are being used); or </t>
#25: SECDIR review: Section 6 -- authentication and integrity need not be provided if the requestor encrypts the token?
Superseded by #36
#26: SECDIR Review: Section 10 -- why no reference for JWS algorithms?
Accepted by modifying as:
- JWS signed with then considered appropriate algorithm
- or encrypted using <xref target="RFC7516"/>. </t>
+ signed using <xref target="RFC7515">JWS</xref>
+ or encrypted using <xref target="RFC7516">JWE</xref>
+ with then considered appropriate algorithm. </t>
#27: SECDIR Review: Section 10.2 - how to do the agreement between client and server "a priori"?
Accepted. Resolved by adding the following:
+ Note that the such agreement needs to be done in a
+ secure fashion. For example, the developers from the
+ server side and the client side can have a face to face
+ meeting to come to such an agreement.
#28: SECDIR Review: Section 10.3 - Indication on "large entropy" and "short lifetime" should be indicated
Accepted. Resolved by adding:
+ The adequate shortness of the validity and
+ the entropy of the Request Object URI depends
+ on the risk calculation based on the value
+ of the resource being protected. A general guidance
+ for the validity time would be less than a minute
+ and the Request Object URI is to include a cryptographic
+ random value of 128bit or more at the time of the
+ writing of this specification.
#29: SECDIR Review: Section 10.3 - Typo
Accepted.
- applies. In addition, the Authorization Server
+ apply. In addition, the Authorization Server
#30: SECDIR Review: Section 10.4 - typos and missing articles
Fixed several. According to grammarly.com, there is no errors left, but there may be more...
#31: SECDIR Review: Section 10.4 - Clearer statement on the lack of endpoint identifiers needed
Accepted. Resolved by modifying as:
- An extension specification should be created.
+ An extension specification should be created
+ as a preventive measure to address
+ potential vulnerabilities that has not yet been identified.
#32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative reference
Accepted.
#33: SECDIR Review: Section 11 - Better English & Entropy language needed
Accepted. Modified as:
- of one-time use and MUST have large enough entropy
+ used only once, have short validity period, and MUST have large enough entropy
+ The adequate shortness of the validity and
+ the entropy of the Request Object URI depends
+ on the risk calculation based on the value
+ of the resource being protected. A general guidance
+ for the validity time would be less than a minute
+ and the Request Object URI is to include a cryptographic
+ random value of 128bit or more at the time of the
+ writing of this specification.
#34: Section 4: Typo
Fixed the errors spotted by grammarly.com
#35: More Acknowledgement
Added Denis Pinkas, Kathleen Moriarty (as AD), and Steve Kent (as SECDIR).
Please let me know if there are other changes needed.
Best,
Nat Sakimura
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender and delete this e-mail.
-----Original Message-----
Sent: Monday, January 30, 2017 7:08 PM
Subject: New Version Notification for draft-ietf-oauth-jwsreq-11.txt
A new version of I-D, draft-ietf-oauth-jwsreq-11.txt has been successfully
submitted by Nat Sakimura and posted to the IETF repository.
Name: draft-ietf-oauth-jwsreq
Revision: 11
Title: The OAuth 2.0 Authorization Framework: JWT Secured
Authorization Request (JAR)
Document date: 2017-01-30
Group: oauth
Pages: 24
https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-11.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-11
The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.
This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be JWS
signed and/or JWE encrypted so that the integrity, source
authentication and confidentiality property of the Authorization
Request is attained. The request can be sent by value or by
reference.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
Sent: Monday, January 30, 2017 7:08 PM
Subject: New Version Notification for draft-ietf-oauth-jwsreq-11.txt
A new version of I-D, draft-ietf-oauth-jwsreq-11.txt has been successfully
submitted by Nat Sakimura and posted to the IETF repository.
Name: draft-ietf-oauth-jwsreq
Revision: 11
Title: The OAuth 2.0 Authorization Framework: JWT Secured
Authorization Request (JAR)
Document date: 2017-01-30
Group: oauth
Pages: 24
https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-11.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-11
The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put
forward.
This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be JWS
signed and/or JWE encrypted so that the integrity, source
authentication and confidentiality property of the Authorization
Request is attained. The request can be sent by value or by
reference.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat