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 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
