Skip to main content

Liaison statement
Response to request for information on URI Signing 2015-11-02

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2015-12-30
From Group cdni
From Contact Kevin J. Ma
To Group ISO-IEC-JTC1-SC29
To Contacts Watanabe Shinji <watanabe@itscj.ipsj.or.jp>
Cc Barry Leiba <barryleiba@computer.org>
Ben Campbell <ben@nostrum.com>
Content Delivery Networks Interconnection Discussion List <cdni@ietf.org>
Alissa Cooper <alissa@cooperw.in>
Francois Le Faucheur <flefauch@cisco.com>
Kevin Ma <kevin.j.ma@ericsson.com>
Stephan Wenger <stewe@stewe.org>
Response Contact Kevin Ma <kevin.j.ma@ericsson.com>
Francois Le Faucheur <flefauch@cisco.com>
Technical Contact Ray van Brandenburg <ray.vanbrandenburg@tno.nl>
Purpose In response
Attachments (None)
Liaisons referred by this one Liaison Statement to IETF on URI signing
Liaisons referring to this one Response to liaison Statement on URI Signing 2015-12-30
Body
The IETF CDNI working group would like to acknowledge our receipt of the MPEG
experts liaison letter and careful consideration during the 94th IETF meeting.

Having reviewed the Online Multimedia Authorization Protocol Version 1.0
(OMAPv1) specification [2012_09_28_OATC-OMAP_1-0], we understand the proposed
scope of usage for CDNI URI Signing to be the only as the Access Token, as
returned by the authorization server in step (E) of sections 2.3 and 2.4 of the
OMAPv1 specification, to be use solely for authorizing requests to the resource
server (i.e., the CDN), as described in steps (F) and (G) of sections 2.3 and
2.4 of the OMAPv1 specification.  We agree that this is an exemplary use case
for CDNI URI Signing with the Path Pattern Information Element.

At the 93rd IETF, the CDNI working group decided to remove text related to
signing of segmented content URIs from the CDNI URI Signing draft
[draft-ietf-cdni-uri-signing] in response to an IPR disclosure made after the
92nd IETF [minutes-93-cdni]. The removed sections are currently documented in a
separate draft [draft-brandenburg-cdni-uri-signing-for-has], as an extension to
the CDNI URI signing draft [draft-ietf-cdni-uri-signing]. It should be noted
that at this point, that document is regarded as an individual submission and
the CDNI working group has not made a decision regarding its future status. At
the 94th IETF, it was agreed that the Path Pattern Information element was not
covered by the IPR disclosure and would be a useful feature for a number of URI
Signing use cases, including segmented content [minutes-94-cdni]. Path Pattern
support will be reinstated in a future revision of the CDNI URI signing draft
[draft-ietf-cdni-uri-signing].

With respect to long-lived tokens, as mentioned in the Security Considerations
section (9) of the CDNI URI Signing draft, increasing the token validity period
increases the potential for replay attacks, including DoS attacks; however,
nothing in the protocol prevents the use of long-lived tokens.

With respect to CDNs refreshing tokens, the CDNI working group discussed
mechanisms for signaling token refresh between CDNs and felt that the required
additional complexity of such a mechanism outweighed the cost of regenerating
the tokens. Note: Signaling between CDNs and clients is out-of-scope for CDNI.
As mentioned above, chained token support was removed from the CDNI URI Signing
draft [draft-ietf-cdni-uri-signing] and there is no plan to reinstate it in the
CDNI URI signing draft [draft-ietf-cdni-uri-signing] due to IPR issues. As
such, the topic of token regeneration is limited to the extension draft
[draft-brandenburg-cdni-uri-signing-for-has].

With respect to name collisions, the current version of the CDNI URI Signing
draft [draft-ietf-cdni-uri-signing] only supports query-string-based conveyance
of the token.  The metadata element "package-attribute" was introduced to allow
content service providers (CSPs) to select any query string parameter name they
wanted, assuming that CSPs would be in the best position to select a
low-collision-probability name; URISigningPackage is only the default name.

With respect to consecutive tokens, the CDNI URI Signing mechanism was designed
to be stateless, so that consecutive tokens can be retrieved from different
delivery nodes. As such, there is no relationship between consecutive tokens
and token invalidation is solely based on the Expiry Time information element.

The CDNI working group appreciates the MPEG experts' thoughtful input and looks
forward to continued collaboration with MPEG experts on URI Signing.

Our next meeting: IETF 95, April 3-8 2016, Buenos Aires, Argentina

[2012_09_28_OATC-OMAP_1-0]
http://www.oatc.us/Portals/_default/Knowledgebase/1/2012_09_28_OATC-OMAP_1-0.pdf
[draft-ietf-cdni-uri-signing]
https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/
[draft-brandenburg-cdni-uri-signing-for-has]
https://datatracker.ietf.org/doc/draft-brandenburg-cdni-uri-signing-for-has/
[minutes-93-cdni] https://www.ietf.org/proceedings/93/minutes/minutes-93-cdni
[minutes-94-cdni] https://www.ietf.org/proceedings/94/minutes/minutes-94-cdni