Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 2 Nov 2012 14:27:59 +0000

Kent, Francois, Matt,

From reading draft-leung-cdni-uri-signing-01 it appears to be trying to outline what is required for CDN "URI Signing"/"Token authorisation" as well as describing a particular "URI Signing" mechanism (that has a number of significant drawbacks).

I'd suggest splitting these more explicitly into a more general discussion on what the authorisation attributes that could/should be supported are, what is needed on the other CDNI interfaces to support uri signing/token authorisation and what the use cases are for different type of signing/authorisation are e.g. is appending query parameters sufficient?

The draft could also describe a particular algorithm/mechanism but I think that should be in a later section or an appendix (or separate document) rather than being placed in the middle of the document as it is currently.

Ben

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 5 Nov 2012 10:28:44 -0500

Hi All,

  I agree with Ben's comments below.  I think it would be helpful if the
  document focused more on a generic method to describe URI signing algorithms
  and better described the information that needs to be exchanged by CDNI.

  wrt CDNI Metadata, we could go simple, and just have a single integer value
  that identifies an algorithms.  The components of any given algorithm could
  be kept outside the scope of CDNI.  If we want to describe the actual scheme,
  there are a few things that need to be distributed:

  1) the query string argument names, e.g., VER/ET/CIP/KO/KN/HF/ALG/US
  2) the allowed values for query string arguments for each field: VER/KO/KN/ALG/HF
     - for CIP, is the dCDN expected to validate that a MAC is actually a MAC
       or that and MEID is actually an MEID, etc?
  3) key retrieval information
  4) anything else?

  wrt CDN Capabilities, the capabilities would need to be much more than just
  "I support signing" or "I support these fields", but would also need to be
  able to describe "I support these values for these fields"?

  Is it intended that a uCDN would be allowed to created a "cryptographically
  equivalent" signing scheme for use when redirecting to the dCDN, if the dCDN
  does not support the exact algorithm specified by the CP?  If so, how?

  The security considerations mention some fundamental issues associated with
  URL signing (i.e., spoofing, nats, long timeouts).  Are we addressing those
  issues here, or just looking at security issues related to exchanging CDNI
  information required for doing signing, regardless of whether its a bad scheme?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Niven-Jenkins
> Sent: Friday, November 02, 2012 10:28 AM
> To: [email-masked]
> Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01
> 
> Kent, Francois, Matt,
> 
> From reading draft-leung-cdni-uri-signing-01 it appears to be trying to
> outline what is required for CDN "URI Signing"/"Token authorisation" as
> well as describing a particular "URI Signing" mechanism (that has a number
> of significant drawbacks).
> 
> I'd suggest splitting these more explicitly into a more general discussion
> on what the authorisation attributes that could/should be supported are,
> what is needed on the other CDNI interfaces to support uri signing/token
> authorisation and what the use cases are for different type of
> signing/authorisation are e.g. is appending query parameters sufficient?
> 
> The draft could also describe a particular algorithm/mechanism but I think
> that should be in a later section or an appendix (or separate document)
> rather than being placed in the middle of the document as it is currently.
> 
> Ben
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 6 Nov 2012 17:31:28 +0000

Hi Ben. Thanks for the feedback.

I agree that the draft attempts to document both the general purpose and the specifics of a scheme. The original intent was specifying the details for interoperability. But it's better that we start with a general discussion.

Here's what I think should be in the generic set of information that need to be passed between CDNs:

   o  Version - Identifier of the version of URI signing method with its set of capabilities.
   o  Expiry Time - Time duration when signed URI remains valid
   o  Client IP - IP address of the client that has access to the content
   o  Key Index - Index to the key used to validate the URI signature
   o  Hash Function -  Identifier of the hash algorithm (e.g.  "MD5", "SHA1") used by HMAC
   o  Algorithm - Identifier of the algorithm used to  compute the URI signature
   o  Client ID - Identifier of the client provided by the CSP
   o  Access to content is subject to URI validation or not indication
   o  Logging should provide indication of URI validation enforcement 

