Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option
draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material 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 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 13, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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 algorithm(s). This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism.

Table of Contents

1.  Introduction
2.  Requirements
    2.1.  Requirements Language
    2.2.  Algorithm Requirements
    2.3.  Requirements for Future MAC Algorithms
3.  Algorithms Specified
    3.1.  Key Derivation Functions (KDFs)
        3.1.1.  The Use of KDF_HMAC_SHA1
        3.1.2.  The Use of KDF_AES_128_CMAC
        3.1.3.  Tips for User Interfaces regarding KDFs
    3.2.  MAC Algorithms
        3.2.1.  The Use of HMAC-SHA-1-96
        3.2.2.  The Use of AES-128-CMAC-96
4.  Change History (RFC Editor: Delete before publishing)
5.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address

1.  Introduction

This document is a companion to TCP-AO [TCP-AO] (Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option,” March 2010.) [I‑D.ietf‑tcpm‑tcp‑auth‑opt]. Like most security protocols, TCP-AO allows users to chose which cryptographic algorithm(s) they want to use to meet their security needs.

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 [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.). The use of cipher-based MACs (CMAC) in Internet protocols is defined in [RFC4493] (Song, JH., Poovendran, R., Lee, J., and T. Iwata, “The AES-CMAC Algorithm,” June 2006.).

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.

2.  Requirements

2.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.2.  Algorithm Requirements

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.

This table lists authentication algorithms for the TCP-AO protocol.

Requirement

Authentication Algorithm

------------

------------------------

MUST

HMAC-SHA-1-96 [RFC2404] (Madson, C. and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH,” November 1998.)

MUST

AES-128-CMAC-96 [RFC4493] (Song, JH., Poovendran, R., Lee, J., and T. Iwata, “The AES-CMAC Algorithm,” June 2006.)

Requirement

Key Derivation Function (KDF)

-------------

------------------------

MUST

KDF_HMAC_SHA1

MUST

KDF_AES_128_CMAC

NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:

