Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CAHbuEH7jW0=P2BhxQyrLPLfkRpn6+Gz-Cup_-ARLtNb45bnDJg@mail.gmail.com>
Date: Fri, 20 Nov 2015 08:59:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <807F71A5-3C01-437C-8187-8A4349D7DF46@oracle.com>
References: <ogcawk0n3xg6qmm80oh907tq.1447957121278@email.android.com>
 <2DC07A54-BA80-48EE-9CC3-7BDE4CAA0AD7@nexusgroup.com>
 <CAHbuEH7jW0=P2BhxQyrLPLfkRpn6+Gz-Cup_-ARLtNb45bnDJg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/3Y-oCBOmWgzqODoY6dj3Rv3lbpM>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>, Justin Richer <ietf@justin.richer.org>
Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05
Precedence: list

+1. I will post an update monday.=20

Ps. Did you see my original responses to your first comments?

Phil

> On Nov 20, 2015, at 08:27, Kathleen Moriarty <kathleen.moriarty.ietf@gmail=
.com> wrote:
>=20
> I'm re-reading to make sure this would be okay at this stage and have
> some suggestions.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Does that should like a good approach?  This just means 2 minor
> changes to make the generic text also explicitly include constrained
> devices.
>=20
> Thanks,
> Kathleen
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Thu, Nov 19, 2015 at 2:29 PM, Erik Wahlstr=C3=B6m neXus
> <erik.wahlstrom@nexusgroup.com> wrote:
>> Fair enough. Was way to late to the game here. All and all, it=E2=80=99s a=
 very good
>> document.
>> / Erik
>>=20
>>=20
>> On 19 Nov 2015, at 19:18, Justin Richer <jricher@MIT.EDU> wrote:
>>=20
>> I agree with added "For example" in a few places. It's not normative it's=

>> informational here.
>>=20
>>=20
>>=20
>> < div=3D"">
>> -- Justin
>>=20
>> / Sent from my phone /
>> <>
>>=20
>>=20
>> -------- Original message --------
>> From: Phil Hunt <phil.hunt@oracle.com>
>> Date: 11/19/2015 11:28 AM (GMT-06:00)
>> To: Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com>
>> Cc: "<oauth@ietf.org>" <oauth@ietf.org>, Justin Richer
>> <ietf@justin.richer.org>
>> Subject: Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05
>>=20
>> I think your point that maybe the architecture doc be generic enough to
>> support both json and cbor tokens is worth consideration.
>>=20
>> I am just not sure of process and consensus now that we are past WGLC. Wo=
uld
>> the cose group prefer this?
>>=20
>> Happy to do it if desired. Also understand if we are too far down the roa=
d.
>>=20
>> Phil
>>=20
>> On Nov 19, 2015, at 08:39, Erik Wahlstr=C3=B6m neXus
>> <erik.wahlstrom@nexusgroup.com> wrote:
>>=20
>> Just a note then. I did not see anything that prohibited the usage of pop=

>> tokens for IoT so  shipping it as is works.
>>=20
>> Sent from my iPhone
>>=20
>> On 19 Nov 2015, at 17:18, Phil Hunt <phil.hunt@oracle.com> wrote:
>>=20
>> 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.
>>=20
>> 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 specif=
ic.
>>=20
>> Another issue is I assume the COSE based tokens will have a different typ=
e
>> (eg cpop) to differentiate between jwt and COSE web tokens (what are we
>> calling them now?).
>>=20
>> As this generalization change could be seen as substantial, I would like t=
o
>> have the chairs and AD comment. Is this a good idea?  Or is COSE better t=
o
>> write their own parallel arch draft?
>>=20
>> I'm happy to bend to the will of the group(s) on this.
>>=20
>> Phil
>>=20
>> On Nov 19, 2015, at 01:17, Erik Wahlstr=C3=B6m neXus
>> <erik.wahlstrom@nexusgroup.com> wrote:
>>=20
>> Hi,
>>=20
>> 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 h=
ere
>> so my review was done with that IoT perspective. I=E2=80=99m a bit late w=
ith the
>> review and some of the comments might already be mentioned by others.
>>=20
>>=20
>>=20
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>=20
>> 3.1. Preventing Access Token Re-Use by the Resource Server
>>=20
>> If a symmetric key is used it=E2=80=99s possible to re-use the key for a r=
esource
>> 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 (=E2=80=9Caud=E2=80=9D) claim in the token to disable missuse.
>>=20
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>>=20
>> The draft in ACE WG
>> (https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00) relies heavi=
ly
>> on this work. The main reason for this is the way PoP tokens can establis=
h
>> key material, with the help of the authorization server, on both the clie=
nt
>> and resource server. PoP tokens is also a very good fit for constrained I=
oT
>> devices that can be offline and it=E2=80=99s also possible to use hardwar=
e key
>> storages to handle asymmetric pop keys.
>>=20
>> There could be a place for a new "Use Case" under section 3 that talks ab=
out
>> 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 auth=
ors
>> if that=E2=80=99s of interest.
>>=20
>> =E2=80=94=E2=80=94=E2=80=94
>>=20
>> s/a bogus tokens/a bogus token
>>=20
>> =E2=80=94=E2=80=94
>>=20
>> In the document only references are made to JSON, JWT and JOSE. More exac=
tly
>> in the following two sections:
>>=20
>>   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].
>>=20
>>=20
>>=20
>>   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].
>>=20
>>=20
>> Constrained IoT devices uses other access token and messages formats
>> (according to our draft). It does not only use signed/encrypted JWT=E2=80=
=99s but
>> also COSE protected CBOR Web Tokens. See
>> https://tools.ietf.org/id/draft-wahlstroem-oauth-cbor-web-token-00.txt
>>=20
>> I totally agree that JWT is the correct examples to have in this document=

>> due to the fact that they are RFC=E2=80=99s, they are well known and shou=
ld 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:
>>=20
>>=20
>>   A number of the threats listed in Section 4 demand protection of the
>>   access token content and a standardized solution in form of, for exampl=
e,
>> a JSON-
>>   based format, is available with the JWT [RFC7519].
>>=20
>>=20
>>=20
>> =E2=80=94=E2=80=94
>>=20
>> For that
>>   purpose the client will have to authenticate the resource server
>>   before transmitting the access token.
>>=20
>>=20
>>=20
>> I=E2=80=99m missing a description about how this is handled in an end-to-=
end
>> security scenario.
>>=20
>> =E2=80=94=E2=80=94=E2=80=94
>>=20
>>      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].
>>=20
>>=20
>>=20
>> Not a question for this draft maybe, but in what draft is the introspecti=
on
>> response claim defined? It=E2=80=99s not defined in
>> https://tools.ietf.org/html/rfc7662#section-2.2 and I don=E2=80=99t know i=
n what
>> other draft it can be defined.
>>=20
>> =E2=80=94=E2=80=94
>>=20
>> 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=E2=80=99t=
 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 resou=
rce
>> 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.
>>=20
>> An open question; should a flow like that be added to the architecture
>> section? That means a new section 7.5.
>>=20
>> =E2=80=94=E2=80=94
>>=20
>> Thanks for writing this. I think it=E2=80=99s very important work.
>>=20
>> / Erik
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
> --=20
>=20
> Best regards,
> Kathleen
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth