idnits 2.17.1 draft-bonica-tcp-auth-05.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 763. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (July 2006) is 6492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. '2') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (ref. '3') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '8') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '12') (Obsoleted by RFC 7323) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '14') (Obsoleted by RFC 4346) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Informational B. Weis 5 Expires: January 2, 2007 S. Viswanathan 6 Cisco Systems 7 A. Lange 8 Alcatel 9 O. Wheeler 10 BT 11 July 2006 13 Authentication for TCP-based Routing and Management Protocols 14 draft-bonica-tcp-auth-05 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 2, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This memo describes a TCP extension that enhances security for BGP, 48 LDP and other TCP-based protocols. It is intended for applications 49 where secure administrative access to both the end-points of the TCP 50 connection is normally available. TCP peers can use this extension 51 to authenticate messages passed between one another. 53 The strategy described herein improves upon current practice, which 54 is described in RFC 2385. Using this new strategy, TCP peers can 55 update authentication keys during the lifetime of a TCP connection. 56 TCP peers can also use stronger authentication algorithms to 57 authenticate routing messages. 59 Table of Contents 61 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. TCP Enhanced Authentication Option . . . . . . . . . . . . . . 6 67 7. Key Attributes . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. MAC Calculation . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Authentication Algorithms . . . . . . . . . . . . . . . . . . 9 70 10. Migration Issues . . . . . . . . . . . . . . . . . . . . . . . 10 71 11. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 10 72 12. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 12.1. Connectionless Resets . . . . . . . . . . . . . . . . . . 11 74 12.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.3. TCP Header Size . . . . . . . . . . . . . . . . . . . . . 11 76 12.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 77 12.5. ICMP-based attacks . . . . . . . . . . . . . . . . . . . 12 78 12.6. Relationship With TLS . . . . . . . . . . . . . . . . . . 12 79 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 17.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Intellectual Property and Copyright Statements . . . . . . . . . . 17 89 1. Conventions Used In This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [1]. 95 2. Terminology 97 The following terms are used in this document: 99 key - A data structure used to authenticate TCP segments. One or 100 more keys can be associated with a TCP connection. Each key 101 contains an identifier, a shared secret, an algorithm identifier, 102 an "active flag" and an "eligible flag". 104 key set - A set of keys that is associated with a TCP connection. 105 A single key set can be associated with multiple TCP connections. 106 Each key within a key set contains an identifier that is unique 107 within the key set. 109 active key - Each key set contains exactly one active key. The 110 sending TCP station uses the shared secret from its active key to 111 generate a Message Authentication Code (MAC) for outgoing TCP 112 segments. The "active flag" on a key indicates whether a 113 particular key is active. 115 eligible key - Each key set contains zero or more eligible keys. 116 The receiving TCP station uses the shared secret from a key to 117 authenticate an incoming TCP segment only if that key is eligible. 118 The "eligible flag" on a key indicates whether a particular key is 119 eligible. 121 3. Introduction 123 RFC 2385 [8] proposes a mechanism that authenticates TCP [2] sessions 124 by including a message authentication code (MAC) in each TCP header. 125 Authentication coverage includes the following fields: 127 - the TCP pseudo-header 129 - the TCP header, excluding options, and assuming a checksum of 130 zero 131 - the TCP segment data (if any) 133 To spoof a connection using the scheme described above, an attacker 134 would not only have to guess TCP sequence numbers, but would also 135 have to obtain the key that was used to calculate the MAC. This key 136 never appears in the connection stream. 138 RFC 3562 [9] addresses key management considerations regarding the 139 TCP MD5 Signature Option. Based upon the strength of the MD5 [10] 140 hashing algorithm, RFC 3562 recommends that keys be changed at least 141 every 90 days. 143 Unfortunately, the strategy described in RFC 2385 permits keys to be 144 changed during the lifetime of a TCP connection only so long as the 145 change is synchronized at both ends. This limitation has proven to 146 be a significant deterrent to the effective deployment of the TCP MD5 147 Signature Option. This memo addresses that limitation. 149 Also, the MD5 algorithm does not now provide a sufficient level of 150 security, and recently published attacks motivate its replacement. 151 In addition, the keyed hash MAC construction used by RFC 2385 has 152 serious cryptographic weaknesses. An attacker who can find a 153 collision in the underlying hash function can forge a MAC using a 154 simple chosen-message attack [11]. This memo makes use of MAC 155 algorithms that do not have these weaknesses. It also provides a 156 mechanism to add additional algorithms as the state-of-the-art in 157 cryptography progresses. 159 4. Proposal 161 This memo proposes a TCP Enhanced Authentication Option that is used 162 as follows: 164 Network operators associate a set of keys with each protected TCP 165 connection. Each key contains an identifier that is unique to the 166 key set, a shared secret, an algorithm identifier, an "active flag" 167 and an "eligible flag". 169 Whenever TCP generates a segment, it searches the associated key set 170 for its active key. Each key set MUST have exactly one active key 171 that is identified as such by having its "active flag" set. 173 Having identified the active key, TCP executes the following 174 sequence: 176 - append the TCP Enhanced Authentication Option to the TCP header. 177 (See Section 6 of this document for details regarding the TCP 178 Enhanced Authentication Option.) 180 - update the TCP Enhanced Authentication Option to include the 181 active key's unique identifier 183 - calculate a Message Authentication Code (MAC) using the shared 184 secret from the active key. (See Section 8 of this document for 185 MAC calculation details.) 187 - update the TCP Enhanced Authentication Option to include the MAC 188 that was calculated above 190 - calculate and update the TCP checksum 192 - forward the segment to a TCP peer. 194 The receiving TCP associates the inbound TCP segment with a local key 195 set based upon source IP address, destination IP address, source port 196 and destination port. It then searches the associated key set for a 197 key whose identifier matches that which was specified by the incoming 198 segment option. 200 If TCP finds such a key and if that key's "eligible flag" is set, TCP 201 continues processing. If no matching eligible key is found then TCP 202 MUST declare an authentication failure and discard the segment. 204 TCP verifies that the algorithm used to produce the MAC is correct. 205 The verification is done by comparing the algorithm attribute 206 associated with the key with the algorithm id listed in the segment 207 option. If the algorithm identifiers do not match, then the MAC 208 calculation will fail. TCP MUST declare an authentication error and 209 discard the segment. 211 TCP uses the shared secret from the key to calculate a MAC. TCP will 212 accept the segment if the calculated MAC matches the MAC specified by 213 the inbound segment. Otherwise, TCP MUST declare an authentication 214 failure and discard the segment. 216 TCP MUST also declare an authentication failure and discard a segment 217 if the segment is received from a connection that is associated with 218 a key set and the segment does not include the TCP Enhanced 219 Authentication Option. 221 To help protect against denial of service attacks it is RECOMMENDED 222 that the inbound TCP segment is validated against the normal TCP 223 criteria (e.g. that the segment sequence number is within the current 224 receive window) prior to the MAC being calculated. Inbound TCP 225 segments on connections requiring the Enhanced Authentication Option 226 MUST NOT cause the current TCP state variables for that connection to 227 be updated unless the MAC has been verified as correct. 229 An authentication failure MUST NOT produce any response back to the 230 sender. Routers SHOULD log authentication failures. 232 Unlike other TCP extensions (e.g., the Window Scale option [12]), the 233 absence of the option in the SYN,ACK segment must not cause the 234 sender to disable its sending of authentication data. This 235 negotiation is typically done to prevent some TCP implementations 236 from misbehaving upon receiving options in non-SYN segments. This is 237 not a problem for this option, since the SYN,ACK sent during 238 connection negotiation will not be signed and will thus be ignored. 239 The connection will never be made, and non-SYN segments with options 240 will never be sent. More importantly, the sending of authentication 241 data must be under the complete control of the application, not at 242 the mercy of the remote host not understanding the option. 244 5. Applications 246 The mechanisms described in this memo are intended for use with 247 applications that manipulate key set contents. An application might 248 toggle the active and eligible flags based upons system time, 249 connection duration or any other external event. 251 6. TCP Enhanced Authentication Option 253 Figure 1 depicts the TCP Enhanced Authentication Option format. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Kind | Length |T|K| Alg ID |Res| Key ID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Authentication Data | 261 | // | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 1: Option Syntax 266 Kind: 8 bits 268 The Kind field identifies the TCP Enhanced Authentication Option. 269 This value will be assigned by IANA. 271 Length: 8 bits 273 The Length field specifies the length of the TCP Enhanced 274 Authentication Option, in octets. This count includes two octets 275 representing the Kind and Length fields. 277 The valid range for this field is from 4 to 40 octets, inclusive. 278 For all algorithms specified in this memo the value will be 16 279 octets. 281 T-Bit: 1 bit 283 The T-bit specifies whether TCP Options were omitted from the TCP 284 header for the purpose of MAC calculation. A value of 1 indicates 285 that all TCP options other than the Extended Authentication Option 286 were omitted. A value of 0 indicates that TCP options were included. 287 The default value is 0. (See Section 8 of this document for MAC 288 calculation details.) 290 K-Bit: 1 bit 292 This bit is reserved for future enhancement. Its value MUST be equal 293 to zero. See Section 11 for details. 295 Alg ID: 6 bits 297 The Alg ID field identifies the MAC algorithm. See Section 9 for 298 permissible values. 300 Res: 2 bits 302 These bits are reserved. They MUST be set to zero. 304 Key ID: 6 bits 306 The Key ID field identifies the key that was used to generate the 307 message digest. 309 Authentication Data: Variable length 311 The Authentication Data field contains data that is used to 312 authenticate the TCP segment. This data includes, but need not be 313 restricted to, a MAC. The length and format of the Authentication 314 Data Field can be derived from the Alg ID. See Section 9 for 315 details. 317 7. Key Attributes 319 A key set is a set of keys, where each key is {L[i], S[i], A[i], 320 E[i]}: 322 i Key identifier, integer (0...63) 323 L[i] Authentication algorithm to use with key[i]. 324 S[i] Shared secret to use with key[i]. 325 A[i] Active flag to use with key[i] 326 E[i] Eligible flag to use with key[i] 328 For the purpose of this document, key[i] is defined as the key whose 329 identifer is equal to i. 331 A list of values for L[i] is provided in Section 9 of this document. 332 The format of S[i] depends upon L[i]. Also see Section 9 for 333 details. 335 L[i] and S[i] MUST be configured symmetrically on TCP peers. That 336 is, if key[i] is configured on two peer systems, L[i] and S[i] must 337 be configured identically on each system. 339 For each key set, exactly one element MUST have A[i] set. Zero or 340 more elements MAY have E[i] set. 342 In general, network operators should avoid reusing shared secrets. 343 The degree to which an operator can reuse keys is defined by local 344 security policy. 346 During the lifetime of a TCP connection, network operators may add 347 and delete keys from the key set. However, the network operator must 348 ensure that the active key is always configured on both TCP 349 endpoints. 351 8. MAC Calculation 353 The sending TCP calculates a MAC by applying the authentication 354 algorithm from the active key to the following items in the order 355 that they are listed: 357 - the TCP pseudo-header 359 - the TCP header, assuming a checksum of zero. (See below for a 360 discussion of TCP Options within the the TCP header.) 361 - the TCP segment data (if any) 363 For IPv4, the pseudo-header is described in RFC 793 [2]. It includes 364 the 32-bit source IP address, the 32-bit destination IP address, the 365 zero-extended protocol number (to form 16 bits), and the 16-bit 366 segment length. Note that this includes use of IPv4 via IPv4-mapped 367 IPv6 addresses, in which case the source and destination IP addresses 368 are from the IPv4 portions of the IPv6 source and destination 369 addresses, respectively. 371 For IPv6, the pseudo-header is described in RFC 2460 [3]. It 372 includes the 128-bit source IPv6 address, the 128-bit destination 373 IPv6 address, the zero-extended next header value (to form 32 bits), 374 and the 32-bit segment length. 376 The header and pseudo-header are in network byte order. 378 By default, for the purpose of MAC calculation, the TCP header 379 includes all TCP options, including the TCP Enhanced Authentication 380 Option with its Authentication Data Field (i.e., MAC) set to zero. 381 However, TCP implementations MAY omit all other TCP options from the 382 MAC calculation; the TCP Enhanced Authentication Option itself must 383 still be included in the calculation, as described above. When 384 implementation do so, they MUST set the T-bit in the TCP Enhanced 385 Authentication Option. 387 The receiving TCP calculates the MAC in a manner identical to the 388 sending TCP. However, it MUST examine the T-bit from the incoming 389 TCP Enhanced Authentication Option to determine whether incoming TCP 390 Options should be included in the MAC calculation. 392 9. Authentication Algorithms 394 The following MAC Algorithms are suitable for use with this option. 396 - AES-128-CMAC-96. AES with a 128-bit key in the CMAC mode of 397 operation [4] [5]. When this algorithm is used, implementations 398 MUST specify a value of 1 (in binary, 000001) in the TCP Enhanced 399 Authentication Option Alg ID field. Also, the Authentication Data 400 field must contain exactly 96 bits representing the MAC, truncated 401 to that length, with the high-order bit first. The 402 AES-128-CMAC-96 algorithm MUST be implemented for an 403 implementation to conform to this specification. 405 - HMAC-SHA-1-96. SHA-1 with a 160-bit key in the HMAC mode of 406 operation [6]. When this algorithm is used, implementations MUST 407 specify a value of 2 (in binary, 000010) in the TCP Enhanced 408 Authentication Option ALG ID field. Also, the Authentication Data 409 field must contain exactly 96 bits representing the MAC, truncated 410 to that length, with the high-order bit first. This algorithm MAY 411 be implemented for an implementation to conform to this 412 specification. 414 The above algorithms are expected to safe to use in this application 415 for many years. New algorithms may be added to this list as 416 necessary, but it is important that they be properly vetted by the 417 cryptographic community. To this end, the above algorithms are 418 described in a list maintained by IANA, and the algorithm identifier 419 associated with the algorithm is placed in the TCP Authentication 420 Option header. Other algorithms may also be defined by an 421 implementation using a Private Use identifier, but the suitability of 422 those algorithms when used with the TCP Extended Authentication 423 option is not assured. 425 Implementations MUST present a management interface through which the 426 user can specify any member of the key space. For example, if the 427 key contains 128 bits, the command line interface might accept this 428 value as a string of exactly 32 hexadecimal digits, with each 429 hexadecimal digit representing 4 bits of the shared secret. 431 Implementations MAY employ authentication algorithms not listed 432 above. 434 10. Migration Issues 436 Either the TCP Enhanced Authentication Option or RFC 2385 may be 437 applied to a TCP segment, but the two options SHOULD NOT be present 438 in the same TCP segment. An implementation MAY support both options 439 for a particular TCP session during migration from RFC 2385, but they 440 MUST use different keys so as not to weaken the security of the TCP 441 Enhanced Authentication Option (see the Security Considerations 442 section for details). A receiver SHOULD accept either option. A 443 sender MAY choose to continue sending RFC 2385 options until it has 444 evidence that the other TCP endpoint shows use of the TCP Enhanced 445 Authentication Option, in which case it migrates to the TCP Enhanced 446 Authentication Option. 448 11. Future Enhancements 450 In the future, the TCP Enhanced Authentication Option will be 451 enhanced to support automated session key distribution. The K-bit is 452 reserved for the purpose of indicating that session key distribution 453 extensions are present. These extensions are beyond the scope of 454 this memo. 456 12. Implications 458 12.1. Connectionless Resets 460 A connectionless reset will be ignored by the receiver of the reset 461 if the originator of that reset does not know the key and therefore 462 cannot generate the proper authentication data for the segment. This 463 means, for example, that connection attempts by a TCP which is 464 generating authentication data to a port with no listener will time 465 out instead of being refused. Similarly, resets generated by a TCP 466 in response to segments sent on a stale connection will also be 467 ignored. Operationally this can be a problem since resets help some 468 protocols recover quickly from peer crashes. 470 12.2. Performance 472 The performance hit in calculating digests may inhibit the use of 473 this option. Performance will vary depending upon processor type, 474 authentication algorithm, packet size and number of MAC calculations 475 per second. 477 12.3. TCP Header Size 479 As with other options that are added to every segment, the size of 480 the TCP Enhanced Authentication Option must be factored into the MSS 481 offered to the other side during connection negotiation. 482 Specifically, the size of the header to subtract from the MTU 483 (whether it is the MTU of the outgoing interface or IP's minimal MTU 484 of 576 octets) is now increased by the size of the TCP Enhanced 485 Authentication Option. 487 The total header size is also an issue. The TCP header specifies 488 where segment data starts with a 4-bit field which gives the total 489 size of the header (including options) in 32-byte words. This means 490 that the total size of the header plus options must be less than or 491 equal to 60 octets. This leaves 40 octets for options. 493 As a concrete example, assume that an implementation defaults to 494 sending window-scaling and timestamp information for connections it 495 initiates. The most loaded segment will be the initial SYN packet to 496 start the connection. With the TCP Enhanced Authentication Option 497 using AES-128-CMAC-96, the SYN packet will contain the following: 499 -- 4 octets MSS option 501 -- 4 octets window scale option (3 octets padded to 4 in many 502 implementations) 504 -- 12 octets for timestamp 506 -- 16 octets for the TCP Enhanced Authentication Option 508 This sums to 36 octets, leaving only four octets for future 509 expansion. 511 12.4. Backwards Compatibility 513 On any particular TCP connection, use of the TCP Enhanced 514 Authentication Option precludes use of the TCP MD5 Signature Option. 515 However, use of the TCP Enhanced Authentication Option on one 516 connection does not preclude the use of the TCP MD5 Signature Option 517 on another connection by the same system. 519 12.5. ICMP-based attacks 521 The mechanism described in this document does not provide significant 522 protection against ICMP-based attacks [13]. 524 12.6. Relationship With TLS 526 The Transport Layer Security protocol (TLS) [14] provides 527 confidentiality and message authentication to TCP connections. 528 However, TLS works above the TCP layer, and does not protect the TCP 529 connection itself. In contrast, the TCP Authentication Option 530 provides protection against attacks on the TCP layer, such as 531 connection reset attacks. 533 13. Contributors 535 The following individuals contributed to this document: 537 Chandrashekhar Appanna (achandra@cisco.com) 539 Andy Heffernan (ahh@juniper.net) 541 Kapil Jain (kapil@juniper.net) 542 David McGrew (mcgrew@cisco.com) 544 Satish Mynam (mynam@cisco.com) 546 Anantha Ramaiah (ananth@cisco.com) 548 14. Acknowledgments 550 Thanks to Steve Bellovin, Ted Faber, Ross Callon, Joe Touch and Ran 551 Atkinson for their comments regarding this draft. 553 15. Security Considerations 555 This proposal describes a strong authentication method for 556 authenticating TCP segments. It defines the use of cryptographic MAC 557 algorithms, which are considered state-of-the-art. As such, their 558 expected lifetime of usefulness extends for several years. But 559 cryptographic algorithms have an effective lifetime, depending on 560 advancing processor speed and cryptographic research. This proposal 561 provides for the future addition of new MAC algorithms as they are 562 needed. 564 Management of RFC 2385 keys has been a significant operational 565 problem, both in terms of key synchronization and key selection. 566 Current guidance [9] warns against sharing RFC 2385 keys between 567 systems, and recommends changing keys according to a schedule. The 568 same general operational issues are relevant for the management of 569 MAC keys. 571 Because the TCP Authentication Option relies on manual configuration, 572 it is possible that misconfigurations will occur. We review the 573 scenarios and describe their impact on security. 575 When multiple devices are configured with the same key, it is 576 possible that one or more of the devices is configured to use the 577 wrong MAC algorithm. If the misconfigured device is using a MAC that 578 is significantly weaker than that used by the correctly configured 579 devices, where the weakness allows an attacker to recover the MAC 580 key, the misconfiguration reduces the security of the properly 581 configured devices. An attacker who can recover the key through 582 cryptanalysis of the weaker algorithm can use that information to 583 attack the stronger algorithm. For this reason, implementations 584 SHOULD verify the length of the keys entered into the system, and 585 reject keys that are too short. The extent of vulnerability will 586 also be reduced when the receiver discards TCP segments due to a MAC 587 Algorithm ID mismatch (i.e., the MAC Algorithm ID field in the TCP 588 segment and the MAC Algorithm ID associated with the key do not 589 match). When this event is detected, it SHOULD provide that 590 information to an administrator, e.g. through logging or a management 591 interface. This attack is not applicable to AES-CMAC or HMAC, since 592 neither of those MACs is vulnerable to a key recovery attack. 594 When one or more devices are configured with a particular key, it is 595 possible that another device is configured with a slightly different 596 key, due to a typographical error. For example, the two keys might 597 differ only in a single hexadecimal digit. Message authentication 598 codes that are vulnerable whenever two related keys are used could be 599 vulnerable in this scenario. In order to protect against this 600 potential vulnerability, it is RECOMMENDED that no MACs with such 601 vulnerabilities be used. Neither AES-CMAC nor HMAC have such a 602 vulnerability. 604 16. IANA Considerations 606 The terms "Standards Action" and "Private Use" in this section 607 indicate the polices described for these terms in [7]. 609 A new TCP Option Kind value must be defined in the IANA TCP 610 Parameters registry. 612 The option header contains an 8-bit ALG ID, for which IANA is to 613 create and maintain a registry entitled "MAC Algorithm IDs". This 614 document defines the following message authentication code types: 616 MAC Algorithm ID Value 617 ---------------- ----- 618 RESERVED 0 619 AES-128-CMAC-96 1 620 HMAC-SHA-1-96 2 621 Standards Action 3-47 622 Private Use 48-63 624 Note to RFC Editor: this section may be removed on publication as an 625 RFC. 627 17. References 629 17.1. Normative References 631 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 632 Levels", BCP 14, RFC 2119, March 1997. 634 [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 635 September 1981. 637 [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 638 Specification", RFC 2460, December 1998. 640 [4] National Institute of Standards and Technology, "Recommendation 641 for Block Cipher Modes of Operation: The CMAC Mode for 642 Authentication", FIPS PUB 800-38B, May 2005, . 645 [5] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC 646 Algorithm", RFC 4493, June 2006. 648 [6] National Institute of Standards and Technology, "The Keyed-Hash 649 Message Authentication Code (HMAC)", FIPS PUB 198, March 2002, 650 . 652 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 653 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 655 17.2. Informative References 657 [8] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 658 Signature Option", RFC 2385, August 1998. 660 [9] Leech, M., "Key Management Considerations for the TCP MD5 661 Signature Option", RFC 3562, July 2003. 663 [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 664 April 1992. 666 [11] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash 667 Functions for Message Authentication", Proceedings of 668 Crypto'96 , LNCS 1109, pp. 1-15., June 1996, . 672 [12] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for 673 High Performance", RFC 1323, May 1992. 675 [13] Gont, F., "ICMP attacks against TCP", 676 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 677 February 2006. 679 [14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 680 RFC 2246, January 1999. 682 Authors' Addresses 684 Ronald P. Bonica 685 Juniper Networks 686 2251 Corporate Park Drive 687 Herndon, VA 20171 688 US 690 Email: rbonica@juniper.net 692 Brian Weis 693 Cisco Systems 694 170 W. Tasman Drive 695 San Jose, CA 95134-1706 696 US 698 Email: bew@cisco.com 700 Sriram Viswanathan 701 Cisco Systems 702 170 W. Tasman Drive 703 San Jose, CA 95134 704 US 706 Email: sriram_v@cisco.com 708 Andrew Lange 709 Alcatel 710 710 E. Middlefield Road 711 Mountain View, CA 94043 712 US 714 Email: andrew.lange@alcatel.com 716 Owen N. Wheeler 717 British Telecommunications plc 718 Adastral Park 719 Martlesham Heath 720 IPSWICH, Suffolk IP5 3RE 721 GB 723 Email: owen.wheeler@bt.com 725 Full Copyright Statement 727 Copyright (C) The Internet Society (2006). 729 This document is subject to the rights, licenses and restrictions 730 contained in BCP 78, and except as set forth therein, the authors 731 retain all their rights. 733 This document and the information contained herein are provided on an 734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 736 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 737 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 738 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 741 Intellectual Property 743 The IETF takes no position regarding the validity or scope of any 744 Intellectual Property Rights or other rights that might be claimed to 745 pertain to the implementation or use of the technology described in 746 this document or the extent to which any license under such rights 747 might or might not be available; nor does it represent that it has 748 made any independent effort to identify any such rights. Information 749 on the procedures with respect to rights in RFC documents can be 750 found in BCP 78 and BCP 79. 752 Copies of IPR disclosures made to the IETF Secretariat and any 753 assurances of licenses to be made available, or the result of an 754 attempt made to obtain a general license or permission for the use of 755 such proprietary rights by implementers or users of this 756 specification can be obtained from the IETF on-line IPR repository at 757 http://www.ietf.org/ipr. 759 The IETF invites any interested party to bring to its attention any 760 copyrights, patents or patent applications, or other proprietary 761 rights that may cover technology that may be required to implement 762 this standard. Please address the information to the IETF at 763 ietf-ipr@ietf.org. 765 Acknowledgment 767 Funding for the RFC Editor function is provided by the IETF 768 Administrative Support Activity (IASA).