idnits 2.17.1 draft-weis-tcp-auth-auto-ks-02.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. 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 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 IETF Trust 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 23, 2007) is 6265 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GMAC' -- 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: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Standards Track D. McGrew 5 Expires: August 27, 2007 A. Ramaiah 6 Cisco Systems 7 February 23, 2007 9 Automated key selection extension for the TCP Enhanced Authentication 10 Option 11 draft-weis-tcp-auth-auto-ks-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 27, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This memo describes an automated key selection extension for the TCP 45 [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key 46 selection extension allows two TCP endpoints to authenticate TCP 47 segments using a Message Authentication Code (MAC) key chosen 48 dynamically by an endpoint, rather than using a pre-configured MAC 49 key. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Automatic Key Selection Process . . . . . . . . . . . . . . . 6 58 2.1. KEK Requirements . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. MAC Key Generation . . . . . . . . . . . . . . . . . . . . 7 60 2.3. Sender Operations . . . . . . . . . . . . . . . . . . . . 7 61 2.4. Receiver Operations . . . . . . . . . . . . . . . . . . . 7 62 2.5. Authentication Data Format . . . . . . . . . . . . . . . . 8 63 2.5.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 9 65 3. MAC Algorithms using Nonces . . . . . . . . . . . . . . . . . 10 66 3.1. Authentication Data Format . . . . . . . . . . . . . . . . 10 67 3.2. MAC Algorithm ID Types . . . . . . . . . . . . . . . . . . 11 69 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.1. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 12 71 4.1.1. Authentication Data Only . . . . . . . . . . . . . . . 12 72 4.1.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 12 73 4.2. Use of the TCP Sequence Number as a MAC Algorithm Nonce . 13 74 4.3. Retention of automatically generated keys . . . . . . . . 14 75 4.4. TCP sequence number wrapping . . . . . . . . . . . . . . . 14 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 85 Appendix A. Rejected Alternatives . . . . . . . . . . . . . . . . 19 86 A.1. Deriving session keys from a master key . . . . . . . . . 19 87 A.2. Deriving session keys using the Diffie-Hellman 88 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 Intellectual Property and Copyright Statements . . . . . . . . . . 22 93 1. Introduction 95 The TCP Enhanced Authentication Option [I-D.bonica-tcp-auth] 96 specifies a means of providing integrity protection to BGP and other 97 TCP-based routing protocols. It does this by applying a Message 98 Authentication Code (MAC) to the TCP pseudo-header, TCP header, and 99 TCP segment data (if any). Several allowed MAC algorithms are 100 defined. 102 MAC algorithms take as input a secret key known to the two TCP 103 endpoints, called a MAC key. The TCP Enhanced Authentication Option 104 describes a means of organizing MAC keys in a "key set" associated 105 with a peer TCP endpoint. These keys are chosen out of band, and 106 manually entered into the configuration of the TCP endpoints. 108 This memo describes a means by which TCP endpoints 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 Enhanced Authentication Option were considered and rejected. 124 These methods and the rejection rationale are described in Appendix A 125 of 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 pass it to 155 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. A KEK is never used directly as a MAC key 167 because using a cryptographic key for multiple purposes (such as a 168 KEK and a MAC key) may cause a cryptographic vulnerability and weaken 169 the key. A KEK typically has a long lifetime. 171 When the automated key selection method is used, MAC keys are 172 generated as needed using a strong random number generator. The KEK 173 is used to encrypt the MAC key, and the resulting ciphertext is then 174 included in the Encrypted Key portion of the TCP Enhanced 175 Authentication Option. This approach allows for a scheduled 176 automatic generation of keys that can be periodically replaced based 177 on the policy of either TCP. Generating and distributing a MAC key 178 requires no operator intervention on either TCP endpoint. 180 2.1. KEK Requirements 182 Before the extension in this memo can be used, both TCP endpoints 183 must have obtained a KEK. The KEK is exchanged using an out-of-band 184 process (e.g., manual configuration or using a separate protocol), 185 which is not discussed in this memo. A TCP endpoint MAY exchange 186 more than one KEK with a particular peer TCP endpoint for the purpose 187 of automatic KEK rollover. However, any such rollover process is 188 outside the scope of this memo. One possible method is described in 189 [I-D.viswanathan-keyrollover]. 191 The use of pair-wise automatically generated MAC Keys is especially 192 powerful, because each side can choose independently when to begin 193 using a new MAC Key for its outbound segments without requiring the 194 peer to coordinate the MAC key rollover event. 196 2.2. MAC Key Generation 198 The TCP Enhanced Authentication Option defines a set of attributes 199 for each MAC key. When this extension is used, the attributes are 200 set as follows: 202 o key identifier i, chosen according to local policy 204 o Authentication algorithm L[i], chosen according to local policy 206 o Shared secret S[i] generated using a strong random number 207 generator 209 o A[i], set according to whether the key is the active key 211 o E[i], set according to whether the key is an eligible key 213 2.3. Sender Operations 215 A TCP Endpoint choosing a new MAC Key uses the following step: 217 o Generates a MAC Key of the appropriate length using a strong 218 random number generator. A random number generator approved for 219 NIST PUB 140-2 [FIPS.140-2.AnnexC] SHOULD be used. 221 o Places the MAC Key into the key set as described above. The Key 222 ID i is set to a Key Id value currently unused in the key set. 223 L[i] is set to a chosen authentication algorithm. 225 o Creates a TCP Enhanced Authentication Option with the K bit set to 226 1, the Alg ID set to A[i], and the Key ID set to i. 228 o Adds an Authentication Data formed as described below. 230 When a TCP end-point sends a new key, it SHOULD leave the previous 231 key in the key set and marked as Eligible until the peer also begins 232 to encrypt using the new key. Doing so allows a continued receipt of 233 TCP segments from the peer, including acknowledgment messages 234 indicating that the segment with the new MAC key was not received. 236 2.4. Receiver Operations 238 A TCP Endpoint receiving a new MAC Key uses the following steps: 240 o Detects that the packet includes an encrypted MAC Key by observing 241 that the K bit is set. 243 o Extracts the new MAC Key by decrypting it with the KEK and 244 verifying that the decrypted key is well formed (i.e., the KEK 245 Algorithm ID is a known algorithm id, and the Reserved bits are 246 set to zero). 248 o Verifies that the MAC Key was used to authenticate the packet. 250 o Places the MAC Key into its key set as described above. A[i] is 251 set to be the authentication algorithm defined in the In-line 252 Encrypted Key Payload. The Key ID i is set to the Key Id value 253 defined in the In-line Encrypted Key Payload. 255 2.5. Authentication Data Format 257 The TCP Enhanced Authentication Option defines an Authentication Data 258 field, which always contains at least a Message Authentication Code. 259 When the automated key selection option is used, the Authentication 260 Data field includes both the MAC and an In-line Encrypted Key 261 Payload, as shown in the following figure. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Message Authentication Code ~ 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | In-line Encrypted Key Payload ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 The Message Authentication Code field contains the output of the MAC 272 algorithm. Its size is deterministic based on MAC algorithm. The 273 In-line Encrypted Key Payload is constructed as follows: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |Res|KEK Alg ID |Res|KEK Key ID | Encrypted Key ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 o Res (2 bits) -- Reserved bits, set to zero. 283 o KEK Alg ID (6 bits) -- This field contains an algorithm identifier 284 to be used with the key encrypting key. 286 o Res (2 bits) -- Reserved bits, set to zero. 288 o KEK Key ID (6 bits) -- This field contains an algorithm type to be 289 used with the key encrypting key. 291 o Encrypted Key (variable). The size of the encrypted key field 292 depends upon the size of the encrypted key (see below). 294 2.5.1. KEK Algorithm ID Types 296 The MAC algorithms described in [I-D.bonica-tcp-auth] and this memo 297 all use a key of 128-bits or smaller. The following algorithm is 298 suitable to be used as a key encrypting key for these key sizes: 300 o AES-128-ECB. The MAC key is encrypted using an AES 128-bit key 301 encrypting key, resulting in a 128-bit encrypted key. Use of ECB 302 mode is acceptable because only one block is being encrypted. 303 This algorithm MUST NOT be used to encrypt a MAC key larger than 304 128 bits. 306 If a MAC algorithm requiring a key of larger than 128 bits is defined 307 for use with this automated key selection extension, then a different 308 key encrypting key algorithm will be required. Two possible methods 309 are defined in [RFC3394] and [RFC3537]. 311 3. MAC Algorithms using Nonces 313 All MAC algorithms take two types of inputs: the data to be 314 authenticated, and the key. Many MAC algorithms (e.g., 315 AES-128-CMAC-96 and HMAC-SHA-1-96) take only these inputs, which 316 results in an Authentication Data field of the size of the resulting 317 MAC. However, another class of MAC algorithms takes an additional 318 input called a "nonce". Algorithms requiring a nonce tend to be 319 better performing MAC algorithms, and thus have value when used with 320 the TCP Enhanced Authentication Option. 322 A nonce permutes the output of a MAC algorithm such that it returns a 323 unique value for each ICV value generated with a particular key and 324 nonce pair. However, a particular key and nonce pair MUST NOT be 325 used to authenticate two different sets of data. Doing so may weaken 326 the MAC such that an attacker is able to generate properly formed 327 MACs, which is a catastrophic cryptographic failure. Note that this 328 restriction results in the requirement that a single MAC key MUST NOT 329 be used to protect more than one TCP session. In order to guarantee 330 that nonces used with a particular MAC key are unique, a 331 monotonically increasing sequence number is included in the nonce. 333 3.1. Authentication Data Format 335 If the MAC algorithm requires a nonce for its operation, the sequence 336 number part of the nonce MUST be included at the beginning of the 337 Authentication data, as follows. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Sequence Number | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Message Authentication Code ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 o Sequence Number (32 bits). A monotonically increasing value used 348 as a base for a nonce for algorithms requiring a unique value for 349 each ICV value generated with a particular key. The first 350 sequence number used with a particular MAC key is typically 1, 351 although it MAY start a higher value. When a sequence number 352 reaches 2**32-1, the key MUST NOT be used to authenticate any 353 further packets. 355 o Message Authentication Code (variable). The size of the MAC 356 varies according to the MAC algorithm definition (see table in a 357 later section). There are no restrictions on the size of the 358 Message Authentication Code field. In all cases, the MAC 359 algorithm definition must produce a result that is a multiple of 8 360 bits. 362 When a MAC algorithm requiring a nonce is used with a TCP Extended 363 Authentication Option where K is 1, the Authentication Data field is 364 as follows, with each field defined as described above: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Sequence Number | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Message Authentication Code ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 ~ In-line Encrypted Key Payload ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 3.2. MAC Algorithm ID Types 378 All Algorithm IDs described in the TCP Enhanced Authentication Option 379 document are suitable for use with this option. Additionally, the 380 following nonce based MAC algorithms are defined. 382 o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the 383 GMAC [GMAC] mode of operation, with the result truncated to 96 384 bits. This algorithm requires a 96-bit unique nonce. The nonce 385 is formed as follows. The leftmost 56 bits are all set to zero. 386 The next eight bits contain a direction byte. The binary value of 387 the direction byte is 00000000 for the TCP endpoint sending the 388 segment containing the encrypted key, and 00000001 for the TCP 389 endpoint receiving the segment containing the encrypted key. The 390 rightmost 32 bits are copied from the Sequence Number field. The 391 AES-128-GMAC-96 algorithm MUST be implemented for an 392 implementation to conform to this specification. 394 o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] 395 with the result truncated to 96 bits. This algorithm also 396 requires a nonce. For the purposes of this document the nonce 397 will be a 40 bit nonce. The nonce is formed as follows. The 398 first eight bits contain a direction byte. The binary value of 399 the direction byte is 00000000 for the TCP endpoint sending the 400 segment containing the encrypted key, and 00000001 for the TCP 401 endpoint receiving the segment containing the encrypted key. The 402 rightmost 32 bits are copied from the Sequence Number field. 404 4. Discussion 406 4.1. MAC Option Size 408 The cumulative number of TCP option bytes is currently limited to 40 409 bytes. The TCP MAC Option can consume a variable number of bytes, 410 depending on a number of factors. The following sections describe 411 several scenarios. 413 The size of the authentication data field varies depending on the 414 output of the MAC algorithm and whether or not the MAC algorithm 415 requires a sequence number field. The following table lists the MAC 416 algorithms identified in this proposal and the resulting size of the 417 authentication data field. 419 +-----------------+---------------------------------+ 420 | MAC Algorithm | Authentication Data Size (bits) | 421 +-----------------+---------------------------------+ 422 | HMAC-SHA-1-96 | 96 | 423 | AES-128-CMAC-96 | 96 | 424 | AES-128-GMAC-96 | 128 | 425 | AES-128-UMAC-96 | 128 | 426 +-----------------+---------------------------------+ 428 4.1.1. Authentication Data Only 430 The TCP Enhanced Authentication Option consumes four bytes for the 431 option header. If K is not set to one, then the total size of the 432 TCP MAC option is only the additional number of bytes needed by the 433 MAC algorithm. All MAC algorithms described in the TCP Enhanced 434 Authentication Option and this memo require 12 bytes. This gives a 435 total of 16 bytes for the TCP MAC option. 437 MAC algorithms requiring a nonce need an additional four bytes to 438 carry a sequence number in the authentication data portion of the 439 option. This results in a total of 20 bytes. However, MAC 440 algorithms requiring a nonce tend to consume fewer software and/or 441 hardware resources than other MAC algorithms. Using a MAC algorithm 442 requiring a nonce trades off an additional four bytes in the segment 443 for a faster cryptographic algorithm. 445 4.1.2. Adding an Encrypted Key 447 If K is set to one, then the encrypted key field is added to the MAC 448 option. This adds the ability to do in-band keying, and simplify key 449 management operations, but with a cost of additional TCP option 450 bytes. When an encrypted key is included, two bytes are always 451 needed to describe the KEK algorithm and KEK Key Identifier used to 452 encrypt the MAC key. The KEK algorithm also determines the number of 453 bytes needed for the encrypted MAC key. The one KEK algorithm 454 defined in this proposal requires 16 bytes, which results in a total 455 of 18 bytes for the encrypted key. 457 Thus, 34 bytes total bytes are required when paired with a MAC 458 algorithm not needing a nonce (although 36 bytes may be used if 459 padding is added). A total of 38 bytes are required when paired with 460 a MAC algorithm needing a nonce (or 40 bytes if padding is added). 461 However, the encrypted key is only required when one of the TCP end- 462 points requires a new key (i.e., at the start of a TCP session, or 463 when the security policy mandates a change later on in the session.) 464 All other segments in the TCP session contain only the Authentication 465 Data portion, which remains a modest size. 467 Additional KEK methods that require fewer bytes passed in the In-line 468 Encrypted Key Payload may be defined at a later time, which would 469 reduce the use of TCP Option bytes. 471 4.2. Use of the TCP Sequence Number as a MAC Algorithm Nonce 473 Using an additional four TCP option bytes for a sequence number 474 dedicated to the MAC option is required in order to satisfy the 475 cryptographic requirement of unique nonces. No other value in a TCP 476 packet is guaranteed to be unique. At first glance, the TCP Sequence 477 Number would appear to be suitable. However, the TCP Sequence Number 478 can wrap, after which it increments back through the same sequence 479 number space. 481 A security system should not depend on an external value when it can 482 be manipulated such that the security constraint of the system is 483 violated. This sort of dependency greatly increases the size of the 484 security boundary (that is, the logical boundary containing all of 485 the security functionality), which makes the validation of the 486 correctness of the security system much more difficult. 488 In this case, the TCP Sequence Number is a value that can be 489 manipulated elsewhere by the TCP module such that it is not actually 490 unique enough for the security constraint. For example, some TCP 491 redundancy solutions may resend TCP segments starting with the same 492 TCP sequence number but with a different length. This violates the 493 security requirement that a key and nonce are never used on TCP 494 segments with different data. 496 In summary, the TCP Sequence Number is not suitable for use a MAC 497 algorithm nonce value. 499 4.3. Retention of automatically generated keys 501 Automatically generated keys MUST NOT be set as Active (i.e., used 502 for sending) after their lifetime has expired. The expired keys MAY 503 be retained and marked as Eligible for a period of time, as defined 504 by local policy. This is useful for continued receipt of TCP 505 segments from the peer while the new key is being propagated. For 506 example, the TCP endpoint may need to receive acknowledgment messages 507 indicating that the segment with the new MAC key was not received. 509 Automatically generated keys SHOULD NOT be saved over a reboot. If 510 this advice is ignored, a nonce containing a sequence number greater 511 than the most recently used sequence number MUST be stored with the 512 key. However, a more reliable system would simply generate a new MAC 513 key (and associated nonce, if required) when the system resumes 514 operation. 516 4.4. TCP sequence number wrapping 518 When a TCP sequence number wraps around (i.e., from a high number to 519 a low number), an automatically generated key MUST be expired 520 irrespective of lifetime policy and replaced with a new key. If the 521 old key were not expired, there is a slight possibility that the TCP 522 sequence numbers in the segment will both wrap, and both appear to be 523 current in the TCP window. In this case, the segment may be accepted 524 by the receiver as a new segment. Should the replayed segment 525 contain an encrypted MAC key, and if the KEK has not changed, then 526 the receiver will install the old key and no longer communicate 527 properly with the authentic sender of the TCP segments. 529 5. IANA Considerations 531 The terms "Standards Action" and "Private Use" in this section 532 indicate the polices described for these terms in [RFC2434]. 534 The TCP Enhanced Authentication Code header includes an Algorithm ID 535 field. The following two new Algorithm ID types are defined in this 536 document, which require values be assigned to them: AES-128-GMAC-96, 537 AES-128-UMAC-96. 539 The In-line Encrypted Key Payload contains an Algorithm ID, for which 540 IANA is to create and maintain a registry entitled "Key Encrypting 541 Key Algorithm IDs". This document defines the following initial set 542 of IDs: 544 KEK Algorithm ID Value 545 ---------------- ----- 546 RESERVED 0 547 AES-128-ECB 1 548 Standards Action 2-47 549 Private Use 48-63 551 6. Security Considerations 553 This proposal allows for automatic re-keying for the TCP Enhanced 554 Authentication Option, which provides the following key management 555 benefits: 557 o Automated key lifetime management. A system can rollover keys 558 triggered by any means chosen by the system (e.g., volume 559 lifetime, time lifetime). However, the effective lifetime of a 560 MAC key is more likely to be terminated by the event of a TCP 561 sequence number wrapping, as described in Section 4.4. 563 o Automated key selection. Keys chosen with a good random number 564 generator are generally superior in quality to keys chosen by a 565 human operator. 567 o Keys are chosen for use of a particular TCP session, and cannot be 568 shared between TCP session to different peers. 570 Use of automatic key selection requires a static KEK with a long 571 lifetime. Whereas the KEK needs to be changed periodically, the 572 length of the period should be very long compared to the lifetime of 573 the MAC keys. Because of the long lifetime, human interaction with 574 the key is unnecessary after initial configuration, other than to 575 verify that the key is entered correctly. This KEK SHOULD be 576 protected in non-volatile storage such that it is not subsequently 577 available except to the TCP Enhanced Authentication Option. Doing so 578 also reduces the likelihood that it requires changing (e.g., due to 579 operator staff turnover). 581 MAC algorithms requiring a unique nonce per segment (e.g., AES-128- 582 GMAC-96) SHOULD NOT be used be used with manually configured MAC 583 keys. If the sequence number used as an input to the nonce wraps (or 584 is re-initialized after a system reboot), a single nonce would be 585 used multiple times with a single key. This would cause a 586 catastrophic cryptographic failure, with the amount of damage 587 dependant upon the actual algorithm. 589 7. References 591 7.1. Normative References 593 [FIPS.197.2001] 594 National Institute of Standards and Technology, "Advanced 595 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 596 http://csrc.nist.gov/publications/fips/fips197/ 597 fips-197.pdf>. 599 [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation 600 (GCM)", Submission to NIST modes of operation, May 2005, 601 . 604 [I-D.bonica-tcp-auth] 605 Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. 606 Wheeler, "Authentication for TCP-based Routing and 607 Management Protocols", draft-bonica-tcp-auth-06 (work in 608 progress), February 2007. 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 [I-D.viswanathan-keyrollover] 635 Viswanathan, S., "Authentication-Key Rollover mechanism 636 for Routing and Management Protocols", 637 draft-viswanathan-keyrollover-00 (work in progress), 638 October 2006. 640 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 641 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 643 [RFC3537] Schaad, J. and R. Housley, "Wrapping a Hashed Message 644 Authentication Code (HMAC) key with a Triple-Data 645 Encryption Standard (DES) Key or an Advanced Encryption 646 Standard (AES) Key", RFC 3537, May 2003. 648 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 649 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 650 RFC 3766, April 2004. 652 Appendix A. Rejected Alternatives 654 This draft discusses a means to exchange encrypted keys between TCP 655 endpoints. Several alternatives have been suggested. This section 656 describes those alternatives as well as the rationale by which they 657 were rejected. 659 Any method of generating keys for use by the TCP Enhanced 660 Authentication option must be implementable within a TCP stack 661 without depending on external management protocols. Therefore, the 662 approach must be relatively simple, yet provide good quality 663 encryption keys in a secure manner. The following methods partially 664 meet this criteria but have flaws that result in their rejection. 666 A.1. Deriving session keys from a master key 668 A TCP endpoint could store a long-term master key used to derive 669 session keys. Session keys would be derived heuristically (e.g., 670 using a one-way hash chain) to create a set of ordered keys. This 671 would have the advantage of not needing to pass the session key in a 672 packet between routers. 674 However, in order to support his method a router would be required to 675 store the position in a sequence to identify previously used keys. 676 This is necessary in order to avoid re-using keys. While that 677 requirement may not initially seem onerous, it should be noted that 678 router configurations are generally stored on media that is not 679 intended to be written frequently (e.g., NVRAM, flash memory). 680 Therefore, reliable storage of ephemeral information (such as the 681 position in a sequence) is problematic. A failure to store the most 682 recently used key would result in a catastrophic security failure, 683 and thus this method is rejected. 685 A.2. Deriving session keys using the Diffie-Hellman algorithm 687 It would be possible for a pair of TCP endpoints to use a Diffie- 688 Hellman based protocol to derive session keys. However, since the 689 Diffie-Hellman public numbers would be passed in the first two 690 segments of an exchange, some other security mechanism (e.g., a long- 691 term shared secret) would be necessary to protect the first two 692 segments in the stream. 694 Diffie-Hellman public numbers with adequate security to derive a 128- 695 bit AES key have been estimated at 3200 bits (400 bytes) [RFC3766]. 696 Numbers this large can consume too many bytes to be effectively 697 transferred in a TCP option. Also, computing the Diffie-Hellman 698 algorithm shared secret during the initial handshake of every BGP 699 session is too much overhead for the control plane of the router. It 700 is clear that any in-band method based on passing Diffie-Hellman 701 numbers is not feasible. 703 Authors' Addresses 705 Brian Weis 706 Cisco Systems 707 170 W. Tasman Drive 708 San Jose, California 95134-1706 709 USA 711 Phone: +1-408-526-4796 712 Email: bew@cisco.com 714 Chandrashekhar Appanna 715 Cisco Systems 716 170 W. Tasman Drive 717 San Jose, California 95134-1706 718 USA 720 Phone: +1-408-526-6198 721 Email: achandra@cisco.com 723 David McGrew 724 Cisco Systems 725 170 W. Tasman Drive 726 San Jose, California 95134-1706 727 USA 729 Phone: +1-301-349-5815 730 Email: mcgrew@cisco.com 732 Anantha Ramaiah 733 Cisco Systems 734 170 W. Tasman Drive 735 San Jose, California 95134-1706 736 USA 738 Phone: +1-408-525-6486 739 Email: ananth@cisco.com 741 Full Copyright Statement 743 Copyright (C) The IETF Trust (2007). 745 This document is subject to the rights, licenses and restrictions 746 contained in BCP 78, and except as set forth therein, the authors 747 retain all their rights. 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 752 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 753 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 754 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Intellectual Property 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 Acknowledgment 783 Funding for the RFC Editor function is provided by the IETF 784 Administrative Support Activity (IASA).