One document matched: draft-touch-tcpm-tcp-simple-auth-02.txt
Differences from draft-touch-tcpm-tcp-simple-auth-01.txt
TCPM WG J. Touch
Internet Draft USC/ISI
Expires: April 2007 A. Mankin
October 22, 2006
The TCP Simple Authentication Option
draft-touch-tcpm-tcp-simple-auth-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2007.
Abstract
This document specifies a TCP Simple Authentication Option (TCP-SA)
which is intended to replace the TCP MD5 Signature option of RFC-2385
(TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and
provides more details on the association of security associations
with TCP connections. TCP-SA assumes an external, out-of-band
mechanism (manual or via a separate protocol) for session key
establishment, parameter negotiation, and rekeying, replicating the
separation of key management and key use as in the IPsec suite.
Touch & Mankin Expires April 22, 2007 [Page 1]
Internet-Draft The TCP Simple Authentication Option October 2006
The result is intended to be a simple modification to support current
infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to
support a larger set of hashes with minimal other system and
operational changes. TCP-SA requires no new option identifier, though
it is intended to be mutually exclusive with TCP/MD5 on a given TCP
connection.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction...................................................3
1.1. Executive Summary.........................................3
1.2. Changes from Previous Versions............................5
1.2.1. New in draft-touch-tcp-simple-auth-02................5
1.2.2. New in draft-touch-tcp-simple-auth-01................5
1.3. Summary of RFC-2119 Requirements..........................5
2. The TCP Simple Authentication Option...........................5
2.1. Review of TCP/MD5 Option..................................6
2.2. TCP-SA Option.............................................6
3. Security Association Management................................9
4. TCP-SA Interaction with TCP...................................11
4.1. User Interface...........................................11
4.2. TCP States and Transitions...............................12
4.3. TCP Segments.............................................12
4.4. Sending TCP Segments.....................................13
4.5. Receiving TCP Segments...................................13
4.6. Impact on TCP Header Size................................14
5. Key Establishment and Duration Issues.........................14
5.1. Implementing the TSAD as an External Database............15
6. Interactions with TCP/MD5.....................................16
7. Security Considerations.......................................17
8. IANA Considerations...........................................18
9. Conclusions...................................................18
10. Acknowledgments..............................................18
11. References...................................................18
11.1. Normative References....................................18
11.2. Informative References..................................19
Author's Addresses...............................................20
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................21
Copyright Statement..............................................21
Touch & Mankin Expires April 22, 2007 [Page 2]
Internet-Draft The TCP Simple Authentication Option October 2006
Acknowledgment...................................................21
1. Introduction
The TCP MD5 Signature (TCP/MD5) is a TCP option that authenticates
TCP segments, including the TCP pseudo-header, TCP header, and TCP
data. It was developed to protect BGP sessions from spoofed TCP
segments which could affect BGP data or the robustness of the TCP
connection itself [RFC2385][To06].
There have been many recently-documented concerns about TCP/MD5. Its
use of a simple keyed hash for authentication is problematic because
there have been escalating attacks on the algorithm itself [Be05]
[Bu06]. TCP/MD5 also lacks both key management and algorithm
agility. This document proposes to add the latter, but suggests that
TCP should not be the framework for cryptographic key management.
This document updates the TCP/MD5 option to become a more general TCP
Simple Authentication Option (TCP-SA), to support the use of other,
stronger hash functions and to provide a more structured
recommendation on external key management.
This document is not intended to replace the use of the IPsec suite
(IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
fact, we recommend the use of IPsec and IKE, especially where IKE's
level of existing support for parameter negotiation, session key
negotiation, or rekeying are desired. TCP-SA is intended for use only
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
keys need to be tightly coordinated with individual transport
sessions [Be06b].
1.1. Executive Summary
This document updates TCP/MD5 as follows [RFC2385]:
o Reuses TCP/MD5's option Kind (=19), but allows TCP/MD5 to continue
to be used for other connections.
o Replaces signed MD5 with HMAC-MD5-96, 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 may be used to make key selection more efficient.
Touch & Mankin Expires April 22, 2007 [Page 3]
Internet-Draft The TCP Simple Authentication Option October 2006
o Provides more detail in how this option interacts with TCP's
states, event processing, and user interface.
o Proposed option is 4 bytes shorter (14 bytes overall, rather than
18) in the default case (HMAC-MD5-96).
This document differs from currently competing proposals to update
TCP/MD5 as follows [Bo06][We05][We06]:
o Does not require a new TCP option Kind value.
o Does not support dynamic parameter negotiation.
o Does not support in-band session key negotiation.
o Does not support in-band session rekeying.
o Does not require additional timers.
o Always authenticates the TCP options as well as the segment
pseudoheader, header, and data.
o Provides more detail in how this option interacts with TCP's
states, event processing, and user interface.
o Proposed option is 2 bytes shorter (14 bytes overall, rather than
16) in the default case (HMAC-MD5-96)
o Does not expose the MAC algorithm in the header.
o Does not require a key ID; it allows for one where key overlap is
desired to support efficient rekeying.
This document differs from an IPsec/IKE solution as follows
[RFC4301][RFC4306]
o Does not support dynamic parameter negotiation.
o Does not require a key ID (SPI), but does allow one.
o Does not protect from replay attacks.
o Forces a change of connection key when a connection restarts, even
when reusing a TCP socket pair (IP addresses and port numbers)
[Be06b].
o Does not support encryption.
Touch & Mankin Expires April 22, 2007 [Page 4]
Internet-Draft The TCP Simple Authentication Option October 2006
o Does not authenticate ICMP messages (some may be authenticated in
IPsec, depending on the configuration).
1.2. Changes from Previous Versions
[NOTE: to be omitted upon final publication as RFC]
1.2.1. New in draft-touch-tcp-simple-auth-02
o Add reference to Bellovin's need-for-TCP-auth doc [Be06b].
o Add reference to SP4 [SDNS88].
o Added notes that TSAD to be externally implemented; this was
compatible with the TSAD described in the previous version.
o Augmented the protocol to allow a KeyID, required to support
efficient overlapping keys during rekeying, and potentially useful
during connection establishment. Accommodated by redesigning the
TSAD.
o Added the odd/even indicator for the KeyID.
o Allow for the exclusion of all TCP options in the MAC calculation.
1.2.2. New in draft-touch-tcp-simple-auth-01
o Allows intra-session rekeying, assuming out-of-band coordination.
o MUST allow TSAD entries to change, enabling rekeying within a TCP
connection.
o Omits discussion of the impact of connection reestablishment on
BGP, because added support for rekeying renders this point moot.
o Adds further discussion on the need for rekeying.
1.3. Summary of RFC-2119 Requirements
[NOTE: a summary will be placed here prior to last call]
2. The TCP Simple Authentication Option
The TCP Simple Authentication Option (TCP-SA) re-uses the Kind value
currently assigned to TCP/MD5.
Touch & Mankin Expires April 22, 2007 [Page 5]
Internet-Draft The TCP Simple Authentication Option October 2006
2.1. Review of TCP/MD5 Option
For review, the TCP/MD5 option is shown in Figure 1.
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| |
+---------------------------------------+
| |
+---------------------------------------+
| |
+-------------------+-------------------+
| |
+-------------------+
Figure 1 Current TCP MD5 Option [RFC2385]
In the current TCP/MD5 option, the length is fixed, and the MD5
digest occupies 16 bytes following the Kind and Length fields, using
the full MD5 digest of 128 bits [RFC1321].
The current TCP/MD5 option specifies the use of the MD5 digest
calculation over the following values in the following order:
1. the TCP pseudoheader (IP source and destination addresses,
protocol number, and segment length)
2. TCP header excluding options and checksum
3. TCP data
4. connection key
2.2. TCP-SA Option
The new TCP-SA option is intended to be a superset of the TCP/MD5
option, and minimal in the spirit of SP4 [SDNS88]. TCP-SA reuses the
same Kind and Length fields, and is shown in Figure 2.
+---------+---------+-----------------...
| Kind=19 | Len=var | MAF... ...
+---------+---------+-----------------...
Figure 2 Proposed TCP-SA Option
The TCP-SA defines the following fields:
Touch & Mankin Expires April 22, 2007 [Page 6]
Internet-Draft The TCP Simple Authentication Option October 2006
o Kind: An unsigned field indicating the TCP-SA Option. TCP-SA
reuses the Kind value=19. Because of how keys are managed (see
Section 3), an endpoint will not use TCP-SA for the same
connection where TCP/MD5 is used, and so there would be no
confusion as to how to interpret incoming Kind=19 segments.
o Length: An unsigned 8-bit field indicating the length of the TCP-
SA option in bytes, including the Kind and Length fields.
>> The Length MUST be greater than or equal to 2.
>> The Length value MUST be consistent with the TCP header length.
Values of 2 and other small values are of dubious utility but not
specifically prohibited. See the MAF description for implications
of odd/even lengths.
o MAF: The MAF is a Message Authentication Field. Its contents are
determined by the particulars of the security association, where
there are two possible variants. When the Length is even, the
option appears as in Figure 3. When the Length is odd, the option
appears as in Figure 4.
+---------+---------+-------------------+
| Kind=19 | Len=var | MAC |
+---------+---------+-------------------+
| MAC (con't)... ...
+-------------------------------------...
Figure 3 TCP-SA MAF without key identifier
+---------+---------+-------------------+
| Kind=19 | Len=var | MAC |
+---------+---------+-------------------+
| MAC (con't)... ...
+-------------------+---------+-------...
...-----------------+---------+
... MAC (con't) | KeyID |
...-----------------+---------+
Figure 4 TCP-SA MAF with key identifier
Touch & Mankin Expires April 22, 2007 [Page 7]
Internet-Draft The TCP Simple Authentication Option October 2006
Typical MACs are 96-128 bits (12-16 bytes), but any length that
fits in the header of the segment being authenticated is allowed.
Because typical MACs are even-length, TCP-SA assumes so [RFC4306].
If a particular MAC is odd-length, it is padded.
>> An odd-length MAC MUST be padded with a single 0x00 byte on
transmit. Setting this pad byte is considered part of the
authentication algorithm.
>> An odd-length MAC MUST have a trailing 0x00 pad byte on
receipt. Checking this pad byte is considered part of the
authentication algorithm.
When the Length is odd, a key identifier (KeyID) is included in
the last byte of the option. 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 3.
>> TCP-SA MUST support HMAC-MD5-96; other MACs MAY be supported
[RFC2403].
>> A single TCP segment MUST NOT have more than one TCP-SA option.
The MAC is defined over the following fields in the following order:
1. the TCP pseudoheader: IP source and destination addresses, zero-
padded protocol number and segment length, all in network byte
order, i.e., exactly as used for the TCP checksum [RFC793]:
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | Proto | TCP Length |
+--------+--------+--------+--------+
Figure 5 TCP pseudoheader [RFC793]
2. TCP header, by default including options, and where the checksum
and TCP-SA MAC fields are set to zero, all in network byte order
3. TCP data
4. Connection key
Touch & Mankin Expires April 22, 2007 [Page 8]
Internet-Draft The TCP Simple Authentication Option October 2006
TCP-SA by default includes the TCP options because these options are
intended to be end-to-end and some are required for proper TCP
operation (e.g., SACK, timestamp). Middleboxes may alter TCP options
en-route are a kind of attack and would be successfully detected by
default by TCP-SA. In cases where the configuration of the
connection's security association state indicates otherwise, the TCP
options can be excluded from the MAC calculation.
The TCP-SA option does not indicate the MAC algorithm either
implicitly (as with TCP/MD5) or explicitly (as with some proposed
alternatives) [RFC2385][Bo06][We05][We06]. The particular algorithm
used is considered part of the configuration state of the
connection's security association and is managed separately (see
Section 3).
3. Security Association Management
TCP-SA relies on a TCP Security Association Database (TSAD). TSAD
entries are assumed to be shared at the endpoints where TCP-SA is
used, in advance of the connection:
1. TCP connection identifier (ID), i.e., socket pair - IP source
address, IP destination address, TCP source port, and TCP
destination address [RFC793]. TSAD entries are uniquely determined
by their TCP connection ID.
2. For each of inbound (received TCP segments) and outbound (sent TCP
segments) on this connection:
a. TCP Option exclusion bit. A bit that, when set, indicates that
TCP options are excluded from all MAC calculations. When the
bit is clear, all TCP options are included.
>> The TCP Option exclusion bit MUST default to "clear".
>> The TCP Option exclusion bit MUST NOT change during a TCP
connection.
b. One or more connection key tuples. Each tuple consists of a
set <KeyID, MAC type, key length, connection key> as follows:
i. KeyID. A single byte used to differentiate overlapping
Connection keys.
Touch & Mankin Expires April 22, 2007 [Page 9]
Internet-Draft The TCP Simple Authentication Option October 2006
ii. MAC type. Indicates the MAC used for this connection, as
per IKEv2 Transform Type 3 [RFC4306]. This includes the
MAC algorithm (e.g., HMAC-MD5, HMAC-SHA1, UMAC, etc.) and
the length of the MAC as computed (e.g., 96, 128, etc.).
Also, a setting of NONE must be supported, to indicate
that authentication is not used in this direction; this
allows asymmetric use of TCP-SA. At least one direction
(inbound/outbound) SHOULD have a non-NONE MAC in
practice, but this is not strictly required.
>> When the outbound MAC is set to values other than
NONE, TCP-SA MUST occur in every outbound TCP segment for
that connection; when set to NONE, TCP-SA MUST NOT occur
in those segments.
>> When the inbound MAC is set to values other than NONE,
TCP-SA MUST occur in every inbound TCP segment for that
connection; when set to NONE, TCP-SA MUST NOT occur in
those segments.
iii. Key length. A byte indicating the length of the
connection key in bytes.
iv. Connection key. A byte sequence used for connection
keying, this may be derived from a separate shared key by
an external protocol over a separate channel.
It is anticipated that TSAD entries for active or opening TCP
connections can be stored in the TCP Control Block (TCB) or in a
separate database (see Section 5.1 for notes on the latter); TSAD
entries for pending connections (in passive or active OPEN) may be
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
connections, the same way that there is only one set of TCBs.
Multiple databases could be used to support virtual hosts, i.e.,
groups of interfaces.
Note that TSAD and the TCP-SA fields may omit the KeyID; the TCP
connection ID already uniquely specifies the TSAD entry, so a
separate field is not needed to specify a key unless key overlay
during rekeying is supported or is needed for key coordination during
connection establishment (see Section 5). The TCP-SA fields omit an
explicit algorithm ID; that algorithm is already specified by the TCP
connection ID and stored in the TSAD.
Also note that this document does not address how TSAD entries are
created or destroyed. It is presumed that a TSAD entry affecting
Touch & Mankin Expires April 22, 2007 [Page 10]
Internet-Draft The TCP Simple Authentication Option October 2006
particular connection cannot be destroyed during an active connection
- or, equivalently, that its parameters are copied local to the
connection and so changes would affect only new connections. The TSAD
could be managed by a separate application protocol, and can be
stored in a separate database if desired.
4. TCP-SA Interaction with TCP
The following is a description of how various TCP states, segments,
events, and interfaces. This description is intended to augment the
description of TCP as provided in RFC793 [RFC793].
4.1. User Interface
The TCP user interface supports active and passive OPEN, SEND,
RECEIVE, CLOSE, STATUS and ABORT.
>> 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
a TSAD entry can be configured.
>> New TSAD entries MUST be checked against a cache of previously
used TSAD entries, and key reuse MUST be prohibited.
Users are advised to not inappropriately reuse keys [RFC3562].
>> TCP STATUS SHOULD be augmented to allow the TSAD entry of a
current or pending connection to be read (for confirmation).
>> TCP STATUS MUST allow TSAD entries for ongoing TCP connections
(i.e., not in the CLOSED state) to be modified. Parameters not used
to index a connection MAY be modified; parameters used to index a
connection MUST NOT be modified.
TSAD entries for TCP connections not in the CLOSED state are deleted
indirectly using the CLOSE or ABORT commands.
>> Use of CLOSE or ABORT MUST retain the TSAD entry in a cache to
assist with checking for key reuse.
This entry may correspond to one of the wait states of TCP (FINE-
WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT), or
may be stored separately (for connections proceeding rapidly to
CLOSED). The size of this cache and duration of retained entries is
up to the user, where we again advise the application of known key
management principles [RFC3562].
Touch & Mankin Expires April 22, 2007 [Page 11]
Internet-Draft The TCP Simple Authentication Option October 2006
TCP SEND and RECEIVE are not affected by TCP-SA.
4.2. TCP States and Transitions
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
CLOSED.
>> A TSAD entry MAY be associated with any TCP state.
>> A TSAD entry MAY underspecify the TCP connection for the LISTEN
state. Such an entry MUST NOT be used for more than one connection
progressing out of the LISTEN state.
4.3. TCP Segments
TCP includes control (at least one of SYN, FIN, RST flags set) and
data (none of SYN, FIN, or RST flags set) segments.
>> All TCP segments MUST be checked against the TSAD for matching TCP
connection IDs.
>> TCP segments matching TSAD entries with non-NULL MACs without TCP-
SA, or with TCP-SA and whose MACs and/or KeyIDs (the latter when in
use) do not validate MUST be silently discarded.
>> TCP segments with TCP-SA but not matching TSAD entries MUST be
silently accepted.
>> 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.
Both warnings, if available, MUST be accessible via the STATUS
interface. Either signal MAY be asynchronous, but if so they MUST be
rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
limiting as well.
All TCP-SA processing occurs between the interface of TCP and IP; for
incoming segments, this occurs after validation of the TCP checksum.
For outgoing segments, this occurs before computation of the TCP
checksum.
Note that the TCP-SA option is not negotiated. It is the
responsibility of the receiver to determine when TCP-SA is required
and to enforce that requirement.
>> Receivers MAY silently accept TCP segments with the TCP-SA option.
Touch & Mankin Expires April 22, 2007 [Page 12]
Internet-Draft The TCP Simple Authentication Option October 2006
4.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support
TCP-SA when a segment departs.
1. Check the segment's TCP connection ID against the TSAD
2. If there is NO TSAD entry, omit the TCP-SA option. Proceed with
computing the TCP checksum and transmit the segment.
3. If there is a TSAD entry and the outgoing MAC is NONE, omit the
TCP-SA option. Proceed with computing the TCP checksum and
transmit the segment.
4. If there is a TSAD entry and the outgoing MAC is not NONE:
a. Augment the TCP header with the TCP-SA, inserting the
appropriate Length and KeyID (the latter only if Length is
odd) based on the indexed TSAD entry. Update the TCP header
length accordingly.
b. Compute the MAC using the indexed TSAD connection key, MAC,
and data from the segment as specified in Section 2.2.
c. Insert the MAC in the TCP-SA field.
d. Proceed with computing the TCP checksum and transmit the
segment.
4.5. Receiving TCP Segments
The following procedure describes the modifications to TCP to support
TCP-SA when a segment arrives.
1. Check the segments TCP connection ID against the TSAD
2. If there is NO TSAD entry, proceed with TCP processing.
3. If there is a TSAD entry and the incoming MAC is NONE, proceed
with TCP processing.
4. If there is a TSAD entry and the incoming MAC is not NONE:
a. Check that the segment's TCP-SA Length matches the length
indicated by the indexed TSAD.
Touch & Mankin Expires April 22, 2007 [Page 13]
Internet-Draft The TCP Simple Authentication Option October 2006
i. If Lengths differ, silently discard the segment. Log
and/or signal the event as indicated in Section 4.3.
b. If the Length is odd, use the KeyID value to index the
appropriate key for this connection
i. If the TSAD has no entry corresponding to the segment's
KeyID, silently discard the segment.
c. Compute the segment's MAC using the indexed TSAD MAC algorithm
and connection key, and portions of the segment as indicated
in Section 2.2.
i. If the computed MAC differs from the TCP-SA MAC field
value, silently discard the segment. Log and/or signal
the event as indicated in Section 4.3.
d. Proceed with TCP processing of the segment.
It is suggested that TCP-SA implementations validate a segment's
Length field before computing a MAC, to reduce the overhead incurred
by spoofed segments with invalid TCP-SA fields.
4.6. Impact on TCP Header Size
The TCP-SA option typically uses a total of 16-18 bytes of TCP header
space. TCP-SA is no larger than and typically 2 bytes smaller than
the TCP/MD5 option. Although TCP option space is limited, we believe
TCP-SA is consistent with the desire to authenticate TCP at the
connection level for similar uses as were intended by TCP/MD5.
5. Key Establishment and Duration Issues
The TCP-SA option does not provide a mechanism for connection key
negotiation or parameter negotiation (MAC algorithm, length, or use
of the TCP-SA option) or rekeying during a connection. We assume out-
of-band mechanisms for key establishment, parameter negotiation, and
rekeying. This separation of key use from key management is similar
to that in the IPsec security suite [RFC4301][RFC4306].
We encourage users of TCP-SA to apply known techniques for generating
appropriate keys, including the use of reasonable connection key
lengths, limited connection key sharing, and limiting the duration of
connection key use [RFC3562].
TCP-SA supports rekeying in which new keys are negotiated out-of-
band, either via a protocol or a manual procedure [Be06a]. New keys
Touch & Mankin Expires April 22, 2007 [Page 14]
Internet-Draft The TCP Simple Authentication Option October 2006
use is coordinated using the out-of-band mechanism to update the LSAD
at both TCP endpoints. In the default case, where only a single key
is used at a time, the temporary use of invalid keys would result in
packets being dropped; TCP is already robust to such drops. Such
drops may affect TCP's throughput temporarily, as a result TCP-SA
benefits from the use of congestion control support for temporary
path outages.
>> TCP-SA SHOULD be deployed in conjunction with support for
selective acknowledgement (SACK), including support for multiple lost
segments in the same round trip [RFC2018][RFC3517].
Note that TCP-SA's support for rekeying is designed to be minimal in
the default case. Segments carry only enough context to identify the
security association [RFC4301][RFC4306]. In TCP-SA, this context is
provided by the socket pair (IP addresses and ports for source and
destination). In the default case, the key is identified only in the
LSAD, and coordinated by a separate mechanism not specified in TCP-
SA. In cases where such coordination is difficult, or where loss
during rekeying is inappropriate, the TSAD can contain multiple
concurrent keys. Where multiple keys are used, 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 keys in sequence.
The KeyID field may also be useful in coordinating keys for new
connections. A TSAD may be configured that matches the unbound source
port, which would return a set of possible keys. The KeyID would then
indicate which key, allowing more efficient connection establishment;
otherwise, the keys could be tried in sequence. See also Section 5.1.
Implementations are encouraged to keep keys in a suitably private
area. Users of TCP-SA are encouraged to use different keys for
inbound and outbound MACs on a given TCP connection.
5.1. Implementing the TSAD as an External Database
The TSAD implementation is considered external to TCP-SA. When an
external database is used, it would be useful to consider the
interface between TCP-SA and the TSAD. The following is largely a
restatement of information in Section 3.
TSAD entries are indexed during a connection as follows:
o TCP connection identifier (The socket pair, sent as 4 byte IP
source address, 4 byte IP destination address, 2 byte TCP source
port, 2 byte TCP destination port)
Touch & Mankin Expires April 22, 2007 [Page 15]
Internet-Draft The TCP Simple Authentication Option October 2006
o Direction indicator (sent as a single byte, 0x00 = inbound, 0x01 =
outbound)
o Number of bytes to be sent/received (two bytes)
o KeyID (single byte, optional, 0x00 when not present)
The call passes the number of bytes sent/received, and an indication
of the direction (send/receive), to enable traffic-based key
rollover.
The source port can be 'unbound', indicated by the value 0x0000. In
this case, the source port is considered a wildcard, and all
corresponding TSAD entries (typically also indexed by the KeyID in
that case) are returned as a list. This feature is used during
connection establishment.
TSAD calls return the following parameters:
o TCP Option exclusion indicator bit (one bit, passed as a byte with
value 0x00 or 0x01).
o Zero or more connection key tuples:
<KeyID, MAC type, MAC length, connection key>
o KeyID (one byte, ignored if the KeyID is not present or 0x00)
o MAC type (two bytes)
o Key length (one byte)
o Connection key (byte sequence, indicating the key value)
When the TSAD returns zero keys, it is indicating that there are no
currently valid keys for the connection.
6. Interactions with TCP/MD5
TCP-SA is intended to be deployed without regard for existing TCP/MD5
option support.
>> A TCP implementation MUST NOT use both TCP-SA and TCP/MD5 for a
particular TCP connection, but MAY support TCP-SA and TCP/MD5
simultaneously for different connections.
There is no need to explicitly indicate which of TCP-SA or TCP/MD5 is
used for a particular connection in the TCP segments. Even where the
Touch & Mankin Expires April 22, 2007 [Page 16]
Internet-Draft The TCP Simple Authentication Option October 2006
two used the same hash (e.g., if TCP-SA were to use MD5 rather than
HMAC-MD5) and the same length (128 bits), TCP-SA computes its MAC
over different data (including the TCP-SA option, notably, with the
MAC zeroed) than TCP/MD5. The probability of a TCP-SA segment being
validated by TCP/MD5 or the converse is roughly equivalent to that of
a random party guessing a valid MAC.
7. Security Considerations
Use of TCP-SA, like use of TCP/MD5 or IPsec, will impact host
performance. Connections that are known to use TCP-SA can be attacked
by transmitting segments with invalid MACs. Attackers would need to
know only the TCP connection ID and TCP-SA Length value to
substantially impact the host's processing capacity. This is similar
to the susceptibility of IPsec to on-path attacks, where the IP
addresses and SPI would be visible. For IPsec, the entire SPI space
(32 bits) is arbitrary, whereas for routing protocols typically only
the source port (16 bits) is arbitrary. As a result, it would be
easier for an off-path attacker to spoof a TCP-SA segment that could
cause receiver validation effort. However, we note that between
Internet routers both ports could be arbitrary (i.e., determined a-
priori out of band), which would constitute roughly the same off-path
antispoofing protection of an arbitrary SPI.
TCP-SA, like TCP/MD5, may inhibit connectionless resets. Such resets
typically occur after peer crashes, either in response to new
connection attempts or when data is sent on stale connections; in
either case, the recovering endpoint may lack the connection key
required (e.g., if lost during the crash). This may result in time-
outs, rather than more responsive recovery after such a crash.
TCP-SA does not expose the MAC algorithm used to authenticate a
particular connection; that information is kept in the TSAD at the
endpoints, and is not indicated in the header.
TCP-SA is intended to provide similar protections to IPsec, but is
not intended to replace the use of IPsec or IKE either for more
robust security or more sophisticated security management.
TCP-SA does not address the issue of ICMP attacks on TCP. IPsec makes
recommendations regarding dropping ICMPs in certain contexts, or
requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the
level of authentication for ICMP that TCP-SA provides for TCP [Go06].
Touch & Mankin Expires April 22, 2007 [Page 17]
Internet-Draft The TCP Simple Authentication Option October 2006
>> A TCP-SA implementation MUST allow the system administrator to
configure whether TCP will ignore incoming ICMP messages of Type 3
Codes 2-4 intended for connections that match TSAD entries with non-
NONE inbound MACs. An implementation SHOULD allow ignored ICMPs to be
logged.
This control affects only ICMPs that currently require 'hard errors'
which would abort the TCP connection. This recommendation is intended
to be similar to how IPsec would handle those messages [RFC4301].
8. IANA Considerations
The TCP-SA option reuses the TCP MD5 Signature option (TCP/MD5),
where Kind=19. This document augments that use of this Kind value,
but there is no need to deprecate or override the use of TCP/MD5.
This document suggests that only one key algorithm would be
applicable in either case, and so there would be no confusion for a
given Length and key value as used for authenticating segments of a
given TCP connection.
If this document is approved as an IETF Standard, IANA is requested
to add a registration for TCP-SA to Kind=19, along with the existing
registration for TCP/MD5, and add a pointer to this document.
9. Conclusions
(to be completed)
10. Acknowledgments
This document was inspired by the revisions to TCP/MD5 suggested by
Brian Weis and Ron Bonica [Bo06][We05]. Russ Housley suggested
L4/application layer management of the TSAD. The KeyID field was
motivated by Steve Bellovin.
11. References
11.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol," STD-007, RFC-
793, Standard, Sept. 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, Proposed
Standard, April 1996.
Touch & Mankin Expires April 22, 2007 [Page 18]
Internet-Draft The TCP Simple Authentication Option October 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Best Current
Practice, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option," RFC-2385, Proposed Standard, Aug. 1998.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, Proposed Standard,
April 2003.
[RFC2403] Madson, C., R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH," RFC-2403, Proposed Standard, Nov. 1998.
11.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
[Be06a] Bellovin, S., "Key Change Strategies for TCP-MD5," draft-
bellovin-keyroll2385-03.txt, (work in progress), Sept.
2006.
[Be06b] Bellovin, S., "Towards a TCP Security Option," draft-
bellovin-tcpsec-00.txt, (work in progress), Oct. 2006.
[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/
[Bo06] Bonica, R., "Authentication for TCP-based Routing and
Management Protocols," draft-bonica-tcp-auth-05, (work in
progress), Jul. 2006.
[Go06] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-00.txt, (expired work in progress), Feb. 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option," RFC-3562, Informational, July 2003.
Touch & Mankin Expires April 22, 2007 [Page 19]
Internet-Draft The TCP Simple Authentication Option October 2006
[RFC4301] Kent, S., K. Seo, "Security Architecture for the Internet
Protocol," RFC-4301, Proposed Standard, Dec. 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol," RFC-
4306, Proposed Standard, Dec. 2005.
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4),"
Specification SDN.401, Revision 1.2, July 12, 1988.
[To06] Touch, J., "Defending TCP Against Spoofing Attacks," draft-
ietf-tcpm-tcp-antispoof-05.txt, (work in progress), Oct.
2006.
[We05] Weis, B., "TCP Message Authentication Code Option," draft-
weis-tcp-mac-option-00.txt, (expired work in progress),
Dec. 2005.
[We06] Weis, B., "Automated key selection extension for the TCP
Authentication Option," draft-weis-tcp-auth-auto-ks-01,
(work in progress), Feb. 2006.
Author's Addresses
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
Email: touch@isi.edu
URL: http://www.isi.edu/touch
Allison Mankin
Washington, DC
U.S.A.
Phone: 1 301 728 7199
Email: mankin@psg.com
URL: http://www.psg.com/~mankin/
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Touch & Mankin Expires April 22, 2007 [Page 20]
Internet-Draft The TCP Simple Authentication Option October 2006
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Touch & Mankin Expires April 22, 2007 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-21 18:55:19 |