draft-ietf-tcpm-tcp-auth-opt-05.txt   draft-ietf-tcpm-tcp-auth-opt-06.txt 
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: January 2010 R. Bonica Expires: April 2010 R. Bonica
Juniper Networks Juniper Networks
July 3, 2009 October 26, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-05.txt draft-ietf-tcpm-tcp-auth-opt-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 3, 2010. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract Abstract
This document specifies the TCP Authentication Option (TCP-AO), which This document specifies the TCP Authentication Option (TCP-AO), which
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
specifies the use of stronger Message Authentication Codes (MACs), specifies the use of stronger Message Authentication Codes (MACs),
protects against replays even for long-lived TCP connections, and protects against replays even for long-lived TCP connections, and
provides more details on the association of security with TCP provides more details on the association of security with TCP
connections than TCP MD5. TCP-AO is compatible with either static connections than TCP MD5. TCP-AO is compatible with either static
master key tuple (MKT) configuration or an external, out-of-band MKT master key tuple (MKT) configuration or an external, out-of-band MKT
skipping to change at page 2, line 29 skipping to change at page 2, line 32
connections (as used, e.g., in BGP and LDP), and to support a larger connections (as used, e.g., in BGP and LDP), and to support a larger
set of MACs with minimal other system and operational changes. TCP-AO set of MACs with minimal other system and operational changes. TCP-AO
uses its own option identifier, even though used mutually exclusive uses its own option identifier, even though used mutually exclusive
of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is
fully compatible with the requirements for the replacement of TCP fully compatible with the requirements for the replacement of TCP
MD5. MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................3 2. Introduction...................................................4
2.1. Executive Summary.........................................4 2.1. Executive Summary.........................................4
2.2. Changes from Previous Versions............................6 2.2. Changes from Previous Version.............................6
2.2.1. New in draft-ietf-tcp-auth-opt-05....................6 2.2.1. New in draft-ietf-tcp-auth-opt-06....................6
3. Conventions used in this document..............................7 3. Conventions used in this document..............................6
4. The TCP Authentication Option..................................7 4. The TCP Authentication Option..................................7
4.1. Review of TCP MD5 Option..................................8 4.1. Review of TCP MD5 Option..................................7
4.2. The TCP-AO Option.........................................8 4.2. The TCP-AO Option.........................................8
5. TCP-AO Keys and Their Properties..............................10 5. TCP-AO Keys and Their Properties..............................10
5.1. Master Key Tuple.........................................10 5.1. Master Key Tuple.........................................10
5.2. Traffic Keys.............................................12 5.2. Traffic Keys.............................................12
5.3. MKT Properties...........................................13 5.3. MKT Properties...........................................13
6. Per-Connection TCP-AO Parameters..............................14 6. Per-Connection TCP-AO Parameters..............................14
7. Cryptographic Algorithms......................................15 7. Cryptographic Algorithms......................................15
7.1. MAC Algorithms...........................................15 7.1. MAC Algorithms...........................................15
7.2. Key Derivation Functions.................................18 7.2. Key Derivation Functions.................................18
7.3. Traffic Key Establishment and Duration Issues............22 7.3. Traffic Key Establishment and Duration Issues............22
7.3.1. MKT Reuse Across Socket Pairs.......................22 7.3.1. MKT Reuse Across Socket Pairs.......................22
7.3.2. MKTs Use Within a Long-lived Connection.............23 7.3.2. MKTs Use Within a Long-lived Connection.............23
8. Additional Security Mechanisms................................23 8. Additional Security Mechanisms................................23
8.1. Coordinating MKT Changes.................................23 8.1. Coordinating Use of New MKTs.............................23
8.2. Preventing replay attacks within long-lived connections..24 8.2. Preventing replay attacks within long-lived connections..24
9. TCP-AO Interaction with TCP...................................26 9. TCP-AO Interaction with TCP...................................26
9.1. TCP User Interface.......................................27 9.1. TCP User Interface.......................................27
9.2. TCP States and Transitions...............................28 9.2. TCP States and Transitions...............................28
9.3. TCP Segments.............................................28 9.3. TCP Segments.............................................28
9.4. Sending TCP Segments.....................................28 9.4. Sending TCP Segments.....................................29
9.5. Receiving TCP Segments...................................30 9.5. Receiving TCP Segments...................................30
9.6. Impact on TCP Header Size................................32 9.6. Impact on TCP Header Size................................32
10. Obsoleting TCP MD5 and Legacy Interactions...................33 10. Obsoleting TCP MD5 and Legacy Interactions...................33
11. Interactions with Middleboxes................................33 11. Interactions with Middleboxes................................33
11.1. Interactions with non-NAT/NAPT Middleboxes..............34 11.1. Interactions with non-NAT/NAPT Middleboxes..............34
11.2. Interactions with NAT/NAPT Devices......................34 11.2. Interactions with NAT/NAPT Devices......................34
12. Evaluation of Requirements Satisfaction......................34 12. Evaluation of Requirements Satisfaction......................34
13. Security Considerations......................................40 13. Security Considerations......................................40
14. IANA Considerations..........................................42 14. IANA Considerations..........................................42
15. References...................................................43 15. References...................................................43
skipping to change at page 6, line 9 skipping to change at page 6, line 15
o TCP-AO forces a change of computed MACs when a connection o TCP-AO forces a change of computed MACs when a connection
restarts, even when reusing a TCP socket pair (IP addresses and restarts, even when reusing a TCP socket pair (IP addresses and
port numbers) [Be07]. port numbers) [Be07].
o TCP-AO does not support encryption. o TCP-AO does not support encryption.
o TCP-AO does not authenticate ICMP messages (some ICMP messages may o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated when using IPsec, depending on the be authenticated when using IPsec, depending on the
configuration). configuration).
2.2. Changes from Previous Versions 2.2. Changes from Previous Version
[NOTE: to be omitted upon final publication as RFC]
2.2.1. New in draft-ietf-tcp-auth-opt-05
o Summary of changes:
o Remove TSAD; replace with discussion of MKTs directly.
o Change most references of IDs to refer to MKTs directly.
o Update and minimize interface to [crypto-ao].
o Removed "what's new" going back more than one version (full
changelist available from the authors)
o Issue tracker responses (http://tools.ietf.org/wg/tcpm/):
o 1 Confusion between master & traffic keys, and key-ids. Done.
o 2 Clarify relationship between master and traffic keys - use
diagram given. Done.
o 3 TSAD concept - Removed.
o 4 Option flag description - Removed 0/1 values.
o 5 TAPD details - TAPD removed.
o 6 KeyId versus master key - Current_key now points to a MKT,
not an ID.
o 7 ESN versus SNE - Used "sequence number extension" rather
than "extended sequence number".
o 8 "typically" in traffic key storage - Replaced with 'can be'.
o 9 MAC truncation & padding - Removed / refers only to existing
components of [crypto-ao].
o 10 SYN traffic keys - explain directionality and that typically
only one is needed. Done.
o 11 Master key for LISTEN - (TAPD issue) Removed with TAPD [NOTE: to be omitted upon final publication as RFC; full changelist
removal. available from the authors]
o 15 Text clarifying traffic keys (related to issues 1,2) - 2.2.1. New in draft-ietf-tcp-auth-opt-06
Done in Section 5.2.
o 16 Text for key coordination - Not inserted, since based on o Items from Stockholm IETF meeting
behavior that was decided against in the WG meeting (e.g.,
that installing keys makes them preferred, that 2MSL forces
keys out of use altogether, and that endpoints sync key
changes).
o Items from SFO IETF meeting o Unify MAC and PRF function notation with ao-crypto.
o 1. TCP-AO key coordination allows 'backup' o Clarify that options are not included in TCP's advertised MSS.
o 2. Clarify names for key entities (issues 1,2) o Clarify that segments not matching MKTs should be silently
accepted. See Section 9.5 for details.
o 3. Address the timers (part of bugtrack item 5) o Clarify that MKTs can be used to derive 4 traffic keys, not
that all are always actually derived.
o 4. Move TAPD to the appendix (issues 3, 5) - removed. o Emphasize that the KeyIDs MAY be the same in both directions.
o Other issues raised on the list: o Change nextkeyID to rnextkeyID, to clarify that it refers to
the KeyID in the opposite (receive) direction. Updated
descriptions of the header fields in Section 4.2 to clarify
this issue.
o ICMP handling - already does as IPsec does. No changes made. o Clarified that the key coordination mechanism is for
performance enhancement on when to start using a new MKT, but
that when to stop using an MKT would be a key management
protocol issue. Removed previous timers used as hints.
3. Conventions used in this document 3. 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.
In this document, the characters ">>" proceeding an indented line(s) In this document, the characters ">>" proceeding an indented line(s)
indicates a compliance requirement statement using the key words indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying listed above. This convention aids reviewers in quickly identifying
or finding this RFC's explicit compliance requirements. or finding the explicit compliance requirements of this RFC.
4. The TCP Authentication Option 4. The TCP Authentication Option
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value The TCP Authentication Option (TCP-AO) uses a TCP option Kind value
of TBD-IANA-KIND. of TBD-IANA-KIND.
4.1. Review of TCP MD5 Option 4.1. Review of TCP MD5 Option
For review, the TCP MD5 option is shown in Figure 1. For review, the TCP MD5 option is shown in Figure 1.
skipping to change at page 8, line 44 skipping to change at page 8, line 10
3. The TCP data payload. 3. The TCP data payload.
4. A key. 4. A key.
4.2. The TCP-AO Option 4.2. The TCP-AO Option
The new TCP-AO option provides a superset of the capabilities of TCP The new TCP-AO option provides a superset of the capabilities of TCP
MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
Kind field, and similar Length field to TCP MD5, a KeyID field, and a Kind field, and similar Length field to TCP MD5, a KeyID field, and a
NextKeyID field as shown in Figure 2. RNextKeyID field as shown in Figure 2.
+-----------+-----------+-----------+-----------+ +------------+------------+------------+------------+
| Kind | Length | KeyID | NextKeyID | | Kind | Length | KeyID | RNextKeyID |
+-----------+-----------+-----------+-----------+ +------------+------------+------------+------------+
| MAC ... | MAC ...
+-----------------------------------... +-----------------------------------...
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP-AO Option Figure 2 The TCP-AO Option
The TCP-AO defines the following fields: The TCP-AO defines the following fields:
o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP-
AO uses a new Kind value of TBD-IANA-KIND. AO uses a new Kind value of TBD-IANA-KIND.
>> An endpoint MUST NOT use TCP-AO for the same connection in >> An endpoint MUST NOT use TCP-AO for the same connection in
which TCP MD5 is used. which TCP MD5 is used.
>> A single TCP segment MUST NOT have more than one TCP-AO option. >> A single TCP segment MUST NOT have more than one TCP-AO option.
o Length: An unsigned 1-byte field indicating the length of the TCP- o Length: An unsigned 1-byte field indicating the length of the TCP-
AO option in bytes, including the Kind, Length, KeyID, NextKeyID, AO option in bytes, including the Kind, Length, KeyID, RNextKeyID,
and MAC fields. and MAC fields.
>> The Length value MUST be greater than or equal to 4. >> The Length value MUST be greater than or equal to 4.
>> 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 avoids overrun/underrun abuse. this is a consistency check and avoids overrun/underrun abuse.
Values of 4 and other small values larger than 4 (e.g., indicating Values of 4 and other small values larger than 4 (e.g., indicating
MACs of very short length) are of dubious utility but are not MAC fields of very short length) are of dubious utility but are
specifically prohibited. not specifically prohibited.
o KeyID: An unsigned 1-byte field used to support efficient key o KeyID: An unsigned 1-byte field indicating the MKT used to
changes during a connection and/or to help with key coordination generate the traffic keys which were used to generate the MAC that
during connection establishment, to be discussed further in authenticates this segment.
Section 8.1. Note that the KeyID has no cryptographic properties -
it need not be random, nor are there any reserved values.
o NextKeyID: An unsigned 1-byte field used to support efficient key It supports efficient key changes during a connection and/or to
change coordination, to be discussed further in Section 8.1. Note help with key coordination during connection establishment, to be
that the NextKeyID has no cryptographic properties - it need not discussed further in Section 8.1. Note that the KeyID has no
be random, nor are there any reserved values. cryptographic properties - it need not be random, nor are there
any reserved values.
>> KeyID values MAY be the same in both directions of a
connection, but do not have to be and there is no special meaning
when they are.
o RNextKeyID: An unsigned 1-byte field indicating the MKT that the
sender is ready use to receive authenticated packets, i.e., the
desired 'receive next' keyID.
It supports efficient key change coordination, to be discussed
further in Section 8.1. Note that the RNextKeyID has no
cryptographic properties - it need not be random, nor are there
any reserved values.
o MAC: Message Authentication Code. Its contents are determined by o MAC: Message Authentication Code. Its contents are determined by
the particulars of the security association. Typical MACs are 96- the particulars of the security association. Typical MACs are 96-
128 bits (12-16 bytes), but any length that fits in the header of 128 bits (12-16 bytes), but any length that fits in the header of
the segment being authenticated is allowed. The MAC computation is the segment being authenticated is allowed. The MAC computation is
described further in Section 7.1. described further in Section 7.1.
>> Required support for TCP-AO MACs as defined in [ao-crypto]; >> Required support for TCP-AO MACs as defined in [ao-crypto];
other MACs MAY be supported. other MACs MAY be supported.
The TCP-AO option fields do not indicate the MAC algorithm either The TCP-AO option fields do 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 and is managed separately (see Section 5). connection's security and is managed separately (see Section 5).
Please note that the use of TCP-AO does not affect TCP's advertised
maximum segment size (MSS), as is the case for all TCP options
[Bo09].
The remainder of this document explains how the TCP-AO option is The remainder of this document explains how the TCP-AO option is
handled and its relationship to TCP. handled and its relationship to TCP.
5. TCP-AO Keys and Their Properties 5. TCP-AO Keys and Their Properties
TCP-AO relies on a two sets of keys to authenticate incoming and TCP-AO relies on two sets of keys to authenticate incoming and
outgoing segments: master key tuples (MKTs) and traffic keys. MKTs outgoing segments: master key tuples (MKTs) and traffic keys. MKTs
are used to derive unique traffic keys, and include the keying are used to derive unique traffic keys, and include the keying
material used to generate those traffic keys, as well as indicating material used to generate those traffic keys, as well as indicating
the associated parameters under which traffic keys are used. Such the associated parameters under which traffic keys are used. Such
parameters include whether TCP options are authenticated, and parameters include whether TCP options are authenticated, and
indicators of the algorithms used for traffic key derivation and MAC indicators of the algorithms used for traffic key derivation and MAC
calculation. Traffic keys are the keying material used to compute the calculation. Traffic keys are the keying material used to compute the
MAC of individual TCP segments. MAC of individual TCP segments.
5.1. Master Key Tuple 5.1. Master Key Tuple
skipping to change at page 11, line 14 skipping to change at page 10, line 37
o TCP option flag. This flag indicates whether TCP options other o TCP option flag. This flag indicates whether TCP options other
than TCP-AO are included in the MAC calculation. When options are than TCP-AO are included in the MAC calculation. When options are
included, the content of all options, in the order present, are included, the content of all options, in the order present, are
included in the MAC, with TCP-AO's MAC field zeroed out. When the included in the MAC, with TCP-AO's MAC field zeroed out. When the
options are not included, all options other than TCP-AO are options are not included, all options other than TCP-AO are
excluded from all MAC calculations (skipped over, not zeroed). excluded from all MAC calculations (skipped over, not zeroed).
Note that TCP-AO, with its MAC field zeroed out, is always Note that TCP-AO, with its MAC field zeroed out, is always
included in the MAC calculation, regardless of the setting of this included in the MAC calculation, regardless of the setting of this
flag; this protects the indication of the MAC length as well as flag; this protects the indication of the MAC length as well as
the key ID fields (KeyID, NextKeyID). The option flag applies to the key ID fields (KeyID, RNextKeyID). The option flag applies to
TCP options in both directions (incoming and outgoing segments). TCP options in both directions (incoming and outgoing segments).
o IDs. The values used in the KeyID or NextKeyID of a TCP-AO option; o IDs. The values used in the KeyID or RNextKeyID of a TCP-AO
used to differentiate MKTs in concurrent use, as well as to option; used to differentiate MKTs in concurrent use, as well as
indicate when MKTs are ready for use. to indicate when MKTs are ready for use.
Each MKT has two IDs - a SendID and a RecvID. The SendID is Each MKT has two IDs - a SendID and a RecvID. The SendID is
inserted as the KeyID of the TCP-OP option of outgoing segments, inserted as the KeyID of the TCP-OP option of outgoing segments,
and the RecvID is matched against the KeyID of the TCP-AO option and the RecvID is matched against the KeyID of the TCP-AO option
of incoming segments. These and other uses of these two IDs are of incoming segments. These and other uses of these two IDs are
described further in Section 9.4 and 9.5. described further in Section 9.4 and 9.5.
>> MKT IDs MUST support any value, 0-255 inclusive. There are no >> MKT IDs MUST support any value, 0-255 inclusive. There are no
reserved ID values. reserved ID values.
skipping to change at page 13, line 7 skipping to change at page 12, line 43
o Receive_other_traffic_key o Receive_other_traffic_key
Note that the keys are directional. A given connection typically uses Note that the keys are directional. A given connection typically uses
only three of these keys, because only one of the SYN keys is only three of these keys, because only one of the SYN keys is
typically used. All four are used only when a connection goes through typically used. All four are used only when a connection goes through
'simultaneous open' [RFC793]. 'simultaneous open' [RFC793].
The relationship between MKTs and traffic keys is shown in Figure The relationship between MKTs and traffic keys is shown in Figure
Figure 3. Traffic keys are indicated with a "*". Note that every MKT Figure 3. Traffic keys are indicated with a "*". Note that every MKT
derives all four traffic keys, regardless of whether all four are can be used to derive any of the four traffic keys, but only the keys
needed for a given connection. Section 7.2 provides further details actually needed to handle the segments of a connection need to be
on how traffic keys are derived. computed. Section 7.2 provides further details on how traffic keys
are derived.
MKT-A MKT-B MKT-A MKT-B
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 | | SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 | | RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC | | MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC | | KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+ +---------------------+ +------------------------+
| | | |
+----------+----------+ | +----------+----------+ |
skipping to change at page 14, line 41 skipping to change at page 14, line 35
segments, whose SendID is inserted in outgoing segments as KeyID segments, whose SendID is inserted in outgoing segments as KeyID
(see Section 9.4, step 5). Incoming segments are authenticated (see Section 9.4, step 5). Incoming segments are authenticated
using the MKT corresponding to the segment and the KeyID in its using the MKT corresponding to the segment and the KeyID in its
TCP-AO header (see Section 9.5, step 5), as matched against the TCP-AO header (see Section 9.5, step 5), as matched against the
MKT TCP connection identifier and the MKT RecvID. There is only MKT TCP connection identifier and the MKT RecvID. There is only
one current_key at any given time on a particular connection. one current_key at any given time on a particular connection.
>> Every TCP connection in a non-IDLE state MUST have at most one >> Every TCP connection in a non-IDLE state MUST have at most one
current_key specified. current_key specified.
2. Next_key -the MKT currently preferred for future use, whose RecvID 2. Rnext_key -the MKT currently preferred for incoming (received)
is inserted in outgoing segments as NextKeyID (see Section 9.5, segments, whose RecvID is inserted in outgoing segments as
step 5). RNextKeyID (see Section 9.5, step 5).
>> Each TCP connection in a non-IDLE state MUST have at most one >> Each TCP connection in a non-IDLE state MUST have at most one
next_key specified. rnext_key specified.
3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to
prevent replay attacks, as described in Section 8.2. Each SNE is prevent replay attacks, as described in Section 8.2. Each SNE is
initialized to zero upon connection establishment. Its use in the initialized to zero upon connection establishment. Its use in the
MAC calculation is described in Section 7.1. MAC calculation is described in Section 7.1.
4. One or more MKTs. These are the MKTs that match this connection's 4. One or more MKTs. These are the MKTs that match this connection's
socket pair. socket pair.
MKTs are used, together with other parameters of a connection, to MKTs are used, together with other parameters of a connection, to
skipping to change at page 15, line 40 skipping to change at page 15, line 29
AO. AO.
7.1. MAC Algorithms 7.1. MAC Algorithms
MAC algorithms take a variable-length input and a key and output a MAC algorithms take a variable-length input and a key and output a
fixed-length number. This number is used to determine whether the fixed-length number. This number is used to determine whether the
input comes from a source with that same key, and whether the input input comes from a source with that same key, and whether the input
has been tampered in transit. MACs for TCP-AO have the following has been tampered in transit. MACs for TCP-AO have the following
interface: interface:
INPUT: MAC_alg, MAC_truncation, traffic_key, data_block MAC = MAC_alg(traffic_key, data_block)
INPUT: MAC_alg, traffic_key, data_block
OUTPUT: MAC OUTPUT: MAC
where: where:
o MAC_alg - MAC algorithm used for this computation o MAC_alg - MAC algorithm used for this computation. The MAC
algorithm specifies the output length, so no separate output
o MAC_truncation - the number of bytes to truncate the output of the length parameter is required.
MAC to. This is indicated by the MAC algorithm, as specified in
[ao-crypto].
o Traffic_key - traffic key used for this computation. This is o Traffic_key - traffic key used for this computation. This is
computed from the connection's current MKT as described in Section computed from the connection's current MKT as described in Section
7.2. 7.2.
o Data_block - input data over which the MAC is computed. In TCP-AO, o Data_block - input data over which the MAC is computed. In TCP-AO,
this is the TCP segment prepended by the TCP pseudoheader and TCP this is the TCP segment prepended by the TCP pseudoheader and TCP
header options, as described in Section 7.1. header options, as described in Section 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the o MAC - the fixed-length output of the MAC algorithm, given the
skipping to change at page 18, line 30 skipping to change at page 18, line 30
MAC algorithm indicates how to use the traffic key, e.g., as HMACs do MAC algorithm indicates how to use the traffic key, e.g., as HMACs do
[RFC2104][RFC2403]. The traffic key is derived from the current MKT [RFC2104][RFC2403]. The traffic key is derived from the current MKT
as described in Sections 7.2. as described in Sections 7.2.
7.2. Key Derivation Functions 7.2. Key Derivation Functions
TCP-AO's traffic keys are derived from the MKTs using Key Derivation TCP-AO's traffic keys are derived from the MKTs using Key Derivation
Functions (KDFs). The KDFs used in TCP-AO have the following Functions (KDFs). The KDFs used in TCP-AO have the following
interface: interface:
INPUT: PRF_alg, master_key, output_length, data_block traffic_key = PRF_alg(master_key, data_block, output_length)
INPUT: PRF_alg, master_key, data_block, output_length
OUTPUT: traffic_key OUTPUT: traffic_key
where: where:
o PRF_alg - the specific pseudorandom function (PRF) that is the o PRF_alg - the specific pseudorandom function (PRF) that is the
basic building block used in constructing the given KDF, as basic building block used in constructing the given KDF, as
indicated in the MKT. This is specified by the KDF as described in indicated in the MKT. This is specified by the KDF as described in
[ao-crypto]. [ao-crypto].
o Master_key - The master_key string, as will be stored into the o Master_key - The master_key string, as will be stored into the
associated MKT. associated MKT.
o Output_length - The desired output length of the KDF, i.e., the
length to which the KDF's output will be truncated. In TCP-AO, the
output_length is the PRF_truncation value of the MKT. This is
specified by the KDF as described in [ao-crypto].
o Data_block - The data block used as input in constructing the KDF. o Data_block - The data block used as input in constructing the KDF.
The data block provided by TCP-AO is used as the "context" as The data block provided by TCP-AO is used as the "context" as
specified in [ao-crypto]. The specific way this context is used, specified in [ao-crypto]. The specific way this context is used,
in conjunction with other information, to create the raw input to in conjunction with other information, to create the raw input to
the PRF is also explained further in [ao-crypto]. the PRF is also explained further in [ao-crypto].
o Output_length - The desired output length of the KDF, i.e., the
length to which the KDF's output will be truncated. In TCP-AO, the
output_length is the PRF_truncation value of the MKT. This is
specified by the KDF as described in [ao-crypto].
o Traffic_key - The desired output of the KDF, of length
output_length, to be used as input to the MAC algorithm, as
described in Section 7.1.
The data used as input to the KDF combines TCP socket pair with the The data used as input to the KDF combines TCP socket pair with the
endpoint initial sequence numbers (ISNs) of a connection. This endpoint initial sequence numbers (ISNs) of a connection. This
provides context unique to each TCP connection instance, which provides context unique to each TCP connection instance, which
enables TCP-AO to generate unique traffic keys for that connection, enables TCP-AO to generate unique traffic keys for that connection,
even from a MKT used across many different connections or across even from a MKT used across many different connections or across
repeated connections that share a socket pair. Unique traffic keys repeated connections that share a socket pair. Unique traffic keys
are generated without relying on external key management properties. are generated without relying on external key management properties.
This data block is defined in Figure 7 and Figure 8. This data block is defined in Figure 7 and Figure 8.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 22, line 7 skipping to change at page 22, line 7
A SYN is authenticated using a destination ISN of zero (whether sent A SYN is authenticated using a destination ISN of zero (whether sent
or received), and all other segments would be authenticated using the or received), and all other segments would be authenticated using the
ISN pair for the connection. There are other cases in which 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 destination ISN is not known, but segments are emitted, such as after
an endpoint reboots, when is possible that the two endpoints would an endpoint reboots, when is possible that the two endpoints would
not have enough information to authenticate segments. In such cases, not have enough information to authenticate segments. In such cases,
TCP's timeout mechanism will allow old state to be cleared to enable TCP's timeout mechanism will allow old state to be cleared to enable
new connections, except where the user timeout is disabled; it is new connections, except where the user timeout is disabled; it is
important that implementations are capable of detecting excesses of important that implementations are capable of detecting excesses of
TCP connections in such a configuration and can clear them out if TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Je07]. needed to protect its memory usage [Ba09].
7.3. Traffic Key Establishment and Duration Issues 7.3. Traffic Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for traffic key The TCP-AO option does not provide a mechanism for traffic 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 for coordinating rekeying during a of the TCP-AO option), or for coordinating rekeying during a
connection. We assume out-of-band mechanisms for MKT establishment, connection. We assume out-of-band mechanisms for MKT establishment,
parameter negotiation, and rekeying. This separation of MKT use from parameter negotiation, and rekeying. This separation of MKT use from
MKT management is similar to that in the IPsec security suite MKT management is similar to that in the IPsec security suite
[RFC4301][RFC4306]. [RFC4301][RFC4306].
skipping to change at page 23, line 31 skipping to change at page 23, line 31
8. Additional Security Mechanisms 8. Additional Security Mechanisms
TCP-AO adds mechanisms to support efficient use, especially in TCP-AO adds mechanisms to support efficient use, especially in
environments where only manual keying is available. These include the environments where only manual keying is available. These include the
previously described mechanisms for supporting multiple concurrent previously described mechanisms for supporting multiple concurrent
MKTs (via the KeyID field) and for generating unique per-connection MKTs (via the KeyID field) and for generating unique per-connection
traffic keys (via the KDF). This section describes additional traffic keys (via the KDF). This section describes additional
mechanisms to coordinate MKT changes and to prevent replay attacks mechanisms to coordinate MKT changes and to prevent replay attacks
when a traffic key is not changed for long periods of time. when a traffic key is not changed for long periods of time.
8.1. Coordinating MKT Changes 8.1. Coordinating Use of New MKTs
At any given time, a single TCP connection may have multiple MKTs At any given time, a single TCP connection may have multiple MKTs
specified for each segment direction (incoming, outgoing). TCP-AO specified for each segment direction (incoming, outgoing). TCP-AO
provides a mechanism to indicate when a new MKT is ready, to allow provides a mechanism to indicate when a new MKT is ready, to allow
the sender to commence use of that new MKT. This supported by using the sender to commence use of that new MKT. This mechanism allows new
two ID fields in the header: MKT use to be coordinated, to avoid unnecessary loss due to sender
authentication using a MKT not yet ready at the receiver.
o KeyID Note that this is intended as an optimization. Deciding when to start
using a key is a performance issue. Deciding when to remove an MKT is
a security issue. Invalid MKTs are expected to be removed. TCP-AO
provides no mechanism to coordinate their removal, as we consider
this a key management operation.
o NextKeyID New MKT use is coordinated through two ID fields in the header:
o KeyID
o RNextKeyID
KeyID represents the outgoing MKT information used by the segment KeyID represents the outgoing MKT information used by the segment
sender to create the segment's MAC (outgoing), and the corresponding sender to create the segment's MAC (outgoing), and the corresponding
incoming keying information used by the segment receiver to validate incoming keying information used by the segment receiver to validate
that MAC. It contains the SendID of the MKT in active use in that that MAC. It contains the SendID of the MKT in active use in that
direction. direction.
NextKeyID represents the preferred MKT information to be used for RNextKeyID represents the preferred MKT information to be used for
subsequent segments. I.e., it is a way for the segment sender to subsequent received segments ('receive next'). I.e., it is a way for
indicate a ready incoming MKT for future segments it receives, so the segment sender to indicate a ready incoming MKT for future
that the segment receiver can know when to switch MKTs (and thus segments it receives, so that the segment receiver can know when to
their KeyIDs and associated traffic keys). It indicates the RecvID of switch MKTs (and thus their KeyIDs and associated traffic keys). It
the MKT desired to for incoming segments. indicates the RecvID of the MKT desired to for incoming segments.
There are two pointers kept by each side of a connection, as noted in There are two pointers kept by each side of a connection, as noted in
the per-connection information (see Section 6): the per-connection information (see Section 6):
o Currently active outgoing MKT (Current_key) o Currently active outgoing MKT (Current_key)
o Current preference for incoming MKT (Next_key) o Current preference for incoming MKT (RNext_key)
Current_key indicates a MKT that is used to authenticate outgoing Current_key indicates a MKT that is used to authenticate outgoing
segments. Upon connection establishment, it points to the first MKT segments. Upon connection establishment, it points to the first MKT
selected for use. selected for use.
Next_key points to an incoming MKT that is ready and preferred for Next_key points to an incoming MKT that is ready and preferred for
use. Upon connection establishment, this points to the currently use. Upon connection establishment, this points to the currently
active incoming MKT. It can be changed when new MKTs are installed active incoming MKT. It can be changed when new MKTs are installed
(e.g., either by automatic MKT management protocol operation or by (e.g., either by automatic MKT management protocol operation or by
user manual selection). user manual selection).
skipping to change at page 25, line 37 skipping to change at page 25, line 47
zero, as well as a current TCP segment field (SEG.SEQ): zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.SNE_FLAG, which indicates when to increment the SND.SNE o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
When a segment is received, the following algorithm (written in C) When a segment is received, the following algorithm (in C-like
computes the SNE used in the MAC; an equivalent algorithm can be pseudocode) computes the SNE used in the MAC; an equivalent algorithm
applied to the "SND" side: can be applied to the "SND" side:
/* set the flag when the SEG.SEQ first rolls over */ /* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0) if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1; RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1; RCV.SNE_FLAG = 1;
} }
/* decide which SNE to use after incremented */ /* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) { if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value SNE = RCV.SNE - 1; # use the pre-increment value
skipping to change at page 27, line 33 skipping to change at page 27, line 33
>> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP >> A TCP-AO implmentation MUST allow the set of MKTs 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.
The MKTs associated with a connection needs to be available for The MKTs associated with a connection needs to be available for
confirmation; this includes the ability to read the MKTs: confirmation; this includes the ability to read the MKTs:
>> TCP STATUS SHOULD be augmented to allow the MKTs of a current or >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or
pending connection to be read (for confirmation). pending connection to be read (for confirmation).
Senders may need to be able to determine when the outgoing MKT Senders may need to be able to determine when the outgoing MKT
changes (KeyID) or when a new preferred MKT (NextKeyID) is indicated; changes (KeyID) or when a new preferred MKT (RNextKeyID) is
these changes immediately affect all subsequent outgoing segments: indicated; these changes immediately affect all subsequent outgoing
segments:
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be
augmented so that the preferred outgoing MKT (Current_key) and/or the augmented so that the preferred outgoing MKT (Current_key) and/or the
preferred incoming MKT Next_key of a connection can be indicated. preferred incoming MKT Next_key of a connection can be indicated.
It may be useful to change the outgoing active MKT (Current_key) even It may be useful to change the outgoing active MKT (Current_key) even
when no data is being sent, which can be achieved by sending a zero- when no data is being sent, which can be achieved by sending a zero-
length buffer or by using a non-send interface (e.g., socket options length buffer or by using a non-send interface (e.g., socket options
in Unix), depending on the implementation. in Unix), depending on the implementation.
It is also useful to indicate recent segment KeyID and NextKeyID It is also useful to indicate recent segment KeyID and RNextKeyID
values received; although there could be a number of such values, values received; although there could be a number of such values,
they are not expected to change quickly so any recent sample should they are not expected to change quickly so any recent sample should
be sufficient: be sufficient:
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE,
MUST be augmented so that the KeyID and NextKeyID of a recently MUST be augmented so that the KeyID and RNextKeyID of a recently
received segment is available to the user out-of-band (e.g., as an received segment is available to the user out-of-band (e.g., as an
additional parameter to RECEIVE, or via a STATUS call). additional parameter to RECEIVE, or via a STATUS call).
9.2. TCP States and Transitions 9.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 MKT MAY be associated with any TCP state. >> A MKT MAY be associated with any TCP state.
skipping to change at page 28, line 27 skipping to change at page 28, line 30
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 set of MKTs for >> All TCP segments MUST be checked against the set of MKTs for
matching TCP connection identifiers. matching TCP connection identifiers.
>> TCP segments whose TCP-AO option does not validate MUST be >> TCP segments whose TCP-AO option does not validate MUST be
silently discarded. silently discarded.
>> TCP segments with TCP-AO but not matching an MKT MUST be silently >> A TCP-AO implementation MUST allow for configuration of the
accepted; this is required for equivalent function with TCPs not behavior of segments with the TCP-AO option but that do not match an
implementing TCP-AO. MKT. The initial default of this configuration SHOULD be to silently
accept such connections. If this is not the desired case, an MKT can
be included to match such connections, or the connection can indicate
that TCP-AO is required. Alternately, the configuration can be
changed to discard segments with the AO option not matching an MKT.
>> Silent discard events SHOULD be signaled to the user as a warning, >> Silent discard events SHOULD be signaled to the user as a warning,
and silent accept events MAY be signaled to the user as a warning. and silent accept events MAY be signaled to the user as a warning.
Both warnings, if available, MUST be accessible via the STATUS Both warnings, if available, MUST be accessible via the STATUS
interface. Either signal MAY be asynchronous, but if so they MUST be interface. Either signal MAY be asynchronous, but if so they MUST be
rate-limited. Either signal MAY be logged; logging SHOULD allow rate- rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
limiting as well. limiting as well.
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.
skipping to change at page 29, line 41 skipping to change at page 30, line 5
current_key (using the current_key MKT's SendID as the TCP-AO current_key (using the current_key MKT's SendID as the TCP-AO
KeyID). Update the TCP header length accordingly. KeyID). Update the TCP header length accordingly.
b. Determine SND.SNE as described in Section 8.2. b. Determine SND.SNE as described in Section 8.2.
c. Determine the appropriate traffic key, i.e., as pointed to by c. Determine the appropriate traffic key, i.e., as pointed to by
current_key (as noted in Section 8.1, and as probably cached current_key (as noted in Section 8.1, and as probably cached
in the TCB). I.e., use the send_SYN_traffic_key for SYN in the TCB). I.e., use the send_SYN_traffic_key for SYN
segments, and the send_other_traffic_key for other segments. segments, and the send_other_traffic_key for other segments.
d. Determine the NextKeyID as indicated by the Next_key pointer, d. Determine the RNextKeyID as indicated by the Rnext_key
and insert it in the TCP-AO option (using the next_key MKT's pointer, and insert it in the TCP-AO option (using the
RecvID as the TCP-AO KeyID) (as noted in Section 8.1). next_key MKT's RecvID as the TCP-AO KeyID) (as noted in
Section 8.1).
e. Compute the MAC using the MKT (and cached traffic key) and e. Compute the MAC using the MKT (and cached traffic key) and
data from the segment as specified in Section 7.1. data from the segment as specified in Section 7.1.
f. Insert the MAC in the TCP-AO MAC field. f. Insert the MAC in the TCP-AO MAC field.
g. Proceed with transmitting the segment. g. Proceed with transmitting the segment.
9.5. Receiving TCP Segments 9.5. Receiving TCP Segments
skipping to change at page 30, line 28 skipping to change at page 30, line 40
segments can cache whether TCP-AO is needed in the TCB. segments can cache whether TCP-AO is needed in the TCB.
1. Find the per-connection parameters for the segment: 1. Find the per-connection parameters for the segment:
a. If the segment is a SYN, then this is the first segment of a a. If the segment is a SYN, then this is the first segment of a
new connection. Find the matching MKT for this segment, using new connection. Find the matching MKT for this segment, using
the segment's socket pair and its TCP-AO KeyID, matched the segment's socket pair and its TCP-AO KeyID, matched
against the MKT's TCP connection identifier and the MKT's against the MKT's TCP connection identifier and the MKT's
RecvID. RecvID.
i. If there is no matching MKT, omit the TCP-AO option. i. If there is no matching MKT, remove the TCP-AO option
Proceed with further TCP handling of the segment. from the segment. Proceed with further TCP handling of
the segment.
NOTE: this presumes that connections that do not match
any MKT should be silently accepted, as noted in Sec 9.3.
ii. If there is a matching MKT, then set the per-connection ii. If there is a matching MKT, then set the per-connection
parameters as needed (see Section 6). Proceed with the parameters as needed (see Section 6). Proceed with the
step 2. step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
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 MKT. indicated by the MKT.
skipping to change at page 31, line 13 skipping to change at page 31, line 26
receive_other_traffic_key for other segments. receive_other_traffic_key for other segments.
d. Compute the segment's MAC using the MKT (and its derived d. Compute the segment's MAC using the MKT (and its derived
traffic key) and portions of the segment as indicated in traffic key) and portions of the segment as indicated in
Section 7.1. Section 7.1.
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 9.3. the event as indicated in Section 9.3.
e. Compare the received NextKeyID value to the currently active e. Compare the received RNextKeyID value to the currently active
outgoing KeyID value (Current_key MKT's SendID). outgoing KeyID value (Current_key MKT's SendID).
i. If they match, no further action is required. i. If they match, no further action is required.
ii. If they differ, determine whether the NextKeyID MKT is ii. If they differ, determine whether the RNextKeyID MKT is
ready. ready.
1. If the MKT corresponding to the segment's socket 1. If the MKT corresponding to the segment's socket
pair and NextKeyID is not available, no action is pair and RNextKeyID is not available, no action is
required (NextKeyID of a received segment needs to required (RNextKeyID of a received segment needs to
match the MKT's SendID). match the MKT's SendID).
2. If the matching MKT corresponding to the segment's 2. If the matching MKT corresponding to the segment's
socket pair and NextKeyID is available: socket pair and RNextKeyID is available:
a. Optionally, set a timer on the MKT indicated by
the current_key and segment socket pair to
ensure that the MKT cannot be deleted for 2*MSL.
If a timer has already been set, reset the
timer.
This timer is advisory only. Removing MKTs with
unexpired timers can result in a user-level
warning, but is not prohibited. Implementation
of timers is not required.
b. Set Current_key to the NextKeyID MKT. a. Set Current_key to the RNextKeyID MKT.
f. Proceed with TCP processing of the segment. f. Proceed with TCP processing of the segment.
It is suggested that TCP-AO implementations validate a segment's It is suggested that TCP-AO implementations validate a segment's
Length field before computing a MAC, to reduce the overhead incurred Length field before computing a MAC, to reduce the overhead incurred
by spoofed segments with invalid TCP-AO fields. by spoofed segments with invalid TCP-AO fields.
Additional reductions in MAC validation overhead can be supported in Additional reductions in MAC validation overhead can be supported in
the MAC algorithms, e.g., by using a computation algorithm that the MAC algorithms, e.g., by using a computation algorithm that
prepends a fixed value to the computed portion and a corresponding prepends a fixed value to the computed portion and a corresponding
skipping to change at page 34, line 26 skipping to change at page 34, line 27
used by an attacker. Depending on the modifications, TCP could have used by an attacker. Depending on the modifications, TCP could have
compromised efficiency (e.g., timestamp changes), or could cease compromised efficiency (e.g., timestamp changes), or could cease
correct operation (e.g., window scale changes). These vulnerabilities correct operation (e.g., window scale changes). These vulnerabilities
affect only the TCP connections for which TCP-AO is configured to affect only the TCP connections for which TCP-AO is configured to
ignore TCP options. ignore TCP options.
11.2. Interactions with NAT/NAPT Devices 11.2. Interactions with NAT/NAPT Devices
TCP-AO cannot interoperate natively across NAT/NAPT devices, which TCP-AO cannot interoperate natively across NAT/NAPT devices, which
modify the IP addresses and/or port numbers. We anticipate that modify the IP addresses and/or port numbers. We anticipate that
traversing such devices will require variants of existing NAT/NAPT traversing such devices may require variants of existing NAT/NAPT
traversal mechanisms, e.g., encapsulation of the TCP-AO-protected traversal mechanisms, e.g., encapsulation of the TCP-AO-protected
segment in another transport segment (e.g., UDP), as is done in IPsec segment in another transport segment (e.g., UDP), as is done in IPsec
[RFC2766][RFC3947]. Such variants can be adapted for use with TCP-AO, [RFC2663][RFC3947]. Such variants can be adapted for use with TCP-AO,
or IPsec NAT traversal can be used instead in such cases [RFC3947]. or IPsec NAT traversal can be used instead in such cases [RFC3947].
An alternate proposal for accommodating NATs extends TCP-AO
independently of this specification [ao-nat].
12. Evaluation of Requirements Satisfaction 12. Evaluation of Requirements Satisfaction
TCP-AO satisfies all the current requirements for a revision to TCP TCP-AO satisfies all the current requirements for a revision to TCP
MD5, as summarized below [Be07]. MD5, as summarized below [Be07].
1. Protected Elements 1. Protected Elements
A solution to revising TCP MD5 should protect (authenticate) the A solution to revising TCP MD5 should protect (authenticate) the
following elements. following elements.
skipping to change at page 41, line 8 skipping to change at page 41, line 8
TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets
typically occur after peer crashes, either in response to new typically occur after peer crashes, either in response to new
connection attempts or when data is sent on stale connections; in connection attempts or when data is sent on stale connections; in
either case, the recovering endpoint may lack the connection key either case, the recovering endpoint may lack the connection key
required (e.g., if lost during the crash). This may result in time- required (e.g., if lost during the crash). This may result in time-
outs, rather than more responsive recovery after such a crash. As outs, rather than more responsive recovery after such a crash. As
noted in Section 7.2, such cases may also result in persistent TCP noted in Section 7.2, such cases may also result in persistent TCP
state for old connections that cannot be cleared, and so state for old connections that cannot be cleared, and so
implementations should be capable of detecting an excess of such implementations should be capable of detecting an excess of such
connections and clearing their state if needed to protect memory connections and clearing their state if needed to protect memory
utilization [Je07]. utilization [Ba09].
TCP-AO does not include a fast decline capability, e.g., where a SYN- TCP-AO does not include a fast decline capability, e.g., where a SYN-
ACK is received without an expected TCP-AO option and the connection ACK is received without an expected TCP-AO option and the connection
is quickly reset or aborted. Normal TCP operation will retry and is quickly reset or aborted. Normal TCP operation will retry and
timeout, which is what should be expected when the intended receiver timeout, which is what should be expected when the intended receiver
is not capable of the TCP variant required anyway. Backoff is not is not capable of the TCP variant required anyway. Backoff is not
optimized because it would present an opportunity for attackers on optimized because it would present an opportunity for attackers on
the wire to abort authenticated connection attempts by sending the wire to abort authenticated connection attempts by sending
spoofed SYN-ACKs without the TCP-AO option. spoofed SYN-ACKs without the TCP-AO option.
TCP-AO is intended to provide similar protections to IPsec, but is TCP-AO is intended to provide similar protections to IPsec, but is
not intended to replace the use of IPsec or IKE either for more not intended to replace the use of IPsec or IKE either for more
robust security or more sophisticated security management. robust security or more sophisticated security management.
TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes
recommendations regarding dropping ICMPs in certain contexts, or recommendations regarding dropping ICMPs in certain contexts, or
requiring that they are endpoint authenticated in others [RFC4301]. requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the of some messages based on TCP state, but these do not provide the
level of authentication for ICMP that TCP-AO provides for TCP [Go07]. level of authentication for ICMP that TCP-AO provides for TCP [Go09].
>> 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
(destination unreachable) Codes 2-4 (protocol unreachable, port (destination unreachable) Codes 2-4 (protocol unreachable, port
unreachable, and fragmentation needed - 'hard errors') intended for unreachable, and fragmentation needed - 'hard errors') intended for
connections that match MKTs. An implementation SHOULD allow ignored connections that match MKTs. An implementation SHOULD allow ignored
ICMPs to be logged. ICMPs to be logged.
This control affects only ICMPs that currently require 'hard errors', This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection [RFC1122]. This recommendation which would abort the TCP connection [RFC1122]. This recommendation
skipping to change at page 43, line 47 skipping to change at page 43, line 47
[RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative [RFC3517] Blanton, E., M. Allman, K. Fall, L. Wang, "A Conservative
Selective Acknowledgment (SACK)-based Loss Recovery Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP", RFC-3517, Proposed Standard, April Algorithm for TCP", RFC-3517, Proposed Standard, April
2003. 2003.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol,"
RFC-4306, Proposed Standard, Dec. 2005. RFC-4306, Proposed Standard, Dec. 2005.
[ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, &
Implementation Requirments for TCP Authentication Option", Implementation Requirments for TCP Authentication Option",
draft-lebovitz-ietf-tcpm-tcp-ao-crypto, Mar. 2009. draft-ietf-tcpm-tcp-ao-crypto-01, Oct. 2009.
15.2. Informative References 15.2. Informative References
[ao-nat] Touch, J., "A TCP Authentication Option NAT Extension,"
draft-touch-tcp-ao-nat-00, Oct. 2009.
[Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem [Be07] Eddy, W., (ed), S. Bellovin, J. Touch, R. Bonica, "Problem
Statement and Requirements for a TCP Authentication Statement and Requirements for a TCP Authentication
Option," draft-bellovin-tcpsec-01, (work in progress), Jul. Option," draft-bellovin-tcpsec-01, (work in progress), Jul.
2007. 2007.
[Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
"Authentication for TCP-based Routing and Management "Authentication for TCP-based Routing and Management
Protocols," draft-bonica-tcp-auth-06, (work in progress), Protocols," draft-bonica-tcp-auth-06, (work in progress),
Feb. 2007. Feb. 2007.
[Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Bo09] Borman, D., "TCP Options and MSS," draft-ietf-tcpm-tcpmss-
attacks-05, (work in progress), Jun. 2009. 02, Jul. 2009.
[Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist [Go09] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
Condition," draft-mahesh-persist-timeout-03, (work in attacks-06, (work in progress), Aug. 2009.
progress), Oct. 2007.
[Ba09] Bashyam, M., M. Jethanandani,, A. Ramaiah "Clarification of
sender behaviour in persist condition," draft-ananth-tcpm-
persist-01, (work in progress), Jul. 2009.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. Informational, April 1992.
[RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
High Performance," RFC-1323, May 1992. High Performance," RFC-1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks,"
RFC-1948, Informational, May 1996. RFC-1948, Informational, May 1996.
[RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing [RFC2104] Krawczyk, H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication," RFC-2104, Informational, Feb. for Message Authentication," RFC-2104, Informational, Feb.
1997. 1997.
[RFC2766] Tsirtsis, G., P. Srisuresh, "Network Address Translation - [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Protocol Translation (NAT-PT)," RFC-2766, Proposed Translator (NAT) Terminology and Considerations", RFC 2663,
Standard, Feb. 2000. August 1999.
[RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues," [RFC3234] Carpenter, B., S. Brim, "Middleboxes: Taxonomy and Issues,"
RFC-3234, Informational, Feb. 2002. RFC-3234, Informational, Feb. 2002.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option," RFC-3562, Informational, July 2003. Signature Option," RFC-3562, Informational, July 2003.
[RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe, [RFC3947] Kivinen, T., B. Swander, A. Huttunen, V. Volpe,
"Negotiation of NAT-Traversal in the IKE," RFC-3947, "Negotiation of NAT-Traversal in the IKE," RFC-3947,
Proposed Standard, Jan. 2005. Proposed Standard, Jan. 2005.
 End of changes. 71 change blocks. 
176 lines changed or deleted 179 lines changed or added

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