Subject: [OAUTH-WG] PoP Key Distribution

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2018 19:46:12 +0000

Hi all,

we have been working on an update for the draft-ietf-oauth-pop-key-distribution document in time for the deadline but we noticed several issues that are worthwhile to bring to your attention.

draft-ietf-oauth-pop-key-distribution defines a mechanism that allows the client to talk to the AS to request a PoP access token and associated keying material.

There are two other groups in the IETF where this concept is used.

·         The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has been helping us to understand their needs. They have defined their own token format, which has been posted on the OAuth group a while ago for review.

·         The other group is ACE with their work on an OAuth-based profile for IoT.

Where should the parameters needed for PoP key distribution should be defined? Currently, they are defined in two places -- in https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In particular, the audience and the token_type parameters are defined in both specs.

IMHO it appears that OAuth would be the best place to define the HTTP-based parameters. ACE could define the IoT-based protocols, such as CoAP, MQTT, and alike. Of course, this is subject for discussion, particularly if there is no interest in doing so in the OAuth working group.

There is also a misalignment in terms of the content. draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. In the meanwhile the work on OAuth meta has been finalized and could potentially be re-used.

When the work on draft-ietf-oauth-pop-key-distribution was initially started there was only a single, standardized token format, namely the JWT. Hence, it appeared reasonable to use the JWT keying structure for delivering keying material from the AS to the client.

In the meanwhile two other formats have been standardized, namely RFC 7635 and the CWT. For use with those specs it appears less ideal to transport keys from the AS to the client using the JSON/JOSE-based format. It would be more appropriate to use whatever PoP token format is used instead. Currently, this hasn't been considered yet.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mike Jones <[email-masked]>
Date: Tue, 3 Jul 2018 20:10:52 +0000

Thanks for working these issues, Hannes.  I agree with your conclusion that the OAuth PoP Key Distribution spec should define the OAuth parameters for use with HTTP and the ACE OAuth profile should define those that are ACE-specific.  Therefore, we should encourage ACE spec to remove the duplicate definitions and instead reference those in the OAuth spec.

