draft-ietf-cdni-uri-signing-15.txt   draft-ietf-cdni-uri-signing-16.txt 
CDNI R. van Brandenburg CDNI R. van Brandenburg
Internet-Draft Tiledmedia Internet-Draft Tiledmedia
Intended status: Standards Track K. Leung Intended status: Standards Track K. Leung
Expires: April 25, 2019 Cisco Systems, Inc. Expires: April 26, 2019 Cisco Systems, Inc.
P. Sorber P. Sorber
Apple, Inc. Apple, Inc.
October 22, 2018 October 23, 2018
URI Signing for CDN Interconnection (CDNI) URI Signing for CDN Interconnection (CDNI)
draft-ietf-cdni-uri-signing-15 draft-ietf-cdni-uri-signing-16
Abstract Abstract
This document describes how the concept of URI signing supports the This document describes how the concept of URI signing supports the
content access control requirements of CDNI and proposes a URI content access control requirements of CDNI and proposes a URI
signing method as a JSON Web Token (JWT) [RFC7519] profile. signing method as a JSON Web Token (JWT) [RFC7519] profile.
The proposed URI signing method specifies the information needed to The proposed URI signing method specifies the information needed to
be included in the URI to transmit the signed JWT as well as the be included in the URI to transmit the signed JWT as well as the
claims needed by the signed JWT to authorize a UA. The mechanism claims needed by the signed JWT to authorize a UA. The mechanism
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27 6.1. CDNI Payload Type . . . . . . . . . . . . . . . . . . . . 27
6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28 6.1.1. CDNI UriSigning Payload Type . . . . . . . . . . . . 28
6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28 6.2. CDNI Logging Record Type . . . . . . . . . . . . . . . . 28
6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28 6.2.1. CDNI Logging Record Version 2 for HTTP . . . . . . . 28
6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28 6.3. CDNI Logging Field Names . . . . . . . . . . . . . . . . 28
6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29 6.4. CDNI URI Signing Signed Token Transport . . . . . . . . . 29
6.5. JSON Web Token Claims Registration . . . . . . . . . . . 29 6.5. JSON Web Token Claims Registration . . . . . . . . . . . 29
6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 29 6.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35 Appendix A. Signed URI Package Example . . . . . . . . . . . . . 35
A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36 A.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 36
A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 36 A.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 37
A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 37 A.3. Signed Token Renewal Example . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of redirection used to provide access authorization in the case of redirection
between interconnected CDNs (CDNI) and between a Content Service between interconnected CDNs (CDNI) and between a Content Service
Provider (CSP) and a CDN. The primary goal of URI Signing is to make Provider (CSP) and a CDN. The primary goal of URI Signing is to make
sure that only authorized User Agents (UAs) are able to access the sure that only authorized User Agents (UAs) are able to access the
content, with a CSP being able to authorize every individual request. content, with a CSP being able to authorize every individual request.
It should be noted that URI Signing is not a content protection It should be noted that URI Signing is not a content protection
skipping to change at page 14, line 29 skipping to change at page 14, line 29
2.1.14. CDNI Signed Token Depth (cdnistd) claim 2.1.14. CDNI Signed Token Depth (cdnistd) claim
CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token
Depth (cdnistd) claim is used to associate a subsequent signed JWT Depth (cdnistd) claim is used to associate a subsequent signed JWT
generated as the result of a CDNI Signed Token Transport claim with a generated as the result of a CDNI Signed Token Transport claim with a
specific URI subset. Its type is a JSON integer. Signed JWTs MUST specific URI subset. Its type is a JSON integer. Signed JWTs MUST
NOT use a negative value for the CDNI Signed Token Depth claim. NOT use a negative value for the CDNI Signed Token Depth claim.
If the transport used for Signed Token Transport allows the CDN to If the transport used for Signed Token Transport allows the CDN to
associate the path component of a URI with tokens, the CDNI Signed associate the path component of a URI with tokens (e.g., an HTTP
Token Depth value is the number of path segments that should be Cookie Path as described in section 4.1.2.4 of [RFC6265]), the CDNI
considered significant for this association. A CDNI Signed Token Signed Token Depth value is the number of path segments that should
be considered significant for this association. A CDNI Signed Token
Depth of zero means that the client SHOULD be directed to return the Depth of zero means that the client SHOULD be directed to return the
token with requests for any path. If the CDNI Signed Token Depth is token with requests for any path. If the CDNI Signed Token Depth is
greater than zero, then the client SHOULD be directed to return the greater than zero, then the client SHOULD be directed to return the
token for future requests wherein the first CDNI Signed Token Depth token for future requests wherein the first CDNI Signed Token Depth
segments of the path match the first CDNI Signed Token Depth segments segments of the path match the first CDNI Signed Token Depth segments
of the signed URI path. This matching MUST use the URI with the of the signed URI path. This matching MUST use the URI with the
token removed, as specified in Section 2.1.15. token removed, as specified in Section 2.1.15.
If the URI path to match contains fewer segments than the CDNI Signed If the URI path to match contains fewer segments than the CDNI Signed
Token Depth claim, a signed JWT MUST NOT be generated for the Token Depth claim, a signed JWT MUST NOT be generated for the
skipping to change at page 17, line 34 skipping to change at page 17, line 34
In order for this renewal of signed JWTs to work, it is necessary for In order for this renewal of signed JWTs to work, it is necessary for
a UA to extract the signed JWT from the HTTP 2xx Successful message a UA to extract the signed JWT from the HTTP 2xx Successful message
of an earlier request and use it to retrieve the next segment. The of an earlier request and use it to retrieve the next segment. The
exact mechanism by which the client does this depends on the exact exact mechanism by which the client does this depends on the exact
segmented protocol and since this document is only concerned with the segmented protocol and since this document is only concerned with the
generation and validation of incoming request, this process is generation and validation of incoming request, this process is
outside the scope of this document. However, in order to also outside the scope of this document. However, in order to also
support legacy UAs that do not include any specific provisions for support legacy UAs that do not include any specific provisions for
the handling of signed JWTs, the folowing section defines a mechanism the handling of signed JWTs, the folowing section defines a mechanism
using HTTP Cookies that allows such UAs to support the concept of using HTTP Cookies [RFC6265] that allows such UAs to support the
renewing signed JWTs without requiring any support on the UA side. concept of renewing signed JWTs without requiring any support on the
UA side.
3.2.1. Required Claims 3.2.1. Required Claims
The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12)
MUST both be present to utilize Signed token Renewal. Either one MUST both be present to utilize Signed token Renewal. Either one
MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean MUST NOT appear alone. You MAY set cdnistt to a value of '0' to mean
no Signed Token Renewal, but you still MUST have a corresponding no Signed Token Renewal, but you still MUST have a corresponding
cdniets that validates as a JSON number. However, if you do not want cdniets that validates as a JSON number. However, if you do not want
to use Signed Token Renewal, it is RECOMMENDED to simply omit both. to use Signed Token Renewal, it is RECOMMENDED to simply omit both.
skipping to change at page 30, line 31 skipping to change at page 30, line 31
o Specification Document(s): Section 2.1.12 of [[ this specification o Specification Document(s): Section 2.1.12 of [[ this specification
]] ]]
o Claim Name: "cdnistt" o Claim Name: "cdnistt"
o Claim Description: CDNI Signed Token Transport Method for Signed o Claim Description: CDNI Signed Token Transport Method for Signed
Token Renewal Token Renewal
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.1.13 of [[ this specification o Specification Document(s): Section 2.1.13 of [[ this specification
]] ]]
o Claim Name: "cdnistd"
o Claim Description: CDNI Signed Token Depth
o Change Controller: IESG
o Specification Document(s): Section 2.1.14 of [[ this specification
]]
7. Security Considerations 7. Security Considerations
This document describes the concept of URI Signing and how it can be This document describes the concept of URI Signing and how it can be
used to provide access authorization in the case of CDNI. The used to provide access authorization in the case of CDNI. The
primary goal of URI Signing is to make sure that only authorized UAs primary goal of URI Signing is to make sure that only authorized UAs
are able to access the content, with a CSP being able to authorize are able to access the content, with a CSP being able to authorize
every individual request. It should be noted that URI Signing is not every individual request. It should be noted that URI Signing is not
a content protection scheme; if a CSP wants to protect the content a content protection scheme; if a CSP wants to protect the content
itself, other mechanisms, such as DRM, are more appropriate. itself, other mechanisms, such as DRM, are more appropriate.
skipping to change at page 34, line 10 skipping to change at page 34, line 15
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <https://www.rfc-editor.org/info/rfc6707>. 2012, <https://www.rfc-editor.org/info/rfc6707>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., [RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F.,
and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection (CDNI)", Content Distribution Network Interconnection (CDNI)",
RFC 6983, DOI 10.17487/RFC6983, July 2013, RFC 6983, DOI 10.17487/RFC6983, July 2013,
<https://www.rfc-editor.org/info/rfc6983>. <https://www.rfc-editor.org/info/rfc6983>.
 End of changes. 10 change blocks. 
13 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/