draft-ietf-tcpm-tcp-auth-opt-07.txt   draft-ietf-tcpm-tcp-auth-opt-08.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: April 2010 R. Bonica Expires: April 2010 R. Bonica
Juniper Networks Juniper Networks
October 26, 2009 October 27, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-07.txt draft-ietf-tcpm-tcp-auth-opt-08.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 April 26, 2010. This Internet-Draft will expire on April 27, 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
master key tuple (MKT) configuration or an external, out-of-band MKT master key tuple (MKT) configuration or an external, out-of-band MKT
management mechanism; in either case, TCP-AO also protects management mechanism; in either case, TCP-AO also protects
connections when using the same MKT across repeated instances of a connections when using the same MKT across repeated instances of a
connection, using traffic keys derived from the MKT, and coordinates connection, using traffic keys derived from the MKT, and coordinates
MKT changes between endpoints. The result is intended to support MKT changes between endpoints. The result is intended to support
current infrastructure uses of TCP MD5, such as to protect long-lived current infrastructure uses of TCP MD5, such as to protect long-lived
connections (as used, e.g., in BGP and LDP), and to support a larger 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 proposed requirements for the replacement
MD5. of TCP MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Introduction...................................................4
2.1. Executive Summary.........................................4 2.1. Executive Summary.........................................4
2.2. Changes from Previous Version.............................6 3. Conventions used in this document..............................6
2.2.1. New in draft-ietf-tcp-auth-opt-07....................6 4. The TCP Authentication Option..................................6
2.2.2. New in draft-ietf-tcp-auth-opt-06....................6 4.1. Review of TCP MD5 Option..................................6
3. Conventions used in this document..............................7 4.2. The TCP-AO Option.........................................7
4. The TCP Authentication Option..................................7 5. TCP-AO Keys and Their Properties...............................9
4.1. Review of TCP MD5 Option..................................7 5.1. Master Key Tuple..........................................9
4.2. The TCP-AO Option.........................................8 5.2. Traffic Keys.............................................11
5. TCP-AO Keys and Their Properties..............................10 5.3. MKT Properties...........................................12
5.1. Master Key Tuple.........................................10 6. Per-Connection TCP-AO Parameters..............................13
5.2. Traffic Keys.............................................12 7. Cryptographic Algorithms......................................14
5.3. MKT Properties...........................................13 7.1. MAC Algorithms...........................................14
6. Per-Connection TCP-AO Parameters..............................14 7.2. Key Derivation Functions.................................17
7. Cryptographic Algorithms......................................15 7.3. Traffic Key Establishment and Duration Issues............21
7.1. MAC Algorithms...........................................15 7.3.1. MKT Reuse Across Socket Pairs.......................21
7.2. Key Derivation Functions.................................18 7.3.2. MKTs Use Within a Long-lived Connection.............22
7.3. Traffic Key Establishment and Duration Issues............22 8. Additional Security Mechanisms................................22
7.3.1. MKT Reuse Across Socket Pairs.......................22 8.1. Coordinating Use of New MKTs.............................22
7.3.2. MKTs Use Within a Long-lived Connection.............23 8.2. Preventing replay attacks within long-lived connections..23
8. Additional Security Mechanisms................................23 9. TCP-AO Interaction with TCP...................................25
8.1. Coordinating Use of New MKTs.............................23 9.1. TCP User Interface.......................................26
8.2. Preventing replay attacks within long-lived connections..24 9.2. TCP States and Transitions...............................27
9. TCP-AO Interaction with TCP...................................26 9.3. TCP Segments.............................................27
9.1. TCP User Interface.......................................27 9.4. Sending TCP Segments.....................................28
9.2. TCP States and Transitions...............................28 9.5. Receiving TCP Segments...................................29
9.3. TCP Segments.............................................28 9.6. Impact on TCP Header Size................................31
9.4. Sending TCP Segments.....................................29 10. Obsoleting TCP MD5 and Legacy Interactions...................32
9.5. Receiving TCP Segments...................................30 11. Interactions with Middleboxes................................32
9.6. Impact on TCP Header Size................................32 11.1. Interactions with non-NAT/NAPT Middleboxes..............33
10. Obsoleting TCP MD5 and Legacy Interactions...................33 11.2. Interactions with NAT/NAPT Devices......................33
11. Interactions with Middleboxes................................33 12. Evaluation of Requirements Satisfaction......................33
11.1. Interactions with non-NAT/NAPT Middleboxes..............34 13. Security Considerations......................................39
11.2. Interactions with NAT/NAPT Devices......................34 14. IANA Considerations..........................................41
12. Evaluation of Requirements Satisfaction......................34 15. References...................................................42
13. Security Considerations......................................40 15.1. Normative References....................................42
14. IANA Considerations..........................................42 15.2. Informative References..................................43
15. References...................................................43 16. Acknowledgments..............................................44
15.1. Normative References....................................43
15.2. Informative References..................................44
16. Acknowledgments..............................................45
1. Contributors 1. Contributors
This document evolved as the result of collaboration of the TCP This document evolved as the result of collaboration of the TCP
Authentication Design team (tcp-auth-dt), whose members were Authentication Design team (tcp-auth-dt), whose members were
(alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy,
Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy
Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus
Westerlund. The text of this document is derived from a proposal by Westerlund. The text of this document is derived from a proposal by
Joe Touch and Allison Mankin [To06] (originally from June 2006), Joe Touch and Allison Mankin [To06] (originally from June 2006),
skipping to change at page 4, line 28 skipping to change at page 4, line 28
giving the ability to move from one key to another within the same giving the ability to move from one key to another within the same
connection. It does not however provide for complete cryptographic connection. It does not however provide for complete cryptographic
key management to be handled in-band of TCP, because TCP SYN segments key management to be handled in-band of TCP, because TCP SYN segments
lack sufficient remaining space to handle such a negotiation (see lack sufficient remaining space to handle such a negotiation (see
Section 9.6). This document obsoletes the TCP MD5 option with a more Section 9.6). This document obsoletes the TCP MD5 option with a more
general TCP Authentication Option (TCP-AO), to support the use of general TCP Authentication Option (TCP-AO), to support the use of
other, stronger hash functions, provide replay protection for long- other, stronger hash functions, provide replay protection for long-
lived connections and across repeated instances of a single lived connections and across repeated instances of a single
connection, coordinate key changes between endpoints, and to provide connection, coordinate key changes between endpoints, and to provide
a more structured recommendation on external key management. The a more structured recommendation on external key management. The
result is compatible with IPv6, and is fully compatible with result is compatible with IPv6, and is fully compatible with proposed
requirements under development for a replacement for TCP MD5 [Be07]. requirements for a replacement for TCP MD5 [Be07].
This document is not intended to replace the use of the IPsec suite This document is not intended to replace the use of the IPsec suite
(IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In (IPsec and IKE) to protect TCP connections [RFC4301][RFC4306]. In
fact, we recommend the use of IPsec and IKE, especially where IKE's fact, we recommend the use of IPsec and IKE, especially where IKE's
level of existing support for parameter negotiation, session key level of existing support for parameter negotiation, session key
negotiation, or rekeying are desired. TCP-AO is intended for use only negotiation, or rekeying are desired. TCP-AO is intended for use only
where the IPsec suite would not be feasible, e.g., as has been where the IPsec suite would not be feasible, e.g., as has been
suggested is the case to support some routing protocols, or in cases suggested is the case to support some routing protocols, or in cases
where keys need to be tightly coordinated with individual transport where keys need to be tightly coordinated with individual transport
sessions [Be07]. sessions [Be07].
skipping to change at page 5, line 15 skipping to change at page 5, line 15
o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND).
o TCP-AO allows TCP MD5 to continue to be used concurrently for o TCP-AO allows TCP MD5 to continue to be used concurrently for
legacy connections. legacy connections.
o TCP-AO replaces MD5's single MAC algorithm with MACs specified in o TCP-AO replaces MD5's single MAC algorithm with MACs specified in
a separate document and can be extended to include other MACs. a separate document and can be extended to include other MACs.
o TCP-AO allows rekeying during a TCP connection, assuming that an o TCP-AO allows rekeying during a TCP connection, assuming that an
out-of-band protocol or manual mechanism provides the new keys. out-of-band protocol or manual mechanism provides the new keys.
The option includes a key ID which allows the efficient concurrent The option includes a 'key ID' which allows the efficient
use of multiple keys, and a key coordination mechanism using a concurrent use of multiple keys, and a key coordination mechanism
next key ID manages the key change within a connection. Note that using a 'receive next key ID' manages the key change within a
TCP MD5 does not preclude rekeying during a connection, but does connection. Note that TCP MD5 does not preclude rekeying during a
not require its support either. Further, TCP-AO supports key connection, but does not require its support either. Further,
changes with zero packet loss, whereas key changes in TCP MD5 can TCP-AO supports key changes with zero segment loss, whereas key
lose packets in transit during the changeover or require trying changes in TCP MD5 can lose segments in transit during the
multiple keys on each received segment during key use overlap changeover or require trying multiple keys on each received
because it lacks an explicit key ID. segment during key use overlap because it lacks an explicit key
ID. Although TCP recovers lost segments through retransmission,
loss can have a substantial impact on performance.
o TCP-AO provides automatic replay protection for long-lived o TCP-AO provides automatic replay protection for long-lived
connections using sequence number extensions. connections using sequence number extensions.
o TCP-AO ensures per-connection traffic keys as unique as the TCP o TCP-AO ensures per-connection traffic keys as unique as the TCP
connection itself, using TCP's initial sequence numbers (ISNs) for connection itself, using TCP's initial sequence numbers (ISNs) for
differentiation, even when static master key tuples are used differentiation, even when static master key tuples are used
across repeated instances of connections on a single socket pair. across repeated instances of connections on a single socket pair.
o TCP-AO specifies the details of how this option interacts with o TCP-AO specifies the details of how this option interacts with
skipping to change at page 6, line 15 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 Version
[NOTE: to be omitted upon final publication as RFC; full changelist
available from the authors]
2.2.1. New in draft-ietf-tcp-auth-opt-07
o Change PRF to KDF throughout to coordinate with ao-crypto
2.2.2. New in draft-ietf-tcp-auth-opt-06
o Items from Stockholm IETF meeting
o Unify MAC and KDF function notation with ao-crypto.
o Clarify that options are not included in TCP's advertised MSS.
o Clarify that segments not matching MKTs should be silently
accepted. See Section 9.5 for details.
o Clarify that MKTs can be used to derive 4 traffic keys, not
that all are always actually derived.
o Emphasize that the KeyIDs MAY be the same in both directions.
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 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.
skipping to change at page 7, line 44 skipping to change at page 7, line 6
| | | |
+---------------------------------------+ +---------------------------------------+
| | | |
+-------------------+-------------------+ +-------------------+-------------------+
| | | |
+-------------------+ +-------------------+
Figure 1 The TCP MD5 Option [RFC2385] Figure 1 The TCP MD5 Option [RFC2385]
In the TCP MD5 option, the length is fixed, and the MD5 digest In the TCP MD5 option, the length is fixed, and the MD5 digest
occupies 16 bytes following the Kind and Length fields, using the occupies 16 bytes following the Kind and Length fields (each one
full MD5 digest of 128 bits [RFC1321]. byte), using the full MD5 digest of 128 bits [RFC1321].
The TCP MD5 option specifies the use of the MD5 digest calculation The TCP MD5 option specifies the use of the MD5 digest calculation
over the following values in the following order: over the following values in the following order:
1. The TCP pseudoheader (IP source and destination addresses, 1. The IP pseudoheader (IP source and destination addresses, protocol
protocol number, and segment length). number, and segment length).
2. The TCP header excluding options and checksum. 2. The TCP header excluding options and checksum.
3. The TCP data payload. 3. The TCP data payload.
4. 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
skipping to change at page 8, line 30 skipping to change at page 7, line 40
+------------+------------+------------+------------+ +------------+------------+------------+------------+
| 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 fields as follows:
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. When both options appear, TCP MUST silently
discard the segment.
>> 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.
When multiple TCP-AO options appear, TCP MUST discard the segment.
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, RNextKeyID, 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. When the
Length value is less than 4, TCP MUST discard the segment.
>> 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.
When the Length value is invalid, TCP MUST discard the segment.
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
MAC fields of very short length) are of dubious utility but are MAC fields of very short length) are of dubious utility but are
not specifically prohibited. not specifically prohibited.
o KeyID: An unsigned 1-byte field indicating the MKT used to o KeyID: An unsigned 1-byte field indicating the MKT used to
generate the traffic keys which were used to generate the MAC that generate the traffic keys which were used to generate the MAC that
authenticates this segment. authenticates this segment.
It supports efficient key changes during a connection and/or to It supports efficient key changes during a connection and/or to
help with key coordination during connection establishment, to be help with key coordination during connection establishment, to be
discussed further in Section 8.1. Note that the KeyID has no discussed further in Section 8.1. Note that the KeyID has no
cryptographic properties - it need not be random, nor are there cryptographic properties - it need not be random, nor are there
any reserved values. any reserved values.
>> KeyID values MAY be the same in both directions of a >> KeyID values MAY be the same in both directions of a
connection, but do not have to be and there is no special meaning connection, but do not have to be and there is no special meaning
when they are. when they are.
o RNextKeyID: An unsigned 1-byte field indicating the MKT that the o RNextKeyID: An unsigned 1-byte field indicating the MKT that the
sender is ready use to receive authenticated packets, i.e., the sender is ready use to receive authenticated segments, i.e., the
desired 'receive next' keyID. desired 'receive next' keyID.
It supports efficient key change coordination, to be discussed It supports efficient key change coordination, to be discussed
further in Section 8.1. Note that the RNextKeyID has no further in Section 8.1. Note that the RNextKeyID has no
cryptographic properties - it need not be random, nor are there cryptographic properties - it need not be random, nor are there
any reserved values. 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 are 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 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 maximum segment size (MSS), as is the case for all TCP options
[Bo09]. [Bo09].
skipping to change at page 11, line 6 skipping to change at page 10, line 6
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, RNextKeyID). 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 RNextKeyID of a TCP-AO o IDs. The values used in the KeyID or RNextKeyID of a TCP-AO
option; used to differentiate MKTs in concurrent use, as well as option; used to differentiate MKTs in concurrent use (KeyID), as
to indicate when MKTs are ready for use. well as to indicate when MKTs are ready for use in the opposite
direction (RNextKeyID).
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 11, line 34 skipping to change at page 10, line 35
o Master key. A byte sequence used for generating traffic keys, this o Master key. A byte sequence used for generating traffic keys, this
may be derived from a separate shared key by an external protocol may be derived from a separate shared key by an external protocol
over a separate channel. This sequence is used in the traffic key over a separate channel. This sequence is used in the traffic key
generation algorithm described in Section 7.2. generation algorithm described in Section 7.2.
Implementations are advised to keep master key values in a Implementations are advised to keep master key values in a
private, protected area of memory or other storage. private, protected area of memory or other storage.
o Key Derivation Function (KDF). Indicates the key derivation o Key Derivation Function (KDF). Indicates the key derivation
function and its parameters, as used to generate traffic keys from function and its parameters, as used to generate traffic keys from
master keys. Explained further in Section 7.1 [ao-crypto]. master keys. Explained further in Section 7.1 of this document and
specified in detail in [ao-crypto].
o Message Authentication Code (MAC) algorithm. Indicates the MAC o Message Authentication Code (MAC) algorithm. Indicates the MAC
algorithm and its parameters as used for this connection, algorithm and its parameters as used for this connection,
explained further in Section 7.1 [ao-crypto]. explained further in Section 7.1 of this document and specified in
detail in [ao-crypto].
>> Components of a MKT MUST NOT change during a connection. >> Components of a MKT MUST NOT change during a connection.
MKT component values cannot change during a connection because TCP MKT component values cannot change during a connection because TCP
state is coordinated during connection establishment. TCP lacks a state is coordinated during connection establishment. TCP lacks a
handshake for modifying that state after a connection has been handshake for modifying that state after a connection has been
established. established.
>> The set of MKTs MAY change during a connection. >> The set of MKTs MAY change during a connection.
skipping to change at page 12, line 26 skipping to change at page 11, line 29
5.2. Traffic Keys 5.2. Traffic Keys
A traffic key is a key derived from the MKT and the properties of a A traffic key is a key derived from the MKT and the properties of a
connection. For established connections, these properties include the connection. For established connections, these properties include the
socket pair (local IP address, local TCP port, remote IP address, socket pair (local IP address, local TCP port, remote IP address,
remote port), and the TCP Initial Sequence Numbers (ISNs) in each remote port), and the TCP Initial Sequence Numbers (ISNs) in each
direction. Segments exchanged before a connection is established use direction. Segments exchanged before a connection is established use
the same information, substituting zero for unknown values (e.g., the same information, substituting zero for unknown values (e.g.,
ISNs not yet coordinated). ISNs not yet coordinated).
A single MKT derives four different MKTs: A single MKT can be used to derive any of four different MKTs:
o Send_SYN_traffic_key o Send_SYN_traffic_key
o Receive_SYN_traffic_key o Receive_SYN_traffic_key
o Send_other_traffic_key o Send_other_traffic_key
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 unidirectional. A given connection typically
only three of these keys, because only one of the SYN keys is uses 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
can be used to derive any of the four traffic keys, but only the keys can be used to derive any of the four traffic keys, but only the keys
actually needed to handle the segments of a connection need to be actually needed to handle the segments of a connection need to be
computed. Section 7.2 provides further details on how traffic keys computed. Section 7.2 provides further details on how traffic keys
are derived. are derived.
skipping to change at page 13, line 40 skipping to change at page 12, line 40
match occurs, TCP-AO is not used. Multiple MKTs may match a single match occurs, TCP-AO is not used. Multiple MKTs may match a single
outgoing segment, e.g., when MKTs are being changed. Those MKTs outgoing segment, e.g., when MKTs are being changed. Those MKTs
cannot have conflicting IDs (as noted elsewhere), and some mechanism cannot have conflicting IDs (as noted elsewhere), and some mechanism
must determine which MKT to use for each given outgoing segment. must determine which MKT to use for each given outgoing segment.
>> An outgoing TCP segment MUST match at most one desired MKT, >> An outgoing TCP segment MUST match at most one desired MKT,
indicated by the segment's socket pair. The segment MAY match indicated by the segment's socket pair. The segment MAY match
multiple MKTs, provided that exactly one MKT is indicated as desired. multiple MKTs, provided that exactly one MKT is indicated as desired.
Other information in the segment MAY be used to determine the desired Other information in the segment MAY be used to determine the desired
MKT when multiple MKTs match; such information MUST NOT include MKT when multiple MKTs match; such information MUST NOT include
values in TCP option fields. values in any TCP option fields.
We recommend that the mechanism used to select from among multiple We recommend that the mechanism used to select from among multiple
MKTs use only information that TCP-AO would authenticate. Because MKTs use only information that TCP-AO would authenticate. Because
MKTs may indicate that non-TCP-AO options are ignored in the MAC MKTs may indicate that non-TCP-AO options are ignored in the MAC
calculation, we recommend that TCP options should not be used to calculation, we recommend that TCP options should not be used to
determine MKTs. determine MKTs.
>> An incoming TCP segment containing the TCP-AO option MUST match at >> An incoming TCP segment containing the TCP-AO option MUST match at
exactly one MKT, indicated solely by the segment's socket pair and exactly one MKT, indicated solely by the segment's socket pair and
its TCP-AO KeyID. its TCP-AO KeyID.
skipping to change at page 15, line 29 skipping to change at page 14, 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:
MAC = MAC_alg(traffic_key, data_block) MAC = MAC_alg(traffic_key, message)
INPUT: MAC_alg, traffic_key, data_block INPUT: MAC_alg, traffic_key, message
OUTPUT: MAC OUTPUT: MAC
where: where:
o MAC_alg - the specific MAC algorithm used for this computation. o MAC_alg - the specific MAC algorithm used for this computation.
The MAC algorithm specifies the output length, so no separate The MAC algorithm specifies the output length, so no separate
output length parameter is required. This is specified as output length parameter is required. This is specified as
described in [ao-crypto]. described 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 Message - 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 IP 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
parameters provided. parameters provided.
At the time of this writing, the algorithms' definitions for use in At the time of this writing, the algorithms' definitions for use in
TCP-AO, as described in [ao-crypto] are each truncated to 96 bits. TCP-AO, as described in [ao-crypto] are each truncated to 96 bits.
Though the algorithms each output a larger MAC, 96 bits provides a Though the algorithms each output a larger MAC, 96 bits provides a
reasonable tradeoff between security and message size, for fitting reasonable tradeoff between security and message size, for fitting
into the TCP-AO header. Though could change in the future, so TCP-AO into the TCP-AO header. Though could change in the future, so TCP-AO
skipping to change at page 16, line 45 skipping to change at page 15, line 45
| SNE | | SNE |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 4 Sequence number extension Figure 4 Sequence number extension
The SNE for transmitted segments is maintained locally in the The SNE for transmitted segments is maintained locally in the
SND.SNE value; for received segments, a local RCV.SNE value is SND.SNE value; for received segments, a local RCV.SNE value is
used. The details of how these values are maintained and used is used. The details of how these values are maintained and used is
described in Sections 8.2, 9.4, and 9.5. described in Sections 8.2, 9.4, and 9.5.
2. The TCP pseudoheader: IP source and destination addresses, 2. The IP pseudoheader: IP source and destination addresses, protocol
protocol number and segment length, all in network byte order, number and segment length, all in network byte order, prepended to
prepended to the TCP header below. The pseudoheader is exactly as the TCP header below. The IP pseudoheader is exactly as used for
used for the TCP checksum in either IPv4 or IPv6 the TCP checksum in either IPv4 or IPv6 [RFC793][RFC2460]:
[RFC793][RFC2460]:
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Proto | TCP Length | | zero | Proto | TCP Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 5 TCP IPv4 pseudoheader [RFC793] Figure 5 TCP IPv4 pseudoheader [RFC793]
skipping to change at page 17, line 33 skipping to change at page 16, line 33
+ + + +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
+ + + +
| | | |
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Upper-Layer Packet Length | | Upper-Layer Payload Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Next Header | | zero | Next Header |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 6 TCP IPv6 pseudoheader [RFC2460] Figure 6 TCP IPv6 pseudoheader [RFC2460]
3. The TCP header, by default including options, and where the TCP 3. The TCP header, by default including options, and where the TCP
checksum and TCP-AO MAC fields are set to zero, all in network checksum and TCP-AO MAC fields are set to zero, all in network
byte order. byte order.
skipping to change at page 18, line 30 skipping to change at page 17, 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:
traffic_key = KDF_alg(master_key, data_block, output_length) traffic_key = KDF_alg(master_key, context, output_length)
INPUT: KDF_alg, master_key, data_block, output_length INPUT: KDF_alg, master_key, context, output_length
OUTPUT: traffic_key OUTPUT: traffic_key
where: where:
o KDF_alg - the specific key derivation function (KDF) that is the o KDF_alg - the specific key derivation function (KDF) that is the
basic building block used in constructing the traffic key, as basic building block used in constructing the traffic key, as
indicated in the MKT. This is specified as described in [ao- indicated in the MKT. This is specified as described in [ao-
crypto]. 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 Data_block - The data block used as input in constructing the o Context - The context used as input in constructing the
traffic_key. The data block provided by TCP-AO is used as the traffic_key, as specified in [ao-crypto]. The specific way this
"context" as specified in [ao-crypto]. The specific way this
context is used, in conjunction with other information, to create context is used, in conjunction with other information, to create
the raw input to the KDF is also explained further in [ao-crypto]. the raw input to the KDF is also explained further in [ao-crypto].
o Output_length - The desired output length of the KDF, i.e., the o Output_length - The desired output length of the KDF, i.e., the
length to which the KDF's output will be truncated. This is length to which the KDF's output will be truncated. This is
specified as described in [ao-crypto]. specified as described in [ao-crypto].
o Traffic_key - The desired output of the KDF, of length o Traffic_key - The desired output of the KDF, of length
output_length, to be used as input to the MAC algorithm, as output_length, to be used as input to the MAC algorithm, as
described in Section 7.1. described in Section 7.1.
The data used as input to the KDF combines TCP socket pair with the The context used as input to the KDF combines TCP socket pair with
endpoint initial sequence numbers (ISNs) of a connection. This the endpoint initial sequence numbers (ISNs) of a connection. This
provides context unique to each TCP connection instance, which data is unique to each TCP connection instance, which enables TCP-AO
enables TCP-AO to generate unique traffic keys for that connection, to generate unique traffic keys for that connection, even from a MKT
even from a MKT used across many different connections or across used across many different connections or across repeated connections
repeated connections that share a socket pair. Unique traffic keys that share a socket pair. Unique traffic keys are generated without
are generated without relying on external key management properties. relying on external key management properties. The KDF context is
This data block is defined in Figure 7 and Figure 8. defined in Figure 7 and Figure 8.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Port | Dest. Port | | Source Port | Dest. Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source ISN | | Source ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Dest. ISN | | Dest. ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 7 Data block for an IPv4 connection Figure 7 KDF Context for an IPv4 connection
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+ + + +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 20, line 29 skipping to change at page 19, line 29
+ + + +
| | | |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Port | Dest. Port | | Source Port | Dest. Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source ISN | | Source ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Dest. ISN | | Dest. ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 8 Data block for an IPv6 connection Figure 8 KDF Context for an IPv6 connection
Traffic keys are directional, so "source" and "destaination" are Traffic keys are directional, so "source" and "destination" are
interpreted differently for incoming and outgoing segments. For interpreted differently for incoming and outgoing segments. For
incoming packets, source is the remote side, whereas for outgoing incoming segments, source is the remote side, whereas for outgoing
packets source is the local side. This further ensures that segments source is the local side. This further ensures that
connection keys generated for each direction are unique. connection keys generated for each direction are unique.
For SYN segments (segments with the SYN set, but the ACK not set), For SYN segments (segments with the SYN set, but the ACK not set),
the destination ISN is not known. For these segments, the connection the destination ISN is not known. For these segments, the connection
key is computed using the connection block shown above, in which the key is computed using the context shown above, in which the
Destination ISN value is zero. For all other segments, the ISN pair Destination ISN value is zero. For all other segments, the ISN pair
is used when known. If the ISN pair is not known, e.g., when sending is used when known. If the ISN pair is not known, e.g., when sending
a RST after a reboot, the segment should be sent without a RST after a reboot, the segment should be sent without
authentication; if authentication was required, the segment cannot authentication; if authentication was required, the segment cannot
have been MAC'd properly anyway and would have been dropped on have been MAC'd properly anyway and would have been dropped on
receipt. receipt.
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination
ISN of zero (whether sent or received); all other segments use the ISN of zero (whether sent or received); all other segments use the
known ISN pair. known ISN pair.
skipping to change at page 22, line 29 skipping to change at page 21, line 29
We encourage users of TCP-AO to apply known techniques for generating We encourage users of TCP-AO to apply known techniques for generating
appropriate MKTs, including the use of reasonable master key lengths, appropriate MKTs, including the use of reasonable master key lengths,
limited traffic key sharing, and limiting the duration of MKT use limited traffic key sharing, and limiting the duration of MKT use
[RFC3562]. This also includes the use of per-connection nonces, as [RFC3562]. This also includes the use of per-connection nonces, as
suggested in Section 7.2. suggested in Section 7.2.
TCP-AO supports rekeying in which new MKTs are negotiated and TCP-AO supports rekeying in which new MKTs are negotiated and
coordinated out-of-band, either via a protocol or a manual procedure coordinated out-of-band, either via a protocol or a manual procedure
[RFC4808]. New MKT use is coordinated using the out-of-band mechanism [RFC4808]. New MKT use is coordinated using the out-of-band mechanism
to update both TCP endpoints. When only a single MKT is used at a to update both TCP endpoints. When only a single MKT is used at a
time, the temporary use of invalid MKTs could result in packets being time, the temporary use of invalid MKTs could result in segments
dropped; although TCP is already robust to such drops, TCP-AO uses being dropped; although TCP is already robust to such drops, TCP-AO
the KeyID field to avoid such drops. A given connection can have uses the KeyID field to avoid such drops. A given connection can have
multiple matching MKTs, where the KeyID field is used to identify the multiple matching MKTs, where the KeyID field is used to identify the
MKT that corresponds to the traffic key used for a segment, to avoid MKT that corresponds to the traffic key used for a segment, to avoid
the need for expensive trial-and-error testing of MKTs in sequence. the need for expensive trial-and-error testing of MKTs in sequence.
TCP-AO provides an explicit MKT coordination mechanism, described in TCP-AO provides an explicit MKT coordination mechanism, described in
Section 8.1. Such a mechanism is useful when new MKTs are installed, Section 8.1. Such a mechanism is useful when new MKTs are installed,
or when MKTs are changed, to determine when to commence using or when MKTs are changed, to determine when to commence using
installed MKTs. installed MKTs.
Users are advised to manage MKTs following the spirit of the advice Users are advised to manage MKTs following the spirit of the advice
skipping to change at page 24, line 22 skipping to change at page 23, line 22
the segment sender to indicate a ready incoming MKT for future the segment sender to indicate a ready incoming MKT for future
segments it receives, so that the segment receiver can know when to segments it receives, so that the segment receiver can know when to
switch MKTs (and thus their KeyIDs and associated traffic keys). It switch MKTs (and thus their KeyIDs and associated traffic keys). It
indicates the RecvID of 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 (RNext_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 Rnext_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).
Next_key is changed only by manual user intervention or MKT Rnext_key is changed only by manual user intervention or MKT
management protocol operation. It is not manipulated by TCP-AO. management protocol operation. It is not manipulated by TCP-AO.
Current_key is updated by TCP-AO when processing received TCP Current_key is updated by TCP-AO when processing received TCP
segments as discussed in the segment processing description in segments as discussed in the segment processing description in
Section 9.5. Note that the algorithm allows the current_key to change Section 9.5. Note that the algorithm allows the current_key to change
to a new MKT, then change back to a previously used MKT (known as to a new MKT, then change back to a previously used MKT (known as
"backing up"). This can occur during a MKT change when segments are "backing up"). This can occur during a MKT change when segments are
received out of order, and is considered a feature of TCP-AO, because received out of order, and is considered a feature of TCP-AO, because
reordering does not result in drops. The only way to avoid reuse of reordering does not result in drops. The only way to avoid reuse of
previously used MKTs is to remove the MKT when it is no longer previously used MKTs is to remove the MKT when it is no longer
considered permitted. considered permitted.
skipping to change at page 25, line 48 skipping to change at page 24, line 48
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 (in C-like When a segment is received, the following algorithm (in C-like
pseudocode) computes the SNE used in the MAC; an equivalent algorithm pseudocode) computes the SNE used in the MAC; this is the "RCV" side,
can be applied to the "SND" side: and an equivalent algorithm 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 26, line 31 skipping to change at page 25, line 31
/* save the current SEQ for the next time through the code */ /* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ; RCV.PREV_SEQ = SEG.SEQ;
In the above code, the first line when the sequence number first In the above code, the first line when the sequence number first
rolls over, i.e., when the new number is low (in the bottom half of rolls over, i.e., when the new number is low (in the bottom half of
the number space) and the old number is high (in the top half of the the number space) and the old number is high (in the top half of the
number space). The first time this happens, the SNE is incremented number space). The first time this happens, the SNE is incremented
and a flag is set. and a flag is set.
If the flag is set and a high number is seen, it must be a reordered If the flag is set and a high number is seen, it must be a reordered
packet, so use the pre-increment SNE, otherwise use the current SNE. segment, so use the pre-increment SNE, otherwise use the current SNE.
The flag will be cleared by the time the number rolls all the way The flag will be cleared by the time the number rolls all the way
around. around.
The flag prevents the SNE from being incremented again until the flag The flag prevents the SNE from being incremented again until the flag
is reset, which happens in the middle of the window (when the old is reset, which happens in the middle of the window (when the old
number is in the bottom half and the new is in the top half). Because number is in the bottom half and the new is in the top half). Because
the receive window is never larger than half of the number space, it the receive window is never larger than half of the number space, it
is impossible to both set and reset the flag at the same time - is impossible to both set and reset the flag at the same time -
outstanding packets, regardless of reordering, cannot straddle both outstanding segments, regardless of reordering, cannot straddle both
regions simultaneously. regions simultaneously.
9. TCP-AO Interaction with TCP 9. TCP-AO Interaction with TCP
The following is a description of how TCP-AO affects various TCP The following is a description of how TCP-AO affects various TCP
states, segments, events, and interfaces. This description is states, segments, events, and interfaces. This description is
intended to augment the description of TCP as provided in RFC-793, intended to augment the description of TCP as provided in RFC-793,
and its presentation mirrors that of RFC-793 as a result [RFC793]. and its presentation mirrors that of RFC-793 as a result [RFC793].
9.1. TCP User Interface 9.1. TCP User Interface
skipping to change at page 27, line 39 skipping to change at page 26, line 39
>> 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 (RNextKeyID) is changes (KeyID) or when a new preferred MKT (RNextKeyID) is
indicated; these changes immediately affect all subsequent outgoing indicated; these changes immediately affect all subsequent outgoing
segments: 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 rnext_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 RNextKeyID 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:
skipping to change at page 29, line 5 skipping to change at page 27, line 50
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.
For outgoing segments, this occurs before computation of the TCP For outgoing segments, this occurs before computation of the TCP
checksum. checksum.
Note that the TCP-AO option is not negotiated. It is the Note that use of the TCP-AO option is not negotiated within TCP. It
responsibility of the receiver to determine when TCP-AO is required is the responsibility of the receiver to determine when TCP-AO is
and to enforce that requirement. required via other means (e.g., out of band, manually or with an key
management protocol) and to enforce that requirement.
9.4. Sending TCP Segments 9.4. Sending TCP Segments
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment departs. TCP-AO when a segment departs.
>> Note that TCP-AO MUST be the last TCP option processed on outgoing >> Note that TCP-AO MUST be the last TCP option processed on outgoing
segments, because its MAC calculation may include the values of other segments, because its MAC calculation may include the values of other
TCP options. TCP options.
skipping to change at page 30, line 5 skipping to change at page 29, 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 RNextKeyID as indicated by the Rnext_key d. Determine the RNextKeyID as indicated by the rnext_key
pointer, and insert it in the TCP-AO option (using the pointer, and insert it in the TCP-AO option (using the
next_key MKT's RecvID as the TCP-AO KeyID) (as noted in rnext_key MKT's RecvID as the TCP-AO KeyID) (as noted in
Section 8.1). 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 32, line 13 skipping to change at page 31, line 13
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
validation algorithm that verifies the fixed value before investing validation algorithm that verifies the fixed value before investing
in the computed portion. Such optimizations would be contained in the in the computed portion. Such optimizations would be contained in the
MAC algorithm specification, and thus are not specified in TCP-AO MAC algorithm specification, and thus are not specified in TCP-AO
explicitly. Note that the KeyID cannot be used for connection explicitly. Note that the KeyID cannot be used for connection
validation per se, because it is not assumed random. validation per se, because it is not assumed random.
9.6. Impact on TCP Header Size 9.6. Impact on TCP Header Size
The TCP-AO option typically uses a total of 17-19 bytes of TCP header The TCP-AO option, using the initially required 96-bit MACs, uses a
space. TCP-AO is no larger than and typically 3 bytes smaller than total of 16 bytes of TCP header space [ao-crypto]. TCP-AO is thus 2
the TCP MD5 option (assuming a 96-bit MAC). bytes smaller than the TCP MD5 option (18 bytes).
Note that TCP option space is most critical in SYN segments, because Note that TCP option space is most critical in SYN segments, because
flags in those segments could potentially increase the option space flags in those segments could potentially increase the option space
area in other segments. Because TCP ignores unknown segments, area in other segments. Because TCP ignores unknown segments,
however, it is not possible to extend the option space of SYNs however, it is not possible to extend the option space of SYNs
without breaking backward-compatibility. without breaking backward-compatibility.
TCP's 4-bit data offset requires that the options end 60 bytes (15 TCP's 4-bit data offset requires that the options end 60 bytes (15
32-bit words) after the header begins, including the 20-byte header. 32-bit words) after the header begins, including the 20-byte header.
This leaves 40 bytes for options, of which 15 are expected in current This leaves 40 bytes for options, of which 15 are expected in current
implementations (listed below), leaving at most 25 for other uses. implementations (listed below), leaving at most 25 for other uses.
Assuming a 96-bit MAC, TCP-AO consumes 16 bytes, leaving up to 9 TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options
bytes for additional SYN options (depending on implementation (depending on implementation dependant alignment padding, which could
dependant alignment padding, which could consume another 2 bytes at consume another 2 bytes at most).
most).
o SACK permitted (2 bytes) [RFC2018][RFC3517] o SACK permitted (2 bytes) [RFC2018][RFC3517]
o Timestamps (10 bytes) [RFC1323] o Timestamps (10 bytes) [RFC1323]
o Window scale (3 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323]
After a SYN, the following options are expected in current After a SYN, the following options are expected in current
implementations of TCP: implementations of TCP:
o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883] o SACK (10bytes) [RFC2018][RFC3517] (18 bytes if D-SACK [RFC2883])
o Timestamps (10 bytes) [RFC1323] o Timestamps (10 bytes) [RFC1323]
TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a
total of 24 bytes for other options, of which the timestamp consumes total of 24 bytes for other options, of which the timestamp consumes
10. This leaves 14 bytes, of which 10 are used for a single SACK 10. This leaves 14 bytes, of which 10 are used for a single SACK
block. When two SACK blocks are used, such as to handle D-SACK, a block. When two SACK blocks are used, such as to handle D-SACK, a
smaller TCP-AO MAC would be required to make room for the additional smaller TCP-AO MAC would be required to make room for the additional
SACK block (i.e., to leave 18 bytes for the D-SACK variant of the SACK block (i.e., to leave 18 bytes for the D-SACK variant of the
SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP- SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP
MD5 in the presence of timestamps, because TCP MD5's MAC length is MD5 in the presence of timestamps, because TCP MD5's MAC length is
fixed and too large to leave sufficient option space. fixed and too large to leave sufficient option space.
Although TCP option space is limited, we believe TCP-AO is consistent Although TCP option space is limited, we believe TCP-AO is consistent
with the desire to authenticate TCP at the connection level for with the desire to authenticate TCP at the connection level for
similar uses as were intended by TCP MD5. similar uses as were intended by TCP MD5.
10. Obsoleting TCP MD5 and Legacy Interactions 10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier: TCP-AO obsoletes TCP MD5. As we have noted earlier:
skipping to change at page 35, line 5 skipping to change at page 34, line 5
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.
This is supported - see Section 7.1. This is supported - see Section 7.1.
a. TCP pseudoheader, including IPv4 and IPv6 versions. a. IP pseudoheader, including IPv4 and IPv6 versions.
Note that we do not allow optional coverage because IP Note that we do not allow optional coverage because IP
addresses define a connection. If they can be coordinated addresses define a connection. If they can be coordinated
across a NAT/NAPT, the sender can compute the MAC based on the across a NAT/NAPT, the sender can compute the MAC based on the
received values; if not, a tunnel is required, as noted in received values; if not, a tunnel is required, as noted in
Section 11.2. Section 11.2.
b. TCP header. b. TCP header.
Note that we do not allow optional port coverage because ports Note that we do not allow optional port coverage because ports
skipping to change at page 35, line 47 skipping to change at page 34, line 47
The option should not unnecessarily expose information about The option should not unnecessarily expose information about
the TCP-AO mechanism. The additional protection afforded by the TCP-AO mechanism. The additional protection afforded by
keeping this information private may be of little value, but keeping this information private may be of little value, but
also helps keep the option size small. also helps keep the option size small.
TCP-AO exposes only the MKT IDs, MAC, and overall option TCP-AO exposes only the MKT IDs, MAC, and overall option
length on the wire. Note that short MACs could be obscured by length on the wire. Note that short MACs could be obscured by
using longer option lengths but specifying a short MAC length using longer option lengths but specifying a short MAC length
(this is equivalent to a different MAC algorithm, and is (this is equivalent to a different MAC algorithm, and is
specified in the TAPD entry). See Section 4.2. specified in the MKT). See Section 4.2.
b. Allow optional per connection. b. Allow optional per connection.
The option should not be required on every connection; it The option should not be required on every connection; it
should be optional on a per connection basis. should be optional on a per connection basis.
This is supported because the set of MKTs can be installed to This is supported because the set of MKTs can be installed to
match some connections and not others. Connections not match some connections and not others. Connections not
matching any MKT do not require TCP-AO. Further, incoming matching any MKT do not require TCP-AO. Further, incoming
segments containing the TCP-AO option are not discarded solely segments containing the TCP-AO option are not discarded solely
skipping to change at page 36, line 41 skipping to change at page 35, line 41
This is supported - see Section 4.2. This is supported - see Section 4.2.
e. Compatible with Large Windows and SACK. e. Compatible with Large Windows and SACK.
The option should be compatible with the use of the Large The option should be compatible with the use of the Large
Windows and SACK options. Windows and SACK options.
This is supported - see Section 9.6. The size of the option is This is supported - see Section 9.6. The size of the option is
intended to allow use with Large Windows and SACK. See also intended to allow use with Large Windows and SACK. See also
Section 2.1, which indicates that TCP-AO is 3 bytes shorter Section 2.1, which indicates that TCP-AO is 2 bytes shorter
than TCP MD5 in the default case, assuming a 96-bit MAC. than TCP MD5 in the default case, assuming a 96-bit MAC.
3. Cryptography requirements 3. Cryptography requirements
A solution to revising TCP MD5 should support modern cryptography A solution to revising TCP MD5 should support modern cryptography
capabilities. capabilities.
a. Baseline defaults. a. Baseline defaults.
The option should have a default that is required in all The option should have a default that is required in all
skipping to change at page 41, line 48 skipping to change at page 40, line 48
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
is intended to be similar to how IPsec would handle those messages is intended to be similar to how IPsec would handle those messages
[RFC4301]. [RFC4301].
TCP-AO includes the TCP connection ID (the socket pair) in the MAC TCP-AO includes the TCP connection ID (the socket pair) in the MAC
calculation. This prevents different concurrent connections using the calculation. This prevents different concurrent connections using the
same MKT (for whatever reason) from potentially enabling a traffic- same MKT (for whatever reason) from potentially enabling a traffic-
crossing attack, in which segments to one socket pair are diverted to crossing attack, in which segments to one socket pair are diverted to
attack a different socket pair. When multiple connections use the attack a different socket pair. When multiple connections use the
same MKT, it would be useful to know that packets intended for one ID same MKT, it would be useful to know that segments intended for one
could not be (maliciously or otherwise) modified in transit and end ID could not be (maliciously or otherwise) modified in transit and
up being authenticated for the other ID. That requirement would place end up being authenticated for the other ID. That requirement would
an additional burden of uniqueness on MKTs within endsystems, and place an additional burden of uniqueness on MKTs within endsystems,
potentially across endsystems. Although the resulting attack is low and potentially across endsystems. Although the resulting attack is
probability, the protection afforded by including the received ID low probability, the protection afforded by including the received ID
warrants its inclusion in the MAC, and does not unduly increase the warrants its inclusion in the MAC, and does not unduly increase the
MAC calculation or MKT management. MAC calculation or MKT management.
The use of any security algorithm can present an opportunity for a The use of any security algorithm can present an opportunity for a
CPU DOS attack, where the attacker sends false, random segments that CPU DOS attack, where the attacker sends false, random segments that
the receiver under attack expends substantial CPU effort to reject. the receiver under attack expends substantial CPU effort to reject.
In IPsec, such attacks are reduced by the use of a large Security In IPsec, such attacks are reduced by the use of a large Security
Parameter Index (SPI) and Sequence Number fields to partly validate Parameter Index (SPI) and Sequence Number fields to partly validate
segments before CPU cycles are invested validated the Integrity Check segments before CPU cycles are invested validated the Integrity Check
Value (ICV). In TCP-AO, the socket pair performs most of the function Value (ICV). In TCP-AO, the socket pair performs most of the function
skipping to change at page 43, line 45 skipping to change at page 42, line 45
for TCP", RFC-2883, Proposed Standard, July 2000. for TCP", RFC-2883, Proposed Standard, July 2000.
[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., E. Rescorla, "Cryptographic Algorithms for
Implementation Requirments for TCP Authentication Option", TCP's Authentication Option, TCP-AO", draft-ietf-tcpm-tcp-
draft-ietf-tcpm-tcp-ao-crypto-01, Oct. 2009. ao-crypto-02, Oct. 2009.
15.2. Informative References 15.2. Informative References
[ao-nat] Touch, J., "A TCP Authentication Option NAT Extension," [ao-nat] Touch, J., "A TCP Authentication Option NAT Extension,"
draft-touch-tcp-ao-nat-00, Oct. 2009. 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.
 End of changes. 57 change blocks. 
173 lines changed or deleted 142 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/