idnits 2.17.1 draft-paddon-tcposp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2009) is 5470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-10 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2487 (Obsoleted by RFC 3207) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Paddon 3 Internet-Draft G. Rose 4 Intended status: Informational Qualcomm 5 Expires: October 30, 2009 April 28, 2009 7 TCP Opportunistic Security (OPSEC) Option 8 draft-paddon-tcposp-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 30, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The TCP Opportunistic Security (OPSEC) option enables cooperating 47 peers to opportunistically negotiate the use of an end to end 48 security protocol on a per connection basis. The negotiated protocol 49 is used to transparently secure application data for the life of the 50 connection, providing protection against all passive and some active 51 attacks. Security protocols may operate anonymously or make 52 opportunistic use of available key material. Backwards compatibility 53 with non-OPSEC-aware hosts is maintained, thereby permitting 54 incremental deployment of this mechanism. 56 Comments and Discussion 58 Please send feedback on this draft to tsv-area@ietf.org. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Security Proposal . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Security Response . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Security Association . . . . . . . . . . . . . . . . . . . 7 69 3.5. Segment Retransmission . . . . . . . . . . . . . . . . . . 7 70 4. Security Protocol Identifiers . . . . . . . . . . . . . . . . 8 71 4.1. TLS (Protocol = 0) . . . . . . . . . . . . . . . . . . . . 8 72 5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 A significant proportion of the TCP traffic carried by the public 83 internet is unsecured. This traffic may be subject to both passive 84 attacks (such as eavesdropping) and active attacks (such as packet 85 modification or injection). 87 Various mechanisms exist to establish end to end security, including 88 IPSec [RFC2401] at the IP layer and TLS [RFC5246] at the transport 89 layer. IPSec is transparent to applications and is commonly used 90 between cooperating sites to create virtual private networks. IPSec 91 can support opportunistic encryption [RFC4322], however such 92 mechanisms have not been deployed widely. This is perhaps due to 93 lack of IPSec implementation support or administrative complexities 94 in dealing with various middleboxes such as firewalls and network 95 address translators. TLS is widely deployed and interoperates better 96 with such middleboxes, however applications, in general, must be TLS 97 aware. Opportunistic encryption is often implemented by specific 98 protocol directives such as the SMTP "STARTTLS" [RFC2487]. 100 As a result of these barriers, in practice a significant proportion 101 of TCP traffic traversing public links remains unsecured plain text. 102 There exists a need for an application transparent, opportunistic and 103 best-effort mechanism to secure this traffic. Such a mechanism must 104 provide useful security between anonymous end points and hence 105 require no key management. Additional security, however, should be 106 achievable when key material is available. 108 This memo describes the TCP Opportunistic Security (OPSEC) option. 109 Cooperating TCP peers may use the OPSEC option to negotiate an end to 110 end security protocol to be applied to TCP payload data on a per 111 connection basis. Peers that do not implement the OPSEC option will 112 ignore the negotiation attempt, and the unsecured TCP connection will 113 proceed as usual. 115 The OPSEC negotiation, and any subsequent opportunistic security 116 applied to payload data, is completely transparent to applications. 117 OPSEC does not provide any type of connection latching to security 118 parameters; it is purely best effort, and on a connection by 119 connection basis. Applications which require connection latching 120 should use mechanisms such as those defined in 121 [I-D.ietf-btns-connection-latching]. Implementations may, however, 122 provide methods to selectively enable or disable the mechanism, or 123 query its status for a given connection. 125 Similar opportunistic security mechanisms might be defined for UDP 126 [RFC0768] flows, using security procotols such as DTLS [RFC4347]. 127 Such mechanisms are outside the scope of this memo. 129 2. Terminology 131 Abbreviations: 133 OPSEC: TCP Opportunistic Security Option 135 TCP: Transmission Control Protocol 137 TLS: Transport Layer Security Protocol 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Operation 145 The OPSEC option is used by TCP peers to propose and accept an 146 opportunistic security protocol. If the negotiation succeeds, the 147 agreed protocol is subsequently used to secure payload data for the 148 life of a TCP connection. The TCP connection state machine is 149 unchanged, and OPSEC negotiation occurs as part of the usual TCP 150 handshake. 152 If either peer does not support the OPSEC option, or the security 153 protocol negotiation is unsuccessful, the TCP connection operates as 154 per [RFC0793]. 156 3.1. Option Format 158 The OPSEC option appears in the header of a TCP segment (see 159 [RFC0793] for general information on TCP options). The general form 160 of an OPSEC option is: 162 +--------+--------+ 163 |Kind=TBA| Length | 164 +--------+--------+ 165 | Protocols... 166 +--------+ 168 The fields (and their octet lengths) are defined as follows: 170 Kind (1 octet): The value "TBA" identifies an OPSEC option. 172 Length (1 octet): The total length of the option in octets, 173 including the Kind, Length and SPID fields. 175 Protocols (variable): A list of security protocol identifiers. 176 Protocol identifiers are exactly one octet in length and are 177 defined in Section 4. The option MUST contain at least one and 178 MAY contain multiple protocol identifiers. 180 3.2. Security Proposal 182 An OPSEC option MAY be included in a SYN segment. This indicates 183 that the initiator wishes to employ opportunistic encryption on this 184 connection. The option proposes a set of protocols to be used for 185 opportunistic security, in order of preference (most preferred 186 first). 188 3.3. Security Response 190 An OPSEC option MAY be included in a SYN-ACK or an ACK segment 191 transmitted in response to a SYN segment. This indicates that the 192 responder agrees to employ an opportunistic security protocol on this 193 connection. A responder MAY always choose to omit the OPSEC option 194 from a response to a SYN segment, thereby indicating that 195 opportunistic security negotiation has failed. If an OPSEC option is 196 included, it MUST specify exactly one protocol selected from the list 197 proposed by the received SYN segment. 199 In the case of a SYN-ACK segment, the responder is free to select any 200 of the proposed protocols. 202 In the case of an ACK segment, note that the responder has (according 203 to the TCP state machine) previously transmitted a SYN segment which 204 may have included an OPSEC proposal. The responder MUST select the 205 highest numbered protocol common to the the list proposed by the 206 received SYN segment and any previously transmitted SYN segment. If 207 there is no such protocol, then the OPSEC option MUST be omitted from 208 the ACK segment. 210 3.4. Security Association 212 Once the TCP connection reaches state "ESTABLISHED" as per [RFC0793], 213 and if a security protocol has been successfully negotiated, the 214 peers MUST establish an end to end security association using the 215 negotiated protocol prior to the transmission of any application 216 data. Once a security association is established, all application 217 data MUST be secured according the negotiated security protocol. 218 Prior to closing the TCP connection, peers SHOULD engage in an 219 orderly shutdown of security protocol. 221 If the security protocol fails at any time, a peer SHOULD immediately 222 reset and abandon the TCP connection. 224 3.5. Segment Retransmission 226 If an OPSEC option is present in a segment, an identical option MUST 227 be included in all retransmissions of that segment. 229 4. Security Protocol Identifiers 231 The currently defined opportunistic security protocol identifiers 232 are: 234 0: TLS as defined in [RFC5246] 236 4.1. TLS (Protocol = 0) 238 The TLS protocol is used to form a security association and protect 239 application data. 241 The following cipher suites MUST be supported: 243 TLS_DH_anon_WITH_AES_128_CBC_SHA 245 The following cipher suites SHOULD be supported: 247 TLS_DH_anon_WITH_AES_256_CBC_SHA 249 TLS_DH_anon_WITH_AES_128_CBC_SHA256 251 TLS_DH_anon_WITH_AES_256_CBC_SHA256 253 Other cipher suites MAY be supported, including those which require 254 non-anonymous key exchanges. The management of key material for non- 255 anonymous cipher suites is outside the scope of this memo. 257 5. Implementation Issues 259 Implementations MAY selectively enable or disable use of the OPSEC 260 option. For example, by convention, connections to TCP port 443 are 261 already secured by TLS and therefore the imposition of an additional 262 security layer is pure overhead. In such cases, an implementation 263 might apply rules to select connections for which OPSEC is 264 appropriate. 266 Implementations MAY expose methods to applications to allow them to 267 explicitly enable or disable use of OPSEC, or determine the 268 opportunistic security status of a given connection. Such mechanisms 269 are primarily useful for disabling OPSEC in specific circumstances 270 for reasons of efficiency. However, application awareness of OPSEC 271 is generally unnecessary by design. 273 6. Security Considerations 275 The security goal of the OPSEC option is to opportunistically 276 establish the greatest degree of end to end security possible on a 277 per connection basis, operating without the necessity for 278 configuration or key management. If secure communications are 279 required by an application, then the mandatory use of a security 280 protocol is strongly recommended. OSPEC MUST NOT be relied upon to 281 provide security in such cases. Rather, the intent of OPSEC is to 282 usefully improve the security of otherwise unsecured traffic, on a 283 scale that makes mass subversion of the mechanism uneconomical. The 284 intended outcome is to enhance the average privacy of security naive 285 applications and reduce the inadvertent exposure of sensitive data. 287 The threats addressed by a successfully negotiated OPSEC-enable 288 connection are: 290 Eavesdropping: Passive, on-path attackers may inspect all packets. 291 Application data is secured to the limits of the negotiated 292 security protocol and the cipher suites it employs. 293 Implementations SHOULD prefer protocols and cipher suites with 294 strong privacy protection. 296 Modification/injection: Active attackers may modify or inject 297 packets (including replays). Application data is secured to the 298 limits of the negotiated security protocol and the cipher suites 299 it employs. Implementations SHOULD prefer protocols and cipher 300 suites with strong integrity and replay protection. 302 Man-in-the-middle: Active, on-path attackers may interpose 303 themselves in the key exchange protocol. In the special case of 304 authentication key material being available to the negotiated 305 security protocol, application data is secured to the limits of 306 that protocol. In the general case of anonymous key exchange 307 (such as Diffie-Hellman), security is no better than plain text. 308 As a matter of good practice, peers SHOULD prefer non-anonymous 309 key exchanges when supported by the negotiated security protocol 310 and available key material. 312 Active on-path attacks are, in general, not addressed by the OPSEC 313 threat model. As well as the man-in-the-middle threat noted above, 314 such attackers can modify TCP segments prior to connection 315 establishment to weaken or disable OPSEC negotiation. Conversely, 316 OPSEC provides application payloads with good security benefits 317 against passive attacks and active off-path attacks. 319 Some security protocols negotiated by OPSEC may support the reuse of 320 security associations. For instance, TLS provides a session 321 resumption mechanism. The reuse of session key material for distinct 322 TCP connections is risky since the connections may not share the same 323 security context. If one of the connections is controlled by an 324 attacker, this creates a known plaintext scenario even if the key is 325 not exposed at the user level. Consequently, implementations SHOULD 326 NOT reuse session key material for distinct TCP connections. 328 7. Acknowledgments 330 The authors wish to thank David Jacobson, Pete Resnick and Paul 331 Hoffman for their contributions to this memo. 333 8. References 335 8.1. Normative References 337 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 338 RFC 793, September 1981. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 344 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 346 8.2. Informative References 348 [I-D.ietf-btns-connection-latching] 349 Williams, N., "IPsec Channels: Connection Latching", 350 draft-ietf-btns-connection-latching-10 (work in progress), 351 April 2009. 353 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 354 August 1980. 356 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 357 Internet Protocol", RFC 2401, November 1998. 359 [RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over 360 TLS", RFC 2487, January 1999. 362 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 363 Encryption using the Internet Key Exchange (IKE)", 364 RFC 4322, December 2005. 366 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 367 Security", RFC 4347, April 2006. 369 Authors' Addresses 371 Michael Paddon 372 Qualcomm Japan Inc. 373 Shin Aoyama Bldg West, 18th Floor 374 1-1-1 Minami Aoyama 375 Minato-ku, Tokyo-to 107-0062 376 Japan 378 Phone: +81-3-5412-8436 379 Email: mwp@qualcomm.com 381 Greg Rose 382 Qualcomm Inc. 383 5775 Morehouse Drive 384 San Diego, California 92121 385 U.S.A. 387 Phone: +1-858-651-5733 388 Email: ggr@qualcomm.com