idnits 2.17.1 draft-weis-tcp-auth-auto-ks-00.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 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 693. ** 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 24, 2006) is 6636 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 208, 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 28, 2006 D. McGrew 5 A. Ramaiah 6 Cisco Systems 7 February 24, 2006 9 Automated key selection extension for the TCP Authentication Option 10 draft-weis-tcp-auth-auto-ks-00 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 28, 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 Intellectual Property and Copyright Statements . . . . . . . . . . 19 89 1. Introduction 91 The TCP Authentication Option [I-D.bonica-tcp-auth] specifies a means 92 of providing integrity protection to BGP and other TCP-based routing 93 protocols. It does this by applying a Message Authentication Code 94 (MAC) to the TCP pseduo-header, TCP header, and TCP segment data (if 95 any). Several allowed MAC algorithms are defined. 97 MAC algorithms take as input a secret key known to the two TCP 98 endpoints, called a MAC key. The TCP Authentication Option describes 99 a means of organizing and storing MAC keys in a key chain. These 100 keys are chosen out of band, and manually entered into the 101 configuration of the TCP endpoints. 103 This memo describes a means by which TCP endponts choose MAC keys 104 using an automated process, and is a more secure and operationally 105 simpler method of key selection. The automatically generated keys 106 are protected during transmission by a long-lived key encryption key 107 (KEK) shared between the TCP endpoints. 109 This memo also specifies additional strong MAC algorithms that use 110 unique nonces for each TCP segment. This is important because at 111 present the best-performing MACs all have this requirement. MAC 112 algorithms using nonces are only safe to use with an automatic key 113 selection process. This is because an automatic key selection 114 process can quickly and securely react to the condition that a non- 115 unique nonce is about to be used. 117 1.1. Requirements notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 1.2. Terminology 125 Key Encrypting Key (KEK). A key used with a cryptographic algorithm 126 to encrypt another key. 128 Message Authentication Code (MAC). A keyed cryptographic integrity 129 function computed on data using a secret key to detect 130 modifications of the data (e.g., a TCP segment). An attacker who 131 does not know the secret key is unable to generate the MAC 132 corresponding to a particular message, or to modify the message in 133 an undetectable fashion, with very high probability. This is true 134 even if the attacker can perform a chosen-message attack, and 135 cause a legitimate user of the system to authenticate messages of 136 its choice. 138 Message Authentication Code Key (MAC Key). A key used to 139 authenticate a TCP segment. 141 2. Automatic Key Selection Process 143 This memo specifies a method for a TCP endpoint to automatically 144 generate a TCP Enhanced Authentication Option MAC key and passing it 145 to a peer in-band. The MAC key is passed in the TCP Enhanced 146 Authentication Option encrypted under a Key Encrypting Key (KEK) 147 known to both TCP end-points. When an encrypted key is included in 148 this TCP option, it is used to authenticate the current segment, and 149 all subsequent segments in the TCP exchange until a new key is chosen 150 by either of the TCP end-points. Key encryption algorithms and modes 151 used with the KEK MUST be strong enough so that inline transmission 152 of the key does not degrade the security offered by the MAC 153 algorithm. One strong KEK algorithm is described below. 155 Two TCP end-points configure one or more KEKs before the in-band key 156 selection method is used. These KEKs can be entered and stored on a 157 key chain, as described in the TCP Enhanced Authentication Option. A 158 KEK is never used directly as a MAC key because using a cryptographic 159 key for multiple purposes (such as a KEK and a MAC key) may cause a 160 cryptographic vulnerability and weaken the key. A KEK typically has 161 a long lifetime. 163 When the automated key selection method is used, MAC keys are 164 generated as needed using a strong random number generator. The KEK 165 is used to encrypt the MAC key, and the resulting ciphertext is then 166 included in the Encrypted Key portion of the TCP Enhanced 167 Authentication Option. This approach allows for a scheduled 168 automatic generation of keys that can be periodically replaced based 169 on the policy of either TCP. Generating and distributing a MAC key 170 requires no operator intervention on either TCP endpoint. 172 2.1. Use of Key Chains 174 Both MAC keys and KEKs are configured in key chains as described in 175 Section 5 of the TCP Enhanced Authentication Option. The following 176 sections describe the requirements for configuring the keys. 178 2.1.1. KEK Configuration 180 The KEK is manually configured in a key chain with the same 181 attributes as described in the TCP Enhanced Authentication Option. 182 This section describes KEKs as if they are stored in a key chain 183 different from MAC keys so as to not complicate or alter the MAC key 184 chain semantics described in the TCP Enhanced Authentication Option. 185 However, this section does not mandate any specific implementation. 186 Note that the presence of multiple KEKs in the same key chain allows 187 for automatic KEK rollover. KEKs can also be configured with a 188 direction (used for inbound and/or outbound segments). This semantic 189 allows each TCP Endpoint to choose an independent outbound KEK, if 190 desired. 192 2.1.2. MAC Key Configuration 194 The automatically generated MAC key is stored in the MAC key chain 195 with the following attributes: 197 o Identifier i set from the TCP Enhanced Authentication Option 199 o Authentication algorithm A[i] set from the TCP Enhanced 200 Authentication Option 202 o Shared secret K[i] set from the automatically generated MAC Key 204 o Inbound or outbound set depending on the setting of V[kek]. 206 o Start time S[i] set from the current time 208 o End time [T] set as the highest possible value 210 o S'[i] set from the current time (unless V[kek] indicates outbound- 211 only, in which S'[i] is set to the highest possible value) 213 o T'[i] set to the highest possible value 215 The use of pair-wise automatically generated MAC Keys is especially 216 powerful, because each side can choose independently when to begin 217 using a new MAC Key for its outbound segments. (See the discussion 218 on V[i] in the TCP Enhanced Authentication Option). 220 2.2. Sender Operations 222 A TCP Endpoint choosing a new MAC Key uses the following step: 224 o Generates a MAC Key of the appropriate length using a strong 225 random number generator. A random number generator approved for 226 NIST PUB 140-2 [FIPS.140-2.AnnexC] SHOULD be used. 228 o Places the MAC Key into its key chain as described above. A[i] is 229 set to a chosen authentication algorithm. The Key ID i is set to 230 a Key Id value currently unused in this key chain. 232 o Creates a TCP Enhanced Authentication Option with The K bit set to 233 1, the Alg ID set to A[i], and the Key ID set to i. 235 o Adds an Authentication Data formed as described below. 237 When a TCP end-point sends a new key, it SHOULD retain the previous 238 key until the peer also begins to encrypt using the new key. Doing 239 so allows a continued receipt of TCP segments from the peer, 240 including ack messages indicating that the segment with the new MAC 241 key was not received. 243 2.3. Receiver Operations 245 A TCP Endpoint receiving a new MAC Key uses the following steps: 247 o Detects that the packet includes an encrypted MAC Key by observing 248 that the K bit is set. 250 o Extracts the new MAC Key by decrypting it with the KEK and 251 verifying that the decrypted key is well formed (i.e., the KEK 252 Algorithm ID is a known algorithm id, and the Reserved bits are 253 set to zero). 255 o Verifies that the MAC Key was used to authenticate the packet. 257 o Places the MAC Key into its key chain as described above. A[i] is 258 set to be the authentication algorithm defined in the In-line 259 Encrypted Key Payload. The Key ID i is set to a Key Id value 260 defined in the In-line Encrypted Key Payload. 262 2.4. Authantication Data Format 264 The TCP Enhanced Authentication Option defines an Authentication Data 265 field, which always contains at least a Message Authentication Code. 266 When the automated key selection option is used, the Authentication 267 Data field includes both the MAC and an In-line Encrypted Key 268 Payload, as shown in the following figure. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Message Authentication Code ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | In-line Encrypted Key Payload ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 The Message Authentication Code field contains the output of the MAC 279 algorithm. Its size is deterministic based on MAC algorithm. The 280 In-line Encrypted Key Payload is constructed as follows: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |Res|KEK Alg ID |Res|KEK Key ID | Encrypted Key ~ 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 o Res (2 bits) -- Reserved bits, set to zero. 290 o KEK Alg ID (6 bits) -- This field contains an algorithm identifier 291 to be used with the key encrypting key. 293 o Res (2 bits) -- Reserved bits, set to zero. 295 o KEK Key ID (6 bits) -- This field contains an algorithm type to be 296 used with the key encrypting key. 298 o Encrypted Key (variable). The size of the encrypted key field 299 depends upon the size of the encrypted key (see below). 301 2.4.1. KEK Algorithm ID Types 303 The MAC algorithms described in [I-D.bonica-tcp-auth] and this memo 304 all use a key of 128-bits or smaller. The following algorithm is 305 suitable to be used as a key encrypting key for these key sizes: 307 AES-128-ECB. The MAC key is encrypted using an AES 128-bit key 308 encrypting key, resulting in a 128-bit encrypted key. Use of ECB 309 mode is acceptable because only one block is being encrypted. 310 This algorithm MUST NOT be used to encrypt a MAC key larger than 311 128 bits. 313 If a MAC algorithm requiring a key of larger than 128 bits is defined 314 for use with this automated key selection extension, then a different 315 key encrypting key algorithm will be required. Two possible methods 316 are defined in [RFC3394] and [RFC3537]. 318 3. MAC Algorithms using Nonces 320 All MAC algorithms take two types of inputs: the data to be 321 authenticated, and the key. Many MAC algorithms (e.g., 322 AES-128-CMAC-96 and HMAC-SHA-1-96) take only these inputs, which 323 results in an Authentication Data field of the size of the resulting 324 MAC. However, another class of MAC algorithms takes an additional 325 input called a "nonce". Algorithms requiring a nonce tend to be 326 better performing MAC algorithms, and thus have value when used with 327 the TCP Enhanced Authentication Option. 329 A nonce permutes the output of a MAC algorithm such that it returns a 330 unique value for each ICV value generated with a particular key and 331 nonce pair. However, a particular key and nonce pair MUST NOT be 332 used to authenticate two different sets of data. Doing so may weaken 333 the MAC such that an attacker is able to generate properly formed 334 MACs, which is a catastrophic cryptographic failure. Note that this 335 restriction results in the requirement that a single MAC key MUST NOT 336 be used to protect more than one TCP session. In order to guarantee 337 that nonces used with a particular MAC key are unique, a 338 monotonically increasing sequence number is included in the nonce. 340 3.1. Authentication Data Format 342 If the MAC algorithm requires a nonce for its operation, the sequence 343 number part of the nonce MUST be included at the beginning of the 344 Authentication data, as follows. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Sequence Number | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Message Authentication Code ~ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 o Sequence Number (32 bits). A monotonically increasing value used 355 as a base for a nonce for algorithms requiring a unique value for 356 each ICV value generated with a particular key. The first 357 sequence number used with a particular MAC key is typically 1, 358 although it MAY start a higher value. When a sequence number 359 reaches 2**32-1, the key MUST NOT be used to authenticate any 360 further packets. 362 o Message Authentication Code (variable). The size of the MAC 363 varies according to the MAC algorithm definition (see table in a 364 later section). There are no restrictions on the size of the 365 Message Authentication Code field. In all cases, the MAC 366 algorithm definition must produce a result that is a multiple of 8 367 bits. 369 When a MAC algorithm requiring a nonce is used with a TCP Extended 370 Authentication Option where K is 1, the Authentication Data field is 371 as follows, with each field defined as described above: 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Sequence Number | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Message Authentication Code ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 ~ In-line Encrypted Key Payload ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 3.2. MAC Algorithm ID Types 385 All Algorithm IDs described in the TCP Authentication Option document 386 are suitable for use with this option. Additionally, the following 387 nonce based MAC algorithms are defined. 389 o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the 390 GMAC [GMAC] mode of operation, with the result truncated to 96 391 bits. This algorithm requires a 96-bit unique nonce. The nonce 392 is formed as follows. The leftmost 56 bits are all set to zero. 393 The next eight bits contain a direction byte. The binary value of 394 the direction byte is 00000000 for the TCP endpoint sending the 395 segment containing the encrypted key, and 00000001 for the TCP 396 endpoint receiving the segment containing the encrypted key. The 397 rightmost 32 bits are copied from the Sequence Number field. The 398 AES-128-GMAC-96 algorithm MUST be implemented for an 399 implementation to conform to this specification. 401 o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] 402 with the result truncated to 96 bits. This algorithm also 403 requires a nonce. For the purposes of this document the nonce 404 will be a 40 bit nonce. The nonce is formed as follows. The 405 first eight bits contain a direction byte. The binary value of 406 the direction byte is 00000000 for the TCP endpoint sending the 407 segment containing the encrypted key, and 00000001 for the TCP 408 endpoint receiving the segment containing the encrypted key. The 409 rightmost 32 bits are copied from the Sequence Number field. 411 4. Discussion 413 4.1. MAC Option Size 415 The cumulative number of TCP option bytes is currently limited to 40 416 bytes. The TCP MAC Option can consume a variable number of bytes, 417 depending on a number of factors. The following sections describe 418 several scenarios. 420 The size of the authentication data field varies depending on the 421 output of the MAC algorithm and whether or not the MAC algorithm 422 requires a sequence number field. The following table lists the MAC 423 algorithms identified in this proposal and the resulting size of the 424 authentication data field. 426 +-----------------+---------------------------------+ 427 | MAC Algorithm | Authentication Data Size (bits) | 428 +-----------------+---------------------------------+ 429 | HMAC-SHA-1-96 | 96 | 430 | AES-128-CMAC-96 | 96 | 431 | AES-128-GMAC-96 | 128 | 432 | AES-128-UMAC-96 | 128 | 433 +-----------------+---------------------------------+ 435 4.1.1. Authentication Data Only 437 The TCP Enhanced Authentication Option consumes four bytes for the 438 option header. If K is not set to one, then the total size of the 439 TCP MAC option is only the additional number of bytes needed by the 440 MAC algorithm. All MAC algorithms described in the TCP Enhanced 441 Authentication Option and this memo require 12 bytes. This gives a 442 total of 16 bytes for the TCP MAC option. 444 MAC algorithms requiring a nonce need an additional four bytes to 445 carry a sequence number in the authentication data portion of the 446 option. This results in a total of 20 bytes. However, MAC 447 algorithms requiring a nonce tend to consume fewer software and/or 448 hardware resources than other MAC algorithms. Using a MAC algorithm 449 requiring a nonce trades off an additional four bytes in the segment 450 for a faster cryptographic algorithm. 452 4.1.2. Adding an Encrypted Key 454 If K is set to one, then the encrypted key field is added to the MAC 455 option. This adds the ability to do in-band keying, and simplify key 456 management operations, but with a cost of additional TCP option 457 bytes. When an encrypted key is included, two bytes are always 458 needed to describe the KEK algorithm and KEK Key Identifier used to 459 encrypt the MAC key. The KEK algorithm also determines the number of 460 bytes needed for the encrypted MAC key. The one KEK algorithm 461 defined in this proposal requires 16 bytes, which results in a total 462 of 18 bytes for the encrypted key. 464 Thus, 34 bytes total bytes are required when paired with a MAC 465 algorithm not needing a nonce (although 36 bytes may be used if 466 padding is added). A total of 38 bytes are required when paired with 467 a MAC algorithm needing a nonce (or 40 bytes if padding is added). 468 However, the encrypted key is only required when one of the TCP end- 469 points requires a new key (i.e., at the start of a TCP session, or 470 when the security policy mandates a change later on in the session.) 471 All other segments in the TCP session contain only the Authentication 472 Data portion, which remains a modest size. 474 Additional KEK methods that require fewer bytes passed in the In-line 475 Encrypted Key Payload may be defined at a later time, which would 476 reduce the use of TCP Option bytes. 478 4.2. Insuitability of the TCP Sequence Number as the Sequence Number 480 Using an additional four TCP option bytes for a sequence number 481 dedicated to the MAC option is required in order to satisfy the 482 cryptographic requirement of unique nonces. No other value in a TCP 483 packet is guaranteed to be unique. At first glance, the TCP Sequence 484 Number would appear to be suitable. However, the TCP Sequence Number 485 can wrap, after which it increments back through the same sequence 486 number space. 488 A security system should not depend on an external value when it can 489 be manipulated such that the security constraint of the system is 490 violated. This sort of dependency greatly increases the size of the 491 security boundary (that is, the logical boundary containing all of 492 the security functionality), which makes the validation of the 493 correctness of the security system much more difficult. 495 In this case, the TCP Sequence Number is a value that can be 496 manipulated elsewhere by the TCP module such that it is not actually 497 unique enough for the security constraint. For example, some TCP 498 redundancy solutions may resend TCP segments starting with the same 499 TCP sequence number but with a different length. This violates the 500 security requirement that a key and nonce are never used on TCP 501 segments with different data. 503 4.3. Retention of automatically generated keys 505 Automatically generated keys MUST NOT be retained after their 506 lifetime has expired. 508 Automatically generated keys SHOULD NOT be saved over a reboot. If 509 this advice is ignored, a nonce containing a sequence number greater 510 than the most recently used sequence number MUST be stored with the 511 key. However, a more reliable system would simply generate a new MAC 512 key (and associated nonce, if required) when the system resumes 513 operation. 515 4.4. TCP sequence number wrapping 517 When a TCP sequence number wraps around (i.e., from a high number to 518 a low number), an automatically generated key MUST be expired 519 irrespective of the time based policy in the key chain and replaced 520 with a new key. If the old key were not expired, there is a slight 521 possibility that the TCP sequence numbers in the segment will both 522 wrap, and both appear to be current in the TCP window. In this case, 523 the segment may be accepted by the receiver as a new segment. Should 524 the replayed segment contain an encrypted MAC key, and if the KEK has 525 not changed, then the receiver will install the old key and no longer 526 communicate properly with the authentic sender of the TCP segments. 528 5. IANA Considerations 530 The terms "Standards Action" and "Private Use" in this section 531 indicate the polices described for these terms in [RFC2434]. 533 The TCP Authentication Code header includes an Algorithm ID field. 534 The following two new Algorithm ID types are defined in this 535 document, which require values be assigned to them: AES-128-GMAC-96, 536 AES-128-UMAC-96. 538 The In-line Encrypted Key Payload contains an Algorithm ID, for which 539 IANA is to create and maintain a registry entitled "Key Encrypting 540 Key Algorithm IDs". This document defines the following initial set 541 of IDs: 543 KEK Algorithm ID Value 544 ---------------- ----- 545 RESERVED 0 546 AES-128-ECB 1 547 Standards Action 2-47 548 Private Use 48-63 550 6. Security Considerations 552 This proposal allows for automatic re-keying for the TCP Enhanced 553 Authentication Option, which provides the following key management 554 benefits: 556 o Automated key lifetime management. A system can rollover keys 557 triggered by any means chosen by the system (e.g., volume 558 lifetime, time lifetime). 560 o Automated key selection. Keys chosen with a good random number 561 generator are generally superior in quality to keys chosen by a 562 human operator. 564 o Keys are chosen for use of a particular TCP session, and cannot be 565 shared between TCP session to different peers. 567 Use of automatic key selection requires a static KEK with a long 568 lifetime. Whereas the KEK needs to be changed periodically, the 569 length of the period should be very long, compared to the lifetime of 570 the MAC keys. 572 MAC algorithms requiring a unique nonce per segment (e.g., AES-128- 573 GMAC-96) SHOULD NOT be used be used with manually configured MAC 574 keys. If the sequence number used as an input to the nonce wraps (or 575 is re-initialized after a system reboot), a single nonce would be 576 used multiple times with a single key. This would cause a 577 catastrophic cryptographic failure, with the amount of damage 578 dependant upon the actual algorithm. 580 7. References 582 7.1. Normative References 584 [FIPS.197.2001] 585 National Institute of Standards and Technology, "Advanced 586 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 587 http://csrc.nist.gov/publications/fips/fips197/ 588 fips-197.pdf>. 590 [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation 591 (GCM)", Submission to NIST modes of operation, May 2005, 592 . 595 [I-D.bonica-tcp-auth] 596 Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. 597 Wheeler, "Authentication for TCP-based Routing and 598 Management Protocols", draft-bonica-tcp-auth-04 (work in 599 progress), February 2006. 601 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 602 RFC 793, September 1981. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 608 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 609 October 1998. 611 [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., and P. 612 Rogaway, "UMAC: Fast and Secure Message Authentication", 613 Advances in Cryptography -- CRYPTO '99 , September 1999, 614 . 616 7.2. Informative References 618 [FIPS.140-2.AnnexC] 619 National Institute of Standards and Technology, "Annex C: 620 Approved Random Number Generators for FIPS PUB 140-2, 621 Security Requirements for Cryptographic Modules", FIPS PUB 622 140-2 Annex C, January 2005, . 625 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 626 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 628 [RFC3537] Schaad, J. and R. Housley, "Wrapping a Hashed Message 629 Authentication Code (HMAC) key with a Triple-Data 630 Encryption Standard (DES) Key or an Advanced Encryption 631 Standard (AES) Key", RFC 3537, May 2003. 633 Authors' Addresses 635 Brian Weis 636 Cisco Systems 637 170 W. Tasman Drive 638 San Jose, California 95134-1706 639 USA 641 Phone: +1-408-526-4796 642 Email: bew@cisco.com 644 Chandrashekhar Appanna 645 Cisco Systems 646 170 W. Tasman Drive 647 San Jose, California 95134-1706 648 USA 650 Phone: +1-408-526-6198 651 Email: achandra@cisco.com 653 David McGrew 654 Cisco Systems 655 170 W. Tasman Drive 656 San Jose, California 95134-1706 657 USA 659 Phone: +1-301-349-5815 660 Email: mcgrew@cisco.com 662 Anantha Ramaiah 663 Cisco Systems 664 170 W. Tasman Drive 665 San Jose, California 95134-1706 666 USA 668 Phone: +1-408-525-6486 669 Email: ananth@cisco.com 671 Intellectual Property Statement 673 The IETF takes no position regarding the validity or scope of any 674 Intellectual Property Rights or other rights that might be claimed to 675 pertain to the implementation or use of the technology described in 676 this document or the extent to which any license under such rights 677 might or might not be available; nor does it represent that it has 678 made any independent effort to identify any such rights. Information 679 on the procedures with respect to rights in RFC documents can be 680 found in BCP 78 and BCP 79. 682 Copies of IPR disclosures made to the IETF Secretariat and any 683 assurances of licenses to be made available, or the result of an 684 attempt made to obtain a general license or permission for the use of 685 such proprietary rights by implementers or users of this 686 specification can be obtained from the IETF on-line IPR repository at 687 http://www.ietf.org/ipr. 689 The IETF invites any interested party to bring to its attention any 690 copyrights, patents or patent applications, or other proprietary 691 rights that may cover technology that may be required to implement 692 this standard. Please address the information to the IETF at 693 ietf-ipr@ietf.org. 695 Disclaimer of Validity 697 This document and the information contained herein are provided on an 698 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 699 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 700 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 701 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 702 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 703 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 705 Copyright Statement 707 Copyright (C) The Internet Society (2006). This document is subject 708 to the rights, licenses and restrictions contained in BCP 78, and 709 except as set forth therein, the authors retain all their rights. 711 Acknowledgment 713 Funding for the RFC Editor function is currently provided by the 714 Internet Society.