Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 09:59:06 +0100

Hi all,

I refreshed the PoP key distribution document. No changes to the
content of the document.

The document contains two questions, namely

QUESTION: A benefit of asymmetric cryptography is to allow clients to
   request a PoP token for use with multiple resource servers.  The
   downside of that approach is linkability since different resource
   servers will be able to link individual requests to the same client.
   (The same is true if the a single public key is linked with PoP
   tokens used with different resource servers.)  Nevertheless, to
   support the functionality the audience parameter could carry an array
   of values.  Is this desirable?

Hannes: My view is that we do not want to introduce likability into
OAuth via the use of these keys. As such, different keys for different
origins.

QUESTION: Should we register the token_type and alg parameters for use
with the dynamic client registration protocol?

Hannes: I believe we should register these two parameters into the
dynamic client registration protocol since that allows us to configure
the values for the client rather than exchanging them with every message.

Feedback appreciated before the submission deadline.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 10:27:33 +0100

inline
> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
John:  Having an array increases complexity and decreases privacy by allowing RS to link.

Audiance should be a single value.  That requires separate keys for symmetric, or asymmetric keys provisioned by the AS.

For asymmetric keys provisioned by the client it would be up to the client to decide if using the same key for multiple RS makes sense.  

It might be that there is a single key provisioned by a MSM in the tpm that they want to use for all the connections as that is the most secure, and are not concerned with correlation as all the RS are internal to a single enterprise.

> the values for the client rather than exchanging them with every message.
John:  Yes I had assumed that that was a no brainer.
The other question on registering is if we should allow the client to preregister a public key as well.
In some situations the client may want to always use the same key and making them push it each time is a waste of bandwidth.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 12:34:10 +0100

Hi John,

> It might be that there is a single key provisioned by a MSM in the tpm that they want to use for all the connections as that is the most secure, and are not concerned with correlation as all the RS…

OK.

> In some situations the client may want to always use the same key and making them push it each time is a waste of bandwidth.
The dynamic client registration already supports the feature of
uploading a public key to the authorization server and hence the missing
feature to support that case is to allow the client to refer to that key
somehow. I assume that the public key uploaded by the dynamic client
registration protocol is referenced using a URI. The question is just
what that URI would be.

Unfortunately, the Dynamic Client Registration spec is silent about how
to reference the public key uploaded via the jwks parameter. Did we just
found a bug in the spec?

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 12:54:39 +0100

For signing authentication requests you include the keyid in the JWT, and the AS looks in the JWKS to find the correct key if there is more than one.

I don't think that is a problem

What we probably need to do is pass a keyid in the request if there is more than one signing key registered for the client.

John B.

> On Mar 5, 2015, at 12:34 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi John,
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 13:43:21 +0100

Hi John,

that's a good idea. However, the dynamic client registration should
state that the "kid" parameter is used and must be included in the JWK
(since the kid is an optional parameter).

The key name is then the 'kid' plus the client id since the value of the
kid is not unique by itself.

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 13:58:23 +0100

I am ok with saying that the JWK must have keyed if there is more than one key and it SHOULD if there is only one. 

Sent from my iPhone

> On Mar 5, 2015, at 1:43 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi John,
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 05 Mar 2015 07:59:27 -0500

Right, but do we need to say that in Dyn-Reg? That's really more of a 
problem for the protocol using the keys, not the one registering it for use.

  -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 14:00:13 +0100

In context of <draft-ietf-oauth-pop-key-distribution-01> we then need to
differentiate the case where the client wants to have the server attach
the already stored key vs. the case where the client wants to create a
new key regardless whether there is one stored or not.

Does that make sense?

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 14:00:45 +0100

I agree and this can be done in AUTH48.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 05 Mar 2015 14:04:27 +0100

Actually, I am not sure my statement below is actually correct.

We need to distinguish the case where the client id is unique per client
software instance and when it isn't.

If the client id is shared by multiple client software instances then
how do we make sure that clients aren't uploading keys that either have
no kid or have an kid that is not unique (since they don't know about
the existence of other client instances or that other client instances
have already uploaded a jwk with the same kid).

Any idea how to address that problem?

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 5 Mar 2015 15:10:31 +0100

Clients that share a common client_id can't pre register.   You need to be doing per instance dynamic client registration for that to work. 

Non confidential clients need to push a key with code, or have it provisioned by the AS with the AT. 

Sent from my iPhone

> On Mar 5, 2015, at 2:04 PM, Hannes Tschofenig <[email-masked]> wrote:
>