Skip to main content

The TCP Authentication Option
RFC 5925

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    tcpm mailing list <>, 
    tcpm chair <>
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:

Ballot Text

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
  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.


  Wesley Eddy ( is the document shepherd. Lars
  Eggert ( reviewed the document for the IESG.

RFC Editor Note