draft-ietf-tcpinc-tcpcrypt-05.txt   draft-ietf-tcpinc-tcpcrypt-06.txt 
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft Google Internet-Draft Google
Intended status: Experimental D. Boneh Intended status: Experimental D. Giffin
Expires: August 19, 2017 D. Giffin Expires: September 14, 2017 Stanford University
M. Hamburg
Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Q. Slack
Stanford University Stanford University
Q. Slack
Sourcegraph
E. Smith E. Smith
Kestrel Institute Kestrel Institute
February 15, 2017 March 13, 2017
Cryptographic protection of TCP Streams (tcpcrypt) Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-05 draft-ietf-tcpinc-tcpcrypt-06
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) [I-D.ietf-tcpinc-tcpeno]. Tcpcrypt coexists with (TCP-ENO) [I-D.ietf-tcpinc-tcpeno]. Tcpcrypt coexists with
middleboxes by tolerating resegmentation, NATs, and other middleboxes by tolerating resegmentation, NATs, and other
manipulations of the TCP header. The protocol is self-contained and manipulations of the TCP header. The protocol is self-contained and
specifically tailored to TCP implementations, which often reside in specifically tailored to TCP implementations, which often reside in
kernels or other environments in which large external software kernels or other environments in which large external software
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 August 19, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Requirements language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements language . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encryption protocol . . . . . . . . . . . . . . . . . . . . . 3 3. Encryption protocol . . . . . . . . . . . . . . . . . . . . . 4
3.1. Cryptographic algorithms . . . . . . . . . . . . . . . . 4 3.1. Cryptographic algorithms . . . . . . . . . . . . . . . . 4
3.2. Protocol negotiation . . . . . . . . . . . . . . . . . . 5 3.2. Protocol negotiation . . . . . . . . . . . . . . . . . . 5
3.3. Key exchange . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Key exchange . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Session ID . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Session caching . . . . . . . . . . . . . . . . . . . . . 8 3.5. Session caching . . . . . . . . . . . . . . . . . . . . . 8
3.6. Data encryption and authentication . . . . . . . . . . . 11 3.6. Data encryption and authentication . . . . . . . . . . . 11
3.7. TCP header protection . . . . . . . . . . . . . . . . . . 12 3.7. TCP header protection . . . . . . . . . . . . . . . . . . 12
3.8. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 12 3.8. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 13 3.9. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 13
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Key exchange messages . . . . . . . . . . . . . . . . . . 14 4.1. Key exchange messages . . . . . . . . . . . . . . . . . . 14
4.2. Application frames . . . . . . . . . . . . . . . . . . . 16 4.2. Application frames . . . . . . . . . . . . . . . . . . . 16
4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Associated data . . . . . . . . . . . . . . . . . . . 17 4.2.2. Associated data . . . . . . . . . . . . . . . . . . . 18
4.2.3. Frame nonce . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Frame nonce . . . . . . . . . . . . . . . . . . . . . 18
5. Key agreement schemes . . . . . . . . . . . . . . . . . . . . 18 5. Key agreement schemes . . . . . . . . . . . . . . . . . . . . 18
6. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . . 19 6. AEAD algorithms . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security considerations . . . . . . . . . . . . . . . . . . . 20 8. Security considerations . . . . . . . . . . . . . . . . . . . 20
9. Design notes . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Design notes . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Asymmetric roles . . . . . . . . . . . . . . . . . . . . 21 9.1. Asymmetric roles . . . . . . . . . . . . . . . . . . . . 22
9.2. Verified liveness . . . . . . . . . . . . . . . . . . . . 21 9.2. Verified liveness . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Protocol constant values . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Protocol constant values . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 13, line 21 skipping to change at page 13, line 25
re-keying_. re-keying_.
When a host has incremented its local generation number and uses the When a host has incremented its local generation number and uses the
new key-set for the first time to encrypt an outgoing frame, it MUST new key-set for the first time to encrypt an outgoing frame, it MUST
set "rekey = 1" for that frame. It MUST set this field to zero in set "rekey = 1" for that frame. It MUST set this field to zero in
all other cases. all other cases.
When a host receives a frame with "rekey = 1", it increments its When a host receives a frame with "rekey = 1", it increments its
record of the remote generation number. If the remote generation record of the remote generation number. If the remote generation
number is now greater than the local generation number, the receiver number is now greater than the local generation number, the receiver
MUST immediately increment its local generation number to match and MUST immediately increment its local generation number to match.
send a frame (with empty application data if necessary) with "rekey = Moreover, if the receiver has not yet transmitted a segment with the
1". FIN flag set, it MUST immediately send a frame (with empty
application data if necessary) with "rekey = 1".
A host SHOULD NOT initiate more than one concurrent re-key operation A host SHOULD NOT initiate more than one concurrent re-key operation
if it has no data to send; that is, it should not initiate re-keying if it has no data to send; that is, it should not initiate re-keying
with an empty application frame more than once while its record of with an empty application frame more than once while its record of
the remote generation number is less than its own. the remote generation number is less than its own.
When retransmitting, implementations must always transmit the same When retransmitting, implementations must always transmit the same
bytes for the same TCP sequence numbers. Thus, a frame in a bytes for the same TCP sequence numbers. Thus, a frame in a
retransmitted segment MUST always be encrypted with the same key as retransmitted segment MUST always be encrypted with the same key as
when it was originally transmitted. when it was originally transmitted.
skipping to change at page 13, line 50 skipping to change at page 14, line 7
Instead of using TCP Keep-Alives to verify that the remote endpoint Instead of using TCP Keep-Alives to verify that the remote endpoint
is still responsive, tcpcrypt implementations SHOULD employ the re- is still responsive, tcpcrypt implementations SHOULD employ the re-
keying mechanism for this purpose, as follows. When necessary, a keying mechanism for this purpose, as follows. When necessary, a
host SHOULD probe the liveness of its peer by initiating re-keying host SHOULD probe the liveness of its peer by initiating re-keying
and transmitting a new frame immediately (with empty application data and transmitting a new frame immediately (with empty application data
if necessary). if necessary).
As described in Section 3.8, a host receiving a frame encrypted under As described in Section 3.8, a host receiving a frame encrypted under
a generation number greater than its own MUST increment its own a generation number greater than its own MUST increment its own
generation number and immediately transmit a new frame (with zero- generation number and (if it has not already transmitted a segment
length application data, if necessary). with FIN set) immediately transmit a new frame (with zero-length
application data if necessary).
Implementations MAY use TCP Keep-Alives for purposes that do not Implementations MAY use TCP Keep-Alives for purposes that do not
require endpoint authentication, as discussed in Section 9.2. require endpoint authentication, as discussed in Section 9.2.
4. Encodings 4. Encodings
This section provides byte-level encodings for values transmitted or This section provides byte-level encodings for values transmitted or
computed by the protocol. computed by the protocol.
4.1. Key exchange messages 4.1. Key exchange messages
skipping to change at page 19, line 24 skipping to change at page 20, line 6
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].
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-ENO encryption protocol identifier registry, as follows: TCP-ENO encryption protocol identifier registry, as follows:
+------+---------------------------+ +------+---------------------------+
| cs | Spec name | | glt | Spec name |
+------+---------------------------+ +------+---------------------------+
| 0x21 | TCPCRYPT_ECDHE_P256 | | 0x21 | TCPCRYPT_ECDHE_P256 |
| 0x22 | TCPCRYPT_ECDHE_P521 | | 0x22 | TCPCRYPT_ECDHE_P521 |
| 0x23 | TCPCRYPT_ECDHE_Curve25519 | | 0x23 | TCPCRYPT_ECDHE_Curve25519 |
| 0x24 | TCPCRYPT_ECDHE_Curve448 | | 0x24 | TCPCRYPT_ECDHE_Curve448 |
+------+---------------------------+ +------+---------------------------+
Table 1: TEP identifiers for use with tcpcrypt Table 1: TEP identifiers 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
skipping to change at page 22, line 31 skipping to change at page 23, line 11
from the TCPINC working group, including Marcelo Bagnulo, David from the TCPINC working group, including Marcelo Bagnulo, David
Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav Black, Bob Briscoe, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Yoav
Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose. Nir, Christoph Paasch, Eric Rescorla, and Kyle Rose.
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.
11. References 11. Contributors
11.1. Normative References Dan Boneh and Michael Hamburg were co-authors of the draft that
became this document.
12. References
12.1. Normative References
[I-D.ietf-tcpinc-tcpeno] [I-D.ietf-tcpinc-tcpeno]
Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres, Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
D., and E. Smith, "TCP-ENO: Encryption Negotiation Smith, "TCP-ENO: Encryption Negotiation Option", draft-
Option", draft-ietf-tcpinc-tcpeno-07 (work in progress), ietf-tcpinc-tcpeno-08 (work in progress), March 2017.
January 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 23, line 22 skipping to change at page 24, line 5
<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 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <http://www.rfc-editor.org/info/rfc7748>. 2016, <http://www.rfc-editor.org/info/rfc7748>.
11.2. Informative References 12.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, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/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.
skipping to change at page 24, line 15 skipping to change at page 24, line 45
Authors' Addresses Authors' Addresses
Andrea Bittau Andrea Bittau
Google Google
345 Spear Street 345 Spear Street
San Francisco, CA 94105 San Francisco, CA 94105
US US
Email: bittau@google.com Email: bittau@google.com
Dan Boneh
Stanford University
353 Serra Mall, Room 475
Stanford, CA 94305
US
Email: dabo@cs.stanford.edu
Daniel B. Giffin Daniel B. Giffin
Stanford University Stanford University
353 Serra Mall, Room 288 353 Serra Mall, Room 288
Stanford, CA 94305 Stanford, CA 94305
US US
Email: dbg@scs.stanford.edu Email: dbg@scs.stanford.edu
Mike Hamburg
Stanford University
353 Serra Mall, Room 475
Stanford, CA 94305
US
Email: mike@shiftleft.org
Mark Handley Mark Handley
University College London University College London
Gower St. Gower St.
London WC1E 6BT London WC1E 6BT
UK UK
Email: M.Handley@cs.ucl.ac.uk Email: M.Handley@cs.ucl.ac.uk
David Mazieres David Mazieres
Stanford University Stanford University
353 Serra Mall, Room 290 353 Serra Mall, Room 290
Stanford, CA 94305 Stanford, CA 94305
US US
Email: dm@uun.org Email: dm@uun.org
Quinn Slack Quinn Slack
Stanford University Sourcegraph
353 Serra Mall, Room 288 121 2nd St Ste 200
Stanford, CA 94305 San Francisco, CA 94105
US US
Email: sqs@cs.stanford.edu Email: sqs@sourcegraph.com
Eric W. Smith Eric W. Smith
Kestrel Institute Kestrel Institute
3260 Hillview Avenue 3260 Hillview Avenue
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Email: eric.smith@kestrel.edu Email: eric.smith@kestrel.edu
 End of changes. 22 change blocks. 
53 lines changed or deleted 43 lines changed or added

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