Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05

From: Justin Richer <[email-masked]>
Date: Thu, 19 Nov 2015 12:18:41 -0600

I agree with added "For example" in a few places. It's not normative it's informational here. 

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Phil Hunt <[email-masked]> 
Date: 11/19/2015  11:28 AM  (GMT-06:00) 
To: Erik Wahlström neXus <[email-masked]> 
Cc: "<[email-masked]>" <[email-masked]>, Justin Richer <[email-masked]> 
Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05 

I think your point that maybe the architecture doc be generic enough to support both json and cbor tokens is worth consideration. 
I am just not sure of process and consensus now that we are past WGLC. Would the cose group prefer this?
Happy to do it if desired. Also understand if we are too far down the road. 

Phil
On Nov 19, 2015, at 08:39, Erik Wahlström neXus <[email-masked]> wrote:

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 <[email-masked]> wrote:

On the subject of making the spec(s) less JWT specific, it was a foundational 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 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 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 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öm neXus <[email-masked]> wrote:

Hi, 

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

——————

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

If a symmetric key is used it’s possible to re-use the key 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 (“aud”) claim in
 the token to disable missuse.

——————

The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-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 server, on both the client and resource server. PoP tokens is also a very good fit for constrained IoT devices that can be offline and it’s 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 about 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 authors if that’s of
 interest. 

———

s/a bogus tokens/a bogus token

——

In the document only references are made to JSON, JWT and JOSE. More exactly 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 (according to our draft). It does not only use signed/encrypted JWT’s 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’s, they are well known and should be used 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].

——

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

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

———

      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’s not defined in https://tools.ietf.org/html/rfc7662#section-2.2 and
 I don’t know in what other draft it can be defined.

——

In ACE WG the draft seitz-ace-oauth-authz have a profile for 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’t send 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 architecture section? That means a new section 7.5.

——

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

/ Erik

_______________________________________________

OAuth mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/oauth

---

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 19 Nov 2015 19:29:24 +0000

Fair enough. Was way to late to the game here. All and all, it’s a very good document.
/ Erik

On 19 Nov 2015, at 19:18, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

< div="">
-- Justin

/ Sent from my phone /
<>

-------- Original message --------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: 11/19/2015 11:28 AM (GMT-06:00)
To: Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05

Phil

On Nov 19, 2015, at 08:39, Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

On 19 Nov 2015, at 17:18, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Nov 19, 2015, at 01:17, Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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

——————

If a symmetric key is used it’s possible to re-use the key 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 (“aud”) claim in the token to disable missuse.

——————

The draft in ACE WG (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-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 server, on both the client and resource server. PoP tokens is also a very good fit for constrained IoT devices that can be offline and it’s 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 about 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 authors if that’s of interest.

———

——

   A number of the threats listed in Section 4<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#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<https://tools.ietf.org/html/rfc7519>].

   With the JSON Web Token (JWT) [RFC7519<https://tools.ietf.org/html/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<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#ref-I-D.ietf-oauth-proof-of-possession>].

I totally agree that JWT is the correct examples to have in this document due to the fact that they are RFC’s, they are well known and should be used 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<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#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<https://tools.ietf.org/html/rfc7519>].

——

 For that

———

      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<https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05#ref-I-D.ietf-oauth-introspection>].

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

——

In ACE WG the draft seitz-ace-oauth-authz have a profile for 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’t send 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.

——

/ Erik

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 11:27:09 -0500

I'm re-reading to make sure this would be okay at this stage and have
some suggestions.

Could 3.2 cover TLS and DTLS?  Then you don't need to state COSE/CBOR
specifically in this section but it hints at applicable IoT use cases
and isn't a big change since OAuth could be used in scenarios with
DTLS and IoT.

Since 3.3 refers to a web client, I'd leave it alone.  It's just a use
case.  And I don't think 3.4 is a good example for IoT with
discussions of load balancers.

In section 4, the client is listed generically without definition,
Maybe stating constrained and devices that are not constrained are
clients would be enough in the Token manufacture/modification threat
scenario? That would be on first use in this section for clients.

Section 6.2 calls out 2 examples with TLS, but doesn't restrict the
selection to these two, so I think the text there is fine as-is,
especially since "available infrastructure" is one of the
considerations.

I think that would be enough and wouldn't be too much to change at
this stage to include IoT under this draft.  I would not add in
explicit mention of CBOR or COSE as the draft doesn't mention JSON or
JOSE anywhere.

Does that should like a good approach?  This just means 2 minor
changes to make the generic text also explicitly include constrained
devices.

Thanks,
Kathleen

On Thu, Nov 19, 2015 at 2:29 PM, Erik Wahlström neXus
<[email-masked]> wrote:
> On 19 Nov 2015, at 19:18, Justin Richer <[email-masked]> wrote:
>
> I think your point that maybe the architecture doc be generic enough to
> support both json and cbor tokens is worth consideration.
>
> 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 the subject of making the spec(s) less JWT specific, it was a
> foundational 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 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
> 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 good idea?  Or is COSE better to
> write their own parallel arch draft?
>
> I have been reviewing draft-ietf-oauth-pop-architecture-05. In ACE WG we
> have a draft that uses PoP tokens for IoT and the architectures defined here
> so my review was done with that IoT perspective. I’m a bit late with the
> review and some of the comments might already be mentioned by others.
>
>
>
> ——————
>
> If a symmetric key is used it’s possible to re-use the key 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 (“aud”) claim in the token to disable missuse.
>
> ——————
>
> The draft in ACE WG
> (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-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 server, on both the client
> and resource server. PoP tokens is also a very good fit for constrained IoT
> devices that can be offline and it’s 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 about
> 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 authors
> if that’s of interest.
>
> ———
>
> Constrained IoT devices uses other access token and messages formats
> (according to our draft). It does not only use signed/encrypted JWT’s 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’s, they are well known and should be used
> in as many places as possible, but it would be good to open up for other
> types of message formats. For example like this:
>
>
> Not a question for this draft maybe, but in what draft is the introspection
> response claim defined? It’s not defined in
> https://tools.ietf.org/html/rfc7662#section-2.2 and I don’t know in what
> other draft it can be defined.
>
> ——
>
> In ACE WG the draft seitz-ace-oauth-authz have a profile for 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’t send 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.
>

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Fri, 20 Nov 2015 08:59:52 -0800

+1. I will post an update monday. 

Ps. Did you see my original responses to your first comments?

Phil

> On Nov 20, 2015, at 08:27, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 12:07:45 -0500

Sent from my iPhone

> On Nov 20, 2015, at 11:59 AM, Phil Hunt <[email-masked]> wrote:
> 

Our emails must have crossed.  Since I was re-reading, I figured it would be best to respond to both after that.

I think we are good now!  Thanks.

Kathleen