< draft-bittau-tcpinc-00.txt		draft-bittau-tcpinc-01.txt >
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Intended status: Standards Track M. Hamburg		Intended status: Standards Track M. Hamburg
	Expires: January 22, 2015 Stanford University		Expires: January 22, 2015 Stanford University
	M. Handley		M. Handley
	University College London		University College London
	D. Mazieres		D. Mazieres
	Q. Slack		Q. Slack
	Stanford University		Stanford University
	July 21, 2014		July 21, 2014
	Cryptographic protection of TCP Streams (tcpcrypt)		Cryptographic protection of TCP Streams (tcpcrypt)
	draft-bittau-tcpinc-00.txt		draft-bittau-tcpinc-01.txt
	Abstract		Abstract
	This document presents tcpcrypt, a TCP extension for		This document presents tcpcrypt, a TCP extension for
	cryptographically protecting TCP segments. Tcpcrypt maintains the		cryptographically protecting TCP segments. Tcpcrypt maintains the
	confidentiality of data transmitted in TCP segments against a passive		confidentiality of data transmitted in TCP segments against a passive
	eavesdropper. It protects connections against denial-of-service		eavesdropper. It protects connections against denial-of-service
	attacks involving desynchronizing of sequence numbers, and when		attacks involving desynchronizing of sequence numbers, and when
	enabled, against forged RST segments. Finally, applications that		enabled, against forged RST segments. Finally, applications that
	perform authentication can obtain end-to-end confidentiality and		perform authentication can obtain end-to-end confidentiality and
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	1. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		1. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Idealized protocol . . . . . . . . . . . . . . . . . . . . . . 5		3. Idealized protocol . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Stages of the protocol . . . . . . . . . . . . . . . . . . 5		3.1. Stages of the protocol . . . . . . . . . . . . . . . . . . 5
	3.1.1. The setup phase . . . . . . . . . . . . . . . . . . . 6		3.1.1. The setup phase . . . . . . . . . . . . . . . . . . . 6
	3.1.2. The ENCRYPTING state . . . . . . . . . . . . . . . . . 6		3.1.2. The ENCRYPTING state . . . . . . . . . . . . . . . . . 6
	3.1.3. The DISABLED state . . . . . . . . . . . . . . . . . . 7		3.1.3. The DISABLED state . . . . . . . . . . . . . . . . . . 7
	3.2. Cryptographic algorithms . . . . . . . . . . . . . . . . . 7		3.2. Cryptographic algorithms . . . . . . . . . . . . . . . . . 7
	3.3. "C" and "S" roles . . . . . . . . . . . . . . . . . . . . 9		3.3. "C" and "S" roles . . . . . . . . . . . . . . . . . . . . 9
	3.4. Key exchange protocol . . . . . . . . . . . . . . . . . . 9		3.4. Key exchange protocol . . . . . . . . . . . . . . . . . . 9
	3.5. Data encryption and authentication . . . . . . . . . . . . 11		3.5. Data encryption and authentication . . . . . . . . . . . . 12
	3.6. Authenticated Sequence Mode (ASM) . . . . . . . . . . . . 12		3.6. Authenticated Sequence Mode (ASM) . . . . . . . . . . . . 13
	3.6.1. ASM-Encrypt . . . . . . . . . . . . . . . . . . . . . 14		3.6.1. ASM-Encrypt . . . . . . . . . . . . . . . . . . . . . 14
	3.6.2. ASM-Decrypt . . . . . . . . . . . . . . . . . . . . . 15		3.6.2. ASM-Decrypt . . . . . . . . . . . . . . . . . . . . . 15
	3.6.3. ASM-Update . . . . . . . . . . . . . . . . . . . . . . 15		3.6.3. ASM-Update . . . . . . . . . . . . . . . . . . . . . . 16
	3.7. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 16		3.7. Re-keying . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.8. Session caching . . . . . . . . . . . . . . . . . . . . . 16		3.8. Session caching . . . . . . . . . . . . . . . . . . . . . 17
	3.8.1. Session caching control . . . . . . . . . . . . . . . 17		3.8.1. Session caching control . . . . . . . . . . . . . . . 17
	4. Extensions to TCP . . . . . . . . . . . . . . . . . . . . . . 17		4. Extensions to TCP . . . . . . . . . . . . . . . . . . . . . . 18
	4.1. Protocol states . . . . . . . . . . . . . . . . . . . . . 18		4.1. Protocol states . . . . . . . . . . . . . . . . . . . . . 18
	4.2. Role negotiation . . . . . . . . . . . . . . . . . . . . . 22		4.2. Role negotiation . . . . . . . . . . . . . . . . . . . . . 23
	4.2.1. Simultaneous open . . . . . . . . . . . . . . . . . . 23		4.2.1. Simultaneous open . . . . . . . . . . . . . . . . . . 24
	4.3. The TCP CRYPT option . . . . . . . . . . . . . . . . . . . 24		4.3. The TCP CRYPT option . . . . . . . . . . . . . . . . . . . 25
	4.3.1. The HELLO suboption . . . . . . . . . . . . . . . . . 27		4.3.1. The HELLO suboption . . . . . . . . . . . . . . . . . 28
	4.3.2. The DECLINE suboption . . . . . . . . . . . . . . . . 28		4.3.2. The DECLINE suboption . . . . . . . . . . . . . . . . 29
	4.3.3. The NEXTK1 and NEXTK2 suboptions . . . . . . . . . . . 28		4.3.3. The NEXTK1 and NEXTK2 suboptions . . . . . . . . . . . 29
	4.3.4. The PKCONF suboption . . . . . . . . . . . . . . . . . 30		4.3.4. The PKCONF suboption . . . . . . . . . . . . . . . . . 31
	4.3.5. The UNKNOWN suboption . . . . . . . . . . . . . . . . 31		4.3.5. The UNKNOWN suboption . . . . . . . . . . . . . . . . 32
	4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions . . . . . . . . 32		4.3.6. The SYNCOOKIE and ACKCOOKIE suboptions . . . . . . . . 33
	4.3.7. The SYNC_REQ and SYNC_OK suboptions . . . . . . . . . 32		4.3.7. The SYNC_REQ and SYNC_OK suboptions . . . . . . . . . 33
	4.3.8. The REKEY and REKEYSTREAM suboptions . . . . . . . . . 34		4.3.8. The REKEY and REKEYSTREAM suboptions . . . . . . . . . 35
	4.3.9. The INIT1 and INIT2 suboptions . . . . . . . . . . . . 37		4.3.9. The INIT1 and INIT2 suboptions . . . . . . . . . . . . 38
	4.4. The TCP MAC option . . . . . . . . . . . . . . . . . . . . 38		4.4. The TCP MAC option . . . . . . . . . . . . . . . . . . . . 39
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	5.1. Example 1: Normal handshake . . . . . . . . . . . . . . . 41		5.1. Example 1: Normal handshake . . . . . . . . . . . . . . . 42
	5.2. Example 2: Normal handshake with SYN cookie . . . . . . . 41		5.2. Example 2: Normal handshake with SYN cookie . . . . . . . 42
	5.3. Example 3: tcpcrypt unsupported . . . . . . . . . . . . . 41		5.3. Example 3: tcpcrypt unsupported . . . . . . . . . . . . . 42
	5.4. Example 4: Reusing established state . . . . . . . . . . . 42		5.4. Example 4: Reusing established state . . . . . . . . . . . 43
	5.5. Example 5: Decline of state reuse . . . . . . . . . . . . 42		5.5. Example 5: Decline of state reuse . . . . . . . . . . . . 43
	5.6. Example 6: Reversal of client and server roles . . . . . . 42		5.6. Example 6: Reversal of client and server roles . . . . . . 43
	6. API extensions . . . . . . . . . . . . . . . . . . . . . . . . 42		6. API extensions . . . . . . . . . . . . . . . . . . . . . . . . 43
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 47		9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 47		10.1. Normative References . . . . . . . . . . . . . . . . . . . 49
	10.2. Informative References . . . . . . . . . . . . . . . . . . 48		10.2. Informative References . . . . . . . . . . . . . . . . . . 49
	Appendix A. Protocol constant values . . . . . . . . . . . . . . 49		Appendix A. Protocol constant values . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Introduction		2. Introduction
	This document describes tcpcrypt, an extension to TCP for		This document describes tcpcrypt, an extension to TCP for
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 38 ¶
	ENC (PK_C, R_S) denotes an encryption of R_S with public key PK_C.		ENC (PK_C, R_S) denotes an encryption of R_S with public key PK_C.
	R_S and N_S are random values chosen by S. Their lengths are defined		R_S and N_S are random values chosen by S. Their lengths are defined
	in Figure 3. PK_S is S's key agreement parameter. PMS is the Pre		in Figure 3. PK_S is S's key agreement parameter. PMS is the Pre
	Master Secret from which keys are ultimately derived.		Master Secret from which keys are ultimately derived.
	Table 1		Table 1
	The two sides then compute a pseudo-random key (PRK) from which all		The two sides then compute a pseudo-random key (PRK) from which all
	session keys are derived as follows:		session keys are derived as follows:
	param := { pub-cipher-list, sym-cipher-list,		param := { num-pub-ciphers, pub-cipher-list, init1, init2 }
	sym-cipher, pub-cipher }		PRK := Extract (N_C, { param, PMS })
	PRK := Extract (N_C, { param, PK_C, KX_S, PMS })
			Here num-pub-ciphers is a single octet specifying how many three-byte
			algorithm specifiers were provided by the "S" host in a PKCONF
			suboption (described in Section 4.3.4). pub-cipher-list is this many
			three-byte specifiers, taken from the body of the PKCONF suboption.
			init1 and init2 are the complete data payload from the TCP segments
			with the INIT1 and INIT2 suboptions (detailed in Section 4.3.9).
	A series of "session secrets" and corresponding Session IDs are then		A series of "session secrets" and corresponding Session IDs are then
	computed as follows:		computed as follows:
	ss[0] := PRK		ss[0] := PRK
	ss[i] := CPRF (ss[i-1], CONST_NEXTK, K_LEN)		ss[i] := CPRF (ss[i-1], CONST_NEXTK, K_LEN)
	SID[i] := CPRF (ss[i], CONST_SESSID, K_LEN)		SID[i] := CPRF (ss[i], CONST_SESSID, K_LEN)
	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
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 24 ¶
	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.8. The TAG values are constants defined in Table 7. The		Section 3.8. The TAG values are constants defined in Table 7. The
	K_LEN values and nonce sizes are negotiated, and are specified in		K_LEN values and nonce sizes are negotiated, and are specified in
	Figure 3.		Figure 3.
	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 | flags, K_LEN)
	mk[i] := CPRF (mk[i-1], CONST_REKEY, K_LEN)		mk[i] := CPRF (mk[i-1], CONST_REKEY, K_LEN)
			Where flags is a single octet from 0x0 to 0x3 computed as follows:
			bit 0 1 2 3 4 5 6 7
			+-+-+-+-+-+-+-+-+
			|0 0 0 0 0 0 s c|
			+-+-+-+-+-+-+-+-+
			Here bit "s" is set when the "S" mode host has indicated application-
			level support for tcpcrypt. The "c" bit is set when the "C" mode
			host has indicated application-level support for tcpcrypt. Both bits
			are 0 by default unless the application has enabled the
			TCP_CRYPT_SUPPORT option described in Section 6.
	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 "S" and "C" roles. Key k_cs is used		authenticated encryption for the "S" and "C" roles. Key k_cs is used
	by "C" to encrypt and "S" to decrypt, while k_sc is used by "S" to		by "C" to encrypt and "S" to decrypt, while k_sc is used by "S" to
	encrypt and "C" to decrypt.		encrypt and "C" to decrypt.
	k_cs := CPRF (mk, CONST_KEY_C, ae_len)		k_cs := CPRF (mk, CONST_KEY_C, ae_len)
	k_sc := CPRF (mk, CONST_KEY_S, ae_len)		k_sc := CPRF (mk, CONST_KEY_S, ae_len)
	tcpcrypt does not use HKDF directly for key derivation because it		tcpcrypt does not use HKDF directly for key derivation because it
	requires multiple expand steps with different keys. This is needed		requires multiple expand steps with different keys. This is needed
	skipping to change at page 30, line 47 ¶		skipping to change at page 31, line 47 ¶
	|0| Algorithm identifier |		|0| Algorithm identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Format of algorithm specifier within PKCONF. Fields starting with 1		Format of algorithm specifier within PKCONF. Fields starting with 1
	are reserved for future use by algorithm identifiers longer than		are reserved for future use by algorithm identifiers longer than
	three bytes.		three bytes.
	The algorithm identifier specifies a number of parameters, defined in		The algorithm identifier specifies a number of parameters, defined in
	Figure 3.		Figure 3.
	Hosts MUST implement OAEP+-RSA3 and ECDHE-P256 and ECDHE-P521.		Hosts MUST implement OAEP+-RSA3 and ECDHE-P256 and ECDHE-P521, but
			MAY by default disable certain algorithms and key sizes. In
			particular, implementations SHOULD disable larger RSA keys (Algorithm
			identifiers 0x102-0x103) by default unless such larger keys and
			ciphertexts can fit into a single TCP segment.
	Servers demanding utmost performance SHOULD use RSA because the RSA		Servers demanding utmost performance SHOULD use RSA because the RSA
	encrypt operation is must faster than Diffie-Hellman operations,		encrypt operation is must faster than Diffie-Hellman operations,
	resulting in a higher connection rate.		resulting in a higher connection rate.
	Depending on the encoding of the PKCONF suboption (see Table 4), it		Depending on the encoding of the PKCONF suboption (see Table 4), it
	can indicate whether "S's" application is tcpcrypt-aware or not. For		can indicate whether "S's" application is tcpcrypt-aware or not. For
	the "C" role, the encoding of the HELLO suboption does this. This		the "C" role, the encoding of the HELLO suboption does this. This
	mechanism can be used for bootstrapping application-level		mechanism can be used for bootstrapping application-level
	authentication without requiring probing in upper layer protocols to		authentication without requiring probing in upper layer protocols to
	skipping to change at page 46, line 9 ¶		skipping to change at page 47, line 9 ¶
	TCP CRYPT suboptions.		TCP CRYPT suboptions.
	Table 5		Table 5
	A "tcpcrypt Algorithm Identifiers" registry needs to be maintained by		A "tcpcrypt Algorithm Identifiers" registry needs to be maintained by
	IANA as per the following table.		IANA as per the following table.
	+-----------------------------------------------------------+		+-----------------------------------------------------------+
	| Algorithm Identifier | Value |		| Algorithm Identifier | Value |
	+------------------------------------------------+----------+		+------------------------------------------------+----------+
	| Cipher: OAEP+-RSA with exponent 3 | 0x000100 |		| Cipher: OAEP+-RSA with exponent 3 | |
			| min/max key size 2048/4096 bits ... | 0x000100 |
			| min/max key size 4096/8192 bits ... | 0x000101 |
			| min/max key size 8192/16384 bits .. | 0x000102 |
			| min key size 16384 bits ....... | 0x000103 |
	| Extract: HKDF-Extract-SHA256 | |		| Extract: HKDF-Extract-SHA256 | |
	| CPRF: HKDF-Expand-SHA256 | |		| CPRF: HKDF-Expand-SHA256 | |
	| N_C len: 32 bytes | |		| N_C len: 32 bytes | |
	| R_S len: 48 bytes | |		| R_S len: 48 bytes | |
	| K_LEN: 32 bytes | |		| K_LEN: 32 bytes | |
	+------------------------------------------------+----------+		+------------------------------------------------+----------+
	| Cipher: ECDHE-P256 | 0x000200 |		| Cipher: ECDHE-P256 | 0x000200 |
	| Extract: HKDF-Extract-SHA256 | |		| Extract: HKDF-Extract-SHA256 | |
	| CPRF: HKDF-Expand-SHA256 | |		| CPRF: HKDF-Expand-SHA256 | |
	| N_C len: 32 bytes | |		| N_C len: 32 bytes | |
End of changes. 11 change blocks.
	41 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/