draft-wood-icnrg-ccnxkeyexchange-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>

<rfc docName="draft-wood-ccnxkeyexchange-01" category="std">

  <front>
    <title abbrev="CCNxKE">CCNx Key Exchange Protocol Version 1.0</title>

    <author initials="M." surname="Mosko" fullname="M. Mosko">
      <organization>PARC</organization>
      <address>
        <email>marc.mosko@parc.com</email>
      </address>
    </author>
    <author initials="E." surname="Uzun" fullname="Ersin Uzun">
      <organization>PARC</organization>
      <address>
        <email>ersin.uzun@parc.com</email>
      </address>
    </author>
    <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>PARC</organization>
      <address>
        <email>christopher.wood@parc.com</email>
      </address>
    </author>

    <date year="2016" month="April" day="06"/>

    <area>General</area>
    <workgroup>icnrg</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document specifies Version 1.0 of the CCNx Key Exchange (CCNxKE) protocol.
The CCNxKE protocol allows two peers to establish a shared, forward-secure key
for secure and confidential communication. The protocol is designed to prevent
eavesdropping, tampering, and message forgery between two peers. It is also
designed to minimize the number of rounds required to establish a shared key.
In the worst case, it requires two RTTs between a consumer and producer to establish
a shared key. In the best case, one RTT is required before sending any application
data. This document outlines how to derive the keys used to encrypt traffic.
An annex provides an example peer-to-peer transport protocol for exchanging
encrypted CCNx communications.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>DISCLAIMER: This is a WIP draft of CCNxKE and has not yet seen rigorous security analysis.</t>

<t>CCNx Key Exchange (CCNxKE) establishes ephemeral forward secure keys between two peers,
called the consumer (client) and producer (server).  The underlying cryptography of
CCNxKE is similar to TLS 1.3, though there are some protocol changes due to the ICN nature
of CCNxKE.  CCNxKE also supports the concept of a MoveToken, which allows the authenticating
producer to shift a session to one (or more) co-operating replicas.</t>

<t>CCNxKE does not specify how the keys are used.  It only specifies how to derive the traffic
secret that could be used to encrypt/decrypt data.  The draft [draft-wood-icnrg-tlvencap] specifies
one way to use the traffic secret to carry out communications in a session.<vspace />
Annex A also sketches out an example CCNx protocol for exchanging encrypted messages,
though it is not part of this standard.
Other protocols may use CCNxKE.<vspace />
For example, a producer and replica may use CCNxKE to establish a shared key to use
in Move Tokens.  Two routers may use CCNxKE to establish MACSEC keys.  A consumer and publisher could establish
a symmetric key while on-line then publish content later for an off-line consumer.
In short, the use of CCNxKE is not limited to a TLS-like transport protocol.</t>

<t>CCNxKE allows upper-layer data to be returned in Round 3, like TLS 1.3.  In this sense, one can achieve 3 RTT
(worst case) or 1 RTT (best case) communcations.  The data put in this response is up to the 
protocol using CCNxKE and may or may not be used.</t>

<t>CCNxKE is not a substitue for
data authenticity, such as Content Object provenance via signatures, group encryption of cached objects,
or DRM protections.  CCNxKE only creates a private, ephemeral tunnel between a consumer
and a producer.  CCNxKE expects that the encrypted communications protocol still carries
normal CCNx packets with normal CCNx attributes such as signatures.</t>

<t>Some types of ICN communications require emphemeral, forward secure encryption.
Typical examples are on-line banking, real-time voice, or on-line shopping.
Other applications may need different types of encryption and thus not use CCNxKE.
There is currently no standard way for CCNx peers to exchange emphemeral, forward
secure keys, thus this RFC specifies the standard mechanism that should be used
by all CCNx peers for such keys. CCNxKE
is built on the CCNx 1.0 protocol and only relies
upon standard Interest and Content Objects as a vehicle for communication.</t>

<t>In this document, the term ‘CCNxKE session’ refers to the key exchange session.
It does not refer to a transport protocol session (like TLS) that uses the derived keys.</t>

<t>This protocol has the following four main properties:</t>

<t><list style="symbols">
  <t>Each peer’s identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA <xref target="RSA"/>, ECDSA <xref target="ECDSA"/>, etc.).
Server authentication is mandatory whereas mutual authentication is
optional.</t>
  <t>The negotiation of a forward-secure shared secret is protected from
eavesdroppers and man-in-the-middle (MITM) attacks.</t>
  <t>The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties to
the communication.</t>
  <t>The state of a CCNxKE session can be securely migrated between an endpoint
performing authentication and that which provides content using a “move token.”
This allows authentication and authorization to be separated from encryption for
a session, enabling different systems to complete these steps.</t>
</list></t>

<t>Usage of CCNxKE is entirely independent of upper-layer application protocols.
CCNxKE may be used for any purpose that requires producer authentication and 
shared emphemeral forward-secure keys.</t>

<t>CCNxKE also introduces a new type of cookie based on reverse hash chains <xref target="HASHCHAIN"/>
to help limit the amount of significant server work done in response to a client
or consumer Interest. TCP-based protocols, such as TLS <xref target="TLS13"/>, use the TCP 3-way handshake
for such proof. UDP-based protocols, such as QUIC <xref target="QUIC"/> and DTLS 1.2 <xref target="DTLS12"/>, use an
optional session address token or cookie that must be presented by the client (consumer) to
prove ownership of an address during a key exchange procedure. Without source addresses,
our cookie technique ensures that the same entity which requested server information,
e.g., the public configuration data, is the same entity that wishes to complete
a key exchange.</t>

<t>The main contribution of this work is adapting key exchange principles to the pull-based
CCNx communication model. CCNxKE only assumes that a consumer knows a first name prefix
to initiate the key exchange. The first Interest does not need to be a CCNxKE packet — the
producer can signal back to the consumer that it requires a transport protocol
using CCNxKE in the response.</t>

<t>This specification does not subsume other ICN-compliant key exchange protocols. Nor
does its existence imply that all encryption in an ICN must be based on sessions.
It was designed specifically to solve the problem of session-based encryption in ICN.</t>

<section anchor="conventions-and-terminology" title="Conventions and Terminology">

<t>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 <xref target="RFC2119"/>.</t>

<t>The following terms are used:</t>

<t>Consumer/Client: The CCN consumer initiating the CCNxKE key exchange via a first Interest.</t>

<t>Producer/Server: The CCN producer receiving or accepting the CCNxKE key exchange request request Interest.</t>

