draft-ietf-tcpm-tcp-ao-crypto-01.txt   draft-ietf-tcpm-tcp-ao-crypto-02.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: May 1, 2010 RTFM Expires: August 14, 2010 RTFM
October 28, 2009 February 10, 2010
Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Cryptographic Algorithms for TCP's Authentication Option, TCP-AO
draft-ietf-tcpm-tcp-ao-crypto-01 draft-ietf-tcpm-tcp-ao-crypto-02
Abstract
The TCP Authentication Option, TCP-AO, relies on security algorithms
to provide authentication between two end-points. There are many
such algorithms available, and two TCP-AO systems cannot interoperate
unless they are using the same algorithms. This document specifies
the algorithms and attributes that can be used in TCP-AO's current
manual keying mechanism.
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.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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/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 May 1, 2010. This Internet-Draft will expire on August 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Abstract document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
The TCP Authentication Option, TCP-AO, relies on security algorithms This document may contain material from IETF Documents or IETF
to provide authentication between two end-points. There are many Contributions published or made publicly available before November
such algorithms available, and two TCP-AO systems cannot interoperate 10, 2008. The person(s) controlling the copyright in some of this
unless they are using the same algorithm(s). This document specifies material may not have granted the IETF Trust the right to allow
the algorithms and attributes that can be used in TCP-AO's current modifications of such material outside the IETF Standards Process.
manual keying mechanism. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . 4
2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . 4
2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4 2.3. Requirements for Future MAC Algorithms . . . . . . . . 5
3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . 5
3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . 6
3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . 7
3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . 11
3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . 12
3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . 12
4. Change History (RFC Editor: Delete before publishing) . . . . 12 4. Change History (RFC Editor: Delete before publishing) . . . 13
5. Needs Work in Next Draft (RFC Editor: Delete Before 5. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 14 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document is a companion to TCP-AO [TCP-AO] This document is a companion to [TCP-AO]
[I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols, [I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols,
TCP-AO allows users to chose which cryptographic algorithm(s) they TCP-AO allows users to chose which cryptographic algorithm(s) they
want to 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, message authentication codes (MACs) are used, which then function, message authentication codes (MACs) are used, which then
rely on shared keys. There are various ways to create MACs. The use rely on shared keys. There are various ways to create MACs. The use
of hashed-based MACs (HMAC) in Internet protocols is defined in of hashed-based MACs (HMAC) in Internet protocols is defined in
[RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols [RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols
is defined in [RFC4493]. is defined in [RFC4493].
This RFC defines the general requirements for MACs used in TCP-AO, This RFC defines the general requirements for MACs used in TCP-AO,
both for currently specified MACs and for any future specified MACs. both for currently specified MACs and for any future specified MACs.
It then specifies two MAC algorithms required in all TCP-AO It then specifies two MAC algorithms required in all TCP-AO
implementations. It also specifies two key derivations functions implementations. It also specifies two key derivation functions
(KDFs) used to create the traffic keys used by the MACs. These KDFs (KDFs) used to create the traffic keys used by the MACs. These KDFs
are also required by all TCP-AO implementations. 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].
skipping to change at page 6, line 23 skipping to change at page 7, line 23
length key. A KDF MAY specify a maximum Output_Length parameter. length key. A KDF MAY specify a maximum Output_Length parameter.
3.1.1. Concrete KDFs 3.1.1. Concrete KDFs
This document defines two KDF algorithms, each paired with a This document defines two KDF algorithms, each paired with a
corresponding PRF algorithm as explained below: corresponding PRF algorithm as explained below:
* KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404]
* KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615]
Each
Both of these KDFs are based on the iteration mode KDFs specified in Both of these KDFs are based on the iteration mode KDFs specified in
[NIST-SP800-108]. This means that they use an underlying [NIST-SP800-108]. This means that they use an underlying
pseudorandom function (PRF) with a fixed-length output lengths, 128 pseudorandom function (PRF) with a fixed-length output lengths, 128
bits in the case of the AES-CMAC, and 160 bits in the case of HMAC- 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 SHA1. The KDF generates an arbitrary number of output bits by
operating the PRF in a "counter mode", where each invocation of the operating the PRF in a "counter mode", where each invocation of the
PRF uses a different input block differentiated by a block counter. PRF uses a different input block differentiated by a block counter.
Each input block is constructed as follows: Each input block is constructed as follows:
( i || Label || Context || Output_Length) ( i || Label || Context || Output_Length)
Where Where
- "||": For any X || Y, "||" represents a concatonation - "||": For any X || Y, "||" represents a concatonation
operation of the binary strings X and Y. operation of the binary strings X and Y.
- i: A counter, a binary string that is an input to each - i: A counter, a binary string that is an input to each
iteration of the PRF in counter mode. The number of 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 iterations will depend on the specific size of the
Output_Length desired for a given MAC. Output_Length desired for a given MAC. "i" always
starts = 1.
- Label: A binary string that clearly identifies the purpose - Label: A binary string that clearly identifies the purpose
of this KDF's derived keying material. For TCP-AO we of this KDF's derived keying material. For TCP-AO we
use the ASCII string "TCP-AO", where the last use the ASCII string "TCP-AO", where the last
character is the capital letter "O", not to be character is the capital letter "O", not to be
confused with a zero. While this may seem like confused with a zero. While this may seem like
overkill in this specification since TCP-AO only overkill in this specification since TCP-AO only
describes one call to the KDF, it is included in describes one call to the KDF, it is included in
order to comply with FIPS 140 certifications. order to comply with FIPS 140 certifications.
- Context : The context argument provided to the KDF interface, - Context : The context argument provided to the KDF interface,
as described above in Section 3.1 . as described above in Section 3.1 .
- Output_Length: The length in bits of the key that the KDF will - Output_Length: The length in bits of the key that the KDF will
produce. This length must be the size required for 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 the MAC algorithm that will use the PRF result as a
seed. seed.
The ouput of mutiple PRF invocations is simply concatenated. For the The ouput of mutiple PRF invocations is simply concatenated. For the
Traffic_Key, values of multiple PRF invocations are concatenated and Traffic_Key, values of multiple PRF invocations are concatenated and
truncated as needed to create a Traffic_Key of the desired length. 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 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 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 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 entire output of the first invocation concatenated with the second
invocation. E.g., invocation. E.g.,
Traffic_Key = Traffic_Key =
KDF_alg(Master_Key, 0 || Label || Context || Output_length) || KDF_alg(Master_Key, 1 || Label || Context || Output_length) ||
KDF_alg(Master_Key, 1 || Label || Context || Output_length) KDF_alg(Master_Key, 2 || Label || Context || Output_length)
If the number of bits required is not an even multiple of the output If the number of bits required is not an even multiple of the output
size of the PRF, then the output of the final invocation of the PRF size of the PRF, then the output of the final invocation of the PRF
is truncated as necessary. is truncated as necessary.
3.1.1.1. KDF_HMAC_SHA1 3.1.1.1. KDF_HMAC_SHA1
For KDF_HMAC_SHA1: For KDF_HMAC_SHA1:
- PRF for KDF_alg: HMAC-SHA1 [RFC2404]. - PRF for KDF_alg: HMAC-SHA1 [RFC2404].
skipping to change at page 9, line 5 skipping to change at page 10, line 5
To handle variable length Master_Keys we use the same mechanism as To handle variable length Master_Keys we use the same mechanism as
described in [RFC4615], Sect 3. First we use AES_128_CMAC with a described in [RFC4615], Sect 3. First we use AES_128_CMAC with a
fixed key of all zeros as a "randomness extractor", while using the 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 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, 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 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) and the true input block as the Input to yield the Traffic_Key (TK)
used in the MAC over the message. The description follows: used in the MAC over the message. The description follows:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 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 M 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. If MKlen is equal to 16 + + Step 1. If MKlen is equal to 16 +
+ Step 1a. then + + Step 1a. then +
+ K := MK; + + K := MK; +
+ Step 1b. else + + Step 1b. else +
+ K := AES-CMAC(0^128, MK, MKlen); + + K := AES-CMAC(0^128, MK, MKlen); +
+ Step 2. TK := AES-CMAC(K, I, len); + + Step 2. TK := AES-CMAC(K, I, len); +
+ return TK; + + return TK; +
+ + + +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1 Figure 1
In step 1, the 128-bit key, K, for AES-CMAC is derived as follows: In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
o If the Master_Key, MK, provided by the administrator is exactly 128 o If the Master_Key, MK, provided by the administrator is exactly 128
bits, then we use it as-is. bits, then we use it as-is.
skipping to change at page 10, line 27 skipping to change at page 11, line 27
3.2. MAC Algorithms 3.2. MAC Algorithms
Each MAC_alg defined for TCP-AO has three fixed elements as part of Each MAC_alg defined for TCP-AO has three fixed elements as part of
its definition: its definition:
- KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the - KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the
Traffic_Key Traffic_Key
- Key_Length: Length in bits required for the Traffic_Key used in - Key_Length: Length in bits required for the Traffic_Key used in
this MAC this MAC
- Output: The final length of the bits used in the TCP-AO MAC - MAC_Length: The final length of the bits used in the TCP-AO MAC
field. This value may be a truncation of the MAC field. This value may be a truncation of the MAC
function's original output length. function's original output length.
MACs computed for TCP-AO have the following interface: MACs computed for TCP-AO have the following interface:
MAC = MAC_alg(Traffic_Key, Message) MAC = MAC_alg(Traffic_Key, Message)
where: where:
- MAC_alg: MAC Algorithm used - MAC_alg: MAC Algorithm used
skipping to change at page 11, line 29 skipping to change at page 12, line 29
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.
The three fixed elements for HMAC-SHA-1-96 are: The three fixed elements for HMAC-SHA-1-96 are:
- KDF_Alg: KDF_HMAC_SHA1. - KDF_Alg: KDF_HMAC_SHA1.
- Key_Length: 160 bits. - Key_Length: 160 bits.
- Output: 96 bits. - MAC_Length: 96 bits.
For: For:
MAC = MAC_alg (Traffic_Key, Message) MAC = MAC_alg (Traffic_Key, Message)
HMAC-SHA-1-96 for TCP-AO has the following values: HMAC-SHA-1-96 for TCP-AO has the following values:
- MAC_alg: HMAC-SHA1 - MAC_alg: HMAC-SHA1
- Traffic_Key: Variable; the result of the KDF. - Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in - Message: The message to be authenticated, as specified in
skipping to change at page 12, line 9 skipping to change at page 13, line 9
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].
The three fixed elements for AES-128-CMAC-96 are: The three fixed elements for AES-128-CMAC-96 are:
- KDF_Alg: KDF_AES_128_CMAC. - KDF_Alg: KDF_AES_128_CMAC.
- Key_Length: 128 bits. - Key_Length: 128 bits.
- Output: 96 bits. - MAC_Length: 96 bits.
For: For:
MAC = MAC_alg (Traffic_Key, Message) MAC = MAC_alg (Traffic_Key, Message)
AES-128-CMAC-96 for TCP-AO has the following values: AES-128-CMAC-96 for TCP-AO has the following values:
- MAC_alg: AES-128-CMAC-96 [RFC4493] - MAC_alg: AES-128-CMAC-96 [RFC4493]
- Traffic_Key: Variable; the result of the KDF. - Traffic_Key: Variable; the result of the KDF.
- Message: The message to be authenticated, as specified in - Message: The message to be authenticated, as specified in
[I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
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 draft-ietf...-02 - 6th submission
o 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification o 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification
o o editorial touch ups - Wes
o in 3.2 s/Output/MAC_length , because -auth-opt-10 used "Output" in
a more generic way in 7.1, so the same term had two different
meanings, one in each doc. Changing -ao-crypto to use MAC_length
seemed most expedient.
o in 3.1.1, changed "i" to always start = 1, and changed the
concatonation example accordingly (it was starting = 0, which did
not match NIST SP 800-108 - Brian Weis
o in 3.1.1, added to definition of "i", "The counter "i" is
represented in a single octet. ", and to the definition of
"Output_Length" "The Output_length is represented within two
octets." - Brian Weis
draft-ietf...-01 - 5th submission draft-ietf...-01 - 5th submission
o simplified title of document - Touch o simplified title of document - Touch
o structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the 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 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 template (of sorts) in both sections that can be easily re-used by
any future KDF definition. any future KDF definition.
o in 3.1, switched "Derived_Key" back to "Traffic_Key" in order to o in 3.1, switched "Derived_Key" back to "Traffic_Key" in order to
sync with -auth-opt spec. sync with -auth-opt spec.
skipping to change at page 14, line 27 skipping to change at page 15, line 39
o copy editing o copy editing
draft-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 should be ready for WG LC. Any changes will come from final WG o None. ready IESG review.
review or IESG review. o Could use a bit broader security area review. Will ask a few
folks to review.
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 16, line 27 skipping to change at page 17, line 41
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] [I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-07 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10
(work in progress), October 2009. (work in progress), January 2010.
[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
 End of changes. 27 change blocks. 
72 lines changed or deleted 91 lines changed or added

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