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

[Kathleen Moriarty <[e-mail]>]

Sent from my iPhone

> On Nov 20, 2015, at 11:59 AM, Phil Hunt <[e-mail]> wrote:
> 
> +1. I will post an update monday. 
> 
> Ps. Did you see my original responses to your first comments?

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 
> 
> Phil
> 
>> On Nov 20, 2015, at 08:27, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> 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
>> <[e-mail]> wrote:
>>> 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 <[e-mail]> wrote:
>>> 
>>> I agree with added "For example" in a few places. It's not normative it's
>>> informational here.
>>> 
>>> 
>>> 
>>> < div="">
>>> -- Justin
>>> 
>>> / Sent from my phone /
>>> <>
>>> 
>>> 
>>> -------- Original message --------
>>> From: Phil Hunt <[e-mail]>
>>> Date: 11/19/2015 11:28 AM (GMT-06:00)
>>> To: Erik Wahlström neXus <[e-mail]>
>>> Cc: "<[e-mail]>" <[e-mail]>, Justin Richer
>>> <[e-mail]>
>>> 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
>>> <[e-mail]> 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 <[e-mail]> 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
>>> <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth