idnits 2.17.1 draft-touch-tcpm-tcp-simple-auth-01.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 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** 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 (June 25, 2006) is 6486 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-00 == Outdated reference: A later version (-06) exists of draft-bonica-tcp-auth-04 == 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-04 == Outdated reference: A later version (-03) exists of draft-weis-tcp-auth-auto-ks-00 Summary: 6 errors (**), 0 flaws (~~), 7 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: December 2006 A. Mankin 4 June 25, 2006 6 The TCP Simple Authentication Option 7 draft-touch-tcpm-tcp-simple-auth-01.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 December 25, 2006. 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-01................5 65 1.3. Summary of RFC-2119 Requirements..........................5 66 2. The TCP Simple Authentication Option...........................5 67 2.1. Review of TCP/MD5 Option..................................5 68 2.2. TCP-SA Option.............................................6 69 3. Security Association Management................................8 70 4. TCP-SA Interaction with TCP....................................9 71 4.1. User Interface............................................9 72 4.2. TCP States and Transitions...............................10 73 4.3. TCP Segments.............................................10 74 4.4. Sending TCP Segments.....................................11 75 4.5. Receiving TCP Segments...................................11 76 4.6. Impact on TCP Header Size................................12 77 5. Key Establishment and Duration Issues.........................12 78 6. Interactions with TCP/MD5.....................................13 79 7. Security Considerations.......................................13 80 8. IANA Considerations...........................................15 81 9. Conclusions...................................................15 82 10. Acknowledgments..............................................15 83 11. References...................................................15 84 11.1. Normative References....................................15 85 11.2. Informative References..................................16 86 Author's Addresses...............................................17 87 Intellectual Property Statement..................................17 88 Disclaimer of Validity...........................................18 89 Copyright Statement..............................................18 90 Acknowledgment...................................................18 92 1. Introduction 94 The TCP MD5 Signature (TCP/MD5) is a TCP option that authenticates 95 TCP segments, including the TCP pseudo-header, TCP header, and TCP 96 data. It was developed to protect BGP sessions from spoofed TCP 97 segments which could affect BGP data or the robustness of the TCP 98 connection itself [RFC2385][To06]. 100 There have been many recently-documented concerns about TCP/MD5. Its 101 use of a simple keyed hash for authentication is problematic because 102 there have been escalating attacks on the algorithm itself [Be05] 103 [Bu06]. TCP/MD5 also lacks both key management and algorithm 104 agility. This document proposes to add the latter, but suggests that 105 TCP should not be the framework for cryptographic key management. 106 This document updates the TCP/MD5 option to become a more general TCP 107 Simple Authentication Option (TCP-SA), to support the use of other, 108 stronger hash functions and to provide a more structured 109 recommendation on external key management. 111 This document is not intended to replace the use of the IPsec suite 112 (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In 113 fact, we recommend the use of IPsec and IKE, especially where IKE's 114 level of existing support for parameter negotiation, session key 115 negotiation, or rekeying are desired. TCP-SA is intended for use only 116 where the IPsec suite would not be feasible, e.g., as has been 117 suggested is the case for some routing protocols. 119 1.1. Executive Summary 121 This document updates TCP/MD5 as follows [RFC2385]: 123 o Reuses TCP/MD5's option Kind (=19), but allows TCP/MD5 to continue 124 to be used for other connections. 126 o Replaces signed MD5 with HMAC-MD5-96, and allows other MACs at the 127 implementer's discretion. 129 o Allows rekeying during a TCP connection, assuming only that an 130 out-of-band protocol or manual mechanism loosely coordinates the 131 change of key and that incorrectly keyed segments are ignored. 133 o Provides more detail in how this option interacts with TCP's 134 states, event processing, and user interface. 136 o Proposed option is 4 bytes shorter (14 bytes overall, rather than 137 18) in the default case (HMAC-MD5-96). 139 This document differs from currently competing proposals to update 140 TCP/MD5 as follows [Bo06][We05][We06]: 142 o Does not require a new TCP option Kind value. 144 o Does not support dynamic parameter negotiation. 146 o Does not support in-band session key negotiation. 148 o Does not support in-band session rekeying. 150 o Does not require additional timers. 152 o Always authenticates the TCP options as well as the segment 153 pseudoheader, header, and data. 155 o Provides more detail in how this option interacts with TCP's 156 states, event processing, and user interface. 158 o Proposed option is 2 bytes shorter (14 bytes overall, rather than 159 16) in the default case (HMAC-MD5-96) 161 o Does not expose the MAC algorithm in the header. 163 o Does not require a key ID. 165 This document differs from an IPsec/IKE solution as follows 166 [RFC4301][RFC4306] 168 o Does not support dynamic parameter negotiation. 170 o Does not support establishment of a per-connection key. 172 o Does not require a key ID (SPI). 174 o Does not protect from replay attacks. 176 o Forces a change of connection key when a connection restarts, even 177 when reusing a TCP socket pair (IP addresses and port numbers). 179 o Does not support encryption. 181 o Does not authenticate ICMP messages (some may be authenticated in 182 IPsec, depending on the configuration). 184 1.2. Changes from Previous Versions 186 [NOTE: to be omitted upon final publication as RFC] 188 1.2.1. New in draft-touch-tcp-simple-auth-01 190 o Allows intra-session rekeying, assuming out-of-band coordination. 192 o MUST allow TSAD entries to change, enabling rekeying within a TCP 193 connection. 195 o Omits discussion of the impact of connection reestablishment on 196 BGP, because added support for rekeying renders this point moot. 198 o Adds further discussion on the need for rekeying. 200 1.3. Summary of RFC-2119 Requirements 202 [NOTE: a summary will be placed here prior to last call] 204 2. The TCP Simple Authentication Option 206 The TCP Simple Authentication Option (TCP-SA) re-uses the Kind value 207 currently assigned to TCP/MD5. 209 2.1. Review of TCP/MD5 Option 211 For review, the TCP/MD5 option is shown in Figure 1. 213 +---------+---------+-------------------+ 214 | Kind=19 |Length=18| MD5 digest... | 215 +---------+---------+-------------------+ 216 | | 217 +---------------------------------------+ 218 | | 219 +---------------------------------------+ 220 | | 221 +-------------------+-------------------+ 222 | | 223 +-------------------+ 225 Figure 1 Current TCP MD5 Option [RFC2385] 227 In the current TCP/MD5 option, the length is fixed, and the MD5 228 digest occupies 16 bytes following the Kind and Length fields, using 229 the full MD5 digest of 128 bits [RFC1321]. 231 The current TCP/MD5 option specifies the use of the MD5 digest 232 calculation over the following values in the following order: 234 1. the TCP pseudoheader (IP source and destination addresses, 235 protocol number, and segment length) 237 2. TCP header excluding options and checksum 239 3. TCP data 241 4. connection key 243 2.2. TCP-SA Option 245 The new TCP-SA option is intended to be a superset of the TCP/MD5 246 option. TCP-SA reuses the same Kind and Length fields, and is shown 247 in Figure 2. 249 +---------+---------+-----------------... 250 | Kind=19 | Len=var | MAC... ... 251 +---------+---------+-----------------... 253 Figure 2 Proposed TCP-SA Option 255 The TCP-SA defines the following fields: 257 o Kind: An unsigned field indicating the TCP Option. TCP-SA reuses 258 the Kind value=19. Because of how keys are managed (see Section 259 3), an endpoint will not use TCP-SA for the same connection where 260 TCP/MD5 is used, and so there would be no confusion as to how to 261 interpret incoming Kind=19 segments. 263 o Length: An unsigned 8-bit field indicating the length of the TCP- 264 SA option in bytes, including the Kind and Length fields. 266 >> The Length MUST be greater than or equal to 2. 268 >> The Length value MUST be consistent with the TCP header length. 270 Values of 2 and other small values are of dubious utility but not 271 specifically prohibited. 273 o MAC: The MAC is a message authentication code. Typical MACs are 274 96-128 bits (12-16 bytes), but any length that fits in the header 275 of the segment being authenticated is allowed. 277 >> TCP-SA MUST support HMAC-MD5-96; other MACs MAY be supported 278 [RFC2403]. 280 >> A single TCP segment MUST NOT have more than one TCP-SA option. 282 The MAC is defined over the following fields in the following order: 284 1. the TCP pseudoheader: IP source and destination addresses, zero- 285 padded protocol number and segment length, all in network byte 286 order, i.e., exactly as used for the TCP checksum [RFC793]: 288 +--------+--------+--------+--------+ 289 | Source Address | 290 +--------+--------+--------+--------+ 291 | Destination Address | 292 +--------+--------+--------+--------+ 293 | zero | PTCL | TCP Length | 294 +--------+--------+--------+--------+ 296 Figure 3 TCP pseudoheader [RFC793] 298 2. TCP header, including options, and where the checksum and TCP-SA 299 MAC fields are set to zero, all in network byte order 301 3. TCP data 303 4. Connection key: a key to be used to in the MAC algorithm, as 304 required by the particular MAC algorithm used 306 TCP-SA includes the TCP options because these options are intended to 307 be end-to-end and some are required for proper TCP operation (e.g., 308 SACK, timestamp). Middleboxes may alter TCP options en-route are a 309 kind of attack and would be successfully detected by TCP-SA. 311 The TCP-SA option does not indicate the MAC algorithm either 312 implicitly (as with TCP/MD5) or explicitly (as with some proposed 313 alternatives) [RFC2385][Bo06][We05][We06]. The particular algorithm 314 used is considered part of the configuration state of the security 315 association of the connection and is managed separately (see Section 316 3). 318 3. Security Association Management 320 TCP-SA relies on a TCP Security Association Database (TSAD). TSAD 321 entries are assumed to be shared at the endpoints where TCP-SA is 322 used, in advance of the connection: 324 1. TCP connection identifier (ID), i.e., socket pair - IP source 325 address, IP destination address, TCP source port, and TCP 326 destination address [RFC793]. TSAD entries are uniquely determined 327 by their TCP connection ID. 329 2. For each of inbound (received TCP segments) and outbound (sent TCP 330 segments) on this connection: 332 a. MAC type for this connection. This includes the MAC algorithm 333 (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and the length of the 334 MAC stored in the option (e.g., 96, 128, etc.). Also, a 335 setting of NONE must be supported, to indicate that 336 authentication is not used in this direction; this allows 337 asymmetric use of TCP-SA. At least one direction 338 (inbound/outbound) SHOULD have a non-NONE MAC in practice, but 339 this is not strictly required. 341 >> When the outbound MAC is set to values other than NONE, 342 TCP-SA MUST occur in every outbound TCP segment for that 343 connection; when set to NONE, TCP-SA MUST NOT occur in those 344 segments. 346 >> When the inbound MAC is set to values other than NONE, TCP- 347 SA MUST occur in every inbound TCP segment for that 348 connection; when set to NONE, TCP-SA MUST NOT occur in those 349 segments. 351 b. Connection key. A byte sequence used for connection keying, 352 this is intended to be a per-connection key, and may be 353 derived from a separate shared key by an external protocol 354 over a separate channel. 356 It is anticipated that TSAD entries for active or opening TCP 357 connections can be stored in the TCP Control Block (TCB); TSAD 358 entries for pending connections (in passive or active OPEN) may be 359 stored in a separate database. This means that in a single host there 360 should be only a single database which is consulted by all pending 361 connections, the same way that there is only one set of TCBs. 362 Multiple databases could be used to support virtual hosts, i.e., 363 groups of interfaces. 365 Note that TSAD and the TCP-SA fields omit a key ID; the TCP 366 connection ID already uniquely specifies the TSAD entry, so a 367 separate ID is not needed. The TCP-SA fields omit an explicit 368 algorithm ID; that algorithm is already specified by the TCP 369 connection ID and stored in the TSAD. 371 Also note that this document does not address how TSAD entries are 372 created or destroyed. It is presumed that a TSAD entry affecting 373 particular connection cannot be destroyed during an active connection 374 - or, equivalently, that its parameters are copied local to the 375 connection and so changes would affect only new connections. The TSAD 376 could be managed by a separate application protocol if desired. 378 4. TCP-SA Interaction with TCP 380 The following is a description of how various TCP states, segments, 381 events, and interfaces. This description is intended to augment the 382 description of TCP as provided in RFC793 [RFC793]. 384 4.1. User Interface 386 The TCP user interface supports active and passive OPEN, SEND, 387 RECEIVE, CLOSE, STATUS and ABORT. 389 >> TCP OPEN, or the sequence of commands that configure a connection 390 to be in the active or passive OPEN state, MUST be augmented so that 391 a TSAD entry can be configured. 393 >> New TSAD entries MUST be checked against a cache of previously 394 used TSAD entries, and key reuse MUST be prohibited. 396 Users are advised to not inappropriately reuse keys [RFC3562]. 398 >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a 399 current or pending connection to be read (for confirmation). 401 >> TCP STATUS MUST allow TSAD entries for ongoing TCP connections 402 (i.e., not in the CLOSED state) to be modified. Parameters not used 403 to index a connection MAY be modified; parameters used to index a 404 connection MUST NOT be modified. 406 TSAD entries for TCP connections not in the CLOSED state are deleted 407 indirectly using the CLOSE or ABORT commands. 409 >> Use of CLOSE or ABORT MUST retain the TSAD entry in a cache to 410 assist with checking for key reuse. 412 This entry may correspond to one of the wait states of TCP (FINE- 413 WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT), or 414 may be stored separately (for connections proceeding rapidly to 415 CLOSED). The size of this cache and duration of retained entries is 416 up to the user, where we again advise the application of known key 417 management principles [RFC3562]. 419 TCP SEND and RECEIVE are not affected by TCP-SA. 421 4.2. TCP States and Transitions 423 TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, 424 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and 425 CLOSED. 427 >> A TSAD entry MAY be associated with any TCP state. 429 >> A TSAD entry MAY underspecify the TCP connection for the LISTEN 430 state. Such an entry MUST NOT be used for more than one connection 431 progressing out of the LISTEN state. 433 4.3. TCP Segments 435 TCP includes control (at least one of SYN, FIN, RST flags set) and 436 data (none of SYN, FIN, or RST flags set) segments. 438 >> All TCP segments MUST be checked against the TSAD for matching TCP 439 connection IDs. 441 >> TCP segments matching TSAD entries with non-NULL MACs without TCP- 442 SA, or with TCP-SA and whose MACs do not validate MUST be silently 443 discarded. 445 >> TCP segments with TCP-SA but not matching TSAD entries MUST be 446 silently accepted. 448 >> Silent discard events SHOULD be signaled to the user as a warning, 449 and silent accept events MAY be signaled to the user as a warning. 450 Both warnings, if available, MUST be accessible via the STATUS 451 interface. Either signal MAY be asynchronous, but if so they MUST be 452 rate-limited. Either signal MAY be logged; logging SHOULD allow rate- 453 limiting as well. 455 All TCP-SA processing occurs between the interface of TCP and IP; for 456 incoming segments, this occurs after validation of the TCP checksum. 457 For outgoing segments, this occurs before computation of the TCP 458 checksum. 460 Note that the TCP-SA option is not negotiated. It is the 461 responsibility of the receiver to determine when TCP-SA is required 462 and to enforce that requirement. 464 >> Receivers MAY silently accept TCP segments with the TCP-SA option. 466 4.4. Sending TCP Segments 468 The following procedure describes the modifications to TCP to support 469 TCP-SA when a segment departs. 471 1. Check the segment's TCP connection ID against the TSAD 473 2. If there is NO TSAD entry, omit the TCP-SA option. Proceed with 474 computing the TCP checksum and transmit the segment. 476 3. If there is a TSAD entry and the outgoing MAC is NONE, omit the 477 TCP-SA option. Proceed with computing the TCP checksum and 478 transmit the segment. 480 4. If there is a TSAD entry and the outgoing MAC is not NONE: 482 a. Augment the TCP header with the TCP-SA, inserting the 483 appropriate Length based on the indexed TSAD entry. Update the 484 TCP header length accordingly. 486 b. Compute the MAC using the indexed TSAD connection key, MAC, 487 and data from the segment as specified in Section 2.2. 489 c. Insert the MAC in the TCP-SA field. 491 d. Proceed with computing the TCP checksum and transmit the 492 segment. 494 4.5. Receiving TCP Segments 496 The following procedure describes the modifications to TCP to support 497 TCP-SA when a segment arrives. 499 1. Check the segments TCP connection ID against the TSAD 501 2. If there is NO TSAD entry, proceed with TCP processing. 503 3. If there is a TSAD entry and the incoming MAC is NONE, proceed 504 with TCP processing. 506 4. If there is a TSAD entry and the incoming MAC is not NONE: 508 a. Check that the segment's TCP-SA Length matches the indexed 509 TSAD Length. 511 i. If Lengths differ, silently discard the segment. Log 512 and/or signal the event as indicated in Section 4.3. 514 b. Compute the segment's MAC using the indexed TSAD MAC algorithm 515 and connection key, and portions of the segment as indicated 516 in Section 2.2. 518 i. If the computed MAC differs from the TCP-SA MAC field 519 value, silently discard the segment. Log and/or signal 520 the event as indicated in Section 4.3. 522 c. Proceed with TCP processing of the segment. 524 It is suggested that TCP-SA implementations validate a segment's 525 Length field before computing a MAC, to reduce the overhead incurred 526 by spoofed segments with invalid TCP-SA fields. 528 4.6. Impact on TCP Header Size 530 The TCP-SA option typically uses a total of 16-18 bytes of TCP header 531 space. TCP-SA is no larger than and typically 2 bytes smaller than 532 the TCP/MD5 option. Although TCP option space is limited, we believe 533 TCP-SA is consistent with the desire to authenticate TCP at the 534 connection level for similar uses as were intended by TCP/MD5. 536 5. Key Establishment and Duration Issues 538 The TCP-SA option does not provide connection key negotiation or 539 parameter negotiation (MAC algorithm, length, or use of the TCP-SA 540 option), or rekeying during a connection. We assume out-of-band 541 mechanisms for key establishment, parameter negotiation, and 542 rekeying. This separation of key use from key management is similar 543 to that in the IPsec security suite [RFC4301][RFC4306]. 545 We encourage users of TCP-SA to apply known techniques for generating 546 appropriate keys, including the use of reasonable connection key 547 lengths, limited connection key sharing, and limiting the duration of 548 connection key use [RFC3562]. 550 TCP-SA supports rekeying in which new keys are negotiated out-of- 551 band, either via a protocol or a manual procedure. New keys use is 552 coordinated using the out-of-band mechanism to update the LSAD at 553 both TCP endpoints. The temporary use of invalid keys would result in 554 packets being dropped; TCP is already robust to such drops. Such 555 drops may affect TCP's throughput temporarily, as a result TCP-SA 556 benefits from the use of congestion control support for temporary 557 path outages. 559 >> TCP-SA SHOULD be deployed in conjunction with support for 560 selective acknowledgement (SACK), including support for multiple lost 561 segments in the same round trip [RFC2018][RFC3517]. 563 Note that TCP-SA's support for rekeying is designed to be minimal. As 564 with the IPsec suite, segments carry only enough context to identify 565 the security association [RFC4301][RFC4306]. In TCP-SA, this context 566 is provided by the socket pair (IP addresses and ports for source and 567 destination). The key is identified only in the LSAD, and coordinated 568 by a separate mechanism not specified in TCP-SA. This differs from 569 recent approaches that assume an additional key ID field and require 570 support for multiple concurrently active keys on a single association 571 [Be06][Bo06][We05][We06]. Such complexity is not necessary in TCP-SA 572 because TCP is already robust to segment loss. 574 Implementations are encouraged to keep keys in a suitably private 575 area. Users of TCP-SA are encouraged to use different keys for 576 inbound and outbound MACs on a given TCP connection. 578 6. Interactions with TCP/MD5 580 TCP-SA is intended to be deployed without regard for existing TCP/MD5 581 option support. 583 >> A TCP implementation MUST NOT use both TCP-SA and TCP/MD5 for a 584 particular TCP connection, but MAY support TCP-SA and TCP/MD5 585 simultaneously for different connections. 587 There is no need to explicitly indicate which of TCP-SA or TCP/MD5 is 588 used for a particular connection in the TCP segments. Even where the 589 two used the same hash (e.g., if TCP-SA were to use MD5 rather than 590 HMAC-MD5) and the same length (128 bits), TCP-SA computes its MAC 591 over different data (including the TCP-SA option, notably, with the 592 MAC zeroed) than TCP/MD5. The probability of a TCP-SA segment being 593 validated by TCP/MD5 or the converse is roughly equivalent to that of 594 a random party guessing a valid MAC. 596 7. Security Considerations 598 Use of TCP-SA, like use of TCP/MD5 or IPsec, will impact host 599 performance. Connections that are known to use TCP-SA can be attacked 600 by transmitting segments with invalid MACs. Attackers would need to 601 know only the TCP connection ID and TCP-SA Length value to 602 substantially impact the host's processing capacity. This is similar 603 to the susceptibility of IPsec to on-path attacks, where the IP 604 addresses and SPI would be visible. For IPsec, the entire SPI space 605 (32 bits) is arbitrary, whereas for routing protocols typically only 606 the source port (16 bits) is arbitrary. As a result, it would be 607 easier for an off-path attacker to spoof a TCP-SA segment that could 608 cause receiver validation effort. However, we note that between 609 Internet routers both ports could be arbitrary (i.e., determined a- 610 priori out of band), which would constitute roughly the same off-path 611 antispoofing protection of an arbitrary SPI. 613 TCP-SA, like TCP/MD5, may inhibit connectionless resets. Such resets 614 typically occur after peer crashes, either in response to new 615 connection attempts or when data is sent on stale connections; in 616 either case, the recovering endpoint may lack the connection key 617 required (e.g., if lost during the crash). This may result in time- 618 outs, rather than more responsive recovery after such a crash. 620 TCP-SA does not expose the MAC algorithm used to authenticate a 621 particular connection; that information is kept in the TSAD at the 622 endpoints, and is not indicated in the header. 624 TCP-SA is intended to provide similar protections to IPsec, but is 625 not intended to replace the use of IPsec or IKE either for more 626 robust security or more sophisticated security management. 628 TCP-SA does not address the issue of ICMP attacks on TCP. IPsec makes 629 recommendations regarding dropping ICMPs in certain contexts, or 630 requiring that they are endpoint authenticated in others [RFC4301]. 631 There are other mechanisms proposed to reduce the impact of ICMP 632 attacks by further validating ICMP contents and changing the effect 633 of some messages based on TCP state, but these do not provide the 634 level of authentication for ICMP that TCP-SA provides for TCP [Go06]. 636 >> A TCP-SA implementation MUST allow the system administrator to 637 configure whether TCP will ignore incoming ICMP messages of Type 3 638 Codes 2-4 intended for connections that match TSAD entries with non- 639 NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be 640 logged. 642 This control affects only ICMPs that currently require 'hard errors' 643 which would abort the TCP connection. This recommendation is intended 644 to be similar to how IPsec would handle those messages [RFC4301]. 646 8. IANA Considerations 648 The TCP-SA option reuses the TCP MD5 Signature option (TCP/MD5), 649 where Kind=19. This document augments that use of this Kind value, 650 but there is no need to deprecate or override the use of TCP/MD5. 651 This document suggests that only one key algorithm would be 652 applicable in either case, and so there would be no confusion for a 653 given Length and key value as used for authenticating segments of a 654 given TCP connection. 656 If this document is approved as an IETF Standard, IANA is requested 657 to add a registration for TCP-SA to Kind=19, along with the existing 658 registration for TCP/MD5, and add a pointer to this document. 660 9. Conclusions 662 (to be completed) 664 10. Acknowledgments 666 This document was inspired by the revisions to TCP/MD5 suggested by 667 Brian Weis and Ron Bonica [Bo06][We05]. Russ Housley suggested 668 L4/application layer management of the TSAD. 670 11. References 672 11.1. Normative References 674 [RFC793] Postel, J., "Transmission Control Protocol," STD-007, RFC- 675 793, Standard, Sept. 1981. 677 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 678 Selective Acknowledgement Options", RFC 2018, Proposed 679 Standard, April 1996. 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, Best Current 683 Practice, March 1997. 685 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 686 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. 688 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 689 Conservative Selective Acknowledgment (SACK)-based Loss 690 Recovery Algorithm for TCP", RFC 3517, Proposed Standard, 691 April 2003. 693 [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP 694 and AH," RFC-2403, Proposed Standard, Nov. 1998. 696 11.2. Informative References 698 [Be05] Bellovin, S., E. Rescorla, "Deploying a New Hash 699 Algorithm," presented at the First NIST Cryptographic Hash 700 Workshop, Oct. 2005. 701 http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm 703 [Be06] Bellovin, S., "Key Change Strategies for TCP-MD5," draft- 704 bellovin-keyroll2385-00, (work in progress), June 2006. 706 [Bu06] Burr, B., "NIST Cryptographic Standards Status Report," 707 Invited talk at Internet 2 5th Annual PKI R&D Workshop, 708 April 2006. 709 http://middleware.internet2.edu/pki06/proceedings/ 711 [Bo06] Bonica, R., "Authentication for TCP-based Routing and 712 Management Protocols," draft-bonica-tcp-auth-04, (work in 713 progress), Jan. 2006. 715 [Go06] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- 716 attacks-00, (work in progress), Feb. 2006. 718 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, 719 Informational, April 1992. 721 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 722 Signature Option," RFC-3562, Informational, July 2003. 724 [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet 725 Protocol," RFC-4301, Proposed Standard, Dec. 2005. 727 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC- 728 4306, Proposed Standard, Dec. 2005. 730 [To06] Touch, J., "Defending TCP Against Spoofing Attacks," draft- 731 ietf-tcpm-tcp-antispoof-04, (work in progress), May 2006. 733 [We05] Weis, B., "TCP Message Authentication Code Option," draft- 734 weis-tcp-mac-option-00, (work in progress), Dec. 2005. 736 [We06] Weis, B., "Automated key selection extension for the TCP 737 Authentication Option," draft-weis-tcp-auth-auto-ks-00, 738 (work in progress), Feb. 2006. 740 Author's Addresses 742 Joe Touch 743 USC/ISI 744 4676 Admiralty Way 745 Marina del Rey, CA 90292-6695 746 U.S.A. 748 Phone: +1 (310) 448-9151 749 Email: touch@isi.edu 750 URL: http://www.isi.edu/touch 752 Allison Mankin 753 Washington, DC 754 U.S.A. 756 Phone: 1 301 728 7199 757 Email: mankin@psg.com 758 URL: http://www.psg.com/~mankin/ 760 Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Disclaimer of Validity 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Copyright Statement 796 Copyright (C) The Internet Society (2006). 798 This document is subject to the rights, licenses and restrictions 799 contained in BCP 78, and except as set forth therein, the authors 800 retain all their rights. 802 Acknowledgment 804 Funding for the RFC Editor function is currently provided by the 805 Internet Society.