TCP-AO algorithms: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
The cryptographic algorithms that the TCP Authentication Option uses to protect each segment.
Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, <https://www.rfc-editor.org/info/rfc5926>.
@misc{rfc5926,
series = {Request for Comments},
number = 5926,
howpublished = {RFC 5926},
publisher = {RFC Editor},
doi = {10.17487/RFC5926},
url = {https://www.rfc-editor.org/info/rfc5926},
author = {G. Lebovitz and E. Rescorla},
title = {{Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)}},
pagetotal = 15,
year = 2010,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Lebovitz
Request for Comments: 5926 Juniper
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM
June 2010
Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
Abstract
The TCP Authentication Option (TCP-AO) relies on security algorithms
to provide authentication between two end-points. There are many
such algorithms available, and two TCP-AO systems cannot interoperate
unless they are using the same algorithms. This document specifies
the algorithms and attributes that can be used in TCP-AO's current
manual keying mechanism and provides the interface for future message
authentication codes (MACs).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5926.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Requirements ....................................................3
2.1. Requirements Language ......................................3
2.2. Algorithm Requirements .....................................3
2.3. Requirements for Future MAC Algorithms .....................3
3. Algorithms Specified ............................................4
3.1. Key Derivation Functions (KDFs) ............................4
3.1.1. Concrete KDFs .......................................5
3.1.1.1. KDF_HMAC_SHA1 ..............................6
3.1.1.2. KDF_AES_128_CMAC ...........................7
3.1.1.3. Tips for User Interfaces Regarding KDFs ....9
3.2. MAC Algorithms .............................................9
3.2.1. The Use of HMAC-SHA-1-96 ...........................10
3.2.2. The Use of AES-128-CMAC-96 .........................11
4. Security Considerations ........................................11
5. IANA Considerations ............................................13
6. Acknowledgements ...............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
1. Introduction
This document is a companion to [RFC5925]. Like most modern security
protocols, TCP-AO allows users to choose which cryptographic
algorithm(s) they want to use to meet their security needs.
TCP-AO provides cryptographic authentication and message integrity
verification between two end-points. In order to accomplish this
function, message authentication codes (MACs) are used, which then
rely on shared keys. There are various ways to create MACs. The use
of hash-based MACs (HMACs) is defined in [RFC2104]. The use of
cipher-based MACs (CMACs) is defined in [NIST-SP800-38B].
This RFC defines the general requirements for MACs used in TCP-AO,
both for currently specified MACs and for any future specified MACs.
It specifies two MAC algorithms required in all TCP-AO
implementations. It also specifies two key derivation functions
(KDFs) used to create the traffic keys used by the MACs. These KDFs
are also required by all TCP-AO implementations.
2. Requirements
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
When used in lowercase, these words convey their typical use in
common language, and they are not to be interpreted as described in
[RFC2119].
2.2. Algorithm Requirements
This is the initial specification of required cryptography for
TCP-AO, and indicates two MAC algorithms and two KDFs. All four
components MUST be implemented in order for the implementation to be
fully compliant with this RFC.
The following table indicates the required MAC algorithms and KDFs
for TCP-AO:
Requirement Authentication Algorithm
------------ ------------------------
MUST HMAC-SHA-1-96 [RFC2104][FIPS-180-3]
MUST AES-128-CMAC-96 [NIST-SP800-38B][FIPS197]
Requirement Key Derivation Function (KDF)
------------- ------------------------
MUST KDF_HMAC_SHA1
MUST KDF_AES_128_CMAC
For an explanation of why two MAC algorithms were mandated, see the
Section 4.
2.3. Requirements for Future MAC Algorithms
TCP-AO is intended to support cryptographic agility. As a result,
this document includes recommendations in various places for future
MAC and KDF algorithms when used for TCP-AO. For future MAC
algorithms specifically, they SHOULD protect at least 2**48 messages
with a collision probability of less than one in 10**9.
3. Algorithms Specified
TCP-AO requires two classes of cryptographic algorithms used on a
particular connection, and refers to this document to define them
both:
(1) Key Derivation Functions (KDFs), which name a pseudorandom
function (PRF) and use a Master_Key and some connection-
specific input with that PRF to produce Traffic_Keys, the
keys suitable for authenticating and integrity checking
individual TCP segments, as described in TCP-AO.
(2) Message Authentication Code (MAC) algorithms, which take a
key and a message and produce an authentication tag that can
be used to verify the integrity and authenticity of those
messages.
In TCP-AO, these algorithms are always used in pairs. Each MAC
algorithm MUST specify the KDF to be used with that MAC algorithm.
However, a KDF MAY be used with more than one MAC algorithm.
3.1. Key Derivation Functions (KDFs)
TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP-
AO's current manual keying have the following interface:
Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)
where:
- KDF_alg: the specific pseudorandom function (PRF) that is
the basic building block used in constructing the
given Traffic_Key.
- Master_Key: In TCP-AO's manual key mode, this is a key shared
by both peers, entered via some interface to their
respective configurations. The Master_Key is used
as the seed for the KDF. We assume that this is a
human-readable pre-shared key (PSK); thus, we
assume it is of variable length. Master_Keys
SHOULD be random, but might not be (e.g., badly
chosen by the user). For interoperability, the
management interface by which the PSK is configured
MUST accept ASCII strings, and SHOULD also allow
for the configuration of any arbitrary binary
string in hexadecimal form. Other configuration
methods MAY be supported.
- Context: A binary string containing information related to
the specific connection for this derived keying
material, as defined in [RFC5925], Section 5.2.
- Output_Length: The length, in bits, of the key that the KDF
will produce. This length must be the size
required for the MAC algorithm that will use the
PRF result as a seed.
When invoked, a KDF generates a string of length Output_Length bits
based on the Master_Key and context value. This result may then be
used as a cryptographic key for any algorithm that takes an
Output_Length length key. A KDF MAY specify a maximum Output_Length
parameter.
3.1.1. Concrete KDFs
This document defines two KDF algorithms, each paired with a
corresponding PRF algorithm as explained below:
* KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2104][FIPS-180-3]
* KDF_AES_128_CMAC based on AES-CMAC-PRF-128
[NIST-SP800-38B][FIPS197]
Both of these KDFs are based on the iteration-mode KDFs specified in
[NIST-SP800-108]. This means that they use an underlying
pseudorandom function (PRF) with a fixed-length output, 128 bits in
the case of the AES-CMAC, and 160 bits in the case of HMAC-SHA1. The
KDF generates an arbitrary number of output bits by operating the PRF
in a "counter mode", where each invocation of the PRF uses a
different input block differentiated by a block counter.
Each input block is constructed as follows:
( i || Label || Context || Output_Length )
Where
- "||": For any X || Y, "||" represents a concatenation
operation of the binary strings X and Y.
- i: A counter, a binary string that is an input to each
iteration of the PRF in counter mode. The counter
"i" is represented in a single octet. The number of
iterations will depend on the specific size of the
Output_Length desired for a given MAC. "i" always
starts = 1.
- Label: A binary string that clearly identifies the purpose
of this KDF's derived keying material. For TCP-AO,
we use the ASCII string "TCP-AO", where the last
character is the capital letter "O", not to be
confused with a zero. While this may seem like
overkill in this specification since TCP-AO only
describes one call to the KDF, it is included in
order to comply with FIPS 140 certifications.
- Context: The context argument provided to the KDF interface,
as described above in Section 3.1 .
- Output_Length: The length, in bits, of the key that the KDF
will produce. The Output_length is represented
within two octets. This length must be the size
required for the MAC algorithm that will use the
PRF result as a seed.
The output of multiple PRF invocations is simply concatenated. For
the Traffic_Key, values of multiple PRF invocations are concatenated
and truncated as needed to create a Traffic_Key of the desired
length. For instance, if one were using KDF_HMAC_SHA1, which uses a
160-bit internal PRF to generate 320 bits of data, one would execute
the PRF twice, once with i=1 and once with i=2. The result would be
the entire output of the first invocation concatenated with the
second invocation. For example,
Traffic_Key =
KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
KDF_alg(Master_Key, 2 || Label || Context || Output_length)
If the number of bits required is not an exact multiple of the output
size of the PRF, then the output of the final invocation of the PRF
is truncated as necessary.
3.1.1.1. KDF_HMAC_SHA1
For KDF_HMAC_SHA1:
- PRF for KDF_alg: HMAC-SHA1 [RFC2104][FIPS-180-3].
- Use: HMAC-SHA1(Key, Input).
- Key: Master_Key, configured by user, and passed to the KDF.
- Input: ( i || Label || Context || Output_Length)
- Output_Length: 160 bits.
- Result: Traffic_Key, used in the MAC function by TCP-AO.
3.1.1.2. KDF_AES_128_CMAC
For KDF_AES_128_CMAC:
- PRF for KDF_alg: AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197].
- Use: AES-CMAC(Key, Input).
- Key: Master_Key (see usage below)
- Input: ( i || Label || Context || Output_Length)
- Output_Length: 128 bits.
- Result: Traffic_Key, used in the MAC function by TCP-AO
The Master_Key in TCP-AO's current manual keying mechanism is a
shared secret, entered by an administrator. It is passed via an out-
of-band mechanism between two devices, and often between two
organizations. The shared secret does not have to be 16 octets, and
the length may vary. However, AES_128_CMAC requires a key of exactly
16 octets (128 bits) in length. We could mandate that
implementations force administrators to input Master_Keys of exactly
128-bit length when using AES_128_CMAC, and with sufficient
randomness, but this places undue burden on the implementors and
deployers. This specification RECOMMENDS that deployers use a
randomly generated 128-bit string as the Master_Key, but acknowledges
that deployers may not.
To handle variable length Master_Keys, we use the same mechanism as
described in [RFC4615], Section 3. First, we use AES_128_CMAC with a
fixed key of all zeros as a "randomness extractor", while using the
shared secret Master_Key, MK, as the message input, to produce a 128-
bit key Derived_Master_Key (K). Second, we use the result as a key,
and run AES-128_CMAC again, this time using the result K as the Key,
and the true input block as the Input to yield the Traffic_Key (TK)
used in the MAC over the message. The description follows:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ KDF-AES-128-CMAC +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : MK (Master_Key, the variable-length shared secret) +
+ : I (Input, i.e., the input data of the PRF) +
+ : MKlen (length of MK in octets) +
+ : len (length of M in octets) +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variable: K (128-bit key for AES-CMAC) +
+ +
+ Step 1. If MKlen is equal to 16 +
+ Step 1a. then +
+ K := MK; +
+ Step 1b. else +
+ K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1
In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
o If the Master_Key, MK, provided by the administrator is exactly 128
bits, then we use it as is.
o If it is longer or shorter than 128 bits, then we derive the key K
by applying the AES-CMAC algorithm using the 128-bit all-zero string
as the key and MK as the input message. This step is described in
1b.
In step 2, we apply the AES-CMAC algorithm again, this time using K
as the key and I as the input message.
The output of this algorithm returns TK, the Traffic_Key, which is
128 bits and is suitable for use in the MAC function on each TCP
segment of the connection.
3.1.1.3. Tips for User Interfaces Regarding KDFs
This section provides suggested representations for the KDFs in
implementation user interfaces (UIs). Following these guidelines
across common implementations will make interoperability easier and
simpler for deployers.
UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1".
UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply
"AES128".
The initial IANA registry values reflect these two entries.
UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO
settings. KDF_HMAC_SHA1 is preferred at this time because it has
wide support, being present in most implementations in the
marketplace.
3.2. MAC Algorithms
Each MAC_alg defined for TCP-AO has three fixed elements as part of
its definition:
- KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the
Traffic_Key.
- Key_Length: Length, in bits, required for the Traffic_Key used in
this MAC.
- MAC_Length: The final length of the bits used in the TCP-AO MAC
field. This value may be a truncation of the MAC
function's original output length.
MACs computed for TCP-AO have the following interface:
MAC = MAC_alg(Traffic_Key, Message)
where:
- MAC_alg: MAC Algorithm used.
- Traffic_Key: Variable; the result of KDF.
- Message The message to be authenticated, as specified in
[RFC5925], Section 5.1.
This document specifies two MAC algorithm options for generating the
MAC as used by TCP-AO:
* HMAC-SHA-1-96 based on [RFC2104] and [FIPS-180-3].
* AES-128-CMAC-96 based on [NIST-SP800-38B][FIPS197]
Both provide a high level of security and efficiency. The AES-128-
CMAC-96 is potentially more efficient, particularly in hardware, but
HMAC-SHA-1-96 is more widely used in Internet protocols and in most
cases could be supported with little or no additional code in today's
deployed software and devices.
An important aspect to note about these algorithms' definitions for
use in TCP-AO is the fact that the MAC outputs are truncated to 96
bits. AES-128-CMAC-96 produces a 128-bit MAC, and HMAC SHA-1
produces a 160-bit result. The MAC output is then truncated to 96
bits to provide a reasonable trade-off between security and message
size, for fitting into the TCP-AO option field.
3.2.1. The Use of HMAC-SHA-1-96
By definition, HMAC [RFC2104] requires a cryptographic hash function.
SHA1 will be that hash function used for authenticating and providing
integrity validation on TCP segments with HMAC.
The three fixed elements for HMAC-SHA-1-96 are:
- KDF_Alg: KDF_HMAC_SHA1.
- Key_Length: 160 bits.
- MAC_Length: 96 bits.
For:
MAC = MAC_alg (Traffic_Key, Message)
HMAC-SHA-1-96 for TCP-AO has the following values:
- MAC_alg: HMAC-SHA1.
- Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in
[RFC5925], Section 5.1.
3.2.2. The Use of AES-128-CMAC-96
In the context of TCP-AO, when we say "AES-128-CMAC-96", we actually
define a usage of AES-128 as a cipher-based MAC according to
[NIST-SP800-38B].
The three fixed elements for AES-128-CMAC-96 are:
- KDF_Alg: KDF_AES_128_CMAC.
- Key_Length: 128 bits.
- MAC_Length: 96 bits.
For:
MAC = MAC_alg (Traffic_Key, Message)
AES-128-CMAC-96 for TCP-AO has the following values:
- MAC_alg: AES-128-CMAC-96. [NIST-SP800-38B]
- Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in
[RFC5925], Section 5.1.
4. Security Considerations
This document inherits all of the security considerations of the
TCP-AO [RFC5925], the AES-CMAC [RFC4493], and the HMAC-SHA-1
[RFC2104] documents.
The security of cryptography-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the
overall system.
Care should also be taken to ensure that the selected key is
unpredictable, avoiding any keys known to be weak for the algorithm
in use. [RFC4086] contains helpful information on both key
generation techniques and cryptographic randomness.
Note that in the composition of KDF_AES_128_CMAC, the PRF needs a
128-bit / 16-byte key as the seed. However, for convenience to the
administrators/deployers, we did not want to force them to enter a
16-byte Master_Key. So we specified the sub-key routine that could
handle a variable length Master_Key, one that might be less than 16
bytes. This does NOT mean that it is safe for administrators to use
weak keys. Administrators are encouraged to follow [RFC4086] as
listed above. We simply attempted to "put a fence around
foolishness", as much as possible.
This document concerns itself with the selection of cryptographic
algorithms for the use of TCP-AO. The algorithms identified in this
document as "MUST implement" are not known to be broken at the
current time, and cryptographic research so far leads us to believe
that they will likely remain secure into the foreseeable future.
Some of the algorithms may be found in the future to have properties
significantly weaker than those that were believed at the time this
document was produced. Expect that new revisions of this document
will be issued from time to time. Be sure to search for more recent
versions of this document before implementing.
NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:
Two MAC algorithms and two corresponding KDFs are mandated as a
result of discussion in the TCPM WG, and in consultation with the
Security Area Directors. SHA-1 was selected because it is widely
deployed and currently has sufficient strength and reasonable
computational cost, so it is a "MUST" for TCP-AO today. The security
strength of SHA-1 HMACs should be sufficient for the foreseeable
future, especially given that the tags are truncated to 96 bits.
Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC
MD5) aren't practical on HMAC-SHA-1, but these types of analyses are
mounting and could potentially pose a concern for HMAC forgery if
they were significantly improved, over time. The security issues
driving the migration from SHA-1 to SHA-256 for digital signatures
[HMAC-ATTACK] do not immediately render SHA-1 weak for this
application of SHA-1 in HMAC mode.
AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but
may not yet have very wide implementation. AES-128 CMAC is also a
"MUST" to implement, in order to drive vendors toward its use, and to
allow for another MAC option, if SHA-1 were to be compromised.
5. IANA Considerations
IANA has created the following registry (http://www.iana.org).
Registry Name: Cryptographic Algorithms for TCP-AO Registration
Procedure: RFC Publication after Expert Review
Initial contents of this registry are:
Algorithm | Reference
----------------|-----------
SHA1 | [RFC5926]
AES128 | [RFC5926]
6. Acknowledgements
Eric "EKR" Rescorla, who provided a ton of input and feedback,
including a somewhat heavy re-write of Section 3.1.x, earning him an
author slot on the document.
Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly
create a first version here.
Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two
hash algorithms for TCP-AO is largely cut-and-pasted into various
sections of this document.
Jeff Schiller, Donald Eastlake, and the IPsec WG, whose [RFC4307] &
[RFC4835] text was consulted and sometimes used in the Requirements
Section 2 of this document.
(In other words, I was truly only an editor of others' text in
creating this document.)
Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues
with the inputs to PRFs for the KDFs. EKR was also of great
assistance in how to structure the text, as well as helping to guide
good cryptographic decisions.
The TCPM working group, who put up with all us crypto and routing
folks DoS'ing their WG for 2 years, and who provided reviews of this
document.
7. References
7.1. Normative References
[FIPS-180-3] FIPS Publication 180-3, "Secured Hash Standard",
FIPS 180-3, October 2008.
[FIPS197] FIPS Publications 197, "Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[NIST-SP800-108]
National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom
Functions, NIST SP800-108", SP 800- 108, October 2009.
[NIST-SP800-38B]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
The CMAC Mode for Authentication", SP 800-38B,
May 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, June 2006.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
7.2. Informative References
[HMAC-ATTACK] "On the Security of HMAC and NMAC Based on HAVAL, MD4,
MD5, SHA-0 and SHA-1", <http://
www.springerlink.com/content/00w4v62651001303> , 2006,
<http://eprint.iacr.org/2006/187>.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec",
RFC 4308, December 2005.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key
Exchange Protocol (IKE)", RFC 4615, August 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)", RFC 4835, April 2007.
Authors' Addresses
Gregory Lebovitz
Juniper Networks, Inc.
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
US
Phone:
EMail: gregory.ietf@gmail.com
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
US
Phone: 650-678-2350
EMail: ekr@rtfm.com
ISO Plain Language
On this page
§1What TCP-AO Needs from Cryptography
This document is a companion to RFC 5925, which defines the TCP Authentication Option. Like most modern security protocols, TCP-AO lets the people who run it choose which cryptographic algorithm they want to use to meet their security needs.
TCP-AO provides cryptographic authentication and message integrity verification between two end points. To do that it uses message authentication codes, which rely on shared keys. There are various ways to build such a code. Hash-based codes, the HMACs, are defined in RFC 2104. Cipher-based codes, the CMACs, are defined in NIST SP 800-38B.
This RFC defines the general requirements for the codes used in TCP-AO, both for the ones specified now and for any specified later. It specifies two code algorithms that every TCP-AO implementation must have, and two key derivation functions used to create the traffic keys the codes use. Those two functions are also required of every implementation.
TCP-AO is a TCP option that lets two computers check that the data between them has not been changed by anyone else. This RFC says which cryptographic algorithms to use for that check and how to turn a shared secret into the per-connection key each check needs.
§2.2The Required Algorithms
This is the first specification of the cryptography TCP-AO requires. It names two message authentication codes and two key derivation functions, and all four components MUST be implemented for an implementation to be fully compliant.
The required codes are HMAC-SHA-1-96, from RFC 2104 and FIPS 180-3, and AES-128-CMAC-96, from NIST SP 800-38B and FIPS 197. The required key derivation functions are KDF_HMAC_SHA1 and KDF_AES_128_CMAC.
The document also asks for room to change. TCP-AO is meant to support cryptographic agility, so it recommends things for future codes and key derivation functions in several places. For a future code in particular, it SHOULD protect at least 2^48 messages with a collision probability of less than one in 10^9.
Every implementation has to have two ways of checking the data and two ways of making the per-connection key. The RFC explains later why two of each were asked for.
- HMAC-SHA-1-96The message authentication code built on SHA-1. Widely used in Internet protocols.
- KDF_HMAC_SHA1The key derivation function that makes the key for HMAC-SHA-1-96. Shown in interfaces as SHA1.
- AES-128-CMAC-96The message authentication code built on AES. Potentially more efficient, especially in hardware.
- KDF_AES_128_CMACThe key derivation function that makes the key for AES-128-CMAC-96. Shown in interfaces as AES128.
§3.1Key Derivation Functions
TCP-AO uses two classes of cryptographic algorithm. Key derivation functions name a pseudorandom function and use a Master_Key and some connection-specific input with that function to produce the Traffic_Keys, the keys used to authenticate and integrity check the individual TCP segments. Message authentication code algorithms take a key and a message and produce an authentication tag used to verify the integrity and authenticity of those messages.
In TCP-AO these algorithms are always used in pairs. Each code algorithm MUST specify the key derivation function to be used with it, though a function MAY be used with more than one code algorithm.
The functions used by the current manual keying of TCP-AO have a fixed interface: Traffic_Key = KDF_alg(Master_Key, Context, Output_Length).
- KDF_alg is the specific pseudorandom function that is the building block of the derived key.
- Master_Key is the key shared by both peers in TCP-AO's manual key mode, entered through some interface into their configurations. It is the seed for the function. It is assumed to be a human-readable pre-shared key, so its length may vary. Master_Keys SHOULD be random, but might not be, for example if a user chooses a bad one. For interoperability, the management interface that configures the pre-shared key MUST accept ASCII strings and SHOULD also allow any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
- Context is a binary string holding information about the specific connection that the derived keying material belongs to, as defined in Section 5.2 of RFC 5925.
- Output_Length is the length in bits of the key the function will produce, which must be the size the code algorithm needs for its seed.
When it runs, the function generates a string of Output_Length bits from the Master_Key and the context. That string can then be used as a key for any algorithm that takes a key of that length, and a function MAY specify a maximum Output_Length.
The two concrete functions are KDF_HMAC_SHA1, based on the HMAC-SHA1 pseudorandom function, and KDF_AES_128_CMAC, based on the AES-CMAC-PRF-128 function. Both are based on the iteration-mode functions of NIST SP 800-108, which use an underlying pseudorandom function with a fixed-length output, 128 bits for the AES-CMAC and 160 bits for HMAC-SHA1. The output of any length is produced by running the function in a counter mode, where each call uses a different input block distinguished by a block counter.
Each input block is built as (i || Label || Context || Output_Length), where || means concatenation. The counter i is a single octet and always starts at 1. The Label is a binary string that clearly identifies the purpose of the derived keying material; for TCP-AO the ASCII string "TCP-AO" is used, with a capital letter O. The RFC says this label looks like overkill in this specification, since TCP-AO describes only one call to the function, but it is there to comply with FIPS 140 certifications.
The output of several calls is simply concatenated, and truncated to the wanted length. With KDF_HMAC_SHA1, whose internal function produces 160 bits, generating 320 bits means running the function twice, once with i = 1 and once with i = 2, and concatenating the results.
The per-connection key is computed from the shared secret, the connection details and the length wanted. The computation runs a one-way function several times with a counter, so that different connections get different keys even from the same secret.
- i || Label || Context || Output_Length The input block of each call.
- i The counter, one octet, starting at 1.
- Label The ASCII string TCP-AO, with a capital letter O.
- Context Information about the specific connection.
- Output_Length The length in bits of the key wanted.
§3.1.1.2KDF_AES_128_CMAC and Keys of Any Length
The Master_Key of TCP-AO's manual keying is a shared secret entered by an administrator and passed between two devices out of band, often between two organizations. It does not have to be 16 octets and its length may vary. AES-128-CMAC, however, needs a key of exactly 16 octets, 128 bits, long.
The RFC does not want to force administrators to enter a 16-byte key, so it uses the mechanism of Section 3 of RFC 4615. First, AES-128-CMAC with a fixed key of all zeros is used as a randomness extractor, with the shared secret as the message input, to produce a 128-bit Derived_Master_Key, K. Second, that result is used as the key and AES-128-CMAC is run again, this time with the true input block as the input, to yield the Traffic_Key, TK, used in the code over the message.
The steps are: if the Master_Key is exactly 128 bits, use it as is; otherwise derive K by applying AES-CMAC with the 128-bit all-zero string as the key and the Master_Key as the input message. Then apply AES-CMAC again, with K as the key and the input block as the message. The result is the Traffic_Key, 128 bits long, which is what the code function uses on each TCP segment of the connection.
The RFC RECOMMENDS that deployers use a randomly generated 128-bit string as the Master_Key, but acknowledges that deployers may not. It says it is trying to put a fence around foolishness, as much as possible.
The AES-based option needs a key of exactly 16 bytes, but the shared secret an administrator types can be any length. The RFC turns a secret of any length into a 16-byte key by running it through the cipher-based code with a fixed all-zero key first.
Input : MK (the variable-length shared secret)
I (the input block of the pseudorandom function)
MKlen (length of MK in octets)
len (length of the message in octets)
Output: TK (the Traffic_Key, 128 bits)
Step 1. If MKlen == 16:
K := MK;
else:
K := AES-CMAC(0^128, MK, MKlen);
Step 2. TK := AES-CMAC(K, I, len);
return TK;§3.2The Message Authentication Codes
Each code algorithm defined for TCP-AO has three fixed elements in its definition. KDF_Alg is the name of the key derivation function used to generate the Traffic_Key. Key_Length is the length in bits required for that Traffic_Key. MAC_Length is the final length of the bits used in the TCP-AO MAC field, which may be a truncation of the output the code function normally produces.
The interface is MAC = MAC_alg(Traffic_Key, Message), where Message is the message to be authenticated as specified in Section 5.1 of RFC 5925.
Two code options are specified. HMAC-SHA-1-96 is based on RFC 2104 and FIPS 180-3, and AES-128-CMAC-96 is based on NIST SP 800-38B and FIPS 197. Both give a high level of security and efficiency. AES-128-CMAC-96 is potentially more efficient, particularly in hardware, but HMAC-SHA-1-96 is more widely used in Internet protocols and in most cases could be supported with little or no additional code in today's deployed software and devices.
One detail matters for the design: the outputs are truncated to 96 bits. AES-128-CMAC produces a 128-bit code and HMAC-SHA-1 produces a 160-bit result, and the output is then cut down to 96 bits as a trade-off between security and message size, so that it fits in the TCP-AO option field.
For HMAC-SHA-1-96 the three elements are KDF_HMAC_SHA1, a key length of 160 bits and a code length of 96 bits. For AES-128-CMAC-96 they are KDF_AES_128_CMAC, a key length of 128 bits and a code length of 96 bits.
The code that checks the data comes in two forms, one built on SHA-1 and one built on AES. Both produce a fixed-size tag of 96 bits, cut down from their natural output so that it fits in the TCP option.
| Property | HMAC-SHA-1-96 | AES-128-CMAC-96 |
|---|---|---|
| Key derivation function | KDF_HMAC_SHA1 | KDF_AES_128_CMAC |
| Traffic key length | 160 bits | 128 bits |
| Code length in the TCP-AO field THIS RFC | 96 bits | 96 bits |
| Based on | RFC 2104 and FIPS 180-3 | NIST SP 800-38B and FIPS 197 |
| Name in a user interface | SHA1 | AES128 |
§3.1.1.3What a Configuration Screen Should Show
The RFC gives suggested names for the two key derivation functions so that different products can be set up the same way. A user interface SHOULD refer to KDF_HMAC_SHA1 simply as "SHA1" and KDF_AES_128_CMAC simply as "AES128". The initial values in the IANA registry match those two entries.
A user interface SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO settings. KDF_HMAC_SHA1 is preferred at this time because it has wide support, being present in most of the implementations in the marketplace.
The RFC asks for the two options to be called SHA1 and AES128 in configuration menus, so that a network engineer sees the same names on every product, and it asks for SHA1 to be the default because most products already have it.
§4Security Considerations
This document inherits all the security considerations of TCP-AO in RFC 5925, of AES-CMAC in RFC 4493 and of HMAC-SHA-1 in RFC 2104.
The security of a system built on cryptography depends on the strength of the algorithms chosen and on the strength of the keys used with them. It also depends on the engineering of the protocol, so that there is no non-cryptographic way to get around the protection.
Care should be taken that the selected key is unpredictable and avoids any key known to be weak for the algorithm in use. RFC 4086 has helpful information on key generation and on cryptographic randomness.
The RFC notes that in KDF_AES_128_CMAC the function needs a 128-bit key as its seed, and that it did not want to force administrators to enter a 16-byte Master_Key, so a sub-key routine was specified that handles a variable length one. That does not make it safe for administrators to use weak keys, and it is encouraged to follow RFC 4086. The RFC says it simply tried to put a fence around foolishness, as much as possible.
The algorithms marked as MUST implement are not known to be broken at the time of writing, and the RFC expects new revisions of the document as time goes by, so implementers should look for a more recent version.
Why two code algorithms were mandated: SHA-1 was selected because it is widely deployed and has sufficient strength and reasonable computational cost, so it is a MUST for TCP-AO today. The security strength of SHA-1 HMACs should be enough for the foreseeable future, especially as the tags are truncated to 96 bits. Recently exposed vulnerabilities in other codes, such as MD5, are not practical against HMAC-SHA-1, though such analyses are mounting and could one day matter. The security issues driving the move from SHA-1 to SHA-256 for digital signatures do not immediately make SHA-1 weak in HMAC mode. AES-128 CMAC is considered stronger than SHA-1 but may not yet have very wide implementation, and it is also a MUST so that vendors move towards it and so there is another option if SHA-1 is compromised.
The choice of algorithm is only half of it. A strong algorithm with a weak key is still weak, so the RFC keeps pointing at the guidance on generating random keys, and it explains why it asked for two algorithms rather than one.
§5IANA Considerations
IANA has created a registry named "Cryptographic Algorithms for TCP-AO Registration", with the procedure RFC Publication after Expert Review. Its initial contents are two entries: SHA1 and AES128, both with this RFC as their reference.
The two algorithms were given registry names, SHA1 and AES128, so that products can name them the same way.