< draft-wood-icnrg-esic-00.txt   draft-wood-icnrg-esic-01.txt >
ICNRG Working Group M. Mosko ICNRG Working Group M. Mosko
Internet-Draft PARC, Inc. Internet-Draft PARC, Inc.
Intended status: Experimental C. Wood Intended status: Informational C. Wood
Expires: September 14, 2017 University of California Irvine Expires: March 16, 2018 University of California Irvine
March 13, 2017 September 12, 2017
Encrypted Sessions In CCNx (ESIC) Encrypted Sessions In CCNx (ESIC)
draft-wood-icnrg-esic-00 draft-wood-icnrg-esic-01
Abstract Abstract
This document describes how to transport CCNx packets inside an This document describes how to transport CCNx packets inside an
encrypted session between peers - a sender and receiver - that share encrypted session between peers that share a traffic secret, such as
a traffic secret, such as that which is derived from [CCNxKE]. The that which is derived from [CCNxKE]. The peers create an outer
peers create an outer naming context to identify the encryption naming context to identify the encryption session in one direction
session in one direction between the sender and the receiver. The between the consumer and the producer. The consumer sends encrypted
sender issues encrypted Interest messages to the receiver, who Interest messages to the producer, who responds with encrypted
responds with encrypted Content Objects. Inside the outer context, Content Objects. Inside the outer context, the consumer sends
the sender sends Interests with different names, for which the Interests with different names, which the producer may respond to or
receiver may reply to or send InterestReturns in response. There may send InterestReturns for. There does not need to be a naming
does not need to be a naming relationship between the outer names and relationship between the outer names and the inner names. The inner
the inner names. The inner content is still protected by normal CCNx content is still protected by normal CCNx authentication mechanisms
authentication mechanisms and possibly encrypted under other schemes. and possiby encrypted under other schemes.
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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
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. Stateless packet keys . . . . . . . . . . . . . . . . . . . . 4 2. Stateless packet keys . . . . . . . . . . . . . . . . . . . . 4
3. Inner and Outer Contexts . . . . . . . . . . . . . . . . . . 4 3. Inner and Outer Contexts . . . . . . . . . . . . . . . . . . 4
3.1. Outer Context Names . . . . . . . . . . . . . . . . . . . 5 3.1. Outer Context Names . . . . . . . . . . . . . . . . . . . 5
3.2. Outer Packet . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Outer Packet . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sender Outer Packet . . . . . . . . . . . . . . . . . 6 3.2.1. Consumer Outer Packet . . . . . . . . . . . . . . . . 6
3.2.2. Receiver Outer Packet . . . . . . . . . . . . . . . . 6 3.2.2. Producer Outer Packet . . . . . . . . . . . . . . . . 6
3.3. Processing Chain . . . . . . . . . . . . . . . . . . . . 6 3.3. Processing Chain . . . . . . . . . . . . . . . . . . . . 6
3.4. Transport State Machine . . . . . . . . . . . . . . . . . 7 3.4. Transport State Machine . . . . . . . . . . . . . . . . . 7
4. Control Channel . . . . . . . . . . . . . . . . . . . . . . . 9 4. Control Channel . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ESIC Control Packets . . . . . . . . . . . . . . . . . . 9 4.1. ESIC Control Packets . . . . . . . . . . . . . . . . . . 9
4.2. ESIC Control Messages . . . . . . . . . . . . . . . . . . 11 4.2. ESIC Control Messages . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. The ESIC API . . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Sample API . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. Sample Encryption TLVs . . . . . . . . . . . . . . . . . 13
A.2. Interest Encapsulation Examples . . . . . . . . . . . . . 13
A.3. Content Object Encapsulation Examples . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
CCNx packets [CCNxMessages] contain a fixed header, optional hop-by- CCNx packets [MESSAGES] contain a fixed header, optional hop-by-hop
hop headers, a CCNx Message, and a validation section. Encrypted headers, a CCNx Message, and a validation section. Encrypted
Sessions in CCNx (ESIC) describes how to to transport encrypted CCNx Sessions in CCNx (ESIC) describes how to to transport encrypted CCNx
packets inside other CCNx packets. The outer packet (the wrapper) packets inside other CCNx packets. The outer packet (the wrapper)
uses a CCNx name that identifies the encrypted session while the uses a CCNx name that identifies the encrypted session while the
inner (encrypted) portion remains hidden and private to an outside inner (encrypted) portion remains hidden and private to an outside
observer. observer.
ESIC defines a new field Encapsulated (T_ENCAP) that may occur in ESIC defines a new field Encapsulated (T_ENCAP) that may occur in
both an Interest (T_INTEREST) and Content Object (T_OBJECT). The both an Interest (T_INTEREST) and Content Object (T_OBJECT). The
T_ENCAP field contains the encryption of the inner CCNx packet, be it T_ENCAP field contains the encryption of the inner CCNx Packet.
an Interest or Content Object.
Because the use of an outer CCNxPacket, the total packet length of Because the use of an outer CCNxPacket, the total packet length of
the inner CCNxPacket may need to be limited to less than the maximum the inner CCNxPacket may need to be limited to less than the maximum
of 64 KB. ESIC allows the use of a compressor before the encryptor, of 64 KB. ESIC allows the use of a compressor before the encryptor,
so it is likely that a packet that would overflow the 64 KB limit so it is likely that a packet that would overflow the 64 KB limit
could be compressed by enough to allow for an outer CCNxPacket. This could be compressed by enough to allow for an outer CCNxPacket. This
consideration for the PacketLength is separate from concerns about consideration for the PacketLength is separate from concerns about
path MTU. path MTU.
It is a requirement of ESIC that one inner packet fit in one outer It is a requirement of ESIC that one inner packet fit in one outer
packet. This is because ESIC does not define a method to issue extra packet. This is because ESIC does not define a method to issue extra
outer interests to fetch extra outer content objects. It relies outer interests to fetch extra outer content objects. It relies
entirely on Interests generated by the sender application. entirely on Interests generated by the consumer application.
ESIC defines a control channel within the outer context by using ESIC defines a control channel within the outer context by using
special names with the inner packets. These names allow signaling special names with the inner packets. These names allow signaling
between the two encryption endpoints for features such as alerts and between the two encryption endpoints for features such as alerts and
rekeying requests. rekeying requests.
ESIC defines how to use a traffic secret (TS), such as derived from ESIC defines how to use a traffic secret (TS), such as derived from
CCNxKE, to encrypt multiple packets in a sender-receiver session. CCNxKE, to encrypt multiple packets in a consumer-producer session.
Each direction will use separate derived keys. If one wishes to have Each direction will use separate derived keys. If one wishes to have
a reverse traffic flow (interests from receiver fetching content a reverse traffic flow (interests from producer fetching content
objects from the sender), then one must share a second TS and use it objects from the consumer), then one must share a second TS and use
with the roles reversed, but otherwise it works exactly as in the it with the roles reversed, but otherwise it works exactly as in the
first case. first case.
The mechanism by which this symmetric key is obtained is outside the The mechanism by which this symmetric key is obtained is outside the
scope of this document; These keys could be pre-shared or derived scope of this document; These keys could be pre-shared or derived
from an online key-exchange protocol [CCNxKE]. from an online key-exchange protocol [CCNxKE].
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
skipping to change at page 4, line 13 skipping to change at page 4, line 15
o Outer Name: The name of the outer packet. o Outer Name: The name of the outer packet.
o Inner Name: The name of the inner packet (not visible in o Inner Name: The name of the inner packet (not visible in
transport). transport).
o Control channel: the use of Inner Packets to convey control o Control channel: the use of Inner Packets to convey control
signaling between encryption endpoints using a special Inner Name. signaling between encryption endpoints using a special Inner Name.
2. Stateless packet keys 2. Stateless packet keys
ESIC assumes that the sender and receiver share a Traffic Secret ESIC assumes that the consumer and producer share a Traffic Secret
(TS), usually derived as per CCNxKE. Regardless of how the TS is (TS), usually derived as per CCNxKE. Regardless of how the TS is
derived, there are four secrets derived from it, as per [CCNxKE]. derived (TODO: it needs to meet some so-far unstated requirements),
This specifies how to generate the Sender Write Key, Receiver Write there are four secrets derived from the TS, as per CCNxKE
Key, Sender Write IV, and Receiver Write IV. Section 9.5. This specifies how to generate the Client Write Key,
Server Write Key, Client Write IV, and Server Write IV.
The AEAD nonce (IV) is derived as specified in [TLS13]. In The AEAD nonce (IV) is derived as specified in [TLS13]. In
particular, the length of the IV for each AEAD operation is set to particular, the length of the IV for each AEAD operation is set to
max(8 bytes, N_MAX), where N_MIN must be at least 8 bytes [RFC5116]. max(8 bytes, N_MAX), where N_MIN must be at least 8 bytes [RFC5116].
With this length, the nonce is initialized by: With this length, the nonce is initialized by:
1. Padding the 64-bit per-packet AEAD sequence number to the left 1. Padding the 64-bit per-packet AEAD sequence number to the left
with zeroes so that its length is equal to the IV length. with zeroes so that its length is equal to the IV length.
2. This padded sequence number is then XORed with the sender or 2. This padded sequence number is then XORed with the consumer or
receiver IV, depending on the role. producer IV, depending on the role.
TODO: Should we allow CCNxKE to specify the starting chunk number so
it does not always start at 0? It would need to be encoded in the
MoveToken.
3. Inner and Outer Contexts 3. Inner and Outer Contexts
The inner context is a CCNx packet with meaning to the sender and The inner context is a CCNx packet with meaning to the consumer and
receiver. They may be clear text or they make use additional producer. They may be clear text or they make use additional
encryption as needed. The sender transmits an Interest packet with encryption, such as group keying, broadcast encryption, homomorphic
an Inner Name (plus other optional fields as normal) and expects to encryption, or something else. The consumer sends an Interest packet
get back a Content Object or InterestReturn packet with corresponding with an Inner Name (plus other optional fields as normal) and
name and fields. expectes to get back a Content Object or InterestReturn packet with
corresponding name and fields.
The outer context names the encryption session and sequences packets. The outer context names the encryption session and sequences packets.
ESIC does not expect a one-to-one correspondence of outer name and ESIC does not expect a one-to-one correspondence of outer name and
inner name. If a sender, for example, transmits 3 interests with inner name. If a consumer, for example, sends 3 interests with outer
outer names NO1, NO2, NO3 and inner names NI1, NI2, and NI3, the names NO1, NO2, NO3 and inner names NI1, NI2, and NI3, the producer
receiver can return those names in any order. It could put content can return those names in any order. It could put content objects
objects with name NI3 in NO1, NI1 in NO2, and NI2 in NO3. ESIC does with name NI3 in NO1, NI1 in NO2, and NI2 in NO3. ESIC does expect
expect normal CCNx processing rules to be followed for the inner normal CCNx processing rules to be followed for the inner packets,
packets, therefore we would expect at most one inner packet returned therefore we would expect at most one inner packet returned for each
for each inner Interest. That inner packet could be either a Content inner Interest. That inner packet could be either a Content Object
Object or Interest Return. or Interest Return.
3.1. Outer Context Names 3.1. Outer Context Names
The outer context name is a routable prefix PREFIX followed by a The outer context name is a routable prefix PREFIX followed by a
session ID (SID) followed by a ChunkNumber (Chunk). The chunk number session ID (SID) followed by a ChunkNumber (Chunk). The chunk number
is a monotonically increasing number. is a monotonically increasing number. The outer name is clear text,
The outer name is clear text, visible to all observers. visible to all observers.
The PREFIX and SID are derived outside of ESIC. In normal use with The PREFIX and SID are derived outside of ESIC. In normal use with
CCNxKE, the PREFIX is that which is set after the handshake CCNxKE, the PREFIX is either the same prefix as used in the key
completes, be it the original producer (receiver) prefix or the exchagne or it is derived from within CCNxKE from Prefix2 or the
MovePrefix. The SID is created by the receiver and given to the MoveToken. The SID is created by the producer and given to the
sender inside CCNxKE. consumer inside CCNxKE.
OuterName := ccnx:/PREFIX/SID=sid/CHUNK=chunk OuterName := ccnx:/PREFIX/SID=sid/CHUNK=chunk
Chunk numbers are limited to 8 bytes and do not wrap around. When Chunk numbers are limited to 8 bytes and do not wrap around. When
the sender gets near the end of the sequence number space, it must the consumer gets near the end of the sequence number space, it must
request a re-keying via the control channel. Because CCNx in a pull- request a re-keying via the control channel. Because CCNx in a pull-
driven model, the sender is responsible for the chunk number and thus driven model, the consumer is reponsible for the chunk number and
responsible for requesting the re-keying. The receiver may also thus responsible for requesting the re-keying. The producer may also
request a re-keying for its own reasons. request a re-keying for its own reasons.
3.2. Outer Packet 3.2. Outer Packet
The outer packet will have a Fixed Header, per hop headers, a CCNx The outer packet will have a Fixed Header, per hop headers, a CCNx
Message with the Outer Name, and a Validation section (ValidationAlg Message with the Outer Name, and a Validation section (ValidationAlg
and ValidationPayload). The outer packet is visible to 3rd parties and ValidationPayload). The outer packet is visible to 3rd parties
in its entirety. Only the 'value' of T_ENCAP TLV field inside the in its entirety. Only the 'value' of T_ENCAP TLV field inside the
CCNx Message is encrypted. The T_ENCAP TLV Value is the AEAD CCNx Message is encrypted. The T_ENCAP TLV Value is the AEAD
'plaintext' that will be converted to the 'ciphertext'. In the outer 'plaintext' that will be converted to the 'ciphertext'. In the outer
packet, only the CCNx Message and the ValidationAlg are covered by packet, only the CCNx Message and the ValidationAlg are covered by
the authentication token the authentication token
The Outer Packet has a Validation section. The ValidationAlg will The Outer Packet has a Validation section. The ValidationAlg will
have a 0-length ValidationType of T_SESSION, which indicates that the have a 0-length ValidationType of T_SESSION, which indidates that the
encryption context must be derived from the SID in the name. encryption context must be derived from the SID in the name.
The Associated Data (in AEAD) covered by the validation output is The Associated Data (in AEAD) covered by the validation output is
from the beignning of the CCNx Message up to but not including the from the beignning of the CCNx Message up to but not including the
T_ENCAP Value concatenated with the ValidationAlg TLV. That is, it T_ENCAP Value concatendated with the ValidationAlg TLV. That is, it
skips the T_ENCAP TLV Value. skips the T_ENCAP TLV Value.
The ValidationPayload contains the AEAD authentication token. The ValidationPayload contains the AEAD authentication token.
If the receiver cannot satisfy an Inner Packet Interest, it will If the Producer cannot satisfy an Inner Packet Interest, it will
encapsulate an InterestReturn inside an OuterPacket of PacketType encapsualte an InterestReturn inside an OuterPacket of PacketType
ContentObject. That is, the InterestReturn is end-to-end signaling ContentObject. That is, the InterestReturn is end-to-end signaling
about the inner context. about the inner context.
If the receiver has an error with the Outer Context, it may return an If the Producer has an error with the Outer Context, it may return an
InterestReturn for the outer context as normal for Interest InterestReturn for the outer context as normal for Interest
processing. processing.
3.2.1. Sender Outer Packet 3.2.1. Consumer Outer Packet
The outer packet from the sender to the receiver will always be of The outer packet from the consumer to the producer will always be of
PacketType Interest. They may have any of the normal Interest per- PacketType Interest. They may have any of the normal Interest per-
hop headers (e.g. InterestLifetime), which will be visible to 3rd hop headers (e.g. InterestLifetime), which will be visible to 3rd
parties and not protected by the encryption or authentication. parties and not protected by the encryption or authentication.
The Outer Context has a T_INTEREST message type, which contains a The Outer Context has a T_INTEREST message type, which contains a
T_NAME of the Outer Name. It may have other additional metadata in T_NAME of the Outer Name. It may have other additional metadata in
clear text. The T_INTEREST container is protected by the encryption clear text. The T_INTEREST container is protected by the encryption
authenticator. Finally, the T_INTEREST has a T_ENCAP field that authenticator. Finally, the T_INTEREST has a T_ENCAP field that
contains the encryption of the Inner Packet. The encryption will use contains the encryption of the Inner Packet. The encryption will use
the algorithm negotiated as part of the SID (i.e. AES-GCM). the algorithm negotiated as part of the SID (i.e. AES-GCM).
3.2.2. Receiver Outer Packet 3.2.2. Producer Outer Packet
The receiver will only send PacketType ContentObject back to the The producer will only send PacketType ContentObject back to the
sender. The Inner packet may be either an InterestReturn or a consumer. The Inner packet may be either an InterestReturn or a
ContentObject corresponding to the Inner Packet interest. ContentObject corresponding to the Inner Packet interest.
The outer packet may have per-hop headers (e.g. The outer packet may have per-hop headers (e.g.
RecommendedCacheTime) that affect the encrypted packet. These are RecommendedCacheTime) that affect the encrypted packet. These are
independent from the inner Per Hop headers. The outer MessageType is independent from the inner Per Hop headers. The outer MessageType is
always T_OBJECT. It may have normal metadata for a content object, always T_OBJECT. It may have normal metadata for a content object,
such as ExpiryTime, which affect only the outer packet. Finally, it such as ExpiryTime, which affect only the outer packet. Finally, it
has a T_ENCAP that contains the wrapped inner Packet. has a T_ENCAP that contains the wrapped inner Packet.
3.3. Processing Chain 3.3. Processing Chain
skipping to change at page 7, line 25 skipping to change at page 7, line 25
o Source: The source of an Inner Packet. o Source: The source of an Inner Packet.
o Compressor: Optional component to reduce the size before o Compressor: Optional component to reduce the size before
encryption. encryption.
o Encrypter/Framer: Creates the ciphertext of the CCNx(z)packet to o Encrypter/Framer: Creates the ciphertext of the CCNx(z)packet to
produce the T_ENCAP, constructs the outer packet, computes the produce the T_ENCAP, constructs the outer packet, computes the
authentication token and generates the ValidationPayload. authentication token and generates the ValidationPayload.
o Channel: Carries the wire format outer packet o Channel: Carries the wireformat outer packet
o Deframer/Decrypter: Verifies the authenticator, decrypts the o Deframer/Decrypter: Verifies the authenticator, decrypts the
T_ENCAP, and passes the Inner Packet to the Decompressor. T_ENCAP, and passes the Inner Packet to the Decompressor.
o Decompressor: Optional component to expand the inner packet o Decompressor: Optional component to expand the inner packet
o Sink: The sink of an Inner Packet. o Sink: The sink of an Inner Packet.
The Encrypter/Framer will generate outer names with sequential outer The Encrypter/Framer will generate outer names with sequential outer
name chunk numbers. name chunk numbers.
The Deframer/Decryptor will extract the SID and chunk number from the The Deframer/Decryptor will extract the SID and chunk number from the
outer name and use those to create the packet key (see below). Using outer name and use those to create the packet key (see below). Using
the packet key, it will verify the authentication token and if the packet key, it will verify the authentication token and if
successful decrypt the T_ENCAP. The output of the T_ENCAP will then successful decrypt the T_ENCAP. The output of the T_ENCAP will then
be passed to the Sink. be passed to the Sink.
3.4. Transport State Machine 3.4. Transport State Machine
ESIC uses a state machine to manage the ephemeral session such that ESIC uses a state machine to manage the ephemeral session such that
the receiver knows when the sender is finished with the SID. It also the Producer knows when the Consumer is finished with the SID. It
will try to re-request packets that fail authentication before also will try to re-request packets that fail authentication before
sending its own InterestReturn up the Sink. sending its own InterestReturn up the Sink.
The protocol begins with each side knowing the four keys (see The protocol begins with each side knowing the four keys (see
Stateless Packet Keys below), the Session ID (SID), and the routable Stateless Packet Keys below), the Session ID (SID), and the routable
prefix PREFIX. prefix PREFIX.
The receiving process uses a replay buffer to prevent replay attacks. The receiving process uses a replay buffer to prevent replay attacks.
The buffer tracks the last N out-of-order verified chunks plus the The buffer tracks the last N out-of-order verified chunks plus the
cumulative verified chunk number. cumulative verified chunk number. TODO: Sort this out how to avoid
replay attacks without requiring reliable in-order delivery.
((TODO: Sort this out how to avoid replay attacks without requiring
reliable in-order delivery.))
Protocol of Encrypter/Framer: Protocol of Encrypter/Framer:
o Initialize: set NextChunkNumber = 0, State = Waiting o Initialize: set NextChunkNumber = 0, State = Waiting
o Waiting: Wait for packet from Source (or compressor). On packet o Waiting: Wait for packet from Source (or compressor). On packet
receive, State = Send receive, State = Send
o Send: o Send:
skipping to change at page 8, line 51 skipping to change at page 8, line 49
o Waiting: wait for packet, on input from channel State = Receive o Waiting: wait for packet, on input from channel State = Receive
o Receive: o Receive:
* Extract the SID and ChunkNumber from name * Extract the SID and ChunkNumber from name
* If replay, drop * If replay, drop
* Authenticate the packet * Authenticate the packet
+ If failed on sender, send InterestReturn to Source with "X + If failed on consumer, send InterestReturn to Source with "X
Error" (TBD) Error" (TBD)
+ If failed on receiver, send failure message to Sink so it + If failed on producer, send failure message to Sink so it
can send end-to-end InterestReturn back over channel (if can send end-to-end InterestReturn back over channel (if
desired) with "Y Error" (TBD) desired) with "Y Error" (TBD)
* Add packet to replay buffer * Add packet to replay buffer
* Decrypt packet * Decrypt packet
* Pass decrypted packet to Sink/Source (or decompressor) * Pass decrypted packet to Sink/Source (or decompressor)
4. Control Channel 4. Control Channel
The sender and receiver will need to exchange signaling about the The consumer and producer will need to exchange signaling about the
encryption context. Control and data traffic should be encryption context. Control and data traffic should be
indistinguishable to an external observer. Therefore, all control indistinguishable to an external observer. Therefore, all control
signaling is done within the same outer names as data traffic. signaling is done within the same outer names as data traffic.
Control signaling is done with a normal Inner Packet that pushes data Control signaling is done with a normal Inner Packet that pushes data
to the other side. We use an Interest with an Inner Name of the form to the other side. We use an Interest with an Inner Name of the form
shown below, where '_direction_' is 'up' from the sender to receiver shown below, where '_direction_' is 'up' from the consumer to
or 'down' for the receiver to sender. This allows each side to producer or 'down' for the producer to consumer. This allows each
maintain its own sequence number space in the 'seqnum'. This is side to maintain its own sequence number space in the 'seqnum'. This
similar to the use of the sequence number in the DTLS record layer. is similar to the use of the sequence number in the DTLS record
layer.
Like DTLS, ESIC control messages are unreliable, though they are Like DTLS, ESIC control messages are unreliable, though they are
uniquely named. uniquely named.
The payload of the control Interest uses a TLV equivalent of the TLS The payload of the control Interest uses a TLV equivalent of the TLS
record format for handshake and alert messages. Application data is record format for handshake and alert messages. Application data is
never communicated in these records, as they use an Inner Packet with never communicated in these records, as they use an Inner Packet with
a different Inner Name. Inside the payload, a TLV type of Alert (21) a different Inner Name. Inside the payload, a TLV type of Alert (21)
or Handshake (22) indicates the purpose of the TLV value. One may or Handshake (22) indicates the purpose of the TLV value. One may
concatenate multiple records into one payload. concatenate multiple records in to one payload.
ControlName := ccnx:/localhost/esic/_direction_/SID=sid/SEQNUM=seqnum ControlName := ccnx:/localhost/esic/_direction_/SID=sid/SEQNUM=seqnum
4.1. ESIC Control Packets 4.1. ESIC Control Packets
A control packet is a CCNx Interest Inner Packet. The name of the A control packet is a CCNx Interest Inner Packet. The name of the
control packet is as above in the /localhost/esic namesapce. The control packet is as above in the /localhost/esic namesapce. The
Payload of the Interest is the actual data. Payload of the Interest is the actual data.
The ESIC control packet SHOULD be padded out to a length that is The ESIC control packet SHOULD be padded out to a length that is
indistinguishable from other traffic in the given _direction_. indistinguishable from other traffic in the given _direction_.
The Payload of the Interest contains a set of TLV records using the The Payload of the Interest contains a set of TLV records using the
normal CCNx TLV encoding. The TLV types and values are defined in normal CCNx TLV encoding. The TLV types and values are defined in
the next section. the next section.
In the 'up' direction from the sender to the receiver, a control In the 'up' direction from the consumer to the producer, a control
packet can be inserted into the Interest stream as normal. The packet can be inserted into the Interest stream as normal. The
receiver may use this extra outer name to return its own control producer may use this extra outer name to return its own control
message or send a "no-op" back to consume the extra name. message or send a "no-op" back to consume the extra name.
In the 'down' direction from the receiver to the sender, there is no In the 'down' direction from the producer to the consumer, there is
pre-allocated outer name available. The receiver can only send the no pre-allocated outer name available. The producer can only send
sender a control message if the sender has outstanding Interests up the consumer a control message if the consumer has outstanding
to the receiver. If there is one or more outstanding interests in Interests up to the producer. If there is one or more oustanding
the outer name space, the receiver normally would send a Content interests in the outer name space, the producer normally would send a
Object or Interest Return corresponding to some inner name. In this Content Object or Interest Return corresponding to some inner name.
case, the receiver would instead inject a control packet Interest in In this case, the producer would instead inject a control packet
the downstream. This means the receiver is now short one outer Interest in the downstream. This means the producer is now short one
Interest in the upstream direction. Therefore, whenever the outer Interest in the upstream direction. Therefore, whenever the
Deframer/Decrypter sees a control message in the downstream Deframer/Decrypter sees a control message in the downstream
direction, it MUST insert an upstream "no-op" packet, padded out to direction, it MUST insert an upstream "no-op" packet, padded out to
statistically undetectable length, to give the receiver back a statistically undetectable length, to give the producer back a
missing name slot. missing name slot.
We allow one ESIC control packet in one outer packet. However, we We allow one ESIC control packet in one outer packet. However, we
allow multiple Alert messages to be encoded in the payload, so long allow multiple Alert messages to be encoded in the payload, so long
as it remains indistinguishable from other packets in the given as it remains indistinguishable from other packets in the given
_direction_. _direction_.
Example from a sender to a receiver, where "NO" means "name outer" Example from a consumer to a producer, where "NO" means "name outer"
and "NI" means "name inner". and "NI" means "name inner".
Sender Receiver Consumer Producer
| >------- NO1 : NI1 (Interest) --------> | | >------- NO1 : NI1 (Interest) --------> |
| >------- NO2 : NI2 (Interest) --------> | | >------- NO2 : NI2 (Interest) --------> |
| <------- NO1 : NI1 (ContentObject) ---< | | <------- NO1 : NI1 (ContentObject) ---< |
| >------- NO3 : NI /local/esic/up/2/1 -> | | >------- NO3 : NI /local/esic/up/2/1 -> |
| <------- NO3 : no-op -----------------< | (no-op) | <------- NO3 : no-op -----------------< | (no-op)
| <------- NO2 : NI2 (ContentObject) ---< | | <------- NO2 : NI2 (ContentObject) ---< |
Here is an example from a receiver to a sender. The receiver uses Here is an example from a producer to a consumer. The producer uses
the second available name NO2 to send a control message to the the second avaialble name NO2 to send a control message to the
sender. The sender must then send a no-op packet back up to the consumer. The consumer must then send a no-op packet back up to the
receiver so it can return the final data packet NI2 inside NO3. producer so it can return the final data packet NI2 inside NO3.
Sender Receiver Consumer Producer
| >------- NO1 : NI1 (Interest) --------> | | >------- NO1 : NI1 (Interest) --------> |
| >------- NO2 : NI2 (Interest) --------> | | >------- NO2 : NI2 (Interest) --------> |
| <------- NO1 : NI1 (ContentObject) ---< | | <------- NO1 : NI1 (ContentObject) ---< |
| <------- NO2 : NI /local/esic/dn/2/1 -< | | <------- NO2 : NI /local/esic/dn/2/1 -< |
| >------- NO3 : -----------------------> | (no-op) | >------- NO3 : -----------------------> | (no-op)
| <------- NO3 : NI2 (ContentObject) ---< | | <------- NO3 : NI2 (ContentObject) ---< |
((TODO: Add examples with loss))
TODO: Add examples with loss
4.2. ESIC Control Messages 4.2. ESIC Control Messages
ESIC adopts the TLS 1.3 Alert Protocol for its control messages. The ESIC adopts the TLS 1.3 Alert Protocol for its control messages. The
TLV type of the message inside the control packet payload is taken TLV type of the message inside the control packet payload is taken
from the enum AlertDescription. As per TLS 1.3, fatal Alert messages from the enum AlertDescription. As per TLS 1.3, fatal Alert messages
are an immediate close of the ESIC session. are an immediate close of the ESIC session.
As per TLS 1.3, each party MUST send a close_notify message closing As per TLS 1.3, each party MUST send a close_nofity message closing
the write side of the connection. In ESIC, this means that when a the write side of the connection. In ESIC, this means that when a
sender is done requesting data, it should send a final close_notify. consumer is done requesting data, it should send a final
The receiver should then use this outer name to send back its own close_notify. The producer should then use this outer name to send
close_notify. If for some reason the receiver must close before the back its own close_notify. If for some reason the producer must
sender, it should inject its own close_notify discarding all close before the consumer, it should inject its own close_notify
remaining data and the receiver should send back upstream a discarding all remaining data and the consumer should send back
close_notify. upstream a close_notify.
The KeyUpdate messages function as per TLS 1.3 Sec 6.3.5.3. Either The KeyUpdate messages function as per TLS 1.3 Sec 6.3.5.3. Either
side may generate a KeyUpdate message and begin transmitting with the side may generate a KeyUpdate message and begin transmitting with the
new key. The other side must update their own key and issue its own new key. The other side must update their own key and issue its own
KeyUpdate message. KeyUpdate message.
5. Security Considerations 5. The ESIC API
In this section we describe the ESIC API. Before doing so, we
highlight some details that molded the API for both consumers and
consumers.
o Encrypted sessions are bound to names instead of addresses.
Consequently, in addition to a set of trusted keys, sessions
between a consumer and producer require only a name to be created.
o Sessions are created by an active consumer with a passive peer
(producer). Thus, the API must reflect these roles.
o Consumers send and receive whole CCNx messages over a session.
Thus, simple read and write functions must be exposed via the API.
o Sessions are not full duplex by default. A producer must specify
in its ServerConfiguration construct that it wishes to send
interests to the consumer. To maintain transparency, the modality
of the resulting session is not reflected in the API.
These observations are distilled in the following ESIC API.
# @Consumer: create a secure session with a producer
CCNxSecureSession *ccnxSecureSession_Connect(CCNxPortal *portal,
PARCIdentity *identity, CCNxName *servicePrefix);
# @Producer: create a passive listener
CCNxSecureSession *ccnxSecureSession_CreateServer(CCNxPortal *portal,
CCNxKeyExchangeConfig *config, CCNxName *servicePrefix);
# @Producer: accept uni- and bi-directional sessions
CCNxSecureSession *ccnxSecureSession_AcceptConnection(CCNxSecureSession *session);
CCNxSecureSession *ccnxSecureSession_AcceptBidirectionalConnection(CCNxSecureSession *session);
# Send a CCNx message
# Override the outer name with the `response` parameter if needed
void ccnxSecureSession_SendMessage(CCNxSecureSession *session,
CCNxTlvDictionary *message, const CCNxStackTimeout *timeout, CCNxName *response);
# Receive and decapsulate a CCNx message
# Store the outer name in the `response` parameter.
CCNxMetaMessage *ccnxSecureSession_ReceiveMessage(CCNxSecureSession *session,
const CCNxStackTimeout *timeout, CCNxName **response);
6. Security Considerations
It may be possible for an observer to identify which outer packets It may be possible for an observer to identify which outer packets
contain a control (alert) message if the ACK response time shows contain a control (alert) message if the ACK response time shows
significant statistical timing different from the normal flow of significant statistical timing different from the normal flow of
messages. messages.
6. References TODO.
6.1. Normative References 7. References
7.1. Normative References
[CCNxKE] "CCNx Key Exchange Protocol Version 1.0", n.d., [CCNxKE] "CCNx Key Exchange Protocol Version 1.0", n.d.,
<https://github.com/parc/ccnx-keyexchange-rfc>. <https://github.com/parc/ccnx-keyexchange-rfc>.
[CCNxMessages] [MESSAGES]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", n.d., "CCNx Messages in TLV Format", n.d.,
<https://tools.ietf.org/html/draft-irtf-icnrg- <https://tools.ietf.org/html/draft-irtf-icnrg-
ccnxmessages-04>. ccnxmessages-02>.
[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>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[TLS13] RTFM, Inc, ., "The Transport Layer Security (TLS) Protocol [TLS13] RTFM, Inc, ., "The Transport Layer Security (TLS) Protocol
Version 1.3", n.d., <https://tools.ietf.org/html/draft- Version 1.3", n.d., <https://tools.ietf.org/html/draft-
ietf-tls-tls13-19>. ietf-tls-tls13-13>.
6.2. Informative References 7.2. Informative References
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
DOI 10.17487/RFC5288, August 2008, DOI 10.17487/RFC5288, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5288>. editor.org/info/rfc5288>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5389>. editor.org/info/rfc5389>.
Appendix A. Sample API
In this section we describe the ESIC API. Before doing so, we
highlight some details that molded the API for both senders and
receivers.
o Encrypted sessions are bound to names instead of addresses.
Consequently, in addition to a set of trusted keys, sessions
between a sender and receiver require only a name to be created.
o Sessions are created by an active sender with a passive peer
(receiver). Thus, the API must reflect these roles.
o Senders transmit and receive whole CCNx messages over a session.
Thus, simple read and write functions must be exposed via the API.
o Sessions are not full duplex by default. A receiver must specify Appendix A. Test Vectors
in its ServerConfiguration construct that it wishes to send
interests to the sender. To maintain transparency, the modality
of the resulting session is not reflected in the API.
These observations are distilled in the following ESIC API. A.1. Sample Encryption TLVs
# @Sender: create a secure session with a receiver TODO
CCNxSecureSession *ccnxSecureSession_Connect(CCNxPortal *portal,
PARCIdentity *identity, CCNxName *servicePrefix);
# @Receiver: create a passive listener A.2. Interest Encapsulation Examples
CCNxSecureSession *ccnxSecureSession_CreateServer(CCNxPortal *portal,
CCNxKeyExchangeConfig *config, CCNxName *servicePrefix);
# @Receiver: accept uni- and bi-directional sessions TODO
CCNxSecureSession *ccnxSecureSession_AcceptConnection(CCNxSecureSession *session);
CCNxSecureSession *ccnxSecureSession_AcceptBidirectionalConnection(CCNxSecureSession *session);
# Send a CCNx message A.3. Content Object Encapsulation Examples
# Override the outer name with the `response` parameter if needed
void ccnxSecureSession_SendMessage(CCNxSecureSession *session,
CCNxTlvDictionary *message, const CCNxStackTimeout *timeout, CCNxName *response);
# Receive and decapsulate a CCNx message TODO
# Store the outer name in the `response` parameter.
CCNxMetaMessage *ccnxSecureSession_ReceiveMessage(CCNxSecureSession *session,
const CCNxStackTimeout *timeout, CCNxName **response);
Authors' Addresses Authors' Addresses
Marc Mosko Marc Mosko
PARC, Inc. PARC, Inc.
Email: marc.mosko@parc.com Email: marc.mosko@parc.com
Christopher A. Wood Christopher A. Wood
University of California Irvine University of California Irvine
 End of changes. 65 change blocks. 
167 lines changed or deleted 192 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/