One document matched: draft-ietf-tcpm-tcp-ao-crypto-00.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 RFC2404 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2404.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 RFC4305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4305.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 RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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="no"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-tcpm-tcp-ao-crypto-00"
ipr="pre5378Trust200902" number="">
<front>
<title abbrev="Crypto for TCP-AO">Cryptographic Algorithms, Use, &
Implementation Requirments for TCP Authentication Option</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="05" month="September" year="2009" />
<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 algorithm(s). This document specifies the
algorithms and attributes that can be used in TCP-AO's current manual
keying mechanism.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document is a companion to TCP-AO <xref
target="I-D.ietf-tcpm-tcp-auth-opt">[TCP-AO]</xref>. Like most 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 to end-points. In order to accomplish this
function, one employs message authentication codes (MACs). There are
various ways to create MACs. The use of hashed-based MACs (HMAC) in
Internet protocols is defined in <xref target="RFC2104"></xref>. The use
of cipher-based MACs (CMAC) in Internet protocols is defined in <xref
target="RFC4493"></xref>.</t>
<t>This RFC discusses the requirements for implementations to support
two MACs used in TCP-AO, both now and in the future, and includes the
rationale behind the present and future requirements. The document then
specifies the use of those two MACs with TCP-AO.</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></t>
</section>
<section title="Algorithm Requirements">
<t>In this the first RFC specifying cryptography for TCP-AO, we
specify two MAC algorithms. Both MUST be implemented in order for the
implementation to be fully compliant with this RFC.</t>
<t>This table lists authentication algorithms for the TCP-AO
protocol.</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="RFC2404"></xref></t>
<t hangText="MUST">AES-128-CMAC-96 <xref
target="RFC4493"></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>NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:</t>
<t>The security issues driving the migration from SHA-1 to SHA-256 for
digital signatures <xref target="HMAC-ATTACK">[HMAC-ATTACK] </xref>do
not immediately render SHA-1 weak for this application of SHA-1 in
HMAC mode. The security strength of SHA-1 HMACs should be sufficient
for the foreseeable future, especially given that the tags are
truncated to 96 bits. However, while it's clear that the attacks
aren't practical on SHA-1, these types of analysis are mounting and
could potentially pose a concern for HMAC forgery if they were
significantly improved, over time. In anticipation of SHA-1's growing
less dependable over time, but given its wide deployment and current
strength, it is a "MUST" for TCP-AO today. AES-128 CMAC is considered
to be far stronger algorithm, but may not yet have very wide
implementation. It is also a "MUST" to implement, in order to drive
vendors toward its use.</t>
</section>
<section anchor="ReqFuture"
title="Requirements for Future MAC Algorithms">
<t>Since this document provides cryptographic agility, it is also
important to establish requirements for future MAC algorithms. The
TCPM WG should restrict any future MAC algorithms for this
specification to ones that can protect at least 2**48 messages with a
probability that a collision will occur of less than one in a
billion.</t>
<t>[Reviewers: Are there any other requirements we want/need to place
in here? RFC EDITOR: Please delete this text before publishing as
RFC]</t>
</section>
</section>
<section anchor="Algos" title="Algorithms Specified">
<t>TCP-AO refers to this document saying that the MAC mechanism employed
for a connection is listed in the TAPD entry, and is chosen from a list
of MACs both named and described in this document.</t>
<t>TCP-AO requires two classes of cryptographic algorithms:</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.</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 of the messages sent
over the wire.</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>Derived_Key = KDF(Master_Key, Input, Output_Length)</t>
</list></t>
<t>where:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- KDF:">the specific pseudorandom function that
is the basic building block used in constructing the given
Derived_Key.</t>
<t></t>
<t hangText="- Master_Key:">The Master_Key as will be stored
into the associated TCP-AO TAPD entry. In TPC-AO's manual key
mode, this is a shared key that both peers enter via some user
interface into their respective configurations. The Master_Key
is the seed for the KDF. We assume that, in manual key mode,
this is a human readable pre-shared key (PSK), thus we assume
that it is of variable length. Users SHOULD chose random
strings for the Master_Key. However, we assume that some users
may not.</t>
<t></t>
<t hangText="- Input:">the input data for the KDF, in
conformance with <xref target="NIST-SP800-108"></xref>, is a
concatonation of:</t>
</list></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="- "||":">Represents a concatonation
operation, between two values X || Y.</t>
<t></t>
<t hangText="- i:">A counter, a binary string that is an
input to each iteration of a PRF in counter mode and
(optionally) in feedback mode. This will depend on the
specific size of the Output_Length desired for an given
MAC.</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 :">A binary string containing
information related to the specific connection for this
derived keying material. In TCP-AO, this is the
Data_Block, as defined in <xref
target="I-D.ietf-tcpm-tcp-auth-opt"></xref>, Section
7.1]</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>
</list></t>
<t></t>
<t>NOTE: The cited NIST document on KDFs calls for an input: (i ||
Label || 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.</t>
<t></t>
<t>When invoked, a KDF runs a certain PRF, using the Master_Key as the
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.</t>
<t>This document defines two KDFs:</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="RFC2404"></xref></t>
<t hangText="* KDF_AES_128_CMAC">based on AES-CMAC-PRF-128
<xref target="RFC4615"></xref></t>
</list></t>
<t></t>
</list></t>
<t></t>
<t>Other KDFs may be defined in future revisions of this document, and
SHOULD follow this same format as described above. When doing so,
note:</t>
<t><list hangIndent="5" style="numbers">
<t>The underlying PRFs specified in this document have fixed sized
output lengths, 128 bits in the case of the AES-CMAC, and 160 bits
in the case of HMAC-SHA1.</t>
<t>It is possible to generate an arbitrary number of output bits
with some given PRF by operating it in a feedback or counter mode.
The KDFs described in <xref target="NIST-SP800-108"></xref>
incorporate this feature, hence the counter "i", which creates
leading "0".</t>
<t>Each MAC needs a key of a specific length.</t>
<t>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).</t>
<t>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).</t>
</list></t>
<section title="The Use of KDF_HMAC_SHA1">
<t>For:</t>
<t><list hangIndent="5" style="empty">
<t>PRF(Master_Key, Input, Output_Length)</t>
</list></t>
<t></t>
<t>KDF_HMAC_SHA1 for TCP-AO has the following values:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="12" style="hanging">
<t hangText="- PRF:">HMAC-SHA1 <xref
target="RFC2404"></xref></t>
<t hangText="- Master_Key: ">As provided in the MKT</t>
<t hangText="- Input:"></t>
</list><list hangIndent="3" style="empty">
<t><list hangIndent="17" style="hanging">
<t hangText="- i:">"0"</t>
<t hangText="- Label:">"TCP-AO"</t>
<t hangText="- Context:">Data_Block</t>
<t hangText="- Output_Length">160</t>
</list></t>
</list><list hangIndent="12" style="hanging">
<t hangText="- Result:">Traffic_Key</t>
</list></t>
</list></t>
<t></t>
<t>The result is computed by performing HMAC-SHA1(Master_Key, Input)
and 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.</t>
</section>
<section title="The Use of KDF_AES_128_CMAC">
<t>For:</t>
<t><list hangIndent="5" style="empty">
<t>PRF(Master_Key, Input, Output_Length)</t>
</list></t>
<t></t>
<t>KDF_AES_128_CMAC for TCP-AO has the following values:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="12" style="hanging">
<t hangText="- PRF:">AES-CMAC-PRF-128 <xref
target="RFC4615"></xref></t>
<t hangText="- Master_Key: ">As provided in the MKT</t>
<t hangText="- Input:"></t>
</list><list hangIndent="3" style="empty">
<t><list hangIndent="17" style="hanging">
<t hangText="- i:">"0"</t>
<t hangText="- Label:">"TCP-AO"</t>
<t hangText="- Context:">Data_Block</t>
<t hangText="- Output_Length">128</t>
</list></t>
</list><list hangIndent="12" style="hanging">
<t hangText="- Result:">Traffic_Key</t>
</list></t>
</list></t>
<t>Whereas the KDF_SHA1 used only one round to produce the
Traffic_Key, the KDF_AES will take two steps. The reasoning
follows:</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 16
octets (128 bits) in length. We could mandate that implementations
force administrators to input Master_Keys of exactly 128 bit length,
and with sufficient randomness, but this places undue burdon on the
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 a similar mechanism
to the AES-CMAC-PRF-128 mechanism represented in <xref
target="RFC4615"></xref>, Sect 3. We do a two step process.</t>
<t>First we use AES_128_CMAC with a fixed key as a "randomness
extractor", while using the shared secret Master_Key, MK, as the
message input to produce a 128 bit key K.</t>
<t>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.</t>
<t>Therefore this KDF is always a 2 step function, as follows
(borrowing the format from <xref target="RFC4615"></xref>):</t>
<t><figure align="left" anchor="Figure1"
title="The AES-CMAC-PRF-128 Algorithm for TCP-AO">
<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 I in octets) +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variable: K (128-bit key for AES-CMAC) +
+ +
+ Step 1. K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
]]></artwork>
</figure></t>
<t></t>
<t><list hangIndent="3" style="empty">
<t>o In Step 1, the 128-bit key, K, for AES-CMAC is derived by
applying the AES-CMAC algorithm using the 128-bit all-zero
string as the key and MK as the input message.</t>
<t></t>
<t>o In Step 2, we apply the AES-CMAC algorithm again, this time
using the output of Step 1, K, as the key. The input message 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.</t>
</list></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>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
has wide support, being present in most implementations in the
marketplace. 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.</t>
</section>
</section>
<section anchor="MACs" title="MAC Algorithms">
<t></t>
<t>MACs for TCP-AO have the following interface:</t>
<t><list hangIndent="4" style="empty">
<t>MAC (Traffic_Key(KDF), Message, Truncation)</t>
</list></t>
<t>where:</t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="15" style="hanging">
<t hangText="- MAC-algo:">MAC Algorithm used</t>
<t hangText="- Traffic_Key:">Variable; Result of KDF.</t>
</list></t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="12" style="hanging">
<t hangText="- KDF:">Name of the TCP-AO KDF used</t>
</list></t>
</list></t>
<t><list hangIndent="15" style="hanging">
<t hangText="- Key_Length:">Length in bits required for the
Traffic_Key used in this MAC</t>
<t hangText="- Truncation:">Length in bits to which the final
MAC result is truncated before being placed into TCP-AO
header</t>
</list></t>
<t></t>
</list>This document specifies two MAC algorithm options for
generating the MAC for TCP-AO's option header:</t>
<t><list hangIndent="4" style="empty">
<t><list hangIndent="18" style="hanging">
<t hangText="* HMAC-SHA-1-96">based on <xref
target="RFC2404"></xref></t>
<t></t>
<t hangText="* AES-128-CMAC-96">based on <xref
target="RFC4493"></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 header.</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 has function used for
authenticating and providing integrity validation on TCP segments
with HMAC.</t>
<t>For:</t>
<t><list hangIndent="5" style="empty">
<t>MAC (Traffic_Key(KDF), Message, Truncation)</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-algo:">MAC Algorithm used</t>
<t hangText="- Traffic_Key:">Variable; Result of KDF.</t>
</list></t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="12" style="hanging">
<t hangText="- KDF:">KDF_HMAC_SHA1</t>
</list></t>
</list></t>
<t><list hangIndent="15" style="hanging">
<t hangText="- Key_Length:">160 bits</t>
<t hangText="- Truncation:">96 bits</t>
<t></t>
</list></t>
</list></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>For:</t>
<t><list hangIndent="5" style="empty">
<t>MAC (Traffic_Key(KDF), Message, Truncation)</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-algo:">AES-128-CMAC-96 <xref
target="RFC4493"></xref></t>
<t hangText="- Traffic_Key:">Variable; Result of KDF.</t>
</list></t>
<t><list hangIndent="3" style="empty">
<t><list hangIndent="12" style="hanging">
<t hangText="- KDF:">KDF_AES_128_CMAC</t>
</list></t>
</list></t>
<t><list hangIndent="15" style="hanging">
<t hangText="- Key_Length:">128 bits</t>
<t hangText="- Truncation:">96 bits</t>
</list></t>
</list></t>
<t>According to <xref target="RFC4493"></xref>, by default, "the
length of the output of AES-128-CMAC is 128 bits. It is possible to
truncate the MAC. The result of the truncation is then taken in most
significant bits first order. The MAC length must be specified
before the communication 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.</t>
<t></t>
<t></t>
</section>
</section>
</section>
<section anchor="ChangeHistory"
title="Change History (RFC Editor: Delete before publishing)">
<t>[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]</t>
<t>draft-ietf...-00 - 4th submission</t>
<t>Submitting draft-lebovitz...-02 as a WG document. Added EKR as co-
author, and gave him credit for rewrite of sect 3.1.x .</t>
<t>lebovitz...-02 - 3rd submission</t>
<t><list style="symbols">
<t>cleaned up explanation in 3.1.2</t>
<t>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 (as
it was in -00) (Polk & Ekr)</t>
<t>deleted cut-and-paste error text from sect 3.1 between "label"
and "context"</t>
<t>changed "conn_key" to "traffic_key" throughout, to follow
auth-opt-05</t>
<t>changed "tsad" to "mkt" throughout, to follow auth-opt-05</t>
<t>changed "conn_block" to "data_block" throughout, to follow
auth-opt-05</t>
</list></t>
<t>lebovitz...-01- 2nd submission</t>
<t><list style="symbols">
<t>removed the whole section on labels (previously section 4), per
WG consensus at IETF74. Added 3.1.3 to specify that implementations
SHOULD make HMAC-SHA1 the default choice for the time being, and to
suggest common names for the KDF's universally in UI's.</t>
<t>changed KDF = PRF... to Derived_Key = KDF... (EKR)</t>
<t>added the text on how to deal with future KDF to end of s3.1
(EKR)</t>
<t>removed references to TCP-AO "manual key mode". Changed to
TCP-AO's "current mode of manual keying". (Touch)</t>
<t>removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now,
per wg consensus at ietf74.</t>
<t>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
(Dave McGrew)</t>
<t>sect 3.1, in Input description, dropped "0x00". Added "NOTE"
explaining why right after the output_length description.</t>
<t>cleaned up all references</t>
<t>copy editing</t>
</list></t>
<t>lebovitz...-00 - original submission</t>
<t></t>
<t></t>
</section>
<section anchor="ToAddress"
title="Needs Work in Next Draft (RFC Editor: Delete Before Publishing)">
<t>[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]</t>
<t>List of stuff that still needs work<list style="symbols">
<t>fix the iana registry section. Need registry entries for the KDFs
and all the other values?</t>
<t>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.</t>
</list></t>
</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 cryptographic-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 stupidity",
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" or "SHOULD 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>
</section>
<section title="IANA Considerations">
<t></t>
<t>IANA has created and will maintain a registry called, "Cryptographic
Algorithms for TCP-AO". The registry consists of a text string and an
RFC number that lists the associated transform(s). New entries can be
added to the registry only after RFC publication and approval by an
expert designated by the IESG.</t>
<t>[need to finish this section]</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
and 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="RFC4305"></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">
&RFC2119;
</references>
<references title="Informative References">
&I-D.narten-iana-considerations-rfc2434bis;
&I-D.ietf-tcpm-tcp-auth-opt;
<reference anchor="NIST-SP800-108">
<front>
<title abbrev="KDF">Recommendation for Key Derivation Using
Pseudorandom Functions</title>
<author fullname="National Institute of Standards and Technology"
initials=""
surname="National Institute of Standards and Technology"></author>
<date month="April" year="2008" />
</front>
<seriesInfo name="SP" value="800-108" />
</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="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>
&RFC2104;
&RFC2401;
&RFC2404;
&RFC2406;
&RFC4086;
&RFC4493;
&RFC4305;
&RFC4307;
&RFC4308;
&RFC4615;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 10:41:38 |