Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

From: Kevin Ma J <[email-masked]>
Date: Tue, 22 Jul 2014 20:53:12 +0000

Hi Ray et al,

  Couple of comments on the latest version:

- section 2.5: "Packacke" -> "Package"

- section 2.5: wrt the following text:

  "Adding any such attributes
   to the Signed URI before the URI Signing Packacke Attribute will
   cause the URI Signing validation to fail."

  Theoretically, the implementer could try all possible permutations
  of query string attributes to see if any of them produce a valid
  hash, thus determining the valid parameters (not that anyone would
  necessarily want to spend the cycles to do it)?

- section 4: I think that the order of sections 4.1 and 4.2 should be
            switched, i.e., implementations should verify the
             signature before doing other validation.  The text does
             not explicitly state which order to perform these sets of
             steps, but I think it should.  The implicit ordering
             implied by the section ordering would allow an attacker
             to insert a bad package, with no signature and a bad VER,
             to launch a DoS attack?

             Now, that said, it would certainly be easier for the
             attacker to just add an attribute to the query string
             before the package attribute, so it's not clear that they
             would go to the trouble to generate a fake package, but I
             thought I'd throw it out there?

             Note: The latter issue could be addressed by putting the
             whole URL into the package, at a size cost, or permuting
             the attributes, at a processing cost?

             Should these be noted in the Security Considerations?

- section 4.2, step 3: Do we want to be more specific about the Base64
                       decoding of the package attribute (similar to
                       the text in section 4.1, step 2)?

- section 4.2, step 4.A.a: wrt the following text:

  "to locate the shared key, which may
   be one of the keys available to use (i.e. set by
   configuration or CDNI metadata)."

  I think "may" should be "MUST"?

- section 5.4: The Allowable * sets should define the default to be
               either allow all or deny all?

- section 5.4: This structure of the metadata needs to be defined to
               clarify the JSON serialization.

- section 5.4/5.5: These will also need to address the capabilities
                   advertisement for the metadata properties and
                   logging fields.

thanx.

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Monday, June 16, 2014 2:57 AM
To: [email-masked]
Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

Hi all,

As you can see, I've just submitted the post-WGLC version of the URI Signing draft as draft-ietf-uri-signing-00.

We've addressed the comments received during WGLC from Ben and Iuniana, as well as minor editorial work.

We plan to publish another new revision before the Toronto deadline that will mostly address the Metadata and IANA considerations sections.

Best regards,

Ray

Begin forwarded message:
From: <[email-masked]<mailto:[email-masked]>>
Date: 16 juni 2014 08:40:06 CEST
To: Ray van Brandenburg <[email-masked]<mailto:[email-masked]>>, Michel Fisher <[email-masked]<mailto:[email-masked]>>, Kent Leung <[email-masked]<mailto:[email-masked]>>, Bill Downey <[email-masked]<mailto:[email-masked]>>, Michel Fisher <[email-masked]<mailto:[email-masked]>>, Bill Downey <[email-masked]<mailto:[email-masked]>>, Kent Leung <[email-masked]<mailto:[email-masked]>>, "Francois Le Faucheur" <[email-masked]<mailto:[email-masked]>>, Ray van Brandenburg <[email-masked]<mailto:[email-masked]>>, Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

A new version of I-D, draft-ietf-cdni-uri-signing-00.txt
has been successfully submitted by Ray van Brandenburg and posted to the
IETF repository.

Name:        draft-ietf-cdni-uri-signing
Revision:    00
Title:        URI Signing for CDN Interconnection (CDNI)
Document date:    2014-06-15
Group:        cdni
Pages:        35
URL:            http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-signing-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00

Abstract:
  This document describes how the concept of URI signing supports the
  content access control requirements of CDNI and proposes a 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 requests for the content referenced by the URI.  Some
  of the information may be accessed by the CDN via configuration or
  CDNI metadata.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

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: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 22 Jul 2014 22:12:43 +0000

Hi Kevin. Thanks for your feedback on the new draft. See comments below.

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma J
Sent: Tuesday, July 22, 2014 1:53 PM
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

Hi Ray et al,

KL> OK.

KL> Right, it may be theoretically possible to inject something or munge the Signed URI that results in the same hash value. But the challenge is that the changed URI still needs to be useful to grab unauthorized content. So, it seems mostly impossible from the practical perspective to achieve gaining access to unauthorized content by inserting attributes in front of the URI Signing package attribute. This is a generic issue for security methods such as message digest, hash, etc. Are you pointing out the issue with the wording? Or that we should have a length value to prevent insertion? Though this does not prevent someone from changing the protected parts to result in the same hash value. In this case, the likelihood of anything useful is almost zero.

KL> There is a processing cost to validating the URI Signature. If the Client IP is not allowed or time expired, then there's not much value in authenticating the Signed URI. We can let implementation determine what's best in terms of performance and capacity. If an attacker can change or generate Signed URI, it will cause some extra processing on the Surrogate. How much is the cost depends on the types of bad Signed URI and the implementation. So, being specific on implementation would be helpful to an attacker to cause the most damage. I understand your point from the conformance perspective for interoperability. Having said all that, I'm open to specifying the ordering of the logic for Signed URI authentication, IE validation, and delivery policy enforcement. Others' comments?

KL> An attacker can just change a bit in the query string too. There are many ways an attacker can do which would result in failed authentication.

KL> Not sure that will help. If the entire URL is put into the package, but the attacker adds or munges the attributes before the package, then we would need to match the received URL with the decoded URL. Why not just assume that the received URL is the same as the decoded URL and validate that? Maybe we should take it offline to discuss more ...

KL> Maybe it's good to point these out in that section.

KL> Do you mean the text should include the example as indicated by "e.g."? Sure.

KL> OK

KL> Right. We should update this section with the default for each metadata.

KL> OK. Will need some help with that. Thanks for volunteering. :)

KL> Yes, to be discussed in tomorrow's meeting.

Kent

thanx.

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Monday, June 16, 2014 2:57 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

Hi all,

Best regards,

Ray

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 22 Jul 2014 22:32:01 +0000

Hi Kent,

  We can discuss more tomorrow, but mostly I think we could just clarify the text
  to explicitly state assumptions or tradeoffs that are being made and any security
  implications of those assumptions/tradeoffs.

  In general, the ability of an attacker to change any URL (signed or not) allows
  them to deny service.  URI signing could prevent an attacker from substituting
 alternate content by denying access instead?  Should there be a more general
  discussion of what URI signing is and isn't?

thanx!

--  Kevin J. Ma

From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: Tuesday, July 22, 2014 6:13 PM
To: Kevin Ma J; Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma J
Sent: Tuesday, July 22, 2014 1:53 PM
To: Brandenburg, R. (Ray) van; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt

Hi Ray et al,

KL> OK.

KL> OK

Kent

thanx.

--  Kevin J. Ma

Hi all,

Best regards,

Ray

Begin forwarded message:

Abstract:

The IETF Secretariat