idnits 2.17.1 draft-touch-tcp-ao-encrypt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2014) is 3425 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Standards Track November 12, 2014 4 Expires: May 2015 6 A TCP Authentication Option Extension for Payload Encryption 7 draft-touch-tcp-ao-encrypt-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, except to publish it 14 as an RFC and to translate it into languages other than English. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on May 12, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 This document describes an extension to the TCP Authentication 52 Option (TCP-AO) to encrypt the TCP segment payload in addition to 53 providing TCP-AO's authentication of the payload, TCP header, and IP 54 pseudoheader. This extension augments how the packet contents and 55 headers are processed and which keys are derived, and adds a 56 capability for in-band coordination of unauthenticated Diffie- 57 Hellman key exchange at connection establishment. The extension 58 preserves key rollover coordination and protection of long-lived 59 connections. 61 Table of Contents 63 1. Introduction...................................................2 64 2. Conventions used in this document..............................3 65 3. Background.....................................................3 66 4. Authenticated and Unauthenticated Modes........................4 67 5. Extension for Payload Encryption...............................4 68 5.1. Additional Master Key Tuple components....................4 69 5.2. Additional traffic keys...................................5 70 5.3. Per-Connection TCP-AO Parameters..........................5 71 5.4. Traffic Encryption Key Derivation Functions...............6 72 6. TCP-AO-ENC Interaction with TCP................................6 73 6.1. Sending TCP Segments......................................6 74 6.2. Receiving TCP Segments....................................7 75 6.3. Other TCP Impact..........................................7 76 7. Security Considerations........................................7 77 8. Keying Algorithms..............................................8 78 9. IANA Considerations............................................8 79 10. References....................................................8 80 10.1. Normative References.....................................8 81 10.2. Informative References...................................8 82 11. Acknowledgments...............................................9 84 1. Introduction 86 This document describes an extension to the TCP Authentication 87 Option (TCP-AO) [RFC5925] called TCP-AO-ENC to support its use to 88 encrypt TCP segment payload contents in addition to authenticating 89 the segment. TCP-AO-ENC is intended for use where TCP user data 90 privacy is required and where TCP control protocol protection is 91 also needed. 93 TCP-AO-ENC supports two different modes: authenticated encryption 94 and unauthenticated (BTNS-style) encryption [RFC5387]. Authenticated 95 mode (ENC-AUTH) relies on out-of-band coordination of master key 96 tuples in the same way as TCP-AO, and protects all segments of a 97 connection. Unauthenticated (ENC-BTNS) mode supports in-band 98 unsigned Diffie-Hellman key exchange during the initial SYN, and 99 protects connections from all except man-in-the-middle attacks 100 during connection establishment. 102 This document assumes detailed familiarity with TCP-AO [RFC5925]. 103 TCP-AO-ENC extends how TCP-AO generates traffic keys and how those 104 keys are used to process TCP segment headers and payloads, but does 105 not otherwise alter other aspects of the TCP-AO mechanism [RFC5926]. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 112 When used in lower case, these words have their conventional meaning 113 and do not convey the interpretations in RFC-2119. 115 3. Background 117 The premise of TCP-AO-ENC is that it might be useful to allow TCP-AO 118 to encrypt TCP segment payloads, in addition to authenticating the 119 entire segment. 121 This is accomplished by the following additions, as a preview: 123 o An encryption flag to indicate when segment payload encryption is 124 used. 126 o Traffic encryption key, in addition to the TCP-AO traffic 127 (authentication) key. TCP-AO-ENC can be used with only symmetric 128 ciphers that avoiding the need for padding (stream ciphers). 130 o Augment input and output processing to include 131 encryption/decryption. 133 TCP-AO-ENC does not change any other aspects of TCP-AO [RFC5925], 134 and is compatible with TCP-AO-NAT [RFC6978]. TCP-AO-NAT is intended 135 for use only where coordinated between endpoints for connections 136 that match the shared Master Key Tuple (MKT) parameters, as with all 137 other MKT parameters. 139 4. Authenticated and Unauthenticated Modes 141 TCP-AO-ENC includes two modes: authenticated (ENC-AUTH) and 142 unauthenticated (ENC-BTNS). The latter is consistent with the 143 "Better Than Nothing Security" approach to protect communication in 144 the absence of public key infrastructure (PKI) or pre-shared keys 145 [RFC5387]. 147 ENC-AUTH mode operates in the same way as original TCP-AO 148 authentication, by relying on out-of-band Master Key Tuples (MKTs) 149 that are deployed in advance of new connections. All segments of 150 connections covered by ENC-AUTH are encrypted and authenticated 151 using keying material derived from those MKTs. 153 ENC-BTNS mode can be used without an out-of-band key exchange 154 protocol. It exchanges unauthenticated, unsigned Diffie-Hellman 155 nonces during connection establishment in-band, and uses that 156 information to derive keys used to protect the remainder of the 157 connection. ENC-BTNS mode is susceptible to man-in-the-middle 158 attacks in which the adversary both participates in the initial 159 nonce exchange and processes subsequent segments; this protection 160 increases the effort of the attacker and can help avoid low-effort 161 DDOS attacks that disrupt established connections [RFC4953]. 163 Because ENC-BTNS uses in-band nonce exchange only during the initial 164 SYN, TCP-AO key rollover is not used in that mode. The KeyIDs used 165 during the nonce exchange are recorded and used throughout the 166 connection. 168 5. Extension for Payload Encryption 170 The following describe the additions to TCP-AO needed to support 171 TCP-AO-ENC. 173 5.1. Additional Master Key Tuple components 175 TCP-AO-ENC augments the MKT as follows; as with other MKT 176 components, these MUST NOT change during a connection: 178 o TCP encryption mode. This indicates the use and mode (ENC-AUTH 179 or ENC-BTNS) of segment payload encryption, or is clear when 180 encryption is not used (e.g., for conventional TCP-AO). 182 o Encryption Key Derivation Function (E-KDF). Indicates the key 183 derivation function and its parameters, as used to generate 184 traffic encryption keys from master keys in the same way that the 185 TCP-AO KDG generates traffic (authentication) keys. 187 o Encryption algorithm. Indicates the encryption algorithm and its 188 parameters as used for encrypted connections. 190 PTCP-AO-ENC processes TCP packets in the same way as TCP-AO, except 191 that it replaces the authentication input and output processing as 192 follows: 194 5.2. Additional traffic keys 196 TCP-AO-ENC uses the E-KDF to derive four additional keys used for 197 traffic encryption: 199 o Send_SYN_traffic_encryption_key 201 o Receive_SYN_traffic_encryption_key 203 o Send_other_traffic_encryption_key 205 o Receive_other_traffic_encryption_key 207 5.3. Per-Connection TCP-AO Parameters 209 The per-connection TCP-AO parameters are not affected by the use of 210 TCP-AO-ENC-AUTH, except that MKTs indicated by Current_key and 211 Rnext_key would indicate the use of payload encryption. 213 The per-connection TCP-AO parameters for TCP-AO-ENC-BTNS are 214 augmented by the addition of the following Diffie-Hellman nonces: 216 o Send_nonce. The locally-generated Diffie-Hellman nonce. 218 o Receive_nonce. The Diffie-Hellman nonce generated by the remote 219 end of the connection. 221 These nonces are exchanged during the initial SYN exchange in ENC- 222 BTNS mode; for ENC-AUTH mode, similar information is exchanged out- 223 of-band and is used to derive the encryption keys. KeyIDs used with 224 these nonces are recorded during nonce exchange and used for the 225 remainder of the connection. 227 The use of payload encryption as specified in these MKTs SHOULD NOT 228 change during a TCP connection. 230 5.4. Traffic Encryption Key Derivation Functions 232 Traffic encryption keys are derived from the MKTs using the E-KDF, 233 in the same way and used on the same segments as their corresponding 234 authentication keys, e.g.: 236 o Send_SYN_traffic_encryption_key / Send_SYN_traffic_key 238 o Receive_SYN_traffic_encryption_key / Receive_SYN_traffic__key 240 o Send_other_traffic_encryption_key / Send_other_traffic__key 242 o Receive_other_traffic_encryption_key / Receive_other_traffic_key 244 6. TCP-AO-ENC Interaction with TCP 246 TCP-AO-ENC augments TCP segment send and receive processing to 247 include encryption/decryption. Note that the encryption 248 initialization vector MAY depend on TCP header state, but MUST NOT 249 depend on the processing of previous segments because segments may 250 arrive (and need to be decrypted) out of order. 252 6.1. Sending TCP Segments 254 For ENC-BTNS, initial SYN and SYN-ACK are used to establish the 255 Diffie-Hellman nonces as follows: 257 o Initial SYN and SYN-ACK. The initial SYN (SYN and not ACK) and 258 SYN-ACK segments are not encrypted or authenticated. Instead, 259 their HMAC field contains the Diffie-Hellman nonce in network- 260 standard byte order. 262 The size of the Diffie-Hellman nonce determines the strength of the 263 resulting association. For TCP, such nonces are limited to the 264 available option space in the SYN and SYN-ACK segments. This 265 currently limits the nonce to 128 bits (16 bytes). Larger nonces can 266 be supported using extensions to expand the TCP SYN option space 267 [Bo14][Br14][To14]. 269 Because these segments are not authenticated or encrypted, they 270 SHOULD NOT contain user data. In a typical client-server system, 271 user data usually commences in other segments anyway. 273 All other TCP segments are processed as follows: 275 1. The segment payload is encrypted in-place using the traffic 276 encryption key. 278 2. The segment is authenticated using TCP-AO as per [RFC5925]. 280 6.2. Receiving TCP Segments 282 For ENC-BTNS, initial SYN and SYN-ACK are used to establish the 283 Diffie-Hellman nonces as follows: 285 o Initial SYN and SYN-ACK. The unauthenticated Diffie-Hellman nonce 286 is extracted from the HMAC field, and used to construct the 287 encryption and traffic keys for the connection. Because these 288 segments are not encrypted or authenticated, no further 289 processing is required. 291 All other incoming TCP segments are processed as follows: 293 1. TCP-AO authenticates the segment, including discarding it if 294 authentication fails, as per [RFC5925]. 296 2. The segment payload is decrypted in-place using the traffic 297 encryption key. 299 6.3. Other TCP Impact 301 TCP-AO-ENC has no impact on TCP beyond that of TCP-AO, including 302 impact on TCP header size, connectionless resets, and ICMP handling. 304 TCP-AO-ENC is compatible with the use of TCP-AO-NAT if traversal of 305 NAT boxes is desired. 307 7. Security Considerations 309 TCP-AO-ENC augments TCP-AO to provide segment payload privacy. 311 TCP-AO-ENC relies on TCP-AO's authentication to avoid replay attacks 312 and to ensure that the segments originate from the intended source. 314 TCP-AO-ENC supports only stream ciphers because the TCP segment must 315 be encrypted and decrypted in-situ. Support for padding would 316 require additional option space to indicate the original message 317 length, and this complication does not seem necessary. 319 The design of TCP-AO-ENC can support either symmetric or asymmetric 320 keys. However, because TCP-AO derives traffic (authentication) keys 321 from MKTs using KDFs, it was deemed sufficient that TCP-AO-ENC 322 derive traffic encryption keys from MKTs using E-KDFs in a similar 323 manner, and both endpoints would thus derive the same traffic 324 encryption keys just as they derive the same traffic 325 (authentication) keys. Extensions of TCP-AO-ENC to support 326 asymmetric keying are possible if traffic keys are managed using an 327 out-of-band mechanism, but not if they are derived from MKTs. 329 ENC-AUTH has no additional security considerations. ENC-BTNS cannot 330 authenticate or encrypt the segments used for nonce exchange, i.e., 331 the initial SYN and SYN-ACK. As a result, ENC-BTNS is susceptible to 332 man-in-the-middle attacks during connection establishment, but 333 remains useful to ensure that established connections are protected. 335 8. Keying Algorithms 337 TCP-AO-ENC algorithms are specified in a separate document, as was 338 the custom for TCP-AO. 340 NOTES [for that doc]: 342 o E-KDF - also, can a MKT use the same alg for KDF and E-KDF? 344 o Encryption algorithm - possibilities include AES CTR (CTR initial 345 value can be the ESN) or AES CBC and Camellia CBC as per TLS 1.2. 347 9. IANA Considerations 349 There are no IANA considerations for this document. This section can 350 be removed upon publication as an RFC. 352 10. References 354 10.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 360 Option", RFC 5925, Jun. 2010. 362 [RFC5926] Lebovitz, G., E. Rescorla, "Cryptographic Algorithms for 363 the TCP Authentication Option (TCP-AO)", RFC 5926, June 364 2010. 366 10.2. Informative References 368 [Bo14] Borman, D., "TCP Four-Way Handshake," draft-borman- 369 tcp4way-00 (work in progress), Oct. 2014. 371 [Br14] Briscoe, B., "Inner Space for TCP Options," draft-briscoe- 372 tcpm-inner-space-01 (work in progress), Oct. 2014. 374 [RFC4953] J. Touch, "Defending TCP Against Spoofing Attacks," RFC 375 4953, July 2007. 377 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 378 Applicability Statement for Better-Than-Nothing Security 379 (BTNS)", RFC 5387, November 2008. 381 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 382 Traversal", RFC 6978, July 2013. 384 [To14] Touch, J., and T. Faber, "TCP SYN Extended Option Space 385 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 386 ext-opt-01 (work in progress), Sep. 2014. 388 11. Acknowledgments 390 This extension was informed by discussions with Gene Tsudik, and 391 various members of the TCPM and TCPCRYPT mailing lists, including 392 Christian von Roques. 394 This document was prepared using 2-Word-v2.0.template.dot. 396 Author's Address 398 Joe Touch 399 USC/ISI 400 4676 Admiralty Way 401 Marina del Rey, CA 90292 402 USA 404 Phone: +1 (310) 448-9151 405 Email: touch@isi.edu