icnrg                                                            C. Wood
Internet-Draft                           University of California Irvine
Intended status: Informational                        September 12, 2017
Expires: March 16, 2018

    Content-Locked Encryption and Authentication of Nameless Objects


   This document specifies CCNx CLEAN - content-locked encryption and
   authentication of nameless objects.  CLEAN describes how to
   transparently encrypt content objects in FLIC Manifests
   [I-D.irtf-icnrg-flic].  Relevant decryption information is carried in
   native FLIC nodes, i.e., without any extensions or modifications to
   FLIC.  CLEAN transparently encrypts public data and supports
   application-specific configuration for private data.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 16, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Wood                     Expires March 16, 2018                 [Page 1]

Internet-Draft                  CCNxCLEAN                 September 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  CLEAN Crypto  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CLEAN Construction  . . . . . . . . . . . . . . . . . . . . .   3
   4.  CLEAN Publishing and Fetching . . . . . . . . . . . . . . . .   4
   5.  FLIC Support  . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Public Data . . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  Private Data  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In CCN, nameless objects are content objects which do not carry a
   Name TLV field.  Thus, a necessary requisite to retrieve them from
   the network is to know their respective ContentObjectHashRestriction,
   or ContentId.  A ContentId is the cryptographic hash of a content
   object [I-D.irtf-icnrg-ccnxsemantics].  A router may only forward a
   nameless content object if its cryptographic hash digest matches the
   ContentId of the corresponding interest.

   By definition, a consumer cannot (with overwhelming probability)
   request a nameless content object without knowledge of its ContentId.
   Manifests are network-level structures that convey ContentIds to
   consumers.  FLIC Manifests [I-D.irtf-icnrg-flic] are one type of
   Manifest structure.  Manifests typically group segments of a large
   piece of data under a common name.  For example, suppose there exists
   a content with the name /foo/bar, which has a total size beyond the
   64KB limit imposed by the CCN packet [I-D.irtf-icnrg-ccnxmessages].
   The producer of /foo/bar can segment the data into fixed size chunks
   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

   1.  Issue an interest for the name /foo/bar.

   2.  Receive, verify, and parse the Manifest.

Wood                     Expires March 16, 2018                 [Page 2]

Internet-Draft                  CCNxCLEAN                 September 2017

   3.  Issue requests for each nameless content object using the
       provided ContentIds.

   (See [I-D.irtf-icnrg-ccnxsemantics] for more details.)

   By default, the data contained inside each nameless content object is
   unencrypted.  If confidentiality is required, producers must
   explicitly encrypt data prior to FLIC encoding.  This arrangement is
   not ideal.  By default, all data should be encrypted, even if it is
   public.  CLEAN - content-locked encryption and authentication of
   nameless objects - is a mechanism that achieves this goal.  CLEAN
   builds on recent advances in message-locked encryption ([MLE]) to
   encrypt nameless objects by default without invalidating their
   natural de-duplication properties.

1.1.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   The following terms are used:

   Nameless object: A CCN content object packet which contain a Name TLV

   CLEAN collection: A manifest tree encrypted via CLEAN.

2.  CLEAN Crypto

   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
   example, a message M may be encrypted by a key k = H(M), where H is a
   suitable cryptographic hash function for use in MLE constructions.
   (See [MLE] for more details.)  The encryption of M is then computed
   as M' = Enc(k, M), where Enc is a symmetric-key encryption algorithm
   suitable for MLE.

   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
   a Manifest with name N.  Let C_1,...,C_n be n nameless content
   objects created from D.  That is, each C_i contains D_i, the i-th

Wood                     Expires March 16, 2018                 [Page 3]

Internet-Draft                  CCNxCLEAN                 September 2017

   chunk of D.  See [I-D.irtf-icnrg-flic] for more details about this
   chunking procedure.

   CLEAN works as follows:

   1.  P computes k = KDF(ctx, H(D)), where KDF is any suitable key
       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)).

   2.  For each C_i in C_1,...,C_n, P derives k_i = KDF(k || i) and uses
       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

   4.  P inserts H(D) into the root node of M(N).  (This is described in
       Section Section 5.)

   The context string "ctx" is used to scope the CLEAN encryption to an
   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

   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:

   -  H(r), where r is a random 32B string.

   -  H(sk), where sk is a long-term secret key kept by the producer.

   The context string must be transferred to the consumer so as to
   derive the same encryption key.  We describe how to do this in
   Section Section 5.

4.  CLEAN Publishing and Fetching

   There are at least three steps in the CLEAN publishing process, drawn
   below and labelled for clarity:

Wood                     Expires March 16, 2018                 [Page 4]

Internet-Draft                  CCNxCLEAN                 September 2017

        +------------> Repo-1 <-------------+
        |            +--------+             |
        |   (3)                     (1)     |
        |            +--------+             |
        +------------> Repo-2 <-------------+
        |            +--------+             |
        |                                   |
    +-------+                               |
    | Adv-1 |                               |
    +-------+                               |
        |               (2)                 |
   +----+-----+      +-------+        +-----+----+
   | Consumer <------| Adv-2 |--------> Producer |
   +----------+      +-------+        +----------+

   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.

Wood                     Expires March 16, 2018                 [Page 5]

Internet-Draft                  CCNxCLEAN                 September 2017

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

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

7.  Security Considerations

   The CLEAN security model depends on the root manifest being protected
   either at rest or, optionally, in transit.  If the root is protected
   at rest via some access control mechanism, then CLEAN remains secure
   in the MLE model.  MLE security also holds if the root is encrypted
   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.

8.  Normative References

              Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", draft-irtf-icnrg-ccnxmessages-04 (work in
              progress), March 2017.

              Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
              draft-irtf-icnrg-ccnxsemantics-04 (work in progress),
              March 2017.

Wood                     Expires March 16, 2018                 [Page 6]

Internet-Draft                  CCNxCLEAN                 September 2017

              Tschudin, C. and C. Wood, "File-Like ICN Collection
              (FLIC)", draft-irtf-icnrg-flic-00 (work in progress), June

              Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
              Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02
              (work in progress), July 2017.

              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
              Ristenpart, "Message-locked encryption and secure
              deduplication", n.d.,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010, <https://www.rfc-

   [TRAPS]    Wood, Christopher., "Protecting the Long Tail: Transparent
              Packet Security in Content-Centric Networks", n.d..

Author's Address

   Christopher A. Wood
   University of California Irvine

   EMail: woodc1@uci.edu

Wood                     Expires March 16, 2018                 [Page 7]