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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/