idnits 2.17.1 draft-wood-icnrg-clean-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.irtf-icnrg-flic]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2017) is 2417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-04 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-00 == Outdated reference: A later version (-01) exists of draft-wood-icnrg-esic-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 icnrg C. Wood 3 Internet-Draft University of California Irvine 4 Intended status: Informational September 12, 2017 5 Expires: March 16, 2018 7 Content-Locked Encryption and Authentication of Nameless Objects 8 draft-wood-icnrg-clean-01 10 Abstract 12 This document specifies CCNx CLEAN - content-locked encryption and 13 authentication of nameless objects. CLEAN describes how to 14 transparently encrypt content objects in FLIC Manifests 15 [I-D.irtf-icnrg-flic]. Relevant decryption information is carried in 16 native FLIC nodes, i.e., without any extensions or modifications to 17 FLIC. CLEAN transparently encrypts public data and supports 18 application-specific configuration for private data. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 16, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 56 2. CLEAN Crypto . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. CLEAN Construction . . . . . . . . . . . . . . . . . . . . . 3 58 4. CLEAN Publishing and Fetching . . . . . . . . . . . . . . . . 4 59 5. FLIC Support . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. Public Data . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.2. Private Data . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 In CCN, nameless objects are content objects which do not carry a 70 Name TLV field. Thus, a necessary requisite to retrieve them from 71 the network is to know their respective ContentObjectHashRestriction, 72 or ContentId. A ContentId is the cryptographic hash of a content 73 object [I-D.irtf-icnrg-ccnxsemantics]. A router may only forward a 74 nameless content object if its cryptographic hash digest matches the 75 ContentId of the corresponding interest. 77 By definition, a consumer cannot (with overwhelming probability) 78 request a nameless content object without knowledge of its ContentId. 79 Manifests are network-level structures that convey ContentIds to 80 consumers. FLIC Manifests [I-D.irtf-icnrg-flic] are one type of 81 Manifest structure. Manifests typically group segments of a large 82 piece of data under a common name. For example, suppose there exists 83 a content with the name /foo/bar, which has a total size beyond the 84 64KB limit imposed by the CCN packet [I-D.irtf-icnrg-ccnxmessages]. 85 The producer of /foo/bar can segment the data into fixed size chunks 86 and, for each chunk, create a nameless content object whose payload 87 is the chunk. Then, the producer may create a Manifest with the name 88 /foo/bar which contains the references to each of these constituent 89 nameless object parts. To fetch /foo/bar, a consumer then does the 90 following: 92 1. Issue an interest for the name /foo/bar. 94 2. Receive, verify, and parse the Manifest. 96 3. Issue requests for each nameless content object using the 97 provided ContentIds. 99 (See [I-D.irtf-icnrg-ccnxsemantics] for more details.) 101 By default, the data contained inside each nameless content object is 102 unencrypted. If confidentiality is required, producers must 103 explicitly encrypt data prior to FLIC encoding. This arrangement is 104 not ideal. By default, all data should be encrypted, even if it is 105 public. CLEAN - content-locked encryption and authentication of 106 nameless objects - is a mechanism that achieves this goal. CLEAN 107 builds on recent advances in message-locked encryption ([MLE]) to 108 encrypt nameless objects by default without invalidating their 109 natural de-duplication properties. 111 1.1. Conventions and Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in RFC 116 2119 [RFC2119]. 118 The following terms are used: 120 Nameless object: A CCN content object packet which contain a Name TLV 121 field. 123 CLEAN collection: A manifest tree encrypted via CLEAN. 125 2. CLEAN Crypto 127 CLEAN only relies on MLE, which is a form of encryption by which the 128 encryption key for a message is derived from the message itself. For 129 example, a message M may be encrypted by a key k = H(M), where H is a 130 suitable cryptographic hash function for use in MLE constructions. 131 (See [MLE] for more details.) The encryption of M is then computed 132 as M' = Enc(k, M), where Enc is a symmetric-key encryption algorithm 133 suitable for MLE. 135 MLE is deterministic. Identical messages will be encrypted to 136 identical ciphertexts. As a result, MLE supports natural de- 137 duplication of data based on ciphertext equality. 139 3. CLEAN Construction 141 Let D be a piece of data for which a producer P would normally create 142 a Manifest with name N. Let C_1,...,C_n be n nameless content 143 objects created from D. That is, each C_i contains D_i, the i-th 144 chunk of D. See [I-D.irtf-icnrg-flic] for more details about this 145 chunking procedure. 147 CLEAN works as follows: 149 1. P computes k = KDF(ctx, H(D)), where KDF is any suitable key 150 derivation function, e.g., HKDF [RFC5869], and ctx is an 151 application context string for the KDF. By default, ctx is an 152 empty string, meaning that k = KDF(H(D)). 154 2. For each C_i in C_1,...,C_n, P derives k_i = KDF(k || i) and uses 155 it to compute C_i' = Enc(k, C_i). Encryption is only performed 156 over the payload of the content, not the headers. 158 3. From C_1',...,C_n', P creates the manifest M(N) as described in 159 [I-D.irtf-icnrg-flic]. 161 4. P inserts H(D) into the root node of M(N). (This is described in 162 Section Section 5.) 164 The context string "ctx" is used to scope the CLEAN encryption to an 165 application-specific context. By default, there is no context, as 166 data is assumed to be public. This means that different producers 167 generating the same content with an empty context will create the 168 same encrypted content objects and, potentially, the same manifest 169 tree. 171 This may not always be desirable. To constrain the context of a 172 CLEAN collection, applications may opt-in to CLEAN and specify 173 encryption contexts. To prevent an attacker from hijacking interests 174 for CLEAN objects, or from creating duplicate content objects, these 175 contexts must be secret to the producer. We describe several 176 candidate contexts below: 178 - H(r), where r is a random 32B string. 180 - H(sk), where sk is a long-term secret key kept by the producer. 182 The context string must be transferred to the consumer so as to 183 derive the same encryption key. We describe how to do this in 184 Section Section 5. 186 4. CLEAN Publishing and Fetching 188 There are at least three steps in the CLEAN publishing process, drawn 189 below and labelled for clarity: 191 +--------+ 192 +------------> Repo-1 <-------------+ 193 | +--------+ | 194 | (3) (1) | 195 | +--------+ | 196 +------------> Repo-2 <-------------+ 197 | +--------+ | 198 | | 199 +-------+ | 200 | Adv-1 | | 201 +-------+ | 202 | (2) | 203 +----+-----+ +-------+ +-----+----+ 204 | Consumer <------| Adv-2 |--------> Producer | 205 +----------+ +-------+ +----------+ 207 1) The producer creates the CLEAN collection and, optionally, uploads 208 the CLEAN contents, without the root manifest, to dedicated content 209 repositories. 2) A consumer fetches the root manifest from the 210 producer. 3) A consumer proceeds to fetch the rest of the CLEAN 211 collection from either the producer or the dedicated repositories. 213 If an eavesdropper only sees traffic from the consumer to the 214 repository, then CLEAN keeps this data safe. If an eavesdropper can 215 also see traffic from the consumer to the producer, then it can learn 216 the necessary information required to decrypt the traffic. 217 Therefore, to ensure safety, consumers SHOULD always fetch the root 218 manifest over a secure session. We expand on this point in 219 Section Section 6.1. 221 5. FLIC Support 223 Consumers require two pieces of information to decrypt a CLEAN 224 collection: "H(D)" and "ctx". The [I-D.irtf-icnrg-flic] format 225 already includes the metadata value OverallDataDigest. For a given 226 FLIC node N, this value corresponds to H(D), where D is the 227 contiguous set of application data in the nameless content objects 228 contained in N. Carrying "ctx" requires an extension to FLIC with 229 the type "clean_context". 231 6. Use Cases 233 This section describes how to use CLEAN to protect public and private 234 data. Private data is that which must be kept confidential, i.e., it 235 requires some form of access control. Public data can be freely 236 accessed by anyone. 238 6.1. Public Data 240 Since public data requires no access control, applications need not 241 provide a CLEAN context string. By definition, anyone should be able 242 to access public data. CLEAN is still useful in this case since it 243 requires an eavesdropper to fetch the root manifest in order to 244 decrypt the leaves. Simply observing the request and response for an 245 encrypted CLEAN object - not the root manifest - in transit does not 246 reveal the necessary information to decrypt the response. Consumers 247 may choose to fetch the root manifest over a secure session, such as 248 that enabled by [I-D.wood-icnrg-ccnxkeyexchange] and 249 [I-D.wood-icnrg-esic], to prevent leaking the necessary decryption 250 information. 252 6.2. Private Data 254 Private data requires access control. In this case, applications 255 MUST provide a secret context string to the CLEAN encryption 256 algorithm. This prevents another (malicious) producer from 257 generating the same set of CLEAN objects. Moreover, it must be 258 assumed that all traffic can be observed in transit. Thus, the root 259 manifest MUST be protected either at rest by encryption-based access 260 control or in transit with a secure session, i.e., with 261 [I-D.wood-icnrg-esic] bootstrapped by 262 [I-D.wood-icnrg-ccnxkeyexchange]. 264 7. Security Considerations 266 The CLEAN security model depends on the root manifest being protected 267 either at rest or, optionally, in transit. If the root is protected 268 at rest via some access control mechanism, then CLEAN remains secure 269 in the MLE model. MLE security also holds if the root is encrypted 270 only in transit over a secure session, i.e., with 271 [I-D.wood-icnrg-esic] using a key bootstrapped by 272 [I-D.wood-icnrg-ccnxkeyexchange]. See [TRAPS] for more details about 273 this analysis. 275 8. Normative References 277 [I-D.irtf-icnrg-ccnxmessages] 278 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 279 Format", draft-irtf-icnrg-ccnxmessages-04 (work in 280 progress), March 2017. 282 [I-D.irtf-icnrg-ccnxsemantics] 283 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 284 draft-irtf-icnrg-ccnxsemantics-04 (work in progress), 285 March 2017. 287 [I-D.irtf-icnrg-flic] 288 Tschudin, C. and C. Wood, "File-Like ICN Collection 289 (FLIC)", draft-irtf-icnrg-flic-00 (work in progress), June 290 2017. 292 [I-D.wood-icnrg-ccnxkeyexchange] 293 Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 294 Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02 295 (work in progress), July 2017. 297 [I-D.wood-icnrg-esic] 298 Mosko, M. and C. Wood, "Encrypted Sessions In CCNx 299 (ESIC)", draft-wood-icnrg-esic-00 (work in progress), 300 March 2017. 302 [MLE] Mihir Bellare, ., Sriram Keelveedhi, ., and . Thomas 303 Ristenpart, "Message-locked encryption and secure 304 deduplication", n.d., 305 . 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, . 312 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 313 Key Derivation Function (HKDF)", RFC 5869, 314 DOI 10.17487/RFC5869, May 2010, . 317 [TRAPS] Wood, Christopher., "Protecting the Long Tail: Transparent 318 Packet Security in Content-Centric Networks", n.d.. 320 Author's Address 322 Christopher A. Wood 323 University of California Irvine 325 EMail: woodc1@uci.edu