draft-ietf-tcpinc-tcpcrypt-00.txt   draft-ietf-tcpinc-tcpcrypt-01.txt 
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft D. Boneh Internet-Draft D. Boneh
Intended status: Standards Track D. Giffin Intended status: Standards Track D. Giffin
Expires: May 6, 2016 M. Hamburg Expires: August 24, 2016 M. Hamburg
Stanford University Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Q. Slack Q. Slack
Stanford University Stanford University
E. Smith E. Smith
Kestrel Institute Kestrel Institute
November 3, 2015 February 21, 2016
Cryptographic protection of TCP Streams (tcpcrypt) Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-00 draft-ietf-tcpinc-tcpcrypt-01
Abstract Abstract
This document specifies tcpcrypt, a cryptographic protocol that This document specifies tcpcrypt, a cryptographic protocol that
protects TCP payload data and is negotiated by means of the TCP protects TCP payload data and is negotiated by means of the TCP
Encryption Negotiation Option (TCP-ENO) [I-D.ietf-tcpinc-tcpeno]. Encryption Negotiation Option (TCP-ENO) [I-D.ietf-tcpinc-tcpeno].
Tcpcrypt coexists with middleboxes by tolerating resegmentation, Tcpcrypt coexists with middleboxes by tolerating resegmentation,
NATs, and other manipulations of the TCP header. The protocol is NATs, and other manipulations of the TCP header. The protocol is
self-contained and specifically tailored to TCP implementations, self-contained and specifically tailored to TCP implementations,
which often reside in kernels or other environments in which large which often reside in kernels or other environments in which large
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2016. This Internet-Draft will expire on August 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
3.8. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 11
3.9. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 12 3.9. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 12
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Key exchange messages . . . . . . . . . . . . . . . . . . 13 4.1. Key exchange messages . . . . . . . . . . . . . . . . . . 13
4.2. Application frames . . . . . . . . . . . . . . . . . . . 15 4.2. Application frames . . . . . . . . . . . . . . . . . . . 15
4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Associated data . . . . . . . . . . . . . . . . . . . 17 4.2.2. Associated data . . . . . . . . . . . . . . . . . . . 17
4.2.3. Frame nonce . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Frame nonce . . . . . . . . . . . . . . . . . . . . . 17
5. API extensions . . . . . . . . . . . . . . . . . . . . . . . 17 5. API extensions . . . . . . . . . . . . . . . . . . . . . . . 17
6. Key agreement schemes . . . . . . . . . . . . . . . . . . . . 18 6. Key agreement schemes . . . . . . . . . . . . . . . . . . . . 18
7. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . . 20 7. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security considerations . . . . . . . . . . . . . . . . . . . 21 10. Security considerations . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Protocol constant values . . . . . . . . . . . . . . 23 Appendix A. Protocol constant values . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
skipping to change at page 7, line 51 skipping to change at page 7, line 51
The value ss[0] is used to generate all key material for the current The value ss[0] is used to generate all key material for the current
connection. SID[0] is the Session ID for the current connection, and connection. SID[0] is the Session ID for the current connection, and
will with overwhelming probability be unique for each individual TCP will with overwhelming probability be unique for each individual TCP
connection. The most computationally expensive part of the key connection. The most computationally expensive part of the key
exchange protocol is the public key cipher. The values of ss[i] for exchange protocol is the public key cipher. The values of ss[i] for
i > 0 can be used to avoid public key cryptography when establishing i > 0 can be used to avoid public key cryptography when establishing
subsequent connections between the same two hosts, as described in subsequent connections between the same two hosts, as described in
Section 3.5. The CONST values are constants defined in Table 3. The Section 3.5. The CONST values are constants defined in Table 3. The
K_LEN values depend on the tcpcrypt spec in use, and are specified in K_LEN values depend on the tcpcrypt spec in use, and are specified in
Figure 3. Section 6.
Given a session secret, ss, the two sides compute a series of master Given a session secret, ss, the two sides compute a series of master
keys as follows: keys as follows:
mk[0] := CPRF (ss, CONST_REKEY, K_LEN) mk[0] := CPRF (ss, CONST_REKEY, K_LEN)
mk[i] := CPRF (mk[i-1], CONST_REKEY, K_LEN) mk[i] := CPRF (mk[i-1], CONST_REKEY, K_LEN)
Finally, each master key mk is used to generate keys for Finally, each master key mk is used to generate keys for
authenticated encryption for the "A" and "B" roles. Key k_ab is used authenticated encryption for the "A" and "B" roles. Key k_ab is used
by host A to encrypt and host B to decrypt, while k_ba is used by by host A to encrypt and host B to decrypt, while k_ba is used by
skipping to change at page 11, line 23 skipping to change at page 11, line 23
"K" set to k_ab or k_ba, according to the host's role as described in "K" set to k_ab or k_ba, according to the host's role as described in
Section 3.4. The plaintext value serves as "P", the associated data Section 3.4. The plaintext value serves as "P", the associated data
as "A", and the frame nonce as "N". The output of the encryption as "A", and the frame nonce as "N". The output of the encryption
operation, "C", is transmitted in the frame's "ciphertext" field. operation, "C", is transmitted in the frame's "ciphertext" field.
When a frame is received, tcpcrypt reconstructs the associated data When a frame is received, tcpcrypt reconstructs the associated data
and frame nonce values (the former contains only data sent in the and frame nonce values (the former contains only data sent in the
clear, and the latter is implicit in the TCP stream), and provides clear, and the latter is implicit in the TCP stream), and provides
these and the ciphertext value to the the AEAD decryption operation. these and the ciphertext value to the the AEAD decryption operation.
The output of this operation is either "P", a plaintext value, or the The output of this operation is either "P", a plaintext value, or the
special symbol FAIL. In the latter case, the implementation MAY special symbol FAIL. In the latter case, the implementation MUST
either ignore the frame or terminate the connection. either ignore the frame or terminate the connection.
3.7. TCP header protection 3.7. TCP header protection
The "ciphertext" field of the application frame contains protected The "ciphertext" field of the application frame contains protected
versions of certain TCP header values. versions of certain TCP header values.
When "URGp" is set, the "urgent" value indicates an offset from the When "URGp" is set, the "urgent" value indicates an offset from the
current frame's beginning offset; the sum of these offsets gives the current frame's beginning offset; the sum of these offsets gives the
index of the last byte of urgent data in the application datastream. index of the last byte of urgent data in the application datastream.
skipping to change at page 14, line 44 skipping to change at page 14, line 44
| | | |
+-------+---...---+-------+ +-------+---...---+-------+
The constant INIT1_MAGIC is defined in Table 3. The four-byte field The constant INIT1_MAGIC is defined in Table 3. The four-byte field
"message_len" gives the length of the entire INIT1 message, encoded "message_len" gives the length of the entire INIT1 message, encoded
as a big-endian integer. The "nciphers" field contains an integer as a big-endian integer. The "nciphers" field contains an integer
value that specifies the number of one-byte symmetric-cipher value that specifies the number of one-byte symmetric-cipher
identifiers that follow. The "sym-cipher" bytes identify identifiers that follow. The "sym-cipher" bytes identify
cryptographic algorithms in Table 2. The length N_A_LEN and the cryptographic algorithms in Table 2. The length N_A_LEN and the
length of PK_A are both determined by the negotiated key-agreement length of PK_A are both determined by the negotiated key-agreement
scheme, as shown in Figure 3. scheme, as described in Section 6.
When sending INIT1, implementations of this protocol MUST omit the When sending INIT1, implementations of this protocol MUST omit the
field "ignored"; that is, they must construct the message such that field "ignored"; that is, they must construct the message such that
its end, as determined by "message_len", coincides with the end of its end, as determined by "message_len", coincides with the end of
the PK_A field. When receiving INIT1, however, implementations MUST the PK_A field. When receiving INIT1, however, implementations MUST
permit and ignore any bytes following PK_A. 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
skipping to change at page 15, line 36 skipping to change at page 15, line 36
+-------+---...---+-------+ +-------+---...---+-------+
| ignored | | ignored |
| | | |
+-------+---...---+-------+ +-------+---...---+-------+
The constant INIT2_MAGIC is defined in Table 3. The four-byte field The constant INIT2_MAGIC is defined in Table 3. The four-byte field
"message_len" gives the length of the entire INIT2 message, encoded "message_len" gives the length of the entire INIT2 message, encoded
as a big-endian integer. The "sym-cipher" value is a selection from as a big-endian integer. The "sym-cipher" value is a selection from
the symmetric-cipher identifiers in the previously-received INIT1 the symmetric-cipher identifiers in the previously-received INIT1
message. The length N_B_LEN and the length of PK_B are both message. The length N_B_LEN and the length of PK_B are both
determined by the negotiated key-agreement scheme, as shown in determined by the negotiated key-agreement scheme, as described in
Figure 3. Section 6.
When sending INIT2, implementations of this protocol MUST omit the When sending INIT2, implementations of this protocol MUST omit the
field "ignored"; that is, they must construct the message such that field "ignored"; that is, they must construct the message such that
its end, as determined by "message_len", coincides with the end of its end, as determined by "message_len", coincides with the end of
the PK_B field. When receiving INIT2, however, implementations MUST the PK_B field. When receiving INIT2, however, implementations MUST
permit and ignore any bytes following PK_B. permit and ignore any bytes following PK_B.
4.2. Application frames 4.2. Application frames
An _application frame_ comprises a control byte and a length-prefixed An _application frame_ comprises a control byte and a length-prefixed
skipping to change at page 18, line 38 skipping to change at page 18, line 38
o Default TCP_CRYPT_BCONF value o Default TCP_CRYPT_BCONF value
o Types, key lengths, and regeneration intervals of local host's o Types, key lengths, and regeneration intervals of local host's
short-lived public keys for implementations that do not use fresh short-lived public keys for implementations that do not use fresh
ECDH parameters for each connection. ECDH parameters for each connection.
6. Key agreement schemes 6. Key agreement schemes
The encryption spec negotiated via TCP-ENO may indicate the use of The encryption spec negotiated via TCP-ENO may indicate the use of
one of these key-agreement schemes: one of the key-agreement schemes named in Table 1.
+---------------------------+----------------------------------+ All schemes listed there use HKDF-Expand-SHA256 as the CPRF, and
| Encryption spec (cs) | Key-agreement scheme | these lengths for nonces and session keys:
+---------------------------+----------------------------------+
| TCPCRYPT_ECDHE_P256 | Cipher: ECDHE-P256 |
| | Extract: HKDF-Extract-SHA256 |
| | CPRF: HKDF-Expand-SHA256 |
| | N_A_LEN: 32 bytes |
| | N_B_LEN: 32 bytes |
| | K_LEN: 32 bytes |
+---------------------------+----------------------------------+
| TCPCRYPT_ECDHE_P521 | Cipher: ECDHE-P521 |
| | Extract: HKDF-Extract-SHA256 |
| | CPRF: HKDF-Expand-SHA256 |
| | N_A_LEN: 32 bytes |
| | N_B_LEN: 32 bytes |
| | K_LEN: 32 bytes |
+---------------------------+----------------------------------+
| TCPCRYPT_ECDHE_Curve25519 | Cipher: ECDHE-Curve25519 |
| | Extract: HKDF-Extract-SHA256 |
| | CPRF: HKDF-Expand-SHA256 |
| | N_A_LEN: 32 bytes |
| | N_B_LEN: 32 bytes |
| | K_LEN: 32 bytes |
+---------------------------+----------------------------------+
Figure 3: Key agreement schemes N_A_LEN: 32 bytes
N_B_LEN: 32 bytes
K_LEN: 32 bytes
Ciphers ECDHE-P256 and ECDHE-P521 employ the ECSVDP-DH secret value Key-agreement schemes ECDHE-P256 and ECDHE-P521 employ the ECSVDP-DH
derivation primitive defined in [ieee1363]. The named curves are secret value derivation primitive defined in [ieee1363]. The named
defined in [nist-dss]. When the public-key values PK_A and PK_B are curves are defined in [nist-dss]. When the public-key values PK_A
transmitted as described in Section 4.1, they are encoded with the and PK_B are transmitted as described in Section 4.1, they are
"Elliptic Curve Point to Octet String Conversion Primitive" described encoded with the "Elliptic Curve Point to Octet String Conversion
in Section E.2.3 of [ieee1363], and are prefixed by a two-byte length Primitive" described in Section E.2.3 of [ieee1363], and are prefixed
in big-endian format: by a two-byte length in big-endian format:
byte 0 1 2 L - 1 byte 0 1 2 L - 1
+-------+-------+-------+---...---+-------+ +-------+-------+-------+---...---+-------+
| pubkey_len | pubkey | | pubkey_len | pubkey |
| = L | | | = L | |
+-------+-------+-------+---...---+-------+ +-------+-------+-------+---...---+-------+
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.
The ECDHE-Curve25519 cipher uses the X25519 function described in Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
[I-D.irtf-cfrg-curves]. When using this cipher, public-key values functions X25519 and X448, respectively, to perform the Diffie-Helman
PK_A and PK_B are transmitted directly as 32-byte values (with no protocol as described in [RFC7748]. When using these ciphers,
length prefix). public-key values PK_A and PK_B are transmitted directly with no
length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448.
A tcpcrypt implementation MUST support at least the schemes A tcpcrypt implementation MUST support at least the schemes
TCPCRYPT_ECDHE_P256 and TCPCRYPT_ECDHE_P521, although system ECDHE-P256 and ECDHE-P521, although system administrators need not
administrators need not enable them. enable them.
7. AEAD algorithms 7. AEAD algorithms
Specifiers and key-lengths for AEAD algorithms are given in Table 2. Specifiers and key-lengths for AEAD algorithms are given in Table 2.
The algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM are specified in 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]. [RFC7539].
8. Acknowledgments 8. Acknowledgments
skipping to change at page 20, line 37 skipping to change at page 20, line 12
Tcpcrypt's spec identifiers ("cs" values) will need to be added to Tcpcrypt's spec identifiers ("cs" values) will need to be added to
IANA's ENO suboption registry, as follows: IANA's ENO suboption registry, as follows:
+------+---------------------------+--------------------------------+ +------+---------------------------+--------------------------------+
| cs | Spec name | Meaning | | cs | Spec name | Meaning |
+------+---------------------------+--------------------------------+ +------+---------------------------+--------------------------------+
| 0x20 | TCPCRYPT_RESUME | tcpcrypt session resumption | | 0x20 | TCPCRYPT_RESUME | tcpcrypt session resumption |
| 0x21 | TCPCRYPT_ECDHE_P256 | tcpcrypt with ECDHE-P256 | | 0x21 | TCPCRYPT_ECDHE_P256 | tcpcrypt with ECDHE-P256 |
| 0x22 | TCPCRYPT_ECDHE_P521 | tcpcrypt with ECDHE-P521 | | 0x22 | TCPCRYPT_ECDHE_P521 | tcpcrypt with ECDHE-P521 |
| 0x23 | TCPCRYPT_ECDHE_Curve25519 | tcpcrypt with ECDHE-Curve25519 | | 0x23 | TCPCRYPT_ECDHE_Curve25519 | tcpcrypt with ECDHE-Curve25519 |
| 0x24 | TCPCRYPT_ECDHE_Curve448 | tcpcrypt with ECDHE-Curve448 |
+------+---------------------------+--------------------------------+ +------+---------------------------+--------------------------------+
Table 1: cs values for use with tcpcrypt Table 1: cs values for use with tcpcrypt
A "tcpcrypt AEAD parameter" registry needs to be maintained by IANA A "tcpcrypt AEAD parameter" registry needs to be maintained by IANA
as per the following table. The use of encryption is described in as per the following table. The use of encryption is described in
Section 3.6. Section 3.6.
+------------------------+------------+------------+ +------------------------+------------+------------+
| AEAD Algorithm | Key Length | sym-cipher | | AEAD Algorithm | Key Length | sym-cipher |
skipping to change at page 22, line 27 skipping to change at page 21, line 41
session caching chain without guessing the content of the resumption session caching chain without guessing the content of the resumption
suboption, which will be hard without key knowledge. suboption, which will be hard without key knowledge.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-tcpinc-tcpeno] [I-D.ietf-tcpinc-tcpeno]
Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
D., and E. Smith, "TCP-ENO: Encryption Negotiation D., and E. Smith, "TCP-ENO: Encryption Negotiation
Option", draft-ietf-tcpinc-tcpeno-00 (work in progress), Option", draft-ietf-tcpinc-tcpeno-01 (work in progress),
September 2015. February 2016.
[I-D.irtf-cfrg-curves]
Langley, A. and M. Hamburg, "Elliptic Curves for
Security", draft-irtf-cfrg-curves-10 (work in progress),
October 2015.
[ieee1363] [ieee1363]
"IEEE Standard Specifications for Public-Key Cryptography "IEEE Standard Specifications for Public-Key Cryptography
(IEEE Std 1363-2000)", 2000. (IEEE Std 1363-2000)", 2000.
[nist-dss] [nist-dss]
"Digital Signature Standard, FIPS 186-2", 2000. "Digital Signature Standard, FIPS 186-2", 2000.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc5116>. <http://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, DOI 10.17487/ Key Derivation Function (HKDF)", RFC 5869,
RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>. <http://www.rfc-editor.org/info/rfc5869>.
[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,
<http://www.rfc-editor.org/info/rfc7539>. <http://www.rfc-editor.org/info/rfc7539>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>.
11.2. Informative References 11.2. Informative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, DOI 10.17487/ Communication Layers", STD 3, RFC 1122,
RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[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.
Appendix A. Protocol constant values Appendix A. Protocol constant values
+------------+--------------+ +------------+--------------+
| Value | Name | | Value | Name |
+------------+--------------+ +------------+--------------+
| 0x01 | CONST_NEXTK | | 0x01 | CONST_NEXTK |
| 0x02 | CONST_SESSID | | 0x02 | CONST_SESSID |
| 0x03 | CONST_REKEY | | 0x03 | CONST_REKEY |
| 0x04 | CONST_KEY_A | | 0x04 | CONST_KEY_A |
| 0x05 | CONST_KEY_B | | 0x05 | CONST_KEY_B |
| 0x15101a0e | INIT1_MAGIC | | 0x15101a0e | INIT1_MAGIC |
| 0x097105e0 | INIT2_MAGIC | | 0x097105e0 | INIT2_MAGIC |
 End of changes. 23 change blocks. 
71 lines changed or deleted 51 lines changed or added

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