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

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

> 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:oauth-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Tuesday, August 9, 2016 1:34 AM
>> To: i-d-announce@ietf.org
>> Cc: oauth@ietf.org
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth