[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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


   OPSEC:  TCP Opportunistic Security Option

   TCP:  Transmission Control Protocol

   TLS:  Transport Layer Security Protocol

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

   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

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

   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:


   The following cipher suites SHOULD be supported:




   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

   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

              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

   Phone: +81-3-5412-8436
   Email: mwp@qualcomm.com

   Greg Rose
   Qualcomm Inc.
   5775 Morehouse Drive
   San Diego, California  92121

   Phone: +1-858-651-5733
   Email: ggr@qualcomm.com

Paddon & Rose           Expires October 30, 2009               [Page 14]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/