<t>Sender: An endpoint that originates a message.</t>

<t>Receiver: An endpoint that is receiving messages.</t>

<t>Peer: An endpoint. When discussing a particular endpoint, “peer” refers to the endpoint that is remote to the primary subject of discussion.</t>

<t>Connection: A network path of n &gt;= 1 hops between the consumer and producer.</t>

<t>Endpoint: Either the consumer or producer of the connection.</t>

<t>Handshake: A series of message exchanges between two peers that is used to perform a
task (e.g., perform key exchange and derivation).</t>

<t>Session: An association between a consumer and a producer resulting from a
CCNxKE handshake.</t>

<t>DH: A Diffie Hellman key exchange procedure <xref target="RFC2631"/> <xref target="DH"/>.</t>

<t>Key Share: One half of the shared-secret provided by one peer performing a DH key exchange.</t>

<t>Forward-secure: The property that compromising any long-term secrets (e.g., cryptographic
keys) does not compromise any session keys derived from those long-term secrets.</t>

<t>CONFIG information: A data structure created by a producer which contains long-term
cryptographic material and associated information needed by a client to initiate a
key-exchange with the producer.</t>

<t>HELLO exchange: An exchange between a consumer and producer wherein the consumer
retrieves the CONFIG information from the producer.</t>

<t>Payload: The payload section of a CCNxMessage as defined in <xref target="CCNxMessages"/>.</t>

<t>KEPayload: A payload for information used in the CCNxKE protocol which is a generic
key-value store. The KEPayload is <spanx style="emph">not</spanx> the CCNxMessage payload.</t>

<t>CCNxName: A CCNxName as defined in <xref target="CCNxMessages"/>.</t>

<t>Semi-static: Short-term.</t>

<t>Short-term Secret (SS): A secret which is derived from the server’s semi-static
DH share and the client’s fresh DH share.</t>

<t>Forward-secure Secret (FSK): A secret which is derived from fresh (i.e., generated
on demand at random) DH shares from both the consumer and producer for the given
connection.</t>

<t>HKDF: Hash-based key-derivation function <xref target="RFC5869"/>.</t>

</section>
</section>
<section anchor="goals" title="Goals">

<t>The goals of the CCNxKE protocol, in order of priority, are as follows:</t>

<t><list style="numbers">
  <t>Cryptographic security: CCNxKE should be used to securely establish a session
and all related shared secrets between two peers. Cryptographic properties of interest
include: (a) forward-secure session key derivation and (b) (state and computational)
denial-of-service prevention at the producer (see <xref target="RFC4987"/>) that is no worse than
DTLS 1.2 <xref target="DTLS12"/>}. For property (a), different keys (and relevant algorithm
parameters such as IVs) are established for each communication direction, i.e.,
from consumer to producer and producer to consumer. For property (b), we use a new
type of stateless cookie inspired by that of DTLS 1.2.</t>
  <t>Interoperability: Independent programmers should be able to develop
applications utilizing CCNxKE that can successfully exchange cryptographic
parameters without knowledge of one another’s code.</t>
  <t>Extensibility: CCNxKE seeks to provide a framework into which new public key
and symmetric key methods and algorithms can be incorporated without breaking
backwards compatibility or requiring all clients to implement new functionality.
Moreover, the protocol should be able to support a variety of peer authentication
protocols, e.g., EAP-TLS, EAP-PWD, or a simple challenge-response protocol.</t>
  <t>Relative efficiency: CCNxKE tries to create sessions with minimal computation,
bandwidth, and message complexity. In particular, it seeks to create sessions with
as few end-to-end round trips as possible, and also provide support for accelerated
session establishment and resumption when appropriate. At most 2 round-trip-times
(RTTs) should be used to establish a session key, with the possibility of 1-RTT
accelerated starts and resumption.</t>
</list></t>

</section>
<section anchor="scope" title="Scope">

<t>This document and the CCNxKE protocol are influenced by the TLS 1.3 <xref target="TLS13"/>,
QUIC <xref target="QUIC"/>, and DTLS 1.2 <xref target="DTLS12"/> protocols.
The reader, however, does not need a detailed understanding of those
protocols to understand this document. Moreover, where appropriate, references
to related protocols are made for brevity and technical clarity. This document
is intended primarily for readers who will be implementing the protocol and for
those doing cryptographic analysis of it. The specification has been written with
this in mind and it is intended to reflect the needs of those two groups.</t>

<t>Unlike TLS, this document does not specify the transport protocol.  It specifies
the establishment of a session ID and shared keys.  Other documents specify
the use of CCKxKE within a transport protocol.</t>

<t>This document is not intended to supply any details of service definition or
of interface definition, although it does cover select areas of policy as they are
required for the maintenance of solid security.</t>

</section>
<section anchor="presentation-language" title="Presentation Language">

<t>This document uses a presentation language of remote calls (i.e. packet messages)
similar to the format used by TLS <xref target="TLS13"/>.</t>

</section>
<section anchor="ccnxke-overview" title="CCNxKE Overview">

<section anchor="connection-establishment-latency" title="Connection Establishment Latency">

<t>CCNxKE operates in three rounds, where each round requires a single RTT
to complete. The full execution of the protocol therefore requires 2 RTTs
before a session is fully established. The full version is used when consumers
have no a priori information about the producer. An accelerated one round
version is used when the consumer has valid configuration information and a
source cookie from the producer; this variant requires 1 RTT before a session
is established.</t>

</section>
<section anchor="connection-migration-and-resumption" title="Connection Migration and Resumption">

<t>CCN end hosts lack the notion of addresses. Thus, the producer endpoint
for a given execution of the CCNxKE protocol is one which can authoritatively
serve as the owner of a particular namespace. For example, a consumer may wish
to establish a session with a producer who owns the /company/foo namespace.
The specific end host which partakes in the protocol instance is not specified,
by virtue of the fact that all CCNxKE messages are based on well-defined names.
This enables the producer end-host which partakes in the protocol to change
based on the name of the CCNxKE messages. Consequently, to maintain
correctness, it is important that a single execution of the protocol operates
within the same trusted context; this does not mean that the same producer
end-host is required to participate in all three steps of the protocol.
Rather, it means that the end-host responding to a CCNxKE message must be
trusted by the consumer to complete the exchange. CCNxKE is designed to enable
this sort of producer migration.</t>

