< draft-ietf-tcpinc-api-05.txt		draft-ietf-tcpinc-api-06.txt >
	Network Working Group A. Bittau		Network Working Group A. Bittau
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational D. Boneh		Intended status: Informational D. Boneh
	Expires: April 2, 2018 D. Giffin		Expires: December 31, 2018 D. Giffin
	Stanford University		Stanford University
	M. Handley		M. Handley
	University College London		University College London
	D. Mazieres		D. Mazieres
	Stanford University		Stanford University
	E. Smith		E. Smith
	Kestrel Institute		Kestrel Institute
	September 29, 2017		June 29, 2018
	Interface Extensions for TCP-ENO and tcpcrypt		Interface Extensions for TCP-ENO and tcpcrypt
	draft-ietf-tcpinc-api-05		draft-ietf-tcpinc-api-06
	Abstract		Abstract
	TCP-ENO and tcpcrypt perform encryption at the transport layer. They		TCP-ENO and tcpcrypt perform encryption at the transport layer. They
	also define a few parameters that are intended to be used or		also define a few parameters that are intended to be used or
	configured by applications. This document specifies operating system		configured by applications. This document specifies operating system
	interfaces for access to these parameters. We describe the		interfaces for access to these parameters. We describe the
	interfaces in terms of socket options, the de facto standard API for		interfaces in terms of socket options, the de facto standard API for
	adjusting per-connection behavior in TCP/IP, and sysctl, a popular		adjusting per-connection behavior in TCP/IP, and sysctl, a popular
	mechanism for setting global defaults. Operating systems that lack		mechanism for setting global defaults. Operating systems that lack
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 https://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 2, 2018.		This Internet-Draft will expire on December 31, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	2.2. System-wide options . . . . . . . . . . . . . . . . . . . 7		2.2. System-wide options . . . . . . . . . . . . . . . . . . . 7
	3. tcpcrypt API extensions . . . . . . . . . . . . . . . . . . . 8		3. tcpcrypt API extensions . . . . . . . . . . . . . . . . . . . 8
	3.1. Per-connection options . . . . . . . . . . . . . . . . . 8		3.1. Per-connection options . . . . . . . . . . . . . . . . . 8
	3.2. System-wide options . . . . . . . . . . . . . . . . . . . 9		3.2. System-wide options . . . . . . . . . . . . . . . . . . . 9
	4. Example API mappings . . . . . . . . . . . . . . . . . . . . 9		4. Example API mappings . . . . . . . . . . . . . . . . . . . . 9
	4.1. Socket options for per-connection settings . . . . . . . 10		4.1. Socket options for per-connection settings . . . . . . . 10
	4.2. Setting System-wide options with sysctl . . . . . . . . . 10		4.2. Setting System-wide options with sysctl . . . . . . . . . 10
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Cookie-based authentication . . . . . . . . . . . . . . . 11		5.1. Cookie-based authentication . . . . . . . . . . . . . . . 11
	5.2. Signature-based authentication . . . . . . . . . . . . . 11		5.2. Signature-based authentication . . . . . . . . . . . . . 11
	6. Security considerations . . . . . . . . . . . . . . . . . . . 11		6. Security considerations . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The TCP Encryption Negotiation Option (TCP-ENO)		The TCP Encryption Negotiation Option (TCP-ENO)
	[I-D.ietf-tcpinc-tcpeno] permits hosts to negotiate encryption of a		[I-D.ietf-tcpinc-tcpeno] permits hosts to negotiate encryption of a
	TCP connection. One of TCP-ENO's use cases is to encrypt traffic		TCP connection. One of TCP-ENO's use cases is to encrypt traffic
	transparently, unbeknownst to legacy applications. Transparent		transparently, unbeknownst to legacy applications. Transparent
	encryption requires no changes to existing APIs. However, other use		encryption requires no changes to existing APIs. However, other use
	cases require applications to interact with TCP-ENO. In particular:		cases require applications to interact with TCP-ENO. In particular:
	skipping to change at page 11, line 8 ¶		skipping to change at page 11, line 8 ¶
	bit. To signal it has been upgraded to support application-level		bit. To signal it has been upgraded to support application-level
	authentication, an application should set the second-least		authentication, an application should set the second-least
	significant bit of "TCP_ENO_SELF_GOPT" before opening a connection.		significant bit of "TCP_ENO_SELF_GOPT" before opening a connection.
	An application should then check that "TCP_ENO_PEER_GOPT" has this		An application should then check that "TCP_ENO_PEER_GOPT" has this
	bit set before attempting to send authenticators that would otherwise		bit set before attempting to send authenticators that would otherwise
	be misinterpreted as application data.		be misinterpreted as application data.
	5.1. Cookie-based authentication		5.1. Cookie-based authentication
	In cookie-based authentication, a client and server both share a		In cookie-based authentication, a client and server both share a
	cryptographically strong random or pseudo-random secret known as a		cryptographically strong random or pseudo-random pre-shared secret
	"cookie". Such a cookie is preferably at least 128 bits long. To		known as a "cookie". Such a cookie is preferably at least 128 bits
	authenticate a session ID using a cookie, each host computes and		long. To authenticate a session ID using a cookie, each host
	sends the following value to the other side:		computes and sends the following value to the other side:
	authenticator = PRF(cookie, local-name)		authenticator = PRF(cookie, local-name)
	Here "PRF" is a pseudo-random function such as HMAC-SHA-256		Here "PRF" is a pseudo-random function such as HMAC-SHA-256
	[RFC6234]. "local-name" is the result of the "TCP_ENO_LOCAL_NAME"		[RFC6234]. "local-name" is the result of the "TCP_ENO_SELF_NAME"
	socket option. Each side must verify that the other side's		socket option. Each side must verify that the other side's
	authenticator is correct. To do so, software obtains the remote		authenticator is correct. To do so, software obtains the remote
	host's name via the "TCP_ENO_PEER_NAME" socket option. Assuming the		host's name via the "TCP_ENO_PEER_NAME" socket option. Assuming the
	authenticators are correct, applications can rely on the TCP-layer		authenticators are correct, applications can rely on the TCP-layer
	encryption for resistance against active network attackers.		encryption for resistance against active network attackers.
	Note that if the same cookie is used in other contexts besides		Note that if the same cookie is used in other contexts besides
	session ID authentication, appropriate domain separation must be		session ID authentication, appropriate domain separation must be
	employed, such as prefixing "local-name" with a unique prefix to		employed, such as prefixing "local-name" with a unique prefix to
	ensure "authenticator" cannot be used out of context.		ensure "authenticator" cannot be used out of context.
			Establishing pre-shared secrets can involve a computational or
			administrative burden, while computing and verifying PRF-based
			authenticators is inexpensive. Hence, applications with pre-shared
			secrets should whenever possible leverage those secrets to achieve
			mutual authentication by sending one authenticator in each direction.
	5.2. Signature-based authentication		5.2. Signature-based authentication
	In signature-based authentication, one or both endpoints of a		In signature-based authentication, one or both endpoints of a
	connection possess a private signature key the public half of which		connection possess a private signature key the public half of which
	is known to or verifiable by the other endpoint. To authenticate		is known to or verifiable by the other endpoint. To authenticate
	itself, the host with a private key computes the following signature:		itself, a host uses its private key to compute the following
			signature:
	authenticator = Sign(PrivKey, local-name)		authenticator = Sign(PrivKey, local-name)
	The other end verifies this value using the corresponding public key.		The other end verifies this value using the corresponding public key.
	Whichever side validates an authenticator in this way knows that the		Whichever side validates an authenticator in this way knows that the
	other side belongs to a host that possesses the appropriate signature		other side belongs to a host that possesses the appropriate signature
	key.		key.
	Once again, if the same signature key is used in other contexts		Once again, if the same signature key is used in other contexts
	besides session ID authentication, appropriate domain separation		besides session ID authentication, appropriate domain separation
	should be employed, such as prefixing "local-name" with a unique		should be employed, such as prefixing "local-name" with a unique
	prefix to ensure "authenticator" cannot be used out of context.		prefix to ensure "authenticator" cannot be used out of context.
			Note that signature-based authentication can be either mutual, if
			both sides have public keys, or unidirectional, when one endpoint is
			anonymous.
	6. Security considerations		6. Security considerations
	The TCP-ENO specification [I-D.ietf-tcpinc-tcpeno] discusses several		The TCP-ENO specification [I-D.ietf-tcpinc-tcpeno] discusses several
	important security considerations that this document incorporates by		important security considerations that this document incorporates by
	reference. The most important one, which bears reiterating, is that		reference. The most important one, which bears reiterating, is that
	until and unless a session ID has been authenticated, TCP-ENO is		until and unless a session ID has been authenticated, TCP-ENO is
	vulnerable to an active network attacker, through either a downgrade		vulnerable to an active network attacker, through either a downgrade
	or active man-in-the-middle attack.		or active man-in-the-middle attack.
	Because of this vulnerability to active network attackers, it is		Because of this vulnerability to active network attackers, it is
	skipping to change at page 12, line 36 ¶		skipping to change at page 12, line 47 ¶
	work was partially funded by DARPA CRASH and the Stanford Secure		work was partially funded by DARPA CRASH and the Stanford Secure
	Internet of Things Project.		Internet of Things Project.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-tcpinc-tcpcrypt]		[I-D.ietf-tcpinc-tcpcrypt]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
	Q., and E. Smith, "Cryptographic protection of TCP Streams		Q., and E. Smith, "Cryptographic protection of TCP Streams
	(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-06 (work in		(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in
	progress), March 2017.		progress), November 2017.
	[I-D.ietf-tcpinc-tcpeno]		[I-D.ietf-tcpinc-tcpeno]
	Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.		Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
	Smith, "TCP-ENO: Encryption Negotiation Option", draft-		Smith, "TCP-ENO: Encryption Negotiation Option", draft-
	ietf-tcpinc-tcpeno-09 (work in progress), August 2017.		ietf-tcpinc-tcpeno-18 (work in progress), November 2017.
	8.2. Informative References		8.2. Informative References
	[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",		[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
	RFC 896, DOI 10.17487/RFC0896, January 1984,		RFC 896, DOI 10.17487/RFC0896, January 1984,
	<https://www.rfc-editor.org/info/rfc896>.		<https://www.rfc-editor.org/info/rfc896>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
End of changes. 14 change blocks.
	16 lines changed or deleted		27 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/