draft-ietf-tcpm-tcp-auth-opt-02.txt   draft-ietf-tcpm-tcp-auth-opt-03.txt 
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: May 2009 R. Bonica Expires: August 2009 R. Bonica
Juniper Networks Juniper Networks
November 3, 2008 February 16, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-02.txt draft-ietf-tcpm-tcp-auth-opt-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 3, 2009. This Internet-Draft will expire on August 16, 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.
Abstract Abstract
This document specifies the TCP Authentication Option (TCP-AO), which This document specifies the TCP Authentication Option (TCP-AO), which
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
specifies the use of stronger Message Authentication Codes (MACs), specifies the use of stronger Message Authentication Codes (MACs),
protects against replays even for long-lived TCP connections, and protects against replays even for long-lived TCP connections, and
provides more details on the association of security with TCP provides more details on the association of security with TCP
connections than TCP MD5. TCP-AO is compatible with either static connections than TCP MD5. TCP-AO is compatible with either static
keying or an external, out-of-band key management mechanism; in master key configuration or an external, out-of-band master key
either case, TCP-AO also protects connections when using the same key management mechanism; in either case, TCP-AO also protects
across repeated instances of a connection. The result is intended to connections when using the same master key across repeated instances
support current infrastructure uses of TCP MD5, such as to protect of a connection, using connection keys derived from the master key.
long-lived connections (as used, e.g., in BGP and LDP), and to The result is intended to support current infrastructure uses of TCP
support a larger set of MACs with minimal other system and MD5, such as to protect long-lived connections (as used, e.g., in BGP
operational changes. TCP-AO uses its own option identifier, even and LDP), and to support a larger set of MACs with minimal other
though used mutually exclusive of TCP MD5 on a given TCP connection. system and operational changes. TCP-AO uses its own option
TCP-AO supports IPv6, and is fully compatible with the requirements identifier, even though used mutually exclusive of TCP MD5 on a given
for the replacement of TCP MD5. TCP connection. TCP-AO supports IPv6, and is fully compatible with
the requirements for the replacement of TCP MD5.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Contributors...................................................3
1.1. Executive Summary.........................................4 2. Introduction...................................................3
1.2. List of TBD Items.........................................5 2.1. Executive Summary.........................................4
1.3. Changes from Previous Versions............................5 2.2. Changes from Previous Versions............................5
1.3.1. New in draft-ietf-tcp-auth-opt-02....................5 2.2.1. New in draft-ietf-tcp-auth-opt-03....................6
1.3.2. New in draft-ietf-tcp-auth-opt-01....................6 2.2.2. New in draft-ietf-tcp-auth-opt-02....................6
1.3.3. New in draft-ietf-tcp-auth-opt-00....................7 2.2.3. New in draft-ietf-tcp-auth-opt-01....................7
1.3.4. New in draft-touch-tcp-simple-auth-03................8 2.2.4. New in draft-ietf-tcp-auth-opt-00....................8
1.3.5. New in draft-touch-tcp-simple-auth-02................8 2.2.5. New in draft-touch-tcp-simple-auth-03................9
1.3.6. New in draft-touch-tcp-simple-auth-01................8 2.2.6. New in draft-touch-tcp-simple-auth-02................9
1.4. Summary of RFC-2119 Requirements..........................8 2.2.7. New in draft-touch-tcp-simple-auth-01................9
2. Conventions used in this document..............................9 3. Conventions used in this document.............................10
3. The TCP Authentication Option..................................9 4. The TCP Authentication Option.................................10
3.1. Review of TCP MD5 Option..................................9 4.1. Review of TCP MD5 Option.................................10
3.2. TCP-AO Option............................................10 4.2. TCP-AO Option............................................11
4. Preventing replay attacks within long-lived connections.......13 5. Preventing replay attacks within long-lived connections.......14
5. Computing connection keys from TSAD entries...................14 6. Computing connection keys from TSAD entries...................16
6. Security Association Management...............................16 7. Security Association Management...............................17
7. TCP-AO Interaction with TCP...................................19 8. TCP-AO Interaction with TCP...................................21
7.1. User Interface...........................................19 8.1. TCP User Interface.......................................21
7.2. TCP States and Transitions...............................20 8.2. TCP States and Transitions...............................22
7.3. TCP Segments.............................................20 8.3. TCP Segments.............................................22
7.4. Sending TCP Segments.....................................21 8.4. Sending TCP Segments.....................................23
7.5. Receiving TCP Segments...................................21 8.5. Receiving TCP Segments...................................24
7.6. Impact on TCP Header Size................................23 8.6. Impact on TCP Header Size................................25
8. Key Establishment and Duration Issues.........................23 9. Connection Key Establishment and Duration Issues..............26
8.1. Key reuse across socket pairs............................24 9.1. Master Key Reuse Across Socket Pairs.....................27
8.2. Key use within a long-lived connection...................24 9.2. Master Key Use Within a Long-lived Connection............27
8.3. Implementing the TSAD as an External Database............24 10. Obsoleting TCP MD5 and Legacy Interactions...................27
9. Obsoleting TCP MD5 and Legacy Interactions....................26 11. Interactions with Middleboxes................................28
10. Interactions with non-NAT/NAPT Middleboxes...................26 11.1. Interactions with non-NAT/NAPT Middleboxes..............28
11. Interactions with NAT/NAPT Devices...........................27 11.2. Interactions with NAT/NAPT Devices......................29
12. Evaluation of Requirements Satisfaction......................27 12. Evaluation of Requirements Satisfaction......................29
13. Security Considerations......................................29 13. Security Considerations......................................35
14. IANA Considerations..........................................32 14. IANA Considerations..........................................37
15. Acknowledgments..............................................32 15. References...................................................37
16. References...................................................32 15.1. Normative References....................................37
16.1. Normative References....................................32 15.2. Informative References..................................38
16.2. Informative References..................................33 16. Acknowledgments..............................................40
1. Introduction 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 TSAD.
Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the
use of ISNs in the connection 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
connection key computation.
2. Introduction
The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates
TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP segments, including the TCP IPv4 pseudoheader, TCP header, and
TCP data. It was developed to protect BGP sessions from spoofed TCP TCP data. It was developed to protect BGP sessions from spoofed TCP
segments which could affect BGP data or the robustness of the TCP segments which could affect BGP data or the robustness of the TCP
connection itself [RFC2385][RFC4953]. connection itself [RFC2385][RFC4953].
There have been many recent concerns about TCP MD5. Its use of a There have been many recent concerns about TCP MD5. Its use of a
simple keyed hash for authentication is problematic because there simple keyed hash for authentication is problematic because there
have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 have been escalating attacks on the algorithm itself [Wa05]. TCP MD5
also lacks both key management and algorithm agility. This document also lacks both key management and algorithm agility. This document
adds the latter, but notes that TCP does not provide a sufficient adds the latter, but notes that TCP does not provide a sufficient
framework for cryptographic key management. This document obsoletes framework for cryptographic key management, because SYN segments lack
the TCP MD5 option with a more general TCP Authentication Option sufficient remaining space to support key coordination in-band (see
(TCP-AO), to support the use of other, stronger hash functions, Section 8.6). This document obsoletes the TCP MD5 option with a more
provide replay protection for long-lived connections and across general TCP Authentication Option (TCP-AO), to support the use of
repeated instances of a single connection, and to provide a more other, stronger hash functions, provide replay protection for long-
structured recommendation on external key management. The result is lived connections and across repeated instances of a single
compatible with IPv6, and is fully compatible with requirements under connection, and to provide a more structured recommendation on
development for a replacement for TCP MD5 [Be07]. 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 This document is not intended to replace the use of the IPsec suite
(IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
fact, we recommend the use of IPsec and IKE, especially where IKE's fact, we recommend the use of IPsec and IKE, especially where IKE's
level of existing support for parameter negotiation, session key level of existing support for parameter negotiation, session key
negotiation, or rekeying are desired. TCP-AO is intended for use only 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 where the IPsec suite would not be feasible, e.g., as has been
suggested is the case for some routing protocols, or in cases where suggested is the case to support some routing protocols, or in cases
keys need to be tightly coordinated with individual transport where keys need to be tightly coordinated with individual transport
sessions [Be07]. sessions [Be07].
Note that TCP-AO obsoletes TCP MD5, although a particular Note that TCP-AO obsoletes TCP MD5, although a particular
implementation may support both for backward compatibility. For a implementation may support both for backward compatibility. For a
given connection, only one can be in use. TCP MD5-protected given connection, only one can be in use. TCP MD5-protected
connections cannot be migrated to TCP-AO because TCP MD5 does not connections cannot be migrated to TCP-AO because TCP MD5 does not
support any changes to a connection's security configuration once support any changes to a connection's security algorithm once
established. established.
1.1. Executive Summary 2.1. Executive Summary
This document replaces TCP MD5 as follows [RFC2385]: This document replaces TCP MD5 as follows [RFC2385]:
o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). 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 for other (legacy) o TCP-AO allows TCP MD5 to continue to be used concurrently for
connections. legacy connections.
o TCP-AO replaces MD5's single MAC algorithm with two prespecified o TCP-AO replaces MD5's single MAC algorithm with MACs specified in
MACs (TBD-WG-MACS), and allows extension to include other MACs. a separate document and allows extension to include other MACs.
o TCP-AO allows rekeying during a TCP connection, assuming that an o TCP-AO allows rekeying during a TCP connection, assuming that an
out-of-band protocol or manual mechanism coordinates the key out-of-band protocol or manual mechanism coordinates the key
change. In such cases, a key ID allows the efficient concurrent change. In such cases, a key ID allows the efficient concurrent
use of multiple keys. Note that TCP MD5 does not preclude rekeying use of multiple keys. Note that TCP MD5 does not preclude rekeying
during a connection, but does not require its support either. during a connection, but does not require its support either.
Further, TCP-AO supports rekeying with zero packet loss, whereas Further, TCP-AO supports rekeying with zero packet loss, whereas
rekeying in TCP MD5 can lose packets in transit during the rekeying in TCP MD5 can lose packets in transit during the
changeover or require trying multiple keys on each received changeover or require trying multiple keys on each received
segment during key use overlap. segment during key use overlap because it lacks an explicit key
ID.
o TCP-AO provides automatic key rollover to provide replay o TCP-AO provides automatic replay protection for long-lived
protection for long-lived connections. connections using an extended sequence number.
o TCP-AO ensures per-connection keys as unique as the TCP connection o TCP-AO ensures per-connection keys as unique as the TCP connection
itself, using TCP's ISNs for differentiation, even when static itself, using TCP's ISNs for differentiation, even when static
keys are used for repeated instances of a socket pair. master keys are used across repeated instances of a socket pair.
o This document provides more detail in how this option interacts o This document provides detail in how this option interacts with
with TCP's states, event processing, and user interface. TCP's states, event processing, and user interface.
o The TCP-AO option is 3 bytes shorter than TCP MD5 (15 bytes o The TCP-AO option is 3 bytes shorter than TCP MD5 (15 bytes
overall, rather than 18) in the default case (assuming a 96-bit overall, rather than 18) in the default case (using a 96-bit MAC).
MAC).
This document differs from an IPsec/IKE solution in that TCP-AO as This document differs from an IPsec/IKE solution in that TCP-AO as
follows [RFC4301][RFC4306]: follows [RFC4301][RFC4306]:
o TCP-AO does not support dynamic parameter negotiation. o TCP-AO does not support dynamic parameter negotiation.
o TCP-AO uses TCP's socket pair (source address, destination o TCP-AO uses TCP's socket pair (source address, destination
address, source port, destination port) as a security parameter address, source port, destination port) as a security parameter
index, rather than using a separate field as a primary index index, rather than using a separate field as a primary index
(IPsec's SPI). (IPsec's SPI).
o TCP-AO forces a change of computed MACs when a connection o TCP-AO forces a change of computed MACs when a connection
restarts, even when reusing a TCP socket pair (IP addresses and restarts, even when reusing a TCP socket pair (IP addresses and
port numbers) [Be07]. port numbers) [Be07].
o TCP-AO does not support encryption. o TCP-AO does not support encryption.
o TCP-AO does not authenticate ICMP messages (some ICMP messages may o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated via IPsec, depending on the configuration). be authenticated via IPsec, depending on the configuration).
1.2. List of TBD Items 2.2. Changes from Previous Versions
[NOTE: to be omitted upon final publication as RFC] [NOTE: to be omitted upon final publication as RFC]
SAAG: The following items are to be determined (TBD) prior to 2.2.1. New in draft-ietf-tcp-auth-opt-03
publication. Once a value is chosen, it should be replaced for the
notation below throughout this document and the item removed from
this list.
TBD-IANA-KIND new TCP option Kind for TCP-AO, assigned by IANA o Added a placeholder to discuss key change coordination in Section
9.
TBD-WG-MACS list of default required MAC algorithms 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.
TBD-WG-MACLEN default length of MAC used in the TCP-AO MAF 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.
1.3. Changes from Previous Versions 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).
[NOTE: to be omitted upon final publication as RFC] o Explained the ESN pseudocode operation in detail.
1.3.1. New in draft-ietf-tcp-auth-opt-02 o Added a contributors section up front.
o List issue - Replay Protection: incorporated key rollover based on o Update discussion of requirements to be sufficiently stand-alone;
extended sequence number space, not using KeyID space. 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.2. 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 o List issue - Unique Connection Keys: ISNs are used to generate
unique connection keys even when static keys used for repeated unique connection keys even when static keys used for repeated
instances of a socket pair. instances of a socket pair.
o List issue - Header Format and Alignment: Moved KeyID to front. o List issue - Header Format and Alignment: Moved KeyID to front.
o List issue - Reserved KeyID Value: Suggestion to reserve a single o List issue - Reserved KeyID Value: Suggestion to reserve a single
KeyID value for implementation optimization received no support on KeyID value for implementation optimization received no support on
the WG list, so this was not changed. the WG list, so this was not changed.
skipping to change at page 6, line 43 skipping to change at page 7, line 47
o Explained why option exclusion can't be changed during a o Explained why option exclusion can't be changed during a
connection. connection.
o Clarified that AO explicitly allows rekeying during a TCP o Clarified that AO explicitly allows rekeying during a TCP
connection, without impacting packet loss. connection, without impacting packet loss.
o Described TCP-AO's interaction with reboots more clearly, and o Described TCP-AO's interaction with reboots more clearly, and
explained the need to clear out old state that persists explained the need to clear out old state that persists
indefinitely. indefinitely.
1.3.2. New in draft-ietf-tcp-auth-opt-01 2.2.3. New in draft-ietf-tcp-auth-opt-01
o Require KeyID in all versions. Remove odd/even indicator of KeyID o Require KeyID in all versions. Remove odd/even indicator of KeyID
usage. usage.
o Relax restrictions on key reuse: requiring an algorithm for nonce o Relax restrictions on key reuse: requiring an algorithm for nonce
introduction based on ISNs, and suggest key rollover every 2^31 introduction based on ISNs, and suggest key rollover every 2^31
bytes (rather than using an extended sequence number, which bytes (rather than using an extended sequence number, which
introduces new state to the TCP connection). introduces new state to the TCP connection).
o Clarify NAT interaction; currently does not support omitting the o Clarify NAT interaction; currently does not support omitting the
skipping to change at page 7, line 24 skipping to change at page 8, line 29
length changes of such options. length changes of such options.
o Augment replay discussion in security considerations. o Augment replay discussion in security considerations.
o Revise discussion of IKEv2 MAC algorithm names. o Revise discussion of IKEv2 MAC algorithm names.
o Remove executive summary comparison to expired documents. o Remove executive summary comparison to expired documents.
o Clarified key words to exclude lower case usage. o Clarified key words to exclude lower case usage.
1.3.3. New in draft-ietf-tcp-auth-opt-00 2.2.4. New in draft-ietf-tcp-auth-opt-00
o List of TBD values, and indication of how each is determined. o List of TBD values, and indication of how each is determined.
o Changed TCP-SA to TCP-AO (removed 'simple' throughout). o Changed TCP-SA to TCP-AO (removed 'simple' throughout).
o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as
appropriate approach instead. appropriate approach instead.
o Made several changes coordinated in the TCP-AUTH-DT as follow: o Made several changes coordinated in the TCP-AUTH-DT as follow:
skipping to change at page 8, line 5 skipping to change at page 9, line 10
o Allow 0 as a legitimate KeyID. o Allow 0 as a legitimate KeyID.
o Allow the WG to determine the two appropriate required MAC o Allow the WG to determine the two appropriate required MAC
algorithms. algorithms.
o Add TO-DO items. o Add TO-DO items.
o Added discussion at end of Introduction as to why TCP MD5 o Added discussion at end of Introduction as to why TCP MD5
connections cannot be upgraded to TCP-AO. connections cannot be upgraded to TCP-AO.
1.3.4. New in draft-touch-tcp-simple-auth-03 2.2.5. New in draft-touch-tcp-simple-auth-03
o Added support for NAT/NAPT. o Added support for NAT/NAPT.
o Added support for IPv6. o Added support for IPv6.
o Added discussion of how this proposal satisfies requirements under o Added discussion of how this proposal satisfies requirements under
development, including those indicated in [Be07]. development, including those indicated in [Be07].
o Clarified the byte order of all data used in the MAC. 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. o Changed the TCP option exclusion bit from a bit to a list.
1.3.5. New in draft-touch-tcp-simple-auth-02 2.2.6. New in draft-touch-tcp-simple-auth-02
o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. o Add reference to Bellovin's need-for-TCP-auth doc [Be07].
o Add reference to SP4 [SDNS88]. o Add reference to SP4 [SDNS88].
o Added notes that TSAD to be externally implemented; this was o Added notes that TSAD to be externally implemented; this was
compatible with the TSAD described in the previous version. compatible with the TSAD described in the previous version.
o Augmented the protocol to allow a KeyID, required to support o Augmented the protocol to allow a KeyID, required to support
efficient overlapping keys during rekeying, and potentially useful efficient overlapping keys during rekeying, and potentially useful
during connection establishment. Accommodated by redesigning the during connection establishment. Accommodated by redesigning the
TSAD. TSAD.
o Added the odd/even indicator for the KeyID. o Added the odd/even indicator for the KeyID.
o Allow for the exclusion of all TCP options in the MAC calculation. o Allow for the exclusion of all TCP options in the MAC calculation.
1.3.6. New in draft-touch-tcp-simple-auth-01 2.2.7. New in draft-touch-tcp-simple-auth-01
o Allows intra-session rekeying, assuming out-of-band coordination. o Allows intra-session rekeying, assuming out-of-band coordination.
o MUST allow TSAD entries to change, enabling rekeying within a TCP o MUST allow TSAD entries to change, enabling rekeying within a TCP
connection. connection.
o Omits discussion of the impact of connection reestablishment on o Omits discussion of the impact of connection reestablishment on
BGP, because added support for rekeying renders this point moot. BGP, because added support for rekeying renders this point moot.
o Adds further discussion on the need for rekeying. o Adds further discussion on the need for rekeying.
1.4. Summary of RFC-2119 Requirements 3. Conventions used in this document
[NOTE: a summary will be placed here prior to last call]
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation 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 only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
3. The TCP Authentication Option 4. The TCP Authentication Option
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
of TBD-IANA-KIND. of TBD-IANA-KIND.
3.1. Review of TCP MD5 Option 4.1. Review of TCP MD5 Option
For review, the TCP MD5 option is shown in Figure 1. For review, the TCP MD5 option is shown in Figure 1.
+---------+---------+-------------------+ +---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... | | Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+ +---------+---------+-------------------+
| | | |
+---------------------------------------+ +---------------------------------------+
| | | |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 10, line 7 skipping to change at page 11, line 7
1. The TCP pseudoheader (IP source and destination addresses, 1. The TCP pseudoheader (IP source and destination addresses,
protocol number, and segment length). protocol number, and segment length).
2. The TCP header excluding options and checksum. 2. The TCP header excluding options and checksum.
3. The TCP data payload. 3. The TCP data payload.
4. The connection key. 4. The connection key.
3.2. TCP-AO Option 4.2. TCP-AO Option
The new TCP-AO option provides a superset of the capabilities of TCP 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 MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
Kind field, and similar Length field to TCP MD5, as well as a KeyID Kind field, and similar Length field to TCP MD5, as well as a KeyID
field as shown in Figure 2. field as shown in Figure 2.
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind | Length | KeyID | MAC | | Kind | Length | KeyID | MAC |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| MAC (con't) ... | MAC (con't) ...
skipping to change at page 10, line 30 skipping to change at page 11, line 30
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP-AO Option Figure 2 The TCP-AO Option
The TCP-AO defines the following fields: The TCP-AO defines the following fields:
o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP-
AO uses a new Kind value of TBD-IANA-KIND. Because of how keys are AO uses a new Kind value of TBD-IANA-KIND. Because of how keys are
managed (see Section 6), an endpoint will not use TCP-AO for the managed (see Section 7), an endpoint will not use TCP-AO for the
same connection in which TCP MD5 is used. same connection in which TCP MD5 is used.
>> A single TCP segment MUST NOT have more than one TCP-AO option. >> 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- o Length: An unsigned 1-byte field indicating the length of the TCP-
AO option in bytes, including the Kind, Length, KeyID, and MAC AO option in bytes, including the Kind, Length, KeyID, and MAC
fields. fields.
>> The Length value MUST be greater than or equal to 3. >> The Length value MUST be greater than or equal to 3.
skipping to change at page 11, line 16 skipping to change at page 12, line 16
changes during a connection and/or to help with key coordination changes during a connection and/or to help with key coordination
during connection establishment, and will be discussed further in during connection establishment, and will be discussed further in
Section 4. Note that the KeyID has no cryptographic properties - Section 4. Note that the KeyID has no cryptographic properties -
it need not be random, nor are there any reserved values. it need not be random, nor are there any reserved values.
o MAC: Message Authentication Field. Its contents are determined by o MAC: Message Authentication Field. Its contents are determined by
the particulars of the security association. Typical MACs are 96- the particulars of the security association. Typical MACs are 96-
128 bits (12-16 bytes), but any length that fits in the header of 128 bits (12-16 bytes), but any length that fits in the header of
the segment being authenticated is allowed. the segment being authenticated is allowed.
>> TCP-AO MUST support TBD-WG-MACS; other MACs MAY be supported >> Required support for TCP-AO MACs as defined in RFC-TBD; other
[RFC2403]. MACs MAY be supported [RFC2403].
The MAC is computed over the following fields in the following order: The MAC is computed over the following fields in the following order:
1. The extended sequence number (ESN), in network-standard byte 1. The extended sequence number (ESN), in network-standard byte
order, as follows: order, as follows (described further in Section 5):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| ESN | | ESN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 3 Extended sequence number Figure 3 Extended sequence number
The ESN for transmitted segments is locally maintained from a The ESN for transmitted segments is locally maintained from a
locally maintained SND.ESN value, for received segments, a local locally maintained SND.ESN value, for received segments, a local
RCV.ESN value is used. The details of how these values are RCV.ESN value is used. The details of how these values are
maintained and used is described in Sections 4, 7.4, and 7.5. maintained and used is described in Sections 5, 8.4, and 8.5.
2. The TCP pseudoheader: IP source and destination addresses, 2. The TCP pseudoheader: IP source and destination addresses,
protocol number and segment length, all in network byte order, protocol number and segment length, all in network byte order,
prepended to the TCP header below. The pseudoheader is exactly as prepended to the TCP header below. The pseudoheader is exactly as
used for the TCP checksum in either IPv4 or IPv6 used for the TCP checksum in either IPv4 or IPv6
[RFC793][RFC2460]: [RFC793][RFC2460]:
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 12, line 35 skipping to change at page 13, line 35
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 5 TCP IPv6 pseudoheader [RFC2460] Figure 5 TCP IPv6 pseudoheader [RFC2460]
3. The TCP header, by default including options, and where the TCP 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 checksum and TCP-AO MAC fields are set to zero, all in network
byte order byte order
4. TCP data, in network byte order 4. TCP data, in network byte order
Note that the connection key is not included here; we expect that the Note that the connection key is not included here; the MAC algorithm
MAC algorithm will indicate how to use the key, e.g., as HMACs do in indicates how to use the connection key, e.g., as HMACs do in general
general [RFC2104][RFC2403]. The connection key is derived from the [RFC2104][RFC2403]. The connection key is derived from the TSAD
TSAD key entry as described in Sections 6, 7.4, and 7.5. entry's master key as described in Sections 7, 8.4, and 8.5.
By default,TCP-AO includes the TCP options in the MAC calculation By default,TCP-AO includes the TCP options in the MAC calculation
because these options are intended to be end-to-end and some are because these options are intended to be end-to-end and some are
required for proper TCP operation (e.g., SACK, timestamp, large required for proper TCP operation (e.g., SACK, timestamp, large
windows). Middleboxes that alter TCP options en-route are a kind of windows). Middleboxes that alter TCP options en-route are a kind of
attack and would be successfully detected by TCP-AO. In cases where attack and would be successfully detected by TCP-AO. In cases where
the configuration of the connection's security association state the configuration of the connection's security association state
indicates otherwise, the TCP options can be excluded from the MAC indicates otherwise, the TCP options can be excluded from the MAC
calculation. When options are excluded, all options - including TCP- calculation. When options are excluded, all options - including TCP-
AO - are skipped over during the MAC calculation (rather than being AO - are skipped over during the MAC calculation (rather than being
zeroed). zeroed).
The TCP-AO option does not indicate the MAC algorithm either The TCP-AO option does not indicate the MAC algorithm either
implicitly (as with TCP MD5) or explicitly. The particular algorithm implicitly (as with TCP MD5) or explicitly. The particular algorithm
used is considered part of the configuration state of the used is considered part of the configuration state of the
connection's security association and is managed separately (see connection's security association and is managed separately (see
Section 6). Section 7).
4. Preventing replay attacks within long-lived connections 5. Preventing replay attacks within long-lived connections
TCP uses a 32-bit sequence number which may, for long-lived TCP uses a 32-bit sequence number which may, for long-lived
connections, roll over and repeat. This could result in TCP segments connections, roll over and repeat. This could result in TCP segments
being intentionally and legitimately replayed within a connection. being intentionally and legitimately replayed within a connection.
TCP-AO prevents replay attacks, and thus requires a way to TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it differentiate these legitimate replays from each other, and so it
adds a 32-bit extended sequence number (ESN) for transmitted and adds a 32-bit extended sequence number (ESN) for transmitted and
received segments. 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 TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN
for received segments, both initialized as zero when a connection for received segments, both initialized as zero when a connection
begins. The intent of these ESNs is, together with TCP's 32-bit begins. The intent of these ESNs is, together with TCP's 32-bit
sequence numbers, to provide a 64-bit overall sequence number space. sequence numbers, to provide a 64-bit overall sequence number space.
For transmitted segments SND.ESN can be implemented by extending For transmitted segments SND.ESN can be implemented by extending
TCP's sequence number to 64-bits; SND.ESN would be the top (high- 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 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 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 appropriate high-order 32-bits of that number as RCV.ESN from the
received 32-bit sequence number and the current connection context. received 32-bit sequence number and the current connection context.
The implementation of ESNs is not specified in this document, but one 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, possible way is described here that can be used for either RCV.ESN,
SND.ESN, or both. SND.ESN, or both.
Consider an implementation with two ESNs as required (SND.ESN, Consider an implementation with two ESNs as required (SND.ESN,
RCV.ESN), and additional variables as listed below, all initialized RCV.ESN), and additional variables as listed below, all initialized
to zero, as well as a current TCP segment field (SEG.SEQ): to zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.ESN o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.ESN
o SND.ESN_FLAG, which indicates when to increment the SND.ESN o SND.ESN_FLAG, which indicates when to increment the SND.ESN
o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN
o ROLL, a temporary variable used to simplify the code
When a segment is received, the following algorithm (written in C) When a segment is received, the following algorithm (written in C)
computes the ESN used in the MAC; an equivalent algorithm can be computes the ESN used in the MAC; an equivalent algorithm can be
applied to the "SND" side: applied to the "SND" side:
ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff); #
# ROLL is just shorthand
ROLL = (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff);
#
# set the flag when the SEG.SEQ first rolls over
if ((RCV.ESN_FLAG == 0) && (ROLL)) { if ((RCV.ESN_FLAG == 0) && (ROLL)) {
RCV.ESN = RCV.ESN + 1; RCV.ESN = RCV.ESN + 1;
RCV.ESN_FLAG = 1; RCV.ESN_FLAG = 1;
} }
#
# we've already incremented the RCV.ESN at this point # decide which ESN to use during rollover after incremented
if ((RCV.ESN_FLAG == 1) && (ROLL)) {
if (ROLL) {
ESN = RCV.ESN - 1; # use the pre-increment value ESN = RCV.ESN - 1; # use the pre-increment value
} else { } else {
ESN = RCV.ESN; # use the current value 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; RCV.PREV_SEQ = SEG.SEQ;
if (SEG.SEQ > 0xffff) { In the above code, ROLL is true in the first line when the sequence
number rolls over, i.e., when the new number is low (in the bottom
RCV.ESN_FLAG = 0; 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. 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.
} 6. Computing connection keys from TSAD entries
5. Computing connection keys from TSAD entries TSAD entries, described in Section 7, include master keys which are
used in conjunction with a TCP's connection ISNs to generate unique
connection keys. This allows a static master key to be reused across
different connections, or across different instances of connections
within a socket pair, while maintaining unique connection keys.
Unique connection keys are generated without relying on external key
management properties.
TSAD key entries, described in Section 6, are used in conjunction Given a master key tuple, the TCP socket pair, and the connection
with a TCP's connection ISNs to generate unique connection keys. This ISNs, the connection key used in the MAC algorithm is computed as
allows a static TSAD key to be reused across different connections, follows, truncated to the same length as the master key, using a
or across different instances of connections within a socket pair, pseudorandom function (PRF):
while maintaining unique connection keys. Unique connection keys are
generated without relying on external key management properties.
Given a TSAD key, the TCP socket pair, and the connection ISNs, the Conn_key = PRF(TSAD_master_key, input)
connection key used in the MAC algorithm is computed as follows, where
truncated to the same length as the TSAD key, using the same MAC input = 0 + "TCP-AO" + connblock + TSAD_master_key_len
algorithm as the TSAD key (TALG):
Conn_key = TALG(TSAD_key, connblock) The components of the input are concatenated as a single byte string
(the string concatenation operator is shown here as "+"). The initial
zero of the input is a single byte, "TCP-AO" is a null-terminated
string, connblock is defined below, and TSAD_master_key_len is the
length of the TSAD master key in bytes, as stored in the TSAD entry.
The PRF to be used for a given master key is indicated in the TDAD
master key tuple, and details of the PRF are provided in [RFC-TBD].
The connection block (connblock) is defined as follows (IP addresses The connection block (connblock) is defined as follows (IP addresses
are correspondingly longer for IPv6 addresses): are correspondingly longer for IPv6 addresses):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source IP | | Source IP |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination IP | | Destination IP |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Port | Dest. Port | | Source Port | Dest. Port |
skipping to change at page 15, line 27 skipping to change at page 17, line 5
| Source ISN | | Source ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination ISN | | Destination ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 6 Connection block used for connection key generation Figure 6 Connection block used for connection key generation
"Source" and "destination" are defined by the direction of the "Source" and "destination" are defined by the direction of the
segment being MAC'd; for incoming packets, source is the remote side, segment being MAC'd; for incoming packets, source is the remote side,
whereas for outgoing packets source is the local side. This further whereas for outgoing packets source is the local side. This further
ensures that keys for each direction are unique. ensures that connection keys generated for each direction are unique.
For SYN segments (segments with the SYN set, but the ACK not set), For SYN segments (segments with the SYN set, but the ACK not set),
the destination ISN is not known. For these segments, the key is the destination ISN is not known. For these segments, the connection
computed using the connection block shown above, in which the key is computed using the connection block shown above, in which the
Destination ISN value is zero. For all other segments, the ISN pair 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 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 a RST after a reboot, the segment should be sent without
authentication; if authentication was required, the segment cannot authentication; if authentication was required, the segment cannot
have been MAC'd properly anyway and would have been dropped on have been MAC'd properly anyway and would have been dropped on
receipt. receipt.
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination >> 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 ISN of zero (whether sent or received); all other segments use the
known ISN pair. known ISN pair.
>> Segments sent in response to connections for which the ISNs are >> Segments sent in response to connections for which the ISNs are
not known SHOULD NOT use TCP-AO. not known SHOULD NOT use TCP-AO.
Once a connection is established, a connection key would typically be Once a connection is established, a connection key would typically be
cached to avoid recomputing it on a per-segment basis. The use of cached to avoid recomputing it on a per-segment basis (e.g., in the
TCP Transmission Control Block, i.e, the TCB [RFC793]). The use of
both ISNs in the connection key computation ensures that segments both ISNs in the connection key computation ensures that segments
cannot be replayed across repeated connections reusing the same cannot be replayed across repeated connections reusing the same
socket pair (provided the ISN pair does not repeat, which is socket pair (provided the ISN pair does not repeat, which is unlikely
extremely 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 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 (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 using the ISN pair for the connection. There are other cases in which
the destination ISN is not known, but segments are emitted, such as the destination ISN is not known, but segments are emitted, such as
after an endpoint reboots, when is possible that the two endpoints after an endpoint reboots, when is possible that the two endpoints
would not have enough information to authenticate segments. In such would not have enough information to authenticate segments. In such
cases, TCP's timeout mechanism will allow old state to be cleared to cases, TCP's timeout mechanism will allow old state to be cleared to
enable new connections, except where the user timeout is disabled; it enable new connections, except where the user timeout is disabled; it
is important that implementations are capable of detecting excesses is important that implementations are capable of detecting excesses
of TCP connections in such a configuration and can clear them out if of TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Je07]. needed to protect its memory usage [Je07].
6. Security Association Management 7. Security Association Management
TCP-AO relies on a TCP Security Association Database (TSAD). TSAD TCP-AO relies on a TCP Security Association Database (TSAD), which
entries are assumed to exist at the endpoints where TCP-AO is used, indicates whether a TCP connection requires TCP-AO, and its
in advance of the connection: parameters when so. The TSAD is described as an explicit component of
TCP-AO to enable external (master) key management mechanisms -
automatic or manual - to interact with TCP-AO as needed.
TSAD entries are assumed to exist at the endpoints where TCP-AO is
used, in advance of the connection:
1. TCP connection identifier (ID), i.e., socket pair - IP source 1. TCP connection identifier (ID), i.e., socket pair - IP source
address, IP destination address, TCP source port, and TCP address, IP destination address, TCP source port, and TCP
destination port [RFC793]. TSAD entries are uniquely determined by destination port [RFC793]. TSAD entries are uniquely determined by
their TCP connection ID, which is used to index those entries. their TCP connection ID, which is used to index those entries. A
TSAD entry may allow wildcards, notably in the source port value.
>> There MUST be no more than one matching TSAD entry per >> There MUST be no more than one matching TSAD entry per
direction for a TCP connection ID. direction for a fully-instantiated (no wildcards) TCP connection
ID.
2. For each of inbound (for received TCP segments) and outbound (for 2. For each of inbound (for received TCP segments) and outbound (for
sent TCP segments) directions for this connection (except as sent TCP segments) directions for this connection (except as
noted): noted):
a. TCP option flag. When 0, this flag allows default operation, a. TCP option flag. When 0, this flag allows default operation,
i.e., TCP options are included in the MAC calculation, with i.e., TCP options are included in the MAC calculation, with
TCP-AO's MAC field zeroed out. When 1, all options (including TCP-AO's MAC field zeroed out. When 1, all options (including
TCP-AO) are excluded from all MAC calculations (skipped over, TCP-AO) are excluded from all MAC calculations (skipped over,
not simply zeroed). not simply zeroed).
skipping to change at page 17, line 10 skipping to change at page 18, line 46
The TCP option flag cannot change during a connection because The TCP option flag cannot change during a connection because
TCP state is coordinated during connection establishment. TCP TCP state is coordinated during connection establishment. TCP
lacks a handshake for modifying that state after a connection lacks a handshake for modifying that state after a connection
has been established. has been established.
b. An extended sequence number (ESN). The ESN enables each b. An extended sequence number (ESN). The ESN enables each
segment's MAC calculation to have unique input data, even when segment's MAC calculation to have unique input data, even when
payload data is retransmitted and the TCP sequence number payload data is retransmitted and the TCP sequence number
repeats due to wraparound. The ESN is initialized to zero upon repeats due to wraparound. The ESN is initialized to zero upon
connection establishment. Its use in the MAC calculation is connection establishment. Its use in the MAC calculation is
described in Section 3.2, and its management is described in described in Section 4.2, and its management is described in
Section 4. Section 5.
c. An ordered list of zero or more key tuples. Each tuple is c. An ordered list of zero or more master key tuples. Each tuple
defined as the set <KeyID, MAC type, key length, key> as is defined as the set <KeyID, MAC type, master key length,
follows: master key, PRF> as follows:
>> TSAD key tuple components MUST NOT change during a >> Components of a TSAD master key tuple MUST NOT change
connection. during a connection.
Keeping the tuple components static ensures that the KeyID Keeping the tuple components static ensures that the KeyID
uniquely determines the properties of a packet; this supports uniquely determines the properties of a packet; this supports
use of the KeyID to determine the packet properties. use of the KeyID to determine the packet properties.
>> The set of TSAD key tuples MAY change during a connection, >> The set of TSAD master key tuples MAY change during a
but KeyIDs of those tuples MUST NOT overlap. I.e., tuple connection, but KeyIDs of those tuples MUST NOT overlap. I.e.,
parameter changes MUST be accompanied by key changes. tuple parameter changes MUST be accompanied by master key
changes.
i. KeyID. A single byte used to differentiate connection i. KeyID. The value as used in the TCP-AO option; used to
keys in concurrent use. differentiate connection keys in concurrent use that are
derived from different master keys.
>> A TSAD implementation MUST support at least two KeyIDs >> A TSAD implementation MUST support at least two KeyIDs
per connection per direction, and MAY support up to 256. per connection per direction, and MAY support up to 256.
>> A KeyID MUST support any value, 0-255 inclusive. There >> A KeyID MUST support any value, 0-255 inclusive. There
are no reserved KeyID values. are no reserved KeyID values.
KeyID values are assigned arbitrarily. They can be KeyID values are assigned arbitrarily. They can be
assigned in sequence, or based on any method mutually assigned in sequence, or based on any method mutually
agreed by the connection endpoints (e.g., using an agreed by the connection endpoints (e.g., using an
external key management mechanism). external master key management mechanism).
>> KeyIDs MUST NOT be assumed to be randomly assigned. >> KeyIDs MUST NOT be assumed to be randomly assigned.
ii. MAC type. Indicates the MAC used for this connection, ii. MAC type. Indicates the MAC used for this connection, as
referencing types registered in the IKEv2 Transform Type defined in [RFC-TBD]. This includes the MAC algorithm
3 (Integrity Algorithms) Registry of the IANA established (e.g., HMAC-SHA1, AES-CMAC, etc.) and the length of the
by [RFC4306]. This includes each MAC algorithm (e.g., MAC as truncated to (e.g., 96, 128, etc.).
HMAC-MD5, HMAC-SHA1, UMAC, etc.) and the length of the
MAC as truncated to (e.g., 96, 128, etc.). Note that TCP-
AO refers to the IKEv2 list of transforms, but TCP-AO is
not dependent on IKEv2 itself.
>> A MAC type of "NONE" MUST be supported, to indicate >> A MAC type of "NONE" MUST be supported, to indicate
that authentication is not used in this direction; this that authentication is not used in this direction; this
allows asymmetric use of TCP-AO. allows asymmetric use of TCP-AO.
>> At least one direction (inbound/outbound) SHOULD have >> At least one direction (inbound/outbound) SHOULD have
a non-"NONE" MAC in practice, but this MUST NOT be a non-"NONE" MAC in practice, but this MUST NOT be
strictly required by an implementation. strictly required by an implementation.
>> When the outbound MAC is set to values other than >> When the outbound MAC is set to values other than
"NONE", TCP-AO MUST occur in every outbound TCP segment "NONE", TCP-AO MUST occur in every outbound TCP segment
for that connection; when set to NONE or when no tuple for that connection; when set to NONE or when no tuple
exists, TCP-AO MUST NOT occur in those segments. exists, TCP-AO MUST NOT occur in those segments.
>> When the inbound MAC is set to values other than >> When the inbound MAC is set to values other than
"NONE", TCP-AO MUST occur in every inbound TCP segment "NONE", TCP-AO MUST occur in every inbound TCP segment
for that connection; when set to "NONE" or when no tuple for that connection; when set to "NONE" or when no tuple
exists, TCP-AO SHOULD NOT be added to those segments, but exists, TCP-AO SHOULD NOT be added to those segments, but
MAY occur and MUST be ignored. MAY occur and MUST be ignored.
iii. Key length. A byte indicating the length of the key in iii. Master key length. Indicates the length of the master key
bytes. in bytes.
iv. Key. A byte sequence used for generating connection keys, iv. Master key. A byte sequence used for generating
this may be derived from a separate shared key by an connection keys, this may be derived from a separate
external protocol over a separate channel. This sequence shared key by an external protocol over a separate
is used in network-standard byte order in the key channel. This sequence is used in network-standard byte
generation algorithm described in Section 5. order in the connection key generation algorithm
described in Section 6.
v. PRF. A pseudorandom function used for the geneation of a
connection key from the master key tuple, as described in
Section 6. The specific functions used are described in
[RFC-TBD].
It is anticipated that TSAD entries for TCP connections in states It is anticipated that TSAD entries for TCP connections in states
other than CLOSED can be stored in the TCP Control Block (TCB) or in other than CLOSED can be indexed in the TCP TCB for convenience, but
a separate database (see Section 8.1 for notes on the latter); TSAD that the index would reference a separate database with entries for
entries for pending connections (in passive or active OPEN) may be all connections to an IP address (see Section 9.1 for notes on the
stored in a separate database. This means that in a single host there latter. This means that for a particular endpoint (i.e., IP address)
should be only a single database that is consulted by all pending there would be exactly one database that is consulted by all pending
connections, the same way that there is only one set of TCBs. connections, the same way that there is only one table of TCBs (a
Multiple databases could be used to support virtual hosts, i.e., database can support multiple endpoints, but an endpoint is
groups of interfaces. represented in only one database). Multiple databases could be used
to support virtual hosts, i.e., groups of interfaces.
Note that the TCP-AO fields omit an explicit algorithm ID; that Note that the TCP-AO fields omit an explicit algorithm ID; that
algorithm is already specified by the TCP connection ID and stored in algorithm is already specified by the TCP connection ID and stored in
the TSAD. the TSAD.
Also note that this document does not address how TSAD entries are Also note that this document does not address how TSAD entries are
created by users/processes; it specifies how they must be destroyed created by users/processes; it specifies how they must be destroyed
corresponding to connection states, but users/processes may destroy corresponding to connection states, but users/processes may destroy
entries as well. It is presumed that a TSAD entry affecting a entries as well. It is presumed that a TSAD entry affecting a
particular connection cannot be destroyed during an active connection particular connection cannot be destroyed during an active connection
- or, equivalently, that its parameters are copied to TSAD entries - or, equivalently, that its parameters are copied to TSAD entries
local to the connection (i.e., instantiated) and so changes would local to the connection (i.e., instantiated) and so changes would
affect only new connections. The TSAD could be managed by a separate affect only new connections. The TSAD could be managed by a separate
application protocol, and can be stored in a separate database if application protocol.
desired.
7. TCP-AO Interaction with TCP 8. TCP-AO Interaction with TCP
The following is a description of how TCP-AO affects various TCP The following is a description of how TCP-AO affects various TCP
states, segments, events, and interfaces. This description is states, segments, events, and interfaces. This description is
intended to augment the description of TCP as provided in RFC793 intended to augment the description of TCP as provided in RFC-793,
[RFC793]. and its presentation mirrors that of RFC-793 as a result [RFC793].
7.1. User Interface 8.1. TCP User Interface
The TCP user interface supports active and passive OPEN, SEND, The TCP user interface supports active and passive OPEN, SEND,
RECEIVE, CLOSE, STATUS and ABORT commands. 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 TSAD
to be configured, as well as to allow an ongoing connection to manage
which KeyID tuples are active. The TSAD 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 >> 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 to be in the active or passive OPEN state, MUST be augmented so that
a TSAD entry can be configured. a TSAD entry can be configured.
Users are advised to not inappropriately reuse keys [RFC3562]. As
noted in Section 3.2, this is accomplished in TCP-AO by the use of
unique per-connection nonces in conjunction with conventional keys.
>> TCP STATUS SHOULD be augmented to allow the TSAD entry of a
current or pending connection to be read (for confirmation).
>> A TCP-AO implmentation MUST allow TSAD entries for ongoing TCP >> A TCP-AO implmentation MUST allow TSAD entries for ongoing TCP
connections (i.e., not in the CLOSED state) to be modified. connections (i.e., not in the CLOSED state) to be modified.
Parameters not used to index a connection MAY be modified; parameters Parameters not used to index a connection MAY be modified; parameters
used to index a connection MUST NOT be modified. used to index a connection MUST NOT be modified.
TSAD entries for TCP connections not in the CLOSED state are deleted The TSAD information of a connection needs to be available for
indirectly using the CLOSE or ABORT commands. confirmation; this includes the ability to read the connection key:
TCP SEND and RECEIVE are not affected by TCP-AO. >> TCP STATUS SHOULD be augmented to allow the TSAD entry of a
current or pending connection to be read (for confirmation).
7.2. TCP States and Transitions Senders need to be able to determine when the outgoing KeyID changes;
this change immediately affects all subsequent outgoing segments
(i.e., it need not be synchronized with the data of the SEND call, if
indicated therein):
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be
augmented so that the KeyID of a TSAD entry can be indicated.
It may be useful to change the sender-side active KeyID 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 for the receive side to indicate the recent KeyID
received; although there could be a number of such KeyIDs, the KeyIDs
are not expected to change quickly so any recent sample of a received
KeyID is sufficient:
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE,
MUST be augmented so that the KeyID 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).
8.2. TCP States and Transitions
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
CLOSED. CLOSED.
>> A TSAD entry MAY be associated with any TCP state. >> A TSAD entry MAY be associated with any TCP state.
>> A TSAD entry MAY underspecify the TCP connection for the LISTEN >> A TSAD entry MAY underspecify the TCP connection for the LISTEN
state. Such an entry MUST NOT be used for more than one connection state. Such an entry MUST NOT be used for more than one connection
progressing out of the LISTEN state. progressing out of the LISTEN state.
7.3. TCP Segments 8.3. TCP Segments
TCP includes control (at least one of SYN, FIN, RST flags set) and 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 data (none of SYN, FIN, or RST flags set) segments. Note that some
control segments can include data (e.g., SYN). control segments can include data (e.g., SYN).
>> All TCP segments MUST be checked against the TSAD for matching TCP >> All TCP segments MUST be checked against the TSAD for matching TCP
connection IDs. connection IDs.
>> TCP segments matching TSAD entries with non-NULL MACs without TCP- >> TCP segments matching TSAD entries with non-NULL MACs without TCP-
AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be AO, or with TCP-AO and whose MACs and KeyIDs do not validate MUST be
skipping to change at page 21, line 5 skipping to change at page 23, line 32
All TCP-AO processing occurs between the interface of TCP and IP; for All TCP-AO processing occurs between the interface of TCP and IP; for
incoming segments, this occurs after validation of the TCP checksum. incoming segments, this occurs after validation of the TCP checksum.
For outgoing segments, this occurs before computation of the TCP For outgoing segments, this occurs before computation of the TCP
checksum. checksum.
Note that the TCP-AO option is not negotiated. It is the Note that the TCP-AO option is not negotiated. It is the
responsibility of the receiver to determine when TCP-AO is required responsibility of the receiver to determine when TCP-AO is required
and to enforce that requirement. and to enforce that requirement.
7.4. Sending TCP Segments 8.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment departs. TCP-AO when a segment departs.
1. Check the segment's TCP connection ID against the TSAD 1. Check the segment's TCP connection ID against the TSAD
2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with 2. If there is NO TSAD entry, omit the TCP-AO option. Proceed with
computing the TCP checksum and transmit the segment. computing the TCP checksum and transmit the segment.
3. If there is a TSAD entry with zero key tuples, omit the TCP-AO 3. If there is a TSAD entry with zero master key tuples, omit the
option. Proceed with computing the TCP checksum and transmit the TCP-AO option. Proceed with computing the TCP checksum and
segment. transmit the segment.
4. If there is a TSAD entry and a key tuple and the outgoing MAC is 4. If there is a TSAD entry and a master key tuple and the outgoing
NONE, omit the TCP-AO option. Proceed with computing the TCP MAC is NONE, omit the TCP-AO option. Proceed with computing the
checksum and transmit the segment. TCP checksum and transmit the segment.
5. If there is a TSAD entry and a key tuple and the outgoing MAC is 5. If there is a TSAD entry and a master key tuple and the outgoing
not NONE: MAC is not NONE:
a. Augment the TCP header with the TCP-AO, inserting the a. Augment the TCP header with the TCP-AO, inserting the
appropriate Length and KeyID based on the indexed TSAD entry. appropriate Length and KeyID based on the indexed TSAD entry.
Update the TCP header length accordingly. Update the TCP header length accordingly.
b. Determine SND.ESN as described in Section 4. b. Determine SND.ESN as described in Section 5.
c. Determine the connection key from the indexed TSAD entry as c. Determine the connection key from the indexed TSAD entry as
described in Section 5. described in Section 6.
d. Compute the MAC using the indexed TSAD entry and data from the d. Compute the MAC using the indexed TSAD entry and data from the
segment as specified in Section 3.2, including the TCP segment as specified in Section 4.2, including the TCP
pseudoheader and TCP header. Include or exclude the options as pseudoheader and TCP header. Include or exclude the options as
indicated by the TSAD entry's TCP option exclusion flag. indicated by the TSAD entry's TCP option exclusion flag.
e. Insert the MAC in the TCP-AO field. e. Insert the MAC in the TCP-AO field.
f. Proceed with computing the TCP checksum on the outgoing packet f. Proceed with computing the TCP checksum on the outgoing packet
and transmit the segment. and transmit the segment.
7.5. Receiving TCP Segments 8.5. Receiving TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment arrives. TCP-AO when a segment arrives.
1. Check the segment's TCP connection ID against the TSAD. 1. Check the segment's TCP connection ID against the TSAD.
2. If there is NO TSAD entry, proceed with TCP processing. 2. If there is NO TSAD entry, proceed with TCP processing.
3. If there is a TSAD entry with zero key tuples, proceed with TCP 3. If there is a TSAD entry with zero master key tuples, proceed with
processing. TCP processing.
4. If there is a TSAD entry with a key tuple and the incoming MAC is 4. If there is a TSAD entry with a master key tuple and the incoming
NONE, proceed with TCP processing. MAC is NONE, proceed with TCP processing.
5. If there is a TSAD entry with a key tuple and the incoming MAC is 5. If there is a TSAD entry with a master key tuple and the incoming
not NONE: MAC is not NONE:
a. Check that the segment's TCP-AO Length matches the length a. Check that the segment's TCP-AO Length matches the length
indicated by the indexed TSAD. indicated by the indexed TSAD.
i. If Lengths differ, silently discard the segment. Log i. If Lengths differ, silently discard the segment. Log
and/or signal the event as indicated in Section 7.3. and/or signal the event as indicated in Section 8.3.
b. Use the KeyID value to index the appropriate key for this b. Use the KeyID value to index the appropriate connection key
connection. for this connection.
i. If the TSAD has no entry corresponding to the segment's i. If the TSAD has no entry corresponding to the segment's
KeyID, silently discard the segment. KeyID, silently discard the segment.
c. Determine the segment's RCV.ESN as described in Section 4. c. Determine the segment's RCV.ESN as described in Section 5.
d. Determine the segment's connection key from the indexed TSAD d. Determine the segment's connection key from the indexed TSAD
entry as described in Section 5. entry as described in Section 6.
e. Compute the segment's MAC using the indexed TSAD entry and e. Compute the segment's MAC using the indexed TSAD entry and
portions of the segment as indicated in Section 3.2. portions of the segment as indicated in Section 4.2.
Again, if options are excluded (as per the TCP option Again, if options are excluded (as per the TCP option
exclusion flag), they are skipped over (rather than zeroed) exclusion flag), they are skipped over (rather than zeroed)
when used as input to the MAC calculation. when used as input to the MAC calculation.
i. If the computed MAC differs from the TCP-AO MAC field i. If the computed MAC differs from the TCP-AO MAC field
value, silently discard the segment. Log and/or signal value, silently discard the segment. Log and/or signal
the event as indicated in Section 7.3. the event as indicated in Section 8.3.
f. Proceed with TCP processing of the segment. f. Proceed with TCP processing of the segment.
It is suggested that TCP-AO implementations validate a segment's It is suggested that TCP-AO implementations validate a segment's
Length field before computing a MAC, to reduce the overhead incurred Length field before computing a MAC, to reduce the overhead incurred
by spoofed segments with invalid TCP-AO fields. by spoofed segments with invalid TCP-AO fields.
Additional reductions in MAC validation can be supported by using a Additional reductions in MAC validation overhead can be supported in
MAC algorithm that partitions the MAC field into fixed and computed the MAC algorithms, e.g, by using a computation algorithm that
portions, where the fixed value is validated before investing in the prepends a fixed value to the computed portion and a corresponding
computed portion. This optimization would be contained in the MAC validation algorithm that verifies the fixed value before investing
algorithm specification. Note that the KeyID cannot be used for in the computed portion. Such optimizations would be contained in the
connection validation per se, because it is not assumed random. 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.
7.6. Impact on TCP Header Size 8.6. Impact on TCP Header Size
The TCP-AO option typically uses a total of 17-19 bytes of TCP header 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 space. TCP-AO is no larger than and typically 3 bytes smaller than
the TCP MD5 option (assuming a 96-bit MAC). Although TCP option space the TCP MD5 option (assuming a 96-bit MAC).
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.
8. Key Establishment and Duration Issues 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 20 for TCP-AO.
Assuming a 96-bit MAC, TCP-AO consumes 15 bytes, leaving up to 10
bytes for other 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]
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.
9. Connection Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for connection key The TCP-AO option does not provide a mechanism for connection key
negotiation or parameter negotiation (MAC algorithm, length, or use negotiation or parameter negotiation (MAC algorithm, length, or use
of the TCP-AO option) or rekeying during a connection. We assume out- of the TCP-AO option), or for coordinating rekeying during a
of-band mechanisms for key establishment, parameter negotiation, and connection. We assume out-of-band mechanisms for master key
rekeying. This separation of key use from key management is similar establishment, parameter negotiation, and rekeying. This separation
to that in the IPsec security suite [RFC4301][RFC4306]. 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 We encourage users of TCP-AO to apply known techniques for generating
appropriate keys, including the use of reasonable connection key appropriate master keys, including the use of reasonable master key
lengths, limited connection key sharing, and limiting the duration of lengths, limited connection key sharing, and limiting the duration of
connection key use [RFC3562]. This also includes the use of per- master key use [RFC3562]. This also includes the use of per-
connection nonces, as suggested in Section 3.2. connection nonces, as suggested in Section 4.2.
TCP-AO supports rekeying in which new keys are negotiated out-of-
band, either via a protocol or a manual procedure [RFC4808]. New keys
use is coordinated using the out-of-band mechanism to update the TSAD
at both TCP endpoints. In the default case, where only a single key
is used at a time, the temporary use of invalid keys would result in
packets being dropped; TCP is already robust to such drops. Such
drops may affect TCP's throughput temporarily, as a result TCP-AO
benefits from the use of congestion control support for temporary
path outages.
>> TCP-AO SHOULD be deployed in conjunction with support for TCP-AO supports rekeying in which new master keys are negotiated and
selective acknowledgement (SACK), including support for multiple lost coordinated out-of-band, either via a protocol or a manual procedure
segments in the same round trip [RFC2018][RFC3517]. [RFC4808]. New master key use is coordinated using the out-of-band
mechanism to update the TSAD 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 TSAD can contain multiple concurrent master keys,
where the KeyID field is used to identify the master key that
corresponds to the connection key used for a segment, to avoid the
need for expensive trial-and-error testing of master keys in
sequence.
Note that TCP-AO's support for rekeying is designed to be minimal in TCP-AO does not currently provide an explicit key coordination
the default case. Segments carry only enough context to identify the mechanism. Such a mechanism is useful when new keys are installed, or
security association [RFC4301][RFC4306]. In TCP-AO, this context is when keys are changed, to determine when to commence using installed
provided by the socket pair (IP addresses and ports for source and keys. Note that because TCP-AO uses directional keys, the receive-
destination). The TSAD can contain multiple concurrent keys, where side keys can be installed in advance of the send side, avoiding the
the KeyID field is used to identify the key that corresponds to a need for tight coordination between endpoints.
segment, to avoid the need for expensive trial-and-error testing of
keys in sequence.
The KeyID field is also useful in coordinating keys for new The KeyID field is also useful in coordinating master keys used for
connections. A TSAD entry may be configured that matches the unbound new connections. A TSAD entry may be configured that matches the
source port, which would return a set of possible keys. The KeyID unbound source port, which would return a set of possible master
would then indicate the specific key, allowing more efficient keys. The KeyID would then indicate the specific master key, allowing
connection establishment; otherwise, the keys could have been tried more efficient connection establishment; otherwise, the master keys
in sequence. See also Section 8.1. could have been tried in sequence. See also Section 9.1.
Implementations are encouraged to keep keys in a suitably private Users are advised to manage master keys following the spirit of the
area. advice for key management when using TCP MD5 [RFC3562], notably to
use appropriate key lengths (12-24 bytes), to avoid sharing master
keys among multiple BGP peering arrangements, and to change master
keys every 90 days. This requires that the TSAD support monitoring
and modification.
8.1. Key reuse across socket pairs 9.1. Master Key Reuse Across Socket Pairs
Keys can be reused across different socket pairs within a host, or Master keys can be reused across different socket pairs within a
across different instances of a socket pair within a host. In either host, or across different instances of a socket pair within a host.
case, replay protection is maintained. In either case, replay protection is maintained.
Keys reused across different socket pairs cannot enable replay Master keys reused across different socket pairs cannot enable replay
attacks because the TCP socket pair is included in the MAC, as well attacks because the TCP socket pair is included in the MAC, as well
as in the generation of the connection key. Keys reused across as in the generation of the connection key. Master keys reused across
repeated instances of a given socket pair cannot enable replay repeated instances of a given socket pair cannot enable replay
attacks because the connection ISNs are included in the connection attacks because the connection ISNs are included in the connection
key generation algorithm, and ISN pairs are unlikely to repeat over key generation algorithm, and ISN pairs are unlikely to repeat over
useful periods. useful periods.
Keys should not be shared across different hosts, because this could 9.2. Master Key Use Within a Long-lived Connection
compromise the keying material itself.
8.2. Key use within a long-lived connection
TCP-AO uses extended sequence numbers (ESNs) to prevent replay TCP-AO uses extended sequence numbers (ESNs) to prevent replay
attacks within long-lived connections. Key rollover can be used to attacks within long-lived connections. Explicit master key rollover,
change keying material for various reasons (e.g., personnel accomplished by external means and indexed using the KeyID field, can
turnover), but is not required to support long-lived connections. be used to change keying material for various reasons (e.g.,
personnel turnover), but is not required to support long-lived
8.3. Implementing the TSAD as an External Database connections.
The TSAD implementation is considered external to TCP-AO. When an
external database is used, it would be useful to consider the
interface between TCP-AO and the TSAD. The following is largely a
restatement of information in Section 6.
The TSAD API is accessed during a connection as follows:
o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP
source address, 4 byte IP destination address, 2 byte TCP source
port, 2 byte TCP destination port).
o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 =
outbound)
o Number of bytes to be sent/received (two bytes); this is used on
the send side to trigger bytecount-based KeyID changes, and on the
receive side only for statistics or length-sensitive KeyID
selection.
o KeyID (single byte); this is provided only by a receiver (i.e.,
matching the KeyID of the received segment), where a sender would
leave this unspecified (and the call would return the appropriate
KeyID to use).
The call passes the number of bytes sent/received, and an indication
of the direction (send/receive), to enable traffic-based key
rollover.
The source port can be 'unbound', indicated by the value 0x0000. In
this case, the source port is considered a wildcard, and all
corresponding TSAD entries (indexed by the KeyID) are returned as a
list. This feature is used during connection establishment.
TSAD calls return the following parameters:
o TCP option exclusion flag (one byte, with 0x00 having the meaning
"exclude none" and 0x01 meaning "exclude all").
o An ordered list of zero or more connection key tuples:
<KeyID, MAC type, MAC length, key length, key>
o KeyID (one byte)
o MAC type (four bytes, an IKEv2 Transform Type 3 ID [RFC4306])
o MAC length (one byte)
o Key length (one byte)
o Key (byte sequence, indicating the key value)
When the TSAD returns zero keys, it is indicating that there are no
currently valid keys for the connection.
9. Obsoleting TCP MD5 and Legacy Interactions 10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier: TCP-AO obsoletes TCP MD5. As we have noted earlier:
>> TCP implementations MUST support TCP-AO. >> TCP implementations MUST support TCP-AO.
Systems implementing TCP MD5 only are considered legacy, and ought to Systems implementing TCP MD5 only are considered legacy, and ought to
be upgraded when possible. In order to support interoperation with be upgraded when possible. In order to support interoperation with
such legacy systems until upgrades are available: such legacy systems until upgrades are available:
>> TCP MD5 SHOULD be supported where interactions with legacy systems >> TCP MD5 SHOULD be supported where interactions with legacy systems
skipping to change at page 26, line 34 skipping to change at page 28, line 30
simultaneously for different connections (notably to support legacy simultaneously for different connections (notably to support legacy
use of TCP MD5). use of TCP MD5).
The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used
for a particular connection in TCP segments. for a particular connection in TCP segments.
It is possible that the TSAD could be augmented to support TCP MD5, It is possible that the TSAD could be augmented to support TCP MD5,
although use of a TSAD-like system is not described in RFC2385. although use of a TSAD-like system is not described in RFC2385.
It is possible to require TCP-AO for a connection or TCP MD5, but it It is possible to require TCP-AO for a connection or TCP MD5, but it
is not possible to require 'either'. Note that when TCP MD5 is is not possible to require 'either'. When an endpoint is configured
required on for a connection, it must be used [RFC2385]. This to require TCP MD5 for a connection, it must be added to all outgoing
prevents combined use of the two options for a given connection, to segments and validated on all incoming segments [RFC2385]. TCP MD5's
be determined by the other end of the connection. requirements prohibit the speculative use of both options for a given
connection, e.g., to be decided by the other end of the connection.
10. Interactions with non-NAT/NAPT Middleboxes 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 TCP-AO supports middleboxes that do not change the IP addresses or
ports of segments. Such middleboxes may modify some TCP options, in ports of segments. Such middleboxes may modify some TCP options, in
which case TCP-AO would need to be configured to ignore all options which case TCP-AO would need to be configured to ignore all options
in the MAC calculation on connections traversing that element. in the MAC calculation on connections traversing that element.
Note that ignoring TCP options may provide less protection, i.e., TCP Note that ignoring TCP options may provide less protection, i.e., TCP
options could be modified in transit, and such modifications could be options could be modified in transit, and such modifications could be
used by an attacker. Depending on the modifications, TCP could have used by an attacker. Depending on the modifications, TCP could have
compromised efficiency (e.g., timestamp changes), or could cease compromised efficiency (e.g., timestamp changes), or could cease
correct operation (e.g., window scale changes). These vulnerabilities correct operation (e.g., window scale changes). These vulnerabilities
affect only the TCP connections for which TCP-AO is configured to affect only the TCP connections for which TCP-AO is configured to
ignore TCP options. ignore TCP options.
11. Interactions with NAT/NAPT Devices 11.2. Interactions with NAT/NAPT Devices
TCP-AO cannot interoperate natively across NAT/NAPT devices, which TCP-AO cannot interoperate natively across NAT/NAPT devices, which
modify the IP addresses and/or port numbers. We anticipate that modify the IP addresses and/or port numbers. We anticipate that
traversing such devices will require variants of existing NAT/NAPT traversing such devices will require variants of existing NAT/NAPT
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
segment in another transport segment (e.g., UDP), as is done in IPsec 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, [RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO,
or IPsec NAT traversal can be used instead in such cases [RFC3947]. or IPsec NAT traversal can be used instead in such cases [RFC3947].
12. Evaluation of Requirements Satisfaction 12. Evaluation of Requirements Satisfaction
TCP-AO satisfies all the current requirements for a revision to TCP TCP-AO satisfies all the current requirements for a revision to TCP
MD5, as indicated in [Be07] and under current development. This MD5, as summarized below [Be07].
should not be a surprise, as the majority of the evolving
requirements are derived from its design. The following is a summary
of those requirements and notes where relevant.
1. Protected Elements - see Section 3.2. 1. Protected Elements
a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that A solution to revising TCP MD5 should protect (authenticate) the
we do not allow optional coverage because IP addresses define following elements.
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.
b. TCP header. Note that we do not allow optional port coverage This is supported - see Section 4.2.
because ports define a connection. If they can be coordinated
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 across a NAT/NAPT, the sender can compute the MAC based on the
received values; if not, a tunnel is required. received values; if not, a tunnel is required, as noted in
Section 11.2.
c. TCP options. Allows exclusion of TCP options from coverage, as b. TCP header.
required.
d. TCP data. Done. 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.
2. Option structure requirements c. TCP options.
a. Privacy. TCP-AO exposes only the key index, MAC, and overall Note that TCP-AO allows exclusion of TCP options from
option length. Note that short MACs could be obscured by using coverage, to enable use with middleboxes that modify options
longer option lengths but specifying a short MAC length (this (except when they modify TCP-AO itself). See Section 11.
is equivalent to a different MAC algorithm, and is specified
in the TSAD entry). See Section 3.2.
b. Allow optional per connection. Done - see Sections 7.3, 7.4, d. TCP payload data.
and 7.5.
c. Require non-optional. Done - see Sections 7.3, 7.4, and 7.5. 2. Option Structure Requirements
d. Standard parsing. Done - see Section 3.2. A solution to revising TCP MD5 should use an option with the
following structural requirements.
e. Compatible with Large Windows. Done - see Section 3.2. The This is supported - see Section 4.2.
size of the option is intended to allow use with Large Windows
and SACK. See also Section 1.1, which indicates that TCP-AO is
3 bytes shorter than TCP MD5 in the default case, assuming a
96-bit MAC.
f. Compatible with SACK. Done - see Section 3.2. The size of the a. Privacy.
option is intended to allow use with Large Windows and SACK.
See also Section 8 regarding key management. See also Section The option should not unnecessarily expose information about
1.1, which indicates that TCP-AO is 3 bytes shorter than TCP the TCP-AO mechanism. The additional protection afforded by
MD5 in the default case. 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 TSAD entry). See Section 4.2.
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 8.3, 8.4, and 8.5.
c. Require non-optional.
The option should be able to be specified as required for a
given connection.
This is supported - see Sections 8.3, 8.4, and 8.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 8.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 3. Cryptography requirements
a. Baseline defaults. TCP-AO uses TBD-WG-MACS as the default, as A solution to revising TCP MD5 should support modern cryptography
noted in Section 3.2. capabilities.
b. Good algorithms. TCP-AO uses TBD-WG-MACS as the default, but a. Baseline defaults.
does not otherwise specify the algorithms used. That would be
specified in the key management protocol, and should be
limited there.
c. Algorithm agility. TCP-AO allows any desired algorithm, The option should have a default that is required in all
subject to TCP option space limitations, as noted in Section implementations.
3.2. The TSAD allows separate connections to use different
algorithms.
d. Pre-TCP processing. Done - see Sections 7.3, 7.4, and 7.5. TCP-AO uses a default required algorithm as specified in [RFC-
Note that pre-TCP processing is required, because TCP segments TBD], as noted in Section 4.2.
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 [RFC-TBD]. The PRF is also
specified in [RFC-TBD]. The PRF input string follows the
typical design (in Section 6).
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 TSAD 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 8.3, 8.4, and 8.5. Note that
pre-TCP processing is further required, because TCP segments
cannot be discarded solely based on a combination of cannot be discarded solely based on a combination of
connection state and out-of-window checks; many such segments, connection state and out-of-window checks; many such segments,
although discarded, cause a host to respond with a replay of although discarded, cause a host to respond with a replay of
the last valid ACK, e.g. [RFC793]. 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 5).
e. Parameter changes require key changes. TSAD parameters that e. Security parameter changes require key changes.
should not change during a connection (TCP connection ID,
receiver TCP connection ID, TCP option exclusion list) cannot
change. Other parameters change only when a key is changed,
using the key tuple mechanism in the TSAD. See Section 6.
4. Keying requirements. TCP-AO does not specify a key management The option should require that the key change whenever the
system, but does indicate a proposed interface to the TSAD, security parameters change. This avoids the need for
allowing a completely separate key system. 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.
a. Intraconnection rekeying. Supported by the KeyID and multiple TSAD parameters that should not change during a connection (by
key tuples in a TSAD entry; see Section 6. 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 TSAD. See Section 7.
b. Efficient rekeying. Supported by the KeyID. See Section 8. 4. Keying requirements.
c. Automated and manual keying. Supported by the TSAD interface. A solution to revising TCP MD5 should support manual keying, and
See Section 8. Enhanced by the generation of unique per- should support the use of an external automated key management
connection keys as noted in Section 5. system (e.g., a protocol or other mechanism).
d. Key management agnostic. Supported by the TSAD interface. See Note that TCP-AO does not specify a master key management system,
Section 8.1. but does indicate a proposed interface to the TSAD, allowing a
completely separate master key system, as noted in Section 7.
5. Expected constraints a. Intraconnection rekeying.
a. Silent failure. Done - see Sections 7.3, 7.4, and 7.5. The option should support rekeying during a connection, to
avoid the impact of long-duration connections.
b. At most one such option per segment. Done - see Section 3.2. This is supported by the KeyID and multiple master key tuples
in a TSAD entry; see Section 7.
c. Outgoing all or none. Done - see Section 7.4. b. Efficient rekeying.
d. Incoming all checked. Done - see Section 7.5. 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.
e. Non-interaction with TCP MD5. Done - see Section 9. This is supported by the use of the KeyID. See Section 9.
f. Optional ICMP discard. Done - see Section 13. c. Automated and manual keying.
g. Allows use of NAT/NAPT devices. Done - see Section 10. The option should support both automated and manual keying.
h. Maintain TCP connection semantics, in which the socket pair The use of a separate TSAD allows external automated and
manual keying. See Section 9. 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 6.
d. Key management agnostic.
The option should not assume or require a particular key
management solution.
This is supported by use of a separate TSAD. See Section 9.1.
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 8.3, 8.4, and 8.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 8.4.
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 8.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, Codes 2-4.
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 alone defines a TCP association and all its security
parameters. Done - see Sections 6 and 10. parameters.
i. Try to avoid creating a CPU DOS attack opportunity. Done - see This is supported - see Sections 7 and 11.
Section 13.
13. Security Considerations 13. Security Considerations
Use of TCP-AO, like use of TCP MD5 or IPsec, will impact host 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 performance. Connections that are known to use TCP-AO can be attacked
by transmitting segments with invalid MACs. Attackers would need to by transmitting segments with invalid MACs. Attackers would need to
know only the TCP connection ID and TCP-AO Length value to know only the TCP connection ID and TCP-AO Length value to
substantially impact the host's processing capacity. This is similar substantially impact the host's processing capacity. This is similar
to the susceptibility of IPsec to on-path attacks, where the IP to the susceptibility of IPsec to on-path attacks, where the IP
addresses and SPI would be visible. For IPsec, the entire SPI space addresses and SPI would be visible. For IPsec, the entire SPI space
skipping to change at page 30, line 19 skipping to change at page 35, line 41
Internet routers both ports could be arbitrary (i.e., determined a- Internet routers both ports could be arbitrary (i.e., determined a-
priori out of band), which would constitute roughly the same off-path priori out of band), which would constitute roughly the same off-path
antispoofing protection of an arbitrary SPI. antispoofing protection of an arbitrary SPI.
TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets
typically occur after peer crashes, either in response to new typically occur after peer crashes, either in response to new
connection attempts or when data is sent on stale connections; in connection attempts or when data is sent on stale connections; in
either case, the recovering endpoint may lack the connection key either case, the recovering endpoint may lack the connection key
required (e.g., if lost during the crash). This may result in time- required (e.g., if lost during the crash). This may result in time-
outs, rather than more responsive recovery after such a crash. As outs, rather than more responsive recovery after such a crash. As
noted in Section 5, such cases may also result in persistent TCP noted in Section 6, such cases may also result in persistent TCP
state for old connections that cannot be cleared, and so state for old connections that cannot be cleared, and so
implementations should be capable of detecting an excess of such implementations should be capable of detecting an excess of such
connections and clearing their state if needed to protect memory connections and clearing their state if needed to protect memory
utilization [Je07]. utilization [Je07].
TCP-AO does not include a fast decline capability, e.g., where a SYN- 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 ACK is received without an expected TCP-AO option and the connection
is quickly reset or aborted. Normal TCP operation will retry and is quickly reset or aborted. Normal TCP operation will retry and
timeout, which is what should be expected when the intended receiver timeout, which is what should be expected when the intended receiver
is not capable of the TCP variant required anyway. Backoff is not is not capable of the TCP variant required anyway. Backoff is not
optimized because it would present an opportunity for attackers on optimized because it would present an opportunity for attackers on
the wire to abort authenticated connection attempts by sending the wire to abort authenticated connection attempts by sending
spoofed SYN-ACKs without the TCP-AO option. spoofed SYN-ACKs without the TCP-AO option.
TCP-AO 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-AO is intended to provide similar protections to IPsec, but is 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 not intended to replace the use of IPsec or IKE either for more
robust security or more sophisticated security management. robust security or more sophisticated security management.
TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes
recommendations regarding dropping ICMPs in certain contexts, or recommendations regarding dropping ICMPs in certain contexts, or
requiring that they are endpoint authenticated in others [RFC4301]. requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the 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]. level of authentication for ICMP that TCP-AO provides for TCP [Go07].
>> A TCP-AO implementation MUST allow the system administrator to >> A TCP-AO implementation MUST allow the system administrator to
configure whether TCP will ignore incoming ICMP messages of Type 3 configure whether TCP will ignore incoming ICMP messages of Type 3
Codes 2-4 intended for connections that match TSAD entries with non- (destination unreachable) Codes 2-4 (protocol unreachable, port
NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be unreachable, and fragmentation needed - 'hard errors') intended for
logged. 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', This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection. This recommendation is intended which would abort the TCP connection [RFC1122]. This recommendation
to be similar to how IPsec would handle those messages [RFC4301]. is intended to be similar to how IPsec would handle those messages
[RFC4301].
TCP-AO includes the TCP connection ID in the MAC calculation. This TCP-AO includes the TCP connection ID (the socket pair) in the MAC
prevents connections using the same key (for whatever reason) from calculation. This prevents different concurrent connections using the
potentially enabling a traffic-crossing attack, in which segments to same connection key (for whatever reason) from potentially enabling a
one socket pair are diverted to attack a different socket pair. When traffic-crossing attack, in which segments to one socket pair are
multiple connections use the same key, it would be useful to know diverted to attack a different socket pair. When multiple connections
that packets intended for one ID could not be (maliciously or use the same master key, it would be useful to know that packets
otherwise) modified in transit and end up being authenticated for the intended for one ID could not be (maliciously or otherwise) modified
other ID. The ID cannot be zeroed, because to do so would require in transit and end up being authenticated for the other ID. The ID
that the TSAD index was unique in both directions (ID->key and key- cannot be zeroed, because to do so would require that the TSAD index
>ID). That requirement would place an additional burden of uniqueness was unique in both directions (ID->key and key->ID). That requirement
on keys within endsystems, and potentially across endsystems. would place an additional burden of uniqueness on master keys within
Although the resulting attack is low probability, the protection endsystems, and potentially across endsystems. Although the resulting
afforded by including the received ID warrants its inclusion in the attack is low probability, the protection afforded by including the
MAC, and does not unduly increase the MAC calculation or key received ID warrants its inclusion in the MAC, and does not unduly
management system. increase the MAC calculation or master key management system.
The use of any security algorithm can present an opportunity for a The use of any security algorithm can present an opportunity for a
CPU DOS attack, where the attacker sends false, random segments that CPU DOS attack, where the attacker sends false, random segments that
the receiver under attack expends substantial CPU effort to reject. the receiver under attack expends substantial CPU effort to reject.
In IPsec, such attacks are reduced by the use of a large Security In IPsec, such attacks are reduced by the use of a large Security
Parameter Index (SPI) and Sequence Number fields to partly validate Parameter Index (SPI) and Sequence Number fields to partly validate
segments before CPU cycles are invested validated the Integrity Check segments before CPU cycles are invested validated the Integrity Check
Value (ICV). In TCP-AO, the socket pair performs most of the function 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 of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay
attacks, isn't needed in all cases due to TCP's Sequence Number, attacks, isn't needed in all cases due to TCP's Sequence Number,
which is used to reorder received segments. TCP already protects which is used to reorder received segments. TCP already protects
itself from replays of authentic segment data as well as authentic itself from replays of authentic segment data as well as authentic
explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic
replays could affect TCP congestion control [Sa99]. TCP-AO does not replays could affect TCP congestion control [Sa99]. TCP-AO does not
skipping to change at page 32, line 10 skipping to change at page 37, line 29
Further, it is not useful to validate TCP's Sequence Number before Further, it is not useful to validate TCP's Sequence Number before
performing a TCP-AO authentication calculation, because out-of-window performing a TCP-AO authentication calculation, because out-of-window
segments can still cause valid TCP protocol actions (e.g., ACK segments can still cause valid TCP protocol actions (e.g., ACK
retransmission) [RFC793]. It is similarly not useful to add a retransmission) [RFC793]. It is similarly not useful to add a
separate Sequence Number field to the TCP-AO option, because doing so 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. could cause a change in TCP's behavior even when segments are valid.
14. IANA Considerations 14. IANA Considerations
The TCP-AO option defines no new namespaces. [NOTE: This section be removed prior to publication as an RFC]
The TCP-AO option uses the TCP option Kind value TCP-IANA-KIND,
allocated by IANA from the TCP option Kind namespace.
To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2
Transform Type 3 IDs, because that database of names already exists
(not because of any reliance on IKEv2) [RFC4306].
[NOTE: The following to be removed prior to publication as an RFC] The TCP-AO option defines no new namespaces.
The TCP-AO option requires that IANA allocate a value from the TCP The TCP-AO option requires that IANA allocate a value from the TCP
option Kind namespace, to be replaced for TCP-IANA-KIND throughout option Kind namespace, to be replaced for TCP-IANA-KIND throughout
this document. this document.
15. Acknowledgments To specify MAC and PRF algorithms, TCP-AO refers to a separate
document that may involve IANA actions [RFC-TBD].
This document was inspired by the revisions to TCP MD5 suggested by
Brian Weis and Ron Bonica [Bo07][We05][We07]. Russ Housley suggested
L4/application layer management of the TSAD. The KeyID field was
motivated by Steve Bellovin. Eric Rescorla suggested the use of ISNs
in the connection key computation and ESNs to avoid replay attacks,
and Brian Weis extended the computation to incorporate the entire
connection ID. Alfred Hoenes, Charlie Kaufman, and Adam Langley
provided substantial feedback. The document is the result of
collaboration with the TCP Authentication Design team (tcp-auth-dt).
This document was prepared using 2-Word-v2.0.template.dot. 15. References
16. References 15.1. Normative References
16.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol," STD-7,
RFC-793, Standard, Sept. 1981.
[RFC793] Postel, J., "Transmission Control Protocol," STD 007, RFC [RFC1122] Braden, R., "Requirements for Internet Hosts --
793, Standard, Sept. 1981. Communication Layers," RFC-1122, Oct. 1989.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, Proposed Selective Acknowledgement Options", RFC-2018, Proposed
Standard, April 1996. Standard, April 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Best Current Requirement Levels", BCP-14, RFC-2119, Best Current
Practice, March 1997. Practice, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC 2385, Proposed Standard, Aug. 1998. Signature Option," RFC-2385, Proposed Standard, Aug. 1998.
[RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP [RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH," RFC 2403, Proposed Standard, Nov. 1998. and AH," RFC-2403, Proposed Standard, Nov. 1998.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification," RFC 2460, Proposed Standard, Dec. (IPv6) Specification," RFC-2460, Proposed Standard, Dec.
1998. 1998.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, Proposed Standard, Recovery Algorithm for TCP", RFC-3517, Proposed Standard,
April 2003. April 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol,"
4306, Proposed Standard, Dec. 2005. RFC-4306, Proposed Standard, Dec. 2005.
16.2. Informative References [RFC-TBD] Lebovitz, G., "MAC Algorithms for TCP-AO," RFC-TBD, date
TBD.
15.2. Informative References
[Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem
Statement and Requirements for a TCP Authentication Statement and Requirements for a TCP Authentication
Option," draft-bellovin-tcpsec-01, (work in progress), Jul. Option," draft-bellovin-tcpsec-01, (work in progress), Jul.
2007. 2007.
[Bo07] Bonica, R., et. al, "Authentication for TCP-based Routing [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
and Management Protocols," draft-bonica-tcp-auth-06, (work "Authentication for TCP-based Routing and Management
in progress), Feb. 2007. Protocols," draft-bonica-tcp-auth-06, (work in progress),
Feb. 2007.
[Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-04, (work in progress), Oct. 2008. attacks-04, (work in progress), Oct. 2008.
[Je07] Jethanandani, M., and M. Bashyam, "TCP Robustness in [Je07] Jethanandani, M., and M. Bashyam, "TCP Robustness in
Persist Condition," draft-mahesh-persist-timeout-02, (work Persist Condition," draft-mahesh-persist-timeout-02, (work
in progress), Oct. 2007. in progress), Oct. 2007.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. 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., Bellare, M., Canetti, R., "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-
Hashing for Message Authentication," RFC 2104, Hashing for Message Authentication," RFC-2104,
Informational, Feb. 1997. Informational, Feb. 1997.
[RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation - [RFC2766] Tsirtsis, G., Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)," RFC 2766, Proposed Protocol Translation (NAT-PT)," RFC-2766, Proposed
Standard, Feb. 2000. 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 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option," RFC 3562, Informational, July 2003. Signature Option," RFC-3562, Informational, July 2003.
[RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe,
"Negotiation of NAT-Traversal in the IKE," RFC 3947, Jan. "Negotiation of NAT-Traversal in the IKE," RFC-3947,
2005. Proposed Standard, Jan. 2005.
[RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet [RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
Protocol," RFC 4301, Proposed Standard, Dec. 2005. Protocol," RFC-4301, Proposed Standard, Dec. 2005.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5," RFC [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5,"
4808, Informational, Mar. 2007. RFC-4808, Informational, Mar. 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks,"
RFC4953, Jul. 2007. RFC-4953, Informational, Jul. 2007.
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP [Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver," ACM Congestion Control with a Misbehaving Receiver," ACM
Computer Communications Review, V29, N5, pp71-78, October Computer Communications Review, V29, N5, pp71-78, October
1999. 1999.
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," [SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4),"
Specification SDN.401, Revision 1.2, July 12, 1988. Specification SDN.401, Revision 1.2, July 12, 1988.
[To??] Touch, J., A. Mankin, "The TCP Simple Authentication [To06] Touch, J., A. Mankin, "The TCP Simple Authentication
Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work
in progress), Oct. 2006. in progress), Oct. 2006.
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash [Wa05] Wang, X., H. Yu, "How to break MD5 and other hash
functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35. functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[We05] Weis, B., "TCP Message Authentication Code Option," draft- [We05] Weis, B., "TCP Message Authentication Code Option," draft-
weis-tcp-mac-option-00, (expired work in progress), Dec. weis-tcp-mac-option-00, (expired work in progress), Dec.
2005. 2005.
[We07] Weis, B., et al., "Automated key selection extension for 16. Acknowledgments
the TCP Authentication Option," draft-weis-tcp-auth-auto-
ks-03, (work in progress), Oct. 2007.
Author's Addresses Alfred Hoenes, Charlie Kaufman, and Adam Langley provided substantial
feedback on this document.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
Email: touch@isi.edu Email: touch@isi.edu
URL: http://www.isi.edu/touch URL: http://www.isi.edu/touch
skipping to change at page 35, line 33 skipping to change at line 1824
Email: mankin@psg.com Email: mankin@psg.com
URL: http://www.psg.com/~mankin/ URL: http://www.psg.com/~mankin/
Ronald P. Bonica Ronald P. Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20171 Herndon, VA 20171
U.S.A. U.S.A.
Email: rbonica@juniper.net Email: rbonica@juniper.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
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.
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.
 End of changes. 199 change blocks. 
524 lines changed or deleted 749 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/