The information can be conveyed via URI query component or CDNI interfaces. The attributes that are appended to the query string may be a subset of the list. 

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Friday, November 02, 2012 7:28 AM
To: [email-masked]
Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01

Kent, Francois, Matt,

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 6 Nov 2012 17:45:25 +0000

Hi Kevin. Agree with your assessment. The only thing that I prefer to have is some specifics for the base function of the standard URI Signing method. That means first, identify the information needed to be exchanged between CDNs generically. Then, come up with the specifics that allows interoperability of the base function. More details need to be flushed out to see if that's feasible. Comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Monday, November 05, 2012 7:29 AM
To: Ben Niven-Jenkins; [email-masked]
Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01

Hi All,

KL> Agree.

  wrt CDNI Metadata, we could go simple, and just have a single integer value
  that identifies an algorithms.  The components of any given algorithm could
  be kept outside the scope of CDNI.  

KL> Prefer to specify a base function. Algorithms can be extended with a flexible scheme such as a simple integer identifier of the new algorithms.

If we want to describe the actual scheme,
  there are a few things that need to be distributed:

KL> We need to discuss the purpose of CID more to see if we should have this in the base function of URI Signing. For example, CID may be split into specific identifiers such as IMSI, MEID, MAC, etc. For the other attributes, is there a need to define the allowed values? 

KL> See above. Depends if there is value to know the allowable values. :)

KL> This should be part of the capabilities advertisement. For HTTP-based request routing, uCDN needs to know that the dCDN supports the algorithm used by uCDN to sign the URI.

KL> These are the issues associated with URI Signing. We can consider if there are ways to mitigate them. Not clear what's meant by "regardless of whether it's a bad scheme"? URI Signing is a bad scheme in general? Compare to another alternative?

Kent

thanx.

--  Kevin J. Ma

> From reading draft-leung-cdni-uri-signing-01 it appears to be trying 
> to outline what is required for CDN "URI Signing"/"Token 
> authorisation" as well as describing a particular "URI Signing" 
> mechanism (that has a number of significant drawbacks).
> 
> I'd suggest splitting these more explicitly into a more general 
> discussion on what the authorisation attributes that could/should be 
> supported are, what is needed on the other CDNI interfaces to support 
> uri signing/token authorisation and what the use cases are for 
> different type of signing/authorisation are e.g. is appending query parameters sufficient?
> 
> The draft could also describe a particular algorithm/mechanism but I 
> think that should be in a later section or an appendix (or separate 
> document) rather than being placed in the middle of the document as it is currently.
> 
> Ben
>

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 6 Nov 2012 13:59:50 -0500

Hi Kent,

> KL> We need to discuss the purpose of CID more to see if we should have
> this in the base function of URI Signing. For example, CID may be split
> into specific identifiers such as IMSI, MEID, MAC, etc. For the other
> attributes, is there a need to define the allowed values?

The allowed values only apply if we are going to allow substituting
"equivalent" URI signing schemes.  If not, then its not clear to me why
we would necessarily need to include KO/KN/HF/ALG in the query string.
They could just be configuration thats never exposed to the clients.
Having them in the query string allows clients to generate their own
algorithms, and opens up different attacks with fake KO/KN/HF injection?
But, that kind of segues into my next comment...  ;)

> KL> These are the issues associated with URI Signing. We can consider if
> there are ways to mitigate them. Not clear what's meant by "regardless of
> whether it's a bad scheme"? URI Signing is a bad scheme in general?
> Compare to another alternative?

What I meant was, the WG should not be addressing the goodness or badness of a
URI signing scheme.  (I tend to find them more bad than good.)  If someone
chooses an infinite expiration time, or chooses not to use a good client id,
or picks a bad key, etc., its a bad scheme, but that is probably inconsequential
to the CDNI interfaces?

Do we agree that the security concerns should be confined to only those concerns
related to CDNI metadata and capabilities exchange, and should not include general
concerns about the goodness or badness of the supported URI signing scheme?

thanx.

--  Kevin J. Ma

