Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt

From: Scott Wainner <[email-masked]>
Date: Tue, 16 Jul 2013 14:30:58 -0400

Kent,

     Some comments and thoughts ...

Scott

2. Signed URI Format

    o  Enforcement Attributes: Attributes that are used to enforce a
       distribution policy defined by the CSP.  Examples of enforcement
       attributes are IP address of the UA and time window.

sw> We need to clarify if this is the IP address assigned to the client 
(often a 192.168.0.x address) or the public IP address presented to the 
system (i.e. post NAT'd).  I presume the latter.

2.1 Enforcement Attributes

    o  Client IP (CIP) [optional] - IP address of the client for which
       this signed URI is generated.  This is represented in dotted
       decimal format for IPv4 or canonical text representation for IPv6
       address [RFC5952] .  The request is rejected if sourced from a
       client with a different IP address.

sw> We need to clarify if this is the IP address assigned to the client 
or the IP address representing the client's public appearance on the 
Internet.  I presume the latter; the CSP will see the public IP address.

2.2.  Signature Computation Attributes

    o  Hash Function (HF) [optional] - A string used for identifying the
       hash function to compute the URI signature (e.g.  "MD5", "SHA1")
       with HMAC.

sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256?

3.  Signing a URI
    9.   Depending on the type of key used to sign the URI, compute the
         message digest or digital signature for symmetric key or
         asymmetric keys, respectively.

         A.  For symmetric key, HMAC is used.
             j.  Append the string for the message digest (e.g. "://
                 example.com/
content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&
                 KID=example:keys:123&HF=SHA-1&
                 MD=4fb1c1adf1588fbe11cc6a04c6e69f35").

sw> This example assumes there were no previously defined query string 
parameters.  We need to specify exactly what is provided as input into 
the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS).  Do we 
include previously define query string parameters that existing on the 
URL or only the path.  I find that clients may need to include query 
strings to facilitate CDN selection or bias decisions.  If the client 
inserts a query string and that portion is validated by the HMAC, then 
the client will invalidate the signature.  Perhaps this is motivation 
for using the tokenized method.  The client can insert query strings in 
front of the token query parameter without invalidating the URL.

4.  Validating a URI Signature

    4.  Extract the value from "CIP" attribute if the attribute exists.
        Validate that the request came from the same IP address as
        indicated in the "CIP" attribute.  If the IP address is
        incorrect, then the request is denied.

sw> Sounds like we're using the IP address presented by the client and 
not the IP address assigned to the client.

4.  Validating a URI Signature

    8.  If neither "MD" or "DS" attribute is in the URI, then no URI

sw> This implies that URL Signing is required.  Presumably, we can 
configure the system such that we know if incoming URL's should or 
should not be signed.  What is the criteria and how do we determine if 
the criteria is met?

5.3.  CDNI Metadata Interface

    o  Content access control indication.

sw>  Is the access control defined on a per object request (manifest / 
segment) or class of service request?  A class of service request (e.g. 
http://service_path/media_path/media?foo) might indicate ALL media 
objects associated with the "://service_path/" require access control.  
How do we define the scope of access control for URL signing?

    o  Encoding format to override the "UST" attribute.  (Editor Note: Is
       this needed in CDNI Metadata or defined in a new CDNI attribute?)

sw>  What is implied by the statement 'override'.  Presumably, the UST 
can be transparently passed from surrogate to surrogate even while the 
domain, path, and query parameters (outside of the UST) are changed.  
That is because the UST contains the validated attributes.

On 5/31/13 11:35 AM, Kent Leung (kleung) wrote:
> Hi folks.  We've made some updates based on the WG feedback and internal discussions. Comments are welcome. Thanks.
>
> Kent
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 31, 2013 8:26 AM
> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (flefauch); Bill Downey
> Subject: New Version Notification for draft-leung-cdni-uri-signing-02.txt
>
>
> A new version of I-D, draft-leung-cdni-uri-signing-02.txt
> has been successfully submitted by Kent Leung and posted to the IETF repository.
>
> Filename:	 draft-leung-cdni-uri-signing
> Revision:	 02
> Title:		 URI Signing for CDN Interconnection (CDNI)
> Creation date:	 2013-05-31
> Group:		 Individual Submission
> Number of pages: 29
> URL:             http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-signing-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-leung-cdni-uri-signing
> Htmlized:        http://tools.ietf.org/html/draft-leung-cdni-uri-signing-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-uri-signing-02
>
> Abstract:
>     This document describes how the concept of URI signing supports the
>     content access control requirements of CDNI and proposes a candidate
>     URI signing scheme.
>
>     The proposed URI signing method specifies the information needed to
>     be included in the URI and the algorithm used to authorize and to
>     validate access request for the content referenced by the URI.  Some
>     of the information may be accessed by the CDN via configuration or
>     CDNI metadata.
>
>                                                                                    
>
>
> The IETF Secretariat
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 17 Jul 2013 03:29:06 +0000

Hi Scott. Thanks for the feedback. See my comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Wainner (swainner)
Sent: Tuesday, July 16, 2013 11:31 AM
To: [email-masked]
Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt

Kent,

Scott

2. Signed URI Format

sw> We need to clarify if this is the IP address assigned to the client
(often a 192.168.0.x address) or the public IP address presented to the system (i.e. post NAT'd).  I presume the latter.

KL> The IP address is the IP address in the IP header of the HTTP request message as seen by the CDN. We can add some clarification if needed.

KL> See previous comment.

KL> I'm open to suggestions. We need to consider current deployments.  One reason for being optional is that the hash function may be obtained via CDNI metadata. As for the mandatory hash functions that need to be supported, I think MD5 and SHA1 can be good candidates.

3.  Signing a URI

KL> This is an example, which is used to keep it simple. Step #2 covers the procedure to include existing query string. Does that answer your question?

KL> Yes, as mentioned in previous comment.

KL> When URL Signing is configured to be validated, then these attributes need to be in the URI.  Yes, it's possible that URI Signing is  configured. I had put this under the CDNI Metadata Interface. See below

o  Type of access control.  Specifically, access to content is
      subject to URI Signing.  URI Signing required indication means
      Downstream CDN ensures URI must be signed and validated before
      content delivery.  Otherwise, Downstream CDN does not perform
      validation regardless if URI is signed or not.

I guess we can say that this can be "set by configuration or CDNI metadata" as noted in other areas. 

KL> I assume that the access control scope is based on the scope of the metadata. So it can be for a specific content or a group of content. 

KL> The override is meant to use another attribute name instead of "UST" to carry the URI Signing token value. Just a method to provide flexibility on the attribute name.

Kent

---

From: Kevin J Ma <[email-masked]>
Date: Sun, 28 Jul 2013 18:44:34 -0400

Hi Kent,

  I finally got around to reading the draft and had a couple comments:

- I'd like to reiterate the point scott made about the query string:

  > KL> This is an example, which is used to keep it simple. Step #2 covers
  > the procedure to include existing query string. Does that answer your
  > question?

  Step #2 seems to assume that no downstream entity is going to insert
  anything else into the query string, which is probably not a safe assumption.
  Cache busting and tracking parameters get appended all the time?  And
  theres nothing that prevents duplicate parameter names from being inserted
  either downstream, or even by the CSP.  We need to be able to uniquely
  identify the parts of the original URI that are being validated.

  There is also a UST requirement in 2.4:

    "The attribute MUST be the last attribute in the query string of the URI."

  This can be enforced at the time of signing, but at the time of verification
  we need to be able to reconstruct the exact URI that was signed.  That text
  probably needs to be more precise.

  And in section 4, the second step 1 for validating the URI says:

    "Copy the Original URI"

  But, it is not clear how to we know what the original URI was?

- "Key ID (KID) [optiona]" -> Key ID (KID) [optional]"

- Is there a reason to separate MD and SD?  Is it just to be semantically
  explicit?  (Is it not implicit in the KID?)

- In section 3, step 9.A.i says:

  "Convert the message digest to its equivalent human readable value."

  We should probably explicity define the format?  hex?  base64?

- In section 3, steps 9.B.c and 9.B.i, do we need to be concerned about
  the use of reserved characters?  And if those characters have to be
  escaped, is the signature performed before or after escaping?

- In step 2 of the tokenizing procedure: ") Note:" -> "). Note:"

  I found this sentance to be a little bit confusing, because it talks about
  the signature, but then it gives an example of the message the signature
  is being calculated over, and then has a note about the signature, but
  the signature is never shown.  I think the example of the message is
  confusing within the context of the signature.

thanx.

--  Kevin J. Ma

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kent Leung (kleung)
> Sent: Tuesday, July 16, 2013 11:29 PM
> To: Scott Wainner (swainner); [email-masked]
> KL> The IP address is the IP address in the IP header of the HTTP request
> message as seen by the CDN. We can add some clarification if needed.
> 
> KL> I'm open to suggestions. We need to consider current deployments.  One
> reason for being optional is that the hash function may be obtained via
> CDNI metadata. As for the mandatory hash functions that need to be
> supported, I think MD5 and SHA1 can be good candidates.
> 
> 3.  Signing a URI
> KL> This is an example, which is used to keep it simple. Step #2 covers
> the procedure to include existing query string. Does that answer your
> question?
> 
> KL> When URL Signing is configured to be validated, then these attributes
> need to be in the URI.  Yes, it's possible that URI Signing is
> configured. I had put this under the CDNI Metadata Interface. See below
> 
> KL> I assume that the access control scope is based on the scope of the
> metadata. So it can be for a specific content or a group of content.
> 
> KL> The override is meant to use another attribute name instead of "UST"
> to carry the URI Signing token value. Just a method to provide flexibility
> on the attribute name.
> 
> Kent
> 
> 
> > Hi folks.  We've made some updates based on the WG feedback and internal
> discussions. Comments are welcome. Thanks.
> >
> > Kent
> >

---

From: Scott Leibrand <[email-masked]>
Date: Sun, 28 Jul 2013 18:46:44 -0700

In our implementation, anything to the left of the hash (h= for us) is used to generate the signature, and can't be changed by the client without causing the signature validation to fail. This prevents the client from changing the expire time or IP, for example. But anything to the right of the hash is not included, so the client can append other query terms without affecting the signature. 

Scott

On Jul 28, 2013, at 3:44 PM, Kevin J Ma <[email-masked]> wrote:

>> Scott Wainner (swainner)

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 29 Jul 2013 03:10:24 -0400

Hi Scott,

  If thats ok with everyone else, it's ok with me, but I think we need to be
  more precise in how we specify it, e.g., extract the right most ET value
  which appears before the right most MD/DS, and any duplicate parameter names
  or rearranging of parameters is explicitly prohibited, so if the CSP has an
  existing extra terestrial variable ET, it must appear to the left of the
  expiration time ET variable, which must appear to the left of the MD/DS, and
  if the client inserts an element tracking variable ET, it must appear to the
  right of the MD/DS, and reordering of the query string is not allowed.

thanx.

--  Kevin J. Ma

> From: Scott Leibrand [mailto:[email-masked]]
> Sent: Sunday, July 28, 2013 9:47 PM
> To: Kevin J Ma
> Cc: Kent Leung (kleung); Scott Wainner (swainner); [email-masked]
> In our implementation, anything to the left of the hash (h= for us) is
> used to generate the signature, and can't be changed by the client without
> causing the signature validation to fail. This prevents the client from
> changing the expire time or IP, for example. But anything to the right of
> the hash is not included, so the client can append other query terms
> without affecting the signature.
> 
> Scott
> 
> >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-
> uri-
> >> signing-02.txt
> >>
> >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-
> uri-
> >> signing-02.txt
> >>
> >> Kent,
> >>
> >>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-
> uri-
> >> signing-02
> >>>
> >>> Abstract:

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 29 Jul 2013 08:50:11 +0000

Hi Kevin. Thanks for the review comments. My comments below.

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Sunday, July 28, 2013 3:45 PM
To: Kent Leung (kleung); Scott Wainner (swainner); [email-masked]
Subject: RE: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt

Hi Kent,

    "Copy the Original URI"

KL> OK. I agree that we need more precise text here.

KL> Yes, it is to be semantically explicit. The KID is used to reference the keying material and not to be overloaded semantically.

KL> Agree. The text should be precise.

KL> Agree this needs to be captured in the text.

KL> OK.

KL> I see the confusion. The procedure is only for computing the URI Signing token.  It does not produce the Signed URI which was mistakenly claimed. The section needs to be worked back into steps 9.A.g and 9.B.e which contain the message to be signed. Good catch.

Appreciate the thorough review.

Kent

thanx.

--  Kevin J. Ma

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Kent Leung (kleung)
> Subject: Re: [CDNi] FW: New Version Notification for 
> draft-leung-cdni-uri- signing-02.txt
> 
> Subject: Re: [CDNi] FW: New Version Notification for 
> draft-leung-cdni-uri- signing-02.txt
> 
> Kent,
> 
> sw> We need to clarify if this is the IP address assigned to the 
> sw> client
> (often a 192.168.0.x address) or the public IP address presented to 
> the system (i.e. post NAT'd).  I presume the latter.
> 
> KL> The IP address is the IP address in the IP header of the HTTP 
> KL> request
> sw> We need to clarify if this is the IP address assigned to the 
> sw> client
> KL> I'm open to suggestions. We need to consider current deployments.  
> KL> One
> reason for being optional is that the hash function may be obtained 
> via CDNI metadata. As for the mandatory hash functions that need to be 
> the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS).  Do 
> we include previously define query string parameters that existing on 
> the URL or only the path.  I find that clients may need to include 
> query strings to facilitate CDN selection or bias decisions.  If the 
> client inserts a query string and that portion is validated by the 
> HMAC, then the client will invalidate the signature.  Perhaps this is 
> motivation for using the tokenized method.  The client can insert 
> query strings in front of the token query parameter without invalidating the URL.
> 
> KL> This is an example, which is used to keep it simple. Step #2 
> KL> covers
> KL> When URL Signing is configured to be validated, then these 
> KL> attributes
> KL> I assume that the access control scope is based on the scope of 
> KL> the
> to carry the URI Signing token value. Just a method to provide 
> flexibility on the attribute name.
> 
> Kent
> 
> 
> > To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); 
> > Francois
> Le Faucheur (flefauch); Bill Downey

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 29 Jul 2013 08:51:59 +0000

I agree that the text needs more clarifications on the sequencing of attributes. Thanks.

Kent

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Monday, July 29, 2013 12:10 AM
To: Scott Leibrand
Cc: Kent Leung (kleung); Scott Wainner (swainner); [email-masked]
Subject: RE: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt

Hi Scott,

thanx.

--  Kevin J. Ma

> used to generate the signature, and can't be changed by the client 
> without causing the signature validation to fail. This prevents the 
> client from changing the expire time or IP, for example. But anything 
> to the right of the hash is not included, so the client can append 
> other query terms without affecting the signature.
> 
> Scott
> 
> >> sw> This example assumes there were no previously defined query 
> >> sw> string
> >> parameters.  We need to specify exactly what is provided as input 
> >> into the HMAC function (PATH ? QUERY_PARAMTERS & 
> >> SIGNING_PARAMETERS).  Do we include previously define query string 
> >> parameters that existing on the URL or only the path.  I find that 
> >> clients may need to include query strings to facilitate CDN 
> >> selection or bias decisions.  If the client inserts a query string 
> >> and that portion is validated by the HMAC, then the client will 
> >> invalidate the signature.  Perhaps this is motivation for using the 
> >> tokenized method.  The client can insert query strings in front of the token query parameter without invalidating the URL.
> >>
> >> the procedure to include existing query string. Does that answer 
> >> your question?
> >
> >  Step #2 seems to assume that no downstream entity is going to 
> > insert  anything else into the query string, which is probably not a 
> > safe
> assumption.
> >  Cache busting and tracking parameters get appended all the time?  
> > And  theres nothing that prevents duplicate parameter names from 
> > being
> inserted
> >  either downstream, or even by the CSP.  We need to be able to 
> > uniquely  identify the parts of the original URI that are being validated.
> >
> >    "The attribute MUST be the last attribute in the query string of 
> > the
> URI."
> >
> >  we need to be able to reconstruct the exact URI that was signed.  
> > That
> text
> > - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned 
> > about  the use of reserved characters?  And if those characters have 
> > to be  escaped, is the signature performed before or after escaping?
> >
> >  I found this sentance to be a little bit confusing, because it 
> > talks
> about
> >  is being calculated over, and then has a note about the signature, 
> > but  the signature is never shown.  I think the example of the 
> > message is  confusing within the context of the signature.
> >
> > thanx.
> >
> > --  Kevin J. Ma
> >
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Kent Leung (kleung)
> >> draft-leung-cdni-
> >> draft-leung-cdni-
> request
> >> or the IP address representing the client's public appearance on 
> >> the Internet.  I presume the latter; the CSP will see the public IP
> address.
> >>
> >> sw> Should we not define a mandatory set of methods? MD5, SHA-1, 
> >> sw> SHA-
> 256?
> >>
> One
> >> via CDNI metadata. As for the mandatory hash functions that need to 
> >> be supported, I think MD5 and SHA1 can be good candidates.
> >>
> >> 3.  Signing a URI
> >> sw> This example assumes there were no previously defined query 
> >> sw> string
> >> parameters.  We need to specify exactly what is provided as input 
> >> into the HMAC function (PATH ? QUERY_PARAMTERS & 
> >> SIGNING_PARAMETERS).  Do we include previously define query string 
> >> parameters that existing on the URL or only the path.  I find that 
> >> clients may need to include query strings to facilitate CDN 
> >> selection or bias decisions.  If the client inserts a query string 
> >> and that portion is validated by the HMAC, then the client will 
> >> invalidate the signature.  Perhaps this is motivation for using the 
> >> tokenized method.  The client can insert query strings in front of the token query parameter without invalidating the URL.
> >>
> >> the procedure to include existing query string. Does that answer 
> >> your question?
> >>
> >> sw> Sounds like we're using the IP address presented by the client 
> >> sw> and
> >> should not be signed.  What is the criteria and how do we determine 
> >> if the criteria is met?
> >>
> attributes
> >> sw>  Is the access control defined on a per object request 
> >> sw> (manifest /
> >> sw>  What is implied by the statement 'override'.  Presumably, the 
> >> sw> UST
> >> can be transparently passed from surrogate to surrogate even while 
> >> the domain, path, and query parameters (outside of the UST) are changed.
> >>> Subject: New Version Notification for 
> >>> draft-leung-cdni-uri-signing-
> >> 02.txt
> >>>
> >>>
> >>> has been successfully submitted by Kent Leung and posted to the 
> >>> IETF
> >> repository.
> >>>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 30 Jul 2013 03:50:04 +0000

Follow up on one issue that you brought up. 

I realized that I confused myself when reading your comments. :) Actually, the steps are right but probably not clear. It does generate the Signed URI as the result. In step 1, the URI signature is shown in the example ("MD=..."). The point is to highlight that the URI signature is part of the message that is tokenized. Basically, all the CDNI attributes that are added to the original URI are encoded into the URI Signing token. The "message" here is for generating the token and appending it to the Original URI to create the Signed URI. It is not related to the "message" used in earlier procedures to compute the URI signature. So step 6 should say "Note: this is the completed Signed URI when URI Signing token is used". And in step 10 in prior procedure, it should say "Note: this is the completed Signed URI when URI Signing token is not used". Would that help to clarify the issue?

Changes to steps 10 and 6:

   10.  When tokenizing the URI Signing attributes is not necessary,
        generate the Signed URI by prepending the "scheme name" part to
        the message (e.g. http://example.com/
        content.mov?VER=1&ET=1209422976&CIP=10.0.0.1&KID=http://
        example.com/public/keys/123&DS=r:
        CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D
        :s:
        57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E
        " ).  Note: this is the completed Signed URI when URI Signing
        token is not used.

   6.  Append the URI Signing token to the message (e.g. "http://
       example.com/
       content.mov?UST=VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEmS0lEP
       WZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZGYxNTg4ZmJlMTFjYz
       ZhMDRjNmU2OWYzNQ==").  Note: this is the completed Signed URI
       when URI Signing token is used.

Kent

<snip>

<snip>