The TCP Authentication Option
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, tcpm mailing list <firstname.lastname@example.org>, tcpm chair <email@example.com> Subject: Protocol Action: 'The TCP Authentication Option' to Proposed Standard The IESG has approved the following document: - 'The TCP Authentication Option ' <draft-ietf-tcpm-tcp-auth-opt-11.txt> as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-11.txt
Technical Summary 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 tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT 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 a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. Working Group Summary There was some initial controversy on this work due to the prior rushed deployment of a similar mechanism which had not been reviewed by the WG. The WG's decision to build an incompatible mechanism was not unanimous, with strong initial resistance from one of the implementers of the prior solution, however other implementors of that solution did come out in support of the WG's product during the course of its evolution. Document Quality Several widely-deployed implementations exist of a pre-WG protocol which is not compatible with the WG's protocol, but very similar both functionally and on the wire. Some vendors have expressed strong support for implementing the WG's product. At one point, a Linux implementation was being pursued of the WG draft, though its status with regard to the current document is unknown. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (firstname.lastname@example.org) reviewed the document for the IESG.