[OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-03.txt

[i***@ietf.org]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

Title : A Method for Signing HTTP Requests for OAuth
Authors : Justin Richer
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-signed-http-request-03.txt
Pages : 13
Date : 2016-08-08

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Nat Sakimura]

Hi Justin, John, and Hannes

Is there an appetite to change the draft in such a way as:

- do not wrap access token itself. It could include at_hash though.
Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodate nonce like string.

Essentially, what I want to do is not the http signing but just the pop
based
client authentication, which is very simple.
While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.

My write up is here: http://bit.ly/oauth-jpop

Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)

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: Tuesday, August 9, 2016 1:34 AM

draft-ietf-oauth-signed-http-request-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : A Method for Signing HTTP Requests for OAuth
Authors : Justin Richer
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-signed-http-request-03.txt
Pages : 13
Date : 2016-08-08
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Denis]

Hi Nat,

I see that you are now back to the list.

Please take note that "draft-ietf-oauth-signed-http-request-03.txt" has
expired on February 9, 2017 .

You said: "perhaps change ts to string to accommodate nonce like string"

In this draft, ts is defined as:

ts RECOMMENDED. The timestamp. This integer provides replay
protection of the signed JSON object. Its value MUST be a number
containing an integer value representing number of whole integer
seconds from midnight, January 1, 1970 GMT.

Section 7 is silent about replay protection and this is the single
instance where "ts" is mentioned in the document.

Hence it is rather hazy to understand how to deal with this value which
is misnamed since it should rather be called:
"iat" which means "Issued At".

A "nonce" is a concept which does not exist in OAuth 2.0 documents (but
which does exist in Open ID Connect documents).

The core of the discussion is to explain how to achieve *replay
protection of the signed JSON object*.

I sent an email on Fri, 17 Feb 2017 21:51:18 +0100 with the following
title :
Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwsreq-11.txt>
(The OAuth 2.0 Authorization Framework: JWT Secured Authorization
Request (JAR)) to Proposed Standard
and _I got no response_.

Please take a look at*ITEM 1* in the email from Friday, 17 February 2017
which addresses replay protection of the signed JSON object
and proposes a solution for OAuth 2.0 (which could be used as well by
Open ID Connect).

I take the opportunity of this email to comment on the individual draft
you posted at: http://bit.ly/oauth-jpop
and which is called: draft-sakimura-oauth-jpop-00

The Abstract states:

Only the party *in possession of* a corresponding cryptographic key
with the Jpop token can use it to get access
to the associated resources unlike in the case of the bearer token
described in [RFC6750]
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/Nat/oauth-rjwtprof/raw/tip/draft-sakimura-oauth-jpop.xml#RFC6750>
where any party in
possession of the access token can access the resource.

The text should rather be changed into:

Only the party *able to use* a corresponding cryptographic key with
the Jpop token can use it to get access
to the associated resources

You know that in case of a collusion between clients, this method will
be ineffective.

Simply stating in the Security Considerations section "The client's
secret key must be kept securely. " is insufficient.

Also the text is speaking of a nonce which is not a value that has been
registered by IANA.

Denis

Post by Nat Sakimura
Hi Justin, John, and Hannes
- do not wrap access token itself. It could include at_hash though.
Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodate nonce like string.
Essentially, what I want to do is not the http signing but just the pop
based client authentication, which is very simple.
While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.
My write up is here: http://bit.ly/oauth-jpop
Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)
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: Tuesday, August 9, 2016 1:34 AM

draft-ietf-oauth-signed-http-request-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : A Method for Signing HTTP Requests for OAuth
Authors : Justin Richer
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-signed-http-request-03.txt
Pages : 13
Date : 2016-08-08
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

Thanks Denis,

Yes. As currently specified, ts is an integer. My previous mail requested
it to be string instead so that I can used it as a nonce generated in the
style of H(timestamp|client_id|key) etc. I agree this is the place to
discuss replay protection etc. (Not in JAR, which is just a container
format.)