> From: Kent Leung (kleung) [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2012 12:45 PM
> To: Kevin J Ma; Ben Niven-Jenkins; [email-masked]
> Subject: RE: [CDNi] Comments on draft-leung-cdni-uri-signing-01
> 
> Hi Kevin. Agree with your assessment. The only thing that I prefer to have
> is some specifics for the base function of the standard URI Signing
> method. That means first, identify the information needed to be exchanged
> between CDNs generically. Then, come up with the specifics that allows
> interoperability of the base function. More details need to be flushed out
> to see if that's feasible. Comments below.
> 
> Kevin J Ma
> KL> Prefer to specify a base function. Algorithms can be extended with a
> flexible scheme such as a simple integer identifier of the new algorithms.
> 
> KL> We need to discuss the purpose of CID more to see if we should have
> this in the base function of URI Signing. For example, CID may be split
> into specific identifiers such as IMSI, MEID, MAC, etc. For the other
> attributes, is there a need to define the allowed values?
> 
> KL> This should be part of the capabilities advertisement. For HTTP-based
> request routing, uCDN needs to know that the dCDN supports the algorithm
> used by uCDN to sign the URI.
> 
> KL> These are the issues associated with URI Signing. We can consider if
> there are ways to mitigate them. Not clear what's meant by "regardless of
> whether it's a bad scheme"? URI Signing is a bad scheme in general?
> Compare to another alternative?
> 
> Kent
> 
> thanx.
> 
> --  Kevin J. Ma
>

---

From: Dan York <[email-masked]>
Date: Tue, 6 Nov 2012 14:46:44 -0500

> concerns about the goodness or badness of the supported URI signing scheme?

On a similar note related to scope, it would be helpful if the Security Considerations section had some commentary about the attack surface of the exchange of information between the CDNs (or pointed to a document where this is described).  By that I mean, is the exchange of CDNI information happening over the public Internet? over private networks? over VPNs? or potentially all of the above?   How accessible the exchange is to attackers can help guide the level of necessary robustness needed in the protection of the information.

Dan

-- 
Dan York  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: Dan York <[email-masked]>
Date: Tue, 6 Nov 2012 15:13:26 -0500

Kent, Francois, Matt,

Several times in the document there is a mention that for assymetric keys "public keys can typically be distributed openly", but unless I missed it (and I could have) I didn't get an understanding in the draft of *how* a CDN could get the public key for another CDN.  

How would a dCDN actually get the CSP's public key?

Would it retrieve it from a specific URL? from DNS? from some other PKI? from some other transfer method? all of the above?

I think the document should make some mention of how this distribution of the public key could occur.

Also, I don't know that I fully agree with this statement:

>    Key distribution for asymmetric keys does not require
>    confidentiality since public keys can typically be distributed openly
>    (because they cannot be used for URI signing) and private keys are
>    kept by the URI signing function.

While that is true, how does the dCDN know that it has the *correct* public key for the CPS?  What if the attacker can somehow provide the dCDN with a public key from the attacker's site?  He or she could then send updates to the dCDN that are signed with a public key and would appear legit - it would just be the wrong public key.

One potential solution would be to look at the work happening over in the DANE working group[1] where a certificate could be published as a DNS record and then signed with DNSSEC[2].  This would provide a way for the dCDN to easily get the public key for the CSP - and would also have strong integrity protection via DNSSEC so that the dCDN would know that it has the *correct* public key.

My 2 cents,
Dan

[1] or look at http://www.internetsociety.org/deploy360/resources/dane/ for some intro material.

[2] And yes, I realize that for this to work DNSSEC would need to be more widely deployed but: a) that's being worked on; and b) we're talking here about a defined set of users (CSPs) who would need to publish their public keys in DNS and sign their zone files.  Not necessarily a huge number of users to work with to get their zones signed and records published.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 7 Nov 2012 04:15:44 +0000

Hi Kevin. Comments below.

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2012 11:00 AM
To: Kent Leung (kleung); Ben Niven-Jenkins; [email-masked]
Subject: RE: [CDNi] Comments on draft-leung-cdni-uri-signing-01

