Subject: [secdir] SecDir review of draft-ietf-cdni-metadata-18

From: Zhang Dacheng <[email-masked]>
Date: Fri, 24 Jun 2016 09:45:46 +0000

Hi,
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.This document defines the CDNI metadata interface which enables a CDN to obtain CDNI metadata from another one.
There are some issues which should be further discussed before publishing the memo.
1. The title of Section 8.1 is Authentication, but the contents are all about unauthorized access to metadata. Maybe you could say something like ‘if an attacker can impersonate a legal CDN without being detected, it is able to…’
2. There is a big overlap between section 8.2, Confidentiality and section 8.4, Privacy. I suggest to merge these two sections.
3.In section 8.3, you mentioned, ” An implementation of the CDNI metadata interface MUST use strong encryption and mutual authentication to prevent undetectable modification of metadata (see Section 8.5).” Normally, when discussing about integrity protection, we prefer to use MAC rather than encryption.
4. In section 8.5, there is a statement about using TLS to provide authorization. I don’t think TLS can decide which meta-data can be sent/processed by a CDN.
5. In section 4.2.1.1, it is sated that by default no authentication needs to be provided when requesting content from a source. Do you assume the source will work in a secure environment?

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 27 Jun 2016 04:06:46 +0000

Hi Dacheng,

  Thank you for the review.
  1-3. We will update the text in the next revision.
  4. I think the thought was that once authenticated, and assuming that dCDNs have access to all metadata accessible from that HostIndex, then the dCDN is authorized to retrieve the metadata; we did not try to differentiate authorization of different metadata in the tree.  Do you think it would be best to just remove that bullet, or try to clarify the text?
  5. The Source metadata tells the dCDN from where it may acquire the content that it is going to distribute.  Generally, content delivery is not necessarily authenticated.  The dCDN is likely just pulling the content from a uCDN cache, and thus would have whatever authentication policy is set there (which could be none).  The CDNI delivery authentication mechanism is being defined in draft-ietf-cdni-uri-signing.  If desired, the URI Signing object could be added.  If URI Signing is required by the content owner, the CDNs are required to maintain it; but if the content owner doesn't care (e.g., the asset is not valuable), and the uCDN doesn't care (e.g., there is no DoS concern), then the content can be sent unauthenticated, regardless of the security of the environment.

thanx!

--  Kevin J. Ma

From: Zhang Dacheng [mailto:[email-masked]]
Sent: Friday, June 24, 2016 5:46 AM
To: The IESG; [email-masked]
Cc: [email-masked]
Subject: SecDir review of draft-ietf-cdni-metadata-18

Hi,