Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528571B2C4E for ; Thu, 19 Nov 2015 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AHiGtXgSj-Y for ; Thu, 19 Nov 2015 08:39:40 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130491B2C3D for ; Thu, 19 Nov 2015 08:39:40 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 19 Nov 2015 17:39:37 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Thu, 19 Nov 2015 17:39:38 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= To: Phil Hunt Thread-Topic: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 Thread-Index: AQHRIqsWCr6RmlnVq02omaMFbp3lkZ6jdZCAgAAW25Q= Date: Thu, 19 Nov 2015 16:39:37 +0000 Message-ID: References: <4197256B-0C12-46AA-B2F2-C9849F44BB3A@nexusgroup.com>, <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> In-Reply-To: <89483136-58E9-49C6-AE8B-E2A58E14F3B3@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:39:44 -0000 --_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just a note then. I did not see anything that prohibited the usage of pop t= okens for IoT so shipping it as is works. Sent from my iPhone On 19 Nov 2015, at 17:18, Phil Hunt > wrote: On the subject of making the spec(s) less JWT specific, it was a foundation= al assumption and (I think) in the charter. However COSE wasn't around yet. I suppose the more generic architecture doc could be altered to cover IoT c= ases, but it may be problematic for the other specs that are more specific. Another issue is I assume the COSE based tokens will have a different type = (eg cpop) to differentiate between jwt and COSE web tokens (what are we cal= ling them now?). As this generalization change could be seen as substantial, I would like to= have the chairs and AD comment. Is this a good idea? Or is COSE better to= write their own parallel arch draft? I'm happy to bend to the will of the group(s) on this. Phil On Nov 19, 2015, at 01:17, Erik Wahlstr=F6m neXus > wrote: Hi, I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we ha= ve a draft that uses PoP tokens for IoT and the architectures defined here = so my review was done with that IoT perspective. I=92m a bit late with the = review and some of the comments might already be mentioned by others. =97=97=97=97=97=97 3.1. Preventing Access Token Re-Use by the Resource Server If a symmetric key is used it=92s possible to re-use the key for a resource= server. The section talks about the importance of scopes, but I feel it sh= ould also mention the importance for the resource server to verify the audi= ence (=93aud=94) claim in the token to disable missuse. =97=97=97=97=97=97 The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-auth= z-00) relies heavily on this work. The main reason for this is the way PoP = tokens can establish key material, with the help of the authorization serve= r, on both the client and resource server. PoP tokens is also a very good f= it for constrained IoT devices that can be offline and it=92s also possible= to use hardware key storages to handle asymmetric pop keys. There could be a place for a new "Use Case" under section 3 that talks abou= t scenarios where PoP keys are a really good match for offline IoT devices.= I could help out ironing out a text for that with the help of the docs aut= hors if that=92s of interest. =97=97=97 s/a bogus tokens/a bogus token =97=97 In the document only references are made to JSON, JWT and JOSE. More exactl= y in the following two sections: A number of the threats listed in Section 4 demand protection of the access token content and a standardized solution, in form of a JSON- based format, is available with the JWT [RFC7519]. With the JSON Web Token (JWT) [RFC7519] a standardized format for access tokens is available. The necessary elements to bind symmetric or asymmetric keys to a JWT are described in [I-D.ietf-oauth-proof-of-possession]. Constrained IoT devices uses other access token and messages formats (accor= ding to our draft). It does not only use signed/encrypted JWT=92s but also = COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstr= oem-oauth-cbor-web-token-00.txt I totally agree that JWT is the correct examples to have in this document d= ue to the fact that they are RFC=92s, they are well known and should be use= d in as many places as possible, but it would be good to open up for other = types of message formats. For example like this: A number of the threats listed in Section 4 demand protection of the access token content and a standardized solution in form of, for example= , a JSON- based format, is available with the JWT [RFC7519]. =97=97 For that purpose the client will have to authenticate the resource server before transmitting the access token. I=92m missing a description about how this is handled in an end-to-end secu= rity scenario. =97=97=97 The resource server queries the authorization server for the symmetric key. This is an approach envisioned by the token introspection endpoint [I-D.ietf-oauth-introspection]. Not a question for this draft maybe, but in what draft is the introspection= response claim defined? It=92s not defined in https://tools.ietf.org/html/= rfc7662#section-2.2 and I don=92t know in what other draft it can be define= d. =97=97 In ACE WG the draft seitz-ace-oauth-authz have a profile for an access requ= est to make it work over CoAP. CoAP is the HTTP equivalent for constrained = devices, and it has limitations, for example it can=92t send large tokens i= n options (headers in "http-speak"). This means that the draft defines a wa= y to first send the PoP token to an new endpoint on the resource server to = establish a security context. Then the real request against the resource se= rver can be done once the security context is established. See more details= here https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00#section-5.= 2. An open question; should a flow like that be added to the architecture sect= ion? That means a new section 7.5. =97=97 Thanks for writing this. I think it=92s very important work. / Erik _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just a note then. I did not see anything that prohibited the usage of = pop tokens for IoT so  shipping it as is works.