<t>For example, a consumer may use an initial name like ‘/parc/index.html’ that
works like an IP any cast address and could got to one of several systems.
CCNxKE allows the responding endpoint to include a localized name to ensure
that subsequent messages from the consumer come back to the same producer.
CCNxKE also allows the key exchange peer to securely hand-off the session to a
content producer peer via another name and session token once the client is
authenticated and keying material is exchanged.</t>

</section>
<section anchor="re-transmissions-timeouts-and-replay-prevention" title="Re-Transmissions, Timeouts, and Replay Prevention">

<t>CCNxKE timeouts and retransmissions are handled using the approach in <xref target="RFC6347"/>.
One primary difference is that timer values may need to be adjusted (elongated)
due to prefix shifts and the need for a producer to transfer security information
between different machines.</t>

<t>Replay attack prevention is also an optional feature, and if used, MAY be done
using one of the following two approaches at the receiver (producer):</t>

<t><list style="symbols">
  <t>IPSec AH <xref target="RFC4302"/> and ESP <xref target="RFC4303"/> style replay detection based on sliding
windows and monotonically increasing sequence numbers for windows. Note that the
sliding window inherently limits the performance of the protocol to the window size,
since only a finite number of messages may be received within a given window (based
on the window size).</t>
  <t>The optimized anti-replay algorithm of <xref target="RFC6479"/>.</t>
</list></t>

</section>
<section anchor="loss-sensitivity" title="Loss Sensitivity">

<t>CCNxKE messages are transferred using standard CCN Interest and Content Objects
and are therefore subject to loss as any datagram. This means that traffic
encrypted with keys derived from CCNxKE must be stateless. They cannot depend
on in-order arrival. This problem is solved by two mechanisms: (1) by prohibiting
stream ciphers of any kind and (2) adding sequence numbers to each message that
allow the receiver to identify and use the correct cryptographic state to decrypt
the message. Moreover, sequence numbers permit anti-replay mechanisms similar to
those used in DTLS <xref target="DTLS12"/> as mentioned above.</t>

</section>
</section>
<section anchor="the-ccnxke-protocol" title="The CCNxKE Protocol">

<t>This section describes the CCNxKE protocol in detail at the message level. The
specific encoding of those messages is given later. CCNxKE could be adapted to
different wire format encodings, such as those used by the NDN protocol.</t>

<t>The following assumptions are made about peers participating in the CCNxKE protocol:</t>

<t><list style="symbols">
  <t>Consumers know the namespace prefix of the producer for which they wish to
execute the CCNxKE protocol.</t>
  <t>CCNxKE protocol information is carried in a distinguished field outside of the payload of CCN messages.
This is done to distinguish key exchange material with application data in a message.
This is necessary for 1 RTT packets that carry both keying material and application payload.</t>
  <t>CCNxKE does not require any special behavior of intermediate systems to forward packets.</t>
  <t>CCNxKE packets generally should not be cached for significant periods of time,
as use normal protocol methods to limit caching. Part of this is achieved through
the use of consumer-specific nonces in names.</t>
</list></t>

<section anchor="round-overview" title="Round Overview">

<t>CCNxKE is composed of three rounds. The purpose of each round is described below.</t>

<t><list style="symbols">
  <t>Round 1: Perform a bare HELLO exchange to obtain the extensions (parameters) for the
key exchange provided by the producer and a source cookie to prove ownership of
the “source” of the request.</t>
  <t>Round 2: Perform the initial FULL-HELLO exchange to establish a forward-secure
key used for future communication, i.e., Interest and Content Object exchanges in
the context of the newly established session.</t>
  <t>Round 3: Send the first bit of application data and (optionally) transfer
resumption cookie(s) from the producer to the consumer.</t>
</list></t>

<t>Conceptually, there are two secrets established during a single execution
of CCNxKE:</t>

<t><list style="symbols">
  <t>Static Secret (SS): A secret which is derived in one of two ways: (a) from
the client and server ephemeral key shares and (b) from the server’s semi-static
share and the client’s ephemeral key share. Keying material derived from SS in option (a)
is not forward secure.</t>
  <t>Ephemeral Secret (ES): A secret which is derived from both the client and server
ephemeral key shares.</t>
</list></t>

<t>Depending on the mode in which CCNxKE is used, these secrets can be established
in a variety of ways. Key derivation details are outlined in Section <xref target="derive"/>.</t>

<t>All secrets are derived with the appropriate amount of randomness <xref target="RFC4086"/>.
An overview of the messages sent in each of the three rounds to
establish and use these secrets is shown in Figure <xref target="ccnxke-high"/> below. This
diagram omits some parts of each message for brevity.</t>

<figure title="High-level message flow for full CCNxKE protocol with a maximum 2-RTT delay." anchor="ccnxke-high"><artwork><![CDATA[
    Consumer                                           Producer

    HELLO:
    + SourceChallenge
                       I[/prefix/random-1]
                            -------->
                                                    HELLO-REJECT:
                                                      + Timestamp
                                                   + SourceCookie
                                                 + pinned-prefix*
                                               + ServerChallenge*
                                           + ServerConfiguration*

                      CO[/prefix/random-1]
                            <---------
    FULL-HELLO:
    + ClientKeyShare
    + SourceCookie
    + SourceProof
    + Timestamp
                    I[/pinned-prefix/random-2]
                             -------->
                                                    HELLO-ACCEPT:
                                                 + ServerKeyShare
                                                      + SessionID
                                          + [CertificateRequest*]
                                           + [CertificateVerify*]
                                     + [MovePrefix*, MoveToken)*]
                                                     + [Finished]
                    CO[/pinned-prefix/random-2]
                            <--------
                    **key exchange complete**
    Payload:
    + MoveToken*
    + MoveProof*
    + [ConsumerData]

                      I[/prefix/SessionID/[...]]
                            -------->
                                                 + NewSessionID*
                                              + NewSessionIDTag*
                                                        Payload:
                                                  [ProducerData]
                     CO[/prefix/SessionID/[...]]
                            <--------

    Repeat with data        <-------->        Repeat with data

            *  Indicates optional or situation-dependent
               messages that are not always sent.

            {} Indicates messages protected using keys
               derived from the short-term secret (SS).

            () Indicates messages protected using keys
               derived from the ephemeral secret (ES).

            [] Indicates messages protected using keys
               derived from the traffic secret (TS).
]]></artwork></figure>

<t>In the following sections, we will describe the format of each round in this
protocol in more detail.</t>