The security issues driving the migration from SHA-1 to SHA-256 for digital signatures [HMAC-ATTACK] (, “On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",” 2006.) [HMAC‑ATTACK]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.

2.3.  Requirements for Future MAC Algorithms

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.

[Reviewers: Are there any other requirements we want/need to place in here? RFC EDITOR: Please delete this text before publishing as RFC]

3.  Algorithms Specified

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.

TCP-AO requires two classes of cryptographic algorithms:

(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 Conn_Keys, the keys suitable for authenticating and integrity checking individual TCP segments.

(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.

In TCP-AO, these algorithms are always used in pairs. Each MAC algorithm MUST specify the KDF to be used with that MAC algorithm. However, a KDF MAY be used with more than one MAC algorithm.

3.1.  Key Derivation Functions (KDFs)

TCP-AO's Conn_Keys are derived using KDFs. The KDFs used in TCP-AO's current manual keying have the following interface:

Derived_Key = KDF(Master_Key, Input, Output_Length)

where:

- KDF:

the specific pseudorandom function that is the basic building block used in constructing the given Derived_Key.

- 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.

- Input:

the input data for the KDF, in conformance with [NIST‑SP800‑108] (National Institute of Standards and Technology, “Recommendation for Key Derivation Using Pseudorandom Functions,” April 2008.), is a concatonation of:

( i || Label || Context || Output_Length)

Where

- "||":

Represents a concatonation operation, between two values X || Y.

- 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.

- 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.

An octet of all zeros. An optional data field used to indicate a separation of different variable length data fields.

- Context :

A binary string containing information related to the specific connection for this derived keying material. In TCP-AO, this is the Conn_Block, as defined in [I‑D.ietf‑tcpm‑tcp‑auth‑opt] (Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option,” March 2010.), Section X]

- 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.

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.

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.

This document defines two KDFs:

* KDF_HMAC_SHA1

based on PRF-HMAC-SHA1 [RFC2404] (Madson, C. and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH,” November 1998.)

* KDF_AES_128_CMAC

based on AES-CMAC-PRF-128 [RFC4615] (Song, J., Poovendran, R., Lee, J., and T. Iwata, “The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” August 2006.)

Other KDFs may be defined in future revisions of this document, and SHOULD follow this same format as described above. When doing so, note:

1. 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.
2. 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 [NIST‑SP800‑108] (National Institute of Standards and Technology, “Recommendation for Key Derivation Using Pseudorandom Functions,” April 2008.) incorporate this feature, hence the counter "i", which creates leading "0".
3. Each MAC needs a key of a specific length.
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

For:

PRF(Master_Key, Input, Output_Length)

KDF_HMAC_SHA1 for TCP-AO has the following values:

- PRF:

HMAC-SHA1 [RFC2404] (Madson, C. and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH,” November 1998.)

- Master_Key:

As provided in the TSAD

- Input:

- i:

"0"

- Label:

"TCP-AO"

- Context:

Conn_Block

- Output_Length

160

- Result:

Conn_Key

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 Conn_Key. The Conn_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

For:

PRF(Master_Key, Input, Output_Length)

KDF_AES_128_CMAC for TCP-AO has the following values:

- PRF:

AES-CMAC-PRF-128 [RFC4615] (Song, J., Poovendran, R., Lee, J., and T. Iwata, “The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” August 2006.)

- Master_Key:

As provided in the TSAD

- Input:

- i:

"0"

- Label:

"TCP-AO"

- Context:

Conn_Block

- Output_Length

128

- Result:

Conn_Key

The result is computed by performing AES-CMAC-PRF-128(Master_Key, Input) and then taking the first (high order) Output_Length, 128, bits. This result is the TCP-AO Conn_Key. The Conn_Key is then used as the seed for the MAC function on each segment of the connection.

Since the Master_Key in TCP-AO's current manual keying mechanism is a pre-shared key (PSK) passed in an out of band mechanism between two devices, and often between two organizations, it is assumed to be of variable length. Therefore it may not have 16 octets / 128 bits, as is required as an input length to AES-128. We could mandate that implementations force administrators to input only keys of such length, and with sufficient randomness, but this places undue burdon on the deployers. The specification does RECOMMEND that deployers use a randomly generated 128-bit string as the Master_Key, but acknowledges that deployers may not. Therefore we use a similar mechanism to the AES-CMAC-PRF-128 mechanism represented in [RFC4615] (Song, J., Poovendran, R., Lee, J., and T. Iwata, “The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” August 2006.), Sect 3, with two changes: (1) we never use the raw Master_Key (MK) alone if K := MK. Instead, we always assume MK is variable length, and we always use both the the FR, the MK, and the MKlen arguments, even when K := MK; and (2) we don't use 0^128 for FR, we use an alpha-numeric string. Therefore this KDF is always a 2 step function, as follows (borrowing the format from [RFC4615] (Song, J., Poovendran, R., Lee, J., and T. Iwata, “The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” August 2006.)):

   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                        KDF-AES-128-CMAC                           +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   +                                                                   +
   + Input  : FR (Fixed 128-bits of randomness)                        +
   +        : MK (Variable-length Master_Key)                          +
   +        : I (Input, i.e., the input data of the PRF)               +
   +        : MKlen (length of MK in octets)                           +
   +        : len (length of I in octets)                              +
   + Output : PRV (128-bit Pseudo-Random Variable)                     +
   +                                                                   +
   +-------------------------------------------------------------------+
   + Variable: K (128-bit key for AES-CMAC)                            +
   +                                                                   +
   + Step 1.     K := AES-CMAC(FR, MK, MKlen);                         +
   + Step 2.   PRV := AES-CMAC(K, I, len);                             +
   +           return PRV;                                             +
   +                                                                   +
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

where FR is always equal to:
    CkhKR2iJzHtlQXAA

o In Step 1, the 128-bit key, K, for AES-CMAC is derived by applying the AES-CMAC algorithm using the FR 128-bit binary representation of the ASCII string "CkhKR2iJzHtlQXAA" as the key and MK as the input message.

o 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 PRV, 128 bits suitable for the seed, the Conn_Key, in the AES-CMAC operation over the segment.

3.1.3.  Tips for User Interfaces regarding KDFs

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.

UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1".

UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply "AES128".

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.

3.2.  MAC Algorithms

MACs for TCP-AO have the following interface:

MAC (Conn_Key(KDF), Message, Truncation)

where:

- MAC-algo:

MAC Algorithm used

- Conn_Key:

Variable; Result of KDF.

- KDF:

Name of the TCP-AO KDF used

- Key_Length:

Length in bits required for the Conn_Key used in this MAC

- Truncation:

Length in bits to which the final MAC result is truncated before being placed into TCP-AO header

This document specifies two MAC algorithm options for generating the MAC for TCP-AO's option header:

* HMAC-SHA-1-961

based on [RFC2404] (Madson, C. and R. Glenn, “The Use of HMAC-SHA-1-96 within ESP and AH,” November 1998.)

* AES-128-CMAC-96

based on [RFC4493] (Song, JH., Poovendran, R., Lee, J., and T. Iwata, “The AES-CMAC Algorithm,” June 2006.)

Both provide a high level of security and efficiency. The AES-128-CMAC-96 is potentially more efficient, particularly in hardware, but HMAC-SHA-1-96 is more widely used in Internet protocols and in most cases could be supported with little or no additional code in today's deployed software and devices.

An important aspect to note about these algorithms' definitions for use in TCP-AO is the fact that the MAC outputs are truncated to 96 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 produces a 160 bit result. The MAC output are then truncated to 96 bits to provide a reasonable tradeoff between security and message size, for fitting into the TCP-AO header.

3.2.1.  The Use of HMAC-SHA-1-96

By definition, HMAC [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) requires a cryptographic hash function. SHA1 will be that has function used for authenticating and providing integrity validation on TCP segments with HMAC.

For:

MAC (Conn_Key(KDF), Message, Truncation)

HMAC-SHA-1-96 for TCP-AO has the following values:

- MAC-algo:

MAC Algorithm used

- Conn_Key:

Variable; Result of KDF.

- KDF:

KDF_HMAC_SHA1

- Key_Length:

160 bits

- Truncation:

96 bits

3.2.2.  The Use of AES-128-CMAC-96

In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually define a usage of AES-128 as a cipher-based MAC according to [NIST‑SP800‑38B] (National Institute of Standards and Technology, “Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” May 2005.).

For:

MAC (Conn_Key(KDF), Message, Truncation)

AES-128-CMAC-96 for TCP-AO has the following values:

- MAC-algo:

AES-128-CMAC-96 [RFC4493] (Song, JH., Poovendran, R., Lee, J., and T. Iwata, “The AES-CMAC Algorithm,” June 2006.)

- Conn_Key:

Variable; Result of KDF.

- KDF:

KDF_AES_128_CMAC

- Key_Length:

128 bits

- Truncation:

96 bits

According to [RFC4493] (Song, JH., Poovendran, R., Lee, J., and T. Iwata, “The AES-CMAC Algorithm,” June 2006.), 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.

4.  Change History (RFC Editor: Delete before publishing)

[NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.]

lebovitz...-00 - original submission

lebovitz...-01- 2nd submission

• 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.
• changed KDF = PRF... to Derived_Key = KDF... (EKR)
• added the text on how to deal with future KDF to end of s3.1 (EKR)
• removed references to TCP-AO "manual key mode". Changed to TCP-AO's "current mode of manual keying". (Touch)
• removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, per wg consensus at ietf74.
• 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)
• sect 3.1, in Input description, dropped "0x00". Added "NOTE" explaining why right after the output_length description.
• cleaned up all references
• copy editing

5.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

[NOTE TO RFC EDITOR: this section for use during I-D stage only. Please remove before publishing as RFC.]

List of stuff that still needs work

• fix the iana registry section. Need registry entries for the KDFs and all the other values?
• 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 again.

6.  Security Considerations

This document inherits all of the security considerations of the TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents.

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.

Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. ][RFC4086] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) contains helpful information on both key generation techniques and cryptographic randomness.

Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 bit / 16 byte key as the seed. However, for convenience to the administrators/deployers, we did not want to force them to enter a 16 byte Master_Key. So we specified the sub-key routine that could handle a variable length Master_Key, one that might be less than 16 bytes. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) as listed above. We simply attempted to "put a fence around stupidity", in as much as possible.

This document concerns itself with the selection of cryptographic algorithms for the use of TCP-AO. The algorithms identified in this document as "MUST implement" 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.

7.  IANA Considerations

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.

[need to finish this section]

8.  Acknowledgements

Paul Hoffman, from whose [RFC4308] (Hoffman, P., “Cryptographic Suites for IPsec,” December 2005.) I sometimes copied, to quickly create a first draft here.

Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two hash algorithms for TCP-AO is largely cut and pasted into various sections of this document.

Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] (Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” December 2005.) & [RFC4305] (Eastlake, D., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” December 2005.) text was consulted and sometimes used in the Requirements Section 2 (Requirements) section of this document.

(In other words, I was truly only an editor of others' text in creating this document.)

Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues with the inputs to PRFs for the KDFs, and was of great assistance in how to structure the text, as well as the correct cryptographic decisions.

David McGrew who caught an issue with the cryptography of section 3.1.2. Now we need to also go and fix [RFC4615] (Song, J., Poovendran, R., Lee, J., and T. Iwata, “The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE),” August 2006.).

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.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address