idnits 2.17.1 draft-weis-tcp-auth-auto-ks-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 757. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC0793], [I-D.bonica-tcp-auth]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6617 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) == Missing Reference: 'T' is mentioned on line 218, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GMAC' == Outdated reference: A later version (-06) exists of draft-bonica-tcp-auth-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.bonica-tcp-auth' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'UMAC' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Weis 3 Internet-Draft C. Appanna 4 Expires: August 5, 2006 D. McGrew 5 A. Ramaiah 6 Cisco Systems 7 February 2006 9 Automated key selection extension for the TCP Authentication Option 10 draft-weis-tcp-auth-auto-ks-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 5, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This memo describes an automated key selection extension for the TCP 44 [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key 45 selection extension allows two TCP endpoints to authenticate TCP 46 segments using a Message Authentication Code (MAC) key chosen 47 dynamically by an endpoint, rather than using a pre-configured MAC 48 key. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Automatic Key Selection Process . . . . . . . . . . . . . . . 5 57 2.1. Use of Key Chains . . . . . . . . . . . . . . . . . . . . 5 58 2.1.1. KEK Configuration . . . . . . . . . . . . . . . . . . 5 59 2.1.2. MAC Key Configuration . . . . . . . . . . . . . . . . 6 60 2.2. Sender Operations . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Receiver Operations . . . . . . . . . . . . . . . . . . . 7 62 2.4. Authantication Data Format . . . . . . . . . . . . . . . . 7 63 2.4.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 8 65 3. MAC Algorithms using Nonces . . . . . . . . . . . . . . . . . 9 66 3.1. Authentication Data Format . . . . . . . . . . . . . . . . 9 67 3.2. MAC Algorithm ID Types . . . . . . . . . . . . . . . . . . 10 69 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.1. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 11 71 4.1.1. Authentication Data Only . . . . . . . . . . . . . . . 11 72 4.1.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 11 73 4.2. Insuitability of the TCP Sequence Number as the 74 Sequence Number . . . . . . . . . . . . . . . . . . . . . 12 75 4.3. Retention of automatically generated keys . . . . . . . . 12 76 4.4. TCP sequence number wrapping . . . . . . . . . . . . . . . 13 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Appendix A. Rejected Alternatives . . . . . . . . . . . . . . . . 18 87 A.1. Deriving session keys from a master key . . . . . . . . . 18 88 A.2. Deriving session keys using the Diffie-Hellman 89 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 92 Intellectual Property and Copyright Statements . . . . . . . . . . 21 94 1. Introduction 96 The TCP Authentication Option [I-D.bonica-tcp-auth] specifies a means 97 of providing integrity protection to BGP and other TCP-based routing 98 protocols. It does this by applying a Message Authentication Code 99 (MAC) to the TCP pseduo-header, TCP header, and TCP segment data (if 100 any). Several allowed MAC algorithms are defined. 102 MAC algorithms take as input a secret key known to the two TCP 103 endpoints, called a MAC key. The TCP Authentication Option describes 104 a means of organizing and storing MAC keys in a key chain. These 105 keys are chosen out of band, and manually entered into the 106 configuration of the TCP endpoints. 108 This memo describes a means by which TCP endponts choose MAC keys 109 using an automated process, and is a more secure and operationally 110 simpler method of key selection. The automatically generated keys 111 are protected during transmission by a long-lived key encryption key 112 (KEK) shared between the TCP endpoints. 114 This memo also specifies additional strong MAC algorithms that use 115 unique nonces for each TCP segment. This is important because at 116 present the best-performing MACs all have this requirement. MAC 117 algorithms using nonces are only safe to use with an automatic key 118 selection process. This is because an automatic key selection 119 process can quickly and securely react to the condition that a non- 120 unique nonce is about to be used. 122 Several alternative methods for automatically providing keys for the 123 TCP Authentication Option were considered and rejected. These 124 methods and the rejection rationale are described in Appendix A of 125 this document. 127 1.1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. Terminology 135 Key Encrypting Key (KEK). A key used with a cryptographic algorithm 136 to encrypt another key. 138 Message Authentication Code (MAC). A keyed cryptographic integrity 139 function computed on data using a secret key to detect 140 modifications of the data (e.g., a TCP segment). An attacker who 141 does not know the secret key is unable to generate the MAC 142 corresponding to a particular message, or to modify the message in 143 an undetectable fashion, with very high probability. This is true 144 even if the attacker can perform a chosen-message attack, and 145 cause a legitimate user of the system to authenticate messages of 146 its choice. 148 Message Authentication Code Key (MAC Key). A key used to 149 authenticate a TCP segment. 151 2. Automatic Key Selection Process 153 This memo specifies a method for a TCP endpoint to automatically 154 generate a TCP Enhanced Authentication Option MAC key and passing it 155 to a peer in-band. The MAC key is passed in the TCP Enhanced 156 Authentication Option encrypted under a Key Encrypting Key (KEK) 157 known to both TCP end-points. When an encrypted key is included in 158 this TCP option, it is used to authenticate the current segment, and 159 all subsequent segments in the TCP exchange until a new key is chosen 160 by either of the TCP end-points. Key encryption algorithms and modes 161 used with the KEK MUST be strong enough so that in-line transmission 162 of the key does not degrade the security offered by the MAC 163 algorithm. One strong KEK algorithm is described below. 165 Two TCP end-points configure one or more KEKs before the in-band key 166 selection method is used. These KEKs can be entered and stored on a 167 key chain, as described in the TCP Enhanced Authentication Option. A 168 KEK is never used directly as a MAC key because using a cryptographic 169 key for multiple purposes (such as a KEK and a MAC key) may cause a 170 cryptographic vulnerability and weaken the key. A KEK typically has 171 a long lifetime. 173 When the automated key selection method is used, MAC keys are 174 generated as needed using a strong random number generator. The KEK 175 is used to encrypt the MAC key, and the resulting ciphertext is then 176 included in the Encrypted Key portion of the TCP Enhanced 177 Authentication Option. This approach allows for a scheduled 178 automatic generation of keys that can be periodically replaced based 179 on the policy of either TCP. Generating and distributing a MAC key 180 requires no operator intervention on either TCP endpoint. 182 2.1. Use of Key Chains 184 Both MAC keys and KEKs are configured in key chains as described in 185 Section 5 of the TCP Enhanced Authentication Option. The following 186 sections describe the requirements for configuring the keys. 188 2.1.1. KEK Configuration 190 The KEK is manually configured in a key chain with the same 191 attributes as described in the TCP Enhanced Authentication Option. 192 This section describes KEKs as if they are stored in a key chain 193 different from MAC keys so as to not complicate or alter the MAC key 194 chain semantics described in the TCP Enhanced Authentication Option. 195 However, this section does not mandate any specific implementation. 196 Note that the presence of multiple KEKs in the same key chain allows 197 for automatic KEK rollover. KEKs can also be configured with a 198 direction (used for inbound and/or outbound segments). This semantic 199 allows each TCP Endpoint to choose an independent outbound KEK, if 200 desired. 202 2.1.2. MAC Key Configuration 204 The automatically generated MAC key is stored in the MAC key chain 205 with the following attributes: 207 o Identifier i set from the TCP Enhanced Authentication Option 209 o Authentication algorithm A[i] set from the TCP Enhanced 210 Authentication Option 212 o Shared secret K[i] set from the automatically generated MAC Key 214 o Inbound or outbound set depending on the setting of V[kek]. 216 o Start time S[i] set from the current time 218 o End time [T] set as the highest possible value 220 o S'[i] set from the current time (unless V[kek] indicates outbound- 221 only, in which S'[i] is set to the highest possible value) 223 o T'[i] set to the highest possible value 225 The use of pair-wise automatically generated MAC Keys is especially 226 powerful, because each side can choose independently when to begin 227 using a new MAC Key for its outbound segments. (See the discussion 228 on V[i] in the TCP Enhanced Authentication Option). 230 2.2. Sender Operations 232 A TCP Endpoint choosing a new MAC Key uses the following step: 234 o Generates a MAC Key of the appropriate length using a strong 235 random number generator. A random number generator approved for 236 NIST PUB 140-2 [FIPS.140-2.AnnexC] SHOULD be used. 238 o Places the MAC Key into its key chain as described above. A[i] is 239 set to a chosen authentication algorithm. The Key ID i is set to 240 a Key Id value currently unused in this key chain. 242 o Creates a TCP Enhanced Authentication Option with The K bit set to 243 1, the Alg ID set to A[i], and the Key ID set to i. 245 o Adds an Authentication Data formed as described below. 247 When a TCP end-point sends a new key, it SHOULD retain the previous 248 key until the peer also begins to encrypt using the new key. Doing 249 so allows a continued receipt of TCP segments from the peer, 250 including ack messages indicating that the segment with the new MAC 251 key was not received. 253 2.3. Receiver Operations 255 A TCP Endpoint receiving a new MAC Key uses the following steps: 257 o Detects that the packet includes an encrypted MAC Key by observing 258 that the K bit is set. 260 o Extracts the new MAC Key by decrypting it with the KEK and 261 verifying that the decrypted key is well formed (i.e., the KEK 262 Algorithm ID is a known algorithm id, and the Reserved bits are 263 set to zero). 265 o Verifies that the MAC Key was used to authenticate the packet. 267 o Places the MAC Key into its key chain as described above. A[i] is 268 set to be the authentication algorithm defined in the In-line 269 Encrypted Key Payload. The Key ID i is set to a Key Id value 270 defined in the In-line Encrypted Key Payload. 272 2.4. Authantication Data Format 274 The TCP Enhanced Authentication Option defines an Authentication Data 275 field, which always contains at least a Message Authentication Code. 276 When the automated key selection option is used, the Authentication 277 Data field includes both the MAC and an In-line Encrypted Key 278 Payload, as shown in the following figure. 280 0 1 2 3 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Message Authentication Code ~ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | In-line Encrypted Key Payload ~ 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 The Message Authentication Code field contains the output of the MAC 289 algorithm. Its size is deterministic based on MAC algorithm. The 290 In-line Encrypted Key Payload is constructed as follows: 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Res|KEK Alg ID |Res|KEK Key ID | Encrypted Key ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 o Res (2 bits) -- Reserved bits, set to zero. 300 o KEK Alg ID (6 bits) -- This field contains an algorithm identifier 301 to be used with the key encrypting key. 303 o Res (2 bits) -- Reserved bits, set to zero. 305 o KEK Key ID (6 bits) -- This field contains an algorithm type to be 306 used with the key encrypting key. 308 o Encrypted Key (variable). The size of the encrypted key field 309 depends upon the size of the encrypted key (see below). 311 2.4.1. KEK Algorithm ID Types 313 The MAC algorithms described in [I-D.bonica-tcp-auth] and this memo 314 all use a key of 128-bits or smaller. The following algorithm is 315 suitable to be used as a key encrypting key for these key sizes: 317 AES-128-ECB. The MAC key is encrypted using an AES 128-bit key 318 encrypting key, resulting in a 128-bit encrypted key. Use of ECB 319 mode is acceptable because only one block is being encrypted. 320 This algorithm MUST NOT be used to encrypt a MAC key larger than 321 128 bits. 323 If a MAC algorithm requiring a key of larger than 128 bits is defined 324 for use with this automated key selection extension, then a different 325 key encrypting key algorithm will be required. Two possible methods 326 are defined in [RFC3394] and [RFC3537]. 328 3. MAC Algorithms using Nonces 330 All MAC algorithms take two types of inputs: the data to be 331 authenticated, and the key. Many MAC algorithms (e.g., 332 AES-128-CMAC-96 and HMAC-SHA-1-96) take only these inputs, which 333 results in an Authentication Data field of the size of the resulting 334 MAC. However, another class of MAC algorithms takes an additional 335 input called a "nonce". Algorithms requiring a nonce tend to be 336 better performing MAC algorithms, and thus have value when used with 337 the TCP Enhanced Authentication Option. 339 A nonce permutes the output of a MAC algorithm such that it returns a 340 unique value for each ICV value generated with a particular key and 341 nonce pair. However, a particular key and nonce pair MUST NOT be 342 used to authenticate two different sets of data. Doing so may weaken 343 the MAC such that an attacker is able to generate properly formed 344 MACs, which is a catastrophic cryptographic failure. Note that this 345 restriction results in the requirement that a single MAC key MUST NOT 346 be used to protect more than one TCP session. In order to guarantee 347 that nonces used with a particular MAC key are unique, a 348 monotonically increasing sequence number is included in the nonce. 350 3.1. Authentication Data Format 352 If the MAC algorithm requires a nonce for its operation, the sequence 353 number part of the nonce MUST be included at the beginning of the 354 Authentication data, as follows. 356 0 1 2 3 357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Sequence Number | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Message Authentication Code ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 o Sequence Number (32 bits). A monotonically increasing value used 365 as a base for a nonce for algorithms requiring a unique value for 366 each ICV value generated with a particular key. The first 367 sequence number used with a particular MAC key is typically 1, 368 although it MAY start a higher value. When a sequence number 369 reaches 2**32-1, the key MUST NOT be used to authenticate any 370 further packets. 372 o Message Authentication Code (variable). The size of the MAC 373 varies according to the MAC algorithm definition (see table in a 374 later section). There are no restrictions on the size of the 375 Message Authentication Code field. In all cases, the MAC 376 algorithm definition must produce a result that is a multiple of 8 377 bits. 379 When a MAC algorithm requiring a nonce is used with a TCP Extended 380 Authentication Option where K is 1, the Authentication Data field is 381 as follows, with each field defined as described above: 383 0 1 2 3 384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sequence Number | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Message Authentication Code ~ 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 ~ In-line Encrypted Key Payload ~ 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 3.2. MAC Algorithm ID Types 395 All Algorithm IDs described in the TCP Authentication Option document 396 are suitable for use with this option. Additionally, the following 397 nonce based MAC algorithms are defined. 399 o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the 400 GMAC [GMAC] mode of operation, with the result truncated to 96 401 bits. This algorithm requires a 96-bit unique nonce. The nonce 402 is formed as follows. The leftmost 56 bits are all set to zero. 403 The next eight bits contain a direction byte. The binary value of 404 the direction byte is 00000000 for the TCP endpoint sending the 405 segment containing the encrypted key, and 00000001 for the TCP 406 endpoint receiving the segment containing the encrypted key. The 407 rightmost 32 bits are copied from the Sequence Number field. The 408 AES-128-GMAC-96 algorithm MUST be implemented for an 409 implementation to conform to this specification. 411 o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] 412 with the result truncated to 96 bits. This algorithm also 413 requires a nonce. For the purposes of this document the nonce 414 will be a 40 bit nonce. The nonce is formed as follows. The 415 first eight bits contain a direction byte. The binary value of 416 the direction byte is 00000000 for the TCP endpoint sending the 417 segment containing the encrypted key, and 00000001 for the TCP 418 endpoint receiving the segment containing the encrypted key. The 419 rightmost 32 bits are copied from the Sequence Number field. 421 4. Discussion 423 4.1. MAC Option Size 425 The cumulative number of TCP option bytes is currently limited to 40 426 bytes. The TCP MAC Option can consume a variable number of bytes, 427 depending on a number of factors. The following sections describe 428 several scenarios. 430 The size of the authentication data field varies depending on the 431 output of the MAC algorithm and whether or not the MAC algorithm 432 requires a sequence number field. The following table lists the MAC 433 algorithms identified in this proposal and the resulting size of the 434 authentication data field. 436 +-----------------+---------------------------------+ 437 | MAC Algorithm | Authentication Data Size (bits) | 438 +-----------------+---------------------------------+ 439 | HMAC-SHA-1-96 | 96 | 440 | AES-128-CMAC-96 | 96 | 441 | AES-128-GMAC-96 | 128 | 442 | AES-128-UMAC-96 | 128 | 443 +-----------------+---------------------------------+ 445 4.1.1. Authentication Data Only 447 The TCP Enhanced Authentication Option consumes four bytes for the 448 option header. If K is not set to one, then the total size of the 449 TCP MAC option is only the additional number of bytes needed by the 450 MAC algorithm. All MAC algorithms described in the TCP Enhanced 451 Authentication Option and this memo require 12 bytes. This gives a 452 total of 16 bytes for the TCP MAC option. 454 MAC algorithms requiring a nonce need an additional four bytes to 455 carry a sequence number in the authentication data portion of the 456 option. This results in a total of 20 bytes. However, MAC 457 algorithms requiring a nonce tend to consume fewer software and/or 458 hardware resources than other MAC algorithms. Using a MAC algorithm 459 requiring a nonce trades off an additional four bytes in the segment 460 for a faster cryptographic algorithm. 462 4.1.2. Adding an Encrypted Key 464 If K is set to one, then the encrypted key field is added to the MAC 465 option. This adds the ability to do in-band keying, and simplify key 466 management operations, but with a cost of additional TCP option 467 bytes. When an encrypted key is included, two bytes are always 468 needed to describe the KEK algorithm and KEK Key Identifier used to 469 encrypt the MAC key. The KEK algorithm also determines the number of 470 bytes needed for the encrypted MAC key. The one KEK algorithm 471 defined in this proposal requires 16 bytes, which results in a total 472 of 18 bytes for the encrypted key. 474 Thus, 34 bytes total bytes are required when paired with a MAC 475 algorithm not needing a nonce (although 36 bytes may be used if 476 padding is added). A total of 38 bytes are required when paired with 477 a MAC algorithm needing a nonce (or 40 bytes if padding is added). 478 However, the encrypted key is only required when one of the TCP end- 479 points requires a new key (i.e., at the start of a TCP session, or 480 when the security policy mandates a change later on in the session.) 481 All other segments in the TCP session contain only the Authentication 482 Data portion, which remains a modest size. 484 Additional KEK methods that require fewer bytes passed in the In-line 485 Encrypted Key Payload may be defined at a later time, which would 486 reduce the use of TCP Option bytes. 488 4.2. Insuitability of the TCP Sequence Number as the Sequence Number 490 Using an additional four TCP option bytes for a sequence number 491 dedicated to the MAC option is required in order to satisfy the 492 cryptographic requirement of unique nonces. No other value in a TCP 493 packet is guaranteed to be unique. At first glance, the TCP Sequence 494 Number would appear to be suitable. However, the TCP Sequence Number 495 can wrap, after which it increments back through the same sequence 496 number space. 498 A security system should not depend on an external value when it can 499 be manipulated such that the security constraint of the system is 500 violated. This sort of dependency greatly increases the size of the 501 security boundary (that is, the logical boundary containing all of 502 the security functionality), which makes the validation of the 503 correctness of the security system much more difficult. 505 In this case, the TCP Sequence Number is a value that can be 506 manipulated elsewhere by the TCP module such that it is not actually 507 unique enough for the security constraint. For example, some TCP 508 redundancy solutions may resend TCP segments starting with the same 509 TCP sequence number but with a different length. This violates the 510 security requirement that a key and nonce are never used on TCP 511 segments with different data. 513 4.3. Retention of automatically generated keys 515 Automatically generated keys MUST NOT be retained after their 516 lifetime has expired. 518 Automatically generated keys SHOULD NOT be saved over a reboot. If 519 this advice is ignored, a nonce containing a sequence number greater 520 than the most recently used sequence number MUST be stored with the 521 key. However, a more reliable system would simply generate a new MAC 522 key (and associated nonce, if required) when the system resumes 523 operation. 525 4.4. TCP sequence number wrapping 527 When a TCP sequence number wraps around (i.e., from a high number to 528 a low number), an automatically generated key MUST be expired 529 irrespective of the time based policy in the key chain and replaced 530 with a new key. If the old key were not expired, there is a slight 531 possibility that the TCP sequence numbers in the segment will both 532 wrap, and both appear to be current in the TCP window. In this case, 533 the segment may be accepted by the receiver as a new segment. Should 534 the replayed segment contain an encrypted MAC key, and if the KEK has 535 not changed, then the receiver will install the old key and no longer 536 communicate properly with the authentic sender of the TCP segments. 538 5. IANA Considerations 540 The terms "Standards Action" and "Private Use" in this section 541 indicate the polices described for these terms in [RFC2434]. 543 The TCP Authentication Code header includes an Algorithm ID field. 544 The following two new Algorithm ID types are defined in this 545 document, which require values be assigned to them: AES-128-GMAC-96, 546 AES-128-UMAC-96. 548 The In-line Encrypted Key Payload contains an Algorithm ID, for which 549 IANA is to create and maintain a registry entitled "Key Encrypting 550 Key Algorithm IDs". This document defines the following initial set 551 of IDs: 553 KEK Algorithm ID Value 554 ---------------- ----- 555 RESERVED 0 556 AES-128-ECB 1 557 Standards Action 2-47 558 Private Use 48-63 560 6. Security Considerations 562 This proposal allows for automatic re-keying for the TCP Enhanced 563 Authentication Option, which provides the following key management 564 benefits: 566 o Automated key lifetime management. A system can rollover keys 567 triggered by any means chosen by the system (e.g., volume 568 lifetime, time lifetime). 570 o Automated key selection. Keys chosen with a good random number 571 generator are generally superior in quality to keys chosen by a 572 human operator. 574 o Keys are chosen for use of a particular TCP session, and cannot be 575 shared between TCP session to different peers. 577 Use of automatic key selection requires a static KEK with a long 578 lifetime. Whereas the KEK needs to be changed periodically, the 579 length of the period should be very long, compared to the lifetime of 580 the MAC keys. 582 MAC algorithms requiring a unique nonce per segment (e.g., AES-128- 583 GMAC-96) SHOULD NOT be used be used with manually configured MAC 584 keys. If the sequence number used as an input to the nonce wraps (or 585 is re-initialized after a system reboot), a single nonce would be 586 used multiple times with a single key. This would cause a 587 catastrophic cryptographic failure, with the amount of damage 588 dependant upon the actual algorithm. 590 7. References 592 7.1. Normative References 594 [FIPS.197.2001] 595 National Institute of Standards and Technology, "Advanced 596 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 597 http://csrc.nist.gov/publications/fips/fips197/ 598 fips-197.pdf>. 600 [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation 601 (GCM)", Submission to NIST modes of operation, May 2005, 602 . 605 [I-D.bonica-tcp-auth] 606 Bonica, R., "Authentication for TCP-based Routing and 607 Management Protocols", draft-bonica-tcp-auth-04 (work in 608 progress), January 2006. 610 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 611 RFC 793, September 1981. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 617 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 618 October 1998. 620 [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., and P. 621 Rogaway, "UMAC: Fast and Secure Message Authentication", 622 Advances in Cryptography -- CRYPTO '99 , September 1999, 623 . 625 7.2. Informative References 627 [FIPS.140-2.AnnexC] 628 National Institute of Standards and Technology, "Annex C: 629 Approved Random Number Generators for FIPS PUB 140-2, 630 Security Requirements for Cryptographic Modules", FIPS PUB 631 140-2 Annex C, January 2005, . 634 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 635 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 637 [RFC3537] Schaad, J. and R. Housley, "Wrapping a Hashed Message 638 Authentication Code (HMAC) key with a Triple-Data 639 Encryption Standard (DES) Key or an Advanced Encryption 640 Standard (AES) Key", RFC 3537, May 2003. 642 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 643 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 644 RFC 3766, April 2004. 646 Appendix A. Rejected Alternatives 648 This draft discusses a means to exchange encrypted keys between TCP 649 endpoints. Several alternatives have been suggested. This section 650 describes those alternatives as well as the rationale by which they 651 were rejected. 653 Any method of generating keys for use by the TCP Authentication 654 option must be implementable within a TCP stack without depending on 655 external management protocols. Therefore, the approach must be 656 relatively simple, yet provide good quality encryption keys in a 657 secure manner. The following methods partially meet this criteria 658 but have flaws that result in their rejection. 660 A.1. Deriving session keys from a master key 662 A TCP endpoint could store a long-term master key used to derive 663 session keys. Session keys would be derived heuristically (e.g., 664 using a one-way hash chain) to create a set of ordered keys. This 665 would have the advantage of not needing to pass the session key in a 666 packet between routers. 668 However, in order to support his method a router would be required to 669 store the position in the chain of the previously used key. This is 670 necessary in order to avoid re-using keys. While that requirement 671 may not initially seem onerous, it should be noted that router 672 configurations are generally stored on media that is not intended to 673 be written frequently (e.g., NVRAM, flash memory). Therefore, 674 reliable storage of ephemeral information (such as the position in a 675 key chain) is problematic. A failure to store the most recently used 676 key would result in a catastrophic security failure, and thus this 677 method is rejected. 679 A.2. Deriving session keys using the Diffie-Hellman algorithm 681 It would be possible for a pair of TCP endpoints to use a Diffie- 682 Hellman based protocol to derive session keys. However, since the 683 Diffie-Hellman public numbers would be passed in the first two 684 segments of an exchange, some other security mechanism (e.g., a long- 685 term shared secret) would be necessary to protect the first two 686 segments in the stream. 688 Diffie-Hellman public numbers with adequate security to derive a 128- 689 bit AES key have been estimated at 3200 bits (400 bytes) [RFC3766]. 690 Numbers this large can consume too many bytes to be effectively 691 transferred in a TCP option. Also, computing the Diffie-Hellman 692 algorithm shared secret during the initial handshake of every BGP 693 session is too much overhead for the control plane of the router. It 694 is clear that any method based on passing Diffie-Hellman numbers is 695 not feasible. 697 Authors' Addresses 699 Brian Weis 700 Cisco Systems 701 170 W. Tasman Drive 702 San Jose, California 95134-1706 703 USA 705 Phone: +1-408-526-4796 706 Email: bew@cisco.com 708 Chandrashekhar Appanna 709 Cisco Systems 710 170 W. Tasman Drive 711 San Jose, California 95134-1706 712 USA 714 Phone: +1-408-526-6198 715 Email: achandra@cisco.com 717 David McGrew 718 Cisco Systems 719 170 W. Tasman Drive 720 San Jose, California 95134-1706 721 USA 723 Phone: +1-301-349-5815 724 Email: mcgrew@cisco.com 726 Anantha Ramaiah 727 Cisco Systems 728 170 W. Tasman Drive 729 San Jose, California 95134-1706 730 USA 732 Phone: +1-408-525-6486 733 Email: ananth@cisco.com 735 Intellectual Property Statement 737 The IETF takes no position regarding the validity or scope of any 738 Intellectual Property Rights or other rights that might be claimed to 739 pertain to the implementation or use of the technology described in 740 this document or the extent to which any license under such rights 741 might or might not be available; nor does it represent that it has 742 made any independent effort to identify any such rights. Information 743 on the procedures with respect to rights in RFC documents can be 744 found in BCP 78 and BCP 79. 746 Copies of IPR disclosures made to the IETF Secretariat and any 747 assurances of licenses to be made available, or the result of an 748 attempt made to obtain a general license or permission for the use of 749 such proprietary rights by implementers or users of this 750 specification can be obtained from the IETF on-line IPR repository at 751 http://www.ietf.org/ipr. 753 The IETF invites any interested party to bring to its attention any 754 copyrights, patents or patent applications, or other proprietary 755 rights that may cover technology that may be required to implement 756 this standard. Please address the information to the IETF at 757 ietf-ipr@ietf.org. 759 Disclaimer of Validity 761 This document and the information contained herein are provided on an 762 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 763 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 764 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 765 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 766 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 767 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 769 Copyright Statement 771 Copyright (C) The Internet Society (2006). This document is subject 772 to the rights, licenses and restrictions contained in BCP 78, and 773 except as set forth therein, the authors retain all their rights. 775 Acknowledgment 777 Funding for the RFC Editor function is currently provided by the 778 Internet Society.