<t>We do not specify the encoding of CCNxKE data sent in Interest and Content Object
payloads. Any viable encoding will suffice, so long as both parties agree
upon the type. For example, the payload could be structured and encoded as
a JSON object, e.g.,</t>

<t>{
    “ClientKeyShare” : 0xaa,
    “SourceCookie” : 0xbb,
    “SourceProof” : 0xbb,
    …
}</t>

<t>For now, we assume some valid encoding mechanism is used to give structure
to message payloads. Moreover, we assume that these payloads are carried in a
distinguished CCNxKE payload field contained in the Interest and Content Objects.</t>

</section>
<section anchor="round-1" title="Round 1">

<t>The purpose of Round 1 is to acquire a cookie to binding the exchange to the
initial consumer and the public configuration information contained in the
ServerConfiguration structure. This information is used in the second round
when performing the actual key exchange. To that end, the format of the Round 1
message is trivial. First, the client issues an Interest with the following name</t>

<figure><artwork><![CDATA[
    /prefix/random-1
]]></artwork></figure>

<t>where random-1 is a randomly generated 64-bit nonce. This interest carries a
KEPayload with the following information:</t>

<texttable>
      <ttcol align='left'>HELLO Field</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <c>SourceChallenge</c>
      <c>A random value generated to prove ownership of the consumer’s “source”</c>
      <c>No</c>
</texttable>

<t>Upon receipt of this interest, the producer responds with a HELLO-REJECT Content Object whose
KEPayload has the following fields:</t>

<texttable>
      <ttcol align='left'>HELLO-REJECT Field</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <c>Timestamp</c>
      <c>Current server timestamp</c>
      <c>No</c>
      <c>SourceCookie</c>
      <c>A cookie that binds the consumer’s challenge to the current timestamp</c>
      <c>No</c>
      <c>PinnedPrefix</c>
      <c>A new prefix that pins the key exchange to a particular server</c>
      <c>Yes</c>
      <c>ServerConfiguration</c>
      <c>The public server configuration information</c>
      <c>Yes</c>
      <c>ServerChallenge</c>
      <c>A random value for the consumer to include in its CertificateVerify if the server requires client authentication</c>
      <c>Yes</c>
</texttable>

<t>The Timestamp and SourceCookie are used in Round 2. Their derivation is described later.
If the server provides a PinnedPrefix then the consumer must use this prefix in Round 2
in lieu of the Round 1 name prefix. (This is because the PinnedPrefix identifies a particular
endpoint that is capable of completing the key exchange.)</t>

<t>The ServerConfiguration information is a semi-static catalog of information that consumers may
use to complete future key exchanges with the producer. The fields of the ServerConfiguration
information are shown below.</t>

<texttable>
      <ttcol align='left'>ServerConfiguration Field</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <c>KEXS</c>
      <c>Supported elliptic-curve key-exchange algorithms</c>
      <c>No</c>
      <c>AEAD</c>
      <c>Supported AEAD algorithms</c>
      <c>No</c>
      <c>PUBS</c>
      <c>List of public values (for key exchange algorithm) encoded appropriately for the given group</c>
      <c>No</c>
      <c>EXPRY</c>
      <c>Expiration timestamp (i.e., longevity of the ServerConfiguration structure)</c>
      <c>No</c>
      <c>VER</c>
      <c>Version of the CONFIG structure</c>
      <c>Yes</c>
      <c>CERT</c>
      <c>Server certificate</c>
      <c>No</c>
      <c>SIG</c>
      <c>Signature produced by the server over the entire ServerConfiguration message</c>
      <c>No</c>
</texttable>

<t>The KEXS is a data structure that enumerates the elliptic curve key-exchange algorithms that
are supported by the producer (see <xref target="QUIC"/> for more details). Currently, only the following
curves are supported:</t>

<t><list style="symbols">
  <t>Curve25519</t>
  <t>P-256</t>
</list></t>

<t>Selection criteria for these curves is given at http://safecurves.cr.yp.to/.</t>

<t>The AEAD structure enumerates the supported AEAD algorithms used for symmetric-key
authenticated encryption after the session has been established. Currently, the
only supported algorithms are:</t>

<t><list style="symbols">
  <t>AES-GCM-(128,192,256) <xref target="GCM"/>: a 12-byte tag is used, where the first four bytes are taken
from the FSK key-derivation step and the last eight are taken from the initial consumer
nonce.</t>
  <t>Salsa20 <xref target="SALSA20"/> (stream cipher) with Poly1305 (MAC).</t>
</list></t>

<t>The key sizes and related parameters are provided with the AEAD tag in the CONFIG
structure.</t>

<t>The PUBS structure contains the public values for the initial key exchange. Both
Curve25519 and P-256 provide their own set of accepted parameters. Thus, the only
values provided here are the random curve elements used in the DH operation.</t>

<t>The EXPRY value is an absolute timestamp that indicates the longevity of the
ServerConfiguration.</t>

<t>The CERT and SIG values contain the server’s certificate and a signature generated
over the entire ServerConfiguration field. This signature is generated with the
corresponding private key.</t>

</section>
<section anchor="round-2" title="Round 2">

<t>The purpose of Round 2 is to perform the initial FULL-HELLO exchange to establish a
forward-secure key used for future communication. It is assumed that
the consumer already has the ServerConfiguration information that is provided from
the producer in Round 1. It is also assumed that the consumer has a</t>

<t>Moreover, assume that nonce2 is a ephemeral nonce provided by the
producer in Round 1. Then, the consumer issues an Interest with the following name:</t>

<figure><artwork><![CDATA[
    /prefix/random-2
]]></artwork></figure>

<t>and a KEPayload with the following information:</t>

