Sent from my iPhone
> On Nov 20, 2015, at 11:59 AM, Phil Hunt <[email protected]> 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 >> <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> Date: 11/19/2015 11:28 AM (GMT-06:00) >>> To: Erik Wahlström neXus <[email protected]> >>> Cc: "<[email protected]>" <[email protected]>, Justin Richer >>> <[email protected]> >>> 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 protected]> 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 protected]> 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 protected]> 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 protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
