draft-ietf-tcpm-tcp-auth-opt-04.txt   draft-ietf-tcpm-tcp-auth-opt-05.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: September 2009 R. Bonica Expires: January 2010 R. Bonica
Juniper Networks Juniper Networks
March 9, 2009 July 3, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-04.txt draft-ietf-tcpm-tcp-auth-opt-05.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 September 9, 2009. This Internet-Draft will expire on January 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies the TCP Authentication Option (TCP-AO), which This document specifies the TCP Authentication Option (TCP-AO), which
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
specifies the use of stronger Message Authentication Codes (MACs), specifies the use of stronger Message Authentication Codes (MACs),
protects against replays even for long-lived TCP connections, and protects against replays even for long-lived TCP connections, and
provides more details on the association of security with TCP provides more details on the association of security with TCP
connections than TCP MD5. TCP-AO is compatible with either static connections than TCP MD5. TCP-AO is compatible with either static
master key configuration or an external, out-of-band master key 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 master key across repeated instances connections when using the same MKT across repeated instances of a
of a connection, using traffic keys derived from the master key, and connection, using traffic keys derived from the MKT, and coordinates
coordinates key changes between endpoints. The result is intended to MKT changes between endpoints. The result is intended to support
support current infrastructure uses of TCP MD5, such as to protect current infrastructure uses of TCP MD5, such as to protect long-lived
long-lived connections (as used, e.g., in BGP and LDP), and to connections (as used, e.g., in BGP and LDP), and to support a larger
support a larger set of MACs with minimal other system and set of MACs with minimal other system and operational changes. TCP-AO
operational changes. TCP-AO uses its own option identifier, even uses its own option identifier, even though used mutually exclusive
though used mutually exclusive of TCP MD5 on a given TCP connection. of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is
TCP-AO supports IPv6, and is fully compatible with the requirements fully compatible with the requirements for the replacement of TCP
for the replacement of TCP MD5. MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Introduction...................................................3
2.1. Executive Summary.........................................4 2.1. Executive Summary.........................................4
2.2. Changes from Previous Versions............................6 2.2. Changes from Previous Versions............................6
2.2.1. New in draft-ietf-tcp-auth-opt-04....................6 2.2.1. New in draft-ietf-tcp-auth-opt-05....................6
2.2.2. New in draft-ietf-tcp-auth-opt-03....................6 3. Conventions used in this document..............................7
2.2.3. New in draft-ietf-tcp-auth-opt-02....................7 4. The TCP Authentication Option..................................7
2.2.4. New in draft-ietf-tcp-auth-opt-01....................8 4.1. Review of TCP MD5 Option..................................8
2.2.5. New in draft-ietf-tcp-auth-opt-00....................9 4.2. The TCP-AO Option.........................................8
2.2.6. New in draft-touch-tcp-simple-auth-03................9 5. TCP-AO Keys and Their Properties..............................10
2.2.7. New in draft-touch-tcp-simple-auth-02...............10 5.1. Master Key Tuple.........................................10
2.2.8. New in draft-touch-tcp-simple-auth-01...............10 5.2. Traffic Keys.............................................12
3. Conventions used in this document.............................10 5.3. MKT Properties...........................................13
4. The TCP Authentication Option.................................11 6. Per-Connection TCP-AO Parameters..............................14
4.1. Review of TCP MD5 Option.................................11 7. Cryptographic Algorithms......................................15
4.2. The TCP-AO Option........................................11 7.1. MAC Algorithms...........................................15
5. The TCP-AO Activation and Parameter Database..................13 7.2. Key Derivation Functions.................................18
6. Per-Connection Parameters.....................................16 7.3. Traffic Key Establishment and Duration Issues............22
7. Cryptographic Algorithms......................................17 7.3.1. MKT Reuse Across Socket Pairs.......................22
7.1. MAC Algorithms...........................................17 7.3.2. MKTs Use Within a Long-lived Connection.............23
7.2. Key Derivation Functions.................................21 8. Additional Security Mechanisms................................23
7.3. Traffic Key Establishment and Duration Issues............24 8.1. Coordinating MKT Changes.................................23
7.3.1. Master Key Reuse Across Socket Pairs................25 8.2. Preventing replay attacks within long-lived connections..24
7.3.2. Master Key Use Within a Long-lived Connection.......25 9. TCP-AO Interaction with TCP...................................26
8. Additional Security Mechanisms................................25 9.1. TCP User Interface.......................................27
8.1. Coordinating KeyID Changes...............................25 9.2. TCP States and Transitions...............................28
8.2. Preventing replay attacks within long-lived connections..26 9.3. TCP Segments.............................................28
9. TCP-AO Interaction with TCP...................................28 9.4. Sending TCP Segments.....................................28
9.1. TCP User Interface.......................................29 9.5. Receiving TCP Segments...................................30
9.2. TCP States and Transitions...............................30 9.6. Impact on TCP Header Size................................32
9.3. TCP Segments.............................................30 10. Obsoleting TCP MD5 and Legacy Interactions...................33
9.4. Sending TCP Segments.....................................31 11. Interactions with Middleboxes................................33
9.5. Receiving TCP Segments...................................32 11.1. Interactions with non-NAT/NAPT Middleboxes..............34
9.6. Impact on TCP Header Size................................34 11.2. Interactions with NAT/NAPT Devices......................34
10. Obsoleting TCP MD5 and Legacy Interactions...................35 12. Evaluation of Requirements Satisfaction......................34
11. Interactions with Middleboxes................................36 13. Security Considerations......................................40
11.1. Interactions with non-NAT/NAPT Middleboxes..............36 14. IANA Considerations..........................................42
11.2. Interactions with NAT/NAPT Devices......................36 15. References...................................................43
12. Evaluation of Requirements Satisfaction......................36 15.1. Normative References....................................43
13. Security Considerations......................................42 15.2. Informative References..................................44
14. IANA Considerations..........................................44 16. Acknowledgments..............................................45
15. References...................................................45
15.1. Normative References....................................45
15.2. Informative References..................................46
16. Acknowledgments..............................................47
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),
which was both inspired by and intended as a counterproposal to the which was both inspired by and intended as a counterproposal to the
revisions to TCP MD5 suggested in a document by Ron Bonica, Brian revisions to TCP MD5 suggested in a document by Ron Bonica, Brian
Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07]
(originally from Sept. 2005) and in a document by Brian Weis [We05]. (originally from Sept. 2005) and in a document by Brian Weis [We05].
Russ Housley suggested L4/application layer management of the TAPD. Russ Housley suggested L4/application layer management of the master
Steve Bellovin motivated the KeyID field. Eric Rescorla suggested the key tuples. Steve Bellovin motivated the KeyID field. Eric Rescorla
use of ISNs in the traffic key computation and ESNs to avoid replay suggested the use of ISNs in the traffic key computation and SNEs to
attacks, and Brian Weis extended the computation to incorporate the avoid replay attacks, and Brian Weis extended the computation to
entire connection ID and provided the details of the traffic key incorporate the entire connection ID and provided the details of the
computation. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ traffic key computation. Mark Allman, Wes Eddy, Lars Eggert, Ted
Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe
Brian Weis developed the key coordination mechanism. Touch, and Brian Weis developed the master key coordination
mechanism.
2. Introduction 2. Introduction
The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates The TCP MD5 Signature (TCP MD5) is a TCP option that authenticates
TCP segments, including the TCP IPv4 pseudoheader, TCP header, and TCP segments, including the TCP IPv4 pseudoheader, TCP header, and
TCP data. It was developed to protect BGP sessions from spoofed TCP TCP data. It was developed to protect BGP sessions from spoofed TCP
segments which could affect BGP data or the robustness of the TCP segments which could affect BGP data or the robustness of the TCP
connection itself [RFC2385][RFC4953]. connection itself [RFC2385][RFC4953].
There have been many recent concerns about TCP MD5. Its use of a There have been many recent concerns about TCP MD5. Its use of a
skipping to change at page 5, line 11 skipping to change at page 5, line 6
2.1. Executive Summary 2.1. Executive Summary
This document replaces TCP MD5 as follows [RFC2385]: This document replaces TCP MD5 as follows [RFC2385]:
o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND). o TCP-AO uses a separate option Kind for TCP-AO (TBD-IANA-KIND).
o TCP-AO allows TCP MD5 to continue to be used 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 allows extension 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. In out-of-band protocol or manual mechanism provides the new keys.
such cases, a key ID allows the efficient concurrent use of The option includes a key ID which allows the efficient concurrent
multiple keys, and a key coordination mechanism manages the key use of multiple keys, and a key coordination mechanism using a
change within a connection. Note that TCP MD5 does not preclude next key ID manages the key change within a connection. Note that
rekeying during a connection, but does not require its support TCP MD5 does not preclude rekeying during a connection, but does
either. Further, TCP-AO supports key changes with zero packet not require its support either. Further, TCP-AO supports key
loss, whereas key changes in TCP MD5 can lose packets in transit changes with zero packet loss, whereas key changes in TCP MD5 can
during the changeover or require trying multiple keys on each lose packets in transit during the changeover or require trying
received segment during key use overlap because it lacks an multiple keys on each received segment during key use overlap
explicit key ID. because it lacks an explicit key ID.
o TCP-AO provides automatic replay protection for long-lived o TCP-AO provides automatic replay protection for long-lived
connections using an extended sequence number. 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 ISNs for differentiation, even when connection itself, using TCP's initial sequence numbers (ISNs) for
static master keys are used across repeated instances of a socket differentiation, even when static master key tuples are used
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
TCP's states, event processing, and user interface. TCP's states, event processing, and user interface.
o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes o The TCP-AO option is 2 bytes shorter than TCP MD5 (16 bytes
overall, rather than 18) in the default case (using a 96-bit MAC). overall, rather than 18) in the initially specified default case
(using a 96-bit MAC).
This document differs from an IPsec/IKE solution in that TCP-AO as This document differs from an IPsec/IKE solution in that TCP-AO as
follows [RFC4301][RFC4306]: follows [RFC4301][RFC4306]:
o TCP-AO does not support dynamic parameter negotiation. o TCP-AO does not support dynamic parameter negotiation.
o TCP-AO uses TCP's socket pair (source address, destination o TCP-AO uses TCP's socket pair (source address, destination
address, source port, destination port) as a security parameter address, source port, destination port) as a security parameter
index, rather than using a separate field as a primary index index, rather than using a separate field as an index (IPsec's
(IPsec's SPI). SPI).
o TCP-AO forces a change of computed MACs when a connection o TCP-AO forces a change of computed MACs when a connection
restarts, even when reusing a TCP socket pair (IP addresses and restarts, even when reusing a TCP socket pair (IP addresses and
port numbers) [Be07]. port numbers) [Be07].
o TCP-AO does not support encryption. o TCP-AO does not support encryption.
o TCP-AO does not authenticate ICMP messages (some ICMP messages may o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated via IPsec, depending on the configuration). be authenticated when using IPsec, depending on the
configuration).
2.2. Changes from Previous Versions 2.2. Changes from Previous Versions
[NOTE: to be omitted upon final publication as RFC] [NOTE: to be omitted upon final publication as RFC]
2.2.1. New in draft-ietf-tcp-auth-opt-04 2.2.1. New in draft-ietf-tcp-auth-opt-05
o Major revision to the document structure, including renaming the
TSAD to TAPD.
o Added a key change coordination mechanism in Section 8.1.
o Added a requirement for symmetric use of TCP-AO, required for the
key change coordination mechanism. This includes an update of the
TAPD to indicate that all master keys are bidirectional.
o Augmented the discussion of the available space for options.
o Fixed a bug in the ESN algorithm.
o Adds a text referring to the TCP-AO cryptography companion
document.
o Changed RFC-TBD to ao-crypto (until the RFC number is assigned).
2.2.2. New in draft-ietf-tcp-auth-opt-03
o Added a placeholder to discuss key change coordination in Section
8.1.
o Moved discussion of required MAC algorithms and PRF to a separate
document, indicated as RFC-TBD until assigned. Included the PRF in
the TSAD master key tuple so that TCP-AO is PRF algorithm agile,
and updated general PRF input format.
o Revised the description the TSAD and impact to the TCP user
interface. Removed the description of the TSAD API. Access to the
API is assumed specific to the implementation, and not part of the
protocol specification.
o Clarified the different uses of the term key; includes master key
(from the TSAD) and connection key (per-connection key, derived
from the master via the PRF).
o Explained the ESN pseudocode operation in detail.
o Added a contributors section up front.
o Update discussion of requirements to be sufficiently stand-alone;
update list to correlate more directly to Be07 (so that Be07 can
be dropped from consideration for publication).
o Provided detail on size of typical options (motivating a small
option).
o Confirmed WG consensus on IETF-72 topic - no algorithm ID and T-
bit (options excluded) locations in the header.
o Confirmed WG consensus on IETF-72 topic - no additional header
bits for in-band key change signaling (the "K" bit from [Bo07]).
2.2.3. New in draft-ietf-tcp-auth-opt-02
o List issue - Replay Protection: incorporated extended sequence
number space, not using KeyID space.
o List issue - Unique Connection Keys: ISNs are used to generate
unique connection keys even when static keys used for repeated
instances of a socket pair.
o List issue - Header Format and Alignment: Moved KeyID to front.
o List issue - Reserved KeyID Value: Suggestion to reserve a single
KeyID value for implementation optimization received no support on
the WG list, so this was not changed.
o List issue - KeyID Randomness: KeyIDs are not assumed random; a
note was added that nonce-based filtering should be done on a
portion of the MAC (incorporated into the algorithm), and that
header fields should not be assumed to have cryptographic
properties (e.g., randomness).
o List issue - Support for NATs: preliminary rough consensus
suggests that TCP-AO should not be augmented to support NAT
traversal. Existing mechanisms for such traversal (UDP support)
can be applied, or IPsec NAT traversal is recommended in such
cases instead.
o IETF-72 topic - providing algorithm ID and T-bit (options
excluded) locations in the header: (No current consensus was
reached on this topic, so no change was made.)
o IETF-72 topic - providing additional header bits for in-band key
change signaling (draft-bonica's "K" bit): (No current consensus
was reached on this topic, so no change was made.)
o Clarified TCP-AO as obsoleting TCP MD5.
o Clarified the MAC Type as referring to the IANA registry of IKEv2
transforms, not the RFC establishing that registry.
o Added citation to the Wang/Yu paper regarding attacks on MD5 Wa05
to replace reports in Be05 and Bu06.
o Explained why option exclusion can't be changed during a
connection.
o Clarified that AO explicitly allows rekeying during a TCP
connection, without impacting packet loss.
o Described TCP-AO's interaction with reboots more clearly, and
explained the need to clear out old state that persists
indefinitely.
2.2.4. New in draft-ietf-tcp-auth-opt-01
o Require KeyID in all versions. Remove odd/even indicator of KeyID
usage.
o Relax restrictions on key reuse: requiring an algorithm for nonce
introduction based on ISNs, and suggest key rollover every 2^31
bytes (rather than using an extended sequence number, which
introduces new state to the TCP connection).
o Clarify NAT interaction; currently does not support omitting the
IP addresses or TCP ports, both of which would be required to
support NATs without any coordination. This appears to present a
problem for key management - if the key manager knows the received
addrs and ports, it should coordinate them (as indicated in Sec
8).
o Options are included or excluded all-or-none. Excluded options are
deleted, not just zeroed, to avoid the impact of reordering or
length changes of such options.
o Augment replay discussion in security considerations.
o Revise discussion of IKEv2 MAC algorithm names.
o Remove executive summary comparison to expired documents.
o Clarified key words to exclude lower case usage.
2.2.5. New in draft-ietf-tcp-auth-opt-00
o List of TBD values, and indication of how each is determined.
o Changed TCP-SA to TCP-AO (removed 'simple' throughout).
o Removed proposed NAT mechanism; cited RFC-3947 NAT-T as
appropriate approach instead.
o Made several changes coordinated in the TCP-AUTH-DT as follow:
o Added R. Bonica as co-author. o Summary of changes:
o Use new TCP option Kind in the core doc. o Remove TSAD; replace with discussion of MKTs directly.
o Addresses the impact of explicit declines on security. o Change most references of IDs to refer to MKTs directly.
o Add limits to TSAD size (2 <= TSAD <= 256). o Update and minimize interface to [crypto-ao].
o Allow 0 as a legitimate KeyID. o Removed "what's new" going back more than one version (full
changelist available from the authors)
o Allow the WG to determine the two appropriate required MAC o Issue tracker responses (http://tools.ietf.org/wg/tcpm/):
algorithms.
o Add TO-DO items. o 1 Confusion between master & traffic keys, and key-ids. Done.
o Added discussion at end of Introduction as to why TCP MD5 o 2 Clarify relationship between master and traffic keys - use
connections cannot be upgraded to TCP-AO. diagram given. Done.
2.2.6. New in draft-touch-tcp-simple-auth-03 o 3 TSAD concept - Removed.
o Added support for NAT/NAPT. o 4 Option flag description - Removed 0/1 values.
o Added support for IPv6. o 5 TAPD details - TAPD removed.
o Added discussion of how this proposal satisfies requirements under o 6 KeyId versus master key - Current_key now points to a MKT,
development, including those indicated in [Be07]. not an ID.
o Clarified the byte order of all data used in the MAC. o 7 ESN versus SNE - Used "sequence number extension" rather
than "extended sequence number".
o Changed the TCP option exclusion bit from a bit to a list. o 8 "typically" in traffic key storage - Replaced with 'can be'.
2.2.7. New in draft-touch-tcp-simple-auth-02 o 9 MAC truncation & padding - Removed / refers only to existing
components of [crypto-ao].
o Add reference to Bellovin's need-for-TCP-auth doc [Be07]. o 10 SYN traffic keys - explain directionality and that typically
only one is needed. Done.
o Add reference to SP4 [SDNS88]. o 11 Master key for LISTEN - (TAPD issue) Removed with TAPD
removal.
o Added notes that TSAD to be externally implemented; this was o 15 Text clarifying traffic keys (related to issues 1,2) -
compatible with the TSAD described in the previous version. Done in Section 5.2.
o Augmented the protocol to allow a KeyID, required to support o 16 Text for key coordination - Not inserted, since based on
efficient overlapping keys during rekeying, and potentially useful behavior that was decided against in the WG meeting (e.g.,
during connection establishment. Accommodated by redesigning the that installing keys makes them preferred, that 2MSL forces
TSAD. keys out of use altogether, and that endpoints sync key
changes).
o Added the odd/even indicator for the KeyID. o Items from SFO IETF meeting
o Allow for the exclusion of all TCP options in the MAC calculation. o 1. TCP-AO key coordination allows 'backup'
2.2.8. New in draft-touch-tcp-simple-auth-01 o 2. Clarify names for key entities (issues 1,2)
o Allows intra-session rekeying, assuming out-of-band coordination. o 3. Address the timers (part of bugtrack item 5)
o MUST allow TSAD entries to change, enabling rekeying within a TCP o 4. Move TAPD to the appendix (issues 3, 5) - removed.
connection.
o Omits discussion of the impact of connection reestablishment on o Other issues raised on the list:
BGP, because added support for rekeying renders this point moot.
o Adds further discussion on the need for rekeying. o ICMP handling - already does as IPsec does. No changes made.
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 12, line 5 skipping to change at page 9, line 5
4. A key. 4. A key.
4.2. The TCP-AO Option 4.2. The TCP-AO Option
The new TCP-AO option provides a superset of the capabilities of TCP The new TCP-AO option provides a superset of the capabilities of TCP
MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new MD5, and is minimal in the spirit of SP4 [SDNS88]. TCP-AO uses a new
Kind field, and similar Length field to TCP MD5, a KeyID field, and a Kind field, and similar Length field to TCP MD5, a KeyID field, and a
NextKeyID field as shown in Figure 2. NextKeyID field as shown in Figure 2.
+----------+----------+----------+----------+ +-----------+-----------+-----------+-----------+
| Kind | Length | KeyID | NextKeyID| | Kind | Length | KeyID | NextKeyID|
+----------+----------+----------+----------+ +-----------+-----------+-----------+-----------+
| MAC ... | MAC ...
+----------------------------------... +-----------------------------------...
...-----------------+ ...-----------------+
... MAC (con't) | ... MAC (con't) |
...-----------------+ ...-----------------+
Figure 2 The TCP-AO Option Figure 2 The TCP-AO Option
The TCP-AO defines the following fields: The TCP-AO defines the following fields:
o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP- o Kind: An unsigned 1-byte field indicating the TCP-AO Option. TCP-
skipping to change at page 12, line 36 skipping to change at page 9, line 36
o Length: An unsigned 1-byte field indicating the length of the TCP- o Length: An unsigned 1-byte field indicating the length of the TCP-
AO option in bytes, including the Kind, Length, KeyID, NextKeyID, AO option in bytes, including the Kind, Length, KeyID, NextKeyID,
and MAC fields. and MAC fields.
>> The Length value MUST be greater than or equal to 4. >> The Length value MUST be greater than or equal to 4.
>> The Length value MUST be consistent with the TCP header length; >> The Length value MUST be consistent with the TCP header length;
this is a consistency check and avoids overrun/underrun abuse. this is a consistency check and avoids overrun/underrun abuse.
Values of 4 and other small values are of dubious utility but are Values of 4 and other small values larger than 4 (e.g., indicating
not specifically prohibited. MACs of very short length) are of dubious utility but are not
specifically prohibited.
o KeyID: An unsigned 1-byte field used to support efficient key o KeyID: An unsigned 1-byte field used to support efficient key
changes during a connection and/or to help with key coordination changes during a connection and/or to help with key coordination
during connection establishment, to be discussed further in during connection establishment, to be discussed further in
Section 8.1. Note that the KeyID has no cryptographic properties - Section 8.1. Note that the KeyID has no cryptographic properties -
it need not be random, nor are there any reserved values. it need not be random, nor are there any reserved values.
o NextKeyID: An unsigned 1-byte field used to support efficient key o NextKeyID: An unsigned 1-byte field used to support efficient key
change coordination, to be discussed further in Section 8.1. Note change coordination, to be discussed further in Section 8.1. Note
that the NextKeyID has no cryptographic properties - it need not that the NextKeyID has no cryptographic properties - it need not
skipping to change at page 13, line 22 skipping to change at page 10, line 22
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).
The remainder of this document explains how the TCP-AO option is The remainder of this document explains how the TCP-AO option is
handled and its relationship to TCP. handled and its relationship to TCP.
5. The TCP-AO Activation and Parameter Database 5. TCP-AO Keys and Their Properties
TCP-AO relies on a TCP-AO Activation and Parameter Database (TAPD), TCP-AO relies on a two sets of keys to authenticate incoming and
which indicates whether a TCP connection requires TCP-AO, and its outgoing segments: master key tuples (MKTs) and traffic keys. MKTs
parameters when so. TAPD entries are assumed to exist at the are used to derive unique traffic keys, and include the keying
endpoints where TCP-AO is used, in advance of the connection, and material used to generate those traffic keys, as well as indicating
consist of the following: the associated parameters under which traffic keys are used. Such
parameters include whether TCP options are authenticated, and
indicators of the algorithms used for traffic key derivation and MAC
calculation. Traffic keys are the keying material used to compute the
MAC of individual TCP segments.
1. TCP connection identifier (ID), i.e., socket pair - IP source 5.1. Master Key Tuple
address, IP destination address, TCP source port, and TCP
destination port [RFC793]. TAPD entries are uniquely determined by
their TCP connection ID, which is used to index those entries. A
TAPD entry may allow wildcards, notably in the source port value.
>> There MUST be no more than one matching TAPD entry per A Master Key Tuple (MKT) describes TCP-AO properties to be associated
direction for a fully-instantiated (no wildcards) TCP connection with one or more connections. It is composed of the following:
ID.
2. A TCP option flag. When 0, this flag allows default operation, o TCP connection identifier. A TCP socket pair, i.e., a local IP
i.e., TCP options are included in the MAC calculation, with TCP- address, a remote IP address, a TCP local port, and a TCP remote
AO's MAC field zeroed out. When 1, all options (excluding TCP-AO) port. Values can be partially specified using ranges (e.g., 2-30),
are excluded from all MAC calculations (skipped over, not simply masks (e.g., 0xF0), wildcards (e.g., "*"), or any other suitable
zeroed). The option flag applies to TCP options in both directions indication.
(incoming and outgoing segments).
>> The TCP option flag MUST NOT change during a TCP connection. o TCP option flag. This flag indicates whether TCP options other
than TCP-AO are included in the MAC calculation. When options are
included, the content of all options, in the order present, are
included in the MAC, with TCP-AO's MAC field zeroed out. When the
options are not included, all options other than TCP-AO are
excluded from all MAC calculations (skipped over, not zeroed).
Note that TCP-AO, with its MAC field zeroed out, is always
included in the MAC calculation, regardless of the setting of this
flag; this protects the indication of the MAC length as well as
the key ID fields (KeyID, NextKeyID). The option flag applies to
TCP options in both directions (incoming and outgoing segments).
The TCP option flag cannot change during a connection because TCP o IDs. The values used in the KeyID or NextKeyID of a TCP-AO option;
used to differentiate MKTs in concurrent use, as well as to
indicate when MKTs are ready for use.
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,
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
described further in Section 9.4 and 9.5.
>> MKT IDs MUST support any value, 0-255 inclusive. There are no
reserved ID values.
ID values are assigned arbitrarily. They can be assigned in
sequence, or based on any method mutually agreed by the connection
endpoints (e.g., using an external MKT management mechanism).
>> IDs MUST NOT be assumed to be randomly assigned.
o Master key. A byte sequence used for generating traffic keys, this
may be derived from a separate shared key by an external protocol
over a separate channel. This sequence is used in the traffic key
generation algorithm described in Section 7.2.
Implementations are advised to keep master key values in a
private, protected area of memory or other storage.
o Key Derivation Function (KDF). Indicates the key derivation
function and its parameters, as used to generate traffic keys from
master keys. Explained further in Section 7.1 [ao-crypto].
o Message Authentication Code (MAC) algorithm. Indicates the MAC
algorithm and its parameters as used for this connection,
explained further in Section 7.1 [ao-crypto].
>> Components of a MKT MUST NOT change during a connection.
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.
3. A list of zero or more master key tuples. >> The set of MKTs MAY change during a connection.
>> Components of a TAPD master key tuple MUST NOT change during a MKT parameters are not changed. Instead, new MKTs can be installed,
connection. and a connection can change which MKT it uses.
Keeping the tuple components static ensures that the KeyID >> The IDs of MKTs MUST NOT overlap where their TCP connection
uniquely determines the properties of a packet; this supports use identifiers overlap.
of the KeyID to determine the packet properties.
>> The set of TAPD master key tuples MAY change during a This document does not address how MKTs are created by users or
connection, but KeyIDs of those tuples MUST NOT overlap. I.e., processes. It is presumed that a MKT affecting a particular
tuple parameter changes MUST be accompanied by master key changes. connection cannot be destroyed during an active connection - or,
equivalently, that its parameters are copied to an area local to the
connection (i.e., instantiated) and so changes would affect only new
connections. The MKTs can be managed by a separate application
protocol.
>> If there are multiple tuples in a TAPD entry, then one tuple 5.2. Traffic Keys
MUST be flagged as the preferred key; that key, when instantiated
as a traffic_key, becomes the current_key for the connection (see
Section 6).
Each tuple is defined as the following components: A traffic key is a key derived from the MKT and the properties of a
connection. For established connections, these properties include the
socket pair (local IP address, local TCP port, remote IP address,
remote port), and the TCP Initial Sequence Numbers (ISNs) in each
direction. Segments exchanged before a connection is established use
the same information, substituting zero for unknown values (e.g.,
ISNs not yet coordinated).
a. KeyID. The value as used in the TCP-AO option; used to A single MKT derives four different MKTs:
differentiate master keys in concurrent use, as well as to
indicate when master keys are ready for use.
>> A TAPD implementation MUST support at least two KeyIDs per o Send_SYN_traffic_key
connection per direction, and MAY support up to 256.
>> A KeyID MUST support any value, 0-255 inclusive. There are o Receive_SYN_traffic_key
no reserved KeyID values.
KeyID values are assigned arbitrarily. They can be assigned in o Send_other_traffic_key
sequence, or based on any method mutually agreed by the
connection endpoints (e.g., using an external master key
management mechanism).
>> KeyIDs MUST NOT be assumed to be randomly assigned. o Receive_other_traffic_key
Note that KeyIDs are unique only within a TAPD entry. Note that the keys are directional. A given connection typically 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
'simultaneous open' [RFC793].
b. Master key. A byte sequence used for generating traffic keys, The relationship between MKTs and traffic keys is shown in Figure
this may be derived from a separate shared key by an external Figure 3. Traffic keys are indicated with a "*". Note that every MKT
protocol over a separate channel. This sequence is used in the derives all four traffic keys, regardless of whether all four are
traffic key generation algorithm described in Section 7.2. needed for a given connection. Section 7.2 provides further details
on how traffic keys are derived.
Implementations are advised to keep master key values in a MKT-A MKT-B
private, protected area of memory or other storage. +---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+
| |
+----------+----------+ |
| | |
v v v
Connection 1 Connection 2 Connection 3
+------------------+ +------------------+ +------------------+
| * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key |
| * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
+------------------+ +------------------+ +------------------+
Implementations are also advised to indicate the length of Figure 3 Relationship between MKTs and traffic keys
this key explicitly, because there are no reserved byte
values.
c. MAC algorithm. Indicates the MAC algorithm used for this 5.3. MKT Properties
connection, explained further in Section 7.1 [ao-crypto]. The
MAC_algorithm indicates other properties, such as MAC
truncation, PRF algorithm, and KDF truncation, as explained
further in [ao-crypto]
The TAPD is consulted when new connections are established to TCP-AO requires that every protected TCP segment match exactly one
determine whether TCP-AO is required. MKT. When an outgoing segment matches an MKT, TCP-AO is used. When no
match occurs, TCP-AO is not used. Multiple MKTs may match a single
outgoing segment, e.g., when MKTs are being changed. Those MKTs
cannot have conflicting IDs (as noted elsewhere), and some mechanism
must determine which MKT to use for each given outgoing segment.
>> When a TAPD entry matches a new connection, TCP-AO is required. >> An outgoing TCP segment MUST match at most one desired MKT,
This is true regardless of whether there are any master key tuples indicated by the segment's socket pair. The segment MAY match
present. multiple MKTs, provided that exactly one MKT is indicated as desired.
Other information in the segment MAY be used to determine the desired
MKT when multiple MKTs match; such information MUST NOT include
values in TCP option fields.
>> When TCP-AO is required, the TCP-AO option MUST occur in every We recommend that the mechanism used to select from among multiple
incoming and outgoing TCP segment. In this case, segments lacking the MKTs use only information that TCP-AO would authenticate. Because
TCP-AO option MUST be silently ignored. MKTs may indicate that non-TCP-AO options are ignored in the MAC
calculation, we recommend that TCP options should not be used to
determine MKTs.
For a particular endpoint (i.e., IP address) there would be exactly >> An incoming TCP segment containing the TCP-AO option MUST match at
one TAPD that is consulted by all pending connections, the same way exactly one MKT, indicated solely by the segment's socket pair and
that there is only one table of TCBs (a database can support multiple its TCP-AO KeyID.
endpoints, but an endpoint is represented in only one database).
Multiple databases could be used to support virtual hosts, i.e.,
groups of interfaces.
This document does not address how TAPD entries are created by Incoming segments include an indicator in the TCP-AO option to select
users/processes; it specifies how they must be destroyed from among multiple matching MKTs - the KeyID field. TCP-AO requires
corresponding to connection states, but users/processes may destroy that the KeyID alone be used to differentiate multiple matching MKTs,
entries as well. It is presumed that a TAPD entry affecting a so that MKT changes can be coordinated using the TCP-AO key change
particular connection cannot be destroyed during an active connection coordination mechanism.
- or, equivalently, that its parameters are copied to an area local
to the connection (i.e., instantiated) and so changes would affect
only new connections. The TAPD can be managed by a separate
application protocol.
NOTE: an open issue is whether to require actions when master keys >> When an outgoing TCP segment matches no MKTs, TCP-AO is not used.
are added to the TAPD. In particular, there is a suggestion to force
new added keys to update current_key to the newly added value, and to
set a timer or flag on previous current_key values. If a timer, the
value is unclear (2*MSL isn't appropriate, because we don't know how
long a key changeover may take, and we're not reacting to messages
from the other side). If a flag, this would require that flagged
entries could never be advertised as NextKeyID.
6. Per-Connection Parameters TCP-AO is always used when outgoing segments match an MKT, and is not
used otherwise.
6. Per-Connection TCP-AO Parameters
TCP-AO uses a small number of parameters associated with each TCP-AO uses a small number of parameters associated with each
connection that uses the TCP-AO option, once instantiated. These connection that uses the TCP-AO option, once instantiated. These
values would typically be stored in the Transport Control Block (TCP) values can be stored in the Transport Control Block (TCP) [RFC793].
[RFC793]. These values are explained in subsequent sections of this These values are explained in subsequent sections of this document as
document as noted; they include: noted; they include:
1. Current_key - the KeyID of the master key tuple currently used to 1. Current_key - the MKT currently used to authenticate outgoing
authenticate outgoing segments, inserted in outgoing segments as segments, whose SendID is inserted in outgoing segments as KeyID
KeyID (see Section 9.4, step 5). Incoming segments are (see Section 9.4, step 5). Incoming segments are authenticated
authenticated using the KeyID in the segment's TCP-AO header (see using the MKT corresponding to the segment and the KeyID in its
Section 9.5, step 5). There is only one current_key at any given TCP-AO header (see Section 9.5, step 5), as matched against the
time on a particular connection. MKT TCP connection identifier and the MKT RecvID. There is only
one current_key at any given time on a particular connection.
>> Every connection in a non-IDLE state MUST have exactly one >> Every TCP connection in a non-IDLE state MUST have at most one
current_key value specified. current_key specified.
2. Next_key - the KeyID of the master key tuple currently preferred 2. Next_key -the MKT currently preferred for future use, whose RecvID
for future use, as inserted in outgoing segments as NextKeyID (see is inserted in outgoing segments as NextKeyID (see Section 9.5,
Section 9.5, step 5). step 5).
>> Each connection in a non-IDLE state MUST have exactly one >> Each TCP connection in a non-IDLE state MUST have at most one
next_key value specified. next_key specified.
3. A pair of Extended Sequence Numbers (ESNs). ESNs are used to 3. A pair of Sequence Numbers Extensions (SNEs). SNEs are used to
prevent replay attacks, as described in Section 8.2. Each ESN is prevent replay attacks, as described in Section 8.2. Each SNE is
initialized to zero upon connection establishment. Its use in the initialized to zero upon connection establishment. Its use in the
MAC calculation is described in Section 7.1. MAC calculation is described in Section 7.1.
4. One or more master key tuples. These are all the master key tuples 4. One or more MKTs. These are the MKTs that match this connection's
that match this connection's socket pair in the TAPD. When a new socket pair.
tuple is added to the TAPD, it is added to the TCB of all matching
connections.
Master key tuples are used, together with other parameters of a MKTs are used, together with other parameters of a connection, to
connection, to create traffic keys unique to each connection, as create traffic keys unique to each connection, as described in
described in Section 7.2. These traffic keys can be cached after Section 7.2. These traffic keys can be cached after computation, and
computation, and are typically stored in the TCB with the can be stored in the TCB with the corresponding MKT information. They
corresponding master key tuple information. They can be considered can be considered part of the per-connection parameters.
part of the per-connection parameters.
7. Cryptographic Algorithms 7. Cryptographic Algorithms
TCP-AO also uses cryptographic algorithms to compute the MAC (Message TCP-AO also uses cryptographic algorithms to compute the MAC (Message
Authentication Code) used to authenticate a segment and its headers; Authentication Code) used to authenticate a segment and its headers;
these are called MAC algorithms and are specified in a separate these are called MAC algorithms and are specified in a separate
document to facilitate updating the algorithm requirements document to facilitate updating the algorithm requirements
independently from the protocol [ao-crypto]. TCP-AO also uses independently from the protocol [ao-crypto]. TCP-AO also uses
cryptographic algorithms to convert master keys, which can be shared cryptographic algorithms to convert MKTs, which can be shared across
across connections, into unique traffic keys for each connection. connections, into unique traffic keys for each connection. These are
These are called Key Derivation Functions (KDFs), and are specified called Key Derivation Functions (KDFs), and are specified [ao-
[ao-crypto]. This section describes how these algorithms are used by crypto]. This section describes how these algorithms are used by TCP-
TCP-AO. AO.
7.1. MAC Algorithms 7.1. MAC Algorithms
MAC algorithms take a variable-length input and a key and output a MAC algorithms take a variable-length input and a key and output a
fixed-length number. This number is used to determine whether the fixed-length number. This number is used to determine whether the
input comes from a source with that same key, and whether the input input comes from a source with that same key, and whether the input
has been tampered in transit. MACs for TCP-AO have the following has been tampered in transit. MACs for TCP-AO have the following
interface: interface:
INPUT: MAC_alg, MAC_truncation, traffic_key, data_block INPUT: MAC_alg, MAC_truncation, traffic_key, data_block
skipping to change at page 18, line 15 skipping to change at page 16, line 6
where: where:
o MAC_alg - MAC algorithm used for this computation o MAC_alg - MAC algorithm used for this computation
o MAC_truncation - the number of bytes to truncate the output of the o MAC_truncation - the number of bytes to truncate the output of the
MAC to. This is indicated by the MAC algorithm, as specified in MAC to. This is indicated by the MAC algorithm, as specified in
[ao-crypto]. [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 master key as described in computed from the connection's current MKT as described in Section
Section 7.2. 7.2.
o Data_block - input data over which the MAC is computed. In TCP-AO, o Data_block - input data over which the MAC is computed. In TCP-AO,
this is the TCP segment prepended by the TCP pseudoheader and TCP this is the TCP segment prepended by the TCP pseudoheader and TCP
header options, as described in Section 7.1. header options, as described in Section 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the o MAC - the fixed-length output of the MAC algorithm, given the
parameters provided. If the MAC_alg output is smaller than the parameters provided.
desired MAC_truncation, it is padded with trailing zeroes as
needed.
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, we truncate the Though the algorithms each output a larger MAC, 96 bits provides a
output to 96 bits to provide a reasonable tradeoff between security reasonable tradeoff between security and message size, for fitting
and message size, for fitting into the TCP-AO header. Though could into the TCP-AO header. Though could change in the future, so TCP-AO
change in the future, so TCP-AO header sizes should not be assumed as header sizes should not be assumed as fixed length.
fixed length.
>> To allow a TCP-AO implementation to compute any implicit MAC
algorithm padding required, the specification for each algorithm used
with TCP-AO MUST specify the padding modulus for the algorithm, if
one is required.
The MAC algorithm employed for the MAC computation on any connection The MAC algorithm employed for the MAC computation on a connection is
is done so by policy definition in the TAPD entry, and is chosen from done so by definition in the MKT, per [ao-crypto]'s definitions.
a list of available MACs, where each MAC also infers an underlying
KDF, per [ao-crypto]'s definitions.
The mandatory-to-implement MAC algorithms for use with TCP-AO are The mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [ao-crypto]. This allows the TCP-AO described in a separate RFC [ao-crypto]. This allows the TCP-AO
specification to proceed along the standards track even if changes specification to proceed along the standards track even if changes
are needed to its associated algorithms and their labels (as might be are needed to its associated algorithms and their labels (as might be
used in a user interface or automated master key management protocol) used in a user interface or automated MKT management protocol) as a
as a result of the ever evolving world of cryptography. result of the ever evolving world of cryptography.
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be >> Additional algorithms, beyond those mandated for TCP-AO, MAY be
supported. supported.
The data input to the MAC is the following fields in the following The data input to the MAC is the following fields in the following
sequence, interpreted in network-standard byte order: sequence, interpreted in network-standard byte order:
1. The extended sequence number (ESN), in network-standard byte 1. The sequence number extension (SNE), in network-standard byte
order, as follows (described further in Section 8.2): order, as follows (described further in Section 8.2):
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| ESN | | SNE |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 3 Extended sequence number Figure 4 Sequence number extension
The ESN for transmitted segments is maintained locally in the The SNE for transmitted segments is maintained locally in the
SND.ESN value; for received segments, a local RCV.ESN 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 TCP pseudoheader: IP source and destination addresses,
protocol number and segment length, all in network byte order, protocol number and segment length, all in network byte order,
prepended to the TCP header below. The pseudoheader is exactly as prepended to the TCP header below. The pseudoheader is exactly as
used for the TCP checksum in either IPv4 or IPv6 used for the TCP checksum in either IPv4 or IPv6
[RFC793][RFC2460]: [RFC793][RFC2460]:
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Address | | Source Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Destination Address | | Destination Address |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Proto | TCP Length | | zero | Proto | TCP Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 4 TCP IPv4 pseudoheader [RFC793] Figure 5 TCP IPv4 pseudoheader [RFC793]
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+ + + +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 20, line 27 skipping to change at page 17, line 44
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Upper-Layer Packet Length | | Upper-Layer Packet Length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| zero | Next Header | | zero | Next Header |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 5 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.
When the TCP option flag is 0, the TCP options are included in MAC The TCP option flag of the MKT indicates whether the TCP options
processing, except that the MAC field of the TCP-AO option is are included in the MAC. When included, only the TCP-AO MAC field
zeroed-out. is zeroed.
When the TCP option flag is 1, all TCP options are omitted from
MAC processing, except for the non-MAC portions of the TCP-AO
option. In this case, the following field is used instead of the
options part of the TCP header:
+----------+----------+----------+----------+ When TCP options are not included, all TCP options except for TCP-
| Kind | Length | KeyID | NextKeyID| AO are omitted from MAC processing. Again, the TCP-AO MAC field is
+----------+----------+----------+----------+ zeroed for the MAC processing.
4. The TCP data, i.e., the payload of the TCP segment. 4. The TCP data, i.e., the payload of the TCP segment.
Note that the traffic key is not included as part of the data; the Note that the traffic key is not included as part of the data; the
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
in general [RFC2104][RFC2403]. The traffic key is derived from the [RFC2104][RFC2403]. The traffic key is derived from the current MKT
current master key 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 master key tuples using TCP-AO's traffic keys are derived from the MKTs using Key Derivation
Key Derivation Functions (KDFs). The KDFs used in TCP-AO have the Functions (KDFs). The KDFs used in TCP-AO have the following
following interface: interface:
INPUT: PRF_alg, master_key, output_length, data_block INPUT: PRF_alg, master_key, output_length, data_block
OUTPUT: traffic_key OUTPUT: traffic_key
where: where:
o PRF_alg - the specific pseudorandom function (PRF) that is the o PRF_alg - the specific pseudorandom function (PRF) that is the
basic building block used in constructing the given KDF. This is basic building block used in constructing the given KDF, as
specified by the MAC algorithm as specified in [ao-crypto]. indicated in the MKT. This is specified by the KDF as described in
[ao-crypto].
o Master_key - The master_key string, as will be stored into the o Master_key - The master_key string, as will be stored into the
associated TCP-AO TAPD master key tuple. associated MKT.
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 or padded. In length to which the KDF's output will be truncated. In TCP-AO, the
TCP-AO, the output_length is the PRF_truncation value of the output_length is the PRF_truncation value of the MKT. This is
master key tuple. This is specified by the MAC algorithm as specified by the KDF as described in [ao-crypto].
specified in [ao-crypto].
o Data_block - The data block used as input in constructing the KDF. o Data_block - The data block used as input in constructing the KDF.
The data block provided by TCP-AO is used as the "context" as The data block provided by TCP-AO is used as the "context" as
specified in [ao-crypto]. The specific way this context is used, specified in [ao-crypto]. The specific way this context is used,
in conjunction with other information, to create the raw input to in conjunction with other information, to create the raw input to
the PRF is also explained further in [ao-crypto]. the PRF is also explained further in [ao-crypto].
The data used as input to the KDF combines TCP socket pair with the The data used as input to the KDF combines TCP socket pair with the
endpoint initial sequence numbers (ISNs) of a connection. This endpoint initial sequence numbers (ISNs) of a connection. This
provides context unique to each TCP connection instance, which provides context unique to each TCP connection instance, which
enables TCP-AO to generate unique traffic keys for that connection, enables TCP-AO to generate unique traffic keys for that connection,
even from a master key used across many different connections or even from a MKT used across many different connections or across
across repeated connections that share a socket pair. Unique traffic repeated connections that share a socket pair. Unique traffic keys
keys are generated without relying on external key management are generated without relying on external key management properties.
properties. This data block is defined in Figure 6 and Figure 7. This data block is 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 6 Data block for an IPv4 connection Figure 7 Data block for an IPv4 connection
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+ + + +
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 22, line 44 skipping to change at page 20, line 29
+ + + +
| | | |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source Port | Dest. Port | | Source Port | Dest. Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source ISN | | Source ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Dest. ISN | | Dest. ISN |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 7 Data block for an IPv6 connection Figure 8 Data block for an IPv6 connection
"Source" and "destination" are defined by the direction of the Traffic keys are directional, so "source" and "destaination" are
segment being MAC'd; for incoming packets, source is the remote side, interpreted differently for incoming and outgoing segments. For
whereas for outgoing packets source is the local side. This further incoming packets, source is the remote side, whereas for outgoing
ensures that connection keys generated for each direction are unique. packets source is the local side. This further ensures that
connection keys generated for each direction are unique.
For SYN segments (segments with the SYN set, but the ACK not set), For SYN segments (segments with the SYN set, but the ACK not set),
the destination ISN is not known. For these segments, the 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 connection block shown above, in which the
Destination ISN value is zero. For all other segments, the ISN pair Destination ISN value is zero. For all other segments, the ISN pair
is used when known. If the ISN pair is not known, e.g., when sending is used when known. If the ISN pair is not known, e.g., when sending
a RST after a reboot, the segment should be sent without a RST after a reboot, the segment should be sent without
authentication; if authentication was required, the segment cannot authentication; if authentication was required, the segment cannot
have been MAC'd properly anyway and would have been dropped on have been MAC'd properly anyway and would have been dropped on
receipt. receipt.
>> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination >> TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination
ISN of zero (whether sent or received); all other segments use the ISN of zero (whether sent or received); all other segments use the
known ISN pair. known ISN pair.
Overall, this means that each connection will use up to four distinct Overall, this means that each connection will use up to four distinct
traffic keys for each master key: traffic keys for each MKT:
o Send_SYN_traffic_key - the traffic key used to authenticate o Send_SYN_traffic_key - the traffic key used to authenticate
outgoing SYNs. The source ISN known (the TCP connection's local outgoing SYNs. The source ISN known (the TCP connection's local
ISN), and the destination (remote) ISN is unknown (and so the ISN), and the destination (remote) ISN is unknown (and so the
value 0 is used). value 0 is used).
o Receive_SYN_traffic_key - the traffic key used to authenticate o Receive_SYN_traffic_key - the traffic key used to authenticate
incoming SYNs. The source ISN known (the TCP connection's remote incoming SYNs. The source ISN known (the TCP connection's remote
ISN), and the destination (remote) ISN is unknown (and so the ISN), and the destination (remote) ISN is unknown (and so the
value 0 is used). value 0 is used).
o Send_other_traffic_key - the traffic key used to authenticate all o Send_other_traffic_key - the traffic key used to authenticate all
other outgoing TCP segments. The source ISN is the TCP other outgoing TCP segments.
connection's local ISN, and the destination ISN is the TCP
connection's remote ISN.
o Receive_other_traffic_key - the traffic key used to authenticate o Receive_other_traffic_key - the traffic key used to authenticate
all other incoming TCP segments. The source ISN is the TCP all other incoming TCP segments.
connection's remote ISN, and the destination ISN is the TCP
connection's remote ISN.
The use of both ISNs in the KDF ensures that segments cannot be The following table describes how each of these traffic keys is
replayed across repeated connections reusing the same socket pair computed, where the TCP-AO algorithms refer to source (S) and
(provided the ISN pair does not repeat, which is unlikely because destination (D) values of the IP address, TCP port, and ISN, and each
both endpoints should select ISNs pseudorandomly [RFC1948], their 32- segment (incoming or outgoing) has a values that refer to the local
bit space avoids repeated use except under reboot, and reuse assumes side of the connection (l) and remote side (r):
both sides repeat their use on the same connection).
In general, a SYN would be MAC'd using a destination ISN of zero S-IP S-port S-ISN D-IP D-port D-ISN
(whether sent or received), and all other segments would be MAC'd ----------------------------------------------------------------
using the ISN pair for the connection. There are other cases in which Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
the destination ISN is not known, but segments are emitted, such as Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
after an endpoint reboots, when is possible that the two endpoints Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
would not have enough information to authenticate segments. In such Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN
cases, TCP's timeout mechanism will allow old state to be cleared to
enable new connections, except where the user timeout is disabled; it The use of both ISNs in the traffic key computations ensures that
is important that implementations are capable of detecting excesses segments cannot be replayed across repeated connections reusing the
of TCP connections in such a configuration and can clear them out if same socket pair (provided the ISN pair does not repeat, which is
unlikely because both endpoints should select ISNs pseudorandomly
[RFC1948], their 32-bit space avoids repeated use except under
reboot, and reuse assumes both sides repeat their use on the same
connection).
A SYN is authenticated using a destination ISN of zero (whether sent
or received), and all other segments would be authenticated using the
ISN pair for the connection. There are other cases in which the
destination ISN is not known, but segments are emitted, such as after
an endpoint reboots, when is possible that the two endpoints would
not have enough information to authenticate segments. In such cases,
TCP's timeout mechanism will allow old state to be cleared to enable
new connections, except where the user timeout is disabled; it is
important that implementations are capable of detecting excesses of
TCP connections in such a configuration and can clear them out if
needed to protect its memory usage [Je07]. needed to protect its memory usage [Je07].
7.3. Traffic Key Establishment and Duration Issues 7.3. Traffic Key Establishment and Duration Issues
The TCP-AO option does not provide a mechanism for traffic key The TCP-AO option does not provide a mechanism for traffic key
negotiation or parameter negotiation (MAC algorithm, length, or use negotiation or parameter negotiation (MAC algorithm, length, or use
of the TCP-AO option), or for coordinating rekeying during a of the TCP-AO option), or for coordinating rekeying during a
connection. We assume out-of-band mechanisms for master key connection. We assume out-of-band mechanisms for MKT establishment,
establishment, parameter negotiation, and rekeying. This separation parameter negotiation, and rekeying. This separation of MKT use from
of master key use from master key management is similar to that in MKT management is similar to that in the IPsec security suite
the IPsec security suite [RFC4301][RFC4306]. [RFC4301][RFC4306].
We encourage users of TCP-AO to apply known techniques for generating We encourage users of TCP-AO to apply known techniques for generating
appropriate master keys, including the use of reasonable master key appropriate MKTs, including the use of reasonable master key lengths,
lengths, limited traffic key sharing, and limiting the duration of limited traffic key sharing, and limiting the duration of MKT use
master key use [RFC3562]. This also includes the use of per- [RFC3562]. This also includes the use of per-connection nonces, as
connection nonces, as suggested in Section 7.2. suggested in Section 7.2.
TCP-AO supports rekeying in which new master keys 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 master key use is coordinated using the out-of-band [RFC4808]. New MKT use is coordinated using the out-of-band mechanism
mechanism to update the TAPD at both TCP endpoints. When only a to update both TCP endpoints. When only a single MKT is used at a
single master key is used at a time, the temporary use of invalid time, the temporary use of invalid MKTs could result in packets being
master keys could result in packets being dropped; although TCP is dropped; although TCP is already robust to such drops, TCP-AO uses
already robust to such drops, TCP-AO uses the KeyID field to avoid the KeyID field to avoid such drops. A given connection can have
such drops. The TAPD can contain multiple concurrent master keys, multiple matching MKTs, where the KeyID field is used to identify the
where the KeyID field is used to identify the master key that MKT that corresponds to the traffic key used for a segment, to avoid
corresponds to the traffic key used for a segment, to avoid the need the need for expensive trial-and-error testing of MKTs in sequence.
for expensive trial-and-error testing of master keys in sequence.
TCP-AO provides an explicit key coordination mechanism, described in
Section 8.1. Such a mechanism is useful when new keys are installed,
or when keys are changed, to determine when to commence using
installed keys.
The KeyID field is also useful in coordinating master keys used for TCP-AO provides an explicit MKT coordination mechanism, described in
new connections. A TAPD entry may be configured that matches the Section 8.1. Such a mechanism is useful when new MKTs are installed,
unbound source port, which would return a set of possible master or when MKTs are changed, to determine when to commence using
keys. The KeyID would then indicate the specific master key, allowing installed MKTs.
more efficient connection establishment; otherwise, the master keys
could have been tried in sequence.
Users are advised to manage master keys following the spirit of the Users are advised to manage MKTs following the spirit of the advice
advice for key management when using TCP MD5 [RFC3562], notably to for key management when using TCP MD5 [RFC3562], notably to use
use appropriate key lengths (12-24 bytes) and to avoid sharing master appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among
keys among multiple BGP peering arrangements. This requires that the multiple BGP peering arrangements.
TAPD support monitoring and modification.
7.3.1. Master Key Reuse Across Socket Pairs 7.3.1. MKT Reuse Across Socket Pairs
Master keys can be reused across different socket pairs within a MKTs can be reused across different socket pairs within a host, or
host, or across different instances of a socket pair within a host. across different instances of a socket pair within a host. In either
In either case, replay protection is maintained. case, replay protection is maintained.
Master keys reused across different socket pairs cannot enable replay MKTs reused across different socket pairs cannot enable replay
attacks because the TCP socket pair is included in the MAC, as well attacks because the TCP socket pair is included in the MAC, as well
as in the generation of the traffic key. Master keys reused across as in the generation of the traffic key. MKTs reused across repeated
repeated instances of a given socket pair cannot enable replay instances of a given socket pair cannot enable replay attacks because
attacks because the connection ISNs are included in the traffic key the connection ISNs are included in the traffic key generation
generation algorithm, and ISN pairs are unlikely to repeat over algorithm, and ISN pairs are unlikely to repeat over useful periods.
useful periods.
7.3.2. Master Key Use Within a Long-lived Connection 7.3.2. MKTs Use Within a Long-lived Connection
TCP-AO uses extended sequence numbers (ESNs) to prevent replay TCP-AO uses sequence number extensions (SNEs) to prevent replay
attacks within long-lived connections. Explicit master key rollover, attacks within long-lived connections. Explicit MKT rollover,
accomplished by external means and indexed using the KeyID field, can accomplished by external means and indexed using the KeyID field, can
be used to change keying material for various reasons (e.g., be used to change keying material for various reasons (e.g.,
personnel turnover), but is not required to support long-lived personnel turnover), but is not required to support long-lived
connections. connections.
8. Additional Security Mechanisms 8. Additional Security Mechanisms
TCP-AO adds mechanisms to support efficient use, especially in TCP-AO adds mechanisms to support efficient use, especially in
environments where only manual keying is available. These include the environments where only manual keying is available. These include the
previously described mechanisms for supporting multiple concurrent previously described mechanisms for supporting multiple concurrent
keys (via the KeyID field) and for generating unique per-connection MKTs (via the KeyID field) and for generating unique per-connection
traffic keys (via the KDF). This section describes additional traffic keys (via the KDF). This section describes additional
mechanisms to coordinate KeyID changes and to prevent replay attacks mechanisms to coordinate MKT changes and to prevent replay attacks
when a traffic key is not changed for long periods of time. when a traffic key is not changed for long periods of time.
8.1. Coordinating KeyID Changes 8.1. Coordinating MKT Changes
At any given time, a single TCP connection may have multiple KeyIDs At any given time, a single TCP connection may have multiple MKTs
specified for each segment direction (incoming, outgoing). TCP-AO specified for each segment direction (incoming, outgoing). TCP-AO
provides a mechanism to indicate when a new KeyID is ready, to allow provides a mechanism to indicate when a new MKT is ready, to allow
the sender to commence use of that new KeyID. This supported by using the sender to commence use of that new MKT. This supported by using
two key ID fields in the header: two ID fields in the header:
o KeyID o KeyID
o NextKeyID o NextKeyID
KeyID represents the outgoing keying information used by the segment KeyID represents the outgoing MKT information used by the segment
sender to create the segment's MAC (outgoing), and the corresponding sender to create the segment's MAC (outgoing), and the corresponding
incoming keying information used by the segment receiver to validate incoming keying information used by the segment receiver to validate
that MAC. It indicates the KeyID in active use in that direction. that MAC. It contains the SendID of the MKT in active use in that
direction.
NextKeyID represents the preferred keying information to be used for NextKeyID represents the preferred MKT information to be used for
subsequent segments. I.e., it is a way for the segment sender to subsequent segments. I.e., it is a way for the segment sender to
indicate ready incoming keying information for future segments it indicate a ready incoming MKT for future segments it receives, so
receives, so that the segment receiver can know when to switch that the segment receiver can know when to switch MKTs (and thus
traffic keys (and thus their KeyIDs). their KeyIDs and associated traffic keys). It 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 KeyID (Current_key) o Currently active outgoing MKT (Current_key)
o Current preference for KeyIDs (Next_key) o Current preference for incoming MKT (Next_key)
Current_key points to a KeyID (and associated master key tuple) that Current_key indicates a MKT that is used to authenticate outgoing
is used to authenticate outgoing segments. Upon connection segments. Upon connection establishment, it points to the first MKT
establishment, it points to the first key selected for use. selected for use.
Next_key points to an incoming KeyID (and associated master key Next_key points to an incoming MKT that is ready and preferred for
tuple) that is ready and preferred for use. Upon connection use. Upon connection establishment, this points to the currently
establishment, this points to the currently active incoming key. It active incoming MKT. It can be changed when new MKTs are installed
can be changed when new keys are installed (e.g., either by automatic (e.g., either by automatic MKT management protocol operation or by
key management protocol operation or by user manual selection). user manual selection).
Next_key is changed only by manual user intervention or key Next_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. 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
"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
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
considered permitted.
8.2. Preventing replay attacks within long-lived connections 8.2. Preventing replay attacks within long-lived connections
TCP uses a 32-bit sequence number which may, for long-lived TCP uses a 32-bit sequence number which may, for long-lived
connections, roll over and repeat. This could result in TCP segments connections, roll over and repeat. This could result in TCP segments
being intentionally and legitimately replayed within a connection. being intentionally and legitimately replayed within a connection.
TCP-AO prevents replay attacks, and thus requires a way to TCP-AO prevents replay attacks, and thus requires a way to
differentiate these legitimate replays from each other, and so it differentiate these legitimate replays from each other, and so it
adds a 32-bit extended sequence number (ESN) for transmitted and adds a 32-bit sequence number extension (SNE) for transmitted and
received segments. received segments.
The ESN extends TCP's sequence number so that segments within a The SNE extends TCP's sequence number so that segments within a
single connection are always unique. When TCP's sequence number rolls single connection are always unique. When TCP's sequence number rolls
over, there is a chance that a segment could be repeated in total; over, there is a chance that a segment could be repeated in total;
using an ESN differentiates even identical segments sent with using an SNE differentiates even identical segments sent with
identical sequence numbers at different times in a connection. TCP-AO identical sequence numbers at different times in a connection. TCP-AO
emulates a 64-bit sequence number space by inferring when to emulates a 64-bit sequence number space by inferring when to
increment the high-order 32-bit portion (the ESN) based on increment the high-order 32-bit portion (the SNE) based on
transitions in the low-order portion (the TCP sequence number). transitions in the low-order portion (the TCP sequence number).
TCP-AO thus maintains SND.ESN for transmitted segments, and RCV.ESN TCP-AO thus maintains SND.SNE for transmitted segments, and RCV.SNE
for received segments, both initialized as zero when a connection for received segments, both initialized as zero when a connection
begins. The intent of these ESNs is, together with TCP's 32-bit begins. The intent of these SNEs is, together with TCP's 32-bit
sequence numbers, to provide a 64-bit overall sequence number space. sequence numbers, to provide a 64-bit overall sequence number space.
For transmitted segments SND.ESN can be implemented by extending For transmitted segments SND.SNE can be implemented by extending
TCP's sequence number to 64-bits; SND.ESN would be the top (high- TCP's sequence number to 64-bits; SND.SNE would be the top (high-
order) 32 bits of that number. For received segments, TCP-AO needs to order) 32 bits of that number. For received segments, TCP-AO needs to
emulate the use of a 64-bit number space, and correctly infer the emulate the use of a 64-bit number space, and correctly infer the
appropriate high-order 32-bits of that number as RCV.ESN from the appropriate high-order 32-bits of that number as RCV.SNE from the
received 32-bit sequence number and the current connection context. received 32-bit sequence number and the current connection context.
The implementation of ESNs is not specified in this document, but one The implementation of SNEs is not specified in this document, but one
possible way is described here that can be used for either RCV.ESN, possible way is described here that can be used for either RCV.SNE,
SND.ESN, or both. SND.SNE, or both.
Consider an implementation with two ESNs as required (SND.ESN, Consider an implementation with two SNEs as required (SND.SNE, RCV.
RCV.ESN), and additional variables as listed below, all initialized SNE), and additional variables as listed below, all initialized to
to zero, as well as a current TCP segment field (SEG.SEQ): zero, as well as a current TCP segment field (SEG.SEQ):
o SND.PREV_SEQ, needed to detect rollover of SND.SEQ o SND.PREV_SEQ, needed to detect rollover of SND.SEQ
o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ o RCV.PREV_SEQ, needed to detect rollover of RCV.SEQ
o SND.ESN_FLAG, which indicates when to increment the SND.ESN o SND.SNE_FLAG, which indicates when to increment the SND.SNE
o RCV.ESN_FLAG, which indicates when to increment the RCV.ESN o RCV.SNE_FLAG, which indicates when to increment the RCV.SNE
When a segment is received, the following algorithm (written in C) When a segment is received, the following algorithm (written in C)
computes the ESN used in the MAC; an equivalent algorithm can be computes the SNE used in the MAC; an equivalent algorithm can be
applied to the "SND" side: 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.ESN_FLAG == 0) if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) { && (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.ESN = RCV.ESN + 1; RCV.SNE = RCV.SNE + 1;
RCV.ESN_FLAG = 1; RCV.SNE_FLAG = 1;
} }
/* */ /* decide which SNE to use after incremented */
/* decide which ESN to use after incremented */ if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
if ((RCV.ESN_FLAG == 1) && (SEG.SEQ > 0x7fff)) { SNE = RCV.SNE - 1; # use the pre-increment value
ESN = RCV.ESN - 1; # use the pre-increment value
} else { } else {
ESN = RCV.ESN; # use the current value SNE = RCV.SNE; # use the current value
} }
/* */
/* reset the flag in the *middle* of the window */ /* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) { if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.ESN_FLAG = 0; RCV.SNE_FLAG = 0;
} }
/* */
/* 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 ESN 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 ESN, otherwise use the current ESN. packet, 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 ESN 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 packets, 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
skipping to change at page 29, line 15 skipping to change at page 27, line 13
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
The TCP user interface supports active and passive OPEN, SEND, The TCP user interface supports active and passive OPEN, SEND,
RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this RECEIVE, CLOSE, STATUS and ABORT commands. TCP-AO does not alter this
interface as it applies to TCP, but some commands or command interface as it applies to TCP, but some commands or command
sequences of the interface need to be modified to support TCP-AO. sequences of the interface need to be modified to support TCP-AO.
TCP-AO does not specify the details of how this is achieved. TCP-AO does not specify the details of how this is achieved.
TCP-AO requires the TCP user interface be extended to allow the TAPD TCP-AO requires the TCP user interface be extended to allow the MKTs
to be configured, as well as to allow an ongoing connection to manage to be configured, as well as to allow an ongoing connection to manage
which KeyID tuples are active. The TAPD needs to be configured prior which MKTs are active. The MKTs need to be configured prior to
to connection establishment, and possibly changed during a connection establishment, and the set of MKTs may change during a
connection: connection:
>> TCP OPEN, or the sequence of commands that configure a connection >> TCP OPEN, or the sequence of commands that configure a connection
to be in the active or passive OPEN state, MUST be augmented so that to be in the active or passive OPEN state, MUST be augmented so that
a TAPD entry can be configured. a MKT can be configured.
>> A TCP-AO implmentation MUST allow TAPD entries for ongoing TCP >> A TCP-AO implmentation MUST allow the set of MKTs for ongoing TCP
connections (i.e., not in the CLOSED state) to be modified. connections (i.e., not in the CLOSED state) to be modified.
Parameters not used to index a connection MAY be modified; parameters
used to index a connection MUST NOT be modified.
The TAPD information of a connection needs to be available for The MKTs associated with a connection needs to be available for
confirmation; this includes the ability to read the connection key: confirmation; this includes the ability to read the MKTs:
>> TCP STATUS SHOULD be augmented to allow the TAPD entry of a >> TCP STATUS SHOULD be augmented to allow the MKTs of a current or
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 KeyID Senders may need to be able to determine when the outgoing MKT
changes or when a new preferred KeyID (NextKeyID) is indicated; these changes (KeyID) or when a new preferred MKT (NextKeyID) is indicated;
changes immediately affect all subsequent outgoing segments: these changes immediately affect all subsequent outgoing segments:
>> TCP SEND, or a sequence of commands resulting in a SEND, MUST be >> TCP SEND, or a sequence of commands resulting in a SEND, MUST be
augmented so that the preferred KeyID (Current_key) and/or the augmented so that the preferred outgoing MKT (Current_key) and/or the
Next_key of a connection can be indicated. preferred incoming MKT Next_key of a connection can be indicated.
It may be useful to change the outgoing active KeyID (Current_key) It may be useful to change the outgoing active MKT (Current_key) even
even when no data is being sent, which can be achieved by sending a when no data is being sent, which can be achieved by sending a zero-
zero-length buffer or by using a non-send interface (e.g., socket length buffer or by using a non-send interface (e.g., socket options
options in Unix), depending on the implementation. in Unix), depending on the implementation.
It is also useful to indicate recent KeyID and NextKeyID values It is also useful to indicate recent segment KeyID and NextKeyID
received; although there could be a number of such values, they are values received; although there could be a number of such values,
not expected to change quickly so any recent sample should be they are not expected to change quickly so any recent sample should
sufficient: be sufficient:
>> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, >> TCP RECEIVE, or the sequence of commands resulting in a RECEIVE,
MUST be augmented so that the KeyID and NextKeyID of a recently MUST be augmented so that the KeyID and NextKeyID of a recently
received segment is available to the user out-of-band (e.g., as an received segment is available to the user out-of-band (e.g., as an
additional parameter to RECEIVE, or via a STATUS call). additional parameter to RECEIVE, or via a STATUS call).
9.2. TCP States and Transitions 9.2. TCP States and Transitions
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and
CLOSED. CLOSED.
>> A TAPD entry MAY be associated with any TCP state. >> A MKT MAY be associated with any TCP state.
>> A TAPD 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.
9.3. TCP Segments 9.3. TCP Segments
TCP includes control (at least one of SYN, FIN, RST flags set) and TCP includes control (at least one of SYN, FIN, RST flags set) and
data (none of SYN, FIN, or RST flags set) segments. Note that some data (none of SYN, FIN, or RST flags set) segments. Note that some
control segments can include data (e.g., SYN). control segments can include data (e.g., SYN).
>> All TCP segments MUST be checked against the TAPD for matching TCP >> All TCP segments MUST be checked against the set of MKTs for
connection IDs. matching TCP connection identifiers.
>> TCP segments matching TAPD entries without TCP-AO, or with TCP-AO >> TCP segments whose TCP-AO option does not validate MUST be
and whose MACs and KeyIDs do not validate MUST be silently discarded. silently discarded.
>> TCP segments with TCP-AO but not matching TAPD entries MUST be >> TCP segments with TCP-AO but not matching an MKT MUST be silently
silently accepted; this is required for equivalent function with TCPs accepted; this is required for equivalent function with TCPs not
not implementing TCP-AO. implementing TCP-AO.
>> Silent discard events SHOULD be signaled to the user as a warning, >> Silent discard events SHOULD be signaled to the user as a warning,
and silent accept events MAY be signaled to the user as a warning. and silent accept events MAY be signaled to the user as a warning.
Both warnings, if available, MUST be accessible via the STATUS Both warnings, if available, MUST be accessible via the STATUS
interface. Either signal MAY be asynchronous, but if so they MUST be interface. Either signal MAY be asynchronous, but if so they MUST be
rate-limited. Either signal MAY be logged; logging SHOULD allow rate- rate-limited. Either signal MAY be logged; logging SHOULD allow rate-
limiting as well. limiting as well.
All TCP-AO processing occurs between the interface of TCP and IP; for All TCP-AO processing occurs between the interface of TCP and IP; for
incoming segments, this occurs after validation of the TCP checksum. incoming segments, this occurs after validation of the TCP checksum.
skipping to change at page 31, line 21 skipping to change at page 29, line 12
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.
1. Find the per-connection parameters for the segment: 1. Find the per-connection parameters for the segment:
a. If the segment is a SYN, then this is the first segment of a a. If the segment is a SYN, then this is the first segment of a
new connection. Consult the TAPD to find the appropriate new connection. Find the matching MKT for this segment based
master key tuple. on the segment's socket pair.
i. If there is no matching TAPD entry, omit the TCP-AO
option. Proceed with transmitting the segment.
ii. If there is a TAPD entry with zero master key tuples, i. If there is no matching MKT, omit the TCP-AO option.
silently discard the segment and cease further Proceed with transmitting the segment.
processing.
iii. If there is a TAPD entry and at least one master key ii. If there is a matching MKT, then set the per-connection
tuple, then set the per-connection parameters as needed parameters as needed (see Section 6). Proceed with the
(see Section 6). Proceed with the step 2. step 2.
b. If the segment is not a SYN, then determine whether TCP-AO is b. If the segment is not a SYN, then determine whether TCP-AO is
being used and the current_key value from the per-connection being used for the connection and use the MKT as indicated by
parameters (see Section 6) and proceed with the step 2. the current_key value from the per-connection parameters (see
Section 6) and proceed with the step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
a. Augment the TCP header with the TCP-AO, inserting the a. Augment the TCP header with the TCP-AO, inserting the
appropriate Length and KeyID based on the master key tuple appropriate Length and KeyID based on the MKT indicated by
indicated by current_key. Update the TCP header length current_key (using the current_key MKT's SendID as the TCP-AO
accordingly. KeyID). Update the TCP header length accordingly.
b. Determine SND.ESN as described in Section 8.2. b. Determine SND.SNE as described in Section 8.2.
c. Determine the appropriate traffic key, i.e., as pointed to by c. Determine the appropriate traffic key, i.e., as pointed to by
current_key (as noted in Section 8.1, and as probably cached current_key (as noted in Section 8.1, and as probably cached
in the TCB). I.e., use the Send_SYN_traffic_key for SYN in the TCB). I.e., use the send_SYN_traffic_key for SYN
segments, and the send_other_traffic_key for other segments. segments, and the send_other_traffic_key for other segments.
d. Determine the NextKeyID as indicated by the Next_key pointer d. Determine the NextKeyID as indicated by the Next_key pointer,
(as noted in Section 8.1). and insert it in the TCP-AO option (using the next_key MKT's
RecvID as the TCP-AO KeyID) (as noted in Section 8.1).
e. Compute the MAC using the master key tuple (and cached traffic e. Compute the MAC using the MKT (and cached traffic key) and
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 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
The following procedure describes the modifications to TCP to support The following procedure describes the modifications to TCP to support
TCP-AO when a segment arrives. TCP-AO when a segment arrives.
>> Note that TCP-AO MUST be the first TCP option processed on >> Note that TCP-AO MUST be the first TCP option processed on
incoming segments, because its MAC calculation may include the values incoming segments, because its MAC calculation may include the values
skipping to change at page 32, line 33 skipping to change at page 30, line 23
This also protects the behavior of all other TCP options from the This also protects the behavior of all other TCP options from the
impact of spoofed segments or modified header information. impact of spoofed segments or modified header information.
>> Note that TCP-AO checks MUST be performed for all incoming SYNs to >> Note that TCP-AO checks MUST be performed for all incoming SYNs to
avoid accepting SYNs lacking the TCP-AO option where required. Other avoid accepting SYNs lacking the TCP-AO option where required. Other
segments can cache whether TCP-AO is needed in the TCB. segments can cache whether TCP-AO is needed in the TCB.
1. Find the per-connection parameters for the segment: 1. Find the per-connection parameters for the segment:
a. If the segment is a SYN, then this is the first segment of a a. If the segment is a SYN, then this is the first segment of a
new connection. Consult the TAPD to find the appropriate new connection. Find the matching MKT for this segment, using
master key tuple. the segment's socket pair and its TCP-AO KeyID, matched
against the MKT's TCP connection identifier and the MKT's
i. If there is no matching TAPD entry, omit the TCP-AO RecvID.
option. Proceed with further TCP handling of the segment.
ii. If there is a TAPD entry with zero master key tuples, i. If there is no matching MKT, omit the TCP-AO option.
silently discard the segment and cease further TCP Proceed with further TCP handling of the segment.
processing.
iii. If there is a TAPD entry and at least one master key ii. If there is a matching MKT, then set the per-connection
tuple, then set the per-connection parameters as needed parameters as needed (see Section 6). Proceed with the
(see Section 6). Proceed with the step 2. step 2.
2. Using the per-connection parameters: 2. Using the per-connection parameters:
a. Check that the segment's TCP-AO Length matches the length a. Check that the segment's TCP-AO Length matches the length
indicated by the master key indicated by the segment's TCP-AO indicated by the MKT.
KeyID field.
i. If lengths differ, silently discard the segment. Log i. If lengths differ, silently discard the segment. Log
and/or signal the event as indicated in Section 9.3. and/or signal the event as indicated in Section 9.3.
b. Use the segment's KeyID value to index the appropriate b. Determine the segment's RCV.SNE as described in Section 8.2.
connection key for this connection.
c. Determine the segment's RCV.ESN as described in Section 8.2.
d. Determine the segment's traffic key from the master key tuple c. Determine the segment's traffic key from the MKT as described
as described in Section 7.1 (and as likely cached in the TCB). in Section 7.1 (and as likely cached in the TCB). I.e., use
I.e., use the receive_SYN_traffic_key for SYN segments, and the receive_SYN_traffic_key for SYN segments, and the
the receive_other_traffic_key for other segments. receive_other_traffic_key for other segments.
e. Compute the segment's MAC using the master key tuple (and its d. Compute the segment's MAC using the MKT (and its derived
derived traffic key) and portions of the segment as indicated traffic key) and portions of the segment as indicated in
in Section 7.1. Section 7.1.
i. If the computed MAC differs from the TCP-AO MAC field i. If the computed MAC differs from the TCP-AO MAC field
value, silently discard the segment. Log and/or signal value, silently discard the segment. Log and/or signal
the event as indicated in Section 9.3. the event as indicated in Section 9.3.
f. Compare the received NextKeyID value to the currently active e. Compare the received NextKeyID value to the currently active
outgoing KeyID value (Current_key). outgoing KeyID value (Current_key MKT's SendID).
i. If they match, no further action is required. i. If they match, no further action is required.
ii. If they differ, determine whether the NextKeyID keying ii. If they differ, determine whether the NextKeyID MKT is
information is ready. ready.
1. If the NextKeyID keying information is not 1. If the MKT corresponding to the segment's socket
available, no action is required. pair and NextKeyID is not available, no action is
required (NextKeyID of a received segment needs to
match the MKT's SendID).
2. If the NextKeyID keying information is available: 2. If the matching MKT corresponding to the segment's
socket pair and NextKeyID is available:
NOTE: there is an open question as to whether to a. Optionally, set a timer on the MKT indicated by
refuse to change to the suggested NextKeyID if it the current_key and segment socket pair to
already has a 2*MSL timer set on it, i.e., to refuse ensure that the MKT cannot be deleted for 2*MSL.
to 'backup' and use a key once it has been If a timer has already been set, reset the
previously used. timer.
a. Set a timer on the previous value of current_key This timer is advisory only. Removing MKTs with
to ensure that the corresponding master key unexpired timers can result in a user-level
cannot be removed from the TAPD for 2*MSL. warning, but is not prohibited. Implementation
of timers is not required.
b. Set Current_key to the NextKeyID value. b. Set Current_key to the NextKeyID MKT.
g. Proceed with TCP processing of the segment. f. Proceed with TCP processing of the segment.
It is suggested that TCP-AO implementations validate a segment's It is suggested that TCP-AO implementations validate a segment's
Length field before computing a MAC, to reduce the overhead incurred Length field before computing a MAC, to reduce the overhead incurred
by spoofed segments with invalid TCP-AO fields. by spoofed segments with invalid TCP-AO fields.
Additional reductions in MAC validation overhead can be supported in Additional reductions in MAC validation overhead can be supported in
the MAC algorithms, e.g., by using a computation algorithm that the MAC algorithms, e.g., by using a computation algorithm that
prepends a fixed value to the computed portion and a corresponding prepends a fixed value to the computed portion and a corresponding
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
skipping to change at page 35, line 43 skipping to change at page 33, line 36
use TCP MD5 instead. use TCP MD5 instead.
>> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a >> A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a
particular TCP connection, but MAY support TCP-AO and TCP MD5 particular TCP connection, but MAY support TCP-AO and TCP MD5
simultaneously for different connections (notably to support legacy simultaneously for different connections (notably to support legacy
use of TCP MD5). use of TCP MD5).
The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used The Kind value explicitly indicates whether TCP-AO or TCP MD5 is used
for a particular connection in TCP segments. for a particular connection in TCP segments.
It is possible that the TAPD could be augmented to support TCP MD5, It is possible that MKTs could be augmented to support TCP MD5,
although use of a TAPD-like system is not described in RFC2385. although use of MKTs is not described in RFC2385.
It is possible to require TCP-AO for a connection or TCP MD5, but it It is possible to require TCP-AO for a connection or TCP MD5, but it
is not possible to require 'either'. When an endpoint is configured is not possible to require 'either'. When an endpoint is configured
to require TCP MD5 for a connection, it must be added to all outgoing to require TCP MD5 for a connection, it must be added to all outgoing
segments and validated on all incoming segments [RFC2385]. TCP MD5's segments and validated on all incoming segments [RFC2385]. TCP MD5's
requirements prohibit the speculative use of both options for a given requirements prohibit the speculative use of both options for a given
connection, e.g., to be decided by the other end of the connection. connection, e.g., to be decided by the other end of the connection.
11. Interactions with Middleboxes 11. Interactions with Middleboxes
skipping to change at page 37, line 43 skipping to change at page 35, line 35
This is supported - see Section 7.1. This is supported - see Section 7.1.
a. Privacy. a. Privacy.
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 master key index, MAC, and overall TCP-AO exposes only the MKT IDs, MAC, and overall option
option length on the wire. Note that short MACs could be length on the wire. Note that short MACs could be obscured by
obscured by using longer option lengths but specifying a short using longer option lengths but specifying a short MAC length
MAC length (this is equivalent to a different MAC algorithm, (this is equivalent to a different MAC algorithm, and is
and is specified in the TAPD entry). See Section 4.2. specified in the TAPD entry). 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 - see Sections 9.3, 9.4, and 9.5. This is supported because the set of MKTs can be installed to
match some connections and not others. Connections not
matching any MKT do not require TCP-AO. Further, incoming
segments containing the TCP-AO option are not discarded solely
because they include the option, provided they do not match
any MKT.
c. Require non-optional. c. Require non-optional.
The option should be able to be specified as required for a The option should be able to be specified as required for a
given connection. given connection.
This is supported - see Sections 9.3, 9.4, and 9.5. This is supported because the set of MKTs can be installed to
match some connections and not others. Connections matching
any MKT require TCP-AO.
d. Standard parsing. d. Standard parsing.
The option should be easily parseable, i.e., without The option should be easily parseable, i.e., without
conditional parsing, and follow the standard RFC 793 option conditional parsing, and follow the standard RFC 793 option
format. format.
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.
skipping to change at page 39, line 22 skipping to change at page 37, line 22
TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also
specified in [ao-crypto]. The PRF input string follows the specified in [ao-crypto]. The PRF input string follows the
typical design (see [ao-crypto]). typical design (see [ao-crypto]).
c. Algorithm agility. c. Algorithm agility.
The option should support algorithms other than the default, The option should support algorithms other than the default,
to allow agility over time. to allow agility over time.
TCP-AO allows any desired algorithm, subject to TCP option TCP-AO allows any desired algorithm, subject to TCP option
space limitations, as noted in Section 4.2. The TAPD allows space limitations, as noted in Section 4.2. The use of set of
separate connections to use different algorithms, both for the MKTs allows separate connections to use different algorithms,
MAC and the PRF. both for the MAC and the PRF.
d. Order-independent processing. d. Order-independent processing.
The option should be processed independently of the proper The option should be processed independently of the proper
order, i.e., they should allow processing of TCP segments in order, i.e., they should allow processing of TCP segments in
the order received, without requiring reordering. This avoids the order received, without requiring reordering. This avoids
the need for reordering prior to processing, and avoids the the need for reordering prior to processing, and avoids the
impact of misordered segments on the option. impact of misordered segments on the option.
This is supported - see Sections 9.3, 9.4, and 9.5. Note that This is supported - see Sections 9.3, 9.4, and 9.5. Note that
pre-TCP processing is further required, because TCP segments pre-TCP processing is further required, because TCP segments
cannot be discarded solely based on a combination of cannot be discarded solely based on a combination of
connection state and out-of-window checks; many such segments, connection state and out-of-window checks; many such segments,
although discarded, cause a host to respond with a replay of although discarded, cause a host to respond with a replay of
the last valid ACK, e.g. [RFC793]. See also the derivation of the last valid ACK, e.g. [RFC793]. See also the derivation of
the ESN, which is reconstituted at the receiver using a the SNE, which is reconstituted at the receiver using a
demonstration algorithm that avoids the need for reordering demonstration algorithm that avoids the need for reordering
(in Section 8.2). (in Section 8.2).
e. Security parameter changes require key changes. e. Security parameter changes require key changes.
The option should require that the key change whenever the The option should require that the MKT change whenever the
security parameters change. This avoids the need for security parameters change. This avoids the need for
coordinating option state during a connection, which is coordinating option state during a connection, which is
typical for TCP options. This also helps allow "bump in the typical for TCP options. This also helps allow "bump in the
stack" implementations that are not integrated with endpoint stack" implementations that are not integrated with endpoint
TCP implementations. TCP implementations.
TAPD parameters that should not change during a connection (by Parameters change only when a new MKT is used. See Section 5.
defininition, e.g., TCP connection ID, receiver TCP connection
ID, TCP option exclusion list) cannot change. Other parameters
change only when a master key is changed, using the master key
tuple mechanism in the TAPD. See Section 5.
4. Keying requirements. 4. Keying requirements.
A solution to revising TCP MD5 should support manual keying, and A solution to revising TCP MD5 should support manual keying, and
should support the use of an external automated key management should support the use of an external automated key management
system (e.g., a protocol or other mechanism). system (e.g., a protocol or other mechanism).
Note that TCP-AO does not specify a master key management system, Note that TCP-AO does not specify a MKT management system.
but does indicate a proposed interface to the TAPD, allowing a
completely separate master key system, as noted in Section 5.
a. Intraconnection rekeying. a. Intraconnection rekeying.
The option should support rekeying during a connection, to The option should support rekeying during a connection, to
avoid the impact of long-duration connections. avoid the impact of long-duration connections.
This is supported by the KeyID and multiple master key tuples This is supported by the use of IDs and multiple MKTs; see
in a TAPD entry; see Section 5. Section 5.
b. Efficient rekeying. b. Efficient rekeying.
The option should support rekeying during a connection without The option should support rekeying during a connection without
the need to expend undue computational resources. In the need to expend undue computational resources. In
particular, the options should avoid the need to try multiple particular, the options should avoid the need to try multiple
keys on a given segment. keys on a given segment.
This is supported by the use of the KeyID. See Section 8.1. This is supported by the use of the KeyID. See Section 8.1.
c. Automated and manual keying. c. Automated and manual keying.
The option should support both automated and manual keying. The option should support both automated and manual keying.
The use of a separate TAPD allows external automated and The use of MKTs allows external automated and manual keying.
manual keying. See Section 5. This capability is enhanced by See Section 5. This capability is enhanced by the generation
the generation of unique per-connection keys, which enables of unique per-connection keys, which enables use of manual
use of manual master keys with automatically generated MKTs with automatically generated traffic keys as noted in
connection keys as noted in Section 7.2. Section 7.2.
d. Key management agnostic. d. Key management agnostic.
The option should not assume or require a particular key The option should not assume or require a particular key
management solution. management solution.
This is supported by use of a separate TAPD. See Section 5. This is supported by use of a set of MKTs. See Section 5.
5. Expected Constraints 5. Expected Constraints
A solution to revising TCP MD5 should also abide by typical safe A solution to revising TCP MD5 should also abide by typical safe
security practices. security practices.
a. Silent failure. a. Silent failure.
Receipt of segments failing authentication must result in no Receipt of segments failing authentication must result in no
visible external action and must not modify internal state, visible external action and must not modify internal state,
skipping to change at page 43, line 42 skipping to change at page 41, line 35
requiring that they are endpoint authenticated in others [RFC4301]. requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the of some messages based on TCP state, but these do not provide the
level of authentication for ICMP that TCP-AO provides for TCP [Go07]. level of authentication for ICMP that TCP-AO provides for TCP [Go07].
>> A TCP-AO implementation MUST allow the system administrator to >> A TCP-AO implementation MUST allow the system administrator to
configure whether TCP will ignore incoming ICMP messages of Type 3 configure whether TCP will ignore incoming ICMP messages of Type 3
(destination unreachable) Codes 2-4 (protocol unreachable, port (destination unreachable) Codes 2-4 (protocol unreachable, port
unreachable, and fragmentation needed - 'hard errors') intended for unreachable, and fragmentation needed - 'hard errors') intended for
connections that match TAPD entries with non-NONE inbound MACs. An connections that match MKTs. An implementation SHOULD allow ignored
implementation SHOULD allow ignored ICMPs to be logged. ICMPs to be logged.
This control affects only ICMPs that currently require 'hard errors', This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection [RFC1122]. This recommendation which would abort the TCP connection [RFC1122]. This recommendation
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 connection key (for whatever reason) from potentially enabling a same MKT (for whatever reason) from potentially enabling a traffic-
traffic-crossing attack, in which segments to one socket pair are crossing attack, in which segments to one socket pair are diverted to
diverted to attack a different socket pair. When multiple connections attack a different socket pair. When multiple connections use the
use the same master key, it would be useful to know that packets same MKT, it would be useful to know that packets intended for one ID
intended for one ID could not be (maliciously or otherwise) modified could not be (maliciously or otherwise) modified in transit and end
in transit and end up being authenticated for the other ID. The ID up being authenticated for the other ID. That requirement would place
cannot be zeroed, because to do so would require that the TAPD index an additional burden of uniqueness on MKTs within endsystems, and
was unique in both directions (ID->key and key->ID). That requirement potentially across endsystems. Although the resulting attack is low
would place an additional burden of uniqueness on master keys within probability, the protection afforded by including the received ID
endsystems, and potentially across endsystems. Although the resulting warrants its inclusion in the MAC, and does not unduly increase the
attack is low probability, the protection afforded by including the MAC calculation or MKT management.
received ID warrants its inclusion in the MAC, and does not unduly
increase the MAC calculation or master key management system.
The use of any security algorithm can present an opportunity for a The use of any security algorithm can present an opportunity for a
CPU DOS attack, where the attacker sends false, random segments that CPU DOS attack, where the attacker sends false, random segments that
the receiver under attack expends substantial CPU effort to reject. the receiver under attack expends substantial CPU effort to reject.
In IPsec, such attacks are reduced by the use of a large Security In IPsec, such attacks are reduced by the use of a large Security
Parameter Index (SPI) and Sequence Number fields to partly validate Parameter Index (SPI) and Sequence Number fields to partly validate
segments before CPU cycles are invested validated the Integrity Check segments before CPU cycles are invested validated the Integrity Check
Value (ICV). In TCP-AO, the socket pair performs most of the function Value (ICV). In TCP-AO, the socket pair performs most of the function
of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay of IPsec's SPI, and IPsec's Sequence Number, used to avoid replay
attacks, isn't needed due to TCP's Sequence Number, which is used to attacks, isn't needed due to TCP's Sequence Number, which is used to
reorder received segments (provided the sequence number doesn't wrap reorder received segments (provided the sequence number doesn't wrap
around, which is why TCP-AO adds the ESN in Section 8.2). TCP already around, which is why TCP-AO adds the SNE in Section 8.2). TCP already
protects itself from replays of authentic segment data as well as protects itself from replays of authentic segment data as well as
authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even authentic explicit TCP control (e.g., SYN, FIN, ACK bits, but even
authentic replays could affect TCP congestion control [Sa99]. TCP-AO authentic replays could affect TCP congestion control [Sa99]. TCP-AO
does not protect TCP congestion control from this last form of attack does not protect TCP congestion control from this last form of attack
due to the cumbersome nature of layering a windowed security sequence due to the cumbersome nature of layering a windowed security sequence
number within TCP in addition to TCP's own sequence number; when such number within TCP in addition to TCP's own sequence number; when such
protection is desired, users are encouraged to apply IPsec instead. protection is desired, users are encouraged to apply IPsec instead.
Further, it is not useful to validate TCP's Sequence Number before Further, it is not useful to validate TCP's Sequence Number before
performing a TCP-AO authentication calculation, because out-of-window performing a TCP-AO authentication calculation, because out-of-window
skipping to change at page 46, line 22 skipping to change at page 44, line 18
Statement and Requirements for a TCP Authentication Statement and Requirements for a TCP Authentication
Option," draft-bellovin-tcpsec-01, (work in progress), Jul. Option," draft-bellovin-tcpsec-01, (work in progress), Jul.
2007. 2007.
[Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler, [Bo07] Bonica, R., B. Weis, S. Viswanathan, A. Lange, O. Wheeler,
"Authentication for TCP-based Routing and Management "Authentication for TCP-based Routing and Management
Protocols," draft-bonica-tcp-auth-06, (work in progress), Protocols," draft-bonica-tcp-auth-06, (work in progress),
Feb. 2007. Feb. 2007.
[Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp- [Go07] Gont, F., "ICMP attacks against TCP," draft-ietf-tcpm-icmp-
attacks-04, (work in progress), Oct. 2008. attacks-05, (work in progress), Jun. 2009.
[Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist [Je07] Jethanandani, M., M. Bashyam, "TCP Robustness in Persist
Condition," draft-mahesh-persist-timeout-02, (work in Condition," draft-mahesh-persist-timeout-03, (work in
progress), Oct. 2007. progress), Oct. 2007.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC-1321,
Informational, April 1992. Informational, April 1992.
[RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [RFC1323] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
High Performance," RFC-1323, May 1992. High Performance," RFC-1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks," [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks,"
RFC-1948, Informational, May 1996. RFC-1948, Informational, May 1996.
 End of changes. 221 change blocks. 
738 lines changed or deleted 627 lines changed or added

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