Network Working Group M. Paddon Internet-Draft G. Rose Intended status: Informational Qualcomm Expires: October 30, 2009 April 28, 2009 TCP Opportunistic Security (OPSEC) Option draft-paddon-tcposp-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 30, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Paddon & Rose Expires October 30, 2009 [Page 1] Internet-Draft TCP OPSEC Option April 2009 Abstract The TCP Opportunistic Security (OPSEC) option enables cooperating peers to opportunistically negotiate the use of an end to end security protocol on a per connection basis. The negotiated protocol is used to transparently secure application data for the life of the connection, providing protection against all passive and some active attacks. Security protocols may operate anonymously or make opportunistic use of available key material. Backwards compatibility with non-OPSEC-aware hosts is maintained, thereby permitting incremental deployment of this mechanism. Paddon & Rose Expires October 30, 2009 [Page 2] Internet-Draft TCP OPSEC Option April 2009 Comments and Discussion Please send feedback on this draft to tsv-area@ietf.org. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Security Proposal . . . . . . . . . . . . . . . . . . . . 6 3.3. Security Response . . . . . . . . . . . . . . . . . . . . 7 3.4. Security Association . . . . . . . . . . . . . . . . . . . 7 3.5. Segment Retransmission . . . . . . . . . . . . . . . . . . 7 4. Security Protocol Identifiers . . . . . . . . . . . . . . . . 8 4.1. TLS (Protocol = 0) . . . . . . . . . . . . . . . . . . . . 8 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Paddon & Rose Expires October 30, 2009 [Page 3] Internet-Draft TCP OPSEC Option April 2009 1. Introduction A significant proportion of the TCP traffic carried by the public internet is unsecured. This traffic may be subject to both passive attacks (such as eavesdropping) and active attacks (such as packet modification or injection). Various mechanisms exist to establish end to end security, including IPSec [RFC2401] at the IP layer and TLS [RFC5246] at the transport layer. IPSec is transparent to applications and is commonly used between cooperating sites to create virtual private networks. IPSec can support opportunistic encryption [RFC4322], however such mechanisms have not been deployed widely. This is perhaps due to lack of IPSec implementation support or administrative complexities in dealing with various middleboxes such as firewalls and network address translators. TLS is widely deployed and interoperates better with such middleboxes, however applications, in general, must be TLS aware. Opportunistic encryption is often implemented by specific protocol directives such as the SMTP "STARTTLS" [RFC2487]. As a result of these barriers, in practice a significant proportion of TCP traffic traversing public links remains unsecured plain text. There exists a need for an application transparent, opportunistic and best-effort mechanism to secure this traffic. Such a mechanism must provide useful security between anonymous end points and hence require no key management. Additional security, however, should be achievable when key material is available. This memo describes the TCP Opportunistic Security (OPSEC) option. Cooperating TCP peers may use the OPSEC option to negotiate an end to end security protocol to be applied to TCP payload data on a per connection basis. Peers that do not implement the OPSEC option will ignore the negotiation attempt, and the unsecured TCP connection will proceed as usual. The OPSEC negotiation, and any subsequent opportunistic security applied to payload data, is completely transparent to applications. OPSEC does not provide any type of connection latching to security parameters; it is purely best effort, and on a connection by connection basis. Applications which require connection latching should use mechanisms such as those defined in [I-D.ietf-btns-connection-latching]. Implementations may, however, provide methods to selectively enable or disable the mechanism, or query its status for a given connection. Similar opportunistic security mechanisms might be defined for UDP [RFC0768] flows, using security procotols such as DTLS [RFC4347]. Such mechanisms are outside the scope of this memo. Paddon & Rose Expires October 30, 2009 [Page 4] Internet-Draft TCP OPSEC Option April 2009 2. Terminology Abbreviations: OPSEC: TCP Opportunistic Security Option TCP: Transmission Control Protocol TLS: Transport Layer Security Protocol The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Paddon & Rose Expires October 30, 2009 [Page 5] Internet-Draft TCP OPSEC Option April 2009 3. Operation The OPSEC option is used by TCP peers to propose and accept an opportunistic security protocol. If the negotiation succeeds, the agreed protocol is subsequently used to secure payload data for the life of a TCP connection. The TCP connection state machine is unchanged, and OPSEC negotiation occurs as part of the usual TCP handshake. If either peer does not support the OPSEC option, or the security protocol negotiation is unsuccessful, the TCP connection operates as per [RFC0793]. 3.1. Option Format The OPSEC option appears in the header of a TCP segment (see [RFC0793] for general information on TCP options). The general form of an OPSEC option is: +--------+--------+ |Kind=TBA| Length | +--------+--------+ | Protocols... +--------+ The fields (and their octet lengths) are defined as follows: Kind (1 octet): The value "TBA" identifies an OPSEC option. Length (1 octet): The total length of the option in octets, including the Kind, Length and SPID fields. Protocols (variable): A list of security protocol identifiers. Protocol identifiers are exactly one octet in length and are defined in Section 4. The option MUST contain at least one and MAY contain multiple protocol identifiers. 3.2. Security Proposal An OPSEC option MAY be included in a SYN segment. This indicates that the initiator wishes to employ opportunistic encryption on this connection. The option proposes a set of protocols to be used for opportunistic security, in order of preference (most preferred first). Paddon & Rose Expires October 30, 2009 [Page 6] Internet-Draft TCP OPSEC Option April 2009 3.3. Security Response An OPSEC option MAY be included in a SYN-ACK or an ACK segment transmitted in response to a SYN segment. This indicates that the responder agrees to employ an opportunistic security protocol on this connection. A responder MAY always choose to omit the OPSEC option from a response to a SYN segment, thereby indicating that opportunistic security negotiation has failed. If an OPSEC option is included, it MUST specify exactly one protocol selected from the list proposed by the received SYN segment. In the case of a SYN-ACK segment, the responder is free to select any of the proposed protocols. In the case of an ACK segment, note that the responder has (according to the TCP state machine) previously transmitted a SYN segment which may have included an OPSEC proposal. The responder MUST select the highest numbered protocol common to the the list proposed by the received SYN segment and any previously transmitted SYN segment. If there is no such protocol, then the OPSEC option MUST be omitted from the ACK segment. 3.4. Security Association Once the TCP connection reaches state "ESTABLISHED" as per [RFC0793], and if a security protocol has been successfully negotiated, the peers MUST establish an end to end security association using the negotiated protocol prior to the transmission of any application data. Once a security association is established, all application data MUST be secured according the negotiated security protocol. Prior to closing the TCP connection, peers SHOULD engage in an orderly shutdown of security protocol. If the security protocol fails at any time, a peer SHOULD immediately reset and abandon the TCP connection. 3.5. Segment Retransmission If an OPSEC option is present in a segment, an identical option MUST be included in all retransmissions of that segment. Paddon & Rose Expires October 30, 2009 [Page 7] Internet-Draft TCP OPSEC Option April 2009 4. Security Protocol Identifiers The currently defined opportunistic security protocol identifiers are: 0: TLS as defined in [RFC5246] 4.1. TLS (Protocol = 0) The TLS protocol is used to form a security association and protect application data. The following cipher suites MUST be supported: TLS_DH_anon_WITH_AES_128_CBC_SHA The following cipher suites SHOULD be supported: TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 Other cipher suites MAY be supported, including those which require non-anonymous key exchanges. The management of key material for non- anonymous cipher suites is outside the scope of this memo. Paddon & Rose Expires October 30, 2009 [Page 8] Internet-Draft TCP OPSEC Option April 2009 5. Implementation Issues Implementations MAY selectively enable or disable use of the OPSEC option. For example, by convention, connections to TCP port 443 are already secured by TLS and therefore the imposition of an additional security layer is pure overhead. In such cases, an implementation might apply rules to select connections for which OPSEC is appropriate. Implementations MAY expose methods to applications to allow them to explicitly enable or disable use of OPSEC, or determine the opportunistic security status of a given connection. Such mechanisms are primarily useful for disabling OPSEC in specific circumstances for reasons of efficiency. However, application awareness of OPSEC is generally unnecessary by design. Paddon & Rose Expires October 30, 2009 [Page 9] Internet-Draft TCP OPSEC Option April 2009 6. Security Considerations The security goal of the OPSEC option is to opportunistically establish the greatest degree of end to end security possible on a per connection basis, operating without the necessity for configuration or key management. If secure communications are required by an application, then the mandatory use of a security protocol is strongly recommended. OSPEC MUST NOT be relied upon to provide security in such cases. Rather, the intent of OPSEC is to usefully improve the security of otherwise unsecured traffic, on a scale that makes mass subversion of the mechanism uneconomical. The intended outcome is to enhance the average privacy of security naive applications and reduce the inadvertent exposure of sensitive data. The threats addressed by a successfully negotiated OPSEC-enable connection are: Eavesdropping: Passive, on-path attackers may inspect all packets. Application data is secured to the limits of the negotiated security protocol and the cipher suites it employs. Implementations SHOULD prefer protocols and cipher suites with strong privacy protection. Modification/injection: Active attackers may modify or inject packets (including replays). Application data is secured to the limits of the negotiated security protocol and the cipher suites it employs. Implementations SHOULD prefer protocols and cipher suites with strong integrity and replay protection. Man-in-the-middle: Active, on-path attackers may interpose themselves in the key exchange protocol. In the special case of authentication key material being available to the negotiated security protocol, application data is secured to the limits of that protocol. In the general case of anonymous key exchange (such as Diffie-Hellman), security is no better than plain text. As a matter of good practice, peers SHOULD prefer non-anonymous key exchanges when supported by the negotiated security protocol and available key material. Active on-path attacks are, in general, not addressed by the OPSEC threat model. As well as the man-in-the-middle threat noted above, such attackers can modify TCP segments prior to connection establishment to weaken or disable OPSEC negotiation. Conversely, OPSEC provides application payloads with good security benefits against passive attacks and active off-path attacks. Some security protocols negotiated by OPSEC may support the reuse of security associations. For instance, TLS provides a session Paddon & Rose Expires October 30, 2009 [Page 10] Internet-Draft TCP OPSEC Option April 2009 resumption mechanism. The reuse of session key material for distinct TCP connections is risky since the connections may not share the same security context. If one of the connections is controlled by an attacker, this creates a known plaintext scenario even if the key is not exposed at the user level. Consequently, implementations SHOULD NOT reuse session key material for distinct TCP connections. Paddon & Rose Expires October 30, 2009 [Page 11] Internet-Draft TCP OPSEC Option April 2009 7. Acknowledgments The authors wish to thank David Jacobson, Pete Resnick and Paul Hoffman for their contributions to this memo. Paddon & Rose Expires October 30, 2009 [Page 12] Internet-Draft TCP OPSEC Option April 2009 8. References 8.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8.2. Informative References [I-D.ietf-btns-connection-latching] Williams, N., "IPsec Channels: Connection Latching", draft-ietf-btns-connection-latching-10 (work in progress), April 2009. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999. [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. Paddon & Rose Expires October 30, 2009 [Page 13] Internet-Draft TCP OPSEC Option April 2009 Authors' Addresses Michael Paddon Qualcomm Japan Inc. Shin Aoyama Bldg West, 18th Floor 1-1-1 Minami Aoyama Minato-ku, Tokyo-to 107-0062 Japan Phone: +81-3-5412-8436 Email: mwp@qualcomm.com Greg Rose Qualcomm Inc. 5775 Morehouse Drive San Diego, California 92121 U.S.A. Phone: +1-858-651-5733 Email: ggr@qualcomm.com Paddon & Rose Expires October 30, 2009 [Page 14]