Hi Kent,

> KL> We need to discuss the purpose of CID more to see if we should 
> KL> have
> this in the base function of URI Signing. For example, CID may be 
> split into specific identifiers such as IMSI, MEID, MAC, etc. For the 
> other attributes, is there a need to define the allowed values?

The allowed values only apply if we are going to allow substituting "equivalent" URI signing schemes.  If not, then its not clear to me why we would necessarily need to include KO/KN/HF/ALG in the query string.
They could just be configuration thats never exposed to the clients.
Having them in the query string allows clients to generate their own algorithms, and opens up different attacks with fake KO/KN/HF injection?
But, that kind of segues into my next comment...  ;)

KL>> Right, some of the attributes may not be needed in the query string if obtained via CDNI Metadata interface. We have to figure out the tradeoffs of how each attribute is obtained by dCDN.

> KL> These are the issues associated with URI Signing. We can consider 
> KL> if
> there are ways to mitigate them. Not clear what's meant by "regardless 
> of whether it's a bad scheme"? URI Signing is a bad scheme in general?

What I meant was, the WG should not be addressing the goodness or badness of a URI signing scheme.  (I tend to find them more bad than good.)  If someone chooses an infinite expiration time, or chooses not to use a good client id, or picks a bad key, etc., its a bad scheme, but that is probably inconsequential to the CDNI interfaces?

Do we agree that the security concerns should be confined to only those concerns related to CDNI metadata and capabilities exchange, and should not include general concerns about the goodness or badness of the supported URI signing scheme?

KL>> I think we should identify the issues with URI Signing scheme. People can figure out the level of concern depending on how URI Signing is used. But I'm still open on this matter.

Kent
<snip>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 7 Nov 2012 04:15:44 +0000

Hi Dan.  I think your question was about the CDNI interface security and more general than URI Signing. The CDNI Framework document states:

Security of CDNI Interfaces

   It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces
   must be able to operate securely over insecure IP networks.  Since it
   is expected that the CDNI interfaces will be implemented using
   existing application protocols such as HTTP or XMPP, we also expect
   that the security mechanisms available to those protocols may be used
   by the CDNI interfaces.  Details of how these interfaces are secured
   will be specified in the relevant interface documents.

Kent

<snip>

Dan

--
Dan York  [email-masked]<mailto:[email-masked]>
http://www.danyork.me/<http://www.danyork.com/>   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 7 Nov 2012 04:15:45 +0000

Hi Dan. That's right. The dCDN needs to know that it has the correct public key to validate the signed URI. I don't think that has been published, but one consideration is obtaining the public key via the CDNI Metadata interface.

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Tuesday, November 06, 2012 12:13 PM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: [CDNi] Assymetric key distribution - Re: Comments on draft-leung-cdni-uri-signing-01

Kent, Francois, Matt,

My 2 cents,
Dan

Kent, Francois, Matt,

Ben

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 7 Nov 2012 12:37:28 +0000

On 6 Nov 2012, at 23:15, Kent Leung (kleung) wrote:

I would also think the URI Signing document needs to identify the general security issues/limits/concerns associated with its use (or use of its particular variations e.g. if IP address (or CID) is not included then it does not protect against use of the URI by another enduser) and how to mitigate those when possible.
Francois

Kent
<snip>

---

From: Dan York <[email-masked]>
Date: Wed, 7 Nov 2012 09:31:09 -0500

Ken,

> Hi Dan.  I think your question was about the CDNI interface security and more general than URI Signing. The CDNI Framework document states:

Thank you for pointing me to this reference in the CDNI Framework document.  I would suggest for people who might someday look at this URI Signing document to figure out how to implement it that there be a sentence in the "Security Considerations" section along the lines of:

----
As noted in the CDNI Framework document [I-D.ietf-cdni-framework], all CDNI interfaces must be able to operate securely over insecure IP networks.  Care should be taken to ensure that the signed URIs are passed between CDNs using a secure transport.
----

Or something like that.

My 2 cents,
Dan