<texttable>
      <ttcol align='left'>FULL-HELLO Field</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <c>ClientKeyShare</c>
      <c>The client’s key share for the key exchange</c>
      <c>No</c>
      <c>SourceCookie</c>
      <c>SourceCookie provided by the server in Round 1</c>
      <c>No</c>
      <c>SourceProof</c>
      <c>The SourceCookie construction proof provided by the client</c>
      <c>No</c>
      <c>Timestamp</c>
      <c>The timestamp provided by the server in Round 1</c>
      <c>No</c>
      <c>ConsumerPrefix</c>
      <c>The consumer’s prefix that can be used for the producer to send interests to the consumer</c>
      <c>Yes</c>
      <c>PreSharedKey</c>
      <c>A pre-shared key that can be configured between a consumer and producer</c>
      <c>Yes</c>
      <c>ResumptionCookie</c>
      <c>The ResumptionCookie derived from a past session</c>
      <c>Yes</c>
      <c>{MoveChallenge}</c>
      <c>A move challenge generated identically to the SourceChallenge</c>
      <c>Yes</c>
      <c>{AlgChoice}</c>
      <c>Algorithm (KEXS and AEAD) options choice (a list of tags echoed from the ServerConfiguration)</c>
      <c>No</c>
      <c>{Proof}</c>
      <c>Proof of demand (i.e., a sorted list of types of proof the consumer will expect)</c>
      <c>No</c>
      <c>{CCS}</c>
      <c>Compressed certificate set that the consumer possesses</c>
      <c>No</c>
      <c>{ConsumerData}</c>
      <c>Application data encrypted under a key derived from SS (in a 1-RTT exchange)</c>
      <c>Yes</c>
      <c>ServerNameIndication</c>
      <c>A server name indication (as a CCNxName) defined in Section 3 of <xref target="RFC6066"/></c>
      <c>Yes</c>
      <c>Certificate</c>
      <c>The client’s certificate</c>
      <c>Yes</c>
      <c>CertificateVerify</c>
      <c>A signature generated over the entire FULL-HELLO message</c>
      <c>Yes</c>
</texttable>

<t>((TODO: provide more details about each of these fields))</t>

<t>Upon receipt of this interest, the producer performs the DH computation
to compute ES and SS, decrypts all protected fields in the consumer’s KEPayload, and validates the
algorithm choice selection (AlgChoice). If any of these steps fail, the producer
replies with with a HELLO-REJECT Content Object whose KEPayload contains
a REJ flag and the reason of the error. The REJ flag and value are encrypted
by the SS (if possible).</t>

<t>If the above steps complete without failure or error, then the producer responds with a
Content Object whose KEPayload has the following fields:</t>

<texttable>
      <ttcol align='left'>HELLO-ACCEPT Field</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Optional?</ttcol>
      <c>SessionID</c>
      <c>Cleartext session identifier</c>
      <c>No</c>
      <c>ServerKeyShare</c>
      <c>Server’s key share for the ES derivation</c>
      <c>No</c>
      <c>{ServerExtensions}</c>
      <c>Additional extensions provided by the server, encrypted under ES</c>
      <c>Yes</c>
      <c>[ResumptionCookie]</c>
      <c>Resumption cookie encrypted under a TS-derived key</c>
      <c>Yes</c>
      <c>{(MovePrefix,MoveToken)}</c>
      <c>Third CCNxName prefix and token to use when moving to session establishment</c>
      <c>Yes</c>
      <c>CertificateRequest*</c>
      <c>Server certificate that matches the type of proof provided by the client</c>
      <c>Yes</c>
      <c>CertificateVerify*</c>
      <c>Signature generated over the entire HELLO-ACCEPT message</c>
      <c>Yes</c>
</texttable>

<t>If a MovePrefix and MoveToken tuple is provided then in the HELLO-ACCEPT message then
a CertificateVerify (signature) MUST also be provided in the response.</t>

</section>
<section anchor="round-3" title="Round 3">

<t>In Round 3, the consumer sends interests whose name and optional Payload are
encrypted using one of the forward-secure keys derived after Round 2. In normal operation,
the producer will respond with Content Objects whose Payloads are encrypted using
a different forward-secure key. That is, interests and Content Objects are encrypted
and authenticated using two separate keys. The producer may also optionally provide
a new resumption cookie (RC) with a Content Object response. This is used to keep
the consumer’s resumption cookie fresh and to also support 0 RTT resumption. In this
case, the producer’s Content Object response has the following fields:</t>

<t><list style="symbols">
  <t>Payload: the actual Content Object payload data encrypted with the producer’s
forward-secure key.</t>
  <t>ResumptionCookie: A new resumption cookie to be used for resuming this session in the future.</t>
</list></t>

<t>The producer is free to choose the frequency at which new resumption cookies are
issued to the consumer.</t>

<t>The producer may also reply with a new SessionID. This is done if the client presented
a MoveToken and MoveProof. A NewSessionID must be accompanied with a NewSessionIDTag,
which is equal to the HMAC of NewSessionID computed with the traffic-secret key.
A client MUST then use NewSessionID instead of SessionID after verifying the
NewSessionIDTag.</t>

</section>
</section>
<section anchor="alternative-exchanges" title="Alternative Exchanges">

<t>CCNxKE also supports one-round key exchange and session resumption. These variants
are outlined below. The key material differences are described later. In these
variants, we use message ExchangeSourceCookie to denote the following exchange:</t>

<figure title="SourceCookie exchange -- ExchangeSourceCookie." anchor="cookieexchange"><artwork><![CDATA[
Consumer                                           Producer

HELLO:
+ SourceChallenge
                   I[/prefix/random-1]
                        -------->
                                                HELLO-REJECT:
                                                  + Timestamp
                                               + SourceCookie
                                             ServerChallenge*
                                         ServerConfiguration*

                   CO[/prefix/random-1]
                        <---------
]]></artwork></figure>

<section anchor="one-rtt-exchange" title="One-RTT Exchange">

<figure title="Exchange with 1 RTT." anchor="onertt-exchange"><artwork><![CDATA[
    Consumer                                           Producer
                            -------->
                       ExchangeSourceCookie
                            <---------
    FULL-HELLO:
    + ClientKeyShare
    + SourceCookie
    + SourceProof
    + Timestamp
    + Certificate*
    + CertificateVerify*
    + {ConsumerData*}
                       I[/prefix/random-2]
                             -------->
                                                    HELLO-ACCEPT:
                                                 + ServerKeyShare
                                                      + SessionID
                                              + [ServerExtensions]
                                              + [ResumptionCookie]
                                           + [CertificateRequest*]
                                            + [CertificateVerify*]
                                       + [MovePrefix*, MoveToken*]
                                                      + [Finished]
                       CO[/prefix/random-2]
                            <--------
                    **key exchange complete**
    Send encrypted data   <-------->   Send encrypted data

            *  Indicates optional or situation-dependent
               messages that are not always sent.

            {} Indicates messages protected using keys
               derived from the short-term secret (SS).

            () Indicates messages protected using keys
               derived from the ephemeral secret (ES).

            [] Indicates messages protected using keys
               derived from the traffic secret (TS).
]]></artwork></figure>

<t>As with TLS, the initial application data is protected with the</t>

</section>
</section>
<section anchor="resumption-and-psk-mode" title="Resumption and PSK Mode">

