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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]> wrote:

> 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:[e-mail] <[e-mail]>] On Behalf [e-mail]
> Sent: Tuesday, August 9, 2016 1:34 AM
> To: [e-mail]
> Cc: [e-mail]
> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation