idnits 2.17.1 draft-ietf-tcpm-tcp-auth-opt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1638. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2385, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5652 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-04 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Obsoletes: 2385 A. Mankin 4 Intended status: Proposed Standard Johns Hopkins Univ. 5 Expires: May 2009 R. Bonica 6 Juniper Networks 7 November 3, 2008 9 The TCP Authentication Option 10 draft-ietf-tcpm-tcp-auth-opt-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 3, 2009. 38 Abstract 40 This document specifies the TCP Authentication Option (TCP-AO), which 41 obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO 42 specifies the use of stronger Message Authentication Codes (MACs), 43 protects against replays even for long-lived TCP connections, and 44 provides more details on the association of security with TCP 45 connections than TCP MD5. TCP-AO is compatible with either static 46 keying or an external, out-of-band key management mechanism; in 47 either case, TCP-AO also protects connections when using the same key 48 across repeated instances of a connection. The result is intended to 49 support current infrastructure uses of TCP MD5, such as to protect 50 long-lived connections (as used, e.g., in BGP and LDP), and to 51 support a larger set of MACs with minimal other system and 52 operational changes. TCP-AO uses its own option identifier, even 53 though used mutually exclusive of TCP MD5 on a given TCP connection. 54 TCP-AO supports IPv6, and is fully compatible with the requirements 55 for the replacement of TCP MD5. 57 Table of Contents 59 1. Introduction...................................................3 60 1.1. Executive Summary.........................................4 61 1.2. List of TBD Items.........................................5 62 1.3. Changes from Previous Versions............................5 63 1.3.1. New in draft-ietf-tcp-auth-opt-02....................5 64 1.3.2. New in draft-ietf-tcp-auth-opt-01....................6 65 1.3.3. New in draft-ietf-tcp-auth-opt-00....................7 66 1.3.4. New in draft-touch-tcp-simple-auth-03................8 67 1.3.5. New in draft-touch-tcp-simple-auth-02................8 68 1.3.6. New in draft-touch-tcp-simple-auth-01................8 69 1.4. Summary of RFC-2119 Requirements..........................8 70 2. Conventions used in this document..............................9 71 3. The TCP Authentication Option..................................9 72 3.1. Review of TCP MD5 Option..................................9 73 3.2. TCP-AO Option............................................10 74 4. Preventing replay attacks within long-lived connections.......13 75 5. Computing connection keys from TSAD entries...................14 76 6. Security Association Management...............................16 77 7. TCP-AO Interaction with TCP...................................19 78 7.1. User Interface...........................................19 79 7.2. TCP States and Transitions...............................20 80 7.3. TCP Segments.............................................20 81 7.4. Sending TCP Segments.....................................21 82 7.5. Receiving TCP Segments...................................21 83 7.6. Impact on TCP Header Size................................23 84 8. Key Establishment and Duration Issues.........................23 85 8.1. Key reuse across socket pairs............................24 86 8.2. Key use within a long-lived connection...................24 87 8.3. Implementing the TSAD as an External Database............24 88 9. Obsoleting TCP MD5 and Legacy Interactions....................26 89 10. Interactions with non-NAT/NAPT Middleboxes...................26 90 11. Interactions with NAT/NAPT Devices...........................27 91 12. Evaluation of Requirements Satisfaction......................27 92 13. Security Considerations......................................29 93 14. IANA Considerations..........................................32 94 15. Acknowledgments..............................................32 95 16. References...................................................32 96 16.1. Normative References....................................32 97 16.2. Informative References..................................33 99 1. Introduction 101 The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates 102 TCP segments, including the TCP IPv4 pseudoheader, TCP header, and 103 TCP data. It was developed to protect BGP sessions from spoofed TCP 104 segments which could affect BGP data or the robustness of the TCP 105 connection itself [RFC2385][RFC4953]. 107 There have been many recent concerns about TCP MD5. Its use of a 108 simple keyed hash for authentication is problematic because there 109 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 110 also lacks both key management and algorithm agility. This document 111 adds the latter, but notes that TCP does not provide a sufficient 112 framework for cryptographic key management. This document obsoletes 113 the TCP MD5 option with a more general TCP Authentication Option 114 (TCP-AO), to support the use of other, stronger hash functions, 115 provide replay protection for long-lived connections and across 116 repeated instances of a single connection, and to provide a more 117 structured recommendation on external key management. The result is 118 compatible with IPv6, and is fully compatible with requirements under 119 development for a replacement for TCP MD5 [Be07]. 121 This document is not intended to replace the use of the IPsec suite 122 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 123 fact, we recommend the use of IPsec and IKE, especially where IKE's 124 level of existing support for parameter negotiation, session key 125 negotiation, or rekeying are desired. TCP-AO is intended for use only 126 where the IPsec suite would not be feasible, e.g., as has been 127 suggested is the case for some routing protocols, or in cases where 128 keys need to be tightly coordinated with individual transport 129 sessions [Be07]. 131 Note that TCP-AO obsoletes TCP MD5, although a particular 132 implementation may support both for backward compatibility. For a 133 given connection, only one can be in use. TCP MD5-protected 134 connections cannot be migrated to TCP-AO because TCP MD5 does not 135 support any changes to a connection's security configuration once 136 established. 138 1.1. Executive Summary 140 This document replaces TCP MD5 as follows [RFC2385]: 142 o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 144 o TCP-AO allows TCP MD5 to continue to be used for other (legacy) 145 connections. 147 o TCP-AO replaces MD5's single MAC algorithm with two prespecified 148 MACs (TBD-WG-MACS), and allows extension to include other MACs. 150 o TCP-AO allows rekeying during a TCP connection, assuming that an 151 out-of-band protocol or manual mechanism coordinates the key 152 change. In such cases, a key ID allows the efficient concurrent 153 use of multiple keys. Note that TCP MD5 does not preclude rekeying 154 during a connection, but does not require its support either. 155 Further, TCP-AO supports rekeying with zero packet loss, whereas 156 rekeying in TCP MD5 can lose packets in transit during the 157 changeover or require trying multiple keys on each received 158 segment during key use overlap. 160 o TCP-AO provides automatic key rollover to provide replay 161 protection for long-lived connections. 163 o TCP-AO ensures per-connection keys as unique as the TCP connection 164 itself, using TCP's ISNs for differentiation, even when static 165 keys are used for repeated instances of a socket pair. 167 o This document provides more detail in how this option interacts 168 with TCP's states, event processing, and user interface. 170 o The TCP-AO option is 3 bytes shorter than TCP MD5 (15 bytes 171 overall, rather than 18) in the default case (assuming a 96-bit 172 MAC). 174 This document differs from an IPsec/IKE solution in that TCP-AO as 175 follows [RFC4301][RFC4306]: 177 o TCP-AO does not support dynamic parameter negotiation. 179 o TCP-AO uses TCP's socket pair (source address, destination 180 address, source port, destination port) as a security parameter 181 index, rather than using a separate field as a primary index 182 (IPsec's SPI). 184 o TCP-AO forces a change of computed MACs when a connection 185 restarts, even when reusing a TCP socket pair (IP addresses and 186 port numbers) [Be07]. 188 o TCP-AO does not support encryption. 190 o TCP-AO does not authenticate ICMP messages (some ICMP messages may 191 be authenticated via IPsec, depending on the configuration). 193 1.2. List of TBD Items 195 [NOTE: to be omitted upon final publication as RFC] 197 SAAG: The following items are to be determined (TBD) prior to 198 publication. Once a value is chosen, it should be replaced for the 199 notation below throughout this document and the item removed from 200 this list. 202 TBD-IANA-KIND new TCP option Kind for TCP-AO, assigned by IANA 204 TBD-WG-MACS list of default required MAC algorithms 206 TBD-WG-MACLEN default length of MAC used in the TCP-AO MAF 208 1.3. Changes from Previous Versions 210 [NOTE: to be omitted upon final publication as RFC] 212 1.3.1. New in draft-ietf-tcp-auth-opt-02 214 o List issue - Replay Protection: incorporated key rollover based on 215 extended sequence number space, not using KeyID space. 217 o List issue - Unique Connection Keys: ISNs are used to generate 218 unique connection keys even when static keys used for repeated 219 instances of a socket pair. 221 o List issue - Header Format and Alignment: Moved KeyID to front. 223 o List issue - Reserved KeyID Value: Suggestion to reserve a single 224 KeyID value for implementation optimization received no support on 225 the WG list, so this was not changed. 227 o List issue - KeyID Randomness: KeyIDs are not assumed random; a 228 note was added that nonce-based filtering should be done on a 229 portion of the MAC (incorporated into the algorithm), and that 230 header fields should not be assumed to have cryptographic 231 properties (e.g., randomness). 233 o List issue - Support for NATs: preliminary rough consensus 234 suggests that TCP-AO should not be augmented to support NAT 235 traversal. Existing mechanisms for such traversal (UDP support) 236 can be applied, or IPsec NAT traversal is recommended in such 237 cases instead. 239 o IETF-72 topic - providing algorithm ID and T-bit (options 240 excluded) locations in the header: (No current consensus was 241 reached on this topic, so no change was made.) 243 o IETF-72 topic - providing additional header bits for in-band key 244 change signaling (draft-bonica's "K" bit): (No current consensus 245 was reached on this topic, so no change was made.) 247 o Clarified TCP-AO as obsoleting TCP MD5. 249 o Clarified the MAC Type as referring to the IANA registry of IKEv2 250 transforms, not the RFC establishing that registry. 252 o Added citation to the Wang/Yu paper regarding attacks on MD5 Wa05 253 to replace reports in Be05 and Bu06. 255 o Explained why option exclusion can't be changed during a 256 connection. 258 o Clarified that AO explicitly allows rekeying during a TCP 259 connection, without impacting packet loss. 261 o Described TCP-AO's interaction with reboots more clearly, and 262 explained the need to clear out old state that persists 263 indefinitely. 265 1.3.2. New in draft-ietf-tcp-auth-opt-01 267 o Require KeyID in all versions. Remove odd/even indicator of KeyID 268 usage. 270 o Relax restrictions on key reuse: requiring an algorithm for nonce 271 introduction based on ISNs, and suggest key rollover every 2^31 272 bytes (rather than using an extended sequence number, which 273 introduces new state to the TCP connection). 275 o Clarify NAT interaction; currently does not support omitting the 276 IP addresses or TCP ports, both of which would be required to 277 support NATs without any coordination. This appears to present a 278 problem for key management - if the key manager knows the received 279 addrs and ports, it should coordinate them (as indicated in Sec 280 8). 282 o Options are included or excluded all-or-none. Excluded options are 283 deleted, not just zeroed, to avoid the impact of reordering or 284 length changes of such options. 286 o Augment replay discussion in security considerations. 288 o Revise discussion of IKEv2 MAC algorithm names. 290 o Remove executive summary comparison to expired documents. 292 o Clarified key words to exclude lower case usage. 294 1.3.3. New in draft-ietf-tcp-auth-opt-00 296 o List of TBD values, and indication of how each is determined. 298 o Changed TCP-SA to TCP-AO (removed 'simple' throughout). 300 o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as 301 appropriate approach instead. 303 o Made several changes coordinated in the TCP-AUTH-DT as follow: 305 o Added R. Bonica as co-author. 307 o Use new TCP option Kind in the core doc. 309 o Addresses the impact of explicit declines on security. 311 o Add limits to TSAD size (2 <= TSAD <= 256). 313 o Allow 0 as a legitimate KeyID. 315 o Allow the WG to determine the two appropriate required MAC 316 algorithms. 318 o Add TO-DO items. 320 o Added discussion at end of Introduction as to why TCP MD5 321 connections cannot be upgraded to TCP-AO. 323 1.3.4. New in draft-touch-tcp-simple-auth-03 325 o Added support for NAT/NAPT. 327 o Added support for IPv6. 329 o Added discussion of how this proposal satisfies requirements under 330 development, including those indicated in [Be07]. 332 o Clarified the byte order of all data used in the MAC. 334 o Changed the TCP option exclusion bit from a bit to a list. 336 1.3.5. New in draft-touch-tcp-simple-auth-02 338 o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. 340 o Add reference to SP4 [SDNS88]. 342 o Added notes that TSAD to be externally implemented; this was 343 compatible with the TSAD described in the previous version. 345 o Augmented the protocol to allow a KeyID, required to support 346 efficient overlapping keys during rekeying, and potentially useful 347 during connection establishment. Accommodated by redesigning the 348 TSAD. 350 o Added the odd/even indicator for the KeyID. 352 o Allow for the exclusion of all TCP options in the MAC calculation. 354 1.3.6. New in draft-touch-tcp-simple-auth-01 356 o Allows intra-session rekeying, assuming out-of-band coordination. 358 o MUST allow TSAD entries to change, enabling rekeying within a TCP 359 connection. 361 o Omits discussion of the impact of connection reestablishment on 362 BGP, because added support for rekeying renders this point moot. 364 o Adds further discussion on the need for rekeying. 366 1.4. Summary of RFC-2119 Requirements 368 [NOTE: a summary will be placed here prior to last call] 370 2. Conventions used in this document 372 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 373 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 374 document are to be interpreted as described in RFC-2119 [RFC2119]. 376 In this document, these words will appear with that interpretation 377 only when in ALL CAPS. Lower case uses of these words are not to be 378 interpreted as carrying RFC-2119 significance. 380 3. The TCP Authentication Option 382 The TCP Authentication Option (TCP-AO) uses a TCP option Kind value 383 of TBD-IANA-KIND. 385 3.1. Review of TCP MD5 Option 387 For review, the TCP MD5 option is shown in Figure 1. 389 +---------+---------+-------------------+ 390 | Kind=19 |Length=18| MD5 digest... | 391 +---------+---------+-------------------+ 392 | | 393 +---------------------------------------+ 394 | | 395 +---------------------------------------+ 396 | | 397 +-------------------+-------------------+ 398 | | 399 +-------------------+ 401 Figure 1 The TCP MD5 Option [RFC2385] 403 In the TCP MD5 option, the length is fixed, and the MD5 digest 404 occupies 16 bytes following the Kind and Length fields, using the 405 full MD5 digest of 128 bits [RFC1321]. 407 The TCP MD5 option specifies the use of the MD5 digest calculation 408 over the following values in the following order: 410 1. The TCP pseudoheader (IP source and destination addresses, 411 protocol number, and segment length). 413 2. The TCP header excluding options and checksum. 415 3. The TCP data payload. 417 4. The connection key. 419 3.2. TCP-AO Option 421 The new TCP-AO option provides a superset of the capabilities of TCP 422 MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new 423 Kind field, and similar Length field to TCP MD5, as well as a KeyID 424 field as shown in Figure 2. 426 +----------+----------+----------+----------+ 427 | Kind | Length | KeyID | MAC | 428 +----------+----------+----------+----------+ 429 | MAC (con't) ... 430 +----------------------------------... 432 ...-----------------+ 433 ... MAC (con't) | 434 ...-----------------+ 436 Figure 2 The TCP-AO Option 438 The TCP-AO defines the following fields: 440 o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- 441 AO uses a new Kind value of TBD-IANA-KIND. Because of how keys are 442 managed (see Section 6), an endpoint will not use TCP-AO for the 443 same connection in which TCP MD5 is used. 445 >> A single TCP segment MUST NOT have more than one TCP-AO option. 447 o Length: An unsigned 1-byte field indicating the length of the TCP- 448 AO option in bytes, including the Kind, Length, KeyID, and MAC 449 fields. 451 >> The Length value MUST be greater than or equal to 3. 453 >> The Length value MUST be consistent with the TCP header length; 454 this is a consistency check and avoids overrun/underrun abuse. 456 Values of 3 and other small values are of dubious utility (e.g., 457 for MAC=NONE, or small values for very short MACs) but not 458 specifically prohibited. 460 o KeyID: An unsigned 1-byte field is used to support efficient key 461 changes during a connection and/or to help with key coordination 462 during connection establishment, and will be discussed further in 463 Section 4. Note that the KeyID has no cryptographic properties - 464 it need not be random, nor are there any reserved values. 466 o MAC: Message Authentication Field. Its contents are determined by 467 the particulars of the security association. Typical MACs are 96- 468 128 bits (12-16 bytes), but any length that fits in the header of 469 the segment being authenticated is allowed. 471 >> TCP-AO MUST support TBD-WG-MACS; other MACs MAY be supported 472 [RFC2403]. 474 The MAC is computed over the following fields in the following order: 476 1. The extended sequence number (ESN), in network-standard byte 477 order, as follows: 479 +--------+--------+--------+--------+ 480 | ESN | 481 +--------+--------+--------+--------+ 483 Figure 3 Extended sequence number 485 The ESN for transmitted segments is locally maintained from a 486 locally maintained SND.ESN value, for received segments, a local 487 RCV.ESN value is used. The details of how these values are 488 maintained and used is described in Sections 4, 7.4, and 7.5. 490 2. The TCP pseudoheader: IP source and destination addresses, 491 protocol number and segment length, all in network byte order, 492 prepended to the TCP header below. The pseudoheader is exactly as 493 used for the TCP checksum in either IPv4 or IPv6 494 [RFC793][RFC2460]: 496 +--------+--------+--------+--------+ 497 | Source Address | 498 +--------+--------+--------+--------+ 499 | Destination Address | 500 +--------+--------+--------+--------+ 501 | zero | Proto | TCP Length | 502 +--------+--------+--------+--------+ 504 Figure 4 TCP IPv4 pseudoheader [RFC793] 505 +--------+--------+--------+--------+ 506 | | 507 + + 508 | | 509 + Source Address + 510 | | 511 + + 512 | | 513 + + 514 +--------+--------+--------+--------+ 515 | | 516 + + 517 | | 518 + Destination Address + 519 | | 520 + + 521 | | 522 +--------+--------+--------+--------+ 523 | Upper-Layer Packet Length | 524 +--------+--------+--------+--------+ 525 | zero | Next Header | 526 +--------+--------+--------+--------+ 528 Figure 5 TCP IPv6 pseudoheader [RFC2460] 530 3. The TCP header, by default including options, and where the TCP 531 checksum and TCP-AO MAC fields are set to zero, all in network 532 byte order 534 4. TCP data, in network byte order 536 Note that the connection key is not included here; we expect that the 537 MAC algorithm will indicate how to use the key, e.g., as HMACs do in 538 general [RFC2104][RFC2403]. The connection key is derived from the 539 TSAD key entry as described in Sections 6, 7.4, and 7.5. 541 By default,TCP-AO includes the TCP options in the MAC calculation 542 because these options are intended to be end-to-end and some are 543 required for proper TCP operation (e.g., SACK, timestamp, large 544 windows). Middleboxes that alter TCP options en-route are a kind of 545 attack and would be successfully detected by TCP-AO. In cases where 546 the configuration of the connection's security association state 547 indicates otherwise, the TCP options can be excluded from the MAC 548 calculation. When options are excluded, all options - including TCP- 549 AO - are skipped over during the MAC calculation (rather than being 550 zeroed). 552 The TCP-AO option does not indicate the MAC algorithm either 553 implicitly (as with TCP MD5) or explicitly. The particular algorithm 554 used is considered part of the configuration state of the 555 connection's security association and is managed separately (see 556 Section 6). 558 4. Preventing replay attacks within long-lived connections 560 TCP uses a 32-bit sequence number which may, for long-lived 561 connections, roll over and repeat. This could result in TCP segments 562 being intentionally and legitimately replayed within a connection. 563 TCP-AO prevents replay attacks, and thus requires a way to 564 differentiate these legitimate replays from each other, and so it 565 adds a 32-bit extended sequence number (ESN) for transmitted and 566 received segments. 568 TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN 569 for received segments, both initialized as zero when a connection 570 begins. The intent of these ESNs is, together with TCP's 32-bit 571 sequence numbers, to provide a 64-bit overall sequence number space. 573 For transmitted segments SND.ESN can be implemented by extending 574 TCP's sequence number to 64-bits; SND.ESN would be the top (high- 575 order) 32 bits of that number. For received segments, TCP-AO needs to 576 emulate the use of a 64-bit number space, and correctly infer the 577 appropriate high-order 32-bits of that number as RCV.ESN from the 578 received 32-bit sequence number and the current connection context. 580 The implementation of ESNs is not specified in this document, but one 581 possible way is described here that can be used for either RCV.ESN, 582 SND.ESN, or both. 584 Consider an implementation with two ESNs as required (SND.ESN, 585 RCV.ESN), and additional variables as listed below, all initialized 586 to zero, as well as a current TCP segment field (SEG.SEQ): 588 o SND.PREV_SEQ, needed to detect rollover of SND.ESN 590 o RCV.PREV_SEQ, needed to detect rollover of RCV.ESN 592 o SND.ESN_FLAG, which indicates when to increment the SND.ESN 594 o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN 596 o ROLL, a temporary variable used to simplify the code 597 When a segment is received, the following algorithm (written in C) 598 computes the ESN used in the MAC; an equivalent algorithm can be 599 applied to the "SND" side: 601 ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); 603 if ((RCV.ESN_FLAG == 0) && (ROLL)) { 605 RCV.ESN = RCV.ESN + 1; 607 RCV.ESN_FLAG = 1; 609 } 611 # we've already incremented the RCV.ESN at this point 613 if (ROLL) { 615 ESN = RCV.ESN - 1; # use the pre-increment value 617 } else { 619 ESN = RCV.ESN; # use the current value 621 } 623 RCV.PREV_SEQ = SEG.SEQ; 625 if (SEG.SEQ > 0xffff) { 627 RCV.ESN_FLAG = 0; 629 } 631 5. Computing connection keys from TSAD entries 633 TSAD key entries, described in Section 6, are used in conjunction 634 with a TCP's connection ISNs to generate unique connection keys. This 635 allows a static TSAD key to be reused across different connections, 636 or across different instances of connections within a socket pair, 637 while maintaining unique connection keys. Unique connection keys are 638 generated without relying on external key management properties. 640 Given a TSAD key, the TCP socket pair, and the connection ISNs, the 641 connection key used in the MAC algorithm is computed as follows, 642 truncated to the same length as the TSAD key, using the same MAC 643 algorithm as the TSAD key (TALG): 645 Conn_key = TALG(TSAD_key, connblock) 647 The connection block (connblock) is defined as follows (IP addresses 648 are correspondingly longer for IPv6 addresses): 650 +--------+--------+--------+--------+ 651 | Source IP | 652 +--------+--------+--------+--------+ 653 | Destination IP | 654 +--------+--------+--------+--------+ 655 | Source Port | Dest. Port | 656 +--------+--------+--------+--------+ 657 | Source ISN | 658 +--------+--------+--------+--------+ 659 | Destination ISN | 660 +--------+--------+--------+--------+ 662 Figure 6 Connection block used for connection key generation 664 "Source" and "destination" are defined by the direction of the 665 segment being MAC'd; for incoming packets, source is the remote side, 666 whereas for outgoing packets source is the local side. This further 667 ensures that keys for each direction are unique. 669 For SYN segments (segments with the SYN set, but the ACK not set), 670 the destination ISN is not known. For these segments, the key is 671 computed using the connection block shown above, in which the 672 Destination ISN value is zero. For all other segments, the ISN pair 673 is used when known. If the ISN pair is not known, e.g., when sending 674 a RST after a reboot, the segment should be sent without 675 authentication; if authentication was required, the segment cannot 676 have been MAC'd properly anyway and would have been dropped on 677 receipt. 679 >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination 680 ISN of zero (whether sent or received); all other segments use the 681 known ISN pair. 683 >> Segments sent in response to connections for which the ISNs are 684 not known SHOULD NOT use TCP-AO. 686 Once a connection is established, a connection key would typically be 687 cached to avoid recomputing it on a per-segment basis. The use of 688 both ISNs in the connection key computation ensures that segments 689 cannot be replayed across repeated connections reusing the same 690 socket pair (provided the ISN pair does not repeat, which is 691 extremely unlikely). 693 In general, a SYN would be MAC'd using a destination ISN of zero 694 (whether sent or received), and all other segments would be MAC'd 695 using the ISN pair for the connection. There are other cases in which 696 the destination ISN is not known, but segments are emitted, such as 697 after an endpoint reboots, when is possible that the two endpoints 698 would not have enough information to authenticate segments. In such 699 cases, TCP's timeout mechanism will allow old state to be cleared to 700 enable new connections, except where the user timeout is disabled; it 701 is important that implementations are capable of detecting excesses 702 of TCP connections in such a configuration and can clear them out if 703 needed to protect its memory usage [Je07]. 705 6. Security Association Management 707 TCP-AO relies on a TCP Security Association Database (TSAD). TSAD 708 entries are assumed to exist at the endpoints where TCP-AO is used, 709 in advance of the connection: 711 1. TCP connection identifier (ID), i.e., socket pair - IP source 712 address, IP destination address, TCP source port, and TCP 713 destination port [RFC793]. TSAD entries are uniquely determined by 714 their TCP connection ID, which is used to index those entries. 716 >> There MUST be no more than one matching TSAD entry per 717 direction for a TCP connection ID. 719 2. For each of inbound (for received TCP segments) and outbound (for 720 sent TCP segments) directions for this connection (except as 721 noted): 723 a. TCP option flag. When 0, this flag allows default operation, 724 i.e., TCP options are included in the MAC calculation, with 725 TCP-AO's MAC field zeroed out. When 1, all options (including 726 TCP-AO) are excluded from all MAC calculations (skipped over, 727 not simply zeroed). 729 >> The TCP option flag MUST default to 0 (i.e., options not 730 excluded). 732 >> The TCP option flag MUST NOT change during a TCP 733 connection. 735 The TCP option flag cannot change during a connection because 736 TCP state is coordinated during connection establishment. TCP 737 lacks a handshake for modifying that state after a connection 738 has been established. 740 b. An extended sequence number (ESN). The ESN enables each 741 segment's MAC calculation to have unique input data, even when 742 payload data is retransmitted and the TCP sequence number 743 repeats due to wraparound. The ESN is initialized to zero upon 744 connection establishment. Its use in the MAC calculation is 745 described in Section 3.2, and its management is described in 746 Section 4. 748 c. An ordered list of zero or more key tuples. Each tuple is 749 defined as the set as 750 follows: 752 >> TSAD key tuple components MUST NOT change during a 753 connection. 755 Keeping the tuple components static ensures that the KeyID 756 uniquely determines the properties of a packet; this supports 757 use of the KeyID to determine the packet properties. 759 >> The set of TSAD key tuples MAY change during a connection, 760 but KeyIDs of those tuples MUST NOT overlap. I.e., tuple 761 parameter changes MUST be accompanied by key changes. 763 i. KeyID. A single byte used to differentiate connection 764 keys in concurrent use. 766 >> A TSAD implementation MUST support at least two KeyIDs 767 per connection per direction, and MAY support up to 256. 769 >> A KeyID MUST support any value, 0-255 inclusive. There 770 are no reserved KeyID values. 772 KeyID values are assigned arbitrarily. They can be 773 assigned in sequence, or based on any method mutually 774 agreed by the connection endpoints (e.g., using an 775 external key management mechanism). 777 >> KeyIDs MUST NOT be assumed to be randomly assigned. 779 ii. MAC type. Indicates the MAC used for this connection, 780 referencing types registered in the IKEv2 Transform Type 781 3 (Integrity Algorithms) Registry of the IANA established 782 by [RFC4306]. This includes each MAC algorithm (e.g., 783 HMAC-MD5, HMAC-SHA1, UMAC, etc.) and the length of the 784 MAC as truncated to (e.g., 96, 128, etc.). Note that TCP- 785 AO refers to the IKEv2 list of transforms, but TCP-AO is 786 not dependent on IKEv2 itself. 788 >> A MAC type of "NONE" MUST be supported, to indicate 789 that authentication is not used in this direction; this 790 allows asymmetric use of TCP-AO. 792 >> At least one direction (inbound/outbound) SHOULD have 793 a non-"NONE" MAC in practice, but this MUST NOT be 794 strictly required by an implementation. 796 >> When the outbound MAC is set to values other than 797 "NONE", TCP-AO MUST occur in every outbound TCP segment 798 for that connection; when set to NONE or when no tuple 799 exists, TCP-AO MUST NOT occur in those segments. 801 >> When the inbound MAC is set to values other than 802 "NONE", TCP-AO MUST occur in every inbound TCP segment 803 for that connection; when set to "NONE" or when no tuple 804 exists, TCP-AO SHOULD NOT be added to those segments, but 805 MAY occur and MUST be ignored. 807 iii. Key length. A byte indicating the length of the key in 808 bytes. 810 iv. Key. A byte sequence used for generating connection keys, 811 this may be derived from a separate shared key by an 812 external protocol over a separate channel. This sequence 813 is used in network-standard byte order in the key 814 generation algorithm described in Section 5. 816 It is anticipated that TSAD entries for TCP connections in states 817 other than CLOSED can be stored in the TCP Control Block (TCB) or in 818 a separate database (see Section 8.1 for notes on the latter); TSAD 819 entries for pending connections (in passive or active OPEN) may be 820 stored in a separate database. This means that in a single host there 821 should be only a single database that is consulted by all pending 822 connections, the same way that there is only one set of TCBs. 823 Multiple databases could be used to support virtual hosts, i.e., 824 groups of interfaces. 826 Note that the TCP-AO fields omit an explicit algorithm ID; that 827 algorithm is already specified by the TCP connection ID and stored in 828 the TSAD. 830 Also note that this document does not address how TSAD entries are 831 created by users/processes; it specifies how they must be destroyed 832 corresponding to connection states, but users/processes may destroy 833 entries as well. It is presumed that a TSAD entry affecting a 834 particular connection cannot be destroyed during an active connection 835 - or, equivalently, that its parameters are copied to TSAD entries 836 local to the connection (i.e., instantiated) and so changes would 837 affect only new connections. The TSAD could be managed by a separate 838 application protocol, and can be stored in a separate database if 839 desired. 841 7. TCP-AO Interaction with TCP 843 The following is a description of how TCP-AO affects various TCP 844 states, segments, events, and interfaces. This description is 845 intended to augment the description of TCP as provided in RFC793 846 [RFC793]. 848 7.1. User Interface 850 The TCP user interface supports active and passive OPEN, SEND, 851 RECEIVE, CLOSE, STATUS and ABORT commands. 853 >> TCP OPEN, or the sequence of commands that configure a connection 854 to be in the active or passive OPEN state, MUST be augmented so that 855 a TSAD entry can be configured. 857 Users are advised to not inappropriately reuse keys [RFC3562]. As 858 noted in Section 3.2, this is accomplished in TCP-AO by the use of 859 unique per-connection nonces in conjunction with conventional keys. 861 >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a 862 current or pending connection to be read (for confirmation). 864 >> A TCP-AO implmentation MUST allow TSAD entries for ongoing TCP 865 connections (i.e., not in the CLOSED state) to be modified. 866 Parameters not used to index a connection MAY be modified; parameters 867 used to index a connection MUST NOT be modified. 869 TSAD entries for TCP connections not in the CLOSED state are deleted 870 indirectly using the CLOSE or ABORT commands. 872 TCP SEND and RECEIVE are not affected by TCP-AO. 874 7.2. TCP States and Transitions 876 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 877 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 878 CLOSED. 880 >> A TSAD entry MAY be associated with any TCP state. 882 >> A TSAD entry MAY underspecify the TCP connection for the LISTEN 883 state. Such an entry MUST NOT be used for more than one connection 884 progressing out of the LISTEN state. 886 7.3. TCP Segments 888 TCP includes control (at least one of SYN, FIN, RST flags set) and 889 data (none of SYN, FIN, or RST flags set) segments. Note that some 890 control segments can include data (e.g., SYN). 892 >> All TCP segments MUST be checked against the TSAD for matching TCP 893 connection IDs. 895 >> TCP segments matching TSAD entries with non-NULL MACs without TCP- 896 AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be 897 silently discarded. 899 >> TCP segments with TCP-AO but not matching TSAD entries MUST be 900 silently accepted; this is required for equivalent function with TCPs 901 not implementing TCP-AO. 903 >> Silent discard events SHOULD be signaled to the user as a warning, 904 and silent accept events MAY be signaled to the user as a warning. 905 Both warnings, if available, MUST be accessible via the STATUS 906 interface. Either signal MAY be asynchronous, but if so they MUST be 907 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 908 limiting as well. 910 All TCP-AO processing occurs between the interface of TCP and IP; for 911 incoming segments, this occurs after validation of the TCP checksum. 912 For outgoing segments, this occurs before computation of the TCP 913 checksum. 915 Note that the TCP-AO option is not negotiated. It is the 916 responsibility of the receiver to determine when TCP-AO is required 917 and to enforce that requirement. 919 7.4. Sending TCP Segments 921 The following procedure describes the modifications to TCP to support 922 TCP-AO when a segment departs. 924 1. Check the segment's TCP connection ID against the TSAD 926 2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with 927 computing the TCP checksum and transmit the segment. 929 3. If there is a TSAD entry with zero key tuples, omit the TCP-AO 930 option. Proceed with computing the TCP checksum and transmit the 931 segment. 933 4. If there is a TSAD entry and a key tuple and the outgoing MAC is 934 NONE, omit the TCP-AO option. Proceed with computing the TCP 935 checksum and transmit the segment. 937 5. If there is a TSAD entry and a key tuple and the outgoing MAC is 938 not NONE: 940 a. Augment the TCP header with the TCP-AO, inserting the 941 appropriate Length and KeyID based on the indexed TSAD entry. 942 Update the TCP header length accordingly. 944 b. Determine SND.ESN as described in Section 4. 946 c. Determine the connection key from the indexed TSAD entry as 947 described in Section 5. 949 d. Compute the MAC using the indexed TSAD entry and data from the 950 segment as specified in Section 3.2, including the TCP 951 pseudoheader and TCP header. Include or exclude the options as 952 indicated by the TSAD entry's TCP option exclusion flag. 954 e. Insert the MAC in the TCP-AO field. 956 f. Proceed with computing the TCP checksum on the outgoing packet 957 and transmit the segment. 959 7.5. Receiving TCP Segments 961 The following procedure describes the modifications to TCP to support 962 TCP-AO when a segment arrives. 964 1. Check the segment's TCP connection ID against the TSAD. 966 2. If there is NO TSAD entry, proceed with TCP processing. 968 3. If there is a TSAD entry with zero key tuples, proceed with TCP 969 processing. 971 4. If there is a TSAD entry with a key tuple and the incoming MAC is 972 NONE, proceed with TCP processing. 974 5. If there is a TSAD entry with a key tuple and the incoming MAC is 975 not NONE: 977 a. Check that the segment's TCP-AO Length matches the length 978 indicated by the indexed TSAD. 980 i. If Lengths differ, silently discard the segment. Log 981 and/or signal the event as indicated in Section 7.3. 983 b. Use the KeyID value to index the appropriate key for this 984 connection. 986 i. If the TSAD has no entry corresponding to the segment's 987 KeyID, silently discard the segment. 989 c. Determine the segment's RCV.ESN as described in Section 4. 991 d. Determine the segment's connection key from the indexed TSAD 992 entry as described in Section 5. 994 e. Compute the segment's MAC using the indexed TSAD entry and 995 portions of the segment as indicated in Section 3.2. 997 Again, if options are excluded (as per the TCP option 998 exclusion flag), they are skipped over (rather than zeroed) 999 when used as input to the MAC calculation. 1001 i. If the computed MAC differs from the TCP-AO MAC field 1002 value, silently discard the segment. Log and/or signal 1003 the event as indicated in Section 7.3. 1005 f. Proceed with TCP processing of the segment. 1007 It is suggested that TCP-AO implementations validate a segment's 1008 Length field before computing a MAC, to reduce the overhead incurred 1009 by spoofed segments with invalid TCP-AO fields. 1011 Additional reductions in MAC validation can be supported by using a 1012 MAC algorithm that partitions the MAC field into fixed and computed 1013 portions, where the fixed value is validated before investing in the 1014 computed portion. This optimization would be contained in the MAC 1015 algorithm specification. Note that the KeyID cannot be used for 1016 connection validation per se, because it is not assumed random. 1018 7.6. Impact on TCP Header Size 1020 The TCP-AO option typically uses a total of 17-19 bytes of TCP header 1021 space. TCP-AO is no larger than and typically 3 bytes smaller than 1022 the TCP MD5 option (assuming a 96-bit MAC). Although TCP option space 1023 is limited, we believe TCP-AO is consistent with the desire to 1024 authenticate TCP at the connection level for similar uses as were 1025 intended by TCP MD5. 1027 8. Key Establishment and Duration Issues 1029 The TCP-AO option does not provide a mechanism for connection key 1030 negotiation or parameter negotiation (MAC algorithm, length, or use 1031 of the TCP-AO option) or rekeying during a connection. We assume out- 1032 of-band mechanisms for key establishment, parameter negotiation, and 1033 rekeying. This separation of key use from key management is similar 1034 to that in the IPsec security suite [RFC4301][RFC4306]. 1036 We encourage users of TCP-AO to apply known techniques for generating 1037 appropriate keys, including the use of reasonable connection key 1038 lengths, limited connection key sharing, and limiting the duration of 1039 connection key use [RFC3562]. This also includes the use of per- 1040 connection nonces, as suggested in Section 3.2. 1042 TCP-AO supports rekeying in which new keys are negotiated out-of- 1043 band, either via a protocol or a manual procedure [RFC4808]. New keys 1044 use is coordinated using the out-of-band mechanism to update the TSAD 1045 at both TCP endpoints. In the default case, where only a single key 1046 is used at a time, the temporary use of invalid keys would result in 1047 packets being dropped; TCP is already robust to such drops. Such 1048 drops may affect TCP's throughput temporarily, as a result TCP-AO 1049 benefits from the use of congestion control support for temporary 1050 path outages. 1052 >> TCP-AO SHOULD be deployed in conjunction with support for 1053 selective acknowledgement (SACK), including support for multiple lost 1054 segments in the same round trip [RFC2018][RFC3517]. 1056 Note that TCP-AO's support for rekeying is designed to be minimal in 1057 the default case. Segments carry only enough context to identify the 1058 security association [RFC4301][RFC4306]. In TCP-AO, this context is 1059 provided by the socket pair (IP addresses and ports for source and 1060 destination). The TSAD can contain multiple concurrent keys, where 1061 the KeyID field is used to identify the key that corresponds to a 1062 segment, to avoid the need for expensive trial-and-error testing of 1063 keys in sequence. 1065 The KeyID field is also useful in coordinating keys for new 1066 connections. A TSAD entry may be configured that matches the unbound 1067 source port, which would return a set of possible keys. The KeyID 1068 would then indicate the specific key, allowing more efficient 1069 connection establishment; otherwise, the keys could have been tried 1070 in sequence. See also Section 8.1. 1072 Implementations are encouraged to keep keys in a suitably private 1073 area. 1075 8.1. Key reuse across socket pairs 1077 Keys can be reused across different socket pairs within a host, or 1078 across different instances of a socket pair within a host. In either 1079 case, replay protection is maintained. 1081 Keys reused across different socket pairs cannot enable replay 1082 attacks because the TCP socket pair is included in the MAC, as well 1083 as in the generation of the connection key. Keys reused across 1084 repeated instances of a given socket pair cannot enable replay 1085 attacks because the connection ISNs are included in the connection 1086 key generation algorithm, and ISN pairs are unlikely to repeat over 1087 useful periods. 1089 Keys should not be shared across different hosts, because this could 1090 compromise the keying material itself. 1092 8.2. Key use within a long-lived connection 1094 TCP-AO uses extended sequence numbers (ESNs) to prevent replay 1095 attacks within long-lived connections. Key rollover can be used to 1096 change keying material for various reasons (e.g., personnel 1097 turnover), but is not required to support long-lived connections. 1099 8.3. Implementing the TSAD as an External Database 1101 The TSAD implementation is considered external to TCP-AO. When an 1102 external database is used, it would be useful to consider the 1103 interface between TCP-AO and the TSAD. The following is largely a 1104 restatement of information in Section 6. 1106 The TSAD API is accessed during a connection as follows: 1108 o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP 1109 source address, 4 byte IP destination address, 2 byte TCP source 1110 port, 2 byte TCP destination port). 1112 o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 = 1113 outbound) 1115 o Number of bytes to be sent/received (two bytes); this is used on 1116 the send side to trigger bytecount-based KeyID changes, and on the 1117 receive side only for statistics or length-sensitive KeyID 1118 selection. 1120 o KeyID (single byte); this is provided only by a receiver (i.e., 1121 matching the KeyID of the received segment), where a sender would 1122 leave this unspecified (and the call would return the appropriate 1123 KeyID to use). 1125 The call passes the number of bytes sent/received, and an indication 1126 of the direction (send/receive), to enable traffic-based key 1127 rollover. 1129 The source port can be 'unbound', indicated by the value 0x0000. In 1130 this case, the source port is considered a wildcard, and all 1131 corresponding TSAD entries (indexed by the KeyID) are returned as a 1132 list. This feature is used during connection establishment. 1134 TSAD calls return the following parameters: 1136 o TCP option exclusion flag (one byte, with 0x00 having the meaning 1137 "exclude none" and 0x01 meaning "exclude all"). 1139 o An ordered list of zero or more connection key tuples: 1140 1142 o KeyID (one byte) 1144 o MAC type (four bytes, an IKEv2 Transform Type 3 ID [RFC4306]) 1146 o MAC length (one byte) 1148 o Key length (one byte) 1150 o Key (byte sequence, indicating the key value) 1152 When the TSAD returns zero keys, it is indicating that there are no 1153 currently valid keys for the connection. 1155 9. Obsoleting TCP MD5 and Legacy Interactions 1157 TCP-AO obsoletes TCP MD5. As we have noted earlier: 1159 >> TCP implementations MUST support TCP-AO. 1161 Systems implementing TCP MD5 only are considered legacy, and ought to 1162 be upgraded when possible. In order to support interoperation with 1163 such legacy systems until upgrades are available: 1165 >> TCP MD5 SHOULD be supported where interactions with legacy systems 1166 is needed. 1168 >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for 1169 connections unless not supported by its peer, at which point it MAY 1170 use TCP MD5 instead. 1172 >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a 1173 particular TCP connection, but MAY support TCP-AO and TCP MD5 1174 simultaneously for different connections (notably to support legacy 1175 use of TCP MD5). 1177 The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used 1178 for a particular connection in TCP segments. 1180 It is possible that the TSAD could be augmented to support TCP MD5, 1181 although use of a TSAD-like system is not described in RFC2385. 1183 It is possible to require TCP-AO for a connection or TCP MD5, but it 1184 is not possible to require 'either'. Note that when TCP MD5 is 1185 required on for a connection, it must be used [RFC2385]. This 1186 prevents combined use of the two options for a given connection, to 1187 be determined by the other end of the connection. 1189 10. Interactions with non-NAT/NAPT Middleboxes 1191 TCP-AO supports middleboxes that do not change the IP addresses or 1192 ports of segments. Such middleboxes may modify some TCP options, in 1193 which case TCP-AO would need to be configured to ignore all options 1194 in the MAC calculation on connections traversing that element. 1196 Note that ignoring TCP options may provide less protection, i.e., TCP 1197 options could be modified in transit, and such modifications could be 1198 used by an attacker. Depending on the modifications, TCP could have 1199 compromised efficiency (e.g., timestamp changes), or could cease 1200 correct operation (e.g., window scale changes). These vulnerabilities 1201 affect only the TCP connections for which TCP-AO is configured to 1202 ignore TCP options. 1204 11. Interactions with NAT/NAPT Devices 1206 TCP-AO cannot interoperate natively across NAT/NAPT devices, which 1207 modify the IP addresses and/or port numbers. We anticipate that 1208 traversing such devices will require variants of existing NAT/NAPT 1209 traversal mechanisms, e.g., encapsulation of the TCP-AO-protected 1210 segment in another transport segment (e.g., UDP), as is done in IPsec 1211 [RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO, 1212 or IPsec NAT traversal can be used instead in such cases [RFC3947]. 1214 12. Evaluation of Requirements Satisfaction 1216 TCP-AO satisfies all the current requirements for a revision to TCP 1217 MD5, as indicated in [Be07] and under current development. This 1218 should not be a surprise, as the majority of the evolving 1219 requirements are derived from its design. The following is a summary 1220 of those requirements and notes where relevant. 1222 1. Protected Elements - see Section 3.2. 1224 a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that 1225 we do not allow optional coverage because IP addresses define 1226 a connection. If they can be coordinated across a NAT/NAPT, 1227 the sender can compute the MAC based on the received values; 1228 if not, a tunnel is required. 1230 b. TCP header. Note that we do not allow optional port coverage 1231 because ports define a connection. If they can be coordinated 1232 across a NAT/NAPT, the sender can compute the MAC based on the 1233 received values; if not, a tunnel is required. 1235 c. TCP options. Allows exclusion of TCP options from coverage, as 1236 required. 1238 d. TCP data. Done. 1240 2. Option structure requirements 1242 a. Privacy. TCP-AO exposes only the key index, MAC, and overall 1243 option length. Note that short MACs could be obscured by using 1244 longer option lengths but specifying a short MAC length (this 1245 is equivalent to a different MAC algorithm, and is specified 1246 in the TSAD entry). See Section 3.2. 1248 b. Allow optional per connection. Done - see Sections 7.3, 7.4, 1249 and 7.5. 1251 c. Require non-optional. Done - see Sections 7.3, 7.4, and 7.5. 1253 d. Standard parsing. Done - see Section 3.2. 1255 e. Compatible with Large Windows. Done - see Section 3.2. The 1256 size of the option is intended to allow use with Large Windows 1257 and SACK. See also Section 1.1, which indicates that TCP-AO is 1258 3 bytes shorter than TCP MD5 in the default case, assuming a 1259 96-bit MAC. 1261 f. Compatible with SACK. Done - see Section 3.2. The size of the 1262 option is intended to allow use with Large Windows and SACK. 1263 See also Section 8 regarding key management. See also Section 1264 1.1, which indicates that TCP-AO is 3 bytes shorter than TCP 1265 MD5 in the default case. 1267 3. Cryptography requirements 1269 a. Baseline defaults. TCP-AO uses TBD-WG-MACS as the default, as 1270 noted in Section 3.2. 1272 b. Good algorithms. TCP-AO uses TBD-WG-MACS as the default, but 1273 does not otherwise specify the algorithms used. That would be 1274 specified in the key management protocol, and should be 1275 limited there. 1277 c. Algorithm agility. TCP-AO allows any desired algorithm, 1278 subject to TCP option space limitations, as noted in Section 1279 3.2. The TSAD allows separate connections to use different 1280 algorithms. 1282 d. Pre-TCP processing. Done - see Sections 7.3, 7.4, and 7.5. 1283 Note that pre-TCP processing is required, because TCP segments 1284 cannot be discarded solely based on a combination of 1285 connection state and out-of-window checks; many such segments, 1286 although discarded, cause a host to respond with a replay of 1287 the last valid ACK, e.g. [RFC793]. 1289 e. Parameter changes require key changes. TSAD parameters that 1290 should not change during a connection (TCP connection ID, 1291 receiver TCP connection ID, TCP option exclusion list) cannot 1292 change. Other parameters change only when a key is changed, 1293 using the key tuple mechanism in the TSAD. See Section 6. 1295 4. Keying requirements. TCP-AO does not specify a key management 1296 system, but does indicate a proposed interface to the TSAD, 1297 allowing a completely separate key system. 1299 a. Intraconnection rekeying. Supported by the KeyID and multiple 1300 key tuples in a TSAD entry; see Section 6. 1302 b. Efficient rekeying. Supported by the KeyID. See Section 8. 1304 c. Automated and manual keying. Supported by the TSAD interface. 1305 See Section 8. Enhanced by the generation of unique per- 1306 connection keys as noted in Section 5. 1308 d. Key management agnostic. Supported by the TSAD interface. See 1309 Section 8.1. 1311 5. Expected constraints 1313 a. Silent failure. Done - see Sections 7.3, 7.4, and 7.5. 1315 b. At most one such option per segment. Done - see Section 3.2. 1317 c. Outgoing all or none. Done - see Section 7.4. 1319 d. Incoming all checked. Done - see Section 7.5. 1321 e. Non-interaction with TCP MD5. Done - see Section 9. 1323 f. Optional ICMP discard. Done - see Section 13. 1325 g. Allows use of NAT/NAPT devices. Done - see Section 10. 1327 h. Maintain TCP connection semantics, in which the socket pair 1328 alone defines a TCP association and all its security 1329 parameters. Done - see Sections 6 and 10. 1331 i. Try to avoid creating a CPU DOS attack opportunity. Done - see 1332 Section 13. 1334 13. Security Considerations 1336 Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 1337 performance. Connections that are known to use TCP-AO can be attacked 1338 by transmitting segments with invalid MACs. Attackers would need to 1339 know only the TCP connection ID and TCP-AO Length value to 1340 substantially impact the host's processing capacity. This is similar 1341 to the susceptibility of IPsec to on-path attacks, where the IP 1342 addresses and SPI would be visible. For IPsec, the entire SPI space 1343 (32 bits) is arbitrary, whereas for routing protocols typically only 1344 the source port (16 bits) is arbitrary. As a result, it would be 1345 easier for an off-path attacker to spoof a TCP-AO segment that could 1346 cause receiver validation effort. However, we note that between 1347 Internet routers both ports could be arbitrary (i.e., determined a- 1348 priori out of band), which would constitute roughly the same off-path 1349 antispoofing protection of an arbitrary SPI. 1351 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets 1352 typically occur after peer crashes, either in response to new 1353 connection attempts or when data is sent on stale connections; in 1354 either case, the recovering endpoint may lack the connection key 1355 required (e.g., if lost during the crash). This may result in time- 1356 outs, rather than more responsive recovery after such a crash. As 1357 noted in Section 5, such cases may also result in persistent TCP 1358 state for old connections that cannot be cleared, and so 1359 implementations should be capable of detecting an excess of such 1360 connections and clearing their state if needed to protect memory 1361 utilization [Je07]. 1363 TCP-AO does not include a fast decline capability, e.g., where a SYN- 1364 ACK is received without an expected TCP-AO option and the connection 1365 is quickly reset or aborted. Normal TCP operation will retry and 1366 timeout, which is what should be expected when the intended receiver 1367 is not capable of the TCP variant required anyway. Backoff is not 1368 optimized because it would present an opportunity for attackers on 1369 the wire to abort authenticated connection attempts by sending 1370 spoofed SYN-ACKs without the TCP-AO option. 1372 TCP-AO does not expose the MAC algorithm used to authenticate a 1373 particular connection; that information is kept in the TSAD at the 1374 endpoints, and is not indicated in the header. 1376 TCP-AO is intended to provide similar protections to IPsec, but is 1377 not intended to replace the use of IPsec or IKE either for more 1378 robust security or more sophisticated security management. 1380 TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes 1381 recommendations regarding dropping ICMPs in certain contexts, or 1382 requiring that they are endpoint authenticated in others [RFC4301]. 1383 There are other mechanisms proposed to reduce the impact of ICMP 1384 attacks by further validating ICMP contents and changing the effect 1385 of some messages based on TCP state, but these do not provide the 1386 level of authentication for ICMP that TCP-AO provides for TCP [Go07]. 1388 >> A TCP-AO implementation MUST allow the system administrator to 1389 configure whether TCP will ignore incoming ICMP messages of Type 3 1390 Codes 2-4 intended for connections that match TSAD entries with non- 1391 NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be 1392 logged. 1394 This control affects only ICMPs that currently require 'hard errors', 1395 which would abort the TCP connection. This recommendation is intended 1396 to be similar to how IPsec would handle those messages [RFC4301]. 1398 TCP-AO includes the TCP connection ID in the MAC calculation. This 1399 prevents connections using the same key (for whatever reason) from 1400 potentially enabling a traffic-crossing attack, in which segments to 1401 one socket pair are diverted to attack a different socket pair. When 1402 multiple connections use the same key, it would be useful to know 1403 that packets intended for one ID could not be (maliciously or 1404 otherwise) modified in transit and end up being authenticated for the 1405 other ID. The ID cannot be zeroed, because to do so would require 1406 that the TSAD index was unique in both directions (ID->key and key- 1407 >ID). That requirement would place an additional burden of uniqueness 1408 on keys within endsystems, and potentially across endsystems. 1409 Although the resulting attack is low probability, the protection 1410 afforded by including the received ID warrants its inclusion in the 1411 MAC, and does not unduly increase the MAC calculation or key 1412 management system. 1414 The use of any security algorithm can present an opportunity for a 1415 CPU DOS attack, where the attacker sends false, random segments that 1416 the receiver under attack expends substantial CPU effort to reject. 1417 In IPsec, such attacks are reduced by the use of a large Security 1418 Parameter Index (SPI) and Sequence Number fields to partly validate 1419 segments before CPU cycles are invested validated the Integrity Check 1420 Value (ICV). In TCP-AO, the socket pair performs most of the function 1421 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay 1422 attacks, isn't needed in all cases due to TCP's Sequence Number, 1423 which is used to reorder received segments. TCP already protects 1424 itself from replays of authentic segment data as well as authentic 1425 explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic 1426 replays could affect TCP congestion control [Sa99]. TCP-AO does not 1427 protect TCP congestion control from such attacks due to the 1428 cumbersome nature of layering a windowed security sequence number 1429 within TCP in addition to TCP's own sequence number; when such 1430 protection is desired, users are encouraged to apply IPsec instead. 1432 Further, it is not useful to validate TCP's Sequence Number before 1433 performing a TCP-AO authentication calculation, because out-of-window 1434 segments can still cause valid TCP protocol actions (e.g., ACK 1435 retransmission) [RFC793]. It is similarly not useful to add a 1436 separate Sequence Number field to the TCP-AO option, because doing so 1437 could cause a change in TCP's behavior even when segments are valid. 1439 14. IANA Considerations 1441 The TCP-AO option defines no new namespaces. 1443 The TCP-AO option uses the TCP option Kind value TCP-IANA-KIND, 1444 allocated by IANA from the TCP option Kind namespace. 1446 To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2 1447 Transform Type 3 IDs, because that database of names already exists 1448 (not because of any reliance on IKEv2) [RFC4306]. 1450 [NOTE: The following to be removed prior to publication as an RFC] 1452 The TCP-AO option requires that IANA allocate a value from the TCP 1453 option Kind namespace, to be replaced for TCP-IANA-KIND throughout 1454 this document. 1456 15. Acknowledgments 1458 This document was inspired by the revisions to TCP MD5 suggested by 1459 Brian Weis and Ron Bonica [Bo07][We05][We07]. Russ Housley suggested 1460 L4/application layer management of the TSAD. The KeyID field was 1461 motivated by Steve Bellovin. Eric Rescorla suggested the use of ISNs 1462 in the connection key computation and ESNs to avoid replay attacks, 1463 and Brian Weis extended the computation to incorporate the entire 1464 connection ID. Alfred Hoenes, Charlie Kaufman, and Adam Langley 1465 provided substantial feedback. The document is the result of 1466 collaboration with the TCP Authentication Design team (tcp-auth-dt). 1468 This document was prepared using 2-Word-v2.0.template.dot. 1470 16. References 1472 16.1. Normative References 1474 [RFC793] Postel, J., "Transmission Control Protocol," STD 007, RFC 1475 793, Standard, Sept. 1981. 1477 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 1478 Selective Acknowledgement Options", RFC 2018, Proposed 1479 Standard, April 1996. 1481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1482 Requirement Levels", BCP 14, RFC 2119, Best Current 1483 Practice, March 1997. 1485 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1486 Signature Option," RFC 2385, Proposed Standard, Aug. 1998. 1488 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 1489 and AH," RFC 2403, Proposed Standard, Nov. 1998. 1491 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 1492 (IPv6) Specification," RFC 2460, Proposed Standard, Dec. 1493 1998. 1495 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 1496 Conservative Selective Acknowledgment (SACK)-based Loss 1497 Recovery Algorithm for TCP", RFC 3517, Proposed Standard, 1498 April 2003. 1500 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC 1501 4306, Proposed Standard, Dec. 2005. 1503 16.2. Informative References 1505 [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem 1506 Statement and Requirements for a TCP Authentication 1507 Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 1508 2007. 1510 [Bo07] Bonica, R., et. al, "Authentication for TCP-based Routing 1511 and Management Protocols," draft-bonica-tcp-auth-06, (work 1512 in progress), Feb. 2007. 1514 [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 1515 attacks-04, (work in progress), Oct. 2008. 1517 [Je07] Jethanandani, M., and M. Bashyam, "TCP Robustness in 1518 Persist Condition," draft-mahesh-persist-timeout-02, (work 1519 in progress), Oct. 2007. 1521 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 1522 Informational, April 1992. 1524 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 1525 Hashing for Message Authentication," RFC 2104, 1526 Informational, Feb. 1997. 1528 [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - 1529 Protocol Translation (NAT-PT)," RFC 2766, Proposed 1530 Standard, Feb. 2000. 1532 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1533 Signature Option," RFC 3562, Informational, July 2003. 1535 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, 1536 "Negotiation of NAT-Traversal in the IKE," RFC 3947, Jan. 1537 2005. 1539 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 1540 Protocol," RFC 4301, Proposed Standard, Dec. 2005. 1542 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," RFC 1543 4808, Informational, Mar. 2007. 1545 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," 1546 RFC4953, Jul. 2007. 1548 [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP 1549 Congestion Control with a Misbehaving Receiver," ACM 1550 Computer Communications Review, V29, N5, pp71-78, October 1551 1999. 1553 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 1554 Specification SDN.401, Revision 1.2, July 12, 1988. 1556 [To??] Touch, J., A. Mankin, "The TCP Simple Authentication 1557 Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work 1558 in progress), Oct. 2006. 1560 [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash 1561 functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. 1563 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 1564 weis-tcp-mac-option-00, (expired work in progress), Dec. 1565 2005. 1567 [We07] Weis, B., et al., "Automated key selection extension for 1568 the TCP Authentication Option," draft-weis-tcp-auth-auto- 1569 ks-03, (work in progress), Oct. 2007. 1571 Author's Addresses 1573 Joe Touch 1574 USC/ISI 1575 4676 Admiralty Way 1576 Marina del Rey, CA 90292-6695 1577 U.S.A. 1579 Phone: +1 (310) 448-9151 1580 Email: touch@isi.edu 1581 URL: http://www.isi.edu/touch 1583 Allison Mankin 1584 Johns Hopkins Univ. 1585 Washington, DC 1586 U.S.A. 1588 Phone: 1 301 728 7199 1589 Email: mankin@psg.com 1590 URL: http://www.psg.com/~mankin/ 1592 Ronald P. Bonica 1593 Juniper Networks 1594 2251 Corporate Park Drive 1595 Herndon, VA 20171 1596 U.S.A. 1598 Email: rbonica@juniper.net 1600 Full Copyright Statement 1602 Copyright (C) The IETF Trust (2008). 1604 This document is subject to the rights, licenses and restrictions 1605 contained in BCP 78, and except as set forth therein, the authors 1606 retain all their rights. 1608 This document and the information contained herein are provided on an 1609 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1610 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1611 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1612 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1613 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1614 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1616 Intellectual Property Statement 1618 The IETF takes no position regarding the validity or scope of any 1619 Intellectual Property Rights or other rights that might be claimed to 1620 pertain to the implementation or use of the technology described in 1621 this document or the extent to which any license under such rights 1622 might or might not be available; nor does it represent that it has 1623 made any independent effort to identify any such rights. Information 1624 on the procedures with respect to rights in RFC documents can be 1625 found in BCP 78 and BCP 79. 1627 Copies of IPR disclosures made to the IETF Secretariat and any 1628 assurances of licenses to be made available, or the result of an 1629 attempt made to obtain a general license or permission for the use of 1630 such proprietary rights by implementers or users of this 1631 specification can be obtained from the IETF on-line IPR repository at 1632 http://www.ietf.org/ipr. 1634 The IETF invites any interested party to bring to its attention any 1635 copyrights, patents or patent applications, or other proprietary 1636 rights that may cover technology that may be required to implement 1637 this standard. Please address the information to the IETF at 1638 ietf-ipr@ietf.org.