Content-Locked Encryption and Authentication of Nameless Objects
draft-wood-icnrg-clean-00

icnrg                                                            C. Wood
Internet-Draft                           University of California Irvine
Intended status: Experimental                             March 13, 2017
Expires: September 14, 2017

    Content-Locked Encryption and Authentication of Nameless Objects
                     draft-wood-icnrg-clean-00

Abstract

   This document specifies CCNx CLEAN - content-locked encryption and
   authentication of nameless objects - as a way of enabling encrypted
   and naturally de-duplicated content in CCN.  CLEAN allows producers
   to encrypt large collections of static data and use the FLIC Manifest
   to convey the necessary decryption information to consumers.  As a
   result, CLEAN encrypts nameless content objects without any
   application input.

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 September 14, 2017.

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 September 14, 2017               [Page 1]
Internet-Draft                  CCNxCLEAN                     March 2017

   the Trust Legal Provisions and are provided without warranty as
   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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  CLEAN Crypto  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CLEAN End Host Support  . . . . . . . . . . . . . . . . . . .   4
   4.  FLIC Support  . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In CCN, nameless objects are content objects which do not carry a
   Name TLV field [CCNxSemantics].  Matching an interest to a nameless
   content object therefore requires knowledge of the latter's
   ContentObjectHash (or ContentId).  A ContentId is the cryptographic
   hash of a Content Object message.  A router may only forward a
   nameless content object if its cryptographic hash digest matches that
   which is specified in the ContentObjectHashRestriction of the
   corresponding interest.

   Manifests are network-level structures used to convey ContentIds to
   consumers so that they may request nameless content objects.  These
   are necessary since a consumer cannot know the ContentId of a
   nameless content object which it has not yet retrieved.  Manifests
   are typically used to group segments of a single, large piece of data
   under a common name.  For example, imagine the consumer wishes to
   obtain the data named /foo/bar, which has a total size well beyond
   the 64KiB limit imposed by the CCN packet format.  To transfer /foo/
   bar efficiently, the producer segments the /foo/bar data into fixed
   size chunks and, for each chunk, creates a nameless content object.

Wood                   Expires September 14, 2017               [Page 2]
Internet-Draft                  CCNxCLEAN                     March 2017

   Then, the producer creates a Manifest with the name /foo/bar which
   contains the references to each of these constituent nameless object
   parts, along with their ContentIds.  To fetch /foo/bar, a consumer
   then (a) issues a request for the name /foo/bar, (b) receives,
   verifies, and parses the Manifest, and (c) subsequently issues
   requests for each nameless content object using the provided
   ContentIds.  (See [CCNxSemantics] for more details.)  The [FLIC] data
   structure is one type of CCN Manifest data structure used to enable
   this mechanism.

   By default, the data contained inside each nameless content object is
   unencrypted.  If privacy is required, the producer application must
   explicitly encrypt the data prior to transfer.  This is not ideal
   since it requires application-layer input.  To improve this baseline
   scenario, we introduce CCNx CLEAN - content-locked encryption and
   authentication of nameless objects.  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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "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
   field.

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, in MLE, 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.  The encryption of M is thus computed as M' =
   Enc(H(M), M), where Enc is a symmetric-key encryption algorithm
   suitable for MLE.  This procedure is deterministic; two identical
   messages will be encrypted to identical ciphertext values.  As a
   result, MLE supports natural de-duplication of data based on
   ciphertext equality.

Wood                   Expires September 14, 2017               [Page 3]
Internet-Draft                  CCNxCLEAN                     March 2017

3.  CLEAN End Host Support

   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
   nameless content object _payloads_ created from D.  The CLEAN
   construction works as follows:

   1.  P computes k = KDF(H(D)), where KDF is a suitable key derivation
       function, such as HKDF [RFC5869].

   2.  For each C_i in C_1,...,C_n, P derives k_i = KDF(k + i) uses it
       to compute C_i' = Enc(k, C_i), where '+' is concatenation.

   3.  From C_1',...,C_n', P creates the manifest M(N) as per the [FLIC]
       specification.

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

   When complete, P publishes the manifest tree M(N) and its constituent
   nameless object pieces.

4.  FLIC Support

   The [FLIC] format already includes the metadata value
   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

   Since the data digest (i.e., H(D)) is contained in the root manifest,
   the privacy of nameless content objects reduces to that of the root
   manifest.  This has the following benefits:

   1.  If access control to D is needed, P need only apply the necessary
       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
       privately, the root manifest can be requested over a secure,
       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

Wood                   Expires September 14, 2017               [Page 4]
Internet-Draft                  CCNxCLEAN                     March 2017

       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
   control to them individually.

6.  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.

7.  Normative References

   [CCNxKE]   Marc Mosko, ., Ersin Uzun, ., and Christopher. Wood, "CCNx
              Key Exchange Protocol Version 1.0", n.d.,
              <https://datatracker.ietf.org/doc/draft-wood-icnrg-
              ccnxkeyexchange/>.

   [CCNxSemantics]
              Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", n.d.,
              <https://tools.ietf.org/html/draft-irtf-icnrg-
              ccnxsemantics-04>.

   [FLIC]     Christian Tschudin, . and Christopher. Wood, "File-Like
              ICN Collection (FLIC)", n.d.,
              <https://datatracker.ietf.org/doc/draft-tschudin-icnrg-
              flic/>.

   [MLE]      Mihir Bellare, ., Sriram Keelveedhi, ., and . Thomas
              Ristenpart, "Message-locked encryption and secure
              deduplication", n.d.,
              <https://eprint.iacr.org/2012/631.pdf>.

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

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

Wood                   Expires September 14, 2017               [Page 5]
Internet-Draft                  CCNxCLEAN                     March 2017

Author's Address

   Christopher A. Wood
   University of California Irvine

   EMail: woodc1@uci.edu

Wood                   Expires September 14, 2017               [Page 6]