draft-ietf-tcpm-tcp-ao-crypto-00.txt   draft-ietf-tcpm-tcp-ao-crypto-01.txt 
TCPM G. Lebovitz TCPM G. Lebovitz
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Standards Track E. Rescorla Intended status: Standards Track E. Rescorla
Expires: March 9, 2010 RTFM Expires: May 1, 2010 RTFM
September 05, 2009 October 28, 2009
Cryptographic Algorithms, Use, & Implementation Requirments for TCP Cryptographic Algorithms for TCP's Authentication Option, TCP-AO
Authentication Option draft-ietf-tcpm-tcp-ao-crypto-01
draft-ietf-tcpm-tcp-ao-crypto-00
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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 March 9, 2010. This Internet-Draft will expire on May 1, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3
2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4 2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4
3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4
3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5
3.1.1. The Use of KDF_HMAC_SHA1 . . . . . . . . . . . . . . . 7 3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . . 6
3.1.2. The Use of KDF_AES_128_CMAC . . . . . . . . . . . . . 8
3.1.3. Tips for User Interfaces regarding KDFs . . . . . . . 9
3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11
3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11
4. Change History (RFC Editor: Delete before publishing) . . . . 12 4. Change History (RFC Editor: Delete before publishing) . . . . 12
5. Needs Work in Next Draft (RFC Editor: Delete Before 5. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 13 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document is a companion to TCP-AO [TCP-AO] This document is a companion to TCP-AO [TCP-AO]
[I-D.ietf-tcpm-tcp-auth-opt]. Like most security protocols, TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols,
allows users to chose which cryptographic algorithm(s) they want to TCP-AO allows users to chose which cryptographic algorithm(s) they
use to meet their security needs. want to use to meet their security needs.
TCP-AO provides cryptographic authentication and message integrity TCP-AO provides cryptographic authentication and message integrity
verification between to end-points. In order to accomplish this verification between to end-points. In order to accomplish this
function, one employs message authentication codes (MACs). There are function, message authentication codes (MACs) are used, which then
various ways to create MACs. The use of hashed-based MACs (HMAC) in rely on shared keys. There are various ways to create MACs. The use
Internet protocols is defined in [RFC2104]. The use of cipher-based of hashed-based MACs (HMAC) in Internet protocols is defined in
MACs (CMAC) in Internet protocols is defined in [RFC4493]. [RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols
is defined in [RFC4493].
This RFC discusses the requirements for implementations to support This RFC defines the general requirements for MACs used in TCP-AO,
two MACs used in TCP-AO, both now and in the future, and includes the both for currently specified MACs and for any future specified MACs.
rationale behind the present and future requirements. The document It then specifies two MAC algorithms required in all TCP-AO
then specifies the use of those two MACs with TCP-AO. implementations. It also specifies two key derivations 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. Requirements
2.1. Requirements Language 2.1. Requirements Language
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in
[RFC2119].
2.2. Algorithm Requirements 2.2. Algorithm Requirements
In this the first RFC specifying cryptography for TCP-AO, we specify This is the initial specification of required cryptography for
two MAC algorithms. Both MUST be implemented in order for the TCP-AO, and indicates two MAC algorithms and two KDFs. All four
implementation to be fully compliant with this RFC. components MUST be implemented in order for the implementation to be
fully compliant with this RFC.
This table lists authentication algorithms for the TCP-AO protocol. The following table indicates the required MAC algorithms and KDFs
for TCP-AO:
Requirement Authentication Algorithm Requirement Authentication Algorithm
------------ ------------------------ ------------ ------------------------
MUST HMAC-SHA-1-96 [RFC2404] MUST HMAC-SHA-1-96 [RFC2404]
MUST AES-128-CMAC-96 [RFC4493] MUST AES-128-CMAC-96 [RFC4493]
Requirement Key Derivation Function (KDF) Requirement Key Derivation Function (KDF)
------------- ------------------------ ------------- ------------------------
MUST KDF_HMAC_SHA1 MUST KDF_HMAC_SHA1
MUST KDF_AES_128_CMAC MUST KDF_AES_128_CMAC
NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:
The security issues driving the migration from SHA-1 to SHA-256 for Two MAC algorithms and two corresponding KDFs are mandated as a
digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately result of discussion in the TCPM WG, and in consultation with the
render SHA-1 weak for this application of SHA-1 in HMAC mode. The Security Area Directors. SHA-1 was selected because it is widely
security strength of SHA-1 HMACs should be sufficient for the deployed and currently has sufficient strength and reasonable
foreseeable future, especially given that the tags are truncated to computational cost, so it is a "MUST" for TCP-AO today. The security
96 bits. However, while it's clear that the attacks aren't practical strength of SHA-1 HMACs should be sufficient for the foreseeable
on SHA-1, these types of analysis are mounting and could potentially future, especially given that the tags are truncated to 96 bits.
pose a concern for HMAC forgery if they were significantly improved,
over time. In anticipation of SHA-1's growing less dependable over Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC
time, but given its wide deployment and current strength, it is a MD5) aren't practical on SHA-1, but these types of analyses are
"MUST" for TCP-AO today. AES-128 CMAC is considered to be far mounting and could potentially pose a concern for HMAC forgery if
stronger algorithm, but may not yet have very wide implementation. they were significantly improved, over time. The security issues
It is also a "MUST" to implement, in order to drive vendors toward driving the migration from SHA-1 to SHA-256 for digital signatures
its use. [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.
2.3. Requirements for Future MAC Algorithms 2.3. Requirements for Future MAC Algorithms
Since this document provides cryptographic agility, it is also TCP-AO is intended to support cryptographic agility. As a result,
important to establish requirements for future MAC algorithms. The this document includes recommendations in various places for future
TCPM WG should restrict any future MAC algorithms for this MAC and KDF algorithms when used for TCP-AO. For future MAC
specification to ones that can protect at least 2**48 messages with a algorithms specifically, they SHOULD protect at least 2**48 messages
probability that a collision will occur of less than one in a with a collision probability of less than one in 10**9.
billion.
[Reviewers: Are there any other requirements we want/need to place in [Reviewers: Are there any other requirements we want/need to place in
here? RFC EDITOR: Please delete this text before publishing as RFC] here? RFC EDITOR: Please delete this note before publishing as RFC]
3. Algorithms Specified 3. Algorithms Specified
TCP-AO refers to this document saying that the MAC mechanism employed TCP-AO requires two classes of cryptographic algorithms used on a
for a connection is listed in the TAPD entry, and is chosen from a particular connection, and refers to this document to define them
list of MACs both named and described in this document. both:
TCP-AO requires two classes of cryptographic algorithms:
(1) Key Derivation Functions (KDFs) which name a pseudorandom (1) Key Derivation Functions (KDFs) which name a pseudorandom
function (PRF) and use a Master_Key and some connection- function (PRF) and use a Master_Key and some connection-
specific Input with that PRF to produce Traffic_Keys, the specific input with that PRF to produce Traffic_Keys, the
keys suitable for authenticating and integrity checking keys suitable for authenticating and integrity checking
individual TCP segments. individual TCP segments, as described in TCP-AO.
(2) Message Authentication Code (MAC) algorithms which take a (2) Message Authentication Code (MAC) algorithms which take a
key and a message and produce an authentication tag which key and a message and produce an authentication tag which
can be used to verify the integrity of the messages sent can be used to verify the integrity and authenticity of
over the wire. those messages.
In TCP-AO, these algorithms are always used in pairs. Each MAC In TCP-AO, these algorithms are always used in pairs. Each MAC
algorithm MUST specify the KDF to be used with that MAC algorithm. algorithm MUST specify the KDF to be used with that MAC algorithm.
However, a KDF MAY be used with more than one MAC algorithm. However, a KDF MAY be used with more than one MAC algorithm.
3.1. Key Derivation Functions (KDFs) 3.1. Key Derivation Functions (KDFs)
TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP-
AO's current manual keying have the following interface: AO's current manual keying have the following interface:
Derived_Key = KDF(Master_Key, Input, Output_Length) Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)
where: where:
- KDF: the specific pseudorandom function that is the - KDF_alg: the specific pseudorandom function (PRF) that is
basic building block used in constructing the given the basic building block used in constructing the
Derived_Key. given Traffic_Key.
- Master_Key: The Master_Key as will be stored into the - Master_Key: In TCP-AO's manual key mode, this is a key shared
associated TCP-AO TAPD entry. In TPC-AO's manual by both peers, entered via some interface to their
key mode, this is a shared key that both peers respective configurations. The Master_Key is used
enter via some user interface into their respective as the seed for the KDF. We assume that this is a
configurations. The Master_Key is the seed for the human-readable pre-shared key (PSK), thus we assume
KDF. We assume that, in manual key mode, this is a it is of variable length. Master_Keys SHOULD be
human readable pre-shared key (PSK), thus we assume random, but might not be (e.g., badly chosen by the
that it is of variable length. Users SHOULD chose user).
random strings for the Master_Key. However, we
assume that some users may not.
- Input: the input data for the KDF, in conformance with - Context : A binary string containing information related to
[NIST-SP800-108], is a concatonation of: the specific connection for this derived keying
material, as defined in
[I-D.ietf-tcpm-tcp-auth-opt], Section 7.2]
( i || Label || Context || Output_Length) - 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.
Where When invoked, a KDF generates a string of length Output_Length bits
based on Master_Key and context value. This result may then be used
as a cryptographic key for any algorithm which takes an Output_Length
length key. A KDF MAY specify a maximum Output_Length parameter.
- "||": Represents a concatonation operation, between two 3.1.1. Concrete KDFs
values X || Y.
- i: A counter, a binary string that is an input to This document defines two KDF algorithms, each paired with a
each iteration of a PRF in counter mode and corresponding PRF algorithm as explained below:
(optionally) in feedback mode. This will depend
on the specific size of the Output_Length desired
for an given MAC.
- Label: A binary string that clearly identifies the * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404]
purpose of this KDF's derived keying material. * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615]
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 : A binary string containing information related to Each
the specific connection for this derived keying
material. In TCP-AO, this is the Data_Block, as
defined in [I-D.ietf-tcpm-tcp-auth-opt], Section
7.1]
- Output_Length: The length in bits of the key that the KDF Both of these KDFs are based on the iteration mode KDFs specified in
will produce. This length must be the size [NIST-SP800-108]. This means that they use an underlying
required for the MAC algorithm that will use the pseudorandom function (PRF) with a fixed-length output lengths, 128
PRF result as a seed. 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.
NOTE: The cited NIST document on KDFs calls for an input: (i || Label Each input block is constructed as follows:
|| 0x00 || Context || Output_Length). That document states that the
"0x00" is an all zero octet and is "an optional data field used to
indicate a separation of different variable length data fields". In
our case, the "Label" is specified and fixed, thus its data field is
fixed, not variable, so there is no need for the 0x00 separator.
Thus, we have dropped it.
When invoked, a KDF runs a certain PRF, using the Master_Key as the ( i || Label || Context || Output_Length)
seed, and Input as the message input and produces a result of
Output_Length bits. This result may then be used as a cryptographic
key for any algorithm which takes an Output_Length length key as its
seed. A KDF MAY specify a maximum Output_Length parameter.
This document defines two KDFs: Where
* KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] - "||": For any X || Y, "||" represents a concatonation
* KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] operation of the binary strings X and Y.
Other KDFs may be defined in future revisions of this document, and - i: A counter, a binary string that is an input to each
SHOULD follow this same format as described above. When doing so, iteration of the PRF in counter mode. The number of
note: iterations will depend on the specific size of the
Output_Length desired for a given MAC.
1. The underlying PRFs specified in this document have fixed sized - Label: A binary string that clearly identifies the purpose
output lengths, 128 bits in the case of the AES-CMAC, and 160 of this KDF's derived keying material. For TCP-AO we
bits in the case of HMAC-SHA1. use the ASCII string "TCP-AO", where the last
2. It is possible to generate an arbitrary number of output bits character is the capital letter "O", not to be
with some given PRF by operating it in a feedback or counter confused with a zero. While this may seem like
mode. The KDFs described in [NIST-SP800-108] incorporate this overkill in this specification since TCP-AO only
feature, hence the counter "i", which creates leading "0". describes one call to the KDF, it is included in
3. Each MAC needs a key of a specific length. order to comply with FIPS 140 certifications.
4. Not totally uncoincidentally, the KDFs we have chosen to use
with each MAC happen to generate the right key size for use with
the MAC, thus avoiding the need for the procedure in (2).
5. If one wanted to use these KDFs with a MAC requiring a longer
key (e.g., HMAC-SHA-256) one would need to use the procedure:
KDF_X = PRF_X(Master_Key, Input).
3.1.1. The Use of KDF_HMAC_SHA1 - Context : The context argument provided to the KDF interface,
as described above in Section 3.1 .
For: - 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.
PRF(Master_Key, Input, Output_Length) The ouput of mutiple 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=0 and once with i=1. The result would be the
entire output of the first invocation concatenated with the second
invocation. E.g.,
KDF_HMAC_SHA1 for TCP-AO has the following values: Traffic_Key =
KDF_alg(Master_Key, 0 || Label || Context || Output_length) ||
KDF_alg(Master_Key, 1 || Label || Context || Output_length)
- PRF: HMAC-SHA1 [RFC2404] If the number of bits required is not an even multiple of the output
- Master_Key: As provided in the MKT size of the PRF, then the output of the final invocation of the PRF
- Input: is truncated as necessary.
- i: "0" 3.1.1.1. KDF_HMAC_SHA1
- Label: "TCP-AO"
- Context: Data_Block
- Output_Length 160
- Result: Traffic_Key
The result is computed by performing HMAC-SHA1(Master_Key, Input) and For KDF_HMAC_SHA1:
then taking the first (high order) Output_Length, 160 here, bits.
This result is the TCP-AO Traffic_Key. The Traffic_Key is then used
as the seed for the MAC function on each segment of the connection.
3.1.2. The Use of KDF_AES_128_CMAC - PRF for KDF_alg: HMAC-SHA1 [RFC2404].
For: - Use: HMAC-SHA1(Key, Input).
PRF(Master_Key, Input, Output_Length) - Key: Master_Key, configured by user, and passed to the KDF.
KDF_AES_128_CMAC for TCP-AO has the following values: - Input: ( i || Label || Context || Output_Length)
- PRF: AES-CMAC-PRF-128 [RFC4615] - Output_Length: 160 bits.
- Master_Key: As provided in the MKT
- Input:
- i: "0" - Result: Traffic_Key, used in the MAC function by TCP-AO.
- Label: "TCP-AO"
- Context: Data_Block
- Output_Length 128
- Result: Traffic_Key
Whereas the KDF_SHA1 used only one round to produce the Traffic_Key, 3.1.1.2. KDF_AES_128_CMAC
the KDF_AES will take two steps. The reasoning follows:
For KDF_AES_128_CMAC:
- PRF for KDF_alg: AES-CMAC-PRF-128 [RFC4615].
- 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 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- shared secret, entered by an administrator. It is passed via an out-
of-band mechanism between two devices, and often between two of-band mechanism between two devices, and often between two
organizations. The shared secret does not have to be 16 octets, and organizations. The shared secret does not have to be 16 octets, and
the length may vary. However, AES_128_CMAC requires a key of 16 the length may vary. However, AES_128_CMAC requires a key of exactly
octets (128 bits) in length. We could mandate that implementations 16 octets (128 bits) in length. We could mandate that
force administrators to input Master_Keys of exactly 128 bit length, implementations force administrators to input Master_Keys of exactly
and with sufficient randomness, but this places undue burdon on the 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 deployers. This specification RECOMMENDS that deployers use a
randomly generated 128-bit string as the Master_Key, but acknowledges randomly generated 128-bit string as the Master_Key, but acknowledges
that deployers may not. that deployers may not.
To handle variable length Master_Keys we use a similar mechanism to To handle variable length Master_Keys we use the same mechanism as
the AES-CMAC-PRF-128 mechanism represented in [RFC4615], Sect 3. We described in [RFC4615], Sect 3. First we use AES_128_CMAC with a
do a two step process. 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
First we use AES_128_CMAC with a fixed key as a "randomness bit key Derived_Master_Key (K). Second, we use the result as a key,
extractor", while using the shared secret Master_Key, MK, as the and run AES-128_CMAC again, this time using the result K as the Key,
message input to produce a 128 bit key K. and the true input block as the Input to yield the Traffic_Key (TK)
used in the MAC over the message. The description follows:
Second, we run AES_128_CMAC again, this time using K as the key and
the normal Input I (as described above) as the message input to
produce Traffic_Key, TK.
Therefore this KDF is always a 2 step function, as follows (borrowing
the format from [RFC4615]):
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ KDF-AES-128-CMAC + + KDF-AES-128-CMAC +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ + + +
+ Input : MK (Master_Key, the variable-length shared secret) + + Input : MK (Master_Key, the variable-length shared secret) +
+ : I (Input, i.e., the input data of the PRF) + + : I (Input, i.e., the input data of the PRF) +
+ : MKlen (length of MK in octets) + + : MKlen (length of MK in octets) +
+ : len (length of I in octets) + + : len (length of M in octets) +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)+
+ + + +
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
+ Variable: K (128-bit key for AES-CMAC) + + Variable: K (128-bit key for AES-CMAC) +
+ + + +
+ Step 1. K := AES-CMAC(0^128, MK, MKlen); + + Step 1. If MKlen is equal to 16 +
+ Step 2. TK := AES-CMAC(K, I, len); + + Step 1a. then +
+ return TK; + + K := MK; +
+ Step 1b. else +
+ K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; +
+ + + +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1: The AES-CMAC-PRF-128 Algorithm for TCP-AO Figure 1
o In Step 1, the 128-bit key, K, for AES-CMAC is derived by In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
applying the AES-CMAC algorithm using the 128-bit all-zero string
as the key and MK as the input message.
o In Step 2, we apply the AES-CMAC algorithm again, this time o If the Master_Key, MK, provided by the administrator is exactly 128
using the output of Step 1, K, as the key. The input message is bits, then we use it as-is.
now I, just as it is described at the beginning of this section.
The output of this algorithm returns TK, the Traffic_Key, which is
128 bits suitable for the seed into the AES-CMAC operation over
the actual TCP segment.
3.1.3. Tips for User Interfaces regarding KDFs 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
step 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 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 This section provides suggested representations for the KDFs in
implementation user interfaces. Following these guidelines across implementation user interfaces. Following these guidelines across
common implementations will make interoperability easier and simpler common implementations will make interoperability easier and simpler
for deployers. for deployers.
UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 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 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply
"AES128". "AES128".
The initial IANA registry values will reflect these two entries.
UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO
settings. KDF_HMAC_SHA1 is preferred at this time solely because it settings. KDF_HMAC_SHA1 is preferred at this time because it has
has wide support, being present in most implementations in the wide support, being present in most implementations in the
marketplace. When such a time arrives as KDF_AES_128_CMAC becomes marketplace.
widely deployed, this document should be updated so that it becomes
the default KDF on implementations.
3.2. MAC Algorithms 3.2. MAC Algorithms
MACs for TCP-AO have the following interface: Each MAC_alg defined for TCP-AO has three fixed elements as part of
its definition:
MAC (Traffic_Key(KDF), Message, Truncation) - 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
- Output: 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.
where: MACs computed for TCP-AO have the following interface:
- MAC-algo: MAC Algorithm used MAC = MAC_alg(Traffic_Key, Message)
- Traffic_Key: Variable; Result of KDF.
- KDF: Name of the TCP-AO KDF used where:
- Key_Length: Length in bits required for the Traffic_Key used in - MAC_alg: MAC Algorithm used
this MAC - Traffic_Key: Variable; the result of KDF.
- Truncation: Length in bits to which the final MAC result is - Message The message to be authenticated, as specified in
truncated before being placed into TCP-AO header [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
This document specifies two MAC algorithm options for generating the This document specifies two MAC algorithm options for generating the
MAC for TCP-AO's option header: MAC as used by TCP-AO:
* HMAC-SHA-1-96 based on [RFC2404] * HMAC-SHA-1-96 based on [RFC2404]
* AES-128-CMAC-96 based on [RFC4493] * AES-128-CMAC-96 based on [RFC4493]
Both provide a high level of security and efficiency. The AES-128- Both provide a high level of security and efficiency. The AES-128-
CMAC-96 is potentially more efficient, particularly in hardware, but CMAC-96 is potentially more efficient, particularly in hardware, but
HMAC-SHA-1-96 is more widely used in Internet protocols and in most 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 cases could be supported with little or no additional code in today's
deployed software and devices. deployed software and devices.
An important aspect to note about these algorithms' definitions for 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 use in TCP-AO is the fact that the MAC outputs are truncated to 96
skipping to change at page 11, line 11 skipping to change at page 11, line 25
produces a 160 bit result. The MAC output are then truncated to 96 produces a 160 bit result. The MAC output are then truncated to 96
bits to provide a reasonable tradeoff between security and message bits to provide a reasonable tradeoff between security and message
size, for fitting into the TCP-AO header. size, for fitting into the TCP-AO header.
3.2.1. The Use of HMAC-SHA-1-96 3.2.1. The Use of HMAC-SHA-1-96
By definition, HMAC [RFC2104] requires a cryptographic hash function. By definition, HMAC [RFC2104] requires a cryptographic hash function.
SHA1 will be that has function used for authenticating and providing SHA1 will be that has function used for authenticating and providing
integrity validation on TCP segments with HMAC. integrity validation on TCP segments with HMAC.
For: The three fixed elements for HMAC-SHA-1-96 are:
MAC (Traffic_Key(KDF), Message, Truncation) - KDF_Alg: KDF_HMAC_SHA1.
- Key_Length: 160 bits.
- Output: 96 bits.
HMAC-SHA-1-96 for TCP-AO has the following values: For:
- MAC-algo: MAC Algorithm used MAC = MAC_alg (Traffic_Key, Message)
- Traffic_Key: Variable; Result of KDF.
- KDF: KDF_HMAC_SHA1 HMAC-SHA-1-96 for TCP-AO has the following values:
- Key_Length: 160 bits - MAC_alg: HMAC-SHA1
- Truncation: 96 bits - Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in
[I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
3.2.2. The Use of AES-128-CMAC-96 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 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 define a usage of AES-128 as a cipher-based MAC according to
[NIST-SP800-38B]. [NIST-SP800-38B].
For: The three fixed elements for AES-128-CMAC-96 are:
MAC (Traffic_Key(KDF), Message, Truncation)
AES-128-CMAC-96 for TCP-AO has the following values: - KDF_Alg: KDF_AES_128_CMAC.
- Key_Length: 128 bits.
- Output: 96 bits.
- MAC-algo: AES-128-CMAC-96 [RFC4493] For:
- Traffic_Key: Variable; Result of KDF.
- KDF: KDF_AES_128_CMAC MAC = MAC_alg (Traffic_Key, Message)
- Key_Length: 128 bits AES-128-CMAC-96 for TCP-AO has the following values:
- Truncation: 96 bits
According to [RFC4493], by default, "the length of the output of AES- - MAC_alg: AES-128-CMAC-96 [RFC4493]
128-CMAC is 128 bits. It is possible to truncate the MAC. The - Traffic_Key: Variable; the result of the KDF.
result of the truncation is then taken in most significant bits first - Message: The message to be authenticated, as specified in
order. The MAC length must be specified before the communication [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
starts, and it must not be changed during the lifetime of the key."
Therefore, we explicitly specify the employed MAC length for TCP-AO
to be 96 bits.
4. Change History (RFC Editor: Delete before publishing) 4. Change History (RFC Editor: Delete before publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only. [NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.] Please remove before publishing as RFC.]
draft-ietf...-02 - 6th submission
o 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification
o
draft-ietf...-01 - 5th submission
o simplified title of document - Touch
o structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the
description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a
template (of sorts) in both sections that can be easily re-used by
any future KDF definition.
o in 3.1, switched "Derived_Key" back to "Traffic_Key" in order to
sync with -auth-opt spec.
o in 3.1, for Traffic_Key definition, changed the name of the
element "Input" to "Context", and removed the hard binding to
NIST-SP800-108 at the generic interface level. The NIST inclusion
is still present in the concrete definitions of the two presented
KDF's, but this way, if NIST changes, or if the community wants to
define some other, non-NIST-like KDFs, the interface is flexible
enough to handle that. Changed "KDF" to "KDF-alg".
o in 3.2, clarified that the output of the function is called "MAC
=", to have a similar look and feel to sect 3.1's function. also
changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from
the function parameters, as it is specified as a fixed element for
each MAC defined, but not passed as a parameter of the function.
o sect 3.2 - removed "truncation" from interface definition, and
placed it as a fixed element of the MAC definition. sect 3.2.1 and
3.2.2 - changed "truncation:" field to "Output:". Removed text
about RFC4493 from end of 3.2.2.
o sect 3.1.1.2, changed back to follow 4615 exactly (agreement with
polk, mcgrew, lebovitz, ekr)
o sect 3.1.1.3, deleted the following: "When such a time arrives as
KDF_AES_128_CMAC becomes widely deployed, this document should be
updated so that it becomes the default KDF on implementations."
o added the two IANA values SHA1 and AES128 to IANA section
o Minor text change in section 3.1 and 3.2, to the definition of
"Context" in both - Joe Touch
o minor text change in 3.1.1 clarifying that the concatenation is of
binary strings - Joe Touch
o copy edits for read-ability throughout - Touch
draft-ietf...-00 - 4th submission draft-ietf...-00 - 4th submission
Submitting draft-lebovitz...-02 as a WG document. Added EKR as co- o Submitting draft-lebovitz...-02 as a WG document. Added EKR as
author, and gave him credit for rewrite of sect 3.1.x . co- author, and gave him credit for rewrite of sect 3.1.x .
lebovitz...-02 - 3rd submission draft-lebovitz...-02 - 3rd submission
o cleaned up explanation in 3.1.2 o cleaned up explanation in 3.1.2
o in 3.1.2, changed the key extractor mechanism back, from using an o in 3.1.2, changed the key extractor mechanism back, from using an
alphanumeric string for the fixed key C to use 0^128 as the key alphanumeric string for the fixed key C to use 0^128 as the key
(as it was in -00) (Polk & Ekr) (as it was in -00) (Polk & Ekr)
o deleted cut-and-paste error text from sect 3.1 between "label" and o deleted cut-and-paste error text from sect 3.1 between "label" and
"context" "context"
o changed "conn_key" to "traffic_key" throughout, to follow auth- o changed "conn_key" to "traffic_key" throughout, to follow auth-
opt-05 opt-05
o changed "tsad" to "mkt" throughout, to follow auth-opt-05 o changed "tsad" to "mkt" throughout, to follow auth-opt-05
o changed "conn_block" to "data_block" throughout, to follow auth- o changed "conn_block" to "data_block" throughout, to follow auth-
opt-05 opt-05
lebovitz...-01- 2nd submission draft-lebovitz...-01- 2nd submission
o removed the whole section on labels (previously section 4), per WG o removed the whole section on labels (previously section 4), per WG
consensus at IETF74. Added 3.1.3 to specify that implementations consensus at IETF74. Added 3.1.3 to specify that implementations
SHOULD make HMAC-SHA1 the default choice for the time being, and SHOULD make HMAC-SHA1 the default choice for the time being, and
to suggest common names for the KDF's universally in UI's. to suggest common names for the KDF's universally in UI's.
o changed KDF = PRF... to Derived_Key = KDF... (EKR) o changed KDF = PRF... to Derived_Key = KDF... (EKR)
o added the text on how to deal with future KDF to end of s3.1 (EKR) o added the text on how to deal with future KDF to end of s3.1 (EKR)
o removed references to TCP-AO "manual key mode". Changed to TCP- o removed references to TCP-AO "manual key mode". Changed to TCP-
AO's "current mode of manual keying". (Touch) AO's "current mode of manual keying". (Touch)
o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now,
per wg consensus at ietf74. per wg consensus at ietf74.
o in 3.1.2, changed the mechanism to force the K to be 128bits from o in 3.1.2, changed the mechanism to force the K to be 128bits from
using 0^128, to using a fixed 128-bit string of random characters using 0^128, to using a fixed 128-bit string of random characters
(Dave McGrew) (Dave McGrew)
o sect 3.1, in Input description, dropped "0x00". Added "NOTE" o sect 3.1, in Input description, dropped "0x00". Added "NOTE"
explaining why right after the output_length description. explaining why right after the output_length description.
o cleaned up all references o cleaned up all references
o copy editing o copy editing
lebovitz...-00 - original submission draft-lebovitz...-00 - original submission
5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only. [NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.] Please remove before publishing as RFC.]
List of stuff that still needs work List of stuff that still needs work
o fix the iana registry section. Need registry entries for the KDFs o should be ready for WG LC. Any changes will come from final WG
and all the other values? review or IESG review.
o this was supposed to be named
draft-ietf-tcpm-tcp-ao-crypto-00.txt, but I forgot that since we
were moving from a personal submission to a wg sub, it had to go
back to a -00, thus needed to be done a week earlier. Oops. Will
fix as soon as the window opens for submitting -00's again.
6. Security Considerations 6. Security Considerations
This document inherits all of the security considerations of the This document inherits all of the security considerations of the
TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents.
The security of cryptographic-based systems depends on both the The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that the engineering of the protocol used by the system to ensure that
skipping to change at page 14, line 29 skipping to change at page 15, line 30
implementing. implementing.
7. IANA Considerations 7. IANA Considerations
IANA has created and will maintain a registry called, "Cryptographic IANA has created and will maintain a registry called, "Cryptographic
Algorithms for TCP-AO". The registry consists of a text string and Algorithms for TCP-AO". The registry consists of a text string and
an RFC number that lists the associated transform(s). New entries an RFC number that lists the associated transform(s). New entries
can be added to the registry only after RFC publication and approval can be added to the registry only after RFC publication and approval
by an expert designated by the IESG. by an expert designated by the IESG.
[need to finish this section] The registry has the following initial values:
SHA1 [This RFC when published]
AES128 [This RFC when published]
8. Acknowledgements 8. Acknowledgements
Eric "EKR" Rescorla, who provided a ton of input and feedback, Eric "EKR" Rescorla, who provided a ton of input and feedback,
including a somewhat heavy re-write of section 3.1.x, earning him and including a somewhat heavy re-write of section 3.1.x, earning him and
author slot on the document. author slot on the document.
Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly
create a first draft here. create a first draft here.
skipping to change at page 15, line 17 skipping to change at page 16, line 25
good cryptographic decisions. good cryptographic decisions.
The TCPM working group, who put up with all us crypto and routing 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 folks DoS'ing their WG for 2 years, and who provided reviews of this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-07
(work in progress), October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[HMAC-ATTACK] [HMAC-ATTACK]
"On the Security of HMAC and NMAC Based on HAVAL, MD4, "On the Security of HMAC and NMAC Based on HAVAL, MD4,
MD5, SHA-0 and SHA-1"", 2006, MD5, SHA-0 and SHA-1"", 2006,
<http://eprint.iacr.org/2006/187 <http://eprint.iacr.org/2006/187
http://www.springerlink.com/content/00w4v62651001303>. http://www.springerlink.com/content/00w4v62651001303>.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
(work in progress), July 2009.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008. progress), March 2008.
[NIST-SP800-108] [NIST-SP800-108]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Key Derivation Using Pseudorandom "Recommendation for Key Derivation Using Pseudorandom
Functions", SP 800-108, April 2008. Functions", SP 800-108, April 2008.
 End of changes. 91 change blocks. 
262 lines changed or deleted 312 lines changed or added

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