draft-ietf-tcpinc-tcpcrypt-08.txt   draft-ietf-tcpinc-tcpcrypt-09.txt 
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft Google Internet-Draft Google
Intended status: Experimental D. Giffin Intended status: Experimental D. Giffin
Expires: April 24, 2018 Stanford University Expires: May 6, 2018 Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Stanford University Stanford University
Q. Slack Q. Slack
Sourcegraph Sourcegraph
E. Smith E. Smith
Kestrel Institute Kestrel Institute
October 21, 2017 November 2, 2017
Cryptographic protection of TCP Streams (tcpcrypt) Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-08 draft-ietf-tcpinc-tcpcrypt-09
Abstract Abstract
This document specifies tcpcrypt, a TCP encryption protocol designed This document specifies tcpcrypt, a TCP encryption protocol designed
for use in conjunction with the TCP Encryption Negotiation Option for use in conjunction with the TCP Encryption Negotiation Option
(TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating
resegmentation, NATs, and other manipulations of the TCP header. The resegmentation, NATs, and other manipulations of the TCP header. The
protocol is self-contained and specifically tailored to TCP protocol is self-contained and specifically tailored to TCP
implementations, which often reside in kernels or other environments implementations, which often reside in kernels or other environments
in which large external software dependencies can be undesirable. in which large external software dependencies can be undesirable.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
tcpcrypt connection. tcpcrypt connection.
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 https://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 April 24, 2018. This Internet-Draft will expire on May 6, 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.8. Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . 13 3.8. Re-Keying . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . 14 3.9. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . 14
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Key-Exchange Messages . . . . . . . . . . . . . . . . . . 15 4.1. Key-Exchange Messages . . . . . . . . . . . . . . . . . . 15
4.2. Encryption Frames . . . . . . . . . . . . . . . . . . . . 17 4.2. Encryption Frames . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Associated Data . . . . . . . . . . . . . . . . . . . 18 4.2.2. Associated Data . . . . . . . . . . . . . . . . . . . 18
4.2.3. Frame Nonce . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. Frame Nonce . . . . . . . . . . . . . . . . . . . . . 19
4.3. Constant Values . . . . . . . . . . . . . . . . . . . . . 19 4.3. Constant Values . . . . . . . . . . . . . . . . . . . . . 19
5. Key-Agreement Schemes . . . . . . . . . . . . . . . . . . . . 19 5. Key-Agreement Schemes . . . . . . . . . . . . . . . . . . . . 19
6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 20 6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Asymmetric Roles . . . . . . . . . . . . . . . . . . . . 23 8.1. Asymmetric Roles . . . . . . . . . . . . . . . . . . . . 24
8.2. Verified Liveness . . . . . . . . . . . . . . . . . . . . 23 8.2. Verified Liveness . . . . . . . . . . . . . . . . . . . . 24
8.3. Mandatory Key-Agreement Schemes . . . . . . . . . . . . . 24 8.3. Mandatory Key-Agreement Schemes . . . . . . . . . . . . . 25
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Requirements Language 1. Requirements Language
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
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Introduction 2. Introduction
skipping to change at page 5, line 12 skipping to change at page 5, line 12
decryption is performed, the tag allows authentication of the decryption is performed, the tag allows authentication of the
encrypted data and of optional, associated plaintext data. encrypted data and of optional, associated plaintext data.
3.2. Protocol Negotiation 3.2. Protocol Negotiation
Tcpcrypt depends on TCP-ENO [I-D.ietf-tcpinc-tcpeno] to negotiate Tcpcrypt depends on TCP-ENO [I-D.ietf-tcpinc-tcpeno] to negotiate
whether encryption will be enabled for a connection, and also which whether encryption will be enabled for a connection, and also which
key-agreement scheme to use. TCP-ENO negotiates the use of a key-agreement scheme to use. TCP-ENO negotiates the use of a
particular TCP encryption protocol or _TEP_ by including protocol particular TCP encryption protocol or _TEP_ by including protocol
identifiers in ENO suboptions. This document associates four TEP identifiers in ENO suboptions. This document associates four TEP
identifiers with the tcpcrypt protocol, as listed in Table 2. Each identifiers with the tcpcrypt protocol, as listed in Table 4. Each
identifier indicates the use of a particular key-agreement scheme, identifier indicates the use of a particular key-agreement scheme,
with an associated CPRF and length parameters. Future standards may with an associated CPRF and length parameters. Future standards may
associate additional TEP identifiers with tcpcrypt, following the associate additional TEP identifiers with tcpcrypt, following the
assignment policy specified by TCP-ENO. assignment policy specified by TCP-ENO.
An active opener that wishes to negotiate the use of tcpcrypt An active opener that wishes to negotiate the use of tcpcrypt
includes an ENO option in its SYN segment. That option includes includes an ENO option in its SYN segment. That option includes
suboptions with tcpcrypt TEP identifiers indicating the key-agreement suboptions with tcpcrypt TEP identifiers indicating the key-agreement
schemes it is willing to enable. The active opener MAY additionally schemes it is willing to enable. The active opener MAY additionally
include suboptions indicating support for encryption protocols other include suboptions indicating support for encryption protocols other
skipping to change at page 6, line 25 skipping to change at page 6, line 25
"v" bits in ENO suboptions, so if host A offers resumption with a "v" bits in ENO suboptions, so if host A offers resumption with a
particular TEP and host B replies with a non-resumption suboption particular TEP and host B replies with a non-resumption suboption
with the same TEP, that may become the negotiated TEP and fresh key with the same TEP, that may become the negotiated TEP and fresh key
agreement will be performed. That is, sending a resumption suboption agreement will be performed. That is, sending a resumption suboption
also implies willingness to perform fresh key agreement with the also implies willingness to perform fresh key agreement with the
indicated TEP. indicated TEP.
As required by TCP-ENO, once a host has both sent and received an ACK As required by TCP-ENO, once a host has both sent and received an ACK
segment containing a valid ENO option, encryption MUST be enabled and segment containing a valid ENO option, encryption MUST be enabled and
plaintext application data MUST NOT ever be exchanged on the plaintext application data MUST NOT ever be exchanged on the
connection. If the negotiated TEP is among those listed in Table 2, connection. If the negotiated TEP is among those listed in Table 4,
a host MUST follow the protocol described in this document. a host MUST follow the protocol described in this document.
3.3. Key Exchange 3.3. Key Exchange
Following successful negotiation of a tcpcrypt TEP, all further Following successful negotiation of a tcpcrypt TEP, all further
signaling is performed in the Data portion of TCP segments. Except signaling is performed in the Data portion of TCP segments. Except
when resumption was negotiated (described below in Section 3.5), the when resumption was negotiated (described below in Section 3.5), the
two hosts perform key exchange through two messages, "Init1" and two hosts perform key exchange through two messages, "Init1" and
"Init2", at the start of the data streams of host A and host B, "Init2", at the start of the data streams of host A and host B,
respectively. These messages may span multiple TCP segments and need respectively. These messages may span multiple TCP segments and need
not end at a segment boundary. However, the segment containing the not end at a segment boundary. However, the segment containing the
last byte of an "Init1" or "Init2" message MUST have TCP's push flag last byte of an "Init1" or "Init2" message MUST have TCP's push flag
(PSH) set. (PSH) set.
The key exchange protocol, in abstract, proceeds as follows: The key exchange protocol, in abstract, proceeds as follows:
A -> B: Init1 = { INIT1_MAGIC, sym-cipher-list, N_A, PK_A } A -> B: Init1 = { INIT1_MAGIC, sym_cipher_list, N_A, PK_A }
B -> A: Init2 = { INIT2_MAGIC, sym-cipher, N_B, PK_B } B -> A: Init2 = { INIT2_MAGIC, sym_cipher, N_B, PK_B }
The concrete format of these messages is specified in Section 4.1. The concrete format of these messages is specified in Section 4.1.
The parameters are defined as follows: The parameters are defined as follows:
o "INIT1_MAGIC", "INIT2_MAGIC": constants defined in Table 1. o "INIT1_MAGIC", "INIT2_MAGIC": constants defined in Table 1.
o "sym-cipher-list": a list of symmetric ciphers (AEAD algorithms) o "sym_cipher_list": a list of symmetric ciphers (AEAD algorithms)
acceptable to host A. These are specified in Table 3. acceptable to host A. These are specified in Table 5.
o "sym-cipher": the symmetric cipher selected by host B from the o "sym_cipher": the symmetric cipher selected by host B from the
"sym-cipher-list" sent by host A. "sym_cipher_list" sent by host A.
o "N_A", "N_B": nonces chosen at random by hosts A and B, o "N_A", "N_B": nonces chosen at random by hosts A and B,
respectively. respectively.
o "PK_A", "PK_B": ephemeral public keys for hosts A and B, o "PK_A", "PK_B": ephemeral public keys for hosts A and B,
respectively. These, as well as their corresponding private keys, respectively. These, as well as their corresponding private keys,
are short-lived values that SHOULD be refreshed periodically. The are short-lived values that SHOULD be refreshed periodically. The
private keys SHOULD NOT ever be written to persistent storage. private keys SHOULD NOT ever be written to persistent storage.
The ephemeral secret ("ES") is the result of the key-agreement The ephemeral secret ("ES") is the result of the key-agreement
skipping to change at page 8, line 27 skipping to change at page 8, line 27
In the first session derived from fresh key-agreement, keys "k_ab[j]" In the first session derived from fresh key-agreement, keys "k_ab[j]"
are used by host A to encrypt and host B to decrypt, while keys are used by host A to encrypt and host B to decrypt, while keys
"k_ba[j]" are used by host B to encrypt and host A to decrypt. In a "k_ba[j]" are used by host B to encrypt and host A to decrypt. In a
resumed session, as described more thoroughly below in Section 3.5, resumed session, as described more thoroughly below in Section 3.5,
each host uses the keys in the same way as it did in the original each host uses the keys in the same way as it did in the original
session, regardless of its role in the current session: for example, session, regardless of its role in the current session: for example,
if a host played role "A" in the first session, it will use keys if a host played role "A" in the first session, it will use keys
"k_ab[j]" to encrypt in each derived session. "k_ab[j]" to encrypt in each derived session.
The value "ae_keylen" depends on the authenticated-encryption The value "ae_keylen" depends on the authenticated-encryption
algorithm selected, and is given under "Key Length" in Table 3. algorithm selected, and is given under "Key Length" in Table 5.
After host B sends "Init2" or host A receives it, that host may After host B sends "Init2" or host A receives it, that host may
immediately begin transmitting protected application data as immediately begin transmitting protected application data as
described in Section 3.6. described in Section 3.6.
If host A receives "Init2" with a "sym-cipher" value that was not If host A receives "Init2" with a "sym_cipher" value that was not
present in the "sym-cipher-list" it previously transmitted in present in the "sym_cipher_list" it previously transmitted in
"Init1", it MUST abort the connection and raise an error condition "Init1", it MUST abort the connection and raise an error condition
distinct from the end-of-file condition. distinct from the end-of-file condition.
Throughout this document, to "abort the connection" means to issue Throughout this document, to "abort the connection" means to issue
the "Abort" command as described in [RFC0793], Section 3.8. That is, the "Abort" command as described in [RFC0793], Section 3.8. That is,
the TCP connection is destroyed, RESET is transmitted, and the local the TCP connection is destroyed, RESET is transmitted, and the local
user is alerted to the abort event. user is alerted to the abort event.
3.4. Session ID 3.4. Session ID
skipping to change at page 12, line 14 skipping to change at page 12, line 14
3.6. Data Encryption and Authentication 3.6. Data Encryption and Authentication
Following key exchange (or its omission via session resumption), all Following key exchange (or its omission via session resumption), all
further communication in a tcpcrypt-enabled connection is carried out further communication in a tcpcrypt-enabled connection is carried out
within delimited _encryption frames_ that are encrypted and within delimited _encryption frames_ that are encrypted and
authenticated using the agreed keys. authenticated using the agreed keys.
This protection is provided via algorithms for Authenticated This protection is provided via algorithms for Authenticated
Encryption with Associated Data (AEAD). The particular algorithms Encryption with Associated Data (AEAD). The particular algorithms
that may be used are listed in Table 3, and additional algorithms may that may be used are listed in Table 5, and additional algorithms may
be specified according to the policy in Section 7. One algorithm is be specified according to the policy in Section 7. One algorithm is
selected during the negotiation described in Section 3.3. selected during the negotiation described in Section 3.3.
The format of an encryption frame is specified in Section 4.2. A The format of an encryption frame is specified in Section 4.2. A
sending host breaks its stream of application data into a series of sending host breaks its stream of application data into a series of
chunks. Each chunk is placed in the "data" portion of a "plaintext" chunks. Each chunk is placed in the "data" portion of a "plaintext"
value, which is then encrypted to yield a frame's "ciphertext" field. value, which is then encrypted to yield a frame's "ciphertext" field.
Chunks must be small enough that the ciphertext (whose length depends Chunks must be small enough that the ciphertext (whose length depends
on the AEAD cipher used, and is generally slightly longer than the on the AEAD cipher used, and is generally slightly longer than the
plaintext) has length less than 2^16 bytes. plaintext) has length less than 2^16 bytes.
skipping to change at page 15, line 31 skipping to change at page 15, line 31
| INIT1_MAGIC | | INIT1_MAGIC |
| | | |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
4 5 6 7 4 5 6 7
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| message_len | | message_len |
| = M | | = M |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
8 K + 8 8
+--------+---------+---------+---...---+-----------+ +--------+-----+----+-----+----+---...---+-----+-----+
|nciphers|sym- |sym- | |sym- | |nciphers|sym_ |sym_ | |sym_ |
| = K |cipher[0]|cipher[1]| |cipher[K-1]| | = K |cipher[0] |cipher[1] | |cipher[K-1]|
+--------+---------+---------+---...---+-----------+ +--------+-----+----+-----+----+---...---+-----+-----+
K + 9 K + 9 + N_A_LEN 2*K + 9 2*K + 9 + N_A_LEN
| | | |
v v v v
+-------+---...---+-------+-------+---...---+-------+ +-------+---...---+-------+-------+---...---+-------+
| N_A | PK_A | | N_A | PK_A |
| | | | | |
+-------+---...---+-------+-------+---...---+-------+ +-------+---...---+-------+-------+---...---+-------+
M - 1 M - 1
+-------+---...---+-------+ +-------+---...---+-------+
| ignored | | ignored |
| | | |
+-------+---...---+-------+ +-------+---...---+-------+
The constant "INIT1_MAGIC" is defined in Table 1. The four-byte The constant "INIT1_MAGIC" is defined in Table 1. The four-byte
field "message_len" gives the length of the entire "Init1" message, field "message_len" gives the length of the entire "Init1" message,
encoded as a big-endian integer. The "nciphers" field contains an encoded as a big-endian integer. The "nciphers" field contains an
integer value that specifies the number of one-byte symmetric-cipher integer value that specifies the number of two-byte symmetric-cipher
identifiers that follow. The "sym-cipher" bytes identify identifiers that follow. The "sym_cipher[i]" identifiers indicate
cryptographic algorithms in Table 3. The length "N_A_LEN" and the cryptographic algorithms in Table 5. The length "N_A_LEN" and the
length of "PK_A" are both determined by the negotiated TEP, as length of "PK_A" are both determined by the negotiated TEP, as
described in Section 5. described in Section 5.
Implementations of this protocol MUST construct "Init1" such that the Implementations of this protocol MUST construct "Init1" such that the
field "ignored" has zero length; that is, they must construct the field "ignored" has zero length; that is, they must construct the
message such that its end, as determined by "message_len", coincides message such that its end, as determined by "message_len", coincides
with the end of the field "PK_A". When receiving "Init1", however, with the end of the field "PK_A". When receiving "Init1", however,
implementations MUST permit and ignore any bytes following "PK_A". implementations MUST permit and ignore any bytes following "PK_A".
The "Init2" message has the following encoding: The "Init2" message has the following encoding:
byte 0 1 2 3 byte 0 1 2 3
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| INIT2_MAGIC | | INIT2_MAGIC |
| | | |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
4 5 6 7 8 4 5 6 7 8 9
+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+
| message_len |sym- | | message_len | sym_cipher |
| = M |cipher | | = M | |
+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+
9 9 + N_B_LEN 10 10 + N_B_LEN
| | | |
v v v v
+-------+---...---+-------+-------+---...---+-------+ +-------+---...---+-------+-------+---...---+-------+
| N_B | PK_B | | N_B | PK_B |
| | | | | |
+-------+---...---+-------+-------+---...---+-------+ +-------+---...---+-------+-------+---...---+-------+
M - 1 M - 1
+-------+---...---+-------+ +-------+---...---+-------+
| ignored | | ignored |
| | | |
+-------+---...---+-------+ +-------+---...---+-------+
The constant "INIT2_MAGIC" is defined in Table 1. The four-byte The constant "INIT2_MAGIC" is defined in Table 1. The four-byte
field "message_len" gives the length of the entire "Init2" message, field "message_len" gives the length of the entire "Init2" message,
encoded as a big-endian integer. The "sym-cipher" value is a encoded as a big-endian integer. The "sym_cipher" value is a
selection from the symmetric-cipher identifiers in the previously- selection from the symmetric-cipher identifiers in the previously-
received "Init1" message. The length "N_B_LEN" and the length of received "Init1" message. The length "N_B_LEN" and the length of
"PK_B" are both determined by the negotiated TEP, as described in "PK_B" are both determined by the negotiated TEP, as described in
Section 5. Section 5.
Implementations of this protocol MUST construct "Init2" such that the Implementations of this protocol MUST construct "Init2" such that the
field "ignored" has zero length; that is, they must construct the field "ignored" has zero length; that is, they must construct the
message such that its end, as determined by "message_len", coincides message such that its end, as determined by "message_len", coincides
with the end of the "PK_B" field. When receiving "Init2", however, with the end of the "PK_B" field. When receiving "Init2", however,
implementations MUST permit and ignore any bytes following "PK_B". implementations MUST permit and ignore any bytes following "PK_B".
skipping to change at page 19, line 47 skipping to change at page 19, line 47
| 0x15101a0e | INIT1_MAGIC | | 0x15101a0e | INIT1_MAGIC |
| 0x097105e0 | INIT2_MAGIC | | 0x097105e0 | INIT2_MAGIC |
| 0x44415441 | FRAME_NONCE_MAGIC | | 0x44415441 | FRAME_NONCE_MAGIC |
+------------+-------------------+ +------------+-------------------+
Table 1: Constant values used in the protocol Table 1: Constant values used in the protocol
5. Key-Agreement Schemes 5. Key-Agreement Schemes
The TEP negotiated via TCP-ENO indicates the use of one of the key- The TEP negotiated via TCP-ENO indicates the use of one of the key-
agreement schemes named in Table 2. For example, agreement schemes named in Table 4. For example,
"TCPCRYPT_ECDHE_P256" names the tcpcrypt protocol using ECDHE-P256 "TCPCRYPT_ECDHE_P256" names the tcpcrypt protocol using ECDHE-P256
together with the CPRF and length parameters specified below. together with the CPRF and length parameters specified below.
All the TEPs specified in this document require the use of HKDF- All the TEPs specified in this document require the use of HKDF-
Expand-SHA256 as the CPRF, and these lengths for nonces and session Expand-SHA256 as the CPRF, and these lengths for nonces and session
keys: keys:
N_A_LEN: 32 bytes N_A_LEN: 32 bytes
N_B_LEN: 32 bytes N_B_LEN: 32 bytes
K_LEN: 32 bytes K_LEN: 32 bytes
skipping to change at page 20, line 43 skipping to change at page 20, line 43
Implementations SHOULD encode these "pubkey" values in "compressed Implementations SHOULD encode these "pubkey" values in "compressed
format", and MUST accept values encoded in "compressed", format", and MUST accept values encoded in "compressed",
"uncompressed" or "hybrid" formats. "uncompressed" or "hybrid" formats.
Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
functions X25519 and X448, respectively, to perform the Diffie-Helman functions X25519 and X448, respectively, to perform the Diffie-Helman
protocol as described in [RFC7748]. When using these ciphers, protocol as described in [RFC7748]. When using these ciphers,
public-key values "PK_A" and "PK_B" are transmitted directly with no public-key values "PK_A" and "PK_B" are transmitted directly with no
length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448. length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448.
The TEP "TCPCRYPT_ECDHE_Curve25519" is mandatory to implement. This Implementations are required to implement certain TEPs, according to
means a tcpcrypt implementation MUST support at least this TEP, Table 2. Note that system administrators may configure which TEPs a
although system administrators need not enable it. host will negotiate, independent of these requirements.
+-------------+---------------------------+
| Requirement | TEP |
+-------------+---------------------------+
| MUST | TCPCRYPT_ECDHE_Curve25519 |
| SHOULD | TCPCRYPT_ECDHE_Curve448 |
| MAY | TCPCRYPT_ECDHE_P256 |
| MAY | TCPCRYPT_ECDHE_P521 |
+-------------+---------------------------+
Table 2: Requirements for implementation of TEPs
6. AEAD Algorithms 6. AEAD Algorithms
Specifiers and key-lengths for AEAD algorithms are given in Table 3. Specifiers and key-lengths for AEAD algorithms are given in Table 5.
The algorithms "AEAD_AES_128_GCM" and "AEAD_AES_256_GCM" are The algorithms "AEAD_AES_128_GCM" and "AEAD_AES_256_GCM" are
specified in [RFC5116]. The algorithm "AEAD_CHACHA20_POLY1305" is specified in [RFC5116]. The algorithm "AEAD_CHACHA20_POLY1305" is
specified in [RFC7539]. specified in [RFC7539].
Implementations are required to support certain algorithms according
to Table 3. Note that system administrators may configure which
algorithms a host will negotiate, independent of these requirements.
+-------------+------------------------+
| Requirement | AEAD Algorithm |
+-------------+------------------------+
| MUST | AEAD_AES_128_GCM |
| SHOULD | AEAD_AES_256_GCM |
| SHOULD | AEAD_CHACHA20_POLY1305 |
+-------------+------------------------+
Table 3: Requirements for implementation of AEAD algorithms
7. IANA Considerations 7. IANA Considerations
Tcpcrypt's TEP identifiers will need to be incorporated in IANA's Tcpcrypt's TEP identifiers will need to be incorporated in IANA's
"TCP encryption protocol identifiers" registry under the "TCP encryption protocol identifiers" registry under the
"Transmission Control Protocol (TCP) Parameters" registry, as in the "Transmission Control Protocol (TCP) Parameters" registry, as in the
following table. The various key-agreement schemes used by these following table. The various key-agreement schemes used by these
tcpcrypt variants are defined in Section 5. tcpcrypt variants are defined in Section 5.
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
| 0x21 | TCPCRYPT_ECDHE_P256 | [RFC-TBD] | | 0x21 | TCPCRYPT_ECDHE_P256 | [RFC-TBD] |
| 0x22 | TCPCRYPT_ECDHE_P521 | [RFC-TBD] | | 0x22 | TCPCRYPT_ECDHE_P521 | [RFC-TBD] |
| 0x23 | TCPCRYPT_ECDHE_Curve25519 | [RFC-TBD] | | 0x23 | TCPCRYPT_ECDHE_Curve25519 | [RFC-TBD] |
| 0x24 | TCPCRYPT_ECDHE_Curve448 | [RFC-TBD] | | 0x24 | TCPCRYPT_ECDHE_Curve448 | [RFC-TBD] |
+-------+---------------------------+-----------+ +-------+---------------------------+-----------+
Table 2: TEP identifiers for use with tcpcrypt Table 4: TEP identifiers for use with tcpcrypt
In Section 4.1, this document defines "sym-cipher" specifiers for In Section 4.1, this document defines "sym_cipher" specifiers for
which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry
under the "Transmission Control Protocol (TCP) Parameters" registry, under the "Transmission Control Protocol (TCP) Parameters" registry,
with initial values as given in the following table. The AEAD with initial values as given in the following table. The AEAD
algorithms named there are defined in Section 6. Future assignments algorithms named there are defined in Section 6. Future assignments
are to be made under the "RFC Required" policy detailed in [RFC8126], are to be made under the "RFC Required" policy detailed in [RFC8126],
relying on early allocation [RFC7120] to facilitate testing before an relying on early allocation [RFC7120] to facilitate testing before an
RFC is finalized. RFC is finalized.
+-------+------------------------+------------+-----------+ +--------+------------------------+------------+-----------+
| Value | AEAD Algorithm | Key Length | Reference | | Value | AEAD Algorithm | Key Length | Reference |
+-------+------------------------+------------+-----------+ +--------+------------------------+------------+-----------+
| 0x01 | AEAD_AES_128_GCM | 16 bytes | [RFC-TBD] | | 0x0001 | AEAD_AES_128_GCM | 16 bytes | [RFC-TBD] |
| 0x02 | AEAD_AES_256_GCM | 32 bytes | [RFC-TBD] | | 0x0002 | AEAD_AES_256_GCM | 32 bytes | [RFC-TBD] |
| 0x10 | AEAD_CHACHA20_POLY1305 | 32 bytes | [RFC-TBD] | | 0x0010 | AEAD_CHACHA20_POLY1305 | 32 bytes | [RFC-TBD] |
+-------+------------------------+------------+-----------+ +--------+------------------------+------------+-----------+
Table 3: Authenticated-encryption algorithms corresponding to sym- Table 5: Authenticated-encryption algorithms corresponding to
cipher specifiers in Init1 and Init2 messages. sym_cipher specifiers in Init1 and Init2 messages.
8. Security Considerations 8. Security Considerations
Public-key generation, public-key encryption, and shared-secret Public-key generation, public-key encryption, and shared-secret
generation all require randomness. Other tcpcrypt functions may also generation all require randomness. Other tcpcrypt functions may also
require randomness, depending on the algorithms and modes of require randomness, depending on the algorithms and modes of
operation selected. A weak pseudo-random generator at either host operation selected. A weak pseudo-random generator at either host
will compromise tcpcrypt's security. Many of tcpcrypt's will compromise tcpcrypt's security. Many of tcpcrypt's
cryptographic functions require random input, and thus any host cryptographic functions require random input, and thus any host
implementing tcpcrypt MUST have access to a cryptographically-secure implementing tcpcrypt MUST have access to a cryptographically-secure
skipping to change at page 24, line 29 skipping to change at page 25, line 22
The IETF's appraisal of best current practice on this matter The IETF's appraisal of best current practice on this matter
[RFC7696] says, "Ideally, two independent sets of mandatory-to- [RFC7696] says, "Ideally, two independent sets of mandatory-to-
implement algorithms will be specified, allowing for a primary suite implement algorithms will be specified, allowing for a primary suite
and a secondary suite. This approach ensures that the secondary and a secondary suite. This approach ensures that the secondary
suite is widely deployed if a flaw is found in the primary one." suite is widely deployed if a flaw is found in the primary one."
To meet that ideal, it might appear natural to also mandate ECDHE To meet that ideal, it might appear natural to also mandate ECDHE
using P-256, as this scheme is well-studied, widely implemented, and using P-256, as this scheme is well-studied, widely implemented, and
sufficiently different from the Curve25519-based scheme that it is sufficiently different from the Curve25519-based scheme that it is
unlikely they will both suffer from a single cryptoanalytic advance. unlikely they will both suffer from a single (non-quantum)
cryptanalytic advance.
However, implementing the Diffie-Hellman function using NIST elliptic However, implementing the Diffie-Hellman function using NIST elliptic
curves (including those specified for use with tcpcrypt, P-256 and curves (including those specified for use with tcpcrypt, P-256 and
P-521) appears to be very difficult to achieve without introducing P-521) appears to be very difficult to achieve without introducing
vulnerability to side-channel attacks [nist-ecc]. Although well- vulnerability to side-channel attacks [nist-ecc]. Although well-
trusted implementations are available as part of large cryptographic trusted implementations are available as part of large cryptographic
libraries, these may be difficult to extract for use in operating- libraries, these may be difficult to extract for use in operating-
system kernels where tcpcrypt is usually best implemented. In system kernels where tcpcrypt is usually best implemented. In
contrast, the characteristics of Curve25519 together with its recent contrast, the characteristics of Curve25519 together with its recent
popularity has led to many safe and efficient implementations, popularity has led to many safe and efficient implementations,
including some that fit naturally into the kernel environment. including some that fit naturally into the kernel environment.
[RFC7696] insists that, "The selected algorithms need to be resistant [RFC7696] insists that, "The selected algorithms need to be resistant
to side-channel attacks and also meet the performance, power, and to side-channel attacks and also meet the performance, power, and
code size requirements on a wide variety of platforms." On this code size requirements on a wide variety of platforms." On this
principle, tcpcrypt excludes the NIST curves from the set of principle, tcpcrypt excludes the NIST curves from the set of
mandatory-to-implement key-agreement algorithms. mandatory-to-implement key-agreement algorithms.
Lastly, this document encourages (via SHOULD) support for key-
agreement with Curve448 as this scheme appears likely to admit safe
and efficient implementations; but it does not absolutely require
such support, as well-proven implementations may not yet be
available.
9. Acknowledgments 9. Acknowledgments
We are grateful for contributions, help, discussions, and feedback We are grateful for contributions, help, discussions, and feedback
from the TCPINC working group, including Marcelo Bagnulo, David from the TCPINC working group and from other IETF reviewers,
Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav including Marcelo Bagnulo, David Black, Bob Briscoe, Jana Iyengar,
Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose. Stephen Kent, Tero Kivinen, Mirja Kuhlewind, Yoav Nir, Christoph
Paasch, Eric Rescorla, Kyle Rose, and Dale Worley.
This work was funded by gifts from Intel (to Brad Karp) and from This work was funded by gifts from Intel (to Brad Karp) and from
Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for Google; by NSF award CNS-0716806 (A Clean-Slate Infrastructure for
Information Flow Control); by DARPA CRASH under contract Information Flow Control); by DARPA CRASH under contract
#N66001-10-2-4088; and by the Stanford Secure Internet of Things #N66001-10-2-4088; and by the Stanford Secure Internet of Things
Project. Project.
10. Contributors 10. Contributors
Dan Boneh and Michael Hamburg were co-authors of the draft that Dan Boneh and Michael Hamburg were co-authors of the draft that
skipping to change at page 25, line 41 skipping to change at page 26, line 41
[nist-dss] [nist-dss]
NIST, "FIPS PUB 186-4: Digital Signature Standard (DSS)", NIST, "FIPS PUB 186-4: Digital Signature Standard (DSS)",
2013. 2013.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997,
editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-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,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, <https://www.rfc- DOI 10.17487/RFC5869, May 2010,
editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>. <https://www.rfc-editor.org/info/rfc7539>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
skipping to change at page 26, line 41 skipping to change at page 27, line 41
11.2. Informative References 11.2. Informative References
[I-D.ietf-tcpinc-api] [I-D.ietf-tcpinc-api]
Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
D., and E. Smith, "Interface Extensions for TCP-ENO and D., and E. Smith, "Interface Extensions for TCP-ENO and
tcpcrypt", draft-ietf-tcpinc-api-05 (work in progress), tcpcrypt", draft-ietf-tcpinc-api-05 (work in progress),
September 2017. September 2017.
[nist-ecc] [nist-ecc]
Bernstein, D. and T. Lange, "Failures in NIST's ECC Bernstein, D. and T. Lange, "Failures in NIST's ECC
standards", 2016, <https://cr.yp.to/newelliptic/nistecc- standards", 2016,
20160106.pdf>. <https://cr.yp.to/newelliptic/nistecc-20160106.pdf>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, <https://www.rfc- DOI 10.17487/RFC1122, October 1989,
editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[tcpcrypt] [tcpcrypt]
Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D. Bittau, A., Hamburg, M., Handley, M., Mazieres, D., and D.
Boneh, "The case for ubiquitous transport-level Boneh, "The case for ubiquitous transport-level
encryption", USENIX Security , 2010. encryption", USENIX Security , 2010.
 End of changes. 38 change blocks. 
75 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/