<t>In this mode, the client uses its ResumptionCookie to re-create a previous
session. The client also provides a key share in case the server opts to fall back
and establish a fresh key. If the server accepts the ResumptionCookie then it
MUST issue a new SessionID and ResumptionCookie for future use with the client.</t>

<figure title="Exchange with 1 RTT." anchor="resumption-exchange"><artwork><![CDATA[
    Consumer                                           Producer
                            -------->
                       ExchangeSourceCookie
                            <---------
    FULL-HELLO:
    + ClientKeyShare
    + SourceCookie
    + SourceProof
    + Timestamp
    + PreSharedKey
    + ResumptionCookie
                       I[/prefix/random-2]
                             -------->
                                                    HELLO-ACCEPT:
                                                 + ServerKeyShare
                                                      + SessionID
                                              + [ServerExtensions]
                                              + [ResumptionCookie]
                                       + [MovePrefix*, MoveToken*]
                                                      + [Finished]
                       CO[/prefix/random-2]
                            <--------
                    **key exchange complete**
    Send encrypted data   <-------->   Send encrypted data

            *  Indicates optional or situation-dependent
               messages that are not always sent.

            {} Indicates messages protected using keys
               derived from the short-term secret (SS).

            () Indicates messages protected using keys
               derived from the ephemeral secret (ES).

            [] Indicates messages protected using keys
               derived from the traffic secret (TS).
]]></artwork></figure>

</section>
<section anchor="derive" title="Secret Derivation">

<t>In this section we describe how secrets used in the protocol are derived.
We cover the SourceCookie, MoveToken, SessionID, ResumptionCookie, and the
actual traffic keys.</t>

<section anchor="sourcecookie-derivation" title="SourceCookie Derivation">

<t>The intention of the SourceCookie is to prove that a client is sending interests
from a legitimate location before any server computation is done. Without this,
a Denial of Service attack could be carried out by sending interests to the server
with the intention of triggering wasted computation. TCP-based protocols prevent
this with the SYN-flood cookie mechanism. Protocols based on UDP use cookies that
bind to the client address <xref target="DTLS12"/>. Since CCN lacks any notion of a source address,
these cookie mechanisms do not apply. Instead, we need a way for clients to prove
that they initiated a key exchange from the “same origin.” We now describe the cookie
mechanism that gives us this guarantee.</t>

<t>Instead of a source address, a SourceCookie is computed using a challenge provided
by a consumer. To create this challenge, a consumer first generates a a randomly
generated 256-bit string X. The consumer then computes SourceChallenge = SHA256(X).
Upon receipt of this challenge, the producer generates a SourceCookie as follows:</t>

<figure><artwork><![CDATA[
SourceCookie = HMAC(k, SourceChallenge || timestamp)
]]></artwork></figure>

<t>where timestamp is the current server timestamp and k is the server’s secret key.
To prove ownership of the “source,” the consumer then provides the SourceCookie
and a SourceProof in the round 2 Interest. The SourceProof is set to the value X
used to derive the SourceChallenge. Upon receipt of the SourceProof, the server
verifies the following equality:</t>

<figure><artwork><![CDATA[
SourceCookie = HMAC(k, SHA256(SourceProof) || timestamp)
]]></artwork></figure>

<t>If this check passes, then the server continues with the computationally expensive
part of the key exchange protocol.</t>

</section>
<section anchor="move-derivation" title="Move Derivation">

<t>The MoveChallenge and MoveProof are computed identically to the SourceChallenge
and SourceProof. The MoveToken, however, is left as an opaque bit string. Extensions
may be specified to describe how to compute this value.</t>

</section>
<section anchor="sessionid-and-resumptioncookie-properties-derivation-and-usage" title="SessionID and ResumptionCookie Properties, Derivation, and Usage">

<t>The purpose of the session identifier SessionID is to uniquely
identify a single session for the producer and consumer. A Producer MAY use
a random bit string or MAY use the method described in this section or MAY
use another proprietary method to distinguish clients.</t>

<t>We provide a more secure creation of the SessionID since it is used
with the ResumptionCookie derivation (defined later). Specifically,
the SessionID is derived as the encryption of the hash digest of a server
secret, TS, and an optional prefix (e.g., MovePrefix).</t>

<t>Encryption is done by the using a long-term secret key owned by the server used
for only this purpose, i.e., it is not used for consumer traffic encryption.
Mechanically, this derivation is:</t>

<figure><artwork><![CDATA[
SessionID = Enc(k1, H(TS || (Prefix3))),
]]></artwork></figure>

<t>where k1 is the long-term producer key.</t>

<t>For the resumption cookie, we require that it must be able to be used to
recover the TS for a given session. Without TS, correct session communication
is not possible. We derive it as the encryption of the hash digest
of the server secret, TS, and the optional (MovePrefix, MoveToken) tuple
(if created for the session). The producer must use a long-term secret key
for this encryption. Mechanically, this derivation is:</t>

<figure><artwork><![CDATA[
ResumptionCookie = Enc(k2, TS || ( (Prefix3 || MoveToken) )),
]]></artwork></figure>

<t>where k2 is again a long-term producer key. Note that it may be the case that
k1 = k2 (see above), though this is not required.</t>

<t>With this SessionID and ResumptionCookie, the consumer then resumes a session by providing
both the SessionID and ResumptionCookie to the producer. This is done to prove to the producer that
the consumer who knows the SessionID is also in possession of the correct ResumptionCookie.
The producer verifies this by computing</t>

<figure><artwork><![CDATA[
(TS || ( (Prefix3 || MoveToken) )) = Dec(k2, ResumptionCookie)
]]></artwork></figure>

<t>and checking the following equality</t>

<figure><artwork><![CDATA[
SessionID = Enc(k1, H(TS || (Prefix3)))
]]></artwork></figure>

<t>If equality holds, the producer uses the TS recovered from ResumptionCookie to
re-initialize the previous session with the consumer.</t>

</section>
<section anchor="key-derivation" title="Key Derivation">

<t>CCNxKE adopts the key schedule and derivation techniques defined in TLS 1.3 <xref target="TLS13"/>.
Specifically, it uses the SS and ES to establish a common master secret (MS) and,
from that, the traffic secret (TS). These dependencies are shown below.</t>

