draft-ietf-tcpm-tcp-auth-opt-01.txt   draft-ietf-tcpm-tcp-auth-opt-02.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 R. Bonica Intended status: Proposed Standard Johns Hopkins Univ.
Expires: January 2009 Juniper Networks Expires: May 2009 R. Bonica
July 14, 2008 Juniper Networks
November 3, 2008
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-01.txt draft-ietf-tcpm-tcp-auth-opt-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 January 14, 2009. This Internet-Draft will expire on May 3, 2009.
Abstract Abstract
This document specifies a TCP Authentication Option (TCP-AO) which is This document specifies the TCP Authentication Option (TCP-AO), which
intended to replace the TCP MD5 Signature option of RFC-2385 (TCP obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
MD5). TCP-AO specifies the use of stronger Message Authentication specifies the use of stronger Message Authentication Codes (MACs),
Codes (MACs) and provides more details on the association of security protects against replays even for long-lived TCP connections, and
associations with TCP connections. TCP-AO assumes an external, out- provides more details on the association of security with TCP
of-band mechanism (manual or via a separate protocol) for session key connections than TCP MD5. TCP-AO is compatible with either static
establishment, parameter negotiation, and rekeying, replicating the keying or an external, out-of-band key management mechanism; in
separation of key management and key use as in the IPsec suite. The either case, TCP-AO also protects connections when using the same key
result is intended to be a simple modification to support current across repeated instances of a connection. The result is intended to
infrastructure uses of TCP MD5, such as to protect BGP and LDP, and support current infrastructure uses of TCP MD5, such as to protect
to support a larger set of MACs with minimal other system and long-lived connections (as used, e.g., in BGP and LDP), and to
operational changes. TCP-AO uses a new option identifier, even though support a larger set of MACs with minimal other system and
it is intended to be mutually exclusive with TCP MD5 on a given TCP operational changes. TCP-AO uses its own option identifier, even
connection. It supports IPv6, and is fully compatible with though used mutually exclusive of TCP MD5 on a given TCP connection.
requirements under development for an update to TCP MD5. 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. Introduction...................................................3
1.1. Executive Summary.........................................3 1.1. Executive Summary.........................................4
1.2. List of TBD Items.........................................5 1.2. List of TBD Items.........................................5
1.3. List of currently pending issues and to-do items..........5 1.3. Changes from Previous Versions............................5
1.4. Changes from Previous Versions............................6 1.3.1. New in draft-ietf-tcp-auth-opt-02....................5
1.4.1. New in draft-ietf-tcp-auth-opt-01....................6 1.3.2. New in draft-ietf-tcp-auth-opt-01....................6
1.4.2. New in draft-ietf-tcp-auth-opt-00....................6 1.3.3. New in draft-ietf-tcp-auth-opt-00....................7
1.4.3. New in draft-touch-tcp-simple-auth-03................7 1.3.4. New in draft-touch-tcp-simple-auth-03................8
1.4.4. New in draft-touch-tcp-simple-auth-02................7 1.3.5. New in draft-touch-tcp-simple-auth-02................8
1.4.5. New in draft-touch-tcp-simple-auth-01................7 1.3.6. New in draft-touch-tcp-simple-auth-01................8
1.5. Summary of RFC-2119 Requirements..........................8 1.4. Summary of RFC-2119 Requirements..........................8
2. Conventions used in this document..............................8 2. Conventions used in this document..............................9
3. The TCP Simple Authentication Option...........................8 3. The TCP Authentication Option..................................9
3.1. Review of TCP MD5 Option..................................8 3.1. Review of TCP MD5 Option..................................9
3.2. TCP-AO Option.............................................9 3.2. TCP-AO Option............................................10
4. Security Association Management...............................12 4. Preventing replay attacks within long-lived connections.......13
5. TCP-AO Interaction with TCP...................................14 5. Computing connection keys from TSAD entries...................14
5.1. User Interface...........................................14 6. Security Association Management...............................16
5.2. TCP States and Transitions...............................15 7. TCP-AO Interaction with TCP...................................19
5.3. TCP Segments.............................................15 7.1. User Interface...........................................19
5.4. Sending TCP Segments.....................................16 7.2. TCP States and Transitions...............................20
5.5. Receiving TCP Segments...................................17 7.3. TCP Segments.............................................20
5.6. Impact on TCP Header Size................................18 7.4. Sending TCP Segments.....................................21
6. Key Establishment and Duration Issues.........................18 7.5. Receiving TCP Segments...................................21
6.1. Implementing the TSAD as an External Database............19 7.6. Impact on TCP Header Size................................23
7. Interactions with TCP MD5.....................................20 8. Key Establishment and Duration Issues.........................23
8. Interactions with NAT/NAPT Devices............................21 8.1. Key reuse across socket pairs............................24
9. Evaluation of Requirements Satisfaction.......................21 8.2. Key use within a long-lived connection...................24
10. Security Considerations......................................24 8.3. Implementing the TSAD as an External Database............24
11. IANA Considerations..........................................26 9. Obsoleting TCP MD5 and Legacy Interactions....................26
12. Acknowledgments..............................................26 10. Interactions with non-NAT/NAPT Middleboxes...................26
13. References...................................................26 11. Interactions with NAT/NAPT Devices...........................27
13.1. Normative References....................................26 12. Evaluation of Requirements Satisfaction......................27
13.2. Informative References..................................27 13. Security Considerations......................................29
14. IANA Considerations..........................................32
15. Acknowledgments..............................................32
16. References...................................................32
16.1. Normative References....................................32
16.2. Informative References..................................33
1. Introduction 1. 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 recently-documented concerns about TCP MD5. Its There have been many recent concerns about TCP MD5. Its use of a
use of a simple keyed hash for authentication is problematic because simple keyed hash for authentication is problematic because there
there have been escalating attacks on the algorithm itself [Be05] have been escalating attacks on the algorithm itself [Wa05]. TCP MD5
[Bu06]. TCP MD5 also lacks both key management and algorithm agility. also lacks both key management and algorithm agility. This document
This document proposes to add the latter, but suggests that TCP adds the latter, but notes that TCP does not provide a sufficient
should not be the framework for cryptographic key management. This framework for cryptographic key management. This document obsoletes
document replaces the TCP MD5 option to become a more general TCP the TCP MD5 option with a more general TCP Authentication Option
Authentication Option (TCP-AO), to support the use of other, stronger (TCP-AO), to support the use of other, stronger hash functions,
hash functions and to provide a more structured recommendation on provide replay protection for long-lived connections and across
external key management. The result is compatible with IPv6, and is repeated instances of a single connection, and to provide a more
fully compatible with requirements under development for an update to structured recommendation on external key management. The result is
TCP MD5 [Be07]. 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 for some routing protocols, or in cases where
keys need to be tightly coordinated with individual transport keys need to be tightly coordinated with individual transport
sessions [Be07]. sessions [Be07].
Note that this option is intended to obsolete the use of TCP MD5, Note that TCP-AO obsoletes TCP MD5, although a particular
although a particular implementation may support both for backward implementation may support both for backward compatibility. For a
compatibility. For a given connection, only one can be in use. TCP given connection, only one can be in use. TCP MD5-protected
MD5-protected connections cannot be migrated to TCP-AO, since TCP MD5 connections cannot be migrated to TCP-AO because TCP MD5 does not
does not support any changes to a connection's security configuration support any changes to a connection's security configuration once
once established. established.
1.1. Executive Summary 1.1. Executive Summary
This document replaces TCP MD5 as follows [RFC2385]: This document replaces TCP MD5 as follows [RFC2385]:
o 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 Allows TCP MD5 to continue to be used for other connections.
o Replaces MD5's one implicit MAC algorithm with two prespecified
MACs (TBD-WG-MACS), and allows other MACs at the implementer's
discretion.
o Allows rekeying during a TCP connection, assuming that an out-of-
band protocol or manual mechanism coordinates the change of key
and that incorrectly keyed segments are ignored. In such cases, a
key ID makes key selection more efficient.
o Provides more detail in how this option interacts with TCP's o TCP-AO allows TCP MD5 to continue to be used for other (legacy)
states, event processing, and user interface. connections.
o Proposed option is 3 bytes shorter (15 bytes overall, rather than o TCP-AO replaces MD5's single MAC algorithm with two prespecified
18) in the default case (assuming a 96-bit MAC, TBD-WG-MACLEN). MACs (TBD-WG-MACS), and allows extension to include other MACs.
This document differs from other proposals to update TCP MD5 in that o TCP-AO allows rekeying during a TCP connection, assuming that an
TCP-AO: [Bo07][We05][We07]: out-of-band protocol or manual mechanism coordinates the key
change. In such cases, a key ID allows the efficient concurrent
use of multiple keys. Note that TCP MD5 does not preclude rekeying
during a connection, but does not require its support either.
Further, TCP-AO supports rekeying with zero packet loss, whereas
rekeying in TCP MD5 can lose packets in transit during the
changeover or require trying multiple keys on each received
segment during key use overlap.
o Is fully compatible with requirements currently under development. o TCP-AO provides automatic key rollover to provide replay
protection for long-lived connections.
o Does not support dynamic parameter negotiation. o TCP-AO ensures per-connection keys as unique as the TCP connection
itself, using TCP's ISNs for differentiation, even when static
keys are used for repeated instances of a socket pair.
o Does not support in-band session key negotiation. o This document provides more detail in how this option interacts
with TCP's states, event processing, and user interface.
o Does not support in-band session rekeying. 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
MAC).
o Does not require additional timers. This document differs from an IPsec/IKE solution in that TCP-AO as
follows [RFC4301][RFC4306]:
o Always authenticates the the segment pseudoheader, header, and o TCP-AO does not support dynamic parameter negotiation.
data.
o Provides more detail in how this option interacts with TCP's o TCP-AO uses TCP's socket pair (source address, destination
states, event processing, and user interface. address, source port, destination port) as a security parameter
index, rather than using a separate field as a primary index
(IPsec's SPI).
o Is shorter than TCP MD5 in the default case. o TCP-AO forces a change of computed MACs when a connection
restarts, even when reusing a TCP socket pair (IP addresses and
port numbers) [Be07].
o Does not expose the MAC algorithm in the header. o TCP-AO does not support encryption.
o Requires a key ID. o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated via IPsec, depending on the configuration).
o Supports TCP over either IPv4 or IPv6. 1.2. List of TBD Items
This document differs from an IPsec/IKE solution in that TCP-AO [NOTE: to be omitted upon final publication as RFC]
[RFC4301][RFC4306]:
o Does not support dynamic parameter negotiation. SAAG: The following items are to be determined (TBD) prior to
publication. Once a value is chosen, it should be replaced for the
notation below throughout this document and the item removed from
this list.
o Does not require a key ID (SPI), but does allow one. TBD-IANA-KIND new TCP option Kind for TCP-AO, assigned by IANA
o Does not protect from replay attacks. TBD-WG-MACS list of default required MAC algorithms
o Forces a change of connection key when a connection restarts, even TBD-WG-MACLEN default length of MAC used in the TCP-AO MAF
when reusing a TCP socket pair (IP addresses and port numbers)
[Be07].
o Does not support encryption. 1.3. Changes from Previous Versions
o Does not authenticate ICMP messages (some may be authenticated in [NOTE: to be omitted upon final publication as RFC]
IPsec, depending on the configuration).
1.2. List of TBD Items 1.3.1. New in draft-ietf-tcp-auth-opt-02
[NOTE: to be omitted upon final publication as RFC] o List issue - Replay Protection: incorporated key rollover based on
extended sequence number space, not using KeyID space.
The following items are to be determined (TBD) prior to publication. o List issue - Unique Connection Keys: ISNs are used to generate
Once a value is chosen, it should be replaced for the notation below unique connection keys even when static keys used for repeated
throughout this document and the item removed from this list. instances of a socket pair.
TBD-IANA-KIND new TCP option Kind for TCP-AO, assigned by IANA o List issue - Header Format and Alignment: Moved KeyID to front.
TBD-WG-MACS list of default required MAC algorithms o List issue - Reserved KeyID Value: Suggestion to reserve a single
KeyID value for implementation optimization received no support on
the WG list, so this was not changed.
TBD-WG-MACLEN default length of MAC used in the TCP-AO MAF o List issue - KeyID Randomness: KeyIDs are not assumed random; a
note was added that nonce-based filtering should be done on a
portion of the MAC (incorporated into the algorithm), and that
header fields should not be assumed to have cryptographic
properties (e.g., randomness).
1.3. List of currently pending issues and to-do items o List issue - Support for NATs: preliminary rough consensus
suggests that TCP-AO should not be augmented to support NAT
traversal. Existing mechanisms for such traversal (UDP support)
can be applied, or IPsec NAT traversal is recommended in such
cases instead.
[NOTE: to be omitted upon final publication as an RFC] o IETF-72 topic - providing algorithm ID and T-bit (options
excluded) locations in the header: (No current consensus was
reached on this topic, so no change was made.)
o [IESG] Should this document deprecate TCP MD5? o IETF-72 topic - providing additional header bits for in-band key
change signaling (draft-bonica's "K" bit): (No current consensus
was reached on this topic, so no change was made.)
o [SAAG] Which two MAC algorithms should be required as default? o Clarified TCP-AO as obsoleting TCP MD5.
Should one be set as the primary default?
o [TCPM] Should TCP-AO include a negotiation protocol with a o Clarified the MAC Type as referring to the IANA registry of IKEv2
backoff, i.e., to allow non-TCP-AO endpoints to connect more transforms, not the RFC establishing that registry.
quickly (or is this a security problem)? Note that this would be
useful only where a rapid failure is useful, or where the TCP
might backoff and use another mode (e.g., TCP MD5 or no
authentication).
o [EDITORS TO-DO] Add a discussion of the use with manual keys, esp. o Added citation to the Wang/Yu paper regarding attacks on MD5 Wa05
for connections with dynamic source ports. to replace reports in Be05 and Bu06.
o [EDITORS TO-DO] Review need for LISTEN instructions. o Explained why option exclusion can't be changed during a
connection.
1.4. Changes from Previous Versions o Clarified that AO explicitly allows rekeying during a TCP
connection, without impacting packet loss.
[NOTE: to be omitted upon final publication as RFC] o Described TCP-AO's interaction with reboots more clearly, and
explained the need to clear out old state that persists
indefinitely.
1.4.1. New in draft-ietf-tcp-auth-opt-01 1.3.2. 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
IP addresses or TCP ports, both of which would be required to IP addresses or TCP ports, both of which would be required to
support NATs without any coordination. This appears to present a support NATs without any coordination. This appears to present a
problem for key management - if the key manager knows the received problem for key management - if the key manager knows the received
addrs and ports, it should coordinate them (as indicated in Sec addrs and ports, it should coordinate them (as indicated in Sec
8). 8).
o Options are included or excluded all-or-none. Excluded options are o Options are included or excluded all-or-none. Excluded options are
deleted, not just zeroed, to avoid the impact of reordering or deleted, not just zeroed, to avoid the impact of reordering or
length changes of such options. length changes of such options.
o Augment replay discussion in security considerations.
o Revise discussion of IKEv2 MAC algorithm names.
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.4.2. New in draft-ietf-tcp-auth-opt-00 1.3.3. 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 7, line 13 skipping to change at page 8, line 5
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.4.3. New in draft-touch-tcp-simple-auth-03 1.3.4. 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.4.4. New in draft-touch-tcp-simple-auth-02 1.3.5. 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.4.5. New in draft-touch-tcp-simple-auth-01 1.3.6. 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.5. Summary of RFC-2119 Requirements 1.4. Summary of RFC-2119 Requirements
[NOTE: a summary will be placed here prior to last call] [NOTE: a summary will be placed here prior to last call]
2. Conventions used in this document 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 Simple Authentication Option 3. The TCP Authentication Option
The TCP Simple Authentication Option (TCP-AO) uses a new TCP option The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
Kind value, (TBD-IANA-KIND). of TBD-IANA-KIND.
3.1. Review of TCP MD5 Option 3.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... |
+---------+---------+-------------------+ +---------+---------+-------------------+
| | | |
+---------------------------------------+ +---------------------------------------+
| | | |
+---------------------------------------+ +---------------------------------------+
| | | |
+-------------------+-------------------+ +-------------------+-------------------+
| | | |
+-------------------+ +-------------------+
Figure 1 Current TCP MD5 Option [RFC2385] Figure 1 The TCP MD5 Option [RFC2385]
In the current TCP MD5 option, the length is fixed, and the MD5 In the TCP MD5 option, the length is fixed, and the MD5 digest
digest occupies 16 bytes following the Kind and Length fields, using occupies 16 bytes following the Kind and Length fields, using the
the full MD5 digest of 128 bits [RFC1321]. full MD5 digest of 128 bits [RFC1321].
The current TCP MD5 option specifies the use of the MD5 digest The TCP MD5 option specifies the use of the MD5 digest calculation
calculation over the following values in the following order: over the following values in the following order:
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. TCP header excluding options and checksum 2. The TCP header excluding options and checksum.
3. TCP data 3. The TCP data payload.
4. connection key 4. The connection key.
3.2. TCP-AO Option 3.2. TCP-AO Option
The new TCP-AO option is intended to be a superset of the TCP MD5 The new TCP-AO option provides a superset of the capabilities of TCP
capability, and to be minimal in the spirit of SP4 [SDNS88]. TCP-AO MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
uses a new Kind field, and similar Length field to TCP MD5, and is Kind field, and similar Length field to TCP MD5, as well as a KeyID
shown in Figure 2. field as shown in Figure 2.
+---------------------+---------+-------------------+ +----------+----------+----------+----------+
| Kind= TBD-IANA-KIND | Len=var | MAC | | Kind | Length | KeyID | MAC |
+---------------------+---------+-------------------+ +----------+----------+----------+----------+
| MAC (con't) ... | MAC (con't) ...
+-------------------------------------... +----------------------------------...
...-----------------+---------+ ...-----------------+
... MAC (con't) | KeyID | ... MAC (con't) |
...-----------------+---------+ ...-----------------+
Figure 2 Proposed 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 field indicating the TCP-AO Option. TCP-AO uses o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP-
a new Kind value=TBD-IANA-KIND. Because of how keys are managed AO uses a new Kind value of TBD-IANA-KIND. Because of how keys are
(see Section 4), an endpoint will not use TCP-AO for the same managed (see Section 6), an endpoint will not use TCP-AO for the
connection where TCP MD5 is used. same connection in which TCP MD5 is used.
o Length: An unsigned 8-bit field indicating the length of the TCP- >> A single TCP segment MUST NOT have more than one TCP-AO option.
AO option in bytes, including the Kind, Length, and KeyID fields.
>> The Length MUST be greater than or equal to 3. o Length: An unsigned 1-byte field indicating the length of the TCP-
AO option in bytes, including the Kind, Length, KeyID, and MAC
fields.
>> The Length value MUST be greater than or equal to 3.
>> The Length value MUST be consistent with the TCP header length; >> The Length value MUST be consistent with the TCP header length;
this is a consistency check and to avoid overrun/underrun abuse. this is a consistency check and avoids overrun/underrun abuse.
Values of 3 and other small values are of dubious utility (e.g., Values of 3 and other small values are of dubious utility (e.g.,
for MAC=NONE, or for very short MACs) but not specifically for MAC=NONE, or small values for very short MACs) but not
prohibited. specifically prohibited.
o KeyID: An unsigned 1-byte field is used to support efficient key
changes during a connection and/or to help with key coordination
during connection establishment, and will be discussed further in
Section 4. Note that the KeyID has no cryptographic properties -
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. Because the KeyID is the segment being authenticated is allowed.
one byte, it may be useful to have odd-length MACs (e.g., to
select an odd number of bytes of a computed even-length MAC).
o KeyID: The last byte of the option is a KeyID field. The KeyID is
used to support efficient key rollover during a connection and/or
to help with key coordination during connection establishment, and
will be discussed further in Sections 4.
>> TCP-AO MUST support TBD-WG-MACS; other MACs MAY be supported >> TCP-AO MUST support TBD-WG-MACS; other MACs MAY be supported
[RFC2403]. [RFC2403].
>> A single TCP segment MUST NOT have more than one TCP-AO option.
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 TCP pseudoheader: IP source and destination addresses, 1. The extended sequence number (ESN), in network-standard byte
order, as follows:
+--------+--------+--------+--------+
| ESN |
+--------+--------+--------+--------+
Figure 3 Extended sequence number
The ESN for transmitted segments is locally maintained from a
locally maintained SND.ESN value, for received segments, a local
RCV.ESN value is used. The details of how these values are
maintained and used is described in Sections 4, 7.4, and 7.5.
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 |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Proto | TCP Length | | zero | Proto | TCP Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 3 TCP IPv4 pseudoheader [RFC793] Figure 4 TCP IPv4 pseudoheader [RFC793]
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+ + + +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 11, line 27 skipping to change at page 12, line 27
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Upper-Layer Packet Length | | Upper-Layer Packet Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Next Header | | zero | Next Header |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 4 TCP IPv6 pseudoheader [RFC2460] Figure 5 TCP IPv6 pseudoheader [RFC2460]
2. 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
3. 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; we expect that the
MAC algorithm will indicate how to use the key, e.g., as HMACs do in MAC algorithm will indicate how to use the key, e.g., as HMACs do in
general [RFC2104][RFC2403]. general [RFC2104][RFC2403]. The connection key is derived from the
TSAD key entry as described in Sections 6, 7.4, and 7.5.
TCP-AO by default includes the TCP options because these options are By default,TCP-AO includes the TCP options in the MAC calculation
intended to be end-to-end and some are required for proper TCP because these options are intended to be end-to-end and some are
operation (e.g., SACK, timestamp, large windows). Middleboxes that required for proper TCP operation (e.g., SACK, timestamp, large
alter TCP options en-route are a kind of attack and would be windows). Middleboxes that alter TCP options en-route are a kind of
successfully detected by TCP-AO. In cases where the configuration of attack and would be successfully detected by TCP-AO. In cases where
the connection's security association state indicates otherwise, the the configuration of the connection's security association state
TCP options can be excluded from the MAC calculation. When options indicates otherwise, the TCP options can be excluded from the MAC
are excluded, all options - including TCP-AO - are skipped over calculation. When options are excluded, all options - including TCP-
during the MAC calculation (rather than being zeroed). AO - are skipped over during the MAC calculation (rather than being
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 4). Section 6).
MACs typically benefit from a per-connection nonce, notably in 4. Preventing replay attacks within long-lived connections
avoiding the impact of key reuse. The presence of TCP's pair of
Initial Sequence Numbers presents a nonce that may be useful in that
case. Such a nonce could be computed as the concatenation of the ISNs
(initiator, responder), and the socket pair (addresses, ports):
o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r TCP uses a 32-bit sequence number which may, for long-lived
connections, roll over and repeat. This could result in TCP segments
being intentionally and legitimately replayed within a connection.
TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it
adds a 32-bit extended sequence number (ESN) for transmitted and
received segments.
The initial SYN would not know ISN_r, so that packet's nonce would TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN
use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse for received segments, both initialized as zero when a connection
on a per connection basis. begins. The intent of these ESNs is, together with TCP's 32-bit
sequence numbers, to provide a 64-bit overall sequence number space.
>> ISN and socket pair nonces MUST be used to generate unique per- For transmitted segments SND.ESN can be implemented by extending
session keys. TCP's sequence number to 64-bits; SND.ESN would be the top (high-
order) 32 bits of that number. For received segments, TCP-AO needs to
emulate the use of a 64-bit number space, and correctly infer the
appropriate high-order 32-bits of that number as RCV.ESN from the
received 32-bit sequence number and the current connection context.
4. Security Association Management The implementation of ESNs is not specified in this document, but one
possible way is described here that can be used for either RCV.ESN,
SND.ESN, or both.
Consider an implementation with two ESNs as required (SND.ESN,
RCV.ESN), and additional variables as listed below, all initialized
to zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.ESN
o RCV.PREV_SEQ, needed to detect rollover of RCV.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 ROLL, a temporary variable used to simplify the code
When a segment is received, the following algorithm (written in C)
computes the ESN used in the MAC; an equivalent algorithm can be
applied to the "SND" side:
ROLL = (RCV.PREV_SEQ > 0xffff) && (SEG.SEQ < 0xffff);
if ((RCV.ESN_FLAG == 0) && (ROLL)) {
RCV.ESN = RCV.ESN + 1;
RCV.ESN_FLAG = 1;
}
# we've already incremented the RCV.ESN at this point
if (ROLL) {
ESN = RCV.ESN - 1; # use the pre-increment value
} else {
ESN = RCV.ESN; # use the current value
}
RCV.PREV_SEQ = SEG.SEQ;
if (SEG.SEQ > 0xffff) {
RCV.ESN_FLAG = 0;
}
5. Computing connection keys from TSAD entries
TSAD key entries, described in Section 6, are used in conjunction
with a TCP's connection ISNs to generate unique connection keys. This
allows a static TSAD 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.
Given a TSAD key, the TCP socket pair, and the connection ISNs, the
connection key used in the MAC algorithm is computed as follows,
truncated to the same length as the TSAD key, using the same MAC
algorithm as the TSAD key (TALG):
Conn_key = TALG(TSAD_key, connblock)
The connection block (connblock) is defined as follows (IP addresses
are correspondingly longer for IPv6 addresses):
+--------+--------+--------+--------+
| Source IP |
+--------+--------+--------+--------+
| Destination IP |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Destination ISN |
+--------+--------+--------+--------+
Figure 6 Connection block used for connection key generation
"Source" and "destination" are defined by the direction of the
segment being MAC'd; for incoming packets, source is the remote side,
whereas for outgoing packets source is the local side. This further
ensures that keys for each direction are unique.
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
computed using the connection block shown above, in which the
Destination ISN value is zero. For all other segments, the ISN pair
is used when known. If the ISN pair is not known, e.g., when sending
a RST after a reboot, the segment should be sent without
authentication; if authentication was required, the segment cannot
have been MAC'd properly anyway and would have been dropped on
receipt.
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination
ISN of zero (whether sent or received); all other segments use the
known ISN pair.
>> Segments sent in response to connections for which the ISNs are
not known SHOULD NOT use TCP-AO.
Once a connection is established, a connection key would typically be
cached to avoid recomputing it on a per-segment basis. The use of
both ISNs in the connection key computation ensures that segments
cannot be replayed across repeated connections reusing the same
socket pair (provided the ISN pair does not repeat, which is
extremely unlikely).
In general, a SYN would be MAC'd using a destination ISN of zero
(whether sent or received), and all other segments would be MAC'd
using the ISN pair for the connection. There are other cases in which
the destination ISN is not known, but segments are emitted, such as
after an endpoint reboots, when is possible that the two endpoints
would not have enough information to authenticate segments. In such
cases, TCP's timeout mechanism will allow old state to be cleared to
enable new connections, except where the user timeout is disabled; it
is important that implementations are capable of detecting excesses
of TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Je07].
6. Security Association Management
TCP-AO relies on a TCP Security Association Database (TSAD). TSAD TCP-AO relies on a TCP Security Association Database (TSAD). TSAD
entries are assumed to exist at the endpoints where TCP-AO is used, entries are assumed to exist at the endpoints where TCP-AO is used,
in advance of the connection: 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.
>> 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 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 exclusion flag. When 0, this flag allows default a. TCP option flag. When 0, this flag allows default operation,
operation, i.e., TCP options are When 1, all options i.e., TCP options are included in the MAC calculation, with
(including TCP-AO) are excluded from all MAC calculations TCP-AO's MAC field zeroed out. When 1, all options (including
(skipped over, not simply zeroed). TCP-AO) are excluded from all MAC calculations (skipped over,
not simply zeroed).
>> The TCP option exclusion flag MUST default to 0 (i.e., >> The TCP option flag MUST default to 0 (i.e., options not
options not excluded). excluded).
>> The TCP option flag list MUST NOT change during a TCP >> The TCP option flag MUST NOT change during a TCP
connection. connection.
b. An ordered list of zero or more connection key tuples. Each The TCP option flag cannot change during a connection because
tuple is defined as the set <KeyID, MAC type, key length, TCP state is coordinated during connection establishment. TCP
connection key> as follows: lacks a handshake for modifying that state after a connection
has been established.
b. An extended sequence number (ESN). The ESN enables each
segment's MAC calculation to have unique input data, even when
payload data is retransmitted and the TCP sequence number
repeats due to wraparound. The ESN is initialized to zero upon
connection establishment. Its use in the MAC calculation is
described in Section 3.2, and its management is described in
Section 4.
c. An ordered list of zero or more key tuples. Each tuple is
defined as the set <KeyID, MAC type, key length, key> as
follows:
>> TSAD key tuple components MUST NOT change during a >> TSAD key tuple components MUST NOT change during a
connection. connection.
Keeping the tuple components static ensures that the KeyID
uniquely determines the properties of a packet; this supports
use of the KeyID to determine the packet properties.
>> The set of TSAD key tuples MAY change during a connection, >> The set of TSAD key tuples MAY change during a connection,
but KeyIDs of those tuples MUST NOT overlap. I.e., tuple but KeyIDs of those tuples MUST NOT overlap. I.e., tuple
parameter changes MUST be accompanied by key changes. parameter changes MUST be accompanied by key changes.
i. KeyID. A single byte used to differentiate overlapping i. KeyID. A single byte used to differentiate connection
Connection keys. keys in concurrent use.
>> 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 MAY have any value, 0-255 inclusive. >> A KeyID MUST support any value, 0-255 inclusive. There
are no reserved KeyID values.
ii. MAC type. Indicates the MAC used for this connection, as KeyID values are assigned arbitrarily. They can be
per IKEv2 Transform Type 3 [RFC4306]. This includes the assigned in sequence, or based on any method mutually
MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and agreed by the connection endpoints (e.g., using an
the length of the MAC as truncated to (e.g., 96, 128, external key management mechanism).
etc.).
>> KeyIDs MUST NOT be assumed to be randomly assigned.
ii. MAC type. Indicates the MAC used for this connection,
referencing types registered in the IKEv2 Transform Type
3 (Integrity Algorithms) Registry of the IANA established
by [RFC4306]. This includes each MAC algorithm (e.g.,
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 iii. Key length. A byte indicating the length of the key in
connection key in bytes. bytes.
iv. Connection key. A byte sequence used for connection iv. Key. A byte sequence used for generating connection keys,
keying, this may be derived from a separate shared key by this may be derived from a separate shared key by an
an external protocol over a separate channel. This external protocol over a separate channel. This sequence
sequence is used in network standard byte order in MAC is used in network-standard byte order in the key
calculations. generation algorithm described in Section 5.
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 stored in the TCP Control Block (TCB) or in
a separate database (see Section 6.1 for notes on the latter); TSAD a separate database (see Section 8.1 for notes on the latter); TSAD
entries for pending connections (in passive or active OPEN) may be entries for pending connections (in passive or active OPEN) may be
stored in a separate database. This means that in a single host there stored in a separate database. This means that in a single host there
should be only a single database which is consulted by all pending should be only a single 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 set of TCBs.
Multiple databases could be used to support virtual hosts, i.e., Multiple databases could be used to support virtual hosts, i.e.,
groups of interfaces. 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, and can be stored in a separate database if
desired. desired.
5. TCP-AO Interaction with TCP 7. 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 RFC793
[RFC793]. [RFC793].
5.1. User Interface 7.1. 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 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 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 noted in Section 3.2, this is accomplished in TCP-AO by the use of
skipping to change at page 15, line 26 skipping to change at page 20, line 5
>> 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 TSAD entries for TCP connections not in the CLOSED state are deleted
indirectly using the CLOSE or ABORT commands. indirectly using the CLOSE or ABORT commands.
TCP SEND and RECEIVE are not affected by TCP-AO. TCP SEND and RECEIVE are not affected by TCP-AO.
5.2. TCP States and Transitions 7.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.
5.3. TCP Segments 7.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 16, line 25 skipping to change at page 21, line 5
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.
5.4. Sending TCP Segments 7.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 key tuples, omit the TCP-AO
skipping to change at page 17, line 5 skipping to change at page 21, line 30
NONE, omit the TCP-AO option. Proceed with computing the TCP NONE, omit the TCP-AO option. Proceed with computing the TCP
checksum and transmit the segment. 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 key tuple and the outgoing MAC is
not NONE: 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. Compute the MAC using the indexed TSAD entry and data from the b. Determine SND.ESN as described in Section 4.
c. Determine the connection key from the indexed TSAD entry as
described in Section 5.
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 3.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.
c. Insert the MAC in the TCP-AO field. e. Insert the MAC in the TCP-AO field.
d. 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.
5.5. Receiving TCP Segments 7.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 key tuples, proceed with TCP
processing. processing.
skipping to change at page 17, line 37 skipping to change at page 22, line 20
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 key tuple and the incoming MAC is
NONE, proceed with TCP processing. 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 key tuple and the incoming MAC is
not NONE: 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 5.3. and/or signal the event as indicated in Section 7.3.
b. Use the KeyID value to index the appropriate key for this b. Use the KeyID value to index the appropriate key for this
connection. 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. Compute the segment's MAC using the indexed TSAD entry and c. Determine the segment's RCV.ESN as described in Section 4.
d. Determine the segment's connection key from the indexed TSAD
entry as described in Section 5.
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 3.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 5.3. the event as indicated in Section 7.3.
d. 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.
5.6. Impact on TCP Header Size Additional reductions in MAC validation can be supported by using a
MAC algorithm that partitions the MAC field into fixed and computed
portions, where the fixed value is validated before investing in the
computed portion. This optimization would be contained in the MAC
algorithm specification. 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
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). Although TCP option space
is limited, we believe TCP-AO is consistent with the desire to is limited, we believe TCP-AO is consistent with the desire to
authenticate TCP at the connection level for similar uses as were authenticate TCP at the connection level for similar uses as were
intended by TCP MD5. intended by TCP MD5.
6. Key Establishment and Duration Issues 8. 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 rekeying during a connection. We assume out-
of-band mechanisms for key establishment, parameter negotiation, and of-band mechanisms for key establishment, parameter negotiation, and
rekeying. This separation of key use from key management is similar rekeying. This separation of key use from key management is similar
to that in the IPsec security suite [RFC4301][RFC4306]. 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 keys, including the use of reasonable connection key
skipping to change at page 19, line 15 skipping to change at page 24, line 10
Note that TCP-AO's support for rekeying is designed to be minimal in Note that TCP-AO's support for rekeying is designed to be minimal in
the default case. Segments carry only enough context to identify the the default case. Segments carry only enough context to identify the
security association [RFC4301][RFC4306]. In TCP-AO, this context is security association [RFC4301][RFC4306]. In TCP-AO, this context is
provided by the socket pair (IP addresses and ports for source and provided by the socket pair (IP addresses and ports for source and
destination). The TSAD can contain multiple concurrent keys, where destination). The TSAD can contain multiple concurrent keys, where
the KeyID field is used to identify the key that corresponds to a the KeyID field is used to identify the key that corresponds to a
segment, to avoid the need for expensive trial-and-error testing of segment, to avoid the need for expensive trial-and-error testing of
keys in sequence. keys in sequence.
The KeyID field is also useful in coordinating keys for new The KeyID field is also useful in coordinating keys for new
connections. A TSAD may be configured that matches the unbound source connections. A TSAD entry may be configured that matches the unbound
port, which would return a set of possible keys. The KeyID would then source port, which would return a set of possible keys. The KeyID
indicate which key, allowing more efficient connection establishment; would then indicate the specific key, allowing more efficient
otherwise, the keys could have been tried in sequence. See also connection establishment; otherwise, the keys could have been tried
Section 6.1. in sequence. See also Section 8.1.
Implementations are encouraged to keep keys in a suitably private Implementations are encouraged to keep keys in a suitably private
area. Users of TCP-AO are encouraged to use different keys for area.
inbound and outbound MACs on a given TCP connection.
6.1. Implementing the TSAD as an External Database 8.1. Key reuse across socket pairs
Keys can be reused across different socket pairs within a host, or
across different instances of a socket pair within a host. In either
case, replay protection is maintained.
Keys reused across different socket pairs cannot enable replay
attacks because the TCP socket pair is included in the MAC, as well
as in the generation of the connection key. Keys reused across
repeated instances of a given socket pair cannot enable replay
attacks because the connection ISNs are included in the connection
key generation algorithm, and ISN pairs are unlikely to repeat over
useful periods.
Keys should not be shared across different hosts, because this could
compromise the keying material itself.
8.2. Key use within a long-lived connection
TCP-AO uses extended sequence numbers (ESNs) to prevent replay
attacks within long-lived connections. Key rollover can be used to
change keying material for various reasons (e.g., personnel
turnover), but is not required to support long-lived connections.
8.3. Implementing the TSAD as an External Database
The TSAD implementation is considered external to TCP-AO. When an The TSAD implementation is considered external to TCP-AO. When an
external database is used, it would be useful to consider the external database is used, it would be useful to consider the
interface between TCP-AO and the TSAD. The following is largely a interface between TCP-AO and the TSAD. The following is largely a
restatement of information in Section 4. restatement of information in Section 6.
The TSAD API is accessed during a connection as follows: The TSAD API is accessed during a connection as follows:
o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP o TCP connection identifier (ID) (The socket pair, sent as 4 byte IP
source address, 4 byte IP destination address, 2 byte TCP source source address, 4 byte IP destination address, 2 byte TCP source
port, 2 byte TCP destination port). port, 2 byte TCP destination port).
o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 = o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 =
outbound) outbound)
o Number of bytes to be sent/received (two bytes); this is used on 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 the send side to trigger bytecount-based KeyID changes, and on the
receive side only for statistics or length-sensitive KeyID receive side only for statistics or length-sensitive KeyID
selection. selection.
>> TCP-AO implementations SHOULD change keys for a connection at
least every 2^31 bytes, to avoid resending segments with the same
TCP sequence number, data, and length under the same key.
o KeyID (single byte); this is provided only by a receiver (i.e., o KeyID (single byte); this is provided only by a receiver (i.e.,
matching the KeyID of the received segment), where a sender would matching the KeyID of the received segment), where a sender would
leave this unspecified (and the call would return the appropriate leave this unspecified (and the call would return the appropriate
KeyID to use). KeyID to use).
The call passes the number of bytes sent/received, and an indication The call passes the number of bytes sent/received, and an indication
of the direction (send/receive), to enable traffic-based key of the direction (send/receive), to enable traffic-based key
rollover. rollover.
The source port can be 'unbound', indicated by the value 0x0000. In The source port can be 'unbound', indicated by the value 0x0000. In
this case, the source port is considered a wildcard, and all this case, the source port is considered a wildcard, and all
corresponding TSAD entries (indexed by the KeyID) are returned as a corresponding TSAD entries (indexed by the KeyID) are returned as a
list. This feature is used during connection establishment. list. This feature is used during connection establishment.
TSAD calls return the following parameters: TSAD calls return the following parameters:
o TCP option exclusion flag (one byte, with 0x00 having the meaning o TCP option exclusion flag (one byte, with 0x00 having the meaning
"exclude none" and 0x01 meaning "exclude all"). "exclude none" and 0x01 meaning "exclude all").
o An ordered list of zero or more connection key tuples: o An ordered list of zero or more connection key tuples:
<KeyID, MAC type, MAC length, connection key> <KeyID, MAC type, MAC length, key length, key>
o KeyID (one byte) o KeyID (one byte)
o MAC type (four bytes, an IKEv2 Transform Type 3 ID [RFC4306]) o MAC type (four bytes, an IKEv2 Transform Type 3 ID [RFC4306])
o MAC length (one byte)
o Key length (one byte) o Key length (one byte)
o Connection key (byte sequence, indicating the key value) o Key (byte sequence, indicating the key value)
When the TSAD returns zero keys, it is indicating that there are no When the TSAD returns zero keys, it is indicating that there are no
currently valid keys for the connection. currently valid keys for the connection.
7. Interactions with TCP MD5 9. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO is intended to be deployed without regard for existing TCP MD5 TCP-AO obsoletes TCP MD5. As we have noted earlier:
option support.
>> TCP implementations MUST support TCP-AO.
Systems implementing TCP MD5 only are considered legacy, and ought to
be upgraded when possible. In order to support interoperation with
such legacy systems until upgrades are available:
>> TCP MD5 SHOULD be supported where interactions with legacy systems
is needed.
>> A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for
connections unless not supported by its peer, at which point it MAY
use TCP MD5 instead.
>> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a
particular TCP connection, but MAY support TCP-AO and TCP MD5 particular TCP connection, but MAY support TCP-AO and TCP MD5
simultaneously for different connections. simultaneously for different connections (notably to support legacy
use of TCP MD5).
The Kind value explicitly indicates which of TCP-AO or TCP MD5 is The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used
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'. Note that when TCP MD5 is
required on for a connection, it must be used [RFC2385]. This required on for a connection, it must be used [RFC2385]. This
prevents combined use of the two options for a given connection, to prevents combined use of the two options for a given connection, to
be determined by the other end of the connection. be determined by the other end of the connection.
8. Interactions with NAT/NAPT Devices 10. Interactions with non-NAT/NAPT Middleboxes
TCP-AO can interoperate across NAT/NAPT devices, which modify the IP TCP-AO supports middleboxes that do not change the IP addresses or
addresses, and may also modify TCP port numbers and/or TCP options. ports of segments. Such middleboxes may modify some TCP options, in
TCP options can be excluded on a per-connection basis. which case TCP-AO would need to be configured to ignore all options
in the MAC calculation on connections traversing that element.
IP addresses and port numbers would preferably be coordinated across Note that ignoring TCP options may provide less protection, i.e., TCP
a NAT/NAPT device, such that the sender and receiver both know the IP options could be modified in transit, and such modifications could be
address and TCP port numbers of the received packet. In that case, used by an attacker. Depending on the modifications, TCP could have
the sender computes the packet as it would be received, i.e., using compromised efficiency (e.g., timestamp changes), or could cease
the receiver's version of the IP pseudoheader and TCP header. correct operation (e.g., window scale changes). These vulnerabilities
affect only the TCP connections for which TCP-AO is configured to
ignore TCP options.
Where such knowledge of the address and port translations are not 11. Interactions with NAT/NAPT Devices
known, NAT/NAPT traversal can be handled in similar ways to IPsec
[RFC2766][RFC3947]. I.e., traversing such a device using a tunnel to
avoid the NAT/NAPT from translating fields in the TCP and IP headers
TCP-AO uses in its MAC calculation. Such a tunnel may need to
coincide with the channel over which keys are exchanged, as in IPsec
NAT traversal [RFC3947].
9. Evaluation of Requirements Satisfaction TCP-AO cannot interoperate natively across NAT/NAPT devices, which
modify the IP addresses and/or port numbers. We anticipate that
traversing such devices will require variants of existing NAT/NAPT
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
segment in another transport segment (e.g., UDP), as is done in IPsec
[RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO,
or IPsec NAT traversal can be used instead in such cases [RFC3947].
12. Evaluation of Requirements Satisfaction
TCP-AO satisfies all the current requirements for a revision to TCP TCP-AO satisfies all the current requirements for a revision to TCP
MD5, as indicated in [Be07] and under current developemt. This should MD5, as indicated in [Be07] and under current development. This
not be a surprise, as the majority of the evolving requirements are should not be a surprise, as the majority of the evolving
derived from its design. The following is a summary of those requirements are derived from its design. The following is a summary
requirements and notes where relevant. of those requirements and notes where relevant.
1. Protected Elements - see Section 3.2. 1. Protected Elements - see Section 3.2.
a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that a. TCP pseudoheader, including IPv4 and IPv6 versions. Note that
we do not allow optional coverage because IP addresses define we do not allow optional coverage because IP addresses define
a connection. If they can be coordinated across a NAT/NAPT, a connection. If they can be coordinated across a NAT/NAPT,
the sender can compute the MAC based on the received values; the sender can compute the MAC based on the received values;
if not, a tunnel is required. if not, a tunnel is required.
b. TCP header. Note that we do not allow optional port coverage b. TCP header. Note that we do not allow optional port coverage
skipping to change at page 22, line 18 skipping to change at page 28, line 5
d. TCP data. Done. d. TCP data. Done.
2. Option structure requirements 2. Option structure requirements
a. Privacy. TCP-AO exposes only the key index, MAC, and overall a. Privacy. TCP-AO exposes only the key index, MAC, and overall
option length. Note that short MACs could be obscured by using option length. Note that short MACs could be obscured by using
longer option lengths but specifying a short MAC length (this longer option lengths but specifying a short MAC length (this
is equivalent to a different MAC algorithm, and is specified is equivalent to a different MAC algorithm, and is specified
in the TSAD entry). See Section 3.2. in the TSAD entry). See Section 3.2.
b. Allow optional per connection. Done - see Sections 5.3, 5.4, b. Allow optional per connection. Done - see Sections 7.3, 7.4,
and 5.5. and 7.5.
c. Require non-optional. Done - see Sections 5.3, 5.4, and 5.5. c. Require non-optional. Done - see Sections 7.3, 7.4, and 7.5.
d. Standard parsing. Done - see Section 3.2. d. Standard parsing. Done - see Section 3.2.
e. Compatible with Large Windows. Done - see Section 3.2. The e. Compatible with Large Windows. Done - see Section 3.2. The
size of the option is intended to allow use with Large Windows 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 and SACK. See also Section 1.1, which indicates that TCP-AO is
4 bytes shorter than TCP MD5 in the default case, assuming a 3 bytes shorter than TCP MD5 in the default case, assuming a
96-bit MAC. 96-bit MAC.
f. Compatible with SACK. Done - see Section 3.2. The size of the f. Compatible with SACK. Done - see Section 3.2. The size of the
option is intended to allow use with Large Windows and SACK. option is intended to allow use with Large Windows and SACK.
See also Section 6 regarding key management. See also Section See also Section 8 regarding key management. See also Section
1.1, which indicates that TCP-AO is 4 bytes shorter than TCP 1.1, which indicates that TCP-AO is 3 bytes shorter than TCP
MD5 in the default case. MD5 in the default case.
3. Cryptography requirements 3. Cryptography requirements
a. Baseline defaults. TCP-AO uses TBD-WG-MACS as the default, as a. Baseline defaults. TCP-AO uses TBD-WG-MACS as the default, as
noted in Section 3.2. noted in Section 3.2.
b. Good algorithms. TCP-AO uses TBD-WG-MACS as the default, but b. Good algorithms. TCP-AO uses TBD-WG-MACS as the default, but
does not otherwise specify the algorithms used. That would be does not otherwise specify the algorithms used. That would be
specified in the key management protocol, and should be specified in the key management protocol, and should be
limited there. limited there.
c. Algorithm agility. TCP-AO allows any desired algorithm, c. Algorithm agility. TCP-AO allows any desired algorithm,
subject to TCP option space limitations, as noted in Section subject to TCP option space limitations, as noted in Section
3.2. The TSAD allows separate connections to use different 3.2. The TSAD allows separate connections to use different
algorithms. algorithms.
d. Pre-TCP processing. Done - see Sections 5.3, 5.4, and 5.5. d. Pre-TCP processing. Done - see Sections 7.3, 7.4, and 7.5.
Note that pre-TCP processing is required, because TCP segments Note that pre-TCP processing is 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].
e. Parameter changes require key changes. TSAD parameters that e. Parameter changes require key changes. TSAD parameters that
should not change during a connection (TCP connection ID, should not change during a connection (TCP connection ID,
receiver TCP connection ID, TCP option exclusion list) cannot receiver TCP connection ID, TCP option exclusion list) cannot
change. Other parameters change only when a key is changed, change. Other parameters change only when a key is changed,
using the key tuple mechanism in the TSAD. See Section 4. using the key tuple mechanism in the TSAD. See Section 6.
4. Keying requirements. TCP-AO does not specify a key management 4. Keying requirements. TCP-AO does not specify a key management
system, but does indicate a proposed interface to the TSAD, system, but does indicate a proposed interface to the TSAD,
allowing a completely separate key system. allowing a completely separate key system.
a. Intraconnection rekeying. Supported by the KeyID and multiple a. Intraconnection rekeying. Supported by the KeyID and multiple
key tuples in a TSAD entry; see Section 4. key tuples in a TSAD entry; see Section 6.
b. Efficient rekeying. Supported by the KeyID. See Section 6. b. Efficient rekeying. Supported by the KeyID. See Section 8.
c. Automated and manual keying. Supported by the TSAD interface. c. Automated and manual keying. Supported by the TSAD interface.
See Section 6. See Section 8. Enhanced by the generation of unique per-
connection keys as noted in Section 5.
d. Key management agnostic. Supported by the TSAD interface. See d. Key management agnostic. Supported by the TSAD interface. See
Section 6.1. Section 8.1.
5. Expected constraints 5. Expected constraints
a. Silent failure. Done - see Sections 5.3, 5.4, and 5.5. a. Silent failure. Done - see Sections 7.3, 7.4, and 7.5.
b. At most one such option per segment. Done - see Section 3.2. b. At most one such option per segment. Done - see Section 3.2.
c. Outgoing all or none. Done - see Section 5.4. c. Outgoing all or none. Done - see Section 7.4.
d. Incoming all checked. Done - see Section 5.5. d. Incoming all checked. Done - see Section 7.5.
e. Non-interaction with TCP MD5. Done - see Section 7. e. Non-interaction with TCP MD5. Done - see Section 9.
f. Optional ICMP discard. Done - see Section 10. f. Optional ICMP discard. Done - see Section 13.
g. Allows use of NAT/NAPT devices. Done - see Section 8. g. Allows use of NAT/NAPT devices. Done - see Section 10.
h. Maintain TCP connection semantics, in which only the socket h. Maintain TCP connection semantics, in which the socket pair
pair defines a TCP association and all its security alone defines a TCP association and all its security
parameters. Done - see Sections 4 and 8. parameters. Done - see Sections 6 and 10.
i. Try to avoid creating a CPU DOS attack opportunity. Done - see i. Try to avoid creating a CPU DOS attack opportunity. Done - see
Section 10. Section 13.
10. 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
(32 bits) is arbitrary, whereas for routing protocols typically only (32 bits) is arbitrary, whereas for routing protocols typically only
the source port (16 bits) is arbitrary. As a result, it would be the source port (16 bits) is arbitrary. As a result, it would be
skipping to change at page 24, line 30 skipping to change at page 30, line 18
cause receiver validation effort. However, we note that between cause receiver validation effort. However, we note that between
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. outs, rather than more responsive recovery after such a crash. As
noted in Section 5, such cases may also result in persistent TCP
state for old connections that cannot be cleared, and so
implementations should be capable of detecting an excess of such
connections and clearing their state if needed to protect memory
utilization [Je07].
TCP-AO does not include a fast decline capability, e.g., where a SYN- 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.
skipping to change at page 25, line 16 skipping to change at page 31, line 11
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- Codes 2-4 intended for connections that match TSAD entries with non-
NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be
logged. 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. This recommendation is intended
to be similar to how IPsec would handle those messages [RFC4301]. 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 in the MAC calculation. This
prevents connections using the same key (for whatever reason) from prevents connections using the same key (for whatever reason) from
potentially enabling a traffic-crossing attack, in which segments to potentially enabling a traffic-crossing attack, in which segments to
one socket pair are diverted to attack a different socket pair. When one socket pair are diverted to attack a different socket pair. When
multiple connections use the same key, it would be useful to know multiple connections use the same key, it would be useful to know
that packets intended for one ID could not be (maliciously or that packets intended for one ID could not be (maliciously or
otherwise) modified in transit and end up being authenticated for the otherwise) modified in transit and end up being authenticated for the
skipping to change at page 25, line 44 skipping to change at page 31, line 39
management system. 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 due to TCP's Sequence Number, which is used to attacks, isn't needed in all cases due to TCP's Sequence Number,
reorder received segments. Unfortunately, it is not useful to which is used to reorder received segments. TCP already protects
validate TCP's Sequence Number before performing a TCP-AO itself from replays of authentic segment data as well as authentic
authentication calculation, because out-of-window segments can still explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic
cause TCP protocol actions (e.g., ACK retransmission) [RFC793]. It is replays could affect TCP congestion control [Sa99]. TCP-AO does not
similarly not useful to add a separate Sequence Number field to the protect TCP congestion control from such attacks due to the
TCP-AO option, because doing so could cause a change in TCP's cumbersome nature of layering a windowed security sequence number
behavior even when segments are valid. within TCP in addition to TCP's own sequence number; when such
protection is desired, users are encouraged to apply IPsec instead.
11. IANA Considerations Further, it is not useful to validate TCP's Sequence Number before
performing a TCP-AO authentication calculation, because out-of-window
segments can still cause valid TCP protocol actions (e.g., ACK
retransmission) [RFC793]. It is similarly not useful to add a
separate Sequence Number field to the TCP-AO option, because doing so
could cause a change in TCP's behavior even when segments are valid.
14. IANA Considerations
The TCP-AO option defines no new namespaces. The TCP-AO option defines no new namespaces.
The TCP-AO option uses the TCP option Kind value TCP-IANA-KIND, The TCP-AO option uses the TCP option Kind value TCP-IANA-KIND,
allocated by IANA from the TCP option Kind namespace. allocated by IANA from the TCP option Kind namespace.
To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2 To specify MAC algorithms, TCP-AO uses the 4-byte namespace of IKEv2
Transform Type 3 IDs [RFC4306]. 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] [NOTE: The following to be removed prior to publication as an RFC]
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.
12. Acknowledgments 15. Acknowledgments
This document was inspired by the revisions to TCP MD5 suggested by This document was inspired by the revisions to TCP MD5 suggested by
Brian Weis and Ron Bonica [Bo07][We05]. Russ Housley suggested Brian Weis and Ron Bonica [Bo07][We05][We07]. Russ Housley suggested
L4/application layer management of the TSAD. The KeyID field was L4/application layer management of the TSAD. The KeyID field was
motivated by Steve Bellovin. Eric Rescorla suggested the use of ISNs motivated by Steve Bellovin. Eric Rescorla suggested the use of ISNs
as nonces, and Brian Weis extended the nonce to incorporate the in the connection key computation and ESNs to avoid replay attacks,
entire connection ID. Alfred Hoenes, Charlie Kaufman, and Adam and Brian Weis extended the computation to incorporate the entire
Langley provided substantial feedback. The document is the result of 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). collaboration with the TCP Authentication Design team (tcp-auth-dt).
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
13. References 16. References
13.1. Normative References 16.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol," STD 007, RFC [RFC793] Postel, J., "Transmission Control Protocol," STD 007, RFC
793, Standard, Sept. 1981. 793, Standard, Sept. 1981.
[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
skipping to change at page 27, line 20 skipping to change at page 33, line 27
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," RFC
4306, Proposed Standard, Dec. 2005. 4306, Proposed Standard, Dec. 2005.
13.2. Informative References 16.2. Informative References
[Be05] Bellovin, S., E. Rescorla, "Deploying a New Hash
Algorithm," presented at the First NIST Cryptographic Hash
Workshop, Oct. 2005.
http://csrc.nist.gov/pki/HashWorkshop/2005/program.htm
[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.
[Bu06] Burr, B., "NIST Cryptographic Standards Status Report,"
Invited talk at Internet 2 5th Annual PKI R&D Workshop,
April 2006.
http://middleware.internet2.edu/pki06/proceedings/
[Bo07] Bonica, R., et. al, "Authentication for TCP-based Routing [Bo07] Bonica, R., et. al, "Authentication for TCP-based Routing
and Management Protocols," draft-bonica-tcp-auth-06 , and Management Protocols," draft-bonica-tcp-auth-06, (work
(work in progress), Feb. 2007. 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-03, (work in progress), Mar. 2008. attacks-04, (work in progress), Oct. 2008.
[Je07] Jethanandani, M., and M. Bashyam, "TCP Robustness in
Persist Condition," draft-mahesh-persist-timeout-02, (work
in progress), Oct. 2007.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. Informational, April 1992.
[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
skipping to change at page 28, line 25 skipping to change at page 34, line 25
[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," RFC
4808, Informational, Mar. 2007. 4808, Informational, Mar. 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks," [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks,"
RFC4953, Jul. 2007. RFC4953, Jul. 2007.
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver," ACM
Computer Communications Review, V29, N5, pp71-78, October
1999.
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)," [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
Option," draft-touch-tcpm-tcp-simple-auth-03, (expired work
in progress), Oct. 2006.
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash
functions," Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[We05] Weis, B., "TCP Message Authentication Code Option," draft- [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 [We07] Weis, B., et al., "Automated key selection extension for
the TCP Authentication Option," draft-weis-tcp-auth-auto- the TCP Authentication Option," draft-weis-tcp-auth-auto-
ks-03, (work in progress), Oct. 2007. ks-03, (work in progress), Oct. 2007.
Author's Addresses Author's Addresses
skipping to change at page 29, line 4 skipping to change at page 35, line 16
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
Allison Mankin Allison Mankin
Johns Hopkins Univ.
Washington, DC Washington, DC
U.S.A. U.S.A.
Phone: 1 301 728 7199 Phone: 1 301 728 7199
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
 End of changes. 168 change blocks. 
356 lines changed or deleted 647 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/