idnits 2.17.1 draft-touch-tcpm-tcp-simple-auth-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 944. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 22, 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) == Outdated reference: A later version (-04) exists of draft-bellovin-keyroll2385-03 == Outdated reference: A later version (-01) exists of draft-bellovin-tcpsec-00 == Outdated reference: A later version (-06) exists of draft-bonica-tcp-auth-05 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-06) exists of draft-ietf-tcpm-tcp-antispoof-05 == Outdated reference: A later version (-03) exists of draft-weis-tcp-auth-auto-ks-01 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 Expires: April 2007 A. Mankin 4 October 22, 2006 6 The TCP Simple Authentication Option 7 draft-touch-tcpm-tcp-simple-auth-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 22, 2007. 35 Abstract 37 This document specifies a TCP Simple Authentication Option (TCP-SA) 38 which is intended to replace the TCP MD5 Signature option of RFC-2385 39 (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and 40 provides more details on the association of security associations 41 with TCP connections. TCP-SA assumes an external, out-of-band 42 mechanism (manual or via a separate protocol) for session key 43 establishment, parameter negotiation, and rekeying, replicating the 44 separation of key management and key use as in the IPsec suite. 46 The result is intended to be a simple modification to support current 47 infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to 48 support a larger set of hashes with minimal other system and 49 operational changes. TCP-SA requires no new option identifier, though 50 it is intended to be mutually exclusive with TCP/MD5 on a given TCP 51 connection. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [RFC2119]. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Executive Summary.........................................3 63 1.2. Changes from Previous Versions............................5 64 1.2.1. New in draft-touch-tcp-simple-auth-02................5 65 1.2.2. New in draft-touch-tcp-simple-auth-01................5 66 1.3. Summary of RFC-2119 Requirements..........................5 67 2. The TCP Simple Authentication Option...........................5 68 2.1. Review of TCP/MD5 Option..................................6 69 2.2. TCP-SA Option.............................................6 70 3. Security Association Management................................9 71 4. TCP-SA Interaction with TCP...................................11 72 4.1. User Interface...........................................11 73 4.2. TCP States and Transitions...............................12 74 4.3. TCP Segments.............................................12 75 4.4. Sending TCP Segments.....................................13 76 4.5. Receiving TCP Segments...................................13 77 4.6. Impact on TCP Header Size................................14 78 5. Key Establishment and Duration Issues.........................14 79 5.1. Implementing the TSAD as an External Database............15 80 6. Interactions with TCP/MD5.....................................16 81 7. Security Considerations.......................................17 82 8. IANA Considerations...........................................18 83 9. Conclusions...................................................18 84 10. Acknowledgments..............................................18 85 11. References...................................................18 86 11.1. Normative References....................................18 87 11.2. Informative References..................................19 88 Author's Addresses...............................................20 89 Intellectual Property Statement..................................20 90 Disclaimer of Validity...........................................21 91 Copyright Statement..............................................21 92 Acknowledgment...................................................21 94 1. Introduction 96 The TCP MD5 Signature (TCP/MD5) is a TCP option that authenticates 97 TCP segments, including the TCP pseudo-header, TCP header, and TCP 98 data. It was developed to protect BGP sessions from spoofed TCP 99 segments which could affect BGP data or the robustness of the TCP 100 connection itself [RFC2385][To06]. 102 There have been many recently-documented concerns about TCP/MD5. Its 103 use of a simple keyed hash for authentication is problematic because 104 there have been escalating attacks on the algorithm itself [Be05] 105 [Bu06]. TCP/MD5 also lacks both key management and algorithm 106 agility. This document proposes to add the latter, but suggests that 107 TCP should not be the framework for cryptographic key management. 108 This document updates the TCP/MD5 option to become a more general TCP 109 Simple Authentication Option (TCP-SA), to support the use of other, 110 stronger hash functions and to provide a more structured 111 recommendation on external key management. 113 This document is not intended to replace the use of the IPsec suite 114 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 115 fact, we recommend the use of IPsec and IKE, especially where IKE's 116 level of existing support for parameter negotiation, session key 117 negotiation, or rekeying are desired. TCP-SA is intended for use only 118 where the IPsec suite would not be feasible, e.g., as has been 119 suggested is the case for some routing protocols, or in cases where 120 keys need to be tightly coordinated with individual transport 121 sessions [Be06b]. 123 1.1. Executive Summary 125 This document updates TCP/MD5 as follows [RFC2385]: 127 o Reuses TCP/MD5's option Kind (=19), but allows TCP/MD5 to continue 128 to be used for other connections. 130 o Replaces signed MD5 with HMAC-MD5-96, and allows other MACs at the 131 implementer's discretion. 133 o Allows rekeying during a TCP connection, assuming that an out-of- 134 band protocol or manual mechanism coordinates the change of key 135 and that incorrectly keyed segments are ignored. In such cases, a 136 key ID may be used to make key selection more efficient. 138 o Provides more detail in how this option interacts with TCP's 139 states, event processing, and user interface. 141 o Proposed option is 4 bytes shorter (14 bytes overall, rather than 142 18) in the default case (HMAC-MD5-96). 144 This document differs from currently competing proposals to update 145 TCP/MD5 as follows [Bo06][We05][We06]: 147 o Does not require a new TCP option Kind value. 149 o Does not support dynamic parameter negotiation. 151 o Does not support in-band session key negotiation. 153 o Does not support in-band session rekeying. 155 o Does not require additional timers. 157 o Always authenticates the TCP options as well as the segment 158 pseudoheader, header, and data. 160 o Provides more detail in how this option interacts with TCP's 161 states, event processing, and user interface. 163 o Proposed option is 2 bytes shorter (14 bytes overall, rather than 164 16) in the default case (HMAC-MD5-96) 166 o Does not expose the MAC algorithm in the header. 168 o Does not require a key ID; it allows for one where key overlap is 169 desired to support efficient rekeying. 171 This document differs from an IPsec/IKE solution as follows 172 [RFC4301][RFC4306] 174 o Does not support dynamic parameter negotiation. 176 o Does not require a key ID (SPI), but does allow one. 178 o Does not protect from replay attacks. 180 o Forces a change of connection key when a connection restarts, even 181 when reusing a TCP socket pair (IP addresses and port numbers) 182 [Be06b]. 184 o Does not support encryption. 186 o Does not authenticate ICMP messages (some may be authenticated in 187 IPsec, depending on the configuration). 189 1.2. Changes from Previous Versions 191 [NOTE: to be omitted upon final publication as RFC] 193 1.2.1. New in draft-touch-tcp-simple-auth-02 195 o Add reference to Bellovin's need-for-TCP-auth doc [Be06b]. 197 o Add reference to SP4 [SDNS88]. 199 o Added notes that TSAD to be externally implemented; this was 200 compatible with the TSAD described in the previous version. 202 o Augmented the protocol to allow a KeyID, required to support 203 efficient overlapping keys during rekeying, and potentially useful 204 during connection establishment. Accommodated by redesigning the 205 TSAD. 207 o Added the odd/even indicator for the KeyID. 209 o Allow for the exclusion of all TCP options in the MAC calculation. 211 1.2.2. New in draft-touch-tcp-simple-auth-01 213 o Allows intra-session rekeying, assuming out-of-band coordination. 215 o MUST allow TSAD entries to change, enabling rekeying within a TCP 216 connection. 218 o Omits discussion of the impact of connection reestablishment on 219 BGP, because added support for rekeying renders this point moot. 221 o Adds further discussion on the need for rekeying. 223 1.3. Summary of RFC-2119 Requirements 225 [NOTE: a summary will be placed here prior to last call] 227 2. The TCP Simple Authentication Option 229 The TCP Simple Authentication Option (TCP-SA) re-uses the Kind value 230 currently assigned to TCP/MD5. 232 2.1. Review of TCP/MD5 Option 234 For review, the TCP/MD5 option is shown in Figure 1. 236 +---------+---------+-------------------+ 237 | Kind=19 |Length=18| MD5 digest... | 238 +---------+---------+-------------------+ 239 | | 240 +---------------------------------------+ 241 | | 242 +---------------------------------------+ 243 | | 244 +-------------------+-------------------+ 245 | | 246 +-------------------+ 248 Figure 1 Current TCP MD5 Option [RFC2385] 250 In the current TCP/MD5 option, the length is fixed, and the MD5 251 digest occupies 16 bytes following the Kind and Length fields, using 252 the full MD5 digest of 128 bits [RFC1321]. 254 The current TCP/MD5 option specifies the use of the MD5 digest 255 calculation over the following values in the following order: 257 1. the TCP pseudoheader (IP source and destination addresses, 258 protocol number, and segment length) 260 2. TCP header excluding options and checksum 262 3. TCP data 264 4. connection key 266 2.2. TCP-SA Option 268 The new TCP-SA option is intended to be a superset of the TCP/MD5 269 option, and minimal in the spirit of SP4 [SDNS88]. TCP-SA reuses the 270 same Kind and Length fields, and is shown in Figure 2. 272 +---------+---------+-----------------... 273 | Kind=19 | Len=var | MAF... ... 274 +---------+---------+-----------------... 276 Figure 2 Proposed TCP-SA Option 278 The TCP-SA defines the following fields: 280 o Kind: An unsigned field indicating the TCP-SA Option. TCP-SA 281 reuses the Kind value=19. Because of how keys are managed (see 282 Section 3), an endpoint will not use TCP-SA for the same 283 connection where TCP/MD5 is used, and so there would be no 284 confusion as to how to interpret incoming Kind=19 segments. 286 o Length: An unsigned 8-bit field indicating the length of the TCP- 287 SA option in bytes, including the Kind and Length fields. 289 >> The Length MUST be greater than or equal to 2. 291 >> The Length value MUST be consistent with the TCP header length. 293 Values of 2 and other small values are of dubious utility but not 294 specifically prohibited. See the MAF description for implications 295 of odd/even lengths. 297 o MAF: The MAF is a Message Authentication Field. Its contents are 298 determined by the particulars of the security association, where 299 there are two possible variants. When the Length is even, the 300 option appears as in Figure 3. When the Length is odd, the option 301 appears as in Figure 4. 303 +---------+---------+-------------------+ 304 | Kind=19 | Len=var | MAC | 305 +---------+---------+-------------------+ 306 | MAC (con't)... ... 307 +-------------------------------------... 309 Figure 3 TCP-SA MAF without key identifier 311 +---------+---------+-------------------+ 312 | Kind=19 | Len=var | MAC | 313 +---------+---------+-------------------+ 314 | MAC (con't)... ... 315 +-------------------+---------+-------... 317 ...-----------------+---------+ 318 ... MAC (con't) | KeyID | 319 ...-----------------+---------+ 321 Figure 4 TCP-SA MAF with key identifier 323 Typical MACs are 96-128 bits (12-16 bytes), but any length that 324 fits in the header of the segment being authenticated is allowed. 325 Because typical MACs are even-length, TCP-SA assumes so [RFC4306]. 326 If a particular MAC is odd-length, it is padded. 328 >> An odd-length MAC MUST be padded with a single 0x00 byte on 329 transmit. Setting this pad byte is considered part of the 330 authentication algorithm. 332 >> An odd-length MAC MUST have a trailing 0x00 pad byte on 333 receipt. Checking this pad byte is considered part of the 334 authentication algorithm. 336 When the Length is odd, a key identifier (KeyID) is included in 337 the last byte of the option. The KeyID is used to support 338 efficient key rollover during a connection and/or to help with key 339 coordination during connection establishment, and will be 340 discussed further in Sections 3. 342 >> TCP-SA MUST support HMAC-MD5-96; other MACs MAY be supported 343 [RFC2403]. 345 >> A single TCP segment MUST NOT have more than one TCP-SA option. 347 The MAC is defined over the following fields in the following order: 349 1. the TCP pseudoheader: IP source and destination addresses, zero- 350 padded protocol number and segment length, all in network byte 351 order, i.e., exactly as used for the TCP checksum [RFC793]: 353 +--------+--------+--------+--------+ 354 | Source Address | 355 +--------+--------+--------+--------+ 356 | Destination Address | 357 +--------+--------+--------+--------+ 358 | zero | Proto | TCP Length | 359 +--------+--------+--------+--------+ 361 Figure 5 TCP pseudoheader [RFC793] 363 2. TCP header, by default including options, and where the checksum 364 and TCP-SA MAC fields are set to zero, all in network byte order 366 3. TCP data 368 4. Connection key 369 TCP-SA by default includes the TCP options because these options are 370 intended to be end-to-end and some are required for proper TCP 371 operation (e.g., SACK, timestamp). Middleboxes may alter TCP options 372 en-route are a kind of attack and would be successfully detected by 373 default by TCP-SA. In cases where the configuration of the 374 connection's security association state indicates otherwise, the TCP 375 options can be excluded from the MAC calculation. 377 The TCP-SA option does not indicate the MAC algorithm either 378 implicitly (as with TCP/MD5) or explicitly (as with some proposed 379 alternatives) [RFC2385][Bo06][We05][We06]. The particular algorithm 380 used is considered part of the configuration state of the 381 connection's security association and is managed separately (see 382 Section 3). 384 3. Security Association Management 386 TCP-SA relies on a TCP Security Association Database (TSAD). TSAD 387 entries are assumed to be shared at the endpoints where TCP-SA is 388 used, in advance of the connection: 390 1. TCP connection identifier (ID), i.e., socket pair - IP source 391 address, IP destination address, TCP source port, and TCP 392 destination address [RFC793]. TSAD entries are uniquely determined 393 by their TCP connection ID. 395 2. For each of inbound (received TCP segments) and outbound (sent TCP 396 segments) on this connection: 398 a. TCP Option exclusion bit. A bit that, when set, indicates that 399 TCP options are excluded from all MAC calculations. When the 400 bit is clear, all TCP options are included. 402 >> The TCP Option exclusion bit MUST default to "clear". 404 >> The TCP Option exclusion bit MUST NOT change during a TCP 405 connection. 407 b. One or more connection key tuples. Each tuple consists of a 408 set as follows: 410 i. KeyID. A single byte used to differentiate overlapping 411 Connection keys. 413 ii. MAC type. Indicates the MAC used for this connection, as 414 per IKEv2 Transform Type 3 [RFC4306]. This includes the 415 MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and 416 the length of the MAC as computed (e.g., 96, 128, etc.). 417 Also, a setting of NONE must be supported, to indicate 418 that authentication is not used in this direction; this 419 allows asymmetric use of TCP-SA. At least one direction 420 (inbound/outbound) SHOULD have a non-NONE MAC in 421 practice, but this is not strictly required. 423 >> When the outbound MAC is set to values other than 424 NONE, TCP-SA MUST occur in every outbound TCP segment for 425 that connection; when set to NONE, TCP-SA MUST NOT occur 426 in those segments. 428 >> When the inbound MAC is set to values other than NONE, 429 TCP-SA MUST occur in every inbound TCP segment for that 430 connection; when set to NONE, TCP-SA MUST NOT occur in 431 those segments. 433 iii. Key length. A byte indicating the length of the 434 connection key in bytes. 436 iv. Connection key. A byte sequence used for connection 437 keying, this may be derived from a separate shared key by 438 an external protocol over a separate channel. 440 It is anticipated that TSAD entries for active or opening TCP 441 connections can be stored in the TCP Control Block (TCB) or in a 442 separate database (see Section 5.1 for notes on the latter); TSAD 443 entries for pending connections (in passive or active OPEN) may be 444 stored in a separate database. This means that in a single host there 445 should be only a single database which is consulted by all pending 446 connections, the same way that there is only one set of TCBs. 447 Multiple databases could be used to support virtual hosts, i.e., 448 groups of interfaces. 450 Note that TSAD and the TCP-SA fields may omit the KeyID; the TCP 451 connection ID already uniquely specifies the TSAD entry, so a 452 separate field is not needed to specify a key unless key overlay 453 during rekeying is supported or is needed for key coordination during 454 connection establishment (see Section 5). The TCP-SA fields omit an 455 explicit algorithm ID; that algorithm is already specified by the TCP 456 connection ID and stored in the TSAD. 458 Also note that this document does not address how TSAD entries are 459 created or destroyed. It is presumed that a TSAD entry affecting 460 particular connection cannot be destroyed during an active connection 461 - or, equivalently, that its parameters are copied local to the 462 connection and so changes would affect only new connections. The TSAD 463 could be managed by a separate application protocol, and can be 464 stored in a separate database if desired. 466 4. TCP-SA Interaction with TCP 468 The following is a description of how various TCP states, segments, 469 events, and interfaces. This description is intended to augment the 470 description of TCP as provided in RFC793 [RFC793]. 472 4.1. User Interface 474 The TCP user interface supports active and passive OPEN, SEND, 475 RECEIVE, CLOSE, STATUS and ABORT. 477 >> TCP OPEN, or the sequence of commands that configure a connection 478 to be in the active or passive OPEN state, MUST be augmented so that 479 a TSAD entry can be configured. 481 >> New TSAD entries MUST be checked against a cache of previously 482 used TSAD entries, and key reuse MUST be prohibited. 484 Users are advised to not inappropriately reuse keys [RFC3562]. 486 >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a 487 current or pending connection to be read (for confirmation). 489 >> TCP STATUS MUST allow TSAD entries for ongoing TCP connections 490 (i.e., not in the CLOSED state) to be modified. Parameters not used 491 to index a connection MAY be modified; parameters used to index a 492 connection MUST NOT be modified. 494 TSAD entries for TCP connections not in the CLOSED state are deleted 495 indirectly using the CLOSE or ABORT commands. 497 >> Use of CLOSE or ABORT MUST retain the TSAD entry in a cache to 498 assist with checking for key reuse. 500 This entry may correspond to one of the wait states of TCP (FINE- 501 WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT), or 502 may be stored separately (for connections proceeding rapidly to 503 CLOSED). The size of this cache and duration of retained entries is 504 up to the user, where we again advise the application of known key 505 management principles [RFC3562]. 507 TCP SEND and RECEIVE are not affected by TCP-SA. 509 4.2. TCP States and Transitions 511 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 512 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 513 CLOSED. 515 >> A TSAD entry MAY be associated with any TCP state. 517 >> A TSAD entry MAY underspecify the TCP connection for the LISTEN 518 state. Such an entry MUST NOT be used for more than one connection 519 progressing out of the LISTEN state. 521 4.3. TCP Segments 523 TCP includes control (at least one of SYN, FIN, RST flags set) and 524 data (none of SYN, FIN, or RST flags set) segments. 526 >> All TCP segments MUST be checked against the TSAD for matching TCP 527 connection IDs. 529 >> TCP segments matching TSAD entries with non-NULL MACs without TCP- 530 SA, or with TCP-SA and whose MACs and/or KeyIDs (the latter when in 531 use) do not validate MUST be silently discarded. 533 >> TCP segments with TCP-SA but not matching TSAD entries MUST be 534 silently accepted. 536 >> Silent discard events SHOULD be signaled to the user as a warning, 537 and silent accept events MAY be signaled to the user as a warning. 538 Both warnings, if available, MUST be accessible via the STATUS 539 interface. Either signal MAY be asynchronous, but if so they MUST be 540 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 541 limiting as well. 543 All TCP-SA processing occurs between the interface of TCP and IP; for 544 incoming segments, this occurs after validation of the TCP checksum. 545 For outgoing segments, this occurs before computation of the TCP 546 checksum. 548 Note that the TCP-SA option is not negotiated. It is the 549 responsibility of the receiver to determine when TCP-SA is required 550 and to enforce that requirement. 552 >> Receivers MAY silently accept TCP segments with the TCP-SA option. 554 4.4. Sending TCP Segments 556 The following procedure describes the modifications to TCP to support 557 TCP-SA when a segment departs. 559 1. Check the segment's TCP connection ID against the TSAD 561 2. If there is NO TSAD entry, omit the TCP-SA option. Proceed with 562 computing the TCP checksum and transmit the segment. 564 3. If there is a TSAD entry and the outgoing MAC is NONE, omit the 565 TCP-SA option. Proceed with computing the TCP checksum and 566 transmit the segment. 568 4. If there is a TSAD entry and the outgoing MAC is not NONE: 570 a. Augment the TCP header with the TCP-SA, inserting the 571 appropriate Length and KeyID (the latter only if Length is 572 odd) based on the indexed TSAD entry. Update the TCP header 573 length accordingly. 575 b. Compute the MAC using the indexed TSAD connection key, MAC, 576 and data from the segment as specified in Section 2.2. 578 c. Insert the MAC in the TCP-SA field. 580 d. Proceed with computing the TCP checksum and transmit the 581 segment. 583 4.5. Receiving TCP Segments 585 The following procedure describes the modifications to TCP to support 586 TCP-SA when a segment arrives. 588 1. Check the segments TCP connection ID against the TSAD 590 2. If there is NO TSAD entry, proceed with TCP processing. 592 3. If there is a TSAD entry and the incoming MAC is NONE, proceed 593 with TCP processing. 595 4. If there is a TSAD entry and the incoming MAC is not NONE: 597 a. Check that the segment's TCP-SA Length matches the length 598 indicated by the indexed TSAD. 600 i. If Lengths differ, silently discard the segment. Log 601 and/or signal the event as indicated in Section 4.3. 603 b. If the Length is odd, use the KeyID value to index the 604 appropriate key for this connection 606 i. If the TSAD has no entry corresponding to the segment's 607 KeyID, silently discard the segment. 609 c. Compute the segment's MAC using the indexed TSAD MAC algorithm 610 and connection key, and portions of the segment as indicated 611 in Section 2.2. 613 i. If the computed MAC differs from the TCP-SA MAC field 614 value, silently discard the segment. Log and/or signal 615 the event as indicated in Section 4.3. 617 d. Proceed with TCP processing of the segment. 619 It is suggested that TCP-SA implementations validate a segment's 620 Length field before computing a MAC, to reduce the overhead incurred 621 by spoofed segments with invalid TCP-SA fields. 623 4.6. Impact on TCP Header Size 625 The TCP-SA option typically uses a total of 16-18 bytes of TCP header 626 space. TCP-SA is no larger than and typically 2 bytes smaller than 627 the TCP/MD5 option. Although TCP option space is limited, we believe 628 TCP-SA is consistent with the desire to authenticate TCP at the 629 connection level for similar uses as were intended by TCP/MD5. 631 5. Key Establishment and Duration Issues 633 The TCP-SA option does not provide a mechanism for connection key 634 negotiation or parameter negotiation (MAC algorithm, length, or use 635 of the TCP-SA option) or rekeying during a connection. We assume out- 636 of-band mechanisms for key establishment, parameter negotiation, and 637 rekeying. This separation of key use from key management is similar 638 to that in the IPsec security suite [RFC4301][RFC4306]. 640 We encourage users of TCP-SA to apply known techniques for generating 641 appropriate keys, including the use of reasonable connection key 642 lengths, limited connection key sharing, and limiting the duration of 643 connection key use [RFC3562]. 645 TCP-SA supports rekeying in which new keys are negotiated out-of- 646 band, either via a protocol or a manual procedure [Be06a]. New keys 647 use is coordinated using the out-of-band mechanism to update the LSAD 648 at both TCP endpoints. In the default case, where only a single key 649 is used at a time, the temporary use of invalid keys would result in 650 packets being dropped; TCP is already robust to such drops. Such 651 drops may affect TCP's throughput temporarily, as a result TCP-SA 652 benefits from the use of congestion control support for temporary 653 path outages. 655 >> TCP-SA SHOULD be deployed in conjunction with support for 656 selective acknowledgement (SACK), including support for multiple lost 657 segments in the same round trip [RFC2018][RFC3517]. 659 Note that TCP-SA's support for rekeying is designed to be minimal in 660 the default case. Segments carry only enough context to identify the 661 security association [RFC4301][RFC4306]. In TCP-SA, this context is 662 provided by the socket pair (IP addresses and ports for source and 663 destination). In the default case, the key is identified only in the 664 LSAD, and coordinated by a separate mechanism not specified in TCP- 665 SA. In cases where such coordination is difficult, or where loss 666 during rekeying is inappropriate, the TSAD can contain multiple 667 concurrent keys. Where multiple keys are used, the KeyID field is 668 used to identify the key that corresponds to a segment, to avoid the 669 need for expensive trial-and-error testing of keys in sequence. 671 The KeyID field may also be useful in coordinating keys for new 672 connections. A TSAD may be configured that matches the unbound source 673 port, which would return a set of possible keys. The KeyID would then 674 indicate which key, allowing more efficient connection establishment; 675 otherwise, the keys could be tried in sequence. See also Section 5.1. 677 Implementations are encouraged to keep keys in a suitably private 678 area. Users of TCP-SA are encouraged to use different keys for 679 inbound and outbound MACs on a given TCP connection. 681 5.1. Implementing the TSAD as an External Database 683 The TSAD implementation is considered external to TCP-SA. When an 684 external database is used, it would be useful to consider the 685 interface between TCP-SA and the TSAD. The following is largely a 686 restatement of information in Section 3. 688 TSAD entries are indexed during a connection as follows: 690 o TCP connection identifier (The socket pair, sent as 4 byte IP 691 source address, 4 byte IP destination address, 2 byte TCP source 692 port, 2 byte TCP destination port) 694 o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 = 695 outbound) 697 o Number of bytes to be sent/received (two bytes) 699 o KeyID (single byte, optional, 0x00 when not present) 701 The call passes the number of bytes sent/received, and an indication 702 of the direction (send/receive), to enable traffic-based key 703 rollover. 705 The source port can be 'unbound', indicated by the value 0x0000. In 706 this case, the source port is considered a wildcard, and all 707 corresponding TSAD entries (typically also indexed by the KeyID in 708 that case) are returned as a list. This feature is used during 709 connection establishment. 711 TSAD calls return the following parameters: 713 o TCP Option exclusion indicator bit (one bit, passed as a byte with 714 value 0x00 or 0x01). 716 o Zero or more connection key tuples: 717 719 o KeyID (one byte, ignored if the KeyID is not present or 0x00) 721 o MAC type (two bytes) 723 o Key length (one byte) 725 o Connection key (byte sequence, indicating the key value) 727 When the TSAD returns zero keys, it is indicating that there are no 728 currently valid keys for the connection. 730 6. Interactions with TCP/MD5 732 TCP-SA is intended to be deployed without regard for existing TCP/MD5 733 option support. 735 >> A TCP implementation MUST NOT use both TCP-SA and TCP/MD5 for a 736 particular TCP connection, but MAY support TCP-SA and TCP/MD5 737 simultaneously for different connections. 739 There is no need to explicitly indicate which of TCP-SA or TCP/MD5 is 740 used for a particular connection in the TCP segments. Even where the 741 two used the same hash (e.g., if TCP-SA were to use MD5 rather than 742 HMAC-MD5) and the same length (128 bits), TCP-SA computes its MAC 743 over different data (including the TCP-SA option, notably, with the 744 MAC zeroed) than TCP/MD5. The probability of a TCP-SA segment being 745 validated by TCP/MD5 or the converse is roughly equivalent to that of 746 a random party guessing a valid MAC. 748 7. Security Considerations 750 Use of TCP-SA, like use of TCP/MD5 or IPsec, will impact host 751 performance. Connections that are known to use TCP-SA can be attacked 752 by transmitting segments with invalid MACs. Attackers would need to 753 know only the TCP connection ID and TCP-SA Length value to 754 substantially impact the host's processing capacity. This is similar 755 to the susceptibility of IPsec to on-path attacks, where the IP 756 addresses and SPI would be visible. For IPsec, the entire SPI space 757 (32 bits) is arbitrary, whereas for routing protocols typically only 758 the source port (16 bits) is arbitrary. As a result, it would be 759 easier for an off-path attacker to spoof a TCP-SA segment that could 760 cause receiver validation effort. However, we note that between 761 Internet routers both ports could be arbitrary (i.e., determined a- 762 priori out of band), which would constitute roughly the same off-path 763 antispoofing protection of an arbitrary SPI. 765 TCP-SA, like TCP/MD5, may inhibit connectionless resets. Such resets 766 typically occur after peer crashes, either in response to new 767 connection attempts or when data is sent on stale connections; in 768 either case, the recovering endpoint may lack the connection key 769 required (e.g., if lost during the crash). This may result in time- 770 outs, rather than more responsive recovery after such a crash. 772 TCP-SA does not expose the MAC algorithm used to authenticate a 773 particular connection; that information is kept in the TSAD at the 774 endpoints, and is not indicated in the header. 776 TCP-SA is intended to provide similar protections to IPsec, but is 777 not intended to replace the use of IPsec or IKE either for more 778 robust security or more sophisticated security management. 780 TCP-SA does not address the issue of ICMP attacks on TCP. IPsec makes 781 recommendations regarding dropping ICMPs in certain contexts, or 782 requiring that they are endpoint authenticated in others [RFC4301]. 783 There are other mechanisms proposed to reduce the impact of ICMP 784 attacks by further validating ICMP contents and changing the effect 785 of some messages based on TCP state, but these do not provide the 786 level of authentication for ICMP that TCP-SA provides for TCP [Go06]. 788 >> A TCP-SA implementation MUST allow the system administrator to 789 configure whether TCP will ignore incoming ICMP messages of Type 3 790 Codes 2-4 intended for connections that match TSAD entries with non- 791 NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be 792 logged. 794 This control affects only ICMPs that currently require 'hard errors' 795 which would abort the TCP connection. This recommendation is intended 796 to be similar to how IPsec would handle those messages [RFC4301]. 798 8. IANA Considerations 800 The TCP-SA option reuses the TCP MD5 Signature option (TCP/MD5), 801 where Kind=19. This document augments that use of this Kind value, 802 but there is no need to deprecate or override the use of TCP/MD5. 803 This document suggests that only one key algorithm would be 804 applicable in either case, and so there would be no confusion for a 805 given Length and key value as used for authenticating segments of a 806 given TCP connection. 808 If this document is approved as an IETF Standard, IANA is requested 809 to add a registration for TCP-SA to Kind=19, along with the existing 810 registration for TCP/MD5, and add a pointer to this document. 812 9. Conclusions 814 (to be completed) 816 10. Acknowledgments 818 This document was inspired by the revisions to TCP/MD5 suggested by 819 Brian Weis and Ron Bonica [Bo06][We05]. Russ Housley suggested 820 L4/application layer management of the TSAD. The KeyID field was 821 motivated by Steve Bellovin. 823 11. References 825 11.1. Normative References 827 [RFC793] Postel, J., "Transmission Control Protocol," STD-007, RFC- 828 793, Standard, Sept. 1981. 830 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 831 Selective Acknowledgement Options", RFC 2018, Proposed 832 Standard, April 1996. 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, Best Current 836 Practice, March 1997. 838 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 839 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 841 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 842 Conservative Selective Acknowledgment (SACK)-based Loss 843 Recovery Algorithm for TCP", RFC 3517, Proposed Standard, 844 April 2003. 846 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 847 and AH," RFC-2403, Proposed Standard, Nov. 1998. 849 11.2. Informative References 851 [Be05] Bellovin, S., E. Rescorla, "Deploying a New Hash 852 Algorithm," presented at the First NIST Cryptographic Hash 853 Workshop, Oct. 2005. 854 http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm 856 [Be06a] Bellovin, S., "Key Change Strategies for TCP-MD5," draft- 857 bellovin-keyroll2385-03.txt, (work in progress), Sept. 858 2006. 860 [Be06b] Bellovin, S., "Towards a TCP Security Option," draft- 861 bellovin-tcpsec-00.txt, (work in progress), Oct. 2006. 863 [Bu06] Burr, B., "NIST Cryptographic Standards Status Report," 864 Invited talk at Internet 2 5th Annual PKI R&D Workshop, 865 April 2006. 866 http://middleware.internet2.edu/pki06/proceedings/ 868 [Bo06] Bonica, R., "Authentication for TCP-based Routing and 869 Management Protocols," draft-bonica-tcp-auth-05, (work in 870 progress), Jul. 2006. 872 [Go06] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 873 attacks-00.txt, (expired work in progress), Feb. 2006. 875 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 876 Informational, April 1992. 878 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 879 Signature Option," RFC-3562, Informational, July 2003. 881 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 882 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 884 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC- 885 4306, Proposed Standard, Dec. 2005. 887 [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," 888 Specification SDN.401, Revision 1.2, July 12, 1988. 890 [To06] Touch, J., "Defending TCP Against Spoofing Attacks," draft- 891 ietf-tcpm-tcp-antispoof-05.txt, (work in progress), Oct. 892 2006. 894 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 895 weis-tcp-mac-option-00.txt, (expired work in progress), 896 Dec. 2005. 898 [We06] Weis, B., "Automated key selection extension for the TCP 899 Authentication Option," draft-weis-tcp-auth-auto-ks-01, 900 (work in progress), Feb. 2006. 902 Author's Addresses 904 Joe Touch 905 USC/ISI 906 4676 Admiralty Way 907 Marina del Rey, CA 90292-6695 908 U.S.A. 910 Phone: +1 (310) 448-9151 911 Email: touch@isi.edu 912 URL: http://www.isi.edu/touch 914 Allison Mankin 915 Washington, DC 916 U.S.A. 918 Phone: 1 301 728 7199 919 Email: mankin@psg.com 920 URL: http://www.psg.com/~mankin/ 922 Intellectual Property Statement 924 The IETF takes no position regarding the validity or scope of any 925 Intellectual Property Rights or other rights that might be claimed to 926 pertain to the implementation or use of the technology described in 927 this document or the extent to which any license under such rights 928 might or might not be available; nor does it represent that it has 929 made any independent effort to identify any such rights. Information 930 on the procedures with respect to rights in RFC documents can be 931 found in BCP 78 and BCP 79. 933 Copies of IPR disclosures made to the IETF Secretariat and any 934 assurances of licenses to be made available, or the result of an 935 attempt made to obtain a general license or permission for the use of 936 such proprietary rights by implementers or users of this 937 specification can be obtained from the IETF on-line IPR repository at 938 http://www.ietf.org/ipr. 940 The IETF invites any interested party to bring to its attention any 941 copyrights, patents or patent applications, or other proprietary 942 rights that may cover technology that may be required to implement 943 this standard. Please address the information to the IETF at 944 ietf-ipr@ietf.org. 946 Disclaimer of Validity 948 This document and the information contained herein are provided on an 949 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 950 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 951 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 952 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 953 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 954 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 956 Copyright Statement 958 Copyright (C) The Internet Society (2006). 960 This document is subject to the rights, licenses and restrictions 961 contained in BCP 78, and except as set forth therein, the authors 962 retain all their rights. 964 Acknowledgment 966 Funding for the RFC Editor function is currently provided by the 967 Internet Society.