< draft-wood-icnrg-clean-00.txt   draft-wood-icnrg-clean-01.txt >
icnrg C. Wood icnrg C. Wood
Internet-Draft University of California Irvine Internet-Draft University of California Irvine
Intended status: Experimental March 13, 2017 Intended status: Informational September 12, 2017
Expires: September 14, 2017 Expires: March 16, 2018
Content-Locked Encryption and Authentication of Nameless Objects Content-Locked Encryption and Authentication of Nameless Objects
draft-wood-icnrg-clean-00 draft-wood-icnrg-clean-01
Abstract Abstract
This document specifies CCNx CLEAN - content-locked encryption and This document specifies CCNx CLEAN - content-locked encryption and
authentication of nameless objects - as a way of enabling encrypted authentication of nameless objects. CLEAN describes how to
and naturally de-duplicated content in CCN. CLEAN allows producers transparently encrypt content objects in FLIC Manifests
to encrypt large collections of static data and use the FLIC Manifest [I-D.irtf-icnrg-flic]. Relevant decryption information is carried in
to convey the necessary decryption information to consumers. As a native FLIC nodes, i.e., without any extensions or modifications to
result, CLEAN encrypts nameless content objects without any FLIC. CLEAN transparently encrypts public data and supports
application input. application-specific configuration for private data.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 14, 2017. This Internet-Draft will expire on March 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. CLEAN Crypto . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CLEAN Crypto . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CLEAN End Host Support . . . . . . . . . . . . . . . . . . . 4 3. CLEAN Construction . . . . . . . . . . . . . . . . . . . . . 3
4. FLIC Support . . . . . . . . . . . . . . . . . . . . . . . . 4 4. CLEAN Publishing and Fetching . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. FLIC Support . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5 6.1. Public Data . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Private Data . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
In CCN, nameless objects are content objects which do not carry a In CCN, nameless objects are content objects which do not carry a
Name TLV field [CCNxSemantics]. Matching an interest to a nameless Name TLV field. Thus, a necessary requisite to retrieve them from
content object therefore requires knowledge of the latter's the network is to know their respective ContentObjectHashRestriction,
ContentObjectHash (or ContentId). A ContentId is the cryptographic or ContentId. A ContentId is the cryptographic hash of a content
hash of a Content Object message. A router may only forward a object [I-D.irtf-icnrg-ccnxsemantics]. A router may only forward a
nameless content object if its cryptographic hash digest matches that nameless content object if its cryptographic hash digest matches the
which is specified in the ContentObjectHashRestriction of the ContentId of the corresponding interest.
corresponding interest.
Manifests are network-level structures used to convey ContentIds to By definition, a consumer cannot (with overwhelming probability)
consumers so that they may request nameless content objects. These request a nameless content object without knowledge of its ContentId.
are necessary since a consumer cannot know the ContentId of a Manifests are network-level structures that convey ContentIds to
nameless content object which it has not yet retrieved. Manifests consumers. FLIC Manifests [I-D.irtf-icnrg-flic] are one type of
are typically used to group segments of a single, large piece of data Manifest structure. Manifests typically group segments of a large
under a common name. For example, imagine the consumer wishes to piece of data under a common name. For example, suppose there exists
obtain the data named /foo/bar, which has a total size well beyond a content with the name /foo/bar, which has a total size beyond the
the 64KiB limit imposed by the CCN packet format. To transfer /foo/ 64KB limit imposed by the CCN packet [I-D.irtf-icnrg-ccnxmessages].
bar efficiently, the producer segments the /foo/bar data into fixed The producer of /foo/bar can segment the data into fixed size chunks
size chunks and, for each chunk, creates a nameless content object. and, for each chunk, create a nameless content object whose payload
is the chunk. Then, the producer may create a Manifest with the name
/foo/bar which contains the references to each of these constituent
nameless object parts. To fetch /foo/bar, a consumer then does the
following:
Then, the producer creates a Manifest with the name /foo/bar which 1. Issue an interest for the name /foo/bar.
contains the references to each of these constituent nameless object
parts, along with their ContentIds. To fetch /foo/bar, a consumer 2. Receive, verify, and parse the Manifest.
then (a) issues a request for the name /foo/bar, (b) receives,
verifies, and parses the Manifest, and (c) subsequently issues 3. Issue requests for each nameless content object using the
requests for each nameless content object using the provided provided ContentIds.
ContentIds. (See [CCNxSemantics] for more details.) The [FLIC] data
structure is one type of CCN Manifest data structure used to enable (See [I-D.irtf-icnrg-ccnxsemantics] for more details.)
this mechanism.
By default, the data contained inside each nameless content object is By default, the data contained inside each nameless content object is
unencrypted. If privacy is required, the producer application must unencrypted. If confidentiality is required, producers must
explicitly encrypt the data prior to transfer. This is not ideal explicitly encrypt data prior to FLIC encoding. This arrangement is
since it requires application-layer input. To improve this baseline not ideal. By default, all data should be encrypted, even if it is
scenario, we introduce CCNx CLEAN - content-locked encryption and public. CLEAN - content-locked encryption and authentication of
authentication of nameless objects. CLEAN builds on recent advances nameless objects - is a mechanism that achieves this goal. CLEAN
in message-locked encryption ([MLE]) to encrypt nameless objects by builds on recent advances in message-locked encryption ([MLE]) to
default without invalidating their natural de-duplication properties. encrypt nameless objects by default without invalidating their
natural de-duplication properties.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
The following terms are used: The following terms are used:
Nameless object: A CCN content object packet which contain a Name TLV Nameless object: A CCN content object packet which contain a Name TLV
field. field.
CLEAN collection: A manifest tree encrypted via CLEAN.
2. CLEAN Crypto 2. CLEAN Crypto
CLEAN only relies on MLE, which is a form of encryption by which the CLEAN only relies on MLE, which is a form of encryption by which the
encryption key for a message is derived from the message itself. For encryption key for a message is derived from the message itself. For
example, in MLE, a message M may be encrypted by a key K = H(M), example, a message M may be encrypted by a key k = H(M), where H is a
where H is a suitable cryptographic hash function for use in MLE suitable cryptographic hash function for use in MLE constructions.
constructions. The encryption of M is thus computed as M' = (See [MLE] for more details.) The encryption of M is then computed
Enc(H(M), M), where Enc is a symmetric-key encryption algorithm as M' = Enc(k, M), where Enc is a symmetric-key encryption algorithm
suitable for MLE. This procedure is deterministic; two identical suitable for MLE.
messages will be encrypted to identical ciphertext values. As a
result, MLE supports natural de-duplication of data based on
ciphertext equality.
3. CLEAN End Host Support MLE is deterministic. Identical messages will be encrypted to
identical ciphertexts. As a result, MLE supports natural de-
duplication of data based on ciphertext equality.
3. CLEAN Construction
Let D be a piece of data for which a producer P would normally create Let D be a piece of data for which a producer P would normally create
a Manifest with name N, i.e., M(N). Let C_1,...,C_n be the n a Manifest with name N. Let C_1,...,C_n be n nameless content
nameless content object _payloads_ created from D. The CLEAN objects created from D. That is, each C_i contains D_i, the i-th
construction works as follows: chunk of D. See [I-D.irtf-icnrg-flic] for more details about this
chunking procedure.
1. P computes k = KDF(H(D)), where KDF is a suitable key derivation CLEAN works as follows:
function, such as HKDF [RFC5869].
2. For each C_i in C_1,...,C_n, P derives k_i = KDF(k + i) uses it 1. P computes k = KDF(ctx, H(D)), where KDF is any suitable key
to compute C_i' = Enc(k, C_i), where '+' is concatenation. derivation function, e.g., HKDF [RFC5869], and ctx is an
application context string for the KDF. By default, ctx is an
empty string, meaning that k = KDF(H(D)).
3. From C_1',...,C_n', P creates the manifest M(N) as per the [FLIC] 2. For each C_i in C_1,...,C_n, P derives k_i = KDF(k || i) and uses
specification. it to compute C_i' = Enc(k, C_i). Encryption is only performed
over the payload of the content, not the headers.
3. From C_1',...,C_n', P creates the manifest M(N) as described in
[I-D.irtf-icnrg-flic].
4. P inserts H(D) into the root node of M(N). (This is described in 4. P inserts H(D) into the root node of M(N). (This is described in
the following section.) Section Section 5.)
When complete, P publishes the manifest tree M(N) and its constituent The context string "ctx" is used to scope the CLEAN encryption to an
nameless object pieces. application-specific context. By default, there is no context, as
data is assumed to be public. This means that different producers
generating the same content with an empty context will create the
same encrypted content objects and, potentially, the same manifest
tree.
4. FLIC Support This may not always be desirable. To constrain the context of a
CLEAN collection, applications may opt-in to CLEAN and specify
encryption contexts. To prevent an attacker from hijacking interests
for CLEAN objects, or from creating duplicate content objects, these
contexts must be secret to the producer. We describe several
candidate contexts below:
The [FLIC] format already includes the metadata value - H(r), where r is a random 32B string.
OverallDataDigest. For a given FLIC node F_i, this value corresponds
to H(D_i), where D_i is the array of application data in the nameless
content objects _contained in_ F_i. If F is the root of M(N), then
H(D) is the hash of complete set of application data in the manifest.
Therefore, CLEAN does not require any changes in the FLIC format.
5. Use Cases - H(sk), where sk is a long-term secret key kept by the producer.
Since the data digest (i.e., H(D)) is contained in the root manifest, The context string must be transferred to the consumer so as to
the privacy of nameless content objects reduces to that of the root derive the same encryption key. We describe how to do this in
manifest. This has the following benefits: Section Section 5.
1. If access control to D is needed, P need only apply the necessary 4. CLEAN Publishing and Fetching
access control scheme to the root manifest so that H(D) is not
leaked. This permits the encrypted nameless object leaves to be
de-duplicated naturally in the network.
2. If D is public data that a consumer Cr wishes to retrieve There are at least three steps in the CLEAN publishing process, drawn
privately, the root manifest can be requested over a secure, below and labelled for clarity:
ephemeral session between Cr and P. One way to establish such a
channel is with [CCNxKE]. Of course, if D is public, then any
malicious consumer Adv may follow this approach to obtain D and
decrypt nameless objects, or learn what data was requested by
other consumers. However, Adv is forced to guess which name N
was requested to be successful in either attack.
In both cases, the nameless content objects that carry segments of D +--------+
remain protected without applying any type of encryption-based access +------------> Repo-1 <-------------+
control to them individually. | +--------+ |
| (3) (1) |
| +--------+ |
+------------> Repo-2 <-------------+
| +--------+ |
| |
+-------+ |
| Adv-1 | |
+-------+ |
| (2) |
+----+-----+ +-------+ +-----+----+
| Consumer <------| Adv-2 |--------> Producer |
+----------+ +-------+ +----------+
6. Security Considerations 1) The producer creates the CLEAN collection and, optionally, uploads
the CLEAN contents, without the root manifest, to dedicated content
repositories. 2) A consumer fetches the root manifest from the
producer. 3) A consumer proceeds to fetch the rest of the CLEAN
collection from either the producer or the dedicated repositories.
If an eavesdropper only sees traffic from the consumer to the
repository, then CLEAN keeps this data safe. If an eavesdropper can
also see traffic from the consumer to the producer, then it can learn
the necessary information required to decrypt the traffic.
Therefore, to ensure safety, consumers SHOULD always fetch the root
manifest over a secure session. We expand on this point in
Section Section 6.1.
5. FLIC Support
Consumers require two pieces of information to decrypt a CLEAN
collection: "H(D)" and "ctx". The [I-D.irtf-icnrg-flic] format
already includes the metadata value OverallDataDigest. For a given
FLIC node N, this value corresponds to H(D), where D is the
contiguous set of application data in the nameless content objects
contained in N. Carrying "ctx" requires an extension to FLIC with
the type "clean_context".
6. Use Cases
This section describes how to use CLEAN to protect public and private
data. Private data is that which must be kept confidential, i.e., it
requires some form of access control. Public data can be freely
accessed by anyone.
6.1. Public Data
Since public data requires no access control, applications need not
provide a CLEAN context string. By definition, anyone should be able
to access public data. CLEAN is still useful in this case since it
requires an eavesdropper to fetch the root manifest in order to
decrypt the leaves. Simply observing the request and response for an
encrypted CLEAN object - not the root manifest - in transit does not
reveal the necessary information to decrypt the response. Consumers
may choose to fetch the root manifest over a secure session, such as
that enabled by [I-D.wood-icnrg-ccnxkeyexchange] and
[I-D.wood-icnrg-esic], to prevent leaking the necessary decryption
information.
6.2. Private Data
Private data requires access control. In this case, applications
MUST provide a secret context string to the CLEAN encryption
algorithm. This prevents another (malicious) producer from
generating the same set of CLEAN objects. Moreover, it must be
assumed that all traffic can be observed in transit. Thus, the root
manifest MUST be protected either at rest by encryption-based access
control or in transit with a secure session, i.e., with
[I-D.wood-icnrg-esic] bootstrapped by
[I-D.wood-icnrg-ccnxkeyexchange].
7. Security Considerations
The CLEAN security model depends on the root manifest being protected The CLEAN security model depends on the root manifest being protected
either at rest or, optionally, in transit. If the root is protected either at rest or, optionally, in transit. If the root is protected
at rest via some access control mechanism, then CLEAN remains secure at rest via some access control mechanism, then CLEAN remains secure
in the MLE model. MLE security also holds if the root is encrypted in the MLE model. MLE security also holds if the root is encrypted
only in transit over a secure session. only in transit over a secure session, i.e., with
[I-D.wood-icnrg-esic] using a key bootstrapped by
[I-D.wood-icnrg-ccnxkeyexchange]. See [TRAPS] for more details about
this analysis.
7. Normative References 8. Normative References
[CCNxKE] Marc Mosko, ., Ersin Uzun, ., and Christopher. Wood, "CCNx [I-D.irtf-icnrg-ccnxmessages]
Key Exchange Protocol Version 1.0", n.d., Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
<https://datatracker.ietf.org/doc/draft-wood-icnrg- Format", draft-irtf-icnrg-ccnxmessages-04 (work in
ccnxkeyexchange/>. progress), March 2017.
[CCNxSemantics] [I-D.irtf-icnrg-ccnxsemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", n.d., Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
<https://tools.ietf.org/html/draft-irtf-icnrg- draft-irtf-icnrg-ccnxsemantics-04 (work in progress),
ccnxsemantics-04>. March 2017.
[FLIC] Christian Tschudin, . and Christopher. Wood, "File-Like [I-D.irtf-icnrg-flic]
ICN Collection (FLIC)", n.d., Tschudin, C. and C. Wood, "File-Like ICN Collection
<https://datatracker.ietf.org/doc/draft-tschudin-icnrg- (FLIC)", draft-irtf-icnrg-flic-00 (work in progress), June
flic/>. 2017.
[I-D.wood-icnrg-ccnxkeyexchange]
Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02
(work in progress), July 2017.
[I-D.wood-icnrg-esic]
Mosko, M. and C. Wood, "Encrypted Sessions In CCNx
(ESIC)", draft-wood-icnrg-esic-00 (work in progress),
March 2017.
[MLE] Mihir Bellare, ., Sriram Keelveedhi, ., and . Thomas [MLE] Mihir Bellare, ., Sriram Keelveedhi, ., and . Thomas
Ristenpart, "Message-locked encryption and secure Ristenpart, "Message-locked encryption and secure
deduplication", n.d., deduplication", n.d.,
<https://eprint.iacr.org/2012/631.pdf>. <https://eprint.iacr.org/2012/631.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5869>. editor.org/info/rfc5869>.
[TRAPS] Wood, Christopher., "Protecting the Long Tail: Transparent
Packet Security in Content-Centric Networks", n.d..
Author's Address Author's Address
Christopher A. Wood Christopher A. Wood
University of California Irvine University of California Irvine
EMail: woodc1@uci.edu EMail: woodc1@uci.edu
 End of changes. 34 change blocks. 
127 lines changed or deleted 210 lines changed or added

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