One document matched: draft-ietf-tcpm-tcp-ao-crypto-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2401.xml">
<!ENTITY RFC2406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2406.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4835 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4835.xml">
<!ENTITY RFC4307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4307.xml">
<!ENTITY RFC4308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4308.xml">
<!ENTITY I-D.ietf-tcpm-tcp-auth-opt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-auth-opt.xml">
<!ENTITY RFC4615 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4615.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-tcpm-tcp-ao-crypto-03"
ipr="trust200902">
<front>
<title abbrev="Crypto for TCP-AO">Cryptographic Algorithms for TCP's
Authentication Option, TCP-AO</title>
<author fullname="Gregory Lebovitz" initials="G.M." surname="Lebovitz">
<organization abbrev="Juniper">Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 North Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1206</code>
<country>US</country>
</postal>
<phone></phone>
<email>gregory.ietf@gmail.com</email>
</address>
</author>
<author fullname="Eric Rescorla" initials="E. K." surname="Rescorla">
<organization abbrev="RTFM">RTFM, Inc.</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>US</country>
</postal>
<phone>650-678-2350</phone>
<email>ekr@rtfm.com</email>
</address>
</author>
<date day="24" month="March" year="2010" />
<area>Transport</area>
<workgroup>TCPM</workgroup>
<abstract>
<t>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 MACs.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document is a companion to <xref
target="I-D.ietf-tcpm-tcp-auth-opt"></xref>. Like most modern
security protocols, TCP-AO allows users to chose which cryptographic
algorithm(s) they want to use to meet their security needs.</t>
<t>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
hashed-based MACs (HMAC) is defined in <xref target="RFC2104"></xref>.
The use of cipher-based MACs (CMAC) is defined in <xref
target="NIST-SP800-38B"></xref>.</t>
<t>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.</t>
<t></t>
<t></t>
</section>
<section anchor="Requirements" title="Requirements">
<t></t>
<section anchor="ReqLanguage" title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Algorithm Requirements">
<t>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.</t>
<t>The following table indicates the required MAC algorithms and KDFs
for TCP-AO:</t>
<t></t>
<t><list hangIndent="8" style="empty">
<t><list hangIndent="17" style="hanging">
<t hangText="Requirement">Authentication Algorithm</t>
<t hangText="------------">------------------------</t>
<t hangText="MUST">HMAC-SHA-1-96 <xref
target="RFC2104"></xref><xref target="FIPS-180-3"></xref></t>
<t hangText="MUST">AES-128-CMAC-96 <xref
target="NIST-SP800-38B"></xref><xref
target="FIPS197"></xref></t>
<t></t>
<t hangText="Requirement">Key Derivation Function (KDF)</t>
<t hangText="-------------">------------------------</t>
<t hangText="MUST">KDF_HMAC_SHA1</t>
<t hangText="MUST">KDF_AES_128_CMAC</t>
</list></t>
</list></t>
<t></t>
<t>For an explanation fo why two MAC algorthims were mandated, see the
<xref target="Security"></xref> section.</t>
<t></t>
</section>
<section anchor="ReqFuture"
title="Requirements for Future MAC Algorithms">
<t>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.</t>
</section>
</section>
<section anchor="Algos" title="Algorithms Specified">
<t>TCP-AO requires two classes of cryptographic algorithms used on a
particular connection, and refers to this document to define them
both:</t>
<t><list hangIndent="4" style="empty">
<t><list hangIndent="5" style="hanging">
<t hangText="(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.</t>
<t hangText="(2)">Message Authentication Code (MAC) algorithms
which take a key and a message and produce an authentication tag
which can be used to verify the integrity and authenticity of
those messages.</t>
</list></t>
</list></t>
<t></t>
<t>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.</t>
<section anchor="KDFs" title="Key Derivation Functions (KDFs)">
<t></t>
<t>TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in
TCP-AO's current manual keying have the following interface:</t>
<t><list hangIndent="4" style="empty">
<t>Traffic_Key = KDF_alg(Master_Key, Context, Output_Length)</t>
</list></t>
<t>where:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- KDF_alg:">the specific pseudorandom function
(PRF) that is the basic building block used in constructing
the given Traffic_Key.</t>
<t></t>
<t hangText="- 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.</t>
<t></t>
<t hangText="- Context:">A binary string containing
information related to the specific connection for this
derived keying material, as defined in <xref
target="I-D.ietf-tcpm-tcp-auth-opt"></xref>, Section 7.2.</t>
<t></t>
<t hangText="- 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.</t>
</list></t>
</list></t>
<t></t>
<t>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.</t>
<section title="Concrete KDFs">
<t>This document defines two KDF algorithms, each paired with a
corresponding PRF algorithm as explained below:</t>
<t><list hangIndent="4" style="empty">
<t><list hangIndent="18" style="hanging">
<t hangText="* KDF_HMAC_SHA1">based on PRF-HMAC-SHA1 <xref
target="RFC2104"></xref><xref
target="FIPS-180-3"></xref></t>
<t hangText="* KDF_AES_128_CMAC">based on AES-CMAC-PRF-128
<xref target="NIST-SP800-38B"></xref><xref
target="FIPS197"></xref></t>
</list></t>
<t></t>
</list>Both of these KDFs are based on the iteration mode KDFs
specified in <xref target="NIST-SP800-108"></xref>. 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.</t>
<t>Each input block is constructed as follows:</t>
<t><list hangIndent="5" style="empty">
<t>( i || Label || Context || Output_Length )</t>
</list></t>
<t><list hangIndent="2" style="empty">
<t hangText=" Where:">Where</t>
<t><list hangIndent="13" style="hanging">
<t hangText="- "||":">For any X || Y, "||"
represents a concatonation operation of the binary strings X
and Y.</t>
<t></t>
<t hangText="- 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.</t>
<t></t>
<t hangText="- 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.</t>
<t></t>
<t hangText="- Context:">The context argument provided to
the KDF interface, as described above in <xref
target="KDFs"></xref> .</t>
<t></t>
<t hangText="- 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.</t>
</list></t>
</list></t>
<t>The ouput 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. E.g.,</t>
<t></t>
<figure>
<artwork align="???"><![CDATA[
Traffic_Key =
KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
KDF_alg(Master_Key, 2 || Label || Context || Output_length)
]]></artwork>
</figure>
<t></t>
<t>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.</t>
<section title="KDF_HMAC_SHA1">
<t>For KDF_HMAC_SHA1:</t>
<t><list hangIndent="13" style="hanging">
<t hangText="- PRF for KDF_alg:">HMAC-SHA1 <xref
target="RFC2104"></xref><xref target="FIPS-180-3"></xref>.</t>
<t></t>
<t hangText="- Use:">HMAC-SHA1(Key, Input).</t>
<t></t>
<t hangText="- Key:">Master_Key, configured by user, and
passed to the KDF.</t>
<t></t>
<t hangText="- Input: ">( i || Label || Context ||
Output_Length)</t>
<t></t>
<t hangText="- Output_Length:">160 bits.</t>
<t></t>
<t hangText="- Result:">Traffic_Key, used in the MAC function
by TCP-AO.</t>
</list></t>
<t></t>
<t></t>
</section>
<section title="KDF_AES_128_CMAC">
<t>For KDF_AES_128_CMAC:</t>
<t></t>
<t><list hangIndent="13" style="hanging">
<t hangText="- PRF for KDF_alg:">AES-CMAC-PRF-128 <xref
target="NIST-SP800-38B"></xref><xref
target="FIPS197"></xref>.</t>
<t></t>
<t hangText="- Use:">AES-CMAC(Key, Input).</t>
<t></t>
<t hangText="- Key:">Master_Key (see usage below)</t>
<t></t>
<t hangText="- Input: ">( i || Label || Context ||
Output_Length)</t>
<t></t>
<t hangText="- Output_Length:">128 bits.</t>
<t></t>
<t hangText="- Result:">Traffic_Key, used in the MAC function
by TCP-AO</t>
</list></t>
<t>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.</t>
<t>To handle variable length Master_Keys we use the same mechanism
as described in <xref target="RFC4615"></xref>, Sect 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:</t>
<t><figure align="left" anchor="Figure1">
<artwork><![CDATA[
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 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; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
]]></artwork>
</figure></t>
<t>In step 1, the 128-bit key, K, for AES-CMAC is derived as
follows:</t>
<t>o If the Master_Key, MK, provided by the administrator is
exactly 128 bits, then we use it as-is.</t>
<t>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.</t>
<t>In step 2, we apply the AES-CMAC algorithm again, this time
using K as the key and I as the input message.</t>
<t>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.</t>
<t></t>
</section>
<section title="Tips for User Interfaces regarding KDFs">
<t>This section provides suggested representations for the KDFs in
implementation user interfaces. Following these guidelines across
common implementations will make interoperability easier and
simpler for deployers.</t>
<t>UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply
"SHA1".</t>
<t>UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply
"AES128".</t>
<t>The initial IANA registry values will reflect these two
entries.</t>
<t>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.</t>
</section>
</section>
</section>
<section anchor="MACs" title="MAC Algorithms">
<t></t>
<t>Each MAC_alg defined for TCP-AO has three fixed elements as part of
its definition:</t>
<t><list hangIndent="15" style="hanging">
<t hangText="- KDF_Alg:">Name of the TCP-AO KDF algorithm used to
generate the Traffic_Key</t>
<t hangText="- Key_Length:">Length in bits required for the
Traffic_Key used in this MAC</t>
<t hangText="- 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.</t>
</list></t>
<t>MACs computed for TCP-AO have the following interface:</t>
<t><list hangIndent="4" style="empty">
<t>MAC = MAC_alg(Traffic_Key, Message)</t>
</list></t>
<t>where:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- MAC_alg:">MAC Algorithm used</t>
<t hangText="- Traffic_Key:">Variable; the result of KDF.</t>
<t hangText="- Message">The message to be authenticated, as
specified in <xref target="I-D.ietf-tcpm-tcp-auth-opt"></xref>
Section 7.1.</t>
</list></t>
</list></t>
<t></t>
<t>This document specifies two MAC algorithm options for generating
the MAC as used by TCP-AO:</t>
<t><list hangIndent="4" style="empty">
<t><list hangIndent="18" style="hanging">
<t hangText="* HMAC-SHA-1-96">based on <xref
target="RFC2104"></xref> and <xref
target="FIPS-180-3"></xref>.</t>
<t></t>
<t hangText="* AES-128-CMAC-96">based on <xref
target="NIST-SP800-38B"></xref><xref
target="FIPS197"></xref></t>
</list></t>
<t></t>
</list>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.</t>
<t>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 are then truncated to 96 bits to
provide a reasonable tradeoff between security and message size, for
fitting into the TCP-AO option field.</t>
<t></t>
<t></t>
<section anchor="HMAC-SHA-1-96" title="The Use of HMAC-SHA-1-96">
<t>By definition, HMAC <xref target="RFC2104"></xref> requires a
cryptographic hash function. SHA1 will be that hash function used
for authenticating and providing integrity validation on TCP
segments with HMAC.</t>
<t></t>
<t>The three fixed elements for HMAC-SHA-1-96 are:</t>
<t><list hangIndent="15" style="hanging">
<t hangText="- KDF_Alg:">KDF_HMAC_SHA1.</t>
<t hangText="- Key_Length:">160 bits.</t>
<t hangText="- MAC_Length:">96 bits.</t>
</list></t>
<t></t>
<t>For:</t>
<t><list hangIndent="5" style="empty">
<t>MAC = MAC_alg (Traffic_Key, Message)</t>
<t></t>
</list></t>
<t>HMAC-SHA-1-96 for TCP-AO has the following values:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- MAC_alg:">HMAC-SHA1</t>
<t hangText="- Traffic_Key:">Variable; the result of the
KDF.</t>
<t hangText="- Message:">The message to be authenticated, as
specified in <xref
target="I-D.ietf-tcpm-tcp-auth-opt"></xref> Section 7.1.</t>
</list></t>
<t></t>
<t></t>
</list></t>
<t></t>
<t></t>
</section>
<section anchor="AES-128-CMAC-96" title="The Use of AES-128-CMAC-96">
<t>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 <xref target="NIST-SP800-38B"></xref>.</t>
<t>The three fixed elements for AES-128-CMAC-96 are:</t>
<t><list hangIndent="15" style="hanging">
<t hangText="- KDF_Alg:">KDF_AES_128_CMAC.</t>
<t hangText="- Key_Length:">128 bits.</t>
<t hangText="- MAC_Length:">96 bits.</t>
</list></t>
<t></t>
<t>For:</t>
<t><list hangIndent="5" style="empty">
<t>MAC = MAC_alg (Traffic_Key, Message)</t>
<t></t>
</list></t>
<t>AES-128-CMAC-96 for TCP-AO has the following values:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- MAC_alg:">AES-128-CMAC-96 <xref
target="NIST-SP800-38B"></xref></t>
<t hangText="- Traffic_Key:">Variable; the result of the
KDF.</t>
<t hangText="- Message:">The message to be authenticated, as
specified in <xref
target="I-D.ietf-tcpm-tcp-auth-opt"></xref> Section 7.1.</t>
<t></t>
<t></t>
</list></t>
</list></t>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document inherits all of the security considerations of the
TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents.</t>
<t>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.</t>
<t>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. <xref target="RFC4086"></xref> contains helpful information on both
key generation techniques and cryptographic randomness.</t>
<t>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 administrators are safe to use weak keys.
Administrators are encouraged to follow <xref target="RFC4086"></xref>
as listed above. We simply attempted to "put a fence around
foolishness", in as much as possible.</t>
<t>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.</t>
<t>NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:</t>
<t>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.</t>
<t>Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC
MD5) aren't practical on 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 <xref
target="HMAC-ATTACK"></xref> do not immediately render SHA-1 weak for
this application of SHA-1 in HMAC mode.</t>
<t>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.</t>
<t></t>
<t></t>
</section>
<section title="IANA Considerations">
<t></t>
<t>Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD</t>
<t>Registry Name: Cryptographic Algorithms for TCP-AO
Registration Procedure: RFC Publication after Expert Review</t>
<t>Initial contents of this registry will be:</t>
<t></t>
<t>Algorithm | Reference</t>
<t>----------------|-----------</t>
<t>SHA1 | [RFC-tcpm-tcp-ao-crypto]</t>
<t>AES128 | [RFC-tcpm-tcp-ao-crypto]</t>
<t></t>
<t></t>
</section>
<section title="Acknowledgements">
<t>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.</t>
<t>Paul Hoffman, from whose <xref target="RFC4308"></xref> I sometimes
copied, to quickly create a first draft here.</t>
<t>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.</t>
<t>Jeff Schiller, Donald Eastlake and the IPsec WG, whose <xref
target="RFC4307"></xref> & <xref target="RFC4835"></xref> text was
consulted and sometimes used in the Requirements <xref
target="Requirements"></xref> section of this document.</t>
<t>(In other words, I was truly only an editor of others' text in
creating this document.)</t>
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="FIPS197">
<front>
<title abbrev="AES">Advanced Encryption Standard (AES)</title>
<author fullname="National Institute of Standards and Technology (NIST)"
initials="" surname="FIPS Publications 197"></author>
<date month="November" year="2001" />
</front>
<seriesInfo name="FIPS" value="197" />
</reference>
<reference anchor="FIPS-180-3">
<front>
<title abbrev="SHA-1">Secured Hash Standard</title>
<author fullname="National Institute of Standards and Technology (NIST)"
initials="" surname="FIPS Publication 180-3"></author>
<date month="October" year="2008" />
</front>
<seriesInfo name="FIPS" value="180-3" />
</reference>
<reference anchor="NIST-SP800-38B">
<front>
<title abbrev="CMAC">Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication</title>
<author fullname="National Institute of Standards and Technology"
initials=""
surname="National Institute of Standards and Technology"></author>
<date month="May" year="2005" />
</front>
<seriesInfo name="SP" value="800-38B" />
</reference>
<reference anchor="NIST-SP800-108">
<front>
<title abbrev="SP800-108">Recommendation for Key Derivation Using Pseudorandom Functions, NIST SP800-108</title>
<author fullname="National Institute of Standards and Technology"
initials=""
surname="National Institute of Standards and Technology"></author>
<date month="October" year="2009" />
</front>
<seriesInfo name="SP" value="800-108" />
</reference>
&RFC2104;
&RFC2119;
&I-D.ietf-tcpm-tcp-auth-opt;
</references>
<references title="Informative References">
<reference anchor="HMAC-ATTACK"
target="http://eprint.iacr.org/2006/187 http://www.springerlink.com/content/00w4v62651001303">
<front>
<title abbrev="HMAC-ATTACK">On the Security of HMAC and NMAC Based
on HAVAL, MD4, MD5, SHA-0 and SHA-1"</title>
<author fullname="Jongsung Kim" initials="" surname=""></author>
<author fullname="Alex Biryukov" initials="" surname=""></author>
<author fullname="Bart Preneel" initials="" surname=""></author>
<author fullname="Seokhie Hong" initials="" surname=""></author>
<date month="" year="2006" />
</front>
</reference>
&RFC4086;
&RFC4835;
&RFC4307;
&RFC4308;
&RFC4615;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:41:05 |