I believe that the ACE "profile" parameter is typically unnecessary and not in the spirit of normal OAuth.  Configuration information between OAuth participants is typically configured out of band and/or retrieved from the AS Discovery document (per the newly minted RFC 8414<https://tools.ietf.org/html/rfc8414>). There's no need to dynamically exchange a profile identifier when this is essentially always known in advance.  We should not include "profile".  For that matter, ACE should delete it as well, as it certainly isn't appropriate in constrained environments.

We should think some more about how we want to treat the function of the "alg" parameter and how to fully specify things for JWTs (an OAuth WG spec) while still enabling other representations when appropriate.

                                                       Thanks,
                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Tuesday, July 3, 2018 12:46 PM
To: [email-masked]
Subject: [OAUTH-WG] PoP Key Distribution

Hi all,

  *   The guys working on RTCWEB is the first. Misi (Mészáros Mihály) has been helping us to understand their needs. They have defined their own token format, which has been posted on the OAuth group a while ago for review.

  *   The other group is ACE with their work on an OAuth-based profile for IoT.

There is also a misalignment in terms of the content.. draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which does not exist in the draft-ietf-ace-oauth-authz document. The draft-ietf-ace-oauth-authz document does, however, have a profile parameter, which does not exist in draft-ietf-oauth-pop-key-distribution. Some alignment is therefore needed. In the meanwhile the work on OAuth meta has been finalized and could potentially be re-used.

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 4 Jul 2018 08:37:09 +0200

On 2018-07-03 22:10, Mike Jones wrote:

> 
> I believe that the ACE “profile” parameter is typically unnecessary and 
> not in the spirit of normal OAuth.  Configuration information between 
> OAuth participants is typically configured out of band and/or retrieved 
> from the AS Discovery document (per the newly minted RFC 8414 
> <https://tools.ietf.org/html/rfc8414>). There’s no need to dynamically 
> exchange a profile identifier when this is essentially always known in 
> advance.  We should not include “profile”.  For that matter, ACE should 
> delete it as well, as it certainly isn’t appropriate in constrained 
> environments.
>

I strongly disagree with this statement. First of all let me correct a 
misconception you seem to have: RFC 8414 is about AS metadata, while 
"profile" is RS metadata, so unless I've overlooked something, RFC 8414 
is not applicable.
The "profile" parameter tells a client which communication security 
method to use with the RS (e.g. TLS) and how to perform the 
proof-of-possession of a token towards an RS (e.g. TLS client 
authentication).
When you take the work on proof-of-possession into account, that feels 
very much in the spirit of OAuth.

Second: the "profile" parameter is optional, so if it is already known 
because it was configured out of band or discovered somehow you just 
don't send it.

Finally: Profile is intended for use cases were mobile clients and RS 
dynamically join and leave a network, so that pre-configuring clients 
with metadata about the RS is difficult. Do you have a better idea how 
to solve these cases?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 4 Jul 2018 08:55:46 +0200

> Hi all,
...
> Where should the parameters needed for PoP key distribution should be 
> defined? Currently, they are defined in two places -- in 
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13 and also in 
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. In 
> particular, the audience and the token_type parameters are defined in 
> both specs.
> 
> IMHO it appears that OAuth would be the best place to define the 
> HTTP-based parameters. ACE could define the IoT-based protocols, such as 
> CoAP, MQTT, and alike. Of course, this is subject for discussion, 
> particularly if there is no interest in doing so in the OAuth working 
> group.
> 

I fully agree that OAuth would be the best place. I've only drawn some 
of these parameters into draft-ietf-ace-oauth-authz because the work on
draft-ietf-oauth-pop-key-distribution seemed to have been discontinued 
(it expired August 2017).
That said, I'd hate to introduce a normative dependency into 
draft-ietf-ace-oauth-authz on a document that will not move forward or 
only move very slowly. What are the prospects of going forward quickly 
with draft-ietf-oauth-pop-key-distribution?

> There is also a misalignment in terms of the content.. 
> draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, which 
> does not exist in the draft-ietf-ace-oauth-authz document. The 
> draft-ietf-ace-oauth-authz document does, however, have a profile 
> parameter, which does not exist in 
> draft-ietf-oauth-pop-key-distribution. Some alignment is therefore 
> needed. In the meanwhile the work on OAuth meta has been finalized and 

It seems indeed that 'alg' and 'profile' parameters have some overlap, 
although 'alg' seemed a bit more narrow to me (which is why I created 
'profile').  If we could extend the definition of 'alg' a bit, I'd be OK
to remove 'profile' from the ACE draft (provided the OAuth draft moves 
forward in a timely manner).

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Jul 2018 16:46:57 -0500

On Tue, Jul 03, 2018 at 08:10:52PM +0000, Mike Jones wrote:
> 
> I believe that the ACE "profile" parameter is typically unnecessary and
> from the AS Discovery document (per the newly minted RFC
> 8414<https://tools.ietf.org/html/rfc8414>). There's no need to
> dynamically exchange a profile identifier when this is essentially always
> known in advance.  We should not include "profile".  For that matter, ACE

For what it's worth, this part of "the spirit of normal OAuth" is something
that leaves me with lingering unease.  While I do not dispute that this
sort of configuration information is usually known out of band or via
discovery, we ought to be considering the potential consequences when the
parties do not actually agree on what configuration should be in use.  An
explicit indicator makes for an easy-to-analyze "fail quickly" scenario,
whereas leaving things implicit is much harder to reason about.  And yes,
this case of easier analysis is at the cost of complexity elsewhere, so
there is a tradeoff.

-Ben

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Jul 2018 15:02:29 +0000

Hi Ludwig.  You're right that AS Metadata doesn't cover RS Metadata.  I stand corrected on that point.  There was once an OAuth Resource Metadata draft but the working group didn't have immediate use cases for it and so it was allowed to expire.  Work on it can resume, if it would be useful.

I'm glad that "profile" is now optional in ACE.  I still believe that dynamic configurations where clients might use multiple OAuth profiles are a corner case and that purpose-built clients that have the profile information baked into the code will be the norm (particularly in constrained environments).  I'm fine with an independent OAuth specification being created that defines a profile identifier but I believe that conflating this with OAuth PoP Key Distribution would be a mistake.

				-- Mike

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 11:37 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] PoP Key Distribution

On 2018-07-03 22:10, Mike Jones wrote:

> 
> I believe that the ACE "profile" parameter is typically unnecessary 
> and not in the spirit of normal OAuth.  Configuration information 
> between OAuth participants is typically configured out of band and/or 
> retrieved from the AS Discovery document (per the newly minted RFC 
> 8414 <https://tools.ietf.org/html/rfc8414>). There's no need to 
> dynamically exchange a profile identifier when this is essentially 
> always known in advance.  We should not include "profile".  For that 
> matter, ACE should delete it as well, as it certainly isn't 
> appropriate in constrained environments.
>

I strongly disagree with this statement. First of all let me correct a misconception you seem to have: RFC 8414 is about AS metadata, while "profile" is RS metadata, so unless I've overlooked something, RFC 8414 is not applicable.
The "profile" parameter tells a client which communication security method to use with the RS (e.g. TLS) and how to perform the proof-of-possession of a token towards an RS (e.g. TLS client authentication).
When you take the work on proof-of-possession into account, that feels very much in the spirit of OAuth.

Second: the "profile" parameter is optional, so if it is already known because it was configured out of band or discovered somehow you just don't send it.

Finally: Profile is intended for use cases were mobile clients and RS dynamically join and leave a network, so that pre-configuring clients with metadata about the RS is difficult. Do you have a better idea how to solve these cases?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Jul 2018 15:03:23 +0000

[See my reply to Ludwig, since the thread forked]

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Wednesday, July 4, 2018 2:47 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] PoP Key Distribution

On Tue, Jul 03, 2018 at 08:10:52PM +0000, Mike Jones wrote:
> matter, ACE

For what it's worth, this part of "the spirit of normal OAuth" is something that leaves me with lingering unease.  While I do not dispute that this sort of configuration information is usually known out of band or via discovery, we ought to be considering the potential consequences when the parties do not actually agree on what configuration should be in use.  An explicit indicator makes for an easy-to-analyze "fail quickly" scenario, whereas leaving things implicit is much harder to reason about.  And yes, this case of easier analysis is at the cost of complexity elsewhere, so there is a tradeoff.

-Ben

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Jul 2018 15:04:35 +0000

I'm fine putting some bandwidth into finishing OAuth PoP Key Distribution - particularly now that OAuth AS Metadata is finally done.  I know that Hannes is willing to do so as well.

				-- Mike

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 11:56 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] PoP Key Distribution

> Hi all,
....
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03. 
> In particular, the audience and the token_type parameters are defined 
> in both specs.
> 
> HTTP-based parameters. ACE could define the IoT-based protocols, such 
> as CoAP, MQTT, and alike. Of course, this is subject for discussion, 

I fully agree that OAuth would be the best place. I've only drawn some of these parameters into draft-ietf-ace-oauth-authz because the work on draft-ietf-oauth-pop-key-distribution seemed to have been discontinued (it expired August 2017).
That said, I'd hate to introduce a normative dependency into draft-ietf-ace-oauth-authz on a document that will not move forward or only move very slowly. What are the prospects of going forward quickly with draft-ietf-oauth-pop-key-distribution?

> draft-ietf-oauth-pop-key-distribution defined an 'alg' parameter, 
> which does not exist in the draft-ietf-ace-oauth-authz document. The 

It seems indeed that 'alg' and 'profile' parameters have some overlap, although 'alg' seemed a bit more narrow to me (which is why I created 'profile').  If we could extend the definition of 'alg' a bit, I'd be OK to remove 'profile' from the ACE draft (provided the OAuth draft moves forward in a timely manner).

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 Jul 2018 21:29:49 -0400

I don’t believe that this is a useful spec without meaningful key presentation mechanisms. 

 — Justin

> On Jul 5, 2018, at 11:04 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> .....