Subject: [CDNi] draft-brandenburg-cdni-uri-signing-for-has-01

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 9 Dec 2015 14:51:42 +0000

Ray,

I was reading draft-brandenburg-cdni-uri-signing-for-has-01 section 5.4.1 and I see under 6.B. that the draft requires a new public/private key to be generated every time a new token is generated? I’m assuming this is a copy & paste error from the section on creating the initial key?

Assuming you don’t intend to have a new public/private key generated for each signed token in the chain, something that occurred to me is that the draft introduces a subtle change to the responsibilities of the CDN / exposure of the CSP for asymmetric signatures.

Today a CSP generates a token and a CDN validates it. The uri-signing-for-has draft allows the CDN to create a token for itself. In the past the CDN could always have done that anyway with a shared key but couldn’t with an asymmetric signature because the CDN never had access to the private key. uri-sgning-for-has requires the CDN to have the private key in order to created chained tokens. That might not be a problem for CSPs but it’s probably worth calling out somewhere in the draft that ui-signing-for-has required the CDN to have the private key whereas ietf-signed-uris draft does not.

Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 9 Dec 2015 16:26:27 +0000

Hi Ben,

Thanks for the review!

See my comments below.

>I was reading draft-brandenburg-cdni-uri-signing-for-has-01 section 5.4.1 and I see under 6.B. that the draft requires a new public/private key to be generated every time a new token is generated? I…

Yes, that's an error, you should only have to generate the key pair once. Now that I think about it, I think we should remove this line from to the main URI signing spec as well. 

>Today a CSP generates a token and a CDN validates it. The uri-signing-for-has draft allows the CDN to create a token for itself. In the past the CDN could always have done that anyway with a shared…

Hmm, good point. In practice, I assume the CDN would not use the CSP's private key but use an internal one for subsequent tokens, but you're right that we should call this out somewhere. In any case, I expect the use of asymmetric keys for chained tokens would only be beneficial in very specific circumstance anyway. 

Thanks again.

Ray

>
>Ben
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 9 Dec 2015 17:28:55 +0000

(I realised I’d only sent my response below to Ray & not the entire WG). Ben

> On 9 Dec 2015, at 17:11, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> Hi Ray,
> 
>> On 9 Dec 2015, at 16:26, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> If the CDN uses an internal key, what happens if a subsequent request from the client goes to a different CDN? E.g. DNS based request routing where the client does a DNS lookup per segment (which is how the iOS client behaves AFAIK) and the results returned in DNS change (the uCDN picks a different dCDN or the CSP is using a CDN selector for example).
> 
> Ben
>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 10 Dec 2015 08:13:28 +0000

Hi Ben,

>> If the CDN uses an internal key, what happens if a subsequent request from the client goes to a different CDN? E.g. DNS based request routing where the client does a DNS lookup per segment (which…

As long as the CDN that created the token makes it's public key available (and places the URI in the KeyID field), it shouldn't matter, right? How is this different from the single (non-chained) token scenario?

Ray

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 14 Dec 2015 17:08:36 +0000

Hi Ray,

> On 10 Dec 2015, at 08:13, Brandenburg, R. (Ray) van <[email-masked]> wrote:
> On 09/12/15 18:28, "Ben Niven-Jenkins" <[email-masked] <mailto:[email-masked]>> wrote:
> 

You are right this isn’t any different to the non-chained token scenario but I’d overlooked that KEYID contained a reference to where to obtain the public key.

I’d assumed that the public key would be carried in CDNI metadata (or otherwise out of band of the token itself) like it would need to be for shared secrets.

Which made me think that if any dCDN can recreate the token using their own key & insert a reference to the public key in the KEYID, what’s to stop Joe Public doing the same and minting their own tokens? Would that mean we’d have to distribute a form of "public keys for tokens” whitelist (containing all public keys that can be used to validate a token/hostname/site), whereas if only the CSP could generate the token you’d only need to distribute a single public key (the CSPs)?

Thanks
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 15 Dec 2015 08:24:50 +0000

Hi Ben,

From: Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>
Date: Monday 14 December 2015 at 18:08
To: Ray van Brandenburg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] draft-brandenburg-cdni-uri-signing-for-has-01

Hi Ray,

On 10 Dec 2015, at 08:13, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:
On 09/12/15 18:28, "Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Dec 2015, at 17:11, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ray,

On 9 Dec 2015, at 16:26, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:
On 09/12/15 15:51, "CDNi on behalf of Ben Niven-Jenkins" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
Assuming you don’t intend to have a new public/private key generated for each signed token in the chain, something that occurred to me is that the draft introduces a subtle change to the responsibilities of the CDN / exposure of the CSP for asymmetric signatures.

Ben

You're right that this is indeed a concern. In practice, I would imagine a CDN would indeed only accept a whitelisted list of KIDs, or domains, although I don't think we need to specify a mechanism for distributing such a list.

The security considerations section of the main URI Signing document currently includes the following paragraph:

" In the case where asymmetric keys are used, the KID information element might contain the URL to the public key.  To prevent malicious clients from signing their own URIs and inserting the associated public key URL in the KID field, thereby passing URI validation, it is important that CDNs check whether the URI conveyed in the KID field is in the allowable set of KIDs as listed in the CDNI metadata or set via configuration."

In addition, the algorithm itself also mentions that upon receiving a public key URL, the receiving CDN should check whether it is in the approved list of KEY IDs (received either via metadata or set by configuration).

Thanks,

Ray

Thanks
Ben