<figure><artwork><![CDATA[
+------+           +------+
| KE-1 |           | KE-2 |
+------+           +----+-+
    |                   |
    |                   |
    |                   |
+---v--+           +----v-+
|  SS  +---+    +--+  ES  |
+------+   |    |  +------+
           |    |
           |    |
         +-v----v-|
         |   MK   |
         +---+----+
             |
             |
             |
           +-v--+
           | TS |
           +----+
]]></artwork></figure>

<t>In this figure, KE-1 and KE-2 are two “sources” of keying material. The following
table shows what these two sources are in different key exchange scenarios.</t>

<texttable>
      <ttcol align='left'>Key Exchange</ttcol>
      <ttcol align='left'>KE-1</ttcol>
      <ttcol align='left'>KE-2</ttcol>
      <c>Full handshake</c>
      <c>ClientKeyShare and ServerKeyShare DH</c>
      <c>ClientKeyShare and ServerKeyShare DH</c>
      <c>Handshake with 1-RTT</c>
      <c>ClientKeyShare and ServerConfiguration public share DH</c>
      <c>ClientKeyShare and ServerKeyShare DH</c>
      <c>PSK</c>
      <c>Pre-shared key</c>
      <c>Pre-shared key</c>
</texttable>

<t>Given the values for SS and ES, the remaining derivation steps are below as defined in <xref target="TLS13"/>.
They are repeated here for posterity.</t>

<t><list style="numbers">
  <t>xSS = HKDF-Extract(0, SS). Note that HKDF-Extract always produces a value the
 same length as the underlying hash function.</t>
  <t>xES = HKDF-Extract(0, ES)</t>
  <t>mSS = HKDF-Expand-Label(xSS, “expanded static secret”,
                             handshake_hash, L)</t>
  <t>mES = HKDF-Expand-Label(xES, “expanded ephemeral secret”,
                             handshake_hash, L)</t>
  <t>master_secret = HKDF-Extract(mSS, mES)</t>
  <t>traffic_secret_0 = HKDF-Expand-Label(master_secret, “traffic secret”, handshake_hash, L)</t>
</list></t>

<t>In all computations, the value “handshake_hash” is defined as the SHA256 hash
digest of all CCNxKE messages contained up to the point of derivation. More details
are given in Section 7.3.1 of <xref target="TLS13"/>.</t>

<t>Updating the traffic secret using the re-key message (defined later) increments
traffic_secret_N to traffic_secret_(N+1). This update procedure works as follows:</t>

<t>traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, “traffic
                                        secret”, “”, L)</t>

</section>
<section anchor="secret-generation-and-lifecycle" title="Secret Generation and Lifecycle">

<t>The secrets (keys and IVs) used to encrypt and authenticate traffic are derived from the traffic
secret. The explicit derivation formula, as is defined in <xref target="TLS13"/>, is as follows:</t>

<t>secret = HKDF-Expand-Label(Secret, phase + “, “ + purpose, handshake_context, key_length)</t>

<t>In this context, secret can be a key or IV.
This formula is used when deriving keys based on a non-forward-secure SS and
the forward-secure TS. The following table enumerates the values for “phase”,
and “handshake_context” to be used when defining keys for different purposes.</t>

<texttable>
      <ttcol align='left'>Record Type</ttcol>
      <ttcol align='left'>Secret</ttcol>
      <ttcol align='left'>Phase</ttcol>
      <ttcol align='left'>Handshake Context</ttcol>
      <c>1-RTT Handshake</c>
      <c>xSS</c>
      <c>“early handshake key expansion”</c>
      <c>HELLO + ServerConfiguration + Server Certificate</c>
      <c>1-RTT Data</c>
      <c>xSS</c>
      <c>“early application data key expansion”</c>
      <c>HELLO + ServerConfiguration + Server Certificate</c>
      <c>Application Data</c>
      <c>TS</c>
      <c>“application data key expansion”</c>
      <c>HELLO … Finished</c>
</texttable>

<t>Moreover, the following table indicates the values of “purpose” used in the
generation of each secret.</t>

<texttable>
      <ttcol align='left'>Secret</ttcol>
      <ttcol align='left'>Purpose</ttcol>
      <c>Client Write Key</c>
      <c>“client write key”</c>
      <c>Server Write Key</c>
      <c>“server write key”</c>
      <c>Client Write IV</c>
      <c>“client write IV”</c>
      <c>Server Write IV</c>
      <c>“server write IV”</c>
</texttable>

<t>(( TODO: should we add examples for each of the above variants? ))</t>

</section>
</section>
<section anchor="re-key-message" title="Re-Key Message">

<t>Either the client and server can trigger a key update by sending an Interest or
Content Object with a KEPayload field containing the flag KeyUpdate. The KEPayload
will be encrypted by the traffic key. Upon receipt, the recipient MUST update the
traffic secret as defined above and re-compute the traffic encryption and authentication
keys. The previous traffic key must be securely discarded.</t>

</section>
<section anchor="application-data-protocol" title="Application Data Protocol">

<t>Once traffic keys and the associated IVs are derived from the CCNxKE protocol,
all subsequent Interest and Content Object messages are encrypted. Packet encryption
uses the TLV encapsulation mechanism specified in <xref target="TLVENCAP"/>. For Interest
encryption, the Salt in <xref target="TLVENCAP"/> is set to the packet sequence number.
The same substitution is done for Content Object encryption. Similarly, the
KeyId field is substituted with the SessionID derived by the CCNxKE protocol.
Packet sequence numbers are 64-bit numbers initialized to 0 when after the
traffic secret is calculated. Each message increments and uses the sequence
number when sending a new datagram (Interest). The sequence number for an Interest
matches that of the Content Object response.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>For CCNxKE to be able to provide a secure connection, both the consumer and producer
systems, keys, and applications must be secure. In addition, the implementation
must be free of security errors.</t>

<t>The system is only as strong as the weakest key exchange and authentication
algorithm supported, and only trustworthy cryptographic functions should be
used. Short public keys and anonymous servers should be used with great
caution. Implementations and users must be careful when deciding which
certificates and certificate authorities are acceptable; a dishonest
certificate authority can do tremendous damage.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC4086' target='http://www.rfc-editor.org/info/rfc4086'>
<front>
<title>Randomness Requirements for Security</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /></author>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></author>
<date year='2005' month='June' />
<abstract><t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>



<reference  anchor='RFC5869' target='http://www.rfc-editor.org/info/rfc5869'>
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5869'/>
<seriesInfo name='DOI' value='10.17487/RFC5869'/>
</reference>