Sent from my iPhone

On 19 Nov 2015, at 17:18, Phil Hunt <phil.hunt@oracle.com> wrote:

On the subject of making the spec(s) less JWT specific, it was a found= ational assumption and (I think) in the charter. However COSE wasn't around= yet. 

I suppose the more generic architecture doc = could be altered to cover IoT cases, but it may be problematic for the othe= r specs that are more specific. 

Another issue is I assume the COSE based tok= ens will have a different type (eg cpop) to differentiate between jwt and C= OSE web tokens (what are we calling them now?). 

As this generalization change could be seen = as substantial, I would like to have the chairs and AD comment. Is this a g= ood idea?  Or is COSE better to write their own parallel arch draft?

I'm happy to bend to the will of the group(s= ) on this. 

Phil

On Nov 19, 2015, at 01:17, Erik Wahlstr=F6m neXus <erik.wahlstrom@nexusgroup.com> wrote:
Hi, 

I have been reviewing draft-ietf-oauth-pop-architectur= e-05. In ACE WG we have a draft that uses PoP tokens for IoT and the archit= ectures defined here so my review was done with that IoT perspective. I=92m= a bit late with the review and some of the comments might already be mentioned by others.

 

=97=97=97=97=97=97

3.1. Preventing Access Token Re-Use by the Resource Server

If a symmetric key is used it=92s possible to re-use the ke= y for a resource server. The section talks about the importance of scopes, = but I feel it should also mention the importance for the resource server to= verify the audience (=93aud=94) claim in the token to disable missuse.

=97=97=97=97=97=97

The draft in ACE WG (https://tools.ietf.org/html/dra= ft-seitz-ace-oauth-authz-00) relies heavily on this work. The main reas= on for this is the way PoP tokens can establish key material, with the help of the authorization server, on both= the client and resource server. PoP tokens is also a very good fit for con= strained IoT devices that can be offline and it=92s also possible to use ha= rdware key storages to handle asymmetric pop keys.

There could be a place for a new "Use Case" under= section 3 that talks about scenarios where PoP keys are a really good matc= h for offline IoT devices. I could help out ironing out a text for that wit= h the help of the docs authors if that=92s of interest. 

=97=97=97

s/a bogus tokens/a bogus token

=97=97

In the document only references are made to JSON, JWT and J= OSE. More exactly in the following two sections:

   A number of the t=
hreats listed in Section 4 demand protection of =
the
   access token content and a standardized solution, in form of a JSON-
   based format, is available with the JWT [RFC7=
519].



   With the JSON Web=
 Token (JWT) [RFC7519] a standardized format=
 for
   access tokens is available.  The necessary elements to bind symmetric
   or asymmetric keys to a JWT are described in
   [I-D.ietf-oauth-proo=
f-of-possession].

Constrained IoT devices uses other access token and message= s formats (according to our draft). It does not only use signed/encrypted J= WT=92s but also COSE protected CBOR Web Tokens. See https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt=

I totally agree that JWT is the correct examples to have in= this document due to the fact that they are RFC=92s, they are well known a= nd should be used in as many places as possible, but it would be good to op= en up for other types of message formats. For example like this:


   A number of the t=
hreats listed in Section 4 demand protection of =
the
   access token content and a standardized solution in form of, for example, a JSON-
   based format, is available with the JWT [RFC7=
519].


=97=97

 For that
   purpose the client will have to authenticate the resource server
   before transmitting the access token.


I=92m missing a description about how this is handled in an= end-to-end security scenario.

=97=97=97

      The resource s=
erver queries the authorization server for the
      symmetric key.  This is an approach envisioned by the token
      introspection endpoint [I-D.ietf-oauth-introspection].


Not a question for this draft maybe, but in what draft is t= he introspection response claim defined? It=92s not defined in https://too= ls.ietf.org/html/rfc7662#section-2.2 and I don=92t know in what other draft it can be defined.

=97=97

In ACE WG the draft seitz-ace-oauth-authz have a profile fo= r an access request to make it work over CoAP. CoAP is the HTTP equivalent = for constrained devices, and it has limitations, for example it can=92t sen= d large tokens in options (headers in "http-speak"). This means that the draft defines a way to first = send the PoP token to an new endpoint on the resource server to establish a= security context. Then the real request against the resource server can be= done once the security context is established. See more details here https://tools.ietf.org/html/= draft-seitz-ace-oauth-authz-00#section-5.2.

An open question; should a flow like that be added to the a= rchitecture section? That means a new section 7.5.

=97=97

Thanks for writing this. I think it=92s very important work= .

/ Erik


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_BE468D61B1164EB58ECBED3A21D846FBnexusgroupcom_--