TCPM WG J. Touch Internet Draft USC/ISI Expires: December 2006 A. Mankin June 9, 2006 The TCP Simple Authentication Option draft-touch-tcpm-tcp-simple-auth-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 December 9, 2006. Abstract This document specifies a TCP Simple Authentication Option (TCP-SA) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and provides more details on the association of security associations with TCP connections. TCP-SA assumes that rekeying is supported by restarting the TCP connection, and so omits in-band parameter negotiation, session key establishment, and rekeying support; where such features are desired, use of the IPsec suite is recommended. Touch & Mankin Expires December 9, 2006 [Page 1] Internet-Draft The TCP Simple Authentication Option June 2006 The result is intended to be a simple modification to support current infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to support a larger set of hashes with minimal other system and operational changes. TCP-SA requires no new option identifier, though it is intended to be mutually exclusive with TCP/MD5 on a given TCP connection. 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]. Table of Contents 1. Introduction...................................................3 1.1. Executive Summary.........................................3 1.2. Summary of RFC-2119 Requirements..........................4 2. The TCP Simple Authentication Option...........................5 2.1. Review of TCP/MD5 Option..................................5 2.2. TCP-SA Option.............................................5 3. Security Association Management................................7 4. TCP-SA Interaction with TCP....................................9 4.1. User Interface............................................9 4.2. TCP States and Transitions................................9 4.3. TCP Segments.............................................10 4.4. Sending TCP Segments.....................................10 4.5. Receiving TCP Segments...................................11 4.6. Impact on TCP Header Size................................12 5. Key Establishment and Duration Issues.........................12 6. Use of TCP-SA with Routing Protocols..........................13 7. Interactions with TCP/MD5.....................................13 8. Security Considerations.......................................14 9. IANA Considerations...........................................15 10. Conclusions..................................................15 11. Acknowledgments..............................................15 12. References...................................................15 12.1. Normative References....................................15 12.2. Informative References..................................16 Author's Addresses...............................................17 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................18 Copyright Statement..............................................18 Acknowledgment...................................................18 Touch & Mankin Expires December 9, 2006 [Page 2] Internet-Draft The TCP Simple Authentication Option June 2006 1. Introduction The TCP MD5 Signature (TCP/MD5) is a TCP option that authenticates TCP segments, including the TCP pseudo-header, 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. There have been many recently-documented 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 [Be05] [Bu06]. TCP/MD5 also lacks both key management and algorithm agility. This document proposes to add the latter, but suggests that TCP should not be the framework for cryptographic key management. This document updates the TCP/MD5 option to become a more general TCP Simple Authentication Option (TCP-SA), to support the use of other, stronger hash functions and to provide a more structured recommendation on external key management. 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 parameter negotiation, session key negotiation, or intra-connection rekeying are desired. 1.1. Executive Summary This document updates TCP/MD5 as follows [RFC2385]: o Reuses TCP/MD5's option Kind (=19), but allows TCP/MD5 to continue to be used for other connections. o Replaces signed MD5 with HMAC-MD5-96, and allows other MACs at the implementer's discretion. o Does not allow rekeying during a TCP connection (although how to achieve this is not specified in RFC2385, notably in its impact to TCP windowing). o Provides more detail in how this option interacts with TCP's states, event processing, and user interface. o Proposed option is 4 bytes shorter (14 bytes overall, rather than 18) in the default case (HMAC-MD5-96). This document differs from currently competing proposals to update TCP/MD5 as follows [Bo05][We06]: Touch & Mankin Expires December 9, 2006 [Page 3] Internet-Draft The TCP Simple Authentication Option June 2006 o Does not require a new TCP option Kind value. o Does not support rekeying during a connection. o Does not support dynamic parameter negotiation. o Does not require additional timers. o Always authenticates the TCP options as well as the segment pseudoheader, header, and data. o Provides more detail in how this option interacts with TCP's states, event processing, and user interface. o Proposed option is 2 bytes shorter (14 bytes overall, rather than 16) in the default case (HMAC-MD5-96) o Does not expose the MAC algorithm in the header. o Does not require a key ID. This document differs from an IPsec/IKE solution as follows [RFC4301][RFC4306] o Does not support rekeying during a connection. o Does not support dynamic parameter negotiation. o Does not support establishment of a per-connection key. o Does not require a key ID (SPI). o Does not protect from replay attacks. o Forces a change of connection key when a connection restarts, even when reusing a TCP socket pair (IP addresses and port numbers). o Does not support encryption. o Does not authenticate ICMP messages (some may be authenticated in IPsec, depending on the configuration). 1.2. Summary of RFC-2119 Requirements [NOTE: a summary will be placed here prior to last call] Touch & Mankin Expires December 9, 2006 [Page 4] Internet-Draft The TCP Simple Authentication Option June 2006 2. The TCP Simple Authentication Option The TCP Simple Authentication Option (TCP-SA) re-uses the Kind value currently assigned to TCP/MD5. 2.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 Current TCP MD5 Option [RFC2385] In the current 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 current 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. TCP header excluding options and checksum 3. TCP data 4. connection key 2.2. TCP-SA Option The new TCP-SA option is intended to be a superset of the TCP/MD5 option. TCP-SA reuses the same Kind and Length fields, and is shown in Figure 2. Touch & Mankin Expires December 9, 2006 [Page 5] Internet-Draft The TCP Simple Authentication Option June 2006 +---------+---------+-----------------... | Kind=19 | Len=var | MAC... ... +---------+---------+-----------------... Figure 2 Proposed TCP-SA Option The TCP-SA defines the following fields: o Kind: An unsigned field indicating the TCP Option. TCP-SA reuses the Kind value=19. Because of how keys are managed (see Section 3), an endpoint will not use TCP-SA for the same connection where TCP/MD5 is used, and so there would be no confusion as to how to interpret incoming Kind=19 segments. o Length: An unsigned 8-bit field indicating the length of the TCP- SA option in bytes, including the Kind and Length fields. >> The Length MUST be greater than or equal to 2. >> The Length value MUST be consistent with the TCP header length. Values of 2 and other small values are of dubious utility but not specifically prohibited. o MAC: The MAC is a message authentication code. Typical MACs are 96-128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. >> TCP-SA MUST support HMAC-MD5-96; other MACs MAY be supported [RFC2403]. >> A single TCP segment MUST NOT have more than one TCP-SA option. The MAC is defined over the following fields in the following order: 1. the TCP pseudoheader: IP source and destination addresses, zero- padded protocol number and segment length, all in network byte order, i.e., exactly as used for the TCP checksum [RFC793]: Touch & Mankin Expires December 9, 2006 [Page 6] Internet-Draft The TCP Simple Authentication Option June 2006 +--------+--------+--------+--------+ | Source Address | +--------+--------+--------+--------+ | Destination Address | +--------+--------+--------+--------+ | zero | PTCL | TCP Length | +--------+--------+--------+--------+ Figure 3 TCP pseudoheader [RFC793] 2. TCP header, including options, and where the checksum and TCP-SA MAC fields are set to zero, all in network byte order 3. TCP data 4. Connection key: a key to be used to in the MAC algorithm, as required by the particular MAC algorithm used TCP-SA includes the TCP options because these options are intended to be end-to-end and some are required for proper TCP operation (e.g., SACK, timestamp). Middleboxes may alter TCP options en-route are a kind of attack and would be successfully detected by TCP-SA. The TCP-SA option does not indicate the MAC algorithm either implicitly (as with TCP/MD5) or explicitly (as with some proposed alternatives) [RFC2385][Bo05][We05]. The particular algorithm used is considered part of the configuration state of the security association of the connection and is managed separately (see Section 3). 3. Security Association Management TCP-SA relies on a TCP Security Association Database (TSAD). TSAD entries are assumed to be shared at the endpoints where TCP-SA is used, in advance of the connection: 1. TCP connection identifier (ID), i.e., socket pair - IP source address, IP destination address, TCP source port, and TCP destination address [RFC793]. TSAD entries are uniquely determined by their TCP connection ID. 2. For each of inbound (received TCP segments) and outbound (sent TCP segments) on this connection: Touch & Mankin Expires December 9, 2006 [Page 7] Internet-Draft The TCP Simple Authentication Option June 2006 a. MAC type for this connection. This includes the MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and the length of the MAC stored in the option (e.g., 96, 128, etc.). Also, a setting of NONE must be supported, to indicate that authentication is not used in this direction; this allows asymmetric use of TCP-SA. At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this is not strictly required. >> When the outbound MAC is set to values other than NONE, TCP-SA MUST occur in every outbound TCP segment for that connection; when set to NONE, TCP-SA MUST NOT occur in those segments. >> When the inbound MAC is set to values other than NONE, TCP- SA MUST occur in every inbound TCP segment for that connection; when set to NONE, TCP-SA MUST NOT occur in those segments. b. Connection key. A byte sequence used for connection keying, this is intended to be a per-connection key, and may be derived from a separate shared key by an external protocol over a separate channel. It is anticipated that TSAD entries for active or opening TCP connections can be stored in the TCP Control Block (TCB); TSAD entries for pending connections (in passive or active OPEN) may be stored in a separate database. This means that in a single host there should be only a single database which is consulted by all pending connections, the same way that there is only one set of TCBs. Multiple databases could be used to support virtual hosts, i.e., groups of interfaces. Note that TSAD and the TCP-SA fields omit a key ID; the TCP connection ID already uniquely specifies the TSAD entry, so a separate ID is not needed. The TCP-SA fields omit an explicit algorithm ID; that algorithm is already specified by the TCP connection ID and stored in the TSAD. Also note that this document does not address how TSAD entries are created or destroyed. It is presumed that a TSAD entry affecting particular connection cannot be destroyed during an active connection - or, equivalently, that its parameters are copied local to the connection and so changes would affect only new connections. The TSAD could be managed by a separate application protocol if desired. Touch & Mankin Expires December 9, 2006 [Page 8] Internet-Draft The TCP Simple Authentication Option June 2006 4. TCP-SA Interaction with TCP The following is a description of how various TCP states, segments, events, and interfaces. This description is intended to augment the description of TCP as provided in RFC793 [RFC793]. 4.1. User Interface The TCP user interface supports active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS and ABORT. >> 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 TSAD entry can be configured. >> New TSAD entries MUST be checked against a cache of previously used TSAD entries. Users are advised to not inappropriately reuse keys [RFC3562]. >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a current or pending connection to be read (for confirmation). >> TCP STATUS MUST NOT allow TSAD entries for ongoing TCP connections (i.e., not in the CLOSED state) to be modified. TSAD entries for TCP connections not in the CLOSED state are deleted indirectly using the CLOSE or ABORT commands. >> Use of CLOSE or ABORT MUST retain the TSAD entry in a cache to assist with checking for key reuse. This entry may correspond to one of the wait states of TCP (FINE- WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT), or may be stored separately (for connections proceeding rapidly to CLOSED). The size of this cache and duration of retained entries is up to the user, where we again advise the application of known key management principles [RFC3562]. TCP SEND and RECEIVE are not affected by TCP-SA. 4.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. Touch & Mankin Expires December 9, 2006 [Page 9] Internet-Draft The TCP Simple Authentication Option June 2006 >> A TSAD entry MAY be associated with any TCP state. >> A TSAD 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. 4.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. >> All TCP segments MUST be checked against the TSAD for matching TCP connection IDs. >> TCP segments matching TSAD entries with non-NULL MACs without TCP- SA, or with TCP-SA and whose MACs do not validate MUST be silently discarded. >> TCP segments with TCP-SA but not matching TSAD entries MUST be silently accepted. >> 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-SA 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. Note that the TCP-SA option is not negotiated. It is the responsibility of the receiver to determine when TCP-SA is required and to enforce that requirement. >> Receivers MAY silently accept TCP segments with the TCP-SA option. 4.4. Sending TCP Segments The following procedure describes the modifications to TCP to support TCP-SA when a segment departs. 1. Check the segment's TCP connection ID against the TSAD Touch & Mankin Expires December 9, 2006 [Page 10] Internet-Draft The TCP Simple Authentication Option June 2006 2. If there is NO TSAD entry, omit the TCP-SA option. Proceed with computing the TCP checksum and transmit the segment. 3. If there is a TSAD entry and the outgoing MAC is NONE, omit the TCP-SA option. Proceed with computing the TCP checksum and transmit the segment. 4. If there is a TSAD entry and the outgoing MAC is not NONE: a. Augment the TCP header with the TCP-SA, inserting the appropriate Length based on the indexed TSAD entry. Update the TCP header length accordingly. b. Compute the MAC using the indexed TSAD connection key, MAC, and data from the segment as specified in Section 2.2. c. Insert the MAC in the TCP-SA field. d. Proceed with computing the TCP checksum and transmit the segment. 4.5. Receiving TCP Segments The following procedure describes the modifications to TCP to support TCP-SA when a segment arrives. 1. Check the segments TCP connection ID against the TSAD 2. If there is NO TSAD entry, proceed with TCP processing. 3. If there is a TSAD entry and the incoming MAC is NONE, proceed with TCP processing. 4. If there is a TSAD entry and the incoming MAC is not NONE: a. Check that the segment's TCP-SA Length matches the indexed TSAD Length. i. If Lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 4.3. b. Compute the segment's MAC using the indexed TSAD MAC algorithm and connection key, and portions of the segment as indicated in Section 2.2. Touch & Mankin Expires December 9, 2006 [Page 11] Internet-Draft The TCP Simple Authentication Option June 2006 i. If the computed MAC differs from the TCP-SA MAC field value, silently discard the segment. Log and/or signal the event as indicated in Section 4.3. c. Proceed with TCP processing of the segment. It is suggested that TCP-SA implementations validate a segment's Length field before computing a MAC, to reduce the overhead incurred by spoofed segments with invalid TCP-SA fields. 4.6. Impact on TCP Header Size The TCP-SA option typically uses a total of 16-18 bytes of TCP header space. TCP-SA is no larger than and typically 2 bytes smaller than the TCP/MD5 option. Although TCP option space is limited, we believe TCP-SA is consistent with the desire to authenticate TCP at the connection level for similar uses as were intended by TCP/MD5. 5. Key Establishment and Duration Issues The TCP-SA option does not provide connection key negotiation, parameter negotiation (MAC algorithm, length, or use of the TCP-SA option), or rekeying during a connection. We assume out-of-band mechanisms for key establishment and parameter negotiation. Deployments desiring more dynamic key and/or parameter management are encouraged to use the IPsec security suite [RFC4301][RFC4306]. We encourage users of TCP-SA to apply known techniques for generating appropriate keys, including the use of reasonable connection key lengths, limited connection key sharing, and limiting the duration of connection key use [RFC3562]. TCP-SA does not support rekeying as such. Connections needing rekeying would close the existing connection using the old connection key and start a new connection using a new connection key. Applications using TCP-SA will work more efficiently if they support graceful transition between sequences of such connections, either by handoff between the two connections while both are open or by limiting the impact of the first connection closing. Such support is already being developed for Internet routing protocols, as discussed in Section 6. Implementations are encouraged to keep keys in a suitably private area. Users of TCP-SA are encouraged to use different keys for inbound and outbound MACs on a given TCP connection. Touch & Mankin Expires December 9, 2006 [Page 12] Internet-Draft The TCP Simple Authentication Option June 2006 6. Use of TCP-SA with Routing Protocols TCP-SA assumes that applications requiring rekeying are not significantly affected by TCP connection reestablishment, because that is the only method for changing keys. Some current routing protocols, notably BGP, may be affected because they interpret the stability of TCP connections to indicate the stability of the communication path to its peers (or of the peers themselves). This problem has already been addressed in extensions to BGP and BGP for MPLS, in a mechanism known as "graceful restart" [Re05][Sa04]. Without graceful restart, when a TCP connection is interrupted - either deliberately (shutdown BGP client) or otherwise (via an attack) - BGP flushes the routes of that peer from its tables, causing substantial service interruption, and taking a long time to reestablish [To06]. In graceful restart, BGP signals its peer in-band that a connection is to be closed, and the routes are not flushed. Although TCP/MD5 is used for other routing protocols besides BGP, notably LDP, PCEP, and MSDP, it is not known whether these protocols support similar graceful restart or other handoff mechanisms. Further, the cost of restarting these protocols is nonzero; some protocols, notably BGP, exchange their entire routing tables upon restart rather than only their updates. This can result in longer convergence time and increased bandwidth utilization. In cases where graceful restart is not feasible or efficient, it may be necessary to support secure associations with dynamic rekeying. In those cases, a true key management protocol - such as IKE - is recommended. Such a mechanism is not included in TCP-AO for simplicity, notably to avoid complex interactions between key activity periods and TCP's windowing algorithm. [can anyone suggest what LDP, PCEP, or MSDP do?] [is there a citation for BGP restart time/cost?] 7. Interactions with TCP/MD5 TCP-SA is intended to be deployed without regard for existing TCP/MD5 option support. >> A TCP implementation MUST NOT use both TCP-SA and TCP/MD5 for a particular TCP connection, but MAY support TCP-SA and TCP/MD5 simultaneously for different connections. Touch & Mankin Expires December 9, 2006 [Page 13] Internet-Draft The TCP Simple Authentication Option June 2006 There is no need to explicitly indicate which of TCP-SA or TCP/MD5 is used for a particular connection in the TCP segments. Even where the two used the same hash (e.g., if TCP-SA were to use MD5 rather than HMAC-MD5) and the same length (128 bits), TCP-SA computes its MAC over different data (including the TCP-SA option, notably, with the MAC zeroed) than TCP/MD5. The probability of a TCP-SA segment being validated by TCP/MD5 or the converse is roughly equivalent to that of a random party guessing a valid MAC. 8. Security Considerations Use of TCP-SA, like use of TCP/MD5 or IPsec, will impact host performance. Connections that are known to use TCP-SA can be attacked by transmitting segments with invalid MACs. Attackers would need to know only the TCP connection ID and TCP-SA 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-SA 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. TCP-SA, 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. TCP-SA does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. TCP-SA 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-SA 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 Touch & Mankin Expires December 9, 2006 [Page 14] Internet-Draft The TCP Simple Authentication Option June 2006 of some messages based on TCP state, but these do not provide the level of authentication for ICMP that TCP-SA provides for TCP [Go06]. >> A TCP-SA implementation MUST allow the system administrator to configure whether TCP will ignore incoming ICMP messages of Type 3 Codes 2-4 intended for connections that match TSAD 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. This recommendation is intended to be similar to how IPsec would handle those messages [RFC4301]. 9. IANA Considerations The TCP-SA option reuses the TCP MD5 Signature option (TCP/MD5), where Kind=19. This document augments that use of this Kind value, but there is no need to deprecate or override the use of TCP/MD5. This document suggests that only one key algorithm would be applicable in either case, and so there would be no confusion for a given Length and key value as used for authenticating segments of a given TCP connection. If this document is approved as an IETF Standard, IANA is requested to add a registration for TCP-SA to Kind=19, along with the existing registration for TCP/MD5, and add a pointer to this document. 10. Conclusions (to be completed) 11. Acknowledgments This document was inspired by the revisions to TCP/MD5 suggested by Brian Weis and Ron Bonica [Bo06][We05]. Russ Housley suggested L4/application layer management of the TSAD. 12. References 12.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol," STD-007, RFC- 793, [Standard], Sept. 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, [Best Current Practice], March 1997. Touch & Mankin Expires December 9, 2006 [Page 15] Internet-Draft The TCP Simple Authentication Option June 2006 [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. [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet Protocol," RFC-4301, [Proposed Standard], Dec. 2005. 12.2. Informative References [Be05] Bellovin, S., E. Rescorla, "Deploying a New Hash Algorithm," presented at the First NIST Cryptographic Hash Workshop, Oct. 2005. http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm [Bu06] Burr, B., "NIST Cryptographic Standards Status Report," Invited talk at Internet 2 5th Annual PKI R&D Workshop, April 2006. http://middleware.internet2.edu/pki06/proceedings/ [Bo06] Bonica, R., "Authentication for TCP-based Routing and Management Protocols," draft-bonica-tcp-auth-04, (work in progress), Jan. 2006. [Go06] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- attacks-00, Feb. 2006. [Re05] Rekhter, Y., R. Aggarwal, "Graceful Restart Mechanism for BGP with MPLS," draft-ietf-mpls-bgp-mpls-restart-05, (work in progress), Aug. 2005. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, April 1992. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option," RFC-3562, July 2003. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC- 4306, [Proposed Standard], Dec. 2005. [Sa04] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Restart Mechanism for BGP," draft-ietf-idr- restart-10 (work in progress), June 2004. [To06] Touch, J., "Defending TCP Against Spoofing Attacks," draft- ietf-tcpm-tcp-antispoof-04, May 2006. Touch & Mankin Expires December 9, 2006 [Page 16] Internet-Draft The TCP Simple Authentication Option June 2006 [We05] Weis, B., "TCP Message Authentication Code Option," draft- weis-tcp-mac-option-00 (work in progress), Dec. 2005. [We06] Weis, B., "Automated key selection extension for the TCP Authentication Option," draft-weis-tcp-auth-auto-ks-00 (work in progress), Feb. 2006. Author's 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 Washington, DC U.S.A. Phone: 1 301 728 7199 Email: mankin@psg.com URL: http://www.psg.com/~mankin/ Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Touch & Mankin Expires December 9, 2006 [Page 17] Internet-Draft The TCP Simple Authentication Option June 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Touch & Mankin Expires December 9, 2006 [Page 18]