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

From: "Nat Sakimura" <[email-masked]>
Date: Tue, 7 Mar 2017 16:13:02 +0900

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-----
> From: OAuth [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, August 9, 2016 1:34 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OAUTH-WG] I-D Action:
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
> 
> 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/
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Denis <[email-masked]>
Date: Tue, 7 Mar 2017 11:58:58 +0100

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

> based client authentication, which is very simple.
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 07 Mar 2017 12:25:40 +0000

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

On Tue, Mar 7, 2017 at 7:59 PM Denis <[email-masked]> wrote:

> Hence it is rather hazy to understand how to deal with this value which is
> misnamed since it should rather be called:
> (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
> and proposes a solution for OAuth 2.0 (which could be used as well by Open
> ID Connect).
>
> Only the party *in possession of* a corresponding cryptographic key with
> Only the party *able to use* a corresponding cryptographic key with the
> Jpop token can use it to get access
> 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.
>
> From: OAuth [mailto:[email-masked] <[email-masked]>] On Behalf [email-masked]
> 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
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Mar 2017 10:30:51 -0500

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