TCPM WG J. Touch Internet Draft USC/ISI Obsoletes: 2385 A. Mankin Intended status: Proposed Standard Johns Hopkins Univ. Expires: September 2009 R. Bonica Juniper Networks March 9, 2009 The TCP Authentication Option draft-ietf-tcpm-tcp-auth-opt-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 9, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Touch Expires September 9, 2009 [Page 1] Internet-Draft The TCP Simple Authentication Option March 2009 Abstract This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key configuration or an external, out-of-band master key management mechanism; in either case, TCP-AO also protects connections when using the same master key across repeated instances of a connection, using traffic keys derived from the master key, and coordinates key changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses its own option identifier, even though used mutually exclusive of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is fully compatible with the requirements for the replacement of TCP MD5. Table of Contents 1. Contributors...................................................3 2. Introduction...................................................4 2.1. Executive Summary.........................................4 2.2. Changes from Previous Versions............................6 2.2.1. New in draft-ietf-tcp-auth-opt-04....................6 2.2.2. New in draft-ietf-tcp-auth-opt-03....................6 2.2.3. New in draft-ietf-tcp-auth-opt-02....................7 2.2.4. New in draft-ietf-tcp-auth-opt-01....................8 2.2.5. New in draft-ietf-tcp-auth-opt-00....................9 2.2.6. New in draft-touch-tcp-simple-auth-03................9 2.2.7. New in draft-touch-tcp-simple-auth-02...............10 2.2.8. New in draft-touch-tcp-simple-auth-01...............10 3. Conventions used in this document.............................10 4. The TCP Authentication Option.................................11 4.1. Review of TCP MD5 Option.................................11 4.2. The TCP-AO Option........................................11 5. The TCP-AO Activation and Parameter Database..................13 6. Per-Connection Parameters.....................................16 7. Cryptographic Algorithms......................................17 7.1. MAC Algorithms...........................................17 7.2. Key Derivation Functions.................................21 7.3. Traffic Key Establishment and Duration Issues............24 7.3.1. Master Key Reuse Across Socket Pairs................25 Touch Expires September 9, 2009 [Page 2] Internet-Draft The TCP Simple Authentication Option March 2009 7.3.2. Master Key Use Within a Long-lived Connection.......25 8. Additional Security Mechanisms................................25 8.1. Coordinating KeyID Changes...............................25 8.2. Preventing replay attacks within long-lived connections..26 9. TCP-AO Interaction with TCP...................................28 9.1. TCP User Interface.......................................29 9.2. TCP States and Transitions...............................30 9.3. TCP Segments.............................................30 9.4. Sending TCP Segments.....................................31 9.5. Receiving TCP Segments...................................32 9.6. Impact on TCP Header Size................................34 10. Obsoleting TCP MD5 and Legacy Interactions...................35 11. Interactions with Middleboxes................................36 11.1. Interactions with non-NAT/NAPT Middleboxes..............36 11.2. Interactions with NAT/NAPT Devices......................36 12. Evaluation of Requirements Satisfaction......................36 13. Security Considerations......................................42 14. IANA Considerations..........................................44 15. References...................................................45 15.1. Normative References....................................45 15.2. Informative References..................................46 16. Acknowledgments..............................................47 1. Contributors This document evolved as the result of collaboration of the TCP Authentication Design team (tcp-auth-dt), whose members were (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Westerlund. The text of this document is derived from a proposal by Joe Touch and Allison Mankin [To06] (originally from June 2006), which was both inspired by and intended as a counterproposal to the revisions to TCP MD5 suggested in a document by Ron Bonica, Brian Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] (originally from Sept. 2005) and in a document by Brian Weis [We05]. Russ Housley suggested L4/application layer management of the TAPD. Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the use of ISNs in the traffic key computation and ESNs to avoid replay attacks, and Brian Weis extended the computation to incorporate the entire connection ID and provided the details of the traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Brian Weis developed the key coordination mechanism. Touch Expires September 9, 2009 [Page 3] Internet-Draft The TCP Simple Authentication Option March 2009 2. Introduction The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP data. It was developed to protect BGP sessions from spoofed TCP segments which could affect BGP data or the robustness of the TCP connection itself [RFC2385][RFC4953]. There have been many recent concerns about TCP MD5. Its use of a simple keyed hash for authentication is problematic because there have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 also lacks both key management and algorithm agility. This document adds the latter, and provides a simple key coordination mechanism giving the ability to move from one key to another within the same connection. It does not however provide for complete cryptographic key management to be handled in-band of TCP, because TCP SYN segments lack sufficient remaining space to handle such a negotiation (see Section 9.6). This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO), to support the use of other, stronger hash functions, provide replay protection for long- lived connections and across repeated instances of a single connection, coordinate key changes between endpoints, and to provide a more structured recommendation on external key management. The result is compatible with IPv6, and is fully compatible with requirements under development for a replacement for TCP MD5 [Be07]. This document is not intended to replace the use of the IPsec suite (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In fact, we recommend the use of IPsec and IKE, especially where IKE's level of existing support for parameter negotiation, session key negotiation, or rekeying are desired. TCP-AO is intended for use only where the IPsec suite would not be feasible, e.g., as has been suggested is the case to support some routing protocols, or in cases where keys need to be tightly coordinated with individual transport sessions [Be07]. Note that TCP-AO obsoletes TCP MD5, although a particular implementation may support both mechanisms for backward compatibility. For a given connection, only one can be in use. TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5 does not support any changes to a connection's security algorithm once established. 2.1. Executive Summary This document replaces TCP MD5 as follows [RFC2385]: Touch Expires September 9, 2009 [Page 4] Internet-Draft The TCP Simple Authentication Option March 2009 o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). o TCP-AO allows TCP MD5 to continue to be used concurrently for legacy connections. o TCP-AO replaces MD5's single MAC algorithm with MACs specified in a separate document and allows extension to include other MACs. o TCP-AO allows rekeying during a TCP connection, assuming that an out-of-band protocol or manual mechanism provides the new keys. In such cases, a key ID allows the efficient concurrent use of multiple keys, and a key coordination mechanism manages the key change within a connection. Note that TCP MD5 does not preclude rekeying during a connection, but does not require its support either. Further, TCP-AO supports key changes with zero packet loss, whereas key changes in TCP MD5 can lose packets in transit during the changeover or require trying multiple keys on each received segment during key use overlap because it lacks an explicit key ID. o TCP-AO provides automatic replay protection for long-lived connections using an extended sequence number. o TCP-AO ensures per-connection traffic keys as unique as the TCP connection itself, using TCP's ISNs for differentiation, even when static master keys are used across repeated instances of a socket pair. o TCP-AO specifies the details of how this option interacts with TCP's states, event processing, and user interface. o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes overall, rather than 18) in the default case (using a 96-bit MAC). This document differs from an IPsec/IKE solution in that TCP-AO as follows [RFC4301][RFC4306]: o TCP-AO does not support dynamic parameter negotiation. o TCP-AO uses TCP's socket pair (source address, destination address, source port, destination port) as a security parameter index, rather than using a separate field as a primary index (IPsec's SPI). o TCP-AO forces a change of computed MACs when a connection restarts, even when reusing a TCP socket pair (IP addresses and port numbers) [Be07]. Touch Expires September 9, 2009 [Page 5] Internet-Draft The TCP Simple Authentication Option March 2009 o TCP-AO does not support encryption. o TCP-AO does not authenticate ICMP messages (some ICMP messages may be authenticated via IPsec, depending on the configuration). 2.2. Changes from Previous Versions [NOTE: to be omitted upon final publication as RFC] 2.2.1. New in draft-ietf-tcp-auth-opt-04 o Major revision to the document structure, including renaming the TSAD to TAPD. o Added a key change coordination mechanism in Section 8.1. o Added a requirement for symmetric use of TCP-AO, required for the key change coordination mechanism. This includes an update of the TAPD to indicate that all master keys are bidirectional. o Augmented the discussion of the available space for options. o Fixed a bug in the ESN algorithm. o Adds a text referring to the TCP-AO cryptography companion document. o Changed RFC-TBD to ao-crypto (until the RFC number is assigned). 2.2.2. New in draft-ietf-tcp-auth-opt-03 o Added a placeholder to discuss key change coordination in Section 8.1. o Moved discussion of required MAC algorithms and PRF to a separate document, indicated as RFC-TBD until assigned. Included the PRF in the TSAD master key tuple so that TCP-AO is PRF algorithm agile, and updated general PRF input format. o Revised the description the TSAD and impact to the TCP user interface. Removed the description of the TSAD API. Access to the API is assumed specific to the implementation, and not part of the protocol specification. o Clarified the different uses of the term key; includes master key (from the TSAD) and connection key (per-connection key, derived from the master via the PRF). Touch Expires September 9, 2009 [Page 6] Internet-Draft The TCP Simple Authentication Option March 2009 o Explained the ESN pseudocode operation in detail. o Added a contributors section up front. o Update discussion of requirements to be sufficiently stand-alone; update list to correlate more directly to Be07 (so that Be07 can be dropped from consideration for publication). o Provided detail on size of typical options (motivating a small option). o Confirmed WG consensus on IETF-72 topic - no algorithm ID and T- bit (options excluded) locations in the header. o Confirmed WG consensus on IETF-72 topic - no additional header bits for in-band key change signaling (the "K" bit from [Bo07]). 2.2.3. New in draft-ietf-tcp-auth-opt-02 o List issue - Replay Protection: incorporated extended sequence number space, not using KeyID space. o List issue - Unique Connection Keys: ISNs are used to generate unique connection keys even when static keys used for repeated instances of a socket pair. o List issue - Header Format and Alignment: Moved KeyID to front. o List issue - Reserved KeyID Value: Suggestion to reserve a single KeyID value for implementation optimization received no support on the WG list, so this was not changed. o List issue - KeyID Randomness: KeyIDs are not assumed random; a note was added that nonce-based filtering should be done on a portion of the MAC (incorporated into the algorithm), and that header fields should not be assumed to have cryptographic properties (e.g., randomness). o List issue - Support for NATs: preliminary rough consensus suggests that TCP-AO should not be augmented to support NAT traversal. Existing mechanisms for such traversal (UDP support) can be applied, or IPsec NAT traversal is recommended in such cases instead. o IETF-72 topic - providing algorithm ID and T-bit (options excluded) locations in the header: (No current consensus was reached on this topic, so no change was made.) Touch Expires September 9, 2009 [Page 7] Internet-Draft The TCP Simple Authentication Option March 2009 o IETF-72 topic - providing additional header bits for in-band key change signaling (draft-bonica's "K" bit): (No current consensus was reached on this topic, so no change was made.) o Clarified TCP-AO as obsoleting TCP MD5. o Clarified the MAC Type as referring to the IANA registry of IKEv2 transforms, not the RFC establishing that registry. o Added citation to the Wang/Yu paper regarding attacks on MD5 Wa05 to replace reports in Be05 and Bu06. o Explained why option exclusion can't be changed during a connection. o Clarified that AO explicitly allows rekeying during a TCP connection, without impacting packet loss. o Described TCP-AO's interaction with reboots more clearly, and explained the need to clear out old state that persists indefinitely. 2.2.4. New in draft-ietf-tcp-auth-opt-01 o Require KeyID in all versions. Remove odd/even indicator of KeyID usage. o Relax restrictions on key reuse: requiring an algorithm for nonce introduction based on ISNs, and suggest key rollover every 2^31 bytes (rather than using an extended sequence number, which introduces new state to the TCP connection). o Clarify NAT interaction; currently does not support omitting the IP addresses or TCP ports, both of which would be required to support NATs without any coordination. This appears to present a problem for key management - if the key manager knows the received addrs and ports, it should coordinate them (as indicated in Sec 8). o Options are included or excluded all-or-none. Excluded options are deleted, not just zeroed, to avoid the impact of reordering or length changes of such options. o Augment replay discussion in security considerations. o Revise discussion of IKEv2 MAC algorithm names. Touch Expires September 9, 2009 [Page 8] Internet-Draft The TCP Simple Authentication Option March 2009 o Remove executive summary comparison to expired documents. o Clarified key words to exclude lower case usage. 2.2.5. New in draft-ietf-tcp-auth-opt-00 o List of TBD values, and indication of how each is determined. o Changed TCP-SA to TCP-AO (removed 'simple' throughout). o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as appropriate approach instead. o Made several changes coordinated in the TCP-AUTH-DT as follow: o Added R. Bonica as co-author. o Use new TCP option Kind in the core doc. o Addresses the impact of explicit declines on security. o Add limits to TSAD size (2 <= TSAD <= 256). o Allow 0 as a legitimate KeyID. o Allow the WG to determine the two appropriate required MAC algorithms. o Add TO-DO items. o Added discussion at end of Introduction as to why TCP MD5 connections cannot be upgraded to TCP-AO. 2.2.6. New in draft-touch-tcp-simple-auth-03 o Added support for NAT/NAPT. o Added support for IPv6. o Added discussion of how this proposal satisfies requirements under development, including those indicated in [Be07]. o Clarified the byte order of all data used in the MAC. o Changed the TCP option exclusion bit from a bit to a list. Touch Expires September 9, 2009 [Page 9] Internet-Draft The TCP Simple Authentication Option March 2009 2.2.7. New in draft-touch-tcp-simple-auth-02 o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. o Add reference to SP4 [SDNS88]. o Added notes that TSAD to be externally implemented; this was compatible with the TSAD described in the previous version. o Augmented the protocol to allow a KeyID, required to support efficient overlapping keys during rekeying, and potentially useful during connection establishment. Accommodated by redesigning the TSAD. o Added the odd/even indicator for the KeyID. o Allow for the exclusion of all TCP options in the MAC calculation. 2.2.8. New in draft-touch-tcp-simple-auth-01 o Allows intra-session rekeying, assuming out-of-band coordination. o MUST allow TSAD entries to change, enabling rekeying within a TCP connection. o Omits discussion of the impact of connection reestablishment on BGP, because added support for rekeying renders this point moot. o Adds further discussion on the need for rekeying. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" proceeding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding this RFC's explicit compliance requirements. Touch Expires September 9, 2009 [Page 10] Internet-Draft The TCP Simple Authentication Option March 2009 4. The TCP Authentication Option The TCP Authentication Option (TCP-AO) uses a TCP option Kind value of TBD-IANA-KIND. 4.1. Review of TCP MD5 Option For review, the TCP MD5 option is shown in Figure 1. +---------+---------+-------------------+ | Kind=19 |Length=18| MD5 digest... | +---------+---------+-------------------+ | | +---------------------------------------+ | | +---------------------------------------+ | | +-------------------+-------------------+ | | +-------------------+ Figure 1 The TCP MD5 Option [RFC2385] In the TCP MD5 option, the length is fixed, and the MD5 digest occupies 16 bytes following the Kind and Length fields, using the full MD5 digest of 128 bits [RFC1321]. The TCP MD5 option specifies the use of the MD5 digest calculation over the following values in the following order: 1. The TCP pseudoheader (IP source and destination addresses, protocol number, and segment length). 2. The TCP header excluding options and checksum. 3. The TCP data payload. 4. A key. 4.2. The TCP-AO Option The new TCP-AO option provides a superset of the capabilities of TCP MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new Kind field, and similar Length field to TCP MD5, a KeyID field, and a NextKeyID field as shown in Figure 2. Touch Expires September 9, 2009 [Page 11] Internet-Draft The TCP Simple Authentication Option March 2009 +----------+----------+----------+----------+ | Kind | Length | KeyID | NextKeyID| +----------+----------+----------+----------+ | MAC ... +----------------------------------... ...-----------------+ ... MAC (con't) | ...-----------------+ Figure 2 The TCP-AO Option The TCP-AO defines the following fields: o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- AO uses a new Kind value of TBD-IANA-KIND. >> An endpoint MUST NOT use TCP-AO for the same connection in which TCP MD5 is used. >> A single TCP segment MUST NOT have more than one TCP-AO option. o Length: An unsigned 1-byte field indicating the length of the TCP- AO option in bytes, including the Kind, Length, KeyID, NextKeyID, and MAC fields. >> The Length value MUST be greater than or equal to 4. >> The Length value MUST be consistent with the TCP header length; this is a consistency check and avoids overrun/underrun abuse. Values of 4 and other small values are of dubious utility but are not specifically prohibited. o KeyID: An unsigned 1-byte field used to support efficient key changes during a connection and/or to help with key coordination during connection establishment, to be discussed further in Section 8.1. Note that the KeyID has no cryptographic properties - it need not be random, nor are there any reserved values. o NextKeyID: An unsigned 1-byte field used to support efficient key change coordination, to be discussed further in Section 8.1. Note that the NextKeyID has no cryptographic properties - it need not be random, nor are there any reserved values. Touch Expires September 9, 2009 [Page 12] Internet-Draft The TCP Simple Authentication Option March 2009 o MAC: Message Authentication Code. Its contents are determined by the particulars of the security association. Typical MACs are 96- 128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. The MAC computation is described further in Section 7.1. >> Required support for TCP-AO MACs as defined in [ao-crypto]; other MACs MAY be supported. The TCP-AO option fields do not indicate the MAC algorithm either implicitly (as with TCP MD5) or explicitly. The particular algorithm used is considered part of the configuration state of the connection's security and is managed separately (see Section 5). The remainder of this document explains how the TCP-AO option is handled and its relationship to TCP. 5. The TCP-AO Activation and Parameter Database TCP-AO relies on a TCP-AO Activation and Parameter Database (TAPD), which indicates whether a TCP connection requires TCP-AO, and its parameters when so. TAPD entries are assumed to exist at the endpoints where TCP-AO is used, in advance of the connection, and consist of the following: 1. TCP connection identifier (ID), i.e., socket pair - IP source address, IP destination address, TCP source port, and TCP destination port [RFC793]. TAPD entries are uniquely determined by their TCP connection ID, which is used to index those entries. A TAPD entry may allow wildcards, notably in the source port value. >> There MUST be no more than one matching TAPD entry per direction for a fully-instantiated (no wildcards) TCP connection ID. Touch Expires September 9, 2009 [Page 13] Internet-Draft The TCP Simple Authentication Option March 2009 2. A TCP option flag. When 0, this flag allows default operation, i.e., TCP options are included in the MAC calculation, with TCP- AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) are excluded from all MAC calculations (skipped over, not simply zeroed). The option flag applies to TCP options in both directions (incoming and outgoing segments). >> The TCP option flag MUST NOT change during a TCP connection. The TCP option flag cannot change during a connection because TCP state is coordinated during connection establishment. TCP lacks a handshake for modifying that state after a connection has been established. 3. A list of zero or more master key tuples. >> Components of a TAPD master key tuple MUST NOT change during a connection. Keeping the tuple components static ensures that the KeyID uniquely determines the properties of a packet; this supports use of the KeyID to determine the packet properties. >> The set of TAPD master key tuples MAY change during a connection, but KeyIDs of those tuples MUST NOT overlap. I.e., tuple parameter changes MUST be accompanied by master key changes. >> If there are multiple tuples in a TAPD entry, then one tuple MUST be flagged as the preferred key; that key, when instantiated as a traffic_key, becomes the current_key for the connection (see Section 6). Each tuple is defined as the following components: Touch Expires September 9, 2009 [Page 14] Internet-Draft The TCP Simple Authentication Option March 2009 a. KeyID. The value as used in the TCP-AO option; used to differentiate master keys in concurrent use, as well as to indicate when master keys are ready for use. >> A TAPD implementation MUST support at least two KeyIDs per connection per direction, and MAY support up to 256. >> A KeyID MUST support any value, 0-255 inclusive. There are no reserved KeyID values. KeyID values are assigned arbitrarily. They can be assigned in sequence, or based on any method mutually agreed by the connection endpoints (e.g., using an external master key management mechanism). >> KeyIDs MUST NOT be assumed to be randomly assigned. Note that KeyIDs are unique only within a TAPD entry. b. Master key. A byte sequence used for generating traffic keys, this may be derived from a separate shared key by an external protocol over a separate channel. This sequence is used in the traffic key generation algorithm described in Section 7.2. Implementations are advised to keep master key values in a private, protected area of memory or other storage. Implementations are also advised to indicate the length of this key explicitly, because there are no reserved byte values. c. MAC algorithm. Indicates the MAC algorithm used for this connection, explained further in Section 7.1 [ao-crypto]. The MAC_algorithm indicates other properties, such as MAC truncation, PRF algorithm, and KDF truncation, as explained further in [ao-crypto] The TAPD is consulted when new connections are established to determine whether TCP-AO is required. >> When a TAPD entry matches a new connection, TCP-AO is required. This is true regardless of whether there are any master key tuples present. >> When TCP-AO is required, the TCP-AO option MUST occur in every incoming and outgoing TCP segment. In this case, segments lacking the TCP-AO option MUST be silently ignored. Touch Expires September 9, 2009 [Page 15] Internet-Draft The TCP Simple Authentication Option March 2009 For a particular endpoint (i.e., IP address) there would be exactly one TAPD that is consulted by all pending connections, the same way that there is only one table of TCBs (a database can support multiple endpoints, but an endpoint is represented in only one database). Multiple databases could be used to support virtual hosts, i.e., groups of interfaces. This document does not address how TAPD entries are created by users/processes; it specifies how they must be destroyed corresponding to connection states, but users/processes may destroy entries as well. It is presumed that a TAPD entry affecting a particular connection cannot be destroyed during an active connection - or, equivalently, that its parameters are copied to an area local to the connection (i.e., instantiated) and so changes would affect only new connections. The TAPD can be managed by a separate application protocol. NOTE: an open issue is whether to require actions when master keys are added to the TAPD. In particular, there is a suggestion to force new added keys to update current_key to the newly added value, and to set a timer or flag on previous current_key values. If a timer, the value is unclear (2*MSL isn't appropriate, because we don't know how long a key changeover may take, and we're not reacting to messages from the other side). If a flag, this would require that flagged entries could never be advertised as NextKeyID. 6. Per-Connection Parameters TCP-AO uses a small number of parameters associated with each connection that uses the TCP-AO option, once instantiated. These values would typically be stored in the Transport Control Block (TCP) [RFC793]. These values are explained in subsequent sections of this document as noted; they include: 1. Current_key - the KeyID of the master key tuple currently used to authenticate outgoing segments, inserted in outgoing segments as KeyID (see Section 9.4, step 5). Incoming segments are authenticated using the KeyID in the segment's TCP-AO header (see Section 9.5, step 5). There is only one current_key at any given time on a particular connection. >> Every connection in a non-IDLE state MUST have exactly one current_key value specified. Touch Expires September 9, 2009 [Page 16] Internet-Draft The TCP Simple Authentication Option March 2009 2. Next_key - the KeyID of the master key tuple currently preferred for future use, as inserted in outgoing segments as NextKeyID (see Section 9.5, step 5). >> Each connection in a non-IDLE state MUST have exactly one next_key value specified. 3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to prevent replay attacks, as described in Section 8.2. Each ESN is initialized to zero upon connection establishment. Its use in the MAC calculation is described in Section 7.1. 4. One or more master key tuples. These are all the master key tuples that match this connection's socket pair in the TAPD. When a new tuple is added to the TAPD, it is added to the TCB of all matching connections. Master key tuples are used, together with other parameters of a connection, to create traffic keys unique to each connection, as described in Section 7.2. These traffic keys can be cached after computation, and are typically stored in the TCB with the corresponding master key tuple information. They can be considered part of the per-connection parameters. 7. Cryptographic Algorithms TCP-AO also uses cryptographic algorithms to compute the MAC (Message Authentication Code) used to authenticate a segment and its headers; these are called MAC algorithms and are specified in a separate document to facilitate updating the algorithm requirements independently from the protocol [ao-crypto]. TCP-AO also uses cryptographic algorithms to convert master keys, which can be shared across connections, into unique traffic keys for each connection. These are called Key Derivation Functions (KDFs), and are specified [ao-crypto]. This section describes how these algorithms are used by TCP-AO. 7.1. MAC Algorithms MAC algorithms take a variable-length input and a key and output a fixed-length number. This number is used to determine whether the input comes from a source with that same key, and whether the input has been tampered in transit. MACs for TCP-AO have the following interface: INPUT: MAC_alg, MAC_truncation, traffic_key, data_block Touch Expires September 9, 2009 [Page 17] Internet-Draft The TCP Simple Authentication Option March 2009 OUTPUT: MAC where: o MAC_alg - MAC algorithm used for this computation o MAC_truncation - the number of bytes to truncate the output of the MAC to. This is indicated by the MAC algorithm, as specified in [ao-crypto]. o Traffic_key - traffic key used for this computation. This is computed from the connection's current master key as described in Section 7.2. o Data_block - input data over which the MAC is computed. In TCP-AO, this is the TCP segment prepended by the TCP pseudoheader and TCP header options, as described in Section 7.1. o MAC - the fixed-length output of the MAC algorithm, given the parameters provided. If the MAC_alg output is smaller than the desired MAC_truncation, it is padded with trailing zeroes as needed. At the time of this writing, the algorithms' definitions for use in TCP-AO, as described in [ao-crypto] are each truncated to 96 bits. Though the algorithms each output a larger MAC, we truncate the output to 96 bits to provide a reasonable tradeoff between security and message size, for fitting into the TCP-AO header. Though could change in the future, so TCP-AO header sizes should not be assumed as fixed length. >> To allow a TCP-AO implementation to compute any implicit MAC algorithm padding required, the specification for each algorithm used with TCP-AO MUST specify the padding modulus for the algorithm, if one is required. The MAC algorithm employed for the MAC computation on any connection is done so by policy definition in the TAPD entry, and is chosen from a list of available MACs, where each MAC also infers an underlying KDF, per [ao-crypto]'s definitions. The mandatory-to-implement MAC algorithms for use with TCP-AO are described in a separate RFC [ao-crypto]. This allows the TCP-AO specification to proceed along the standards track even if changes are needed to its associated algorithms and their labels (as might be used in a user interface or automated master key management protocol) as a result of the ever evolving world of cryptography. Touch Expires September 9, 2009 [Page 18] Internet-Draft The TCP Simple Authentication Option March 2009 >> Additional algorithms, beyond those mandated for TCP-AO, MAY be supported. The data input to the MAC is the following fields in the following sequence, interpreted in network-standard byte order: 1. The extended sequence number (ESN), in network-standard byte order, as follows (described further in Section 8.2): +--------+--------+--------+--------+ | ESN | +--------+--------+--------+--------+ Figure 3 Extended sequence number The ESN for transmitted segments is maintained locally in the SND.ESN value; for received segments, a local RCV.ESN value is used. The details of how these values are maintained and used is described in Sections 8.2, 9.4, and 9.5. 2. The TCP pseudoheader: IP source and destination addresses, protocol number and segment length, all in network byte order, prepended to the TCP header below. The pseudoheader is exactly as used for the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]: +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | Proto | TCP Length | +--------+--------+--------+--------+ Figure 4 TCP IPv4 pseudoheader [RFC793] Touch Expires September 9, 2009 [Page 19] Internet-Draft The TCP Simple Authentication Option March 2009 +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Packet Length | +--------+--------+--------+--------+ | zero | Next Header | +--------+--------+--------+--------+ Figure 5 TCP IPv6 pseudoheader [RFC2460] 3. The TCP header, by default including options, and where the TCP checksum and TCP-AO MAC fields are set to zero, all in network byte order. When the TCP option flag is 0, the TCP options are included in MAC processing, except that the MAC field of the TCP-AO option is zeroed-out. When the TCP option flag is 1, all TCP options are omitted from MAC processing, except for the non-MAC portions of the TCP-AO option. In this case, the following field is used instead of the options part of the TCP header: +----------+----------+----------+----------+ | Kind | Length | KeyID | NextKeyID| +----------+----------+----------+----------+ 4. The TCP data, i.e., the payload of the TCP segment. Note that the traffic key is not included as part of the data; the MAC algorithm indicates how to use the traffic key, e.g., as HMACs do Touch Expires September 9, 2009 [Page 20] Internet-Draft The TCP Simple Authentication Option March 2009 in general [RFC2104][RFC2403]. The traffic key is derived from the current master key as described in Sections 7.2. 7.2. Key Derivation Functions TCP-AO's traffic keys are derived from the master key tuples using Key Derivation Functions (KDFs). The KDFs used in TCP-AO have the following interface: INPUT: PRF_alg, master_key, output_length, data_block OUTPUT: traffic_key where: o PRF_alg - the specific pseudorandom function (PRF) that is the basic building block used in constructing the given KDF. This is specified by the MAC algorithm as specified in [ao-crypto]. o Master_key - The master_key string, as will be stored into the associated TCP-AO TAPD master key tuple. o Output_length - The desired output length of the KDF, i.e., the length to which the KDF's output will be truncated or padded. In TCP-AO, the output_length is the PRF_truncation value of the master key tuple. This is specified by the MAC algorithm as specified in [ao-crypto]. o Data_block - The data block used as input in constructing the KDF. The data block provided by TCP-AO is used as the "context" as specified in [ao-crypto]. The specific way this context is used, in conjunction with other information, to create the raw input to the PRF is also explained further in [ao-crypto]. The data used as input to the KDF combines TCP socket pair with the endpoint initial sequence numbers (ISNs) of a connection. This provides context unique to each TCP connection instance, which enables TCP-AO to generate unique traffic keys for that connection, even from a master key used across many different connections or across repeated connections that share a socket pair. Unique traffic keys are generated without relying on external key management properties. This data block is defined in Figure 6 and Figure 7. Touch Expires September 9, 2009 [Page 21] Internet-Draft The TCP Simple Authentication Option March 2009 +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | Source Port | Dest. Port | +--------+--------+--------+--------+ | Source ISN | +--------+--------+--------+--------+ | Dest. ISN | +--------+--------+--------+--------+ Figure 6 Data block for an IPv4 connection +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Source Port | Dest. Port | +--------+--------+--------+--------+ | Source ISN | +--------+--------+--------+--------+ | Dest. ISN | +--------+--------+--------+--------+ Figure 7 Data block for an IPv6 connection "Source" and "destination" are defined by the direction of the segment being MAC'd; for incoming packets, source is the remote side, whereas for outgoing packets source is the local side. This further ensures that connection keys generated for each direction are unique. Touch Expires September 9, 2009 [Page 22] Internet-Draft The TCP Simple Authentication Option March 2009 For SYN segments (segments with the SYN set, but the ACK not set), the destination ISN is not known. For these segments, the connection key is computed using the connection block shown above, in which the Destination ISN value is zero. For all other segments, the ISN pair is used when known. If the ISN pair is not known, e.g., when sending a RST after a reboot, the segment should be sent without authentication; if authentication was required, the segment cannot have been MAC'd properly anyway and would have been dropped on receipt. >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination ISN of zero (whether sent or received); all other segments use the known ISN pair. Overall, this means that each connection will use up to four distinct traffic keys for each master key: o Send_SYN_traffic_key - the traffic key used to authenticate outgoing SYNs. The source ISN known (the TCP connection's local ISN), and the destination (remote) ISN is unknown (and so the value 0 is used). o Receive_SYN_traffic_key - the traffic key used to authenticate incoming SYNs. The source ISN known (the TCP connection's remote ISN), and the destination (remote) ISN is unknown (and so the value 0 is used). o Send_other_traffic_key - the traffic key used to authenticate all other outgoing TCP segments. The source ISN is the TCP connection's local ISN, and the destination ISN is the TCP connection's remote ISN. o Receive_other_traffic_key - the traffic key used to authenticate all other incoming TCP segments. The source ISN is the TCP connection's remote ISN, and the destination ISN is the TCP connection's remote ISN. The use of both ISNs in the KDF ensures that segments cannot be replayed across repeated connections reusing the same socket pair (provided the ISN pair does not repeat, which is unlikely because both endpoints should select ISNs pseudorandomly [RFC1948], their 32- bit space avoids repeated use except under reboot, and reuse assumes both sides repeat their use on the same connection). In general, a SYN would be MAC'd using a destination ISN of zero (whether sent or received), and all other segments would be MAC'd using the ISN pair for the connection. There are other cases in which Touch Expires September 9, 2009 [Page 23] Internet-Draft The TCP Simple Authentication Option March 2009 the destination ISN is not known, but segments are emitted, such as after an endpoint reboots, when is possible that the two endpoints would not have enough information to authenticate segments. In such cases, TCP's timeout mechanism will allow old state to be cleared to enable new connections, except where the user timeout is disabled; it is important that implementations are capable of detecting excesses of TCP connections in such a configuration and can clear them out if needed to protect its memory usage [Je07]. 7.3. Traffic Key Establishment and Duration Issues The TCP-AO option does not provide a mechanism for traffic key negotiation or parameter negotiation (MAC algorithm, length, or use of the TCP-AO option), or for coordinating rekeying during a connection. We assume out-of-band mechanisms for master key establishment, parameter negotiation, and rekeying. This separation of master key use from master key management is similar to that in the IPsec security suite [RFC4301][RFC4306]. We encourage users of TCP-AO to apply known techniques for generating appropriate master keys, including the use of reasonable master key lengths, limited traffic key sharing, and limiting the duration of master key use [RFC3562]. This also includes the use of per- connection nonces, as suggested in Section 7.2. TCP-AO supports rekeying in which new master keys are negotiated and coordinated out-of-band, either via a protocol or a manual procedure [RFC4808]. New master key use is coordinated using the out-of-band mechanism to update the TAPD at both TCP endpoints. When only a single master key is used at a time, the temporary use of invalid master keys could result in packets being dropped; although TCP is already robust to such drops, TCP-AO uses the KeyID field to avoid such drops. The TAPD can contain multiple concurrent master keys, where the KeyID field is used to identify the master key that corresponds to the traffic key used for a segment, to avoid the need for expensive trial-and-error testing of master keys in sequence. TCP-AO provides an explicit key coordination mechanism, described in Section 8.1. Such a mechanism is useful when new keys are installed, or when keys are changed, to determine when to commence using installed keys. The KeyID field is also useful in coordinating master keys used for new connections. A TAPD entry may be configured that matches the unbound source port, which would return a set of possible master keys. The KeyID would then indicate the specific master key, allowing Touch Expires September 9, 2009 [Page 24] Internet-Draft The TCP Simple Authentication Option March 2009 more efficient connection establishment; otherwise, the master keys could have been tried in sequence. Users are advised to manage master keys following the spirit of the advice for key management when using TCP MD5 [RFC3562], notably to use appropriate key lengths (12-24 bytes) and to avoid sharing master keys among multiple BGP peering arrangements. This requires that the TAPD support monitoring and modification. 7.3.1. Master Key Reuse Across Socket Pairs Master keys can be reused across different socket pairs within a host, or across different instances of a socket pair within a host. In either case, replay protection is maintained. Master keys reused across different socket pairs cannot enable replay attacks because the TCP socket pair is included in the MAC, as well as in the generation of the traffic key. Master keys reused across repeated instances of a given socket pair cannot enable replay attacks because the connection ISNs are included in the traffic key generation algorithm, and ISN pairs are unlikely to repeat over useful periods. 7.3.2. Master Key Use Within a Long-lived Connection TCP-AO uses extended sequence numbers (ESNs) to prevent replay attacks within long-lived connections. Explicit master key rollover, accomplished by external means and indexed using the KeyID field, can be used to change keying material for various reasons (e.g., personnel turnover), but is not required to support long-lived connections. 8. Additional Security Mechanisms TCP-AO adds mechanisms to support efficient use, especially in environments where only manual keying is available. These include the previously described mechanisms for supporting multiple concurrent keys (via the KeyID field) and for generating unique per-connection traffic keys (via the KDF). This section describes additional mechanisms to coordinate KeyID changes and to prevent replay attacks when a traffic key is not changed for long periods of time. 8.1. Coordinating KeyID Changes At any given time, a single TCP connection may have multiple KeyIDs specified for each segment direction (incoming, outgoing). TCP-AO provides a mechanism to indicate when a new KeyID is ready, to allow Touch Expires September 9, 2009 [Page 25] Internet-Draft The TCP Simple Authentication Option March 2009 the sender to commence use of that new KeyID. This supported by using two key ID fields in the header: o KeyID o NextKeyID KeyID represents the outgoing keying information used by the segment sender to create the segment's MAC (outgoing), and the corresponding incoming keying information used by the segment receiver to validate that MAC. It indicates the KeyID in active use in that direction. NextKeyID represents the preferred keying information to be used for subsequent segments. I.e., it is a way for the segment sender to indicate ready incoming keying information for future segments it receives, so that the segment receiver can know when to switch traffic keys (and thus their KeyIDs). There are two pointers kept by each side of a connection, as noted in the per-connection information (see Section 6): o Currently active outgoing KeyID (Current_key) o Current preference for KeyIDs (Next_key) Current_key points to a KeyID (and associated master key tuple) that is used to authenticate outgoing segments. Upon connection establishment, it points to the first key selected for use. Next_key points to an incoming KeyID (and associated master key tuple) that is ready and preferred for use. Upon connection establishment, this points to the currently active incoming key. It can be changed when new keys are installed (e.g., either by automatic key management protocol operation or by user manual selection). Next_key is changed only by manual user intervention or key management protocol operation. It is not manipulated by TCP-AO. Current_key is updated by TCP-AO when processing received TCP segments as discussed in the segment processing description in Section 9.5. 8.2. Preventing replay attacks within long-lived connections TCP uses a 32-bit sequence number which may, for long-lived connections, roll over and repeat. This could result in TCP segments being intentionally and legitimately replayed within a connection. TCP-AO prevents replay attacks, and thus requires a way to Touch Expires September 9, 2009 [Page 26] Internet-Draft The TCP Simple Authentication Option March 2009 differentiate these legitimate replays from each other, and so it adds a 32-bit extended sequence number (ESN) for transmitted and received segments. The ESN extends TCP's sequence number so that segments within a single connection are always unique. When TCP's sequence number rolls over, there is a chance that a segment could be repeated in total; using an ESN differentiates even identical segments sent with identical sequence numbers at different times in a connection. TCP-AO emulates a 64-bit sequence number space by inferring when to increment the high-order 32-bit portion (the ESN) based on transitions in the low-order portion (the TCP sequence number). TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN for received segments, both initialized as zero when a connection begins. The intent of these ESNs is, together with TCP's 32-bit sequence numbers, to provide a 64-bit overall sequence number space. For transmitted segments SND.ESN can be implemented by extending TCP's sequence number to 64-bits; SND.ESN would be the top (high- order) 32 bits of that number. For received segments, TCP-AO needs to emulate the use of a 64-bit number space, and correctly infer the appropriate high-order 32-bits of that number as RCV.ESN from the received 32-bit sequence number and the current connection context. The implementation of ESNs is not specified in this document, but one possible way is described here that can be used for either RCV.ESN, SND.ESN, or both. Consider an implementation with two ESNs as required (SND.ESN, RCV.ESN), and additional variables as listed below, all initialized to zero, as well as a current TCP segment field (SEG.SEQ): o SND.PREV_SEQ, needed to detect rollover of SND.SEQ o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ o SND.ESN_FLAG, which indicates when to increment the SND.ESN o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN When a segment is received, the following algorithm (written in C) computes the ESN used in the MAC; an equivalent algorithm can be applied to the "SND" side: Touch Expires September 9, 2009 [Page 27] Internet-Draft The TCP Simple Authentication Option March 2009 /* */ /* set the flag when the SEG.SEQ first rolls over */ if ((RCV.ESN_FLAG == 0) && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { RCV.ESN = RCV.ESN + 1; RCV.ESN_FLAG = 1; } /* */ /* decide which ESN to use after incremented */ if ((RCV.ESN_FLAG == 1) && (SEG.SEQ > 0x7fff)) { ESN = RCV.ESN - 1; # use the pre-increment value } else { ESN = RCV.ESN; # use the current value } /* */ /* reset the flag in the *middle* of the window */ if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { RCV.ESN_FLAG = 0; } /* */ /* save the current SEQ for the next time through the code */ RCV.PREV_SEQ = SEG.SEQ; In the above code, the first line when the sequence number first rolls over, i.e., when the new number is low (in the bottom half of the number space) and the old number is high (in the top half of the number space). The first time this happens, the ESN is incremented and a flag is set. If the flag is set and a high number is seen, it must be a reordered packet, so use the pre-increment ESN, otherwise use the current ESN. The flag will be cleared by the time the number rolls all the way around. The flag prevents the ESN from being incremented again until the flag is reset, which happens in the middle of the window (when the old number is in the bottom half and the new is in the top half). Because the receive window is never larger than half of the number space, it is impossible to both set and reset the flag at the same time - outstanding packets, regardless of reordering, cannot straddle both regions simultaneously. 9. TCP-AO Interaction with TCP The following is a description of how TCP-AO affects various TCP states, segments, events, and interfaces. This description is Touch Expires September 9, 2009 [Page 28] Internet-Draft The TCP Simple Authentication Option March 2009 intended to augment the description of TCP as provided in RFC-793, and its presentation mirrors that of RFC-793 as a result [RFC793]. 9.1. TCP User Interface The TCP user interface supports active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this interface as it applies to TCP, but some commands or command sequences of the interface need to be modified to support TCP-AO. TCP-AO does not specify the details of how this is achieved. TCP-AO requires the TCP user interface be extended to allow the TAPD to be configured, as well as to allow an ongoing connection to manage which KeyID tuples are active. The TAPD needs to be configured prior to connection establishment, and possibly changed during a connection: >> TCP OPEN, or the sequence of commands that configure a connection to be in the active or passive OPEN state, MUST be augmented so that a TAPD entry can be configured. >> A TCP-AO implmentation MUST allow TAPD entries for ongoing TCP connections (i.e., not in the CLOSED state) to be modified. Parameters not used to index a connection MAY be modified; parameters used to index a connection MUST NOT be modified. The TAPD information of a connection needs to be available for confirmation; this includes the ability to read the connection key: >> TCP STATUS SHOULD be augmented to allow the TAPD entry of a current or pending connection to be read (for confirmation). Senders may need to be able to determine when the outgoing KeyID changes or when a new preferred KeyID (NextKeyID) is indicated; these changes immediately affect all subsequent outgoing segments: >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be augmented so that the preferred KeyID (Current_key) and/or the Next_key of a connection can be indicated. It may be useful to change the outgoing active KeyID (Current_key) even when no data is being sent, which can be achieved by sending a zero-length buffer or by using a non-send interface (e.g., socket options in Unix), depending on the implementation. It is also useful to indicate recent KeyID and NextKeyID values received; although there could be a number of such values, they are Touch Expires September 9, 2009 [Page 29] Internet-Draft The TCP Simple Authentication Option March 2009 not expected to change quickly so any recent sample should be sufficient: >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, MUST be augmented so that the KeyID and NextKeyID of a recently received segment is available to the user out-of-band (e.g., as an additional parameter to RECEIVE, or via a STATUS call). 9.2. TCP States and Transitions TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and CLOSED. >> A TAPD entry MAY be associated with any TCP state. >> A TAPD entry MAY underspecify the TCP connection for the LISTEN state. Such an entry MUST NOT be used for more than one connection progressing out of the LISTEN state. 9.3. TCP Segments TCP includes control (at least one of SYN, FIN, RST flags set) and data (none of SYN, FIN, or RST flags set) segments. Note that some control segments can include data (e.g., SYN). >> All TCP segments MUST be checked against the TAPD for matching TCP connection IDs. >> TCP segments matching TAPD entries without TCP-AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be silently discarded. >> TCP segments with TCP-AO but not matching TAPD entries MUST be silently accepted; this is required for equivalent function with TCPs not implementing TCP-AO. >> Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. Both warnings, if available, MUST be accessible via the STATUS interface. Either signal MAY be asynchronous, but if so they MUST be rate-limited. Either signal MAY be logged; logging SHOULD allow rate- limiting as well. All TCP-AO processing occurs between the interface of TCP and IP; for incoming segments, this occurs after validation of the TCP checksum. For outgoing segments, this occurs before computation of the TCP checksum. Touch Expires September 9, 2009 [Page 30] Internet-Draft The TCP Simple Authentication Option March 2009 Note that the TCP-AO option is not negotiated. It is the responsibility of the receiver to determine when TCP-AO is required and to enforce that requirement. 9.4. Sending TCP Segments The following procedure describes the modifications to TCP to support TCP-AO when a segment departs. >> Note that TCP-AO MUST be the last TCP option processed on outgoing segments, because its MAC calculation may include the values of other TCP options. 1. Find the per-connection parameters for the segment: a. If the segment is a SYN, then this is the first segment of a new connection. Consult the TAPD to find the appropriate master key tuple. i. If there is no matching TAPD entry, omit the TCP-AO option. Proceed with transmitting the segment. ii. If there is a TAPD entry with zero master key tuples, silently discard the segment and cease further processing. iii. If there is a TAPD entry and at least one master key tuple, then set the per-connection parameters as needed (see Section 6). Proceed with the step 2. b. If the segment is not a SYN, then determine whether TCP-AO is being used and the current_key value from the per-connection parameters (see Section 6) and proceed with the step 2. 2. Using the per-connection parameters: a. Augment the TCP header with the TCP-AO, inserting the appropriate Length and KeyID based on the master key tuple indicated by current_key. Update the TCP header length accordingly. b. Determine SND.ESN as described in Section 8.2. c. Determine the appropriate traffic key, i.e., as pointed to by current_key (as noted in Section 8.1, and as probably cached in the TCB). I.e., use the Send_SYN_traffic_key for SYN segments, and the send_other_traffic_key for other segments. Touch Expires September 9, 2009 [Page 31] Internet-Draft The TCP Simple Authentication Option March 2009 d. Determine the NextKeyID as indicated by the Next_key pointer (as noted in Section 8.1). e. Compute the MAC using the master key tuple (and cached traffic key) and data from the segment as specified in Section 7.1. f. Insert the MAC in the TCP-AO field. g. Proceed with transmitting the segment. 9.5. Receiving TCP Segments The following procedure describes the modifications to TCP to support TCP-AO when a segment arrives. >> Note that TCP-AO MUST be the first TCP option processed on incoming segments, because its MAC calculation may include the values of other TCP options which could change during TCP option processing. This also protects the behavior of all other TCP options from the impact of spoofed segments or modified header information. >> Note that TCP-AO checks MUST be performed for all incoming SYNs to avoid accepting SYNs lacking the TCP-AO option where required. Other segments can cache whether TCP-AO is needed in the TCB. 1. Find the per-connection parameters for the segment: a. If the segment is a SYN, then this is the first segment of a new connection. Consult the TAPD to find the appropriate master key tuple. i. If there is no matching TAPD entry, omit the TCP-AO option. Proceed with further TCP handling of the segment. ii. If there is a TAPD entry with zero master key tuples, silently discard the segment and cease further TCP processing. iii. If there is a TAPD entry and at least one master key tuple, then set the per-connection parameters as needed (see Section 6). Proceed with the step 2. 2. Using the per-connection parameters: a. Check that the segment's TCP-AO Length matches the length indicated by the master key indicated by the segment's TCP-AO KeyID field. Touch Expires September 9, 2009 [Page 32] Internet-Draft The TCP Simple Authentication Option March 2009 i. If lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 9.3. b. Use the segment's KeyID value to index the appropriate connection key for this connection. c. Determine the segment's RCV.ESN as described in Section 8.2. d. Determine the segment's traffic key from the master key tuple as described in Section 7.1 (and as likely cached in the TCB). I.e., use the receive_SYN_traffic_key for SYN segments, and the receive_other_traffic_key for other segments. e. Compute the segment's MAC using the master key tuple (and its derived traffic key) and portions of the segment as indicated in Section 7.1. i. If the computed MAC differs from the TCP-AO MAC field value, silently discard the segment. Log and/or signal the event as indicated in Section 9.3. f. Compare the received NextKeyID value to the currently active outgoing KeyID value (Current_key). i. If they match, no further action is required. ii. If they differ, determine whether the NextKeyID keying information is ready. 1. If the NextKeyID keying information is not available, no action is required. 2. If the NextKeyID keying information is available: NOTE: there is an open question as to whether to refuse to change to the suggested NextKeyID if it already has a 2*MSL timer set on it, i.e., to refuse to 'backup' and use a key once it has been previously used. a. Set a timer on the previous value of current_key to ensure that the corresponding master key cannot be removed from the TAPD for 2*MSL. b. Set Current_key to the NextKeyID value. g. Proceed with TCP processing of the segment. Touch Expires September 9, 2009 [Page 33] Internet-Draft The TCP Simple Authentication Option March 2009 It is suggested that TCP-AO implementations validate a segment's Length field before computing a MAC, to reduce the overhead incurred by spoofed segments with invalid TCP-AO fields. Additional reductions in MAC validation overhead can be supported in the MAC algorithms, e.g., by using a computation algorithm that prepends a fixed value to the computed portion and a corresponding validation algorithm that verifies the fixed value before investing in the computed portion. Such optimizations would be contained in the MAC algorithm specification, and thus are not specified in TCP-AO explicitly. Note that the KeyID cannot be used for connection validation per se, because it is not assumed random. 9.6. Impact on TCP Header Size The TCP-AO option typically uses a total of 17-19 bytes of TCP header space. TCP-AO is no larger than and typically 3 bytes smaller than the TCP MD5 option (assuming a 96-bit MAC). Note that TCP option space is most critical in SYN segments, because flags in those segments could potentially increase the option space area in other segments. Because TCP ignores unknown segments, however, it is not possible to extend the option space of SYNs without breaking backward-compatibility. TCP's 4-bit data offset requires that the options end 60 bytes (15 32-bit words) after the header begins, including the 20-byte header. This leaves 40 bytes for options, of which 15 are expected in current implementations (listed below), leaving at most 25 for other uses. Assuming a 96-bit MAC, TCP-AO consumes 16 bytes, leaving up to 9 bytes for additional SYN options (depending on implementation dependant alignment padding, which could consume another 2 bytes at most). o SACK permitted (2 bytes) [RFC2018][RFC3517] o Timestamps (10 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323] After a SYN, the following options are expected in current implementations of TCP: o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883] o Timestamps (10 bytes) [RFC1323] Touch Expires September 9, 2009 [Page 34] Internet-Draft The TCP Simple Authentication Option March 2009 TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a total of 24 bytes for other options, of which the timestamp consumes 10. This leaves 14 bytes, of which 10 are used for a single SACK block. When two SACK blocks are used, such as to handle D-SACK, a smaller TCP-AO MAC would be required to make room for the additional SACK block (i.e., to leave 18 bytes for the D-SACK variant of the SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP- MD5 in the presence of timestamps, because TCP MD5's MAC length is fixed and too large to leave sufficient option space. Although TCP option space is limited, we believe TCP-AO is consistent with the desire to authenticate TCP at the connection level for similar uses as were intended by TCP MD5. 10. Obsoleting TCP MD5 and Legacy Interactions TCP-AO obsoletes TCP MD5. As we have noted earlier: >> TCP implementations MUST support TCP-AO. Systems implementing TCP MD5 only are considered legacy, and ought to be upgraded when possible. In order to support interoperation with such legacy systems until upgrades are available: >> TCP MD5 SHOULD be supported where interactions with legacy systems is needed. >> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for connections unless not supported by its peer, at which point it MAY use TCP MD5 instead. >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a particular TCP connection, but MAY support TCP-AO and TCP MD5 simultaneously for different connections (notably to support legacy use of TCP MD5). The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used for a particular connection in TCP segments. It is possible that the TAPD could be augmented to support TCP MD5, although use of a TAPD-like system is not described in RFC2385. It is possible to require TCP-AO for a connection or TCP MD5, but it is not possible to require 'either'. When an endpoint is configured to require TCP MD5 for a connection, it must be added to all outgoing segments and validated on all incoming segments [RFC2385]. TCP MD5's Touch Expires September 9, 2009 [Page 35] Internet-Draft The TCP Simple Authentication Option March 2009 requirements prohibit the speculative use of both options for a given connection, e.g., to be decided by the other end of the connection. 11. Interactions with Middleboxes TCP-AO may interact with middleboxes, depending on their behavior [RFC3234]. Some middleboxes either alter TCP options (such as TCP-AO) directly or alter the information TCP-AO includes in its MAC calculation. TCP-AO may interfere with these devices, exactly where the device modifies information TCP-AO is designed to protect. 11.1. Interactions with non-NAT/NAPT Middleboxes TCP-AO supports middleboxes that do not change the IP addresses or ports of segments. Such middleboxes may modify some TCP options, in which case TCP-AO would need to be configured to ignore all options in the MAC calculation on connections traversing that element. Note that ignoring TCP options may provide less protection, i.e., TCP options could be modified in transit, and such modifications could be used by an attacker. Depending on the modifications, TCP could have compromised efficiency (e.g., timestamp changes), or could cease correct operation (e.g., window scale changes). These vulnerabilities affect only the TCP connections for which TCP-AO is configured to ignore TCP options. 11.2. Interactions with NAT/NAPT Devices TCP-AO cannot interoperate natively across NAT/NAPT devices, which modify the IP addresses and/or port numbers. We anticipate that traversing such devices will require variants of existing NAT/NAPT traversal mechanisms, e.g., encapsulation of the TCP-AO-protected segment in another transport segment (e.g., UDP), as is done in IPsec [RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO, or IPsec NAT traversal can be used instead in such cases [RFC3947]. 12. Evaluation of Requirements Satisfaction TCP-AO satisfies all the current requirements for a revision to TCP MD5, as summarized below [Be07]. 1. Protected Elements A solution to revising TCP MD5 should protect (authenticate) the following elements. This is supported - see Section 7.1. Touch Expires September 9, 2009 [Page 36] Internet-Draft The TCP Simple Authentication Option March 2009 a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that we do not allow optional coverage because IP addresses define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values; if not, a tunnel is required, as noted in Section 11.2. b. TCP header. Note that we do not allow optional port coverage because ports define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values; if not, a tunnel is required, as noted in Section 11.2. c. TCP options. Note that TCP-AO allows exclusion of TCP options from coverage, to enable use with middleboxes that modify options (except when they modify TCP-AO itself). See Section 11. d. TCP payload data. 2. Option Structure Requirements A solution to revising TCP MD5 should use an option with the following structural requirements. This is supported - see Section 7.1. a. Privacy. The option should not unnecessarily expose information about the TCP-AO mechanism. The additional protection afforded by keeping this information private may be of little value, but also helps keep the option size small. TCP-AO exposes only the master key index, MAC, and overall option length on the wire. Note that short MACs could be obscured by using longer option lengths but specifying a short MAC length (this is equivalent to a different MAC algorithm, and is specified in the TAPD entry). See Section 4.2. Touch Expires September 9, 2009 [Page 37] Internet-Draft The TCP Simple Authentication Option March 2009 b. Allow optional per connection. The option should not be required on every connection; it should be optional on a per connection basis. This is supported - see Sections 9.3, 9.4, and 9.5. c. Require non-optional. The option should be able to be specified as required for a given connection. This is supported - see Sections 9.3, 9.4, and 9.5. d. Standard parsing. The option should be easily parseable, i.e., without conditional parsing, and follow the standard RFC 793 option format. This is supported - see Section 4.2. e. Compatible with Large Windows and SACK. The option should be compatible with the use of the Large Windows and SACK options. This is supported - see Section 9.6. The size of the option is intended to allow use with Large Windows and SACK. See also Section 2.1, which indicates that TCP-AO is 3 bytes shorter than TCP MD5 in the default case, assuming a 96-bit MAC. 3. Cryptography requirements A solution to revising TCP MD5 should support modern cryptography capabilities. a. Baseline defaults. The option should have a default that is required in all implementations. TCP-AO uses a default required algorithm as specified in [ao- crypto], as noted in Section 7.1. Touch Expires September 9, 2009 [Page 38] Internet-Draft The TCP Simple Authentication Option March 2009 b. Good algorithms. The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms should be avoided. TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also specified in [ao-crypto]. The PRF input string follows the typical design (see [ao-crypto]). c. Algorithm agility. The option should support algorithms other than the default, to allow agility over time. TCP-AO allows any desired algorithm, subject to TCP option space limitations, as noted in Section 4.2. The TAPD allows separate connections to use different algorithms, both for the MAC and the PRF. d. Order-independent processing. The option should be processed independently of the proper order, i.e., they should allow processing of TCP segments in the order received, without requiring reordering. This avoids the need for reordering prior to processing, and avoids the impact of misordered segments on the option. This is supported - see Sections 9.3, 9.4, and 9.5. Note that pre-TCP processing is further required, because TCP segments cannot be discarded solely based on a combination of connection state and out-of-window checks; many such segments, although discarded, cause a host to respond with a replay of the last valid ACK, e.g. [RFC793]. See also the derivation of the ESN, which is reconstituted at the receiver using a demonstration algorithm that avoids the need for reordering (in Section 8.2). Touch Expires September 9, 2009 [Page 39] Internet-Draft The TCP Simple Authentication Option March 2009 e. Security parameter changes require key changes. The option should require that the key change whenever the security parameters change. This avoids the need for coordinating option state during a connection, which is typical for TCP options. This also helps allow "bump in the stack" implementations that are not integrated with endpoint TCP implementations. TAPD parameters that should not change during a connection (by defininition, e.g., TCP connection ID, receiver TCP connection ID, TCP option exclusion list) cannot change. Other parameters change only when a master key is changed, using the master key tuple mechanism in the TAPD. See Section 5. 4. Keying requirements. A solution to revising TCP MD5 should support manual keying, and should support the use of an external automated key management system (e.g., a protocol or other mechanism). Note that TCP-AO does not specify a master key management system, but does indicate a proposed interface to the TAPD, allowing a completely separate master key system, as noted in Section 5. a. Intraconnection rekeying. The option should support rekeying during a connection, to avoid the impact of long-duration connections. This is supported by the KeyID and multiple master key tuples in a TAPD entry; see Section 5. b. Efficient rekeying. The option should support rekeying during a connection without the need to expend undue computational resources. In particular, the options should avoid the need to try multiple keys on a given segment. This is supported by the use of the KeyID. See Section 8.1. Touch Expires September 9, 2009 [Page 40] Internet-Draft The TCP Simple Authentication Option March 2009 c. Automated and manual keying. The option should support both automated and manual keying. The use of a separate TAPD allows external automated and manual keying. See Section 5. This capability is enhanced by the generation of unique per-connection keys, which enables use of manual master keys with automatically generated connection keys as noted in Section 7.2. d. Key management agnostic. The option should not assume or require a particular key management solution. This is supported by use of a separate TAPD. See Section 5. 5. Expected Constraints A solution to revising TCP MD5 should also abide by typical safe security practices. a. Silent failure. Receipt of segments failing authentication must result in no visible external action and must not modify internal state, and those events should be logged. This is supported - see Sections 9.3, 9.4, and 9.5. b. At most one such option per segment. Only one authentication option can be permitted per segment. This is supported by the protocol requirements - see Section 4.2. c. Outgoing all or none. Segments out of a TCP connection are either all authenticated or all not authenticated. This is supported - see Section 9.4. Touch Expires September 9, 2009 [Page 41] Internet-Draft The TCP Simple Authentication Option March 2009 d. Incoming all checked. Segments into a TCP connection are always checked to determine whether their authentication should be present and valid. This is supported - see Section 9.5. e. Non-interaction with TCP MD5. The use of this option for a given connection should not preclude the use of TCP MD5, e.g., for legacy use, for other connections. This is supported - see Section 10. f. Optional ICMP discard. The option should allow certain ICMPs to be discarded, notably Type 3 (destination unreachable), Codes 2-4 (transport protocol unreachable, port unreachable, or fragmentation needed and IP DF field set), i.e., the ones indicating the failure of the endpoint to communicate. This is supported - see Section 13. g. Maintain TCP connection semantics, in which the socket pair alone defines a TCP association and all its security parameters. This is supported - see Sections 5 and 11. 13. Security Considerations Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host performance. Connections that are known to use TCP-AO can be attacked by transmitting segments with invalid MACs. Attackers would need to know only the TCP connection ID and TCP-AO Length value to substantially impact the host's processing capacity. This is similar to the susceptibility of IPsec to on-path attacks, where the IP addresses and SPI would be visible. For IPsec, the entire SPI space (32 bits) is arbitrary, whereas for routing protocols typically only the source port (16 bits) is arbitrary. As a result, it would be easier for an off-path attacker to spoof a TCP-AO segment that could cause receiver validation effort. However, we note that between Internet routers both ports could be arbitrary (i.e., determined a- priori out of band), which would constitute roughly the same off-path antispoofing protection of an arbitrary SPI. Touch Expires September 9, 2009 [Page 42] Internet-Draft The TCP Simple Authentication Option March 2009 TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets typically occur after peer crashes, either in response to new connection attempts or when data is sent on stale connections; in either case, the recovering endpoint may lack the connection key required (e.g., if lost during the crash). This may result in time- outs, rather than more responsive recovery after such a crash. As noted in Section 7.2, such cases may also result in persistent TCP state for old connections that cannot be cleared, and so implementations should be capable of detecting an excess of such connections and clearing their state if needed to protect memory utilization [Je07]. TCP-AO does not include a fast decline capability, e.g., where a SYN- ACK is received without an expected TCP-AO option and the connection is quickly reset or aborted. Normal TCP operation will retry and timeout, which is what should be expected when the intended receiver is not capable of the TCP variant required anyway. Backoff is not optimized because it would present an opportunity for attackers on the wire to abort authenticated connection attempts by sending spoofed SYN-ACKs without the TCP-AO option. TCP-AO is intended to provide similar protections to IPsec, but is not intended to replace the use of IPsec or IKE either for more robust security or more sophisticated security management. TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes recommendations regarding dropping ICMPs in certain contexts, or requiring that they are endpoint authenticated in others [RFC4301]. There are other mechanisms proposed to reduce the impact of ICMP attacks by further validating ICMP contents and changing the effect of some messages based on TCP state, but these do not provide the level of authentication for ICMP that TCP-AO provides for TCP [Go07]. >> A TCP-AO implementation MUST allow the system administrator to configure whether TCP will ignore incoming ICMP messages of Type 3 (destination unreachable) Codes 2-4 (protocol unreachable, port unreachable, and fragmentation needed - 'hard errors') intended for connections that match TAPD entries with non-NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be logged. This control affects only ICMPs that currently require 'hard errors', which would abort the TCP connection [RFC1122]. This recommendation is intended to be similar to how IPsec would handle those messages [RFC4301]. TCP-AO includes the TCP connection ID (the socket pair) in the MAC calculation. This prevents different concurrent connections using the Touch Expires September 9, 2009 [Page 43] Internet-Draft The TCP Simple Authentication Option March 2009 same connection key (for whatever reason) from potentially enabling a traffic-crossing attack, in which segments to one socket pair are diverted to attack a different socket pair. When multiple connections use the same master key, it would be useful to know that packets intended for one ID could not be (maliciously or otherwise) modified in transit and end up being authenticated for the other ID. The ID cannot be zeroed, because to do so would require that the TAPD index was unique in both directions (ID->key and key->ID). That requirement would place an additional burden of uniqueness on master keys within endsystems, and potentially across endsystems. Although the resulting attack is low probability, the protection afforded by including the received ID warrants its inclusion in the MAC, and does not unduly increase the MAC calculation or master key management system. The use of any security algorithm can present an opportunity for a CPU DOS attack, where the attacker sends false, random segments that the receiver under attack expends substantial CPU effort to reject. In IPsec, such attacks are reduced by the use of a large Security Parameter Index (SPI) and Sequence Number fields to partly validate segments before CPU cycles are invested validated the Integrity Check Value (ICV). In TCP-AO, the socket pair performs most of the function of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay attacks, isn't needed due to TCP's Sequence Number, which is used to reorder received segments (provided the sequence number doesn't wrap around, which is why TCP-AO adds the ESN in Section 8.2). TCP already protects itself from replays of authentic segment data as well as authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic replays could affect TCP congestion control [Sa99]. TCP-AO does not protect TCP congestion control from this last form of attack due to the cumbersome nature of layering a windowed security sequence number within TCP in addition to TCP's own sequence number; when such protection is desired, users are encouraged to apply IPsec instead. Further, it is not useful to validate TCP's Sequence Number before performing a TCP-AO authentication calculation, because out-of-window segments can still cause valid TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is similarly not useful to add a separate Sequence Number field to the TCP-AO option, because doing so could cause a change in TCP's behavior even when segments are valid. 14. IANA Considerations [NOTE: This section be removed prior to publication as an RFC] The TCP-AO option defines no new namespaces. Touch Expires September 9, 2009 [Page 44] Internet-Draft The TCP Simple Authentication Option March 2009 The TCP-AO option requires that IANA allocate a value from the TCP option Kind namespace, to be replaced for TCP-IANA-KIND throughout this document. To specify MAC and PRF algorithms, TCP-AO refers to a separate document that may involve IANA actions [ao-crypto]. 15. References 15.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol," STD-7, RFC-793, Standard, Sept. 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers," RFC-1122, Oct. 1989. [RFC2018] Mathis, M., J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgement Options", RFC-2018, Proposed Standard, April 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP-14, RFC-2119, Best Current Practice, March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option," RFC-2385, Proposed Standard, Aug. 1998. [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH," RFC-2403, Proposed Standard, Nov. 1998. [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC-2460, Proposed Standard, Dec. 1998. [RFC2883] Floyd, S., J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC-2883, Proposed Standard, July 2000. [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC-3517, Proposed Standard, April 2003. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC-4306, Proposed Standard, Dec. 2005. Touch Expires September 9, 2009 [Page 45] Internet-Draft The TCP Simple Authentication Option March 2009 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto, Mar. 2009. 15.2. Informative References [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem Statement and Requirements for a TCP Authentication Option," draft-bellovin-tcpsec-01, (work in progress), Jul. 2007. [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, "Authentication for TCP-based Routing and Management Protocols," draft-bonica-tcp-auth-06, (work in progress), Feb. 2007. [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- attacks-04, (work in progress), Oct. 2008. [Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist Condition," draft-mahesh-persist-timeout-02, (work in progress), Oct. 2007. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, Informational, April 1992. [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for High Performance," RFC-1323, May 1992. [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," RFC-1948, Informational, May 1996. [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC-2104, Informational, Feb. 1997. [RFC2766] Tsirtsis, G., P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)," RFC-2766, Proposed Standard, Feb. 2000. [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," RFC-3234, Informational, Feb. 2002. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option," RFC-3562, Informational, July 2003. Touch Expires September 9, 2009 [Page 46] Internet-Draft The TCP Simple Authentication Option March 2009 [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, "Negotiation of NAT-Traversal in the IKE," RFC-3947, Proposed Standard, Jan. 2005. [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet Protocol," RFC-4301, Proposed Standard, Dec. 2005. [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," RFC-4808, Informational, Mar. 2007. [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," RFC-4953, Informational, Jul. 2007. [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP Congestion Control with a Misbehaving Receiver," ACM Computer Communications Review, V29, N5, pp71-78, October 1999. [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," Specification SDN.401, Revision 1.2, July 12, 1988. [To06] Touch, J., A. Mankin, "The TCP Simple Authentication Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work in progress), Oct. 2006. [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. [We05] Weis, B., "TCP Message Authentication Code Option," draft- weis-tcp-mac-option-00, (expired work in progress), Dec. 2005. 16. Acknowledgments Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial feedback on this document. This document was prepared using 2-Word-v2.0.template.dot. Touch Expires September 9, 2009 [Page 47] Internet-Draft The TCP Simple Authentication Option March 2009 Authors' Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 Email: touch@isi.edu URL: http://www.isi.edu/touch Allison Mankin Johns Hopkins Univ. Washington, DC U.S.A. Phone: 1 301 728 7199 Email: mankin@psg.com URL: http://www.psg.com/~mankin/ Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 U.S.A. Email: rbonica@juniper.net Touch Expires September 9, 2009 [Page 48]