<reference  anchor='RFC2631' target='http://www.rfc-editor.org/info/rfc2631'>
<front>
<title>Diffie-Hellman Key Agreement Method</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='1999' month='June' />
<abstract><t>This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2631'/>
<seriesInfo name='DOI' value='10.17487/RFC2631'/>
</reference>



<reference  anchor='RFC4987' target='http://www.rfc-editor.org/info/rfc4987'>
<front>
<title>TCP SYN Flooding Attacks and Common Mitigations</title>
<author initials='W.' surname='Eddy' fullname='W. Eddy'><organization /></author>
<date year='2007' month='August' />
<abstract><t>This document describes TCP SYN flooding attacks, which have been well-known to the community for several years.  Various countermeasures against these attacks, and the trade-offs of each, are described.  This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4987'/>
<seriesInfo name='DOI' value='10.17487/RFC4987'/>
</reference>



<reference  anchor='RFC6066' target='http://www.rfc-editor.org/info/rfc6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2011' month='January' />
<abstract><t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, &quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;.  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6066'/>
<seriesInfo name='DOI' value='10.17487/RFC6066'/>
</reference>


<reference anchor="SALSA20" >
  <front>
    <title>Salsa20 specification</title>
    <author initials="D." surname="Bernstein">
      <organization></organization>
    </author>
    <date year="2005" month="April"/>
  </front>
  <seriesInfo name="www.http://cr.yp.to/snuffle/spec.pdf" value=""/>
</reference>




<reference  anchor='RFC6479' target='http://www.rfc-editor.org/info/rfc6479'>
<front>
<title>IPsec Anti-Replay Algorithm without Bit Shifting</title>
<author initials='X.' surname='Zhang' fullname='X. Zhang'><organization /></author>
<author initials='T.' surname='Tsou' fullname='T. Tsou'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP).  The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6479'/>
<seriesInfo name='DOI' value='10.17487/RFC6479'/>
</reference>



<reference  anchor='RFC4302' target='http://www.rfc-editor.org/info/rfc4302'>
<front>
<title>IP Authentication Header</title>
<author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author>
<date year='2005' month='December' />
<abstract><t>This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6.  This document obsoletes RFC 2402 (November 1998).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4302'/>
<seriesInfo name='DOI' value='10.17487/RFC4302'/>
</reference>



<reference  anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>



<reference  anchor='RFC4303' target='http://www.rfc-editor.org/info/rfc4303'>
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author>
<date year='2005' month='December' />
<abstract><t>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4303'/>
<seriesInfo name='DOI' value='10.17487/RFC4303'/>
</reference>


<reference anchor="QUIC" >
  <front>
    <title>QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2</title>
    <author initials="J." surname="Iyengar">
      <organization>Google</organization>
    </author>
    <author initials="I." surname="Swett">
      <organization>Google</organization>
    </author>
    <date year="2015" month="December" day="19"/>
  </front>
</reference>
<reference anchor="TLS13" target="https://tools.ietf.org/html/draft-ietf-tls-tls13-11">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
    </author>
    <date year="2015" month="December" day="28"/>
  </front>
</reference>
<reference anchor="DTLS12" target="https://tools.ietf.org/html/rfc6347">
  <front>
    <title>Datagram Transport Layer Security Version 1.2</title>
    <author initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
    </author>
    <author initials="N." surname="Modadugu">
      <organization>Google, Inc.</organization>
    </author>
    <date year="2012" month="January"/>
  </front>
</reference>
<reference anchor="GCM" >
  <front>
    <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
    <author initials="M." surname="Dworkin">
      <organization></organization>
    </author>
    <date year="2007" month="November"/>
  </front>
  <seriesInfo name="NIST" value="Special Publication 800-38D"/>
</reference>
<reference anchor="DH" >
  <front>
    <title>New Directions in Cryptography</title>
    <author initials="W." surname="Diffie">
      <organization></organization>
    </author>
    <author initials="M." surname="Hellman">
      <organization></organization>
    </author>
    <date year="1977" month="June"/>
  </front>
  <seriesInfo name="IEEE Transactions on Information Theory, V.IT-22 n.6" value=""/>
</reference>
<reference anchor="RSA" >
  <front>
    <title>A Method for Obtaining Digital Signatures and Public-Key Cryptosystems</title>
    <author initials="R." surname="Rivest">
      <organization></organization>
    </author>
    <author initials="A." surname="Shamir">
      <organization></organization>
    </author>
    <author initials="L.M." surname="Adleman">
      <organization></organization>
    </author>
    <date year="1978" month="February"/>
  </front>
  <seriesInfo name="Communications of the ACM" value="v. 21, n. 2, pp. 120-126."/>
</reference>
<reference anchor="ECDSA" >
  <front>
    <title>Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
    <author >
      <organization>American National Standards Institute</organization>
    </author>
    <date year="2005" month="November"/>
  </front>
  <seriesInfo name="ANSI" value="ANS X9.62-2005"/>
</reference>
<reference anchor="CCNxMessages" target="https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-01">
  <front>
    <title>CCNx Messages in TLV Format</title>
    <author initials="M." surname="Mosko">
      <organization>PARC, Inc.</organization>
    </author>
    <author initials="I." surname="Solis">
      <organization>PARC, Inc.</organization>
    </author>
    <date year="2016" month="January" day="11"/>
  </front>
</reference>
<reference anchor="TLVENCAP" target="https://github.com/PARC/ccnx-tlvencap-rfc">
  <front>
    <title>CCNx Packet Encapsulation</title>
    <author initials="M." surname="Mosko">
      <organization>PARC, Inc.</organization>
    </author>
    <author initials="C." surname="Wood">
      <organization>PARC, Inc.</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References'>





<reference  anchor='RFC5077' target='http://www.rfc-editor.org/info/rfc5077'>
<front>
<title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></author>
<author initials='H.' surname='Zhou' fullname='H. Zhou'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state.  The TLS server encapsulates the session state into a ticket and forwards it to the client.  The client can subsequently resume a session using the obtained ticket.  This document obsoletes RFC 4507.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5077'/>
<seriesInfo name='DOI' value='10.17487/RFC5077'/>
</reference>


<reference anchor="HASHCHAIN" >
  <front>
    <title>Password Authentication with Insecure Communication</title>
    <author >
      <organization>L. Lamport</organization>
    </author>
    <date year="1981" month="November"/>
  </front>
  <seriesInfo name="ANSI" value="Communications of the ACM 24.11, pp 770-772"/>
</reference>


    </references>



  </back>
</rfc>