idnits 2.17.1 draft-weis-tcp-mac-option-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 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. ** 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.ietf-idr-bgp4]), 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 (December 2, 2005) is 6718 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: 'UMAC' is mentioned on line 237, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'GMAC' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group B. Weis 3 Internet-Draft C. Appanna 4 Expires: June 5, 2006 D. McGrew 5 A. Ramaiah 6 Cisco Systems 7 December 2, 2005 9 TCP Message Authentication Code Option 10 draft-weis-tcp-mac-option-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 June 5, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This memo describes a TCP [RFC0793] extension to enhance security for 44 BGP [I-D.ietf-idr-bgp4] and other TCP-based protocols requiring 45 message authentication. It provides message authentication using a 46 Message Authentication Code (MAC), which is a superior authentication 47 method to the keyed MD5 method previously used. The option also 48 includes provision for automatic generation and distribution of MAC 49 keys. A set of MAC algorithms are specified, as well as guidance 50 when to use each one. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Option Header . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. MAC Algorithm ID Types . . . . . . . . . . . . . . . . 6 63 3.2. Authentication Data . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Authentication Data Size . . . . . . . . . . . . . . . 8 65 3.3. Encrypted Key . . . . . . . . . . . . . . . . . . . . . . 8 66 3.3.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 8 68 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. Key Management Methods . . . . . . . . . . . . . . . . . . 10 70 4.1.1. Locally Managed MAC Keys . . . . . . . . . . . . . . . 10 71 4.1.2. Automatic Generation of Keys . . . . . . . . . . . . . 10 72 4.2. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 11 73 4.2.1. Authentication Data Only . . . . . . . . . . . . . . . 11 74 4.2.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Intellectual Property and Copyright Statements . . . . . . . . . . 17 87 1. Introduction 89 The TCP MD5 Signature Option [RFC2385] specifies an option to provide 90 integrity protection to BGP sessions using the MD5 algorithm and a 91 key in a keyed MAC construction. MD5 does not provide a sufficient 92 level of security, and recently published attacks motivate its 93 replacement. Also, the keyed hash MAC construction used by RFC2385 94 has serious cryptographic weaknesses. An attacker who can find a 95 collision in the underlying hash function can forge a message 96 authentication code using a simple chosen-message attack [MACS]. 98 This proposal describes a set of message authentication codes used to 99 verify integrity of a TCP message. Message authentication codes are 100 a well-accepted method of verifying message integrity. 102 This proposal can use message authentication codes that require 103 unique nonces. This is important because at present the best- 104 performing MACs all have this requirement. The MAC Option can also 105 securely transport new key material between end-points, using a long- 106 lived encryption key. Neither of these options is mandatory to 107 implement, in order to ensure that the MAC Option can easily be 108 implemented in current TCP stacks. 110 1.1. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 1.2. Terminology 118 Key Encrypting Key (KEK). A key used with a cryptographic algorithm 119 to encrypt another key. 121 Message Authentication Code (MAC). A keyed cryptographic checksum on 122 data that uses a secret key to detect modifications of a message 123 (e.g., a TCP segment). An attacker who does not know the secret 124 key is unable to generate the MAC corresponding to a particular 125 message, with very high probability. This is true even when the 126 attacker can perform a chosen-message attack, and cause a 127 legitimate user of the system to authenticate messages of its 128 choice. 130 2. Proposal 132 This proposal describes a means of using a Message Authentication 133 Code (MAC) algorithm to authenticate a TCP segment. Modern MAC 134 algorithms were developed specifically for detecting modification to 135 data (e.g., TCP segments) and are significantly stronger 136 cryptographic methods than the TCP MD5 Signature Option. A number of 137 MAC algorithms may be used, each of which has different strengths and 138 weaknesses (described later in this proposal). The key used to 139 create the MAC is assumed to be known only to the TCP end-points. 141 The MAC authentication data is created by applying a MAC algorithm 142 and a key to the following data: 144 1. the TCP pseudo-header (in the order: source IP address, 145 destination IP address, zero-padded protocol number, and segment 146 length) 148 2. the TCP header, excluding options, and assuming a checksum of 149 zero 151 3. the TCP segment data (if any) 153 Creating a MAC in this manner, an attacker does not only need to 154 create a valid TCP segment (including a valid TCP sequence number), 155 but also must be able to create a valid MAC. Creating a valid MAC 156 requires knowledge of the key used to create the MAC. 158 Unlike RFC 2385, this proposal does not apply the MAC algorithm to 159 the key in the same manner as the MAC algorithm is applied to the TCP 160 pseudo-header, header, and data. The MAC algorithms defined for this 161 option use the key as a direct input to the algorithm, so there is no 162 need to additionally include it in the MAC data. Additionally, 163 including the key in the hashed data may weaken the MAC. This is 164 because using the key as part of the message interferes with the 165 reduction-based methods used to design encryption algorithms and to 166 prove their security [KDM]. 168 This proposal includes an option for passing the MAC key in-band, 169 encrypted under a Key Encrypting Key (KEK) known to both TCP end- 170 points. When an encrypted key is included in a TCP option, it is 171 used to authenticate the current segment, and all subsequent segments 172 in the TCP exchange until a new key is chosen by one or the other of 173 the TCP end-points. Algorithms used with the KEK MUST be strong 174 enough so that an attacker observing the segment cannot determine the 175 key in a reasonable amount of time. One strong KEK algorithm is 176 described below. 178 Several methods of key management are possible with this proposal, 179 and are discussed later in this document. 181 3. Syntax 183 This option has three parts: TCP option header, authentication data, 184 and an optional encrypted key for use verifying integrity of this and 185 future segments within this TCP flow. 187 3.1. Option Header 189 The option header has the following format: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Kind | Length | MAC Alg ID |K| Key ID | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 197 o Kind (8 bits). Value that identifies this option as the 198 Cryptographic Option. 200 o Length (8 bits). Length in octets of the option, including its 201 header. 203 o MAC Alg ID (7 bits). Unique identifier describing the 204 cryptographic algorithm and mode to be used as the MAC algorithm. 206 o K (1 bit). When set to 1, signals that an encrypted key is 207 included in the option. 209 o Key ID (8 bits). A value identifying a particular key to both the 210 sender and receiver. If K is set to one, the Key ID identifies 211 the KEK used to protect encrypted MAC key. A value of 0 indicates 212 that the key in use has no identifier. 214 3.1.1. MAC Algorithm ID Types 216 The following MAC Algorithms are strong MAC algorithms suitable for 217 use with this option. 219 o HMAC-SHA-1-96. HMAC with the SHA-1 hash function, with output 220 truncated to 96 bits [FIPS.198.2002]. This algorithm MAY be 221 implemented for an implementation to conform to this option. 223 o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the 224 GMAC [GMAC] mode of operation, with a 96-bit tag. This algorithm 225 requires a 96-bit unique nonce. The nonce is formed as follows. 226 The leftmost 56 bits are all set to zero. The next eight bits 227 contain a direction byte; its binary value is 00000000 for the 228 sender, and 00000001 for the receiver. The rightmost 32 bits are 229 copied from the Sequence Number field. This algorithm MAY be 230 implemented for an implementation to conform to this option. 232 o AES-128-CMAC-96. AES with a 128-bit key in the CMAC mode of 233 operation [FIPS.800-38B], with output truncated to 96 bits. The 234 AES-128-CMAC-96 algorithm MUST be implemented for an 235 implementation to conform to this option. 237 o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] 238 with a 96-bit output tag. This algorithm also requires a nonce. 239 For the purposes of this document the nonce will be 40 bit nonce. 240 The nonce is formed as follows. The first eight bits contain a 241 direction byte; its binary value is 00000000 for the sender, and 242 00000001 for the receiver. The rightmost 32 bits are copied from 243 the Sequence Number field. This algorithm MAY be implemented for 244 an implementation to conform to this option. 246 3.2. Authentication Data 248 The authentication data provides segment integrity. If the MAC 249 algorithm does not requires a nonce, then the Authentication Data is 250 simply comprised of the MAC bytes, as follows. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 ~ Message Authentication Code ~ 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 o Message Authentication Code (variable). The size of the MAC 259 varies according to the MAC algorithm (see table at the end of 260 this section). 262 If the MAC algorithm requires a nonce for its operation, it MUST be 263 included at the beginning of the Authentication data, as follows. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sequence Number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ Message Authentication Code ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 o Sequence Number (32 bits). A unique monotonically increasing 274 value used as a base for a nonce for algorithms requiring a unique 275 value for each ICV value generated with a particular key. When a 276 sequence number reaches the maximum value, the key MUST NOT be 277 used to authenticate any further packets. 279 o Message Authentication Code (variable). The size of the MAC 280 varies according to the MAC algorithm (see table at the end of 281 this section). 283 3.2.1. Authentication Data Size 285 The size of the authentication data field varies depending on the 286 output of the MAC algorithm and whether or not the MAC algorithm 287 requires a sequence number field. The following table lists the MAC 288 algorithms identified in this proposal and the resulting size of the 289 authentication data field. 291 +-----------------+---------------------------------+ 292 | MAC Algorithm | Authentication Data Size (bits) | 293 +-----------------+---------------------------------+ 294 | HMAC-SHA-1-96 | 96 | 295 | AES-128-GMAC-96 | 128 | 296 | AES-128-CMAC-96 | 96 | 297 | AES-128-UMAC-96 | 128 | 298 +-----------------+---------------------------------+ 300 3.3. Encrypted Key 302 When K is set to 1, the encrypted key is included in the TCP MAC 303 Option following the authentication data. The length of the key can 304 be determined from the algorithm type, and need not be explicitly 305 included in the option. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 ~ KEK Alg ID | Encrypted Key ~ 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 o KEK Alg ID (8 bits) -- This field contains an algorithm type to be 314 used with the key encrypting key. 316 o Encrypted Key (variable). The size of the encrypted key field 317 depends upon the size of the encrypted key (see below). 319 3.3.1. KEK Algorithm ID Types 321 The following algorithms are suitable to be used with a key 322 encrypting key. 324 AES-128-ECB. The MAC key is encrypted using an AES 128-bit key 325 encrypting key, resulting in a 128-bit encrypted key. Use of ECB 326 mode is acceptable because only one block is being encrypted. 327 This algorithm MUST NOT be used to encrypt a MAC key larger than 328 128 bits. (An example of an algorithm that could be used to 329 encrypt a MAC larger than 128 bits is the NIST Key Wrap 330 [KEYWRAP].) 332 4. Discussion 334 4.1. Key Management Methods 336 Experience with key management for RFC 2385 have shown that key 337 management for TCP option keys is subject to varying operational 338 constraints. A single pre-configured MAC key is neither secure, nor 339 operationally sound. This proposal provides for several different 340 methods of managing multiple MAC keys, depending on the operational 341 requirements of the communicating TCP end-points. Two of these 342 methods are described in detail below. 344 4.1.1. Locally Managed MAC Keys 346 In this method, two TCP end-points each configure one or more MAC 347 keys. When keys have a unique Key ID, it is placed in the option 348 header to declare which key was used to calculated the MAC. In order 349 to guarantee that keys are not used longer than their cryptographic 350 lifetime, keys must be periodically changed. Some methods of 351 changing keys is described in [I-D.ramaiah-key-rollover]. 353 When locally managed MAC keys are used, the proposed option only 354 contains the option header and authentication data. K in the option 355 header is never set to 1 when locally managed MAC keys are used. A 356 MAC algorithm requiring a nonce MUST NOT be used in this mode due to 357 the risk of re-using a nonce. 359 4.1.2. Automatic Generation of Keys 361 In this method, the two TCP end-points configure one or more KEKs 362 having a long lifetime. A KEK is used to encrypt a randomly 363 generated MAC key, which is then included in the Encrypted Key 364 portion of the TCP option. This allows for the scheduled automatic 365 generation of keys that can be periodically replaced or based on the 366 policy of either TCP. 368 Each KEK has a Key ID associated with it. When a particular KEK is 369 used to generate a MAC key, the TCP endpoint places its Key ID in the 370 option header to declare which key was used to encrypt the MAC key. 372 When a TCP end-point begins to send with a new key, it SHOULD retain 373 the previous key until the peer also begins to encrypt using the new 374 key. Doing so allows a continued receipt of TCP segments from the 375 peer, including ack messages indicating that the segment with the new 376 MAC key was not received. 378 MAC algorithms requiring a nonce can be used safely, since the keys 379 are randomly chosen. 381 4.2. MAC Option Size 383 The cumulative number of TCP option bytes is currently limited to 40 384 bytes. The TCP MAC Option can consume more or fewer bytes, depending 385 on a number of factors. The following sections describe several 386 scenarios. 388 4.2.1. Authentication Data Only 390 The option consumes four bytes for the option header. If K is not 391 set to one, then the total size of the TCP MAC option is only the 392 additional number of bytes needed by the MAC algorithm. All MAC 393 algorithms described in this proposal not requiring a nonce require 394 12 bytes. This gives a total of 16 bytes for the TCP MAC option, 395 which is four bytes less than used by RFC 2385. 397 MAC algorithms requiring a nonce require an additional four bytes to 398 carry a sequence number in the authentication data portion of the 399 option. This results in a total of 20 bytes. However, MAC 400 algorithms requiring a nonce tend to consume fewer software and/or 401 hardware resources than other MAC algorithms. Using a MAC algorithm 402 requiring a nonce trades off of an additional four bytes in the 403 segment for a faster cryptographic algorithm. 405 4.2.2. Adding an Encrypted Key 407 If K is set to one, then the encrypted key field is added to the MAC 408 option. This adds the ability to do in-band keying, and simplify key 409 management operations, but with a cost of additional TCP option 410 bytes. When an encrypted key is included, one byte is always needed 411 to describe the KEK algorithm used to encrypt the MAC key. The KEK 412 algorithm also determines the number of bytes needed for the 413 encrypted MAC key. The one KEK algorithm defined in this proposal 414 requires 16 bytes, which results in a total of 17 bytes for the 415 encrypted key. 417 Thus, 33 bytes total bytes are required when paired with a MAC 418 algorithm not needing a nonce (although 36 bytes may be used if 419 padding is added). A total of 37 bytes are required when paired with 420 a MAC algorithm needing a nonce (or 40 bytes if padding is added). 421 However, the encrypted key is only required when one of the TCP end- 422 points requires a new key (i.e., at the start of a TCP session, or 423 when the security policy mandates a change later on in the session.) 424 All other segments in the TCP session contain only the Authentication 425 Data portion, which remains a modest size. 427 5. IANA Considerations 429 The terms "Standards Action" and "Private Use" in this section 430 indicate the polices described for these terms in [RFC2434]. 432 A new TCP Option Kind value must be defined in the IANA TCP 433 Parameters registry. 435 The option header contains an 8-bit message type, for which IANA is 436 to create and maintain a registry entitled "MAC Algorithm IDs". This 437 document defines the following message authentication code types: 439 MAC Algorithm ID Value 440 ---------------- ----- 441 RESERVED 0 442 HMAC-SHA-1-96 1 443 AES-128-GMAC-96 2 444 AES-128-CMAC-96 3 445 AES-128-UMAC-96 4 446 Standards Action 5-64 447 Private Use 65-127 449 The option header contains an 8-bit message type, for which IANA is 450 to create and maintain a registry entitled "Key Encrypting Key 451 Algorithm IDs". This document defines the following KEK types: 453 KEK Algorithm ID Value 454 ---------------- ----- 455 RESERVED 0 456 AES-128-ECB 1 457 Standards Action 2-128 458 Private Use 129-254 460 Note to RFC Editor: this section may be removed on publication as an 461 RFC. 463 6. Security Considerations 465 This proposal describes a strong authentication method for 466 authenticating TCP segments. It defines the use of cryptographic MAC 467 algorithms, which are considered state-of-the-art. As such, their 468 expected lifetime of usefulness extends for several years. But 469 cryptographic algorithms have an effective lifetime, depending on 470 advancing processor speed and cryptographic research. This proposal 471 provides for the future addition of new MAC algorithms as they are 472 needed. 474 MAC algorithms requiring a unique nonce per segments (e.g., AES-128- 475 GMAC-96) MUST NOT be used be used with manually configured keys. If 476 the sequence number used as an input to the nonce wraps (or is re- 477 initializing after a system reboot), a single nonce would be used 478 multiple times with a single key. This would cause a catastrophic 479 cryptographic failure, with the amount of damage dependant upon the 480 actual algorithm. 482 Management of RFC 2385 keys has been a significant operational 483 problem, both in terms of key synchronization and key selection. 484 Current guidance [RFC3562] warns against sharing RFC 2385 keys 485 between systems, and recommends changing keys according to a 486 schedule. The same general operational issues are relevant for the 487 management of MAC keys. This proposal allows for in-band automatic 488 re-keying, which provides the following key management benefits: 490 o Automated key lifetime management. A system can rollover keys 491 triggered by any means chosen by the system (e.g., volume 492 lifetime, time lifetime). 494 o Automated key selection. Keys chosen with a good random number 495 generator are superior in quality to manually chosen keys. 497 o Keys are chosen for use of a particular TCP session, and not 498 shared between TCP session to different peers. 500 Use of in-line key management requires a static KEK with a long 501 lifetime. Whereas the KEK needs to be changed periodically, the 502 length of the period should be very long, compared to the lifetime of 503 the MAC keys. 505 7. References 507 7.1. Normative References 509 [FIPS.197.2001] 510 National Institute of Standards and Technology, "Advanced 511 Encryption Standard (AES)", FIPS PUB 197, November 2001, < 512 http://csrc.nist.gov/publications/fips/fips197/ 513 fips-197.pdf>. 515 [FIPS.198.2002] 516 National Institute of Standards and Technology, "The 517 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 518 198, March 2002, . 521 [FIPS.800-38B] 522 National Institute of Standards and Technology, 523 "Recommendation for Block Cipher Modes of Operation: The 524 CMAC Mode for Authentication", FIPS PUB 800-38B, May 2005, 525 . 528 [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation 529 (GCM)", Submission to NIST modes of operation, May 2005, 530 . 533 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 534 RFC 793, September 1981. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 540 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 541 October 1998. 543 7.2. Informative References 545 [I-D.ietf-idr-bgp4] 546 Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", 547 draft-ietf-idr-bgp4-26 (work in progress), October 2004. 549 [I-D.ramaiah-key-rollover] 550 Ramaiah, A., Mynam, S., and C. Appanna, "Key rollover 551 schemes for TCP-based routing applications", 552 draft-ramaiah-key-rollover-00 (work in progress), 553 November 2005. 555 [KDM] Black, J., Rogaway, P., and T. Shrimpton, "Encryption- 556 Scheme Security in the Presence of Key-Dependent 557 Messages", Selected Areas in Cryptography 2002 (SAC 2002), 558 Lecture Notes in Computer Science, vol. 2595, Springer- 559 Verlag, 2003., May 2002, 560 . 562 [KEYWRAP] "Draft NIST AES Key Wrap Specification", November 2001, 563 . 565 [MACS] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash 566 Functions for Message Authentication", Proceedings of 567 Crypto'96 , LNCS 1109, pp. 1-15., June 1996, . 571 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 572 Signature Option", RFC 2385, August 1998. 574 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 575 Signature Option", RFC 3562, July 2003. 577 Authors' Addresses 579 Brian Weis 580 Cisco Systems 581 170 W. Tasman Drive 582 San Jose, California 95134-1706 583 USA 585 Phone: +1-408-526-4796 586 Email: bew@cisco.com 588 Chandrashekhar Appanna 589 Cisco Systems 590 170 W. Tasman Drive 591 San Jose, California 95134-1706 592 USA 594 Phone: +1-408-526-6198 595 Email: achandra@cisco.com 597 David McGrew 598 Cisco Systems 599 170 W. Tasman Drive 600 San Jose, California 95134-1706 601 USA 603 Phone: +1-301-349-5815 604 Email: mcgrew@cisco.com 606 Anantha Ramaiah 607 Cisco Systems 608 170 W. Tasman Drive 609 San Jose, California 95134-1706 610 USA 612 Phone: +1-408-525-6486 613 Email: ananth@cisco.com 615 Intellectual Property Statement 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; nor does it represent that it has 622 made any independent effort to identify any such rights. Information 623 on the procedures with respect to rights in RFC documents can be 624 found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use of 629 such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository at 631 http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at 637 ietf-ipr@ietf.org. 639 Disclaimer of Validity 641 This document and the information contained herein are provided on an 642 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 643 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 644 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 645 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 646 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 647 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 649 Copyright Statement 651 Copyright (C) The Internet Society (2005). This document is subject 652 to the rights, licenses and restrictions contained in BCP 78, and 653 except as set forth therein, the authors retain all their rights. 655 Acknowledgment 657 Funding for the RFC Editor function is currently provided by the 658 Internet Society.