And, I have not yet posted oauth-jpop as an I-D :-) It is still in my repo
only and it has got more things to be done before it can be posted.
Hopefully, I can add more text and post it by Friday this week to make the
deadline for the next IETF.

Best,

Nat

Post by Denis
Hi Nat,
I see that you are now back to the list.
Please take note that "draft-ietf-oauth-signed-http-request-03.txt" has
expired on February 9, 2017 .
You said: "perhaps change ts to string to accommodate nonce like string"
ts RECOMMENDED. The timestamp. This integer provides replay
protection of the signed JSON object. Its value MUST be a number
containing an integer value representing number of whole integer
seconds from midnight, January 1, 1970 GMT.
Section 7 is silent about replay protection and this is the single
instance where "ts" is mentioned in the document.
Hence it is rather hazy to understand how to deal with this value which is
"iat" which means "Issued At".
A "nonce" is a concept which does not exist in OAuth 2.0 documents (but
which does exist in Open ID Connect documents).
The core of the discussion is to explain how to achieve *replay
protection of the signed JSON object*.
I sent an email on Fri, 17 Feb 2017 21:51:18 +0100 with the following
Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-jwsreq-11.txt>
(The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR)) to Proposed Standard
and *I got no response*.
Please take a look at* ITEM 1* in the email from Friday, 17 February 2017
which addresses replay protection of the signed JSON object
and proposes a solution for OAuth 2.0 (which could be used as well by Open
ID Connect).
I take the opportunity of this email to comment on the individual draft
you posted at: http://bit.ly/oauth-jpop
and which is called: draft-sakimura-oauth-jpop-00
Only the party *in possession of* a corresponding cryptographic key with
the Jpop token can use it to get access
to the associated resources unlike in the case of the bearer token
described in [RFC6750]
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/Nat/oauth-rjwtprof/raw/tip/draft-sakimura-oauth-jpop.xml#RFC6750>
where any party in
possession of the access token can access the resource.
Only the party *able to use* a corresponding cryptographic key with the
Jpop token can use it to get access
to the associated resources
You know that in case of a collusion between clients, this method will be
ineffective.
Simply stating in the Security Considerations section "The client's secret
key must be kept securely. " is insufficient.
Also the text is speaking of a nonce which is not a value that has been
registered by IANA.
Denis
Hi Justin, John, and Hannes
- do not wrap access token itself. It could include at_hash though.
Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodate nonce like string.
Essentially, what I want to do is not the http signing but just the pop
based client authentication, which is very simple.
While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.
My write up is here: http://bit.ly/oauth-jpop
Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)
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: Tuesday, August 9, 2016 1:34 AM
draft-ietf-oauth-signed-http-request-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : A Method for Signing HTTP Requests for OAuth
Authors : Justin Richer
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-signed-http-request-03.txt
Pages : 13
Date : 2016-08-08
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.
The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
There's also a htmlized version available at:https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03
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.
Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

What you describe as your minimum case is what I intended to be the
minimum case for this document. I opted to put the token inside the
payload instead of a hash because then we wouldn't need an additional
header to carry the token, and the client wouldn't be required to do an
additional crypto operation outside of the JOSE process.

-- Justin

Post by Nat Sakimura
Hi Justin, John, and Hannes
- do not wrap access token itself. It could include at_hash though.
Rationale: Pop access token can be pretty large and I do not want to
double base64url encode.
- perhaps change ts to string to accommodate nonce like string.
Essentially, what I want to do is not the http signing but just the pop
based
client authentication, which is very simple.
While I was writing it up, it occurred that if the above modification were
done, your draft will be a superset of what I wanted to do.
My write up is here: http://bit.ly/oauth-jpop
Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)
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: Tuesday, August 9, 2016 1:34 AM

draft-ietf-oauth-signed-http-request-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : A Method for Signing HTTP Requests for OAuth
Authors : Justin Richer
John Bradley
Hannes Tschofenig
Filename : draft-ietf-oauth-signed-http-request-03.txt
Pages : 13
Date : 2016-08-08
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-03
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth