Network Working Group B. Weis Internet-Draft C. Appanna Expires: August 28, 2006 D. McGrew A. Ramaiah Cisco Systems February 24, 2006 Automated key selection extension for the TCP Authentication Option draft-weis-tcp-auth-auto-ks-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes an automated key selection extension for the TCP [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key selection extension allows two TCP endpoints to authenticate TCP segments using a Message Authentication Code (MAC) key chosen dynamically by an endpoint, rather than using a pre-configured MAC key. Weis, et al. Expires August 28, 2006 [Page 1] Internet-Draft Automated TCP Auth Key Selection February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Automatic Key Selection Process . . . . . . . . . . . . . . . 5 2.1. Use of Key Chains . . . . . . . . . . . . . . . . . . . . 5 2.1.1. KEK Configuration . . . . . . . . . . . . . . . . . . 5 2.1.2. MAC Key Configuration . . . . . . . . . . . . . . . . 6 2.2. Sender Operations . . . . . . . . . . . . . . . . . . . . 6 2.3. Receiver Operations . . . . . . . . . . . . . . . . . . . 7 2.4. Authantication Data Format . . . . . . . . . . . . . . . . 7 2.4.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 8 3. MAC Algorithms using Nonces . . . . . . . . . . . . . . . . . 9 3.1. Authentication Data Format . . . . . . . . . . . . . . . . 9 3.2. MAC Algorithm ID Types . . . . . . . . . . . . . . . . . . 10 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Authentication Data Only . . . . . . . . . . . . . . . 11 4.1.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 11 4.2. Insuitability of the TCP Sequence Number as the Sequence Number . . . . . . . . . . . . . . . . . . . . . 12 4.3. Retention of automatically generated keys . . . . . . . . 12 4.4. TCP sequence number wrapping . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Weis, et al. Expires August 28, 2006 [Page 2] Internet-Draft Automated TCP Auth Key Selection February 2006 1. Introduction The TCP Authentication Option [I-D.bonica-tcp-auth] specifies a means of providing integrity protection to BGP and other TCP-based routing protocols. It does this by applying a Message Authentication Code (MAC) to the TCP pseduo-header, TCP header, and TCP segment data (if any). Several allowed MAC algorithms are defined. MAC algorithms take as input a secret key known to the two TCP endpoints, called a MAC key. The TCP Authentication Option describes a means of organizing and storing MAC keys in a key chain. These keys are chosen out of band, and manually entered into the configuration of the TCP endpoints. This memo describes a means by which TCP endponts choose MAC keys using an automated process, and is a more secure and operationally simpler method of key selection. The automatically generated keys are protected during transmission by a long-lived key encryption key (KEK) shared between the TCP endpoints. This memo also specifies additional strong MAC algorithms that use unique nonces for each TCP segment. This is important because at present the best-performing MACs all have this requirement. MAC algorithms using nonces are only safe to use with an automatic key selection process. This is because an automatic key selection process can quickly and securely react to the condition that a non- unique nonce is about to be used. 1.1. Requirements notation 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]. 1.2. Terminology Key Encrypting Key (KEK). A key used with a cryptographic algorithm to encrypt another key. Message Authentication Code (MAC). A keyed cryptographic integrity function computed on data using a secret key to detect modifications of the data (e.g., a TCP segment). An attacker who does not know the secret key is unable to generate the MAC corresponding to a particular message, or to modify the message in an undetectable fashion, with very high probability. This is true even if the attacker can perform a chosen-message attack, and cause a legitimate user of the system to authenticate messages of its choice. Weis, et al. Expires August 28, 2006 [Page 3] Internet-Draft Automated TCP Auth Key Selection February 2006 Message Authentication Code Key (MAC Key). A key used to authenticate a TCP segment. Weis, et al. Expires August 28, 2006 [Page 4] Internet-Draft Automated TCP Auth Key Selection February 2006 2. Automatic Key Selection Process This memo specifies a method for a TCP endpoint to automatically generate a TCP Enhanced Authentication Option MAC key and passing it to a peer in-band. The MAC key is passed in the TCP Enhanced Authentication Option encrypted under a Key Encrypting Key (KEK) known to both TCP end-points. When an encrypted key is included in this TCP option, it is used to authenticate the current segment, and all subsequent segments in the TCP exchange until a new key is chosen by either of the TCP end-points. Key encryption algorithms and modes used with the KEK MUST be strong enough so that inline transmission of the key does not degrade the security offered by the MAC algorithm. One strong KEK algorithm is described below. Two TCP end-points configure one or more KEKs before the in-band key selection method is used. These KEKs can be entered and stored on a key chain, as described in the TCP Enhanced Authentication Option. A KEK is never used directly as a MAC key because using a cryptographic key for multiple purposes (such as a KEK and a MAC key) may cause a cryptographic vulnerability and weaken the key. A KEK typically has a long lifetime. When the automated key selection method is used, MAC keys are generated as needed using a strong random number generator. The KEK is used to encrypt the MAC key, and the resulting ciphertext is then included in the Encrypted Key portion of the TCP Enhanced Authentication Option. This approach allows for a scheduled automatic generation of keys that can be periodically replaced based on the policy of either TCP. Generating and distributing a MAC key requires no operator intervention on either TCP endpoint. 2.1. Use of Key Chains Both MAC keys and KEKs are configured in key chains as described in Section 5 of the TCP Enhanced Authentication Option. The following sections describe the requirements for configuring the keys. 2.1.1. KEK Configuration The KEK is manually configured in a key chain with the same attributes as described in the TCP Enhanced Authentication Option. This section describes KEKs as if they are stored in a key chain different from MAC keys so as to not complicate or alter the MAC key chain semantics described in the TCP Enhanced Authentication Option. However, this section does not mandate any specific implementation. Note that the presence of multiple KEKs in the same key chain allows for automatic KEK rollover. KEKs can also be configured with a direction (used for inbound and/or outbound segments). This semantic Weis, et al. Expires August 28, 2006 [Page 5] Internet-Draft Automated TCP Auth Key Selection February 2006 allows each TCP Endpoint to choose an independent outbound KEK, if desired. 2.1.2. MAC Key Configuration The automatically generated MAC key is stored in the MAC key chain with the following attributes: o Identifier i set from the TCP Enhanced Authentication Option o Authentication algorithm A[i] set from the TCP Enhanced Authentication Option o Shared secret K[i] set from the automatically generated MAC Key o Inbound or outbound set depending on the setting of V[kek]. o Start time S[i] set from the current time o End time [T] set as the highest possible value o S'[i] set from the current time (unless V[kek] indicates outbound- only, in which S'[i] is set to the highest possible value) o T'[i] set to the highest possible value The use of pair-wise automatically generated MAC Keys is especially powerful, because each side can choose independently when to begin using a new MAC Key for its outbound segments. (See the discussion on V[i] in the TCP Enhanced Authentication Option). 2.2. Sender Operations A TCP Endpoint choosing a new MAC Key uses the following step: o Generates a MAC Key of the appropriate length using a strong random number generator. A random number generator approved for NIST PUB 140-2 [FIPS.140-2.AnnexC] SHOULD be used. o Places the MAC Key into its key chain as described above. A[i] is set to a chosen authentication algorithm. The Key ID i is set to a Key Id value currently unused in this key chain. o Creates a TCP Enhanced Authentication Option with The K bit set to 1, the Alg ID set to A[i], and the Key ID set to i. o Adds an Authentication Data formed as described below. Weis, et al. Expires August 28, 2006 [Page 6] Internet-Draft Automated TCP Auth Key Selection February 2006 When a TCP end-point sends a new key, it SHOULD retain the previous key until the peer also begins to encrypt using the new key. Doing so allows a continued receipt of TCP segments from the peer, including ack messages indicating that the segment with the new MAC key was not received. 2.3. Receiver Operations A TCP Endpoint receiving a new MAC Key uses the following steps: o Detects that the packet includes an encrypted MAC Key by observing that the K bit is set. o Extracts the new MAC Key by decrypting it with the KEK and verifying that the decrypted key is well formed (i.e., the KEK Algorithm ID is a known algorithm id, and the Reserved bits are set to zero). o Verifies that the MAC Key was used to authenticate the packet. o Places the MAC Key into its key chain as described above. A[i] is set to be the authentication algorithm defined in the In-line Encrypted Key Payload. The Key ID i is set to a Key Id value defined in the In-line Encrypted Key Payload. 2.4. Authantication Data Format The TCP Enhanced Authentication Option defines an Authentication Data field, which always contains at least a Message Authentication Code. When the automated key selection option is used, the Authentication Data field includes both the MAC and an In-line Encrypted Key Payload, as shown in the following figure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-line Encrypted Key Payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Authentication Code field contains the output of the MAC algorithm. Its size is deterministic based on MAC algorithm. The In-line Encrypted Key Payload is constructed as follows: Weis, et al. Expires August 28, 2006 [Page 7] Internet-Draft Automated TCP Auth Key Selection February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|KEK Alg ID |Res|KEK Key ID | Encrypted Key ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Res (2 bits) -- Reserved bits, set to zero. o KEK Alg ID (6 bits) -- This field contains an algorithm identifier to be used with the key encrypting key. o Res (2 bits) -- Reserved bits, set to zero. o KEK Key ID (6 bits) -- This field contains an algorithm type to be used with the key encrypting key. o Encrypted Key (variable). The size of the encrypted key field depends upon the size of the encrypted key (see below). 2.4.1. KEK Algorithm ID Types The MAC algorithms described in [I-D.bonica-tcp-auth] and this memo all use a key of 128-bits or smaller. The following algorithm is suitable to be used as a key encrypting key for these key sizes: AES-128-ECB. The MAC key is encrypted using an AES 128-bit key encrypting key, resulting in a 128-bit encrypted key. Use of ECB mode is acceptable because only one block is being encrypted. This algorithm MUST NOT be used to encrypt a MAC key larger than 128 bits. If a MAC algorithm requiring a key of larger than 128 bits is defined for use with this automated key selection extension, then a different key encrypting key algorithm will be required. Two possible methods are defined in [RFC3394] and [RFC3537]. Weis, et al. Expires August 28, 2006 [Page 8] Internet-Draft Automated TCP Auth Key Selection February 2006 3. MAC Algorithms using Nonces All MAC algorithms take two types of inputs: the data to be authenticated, and the key. Many MAC algorithms (e.g., AES-128-CMAC-96 and HMAC-SHA-1-96) take only these inputs, which results in an Authentication Data field of the size of the resulting MAC. However, another class of MAC algorithms takes an additional input called a "nonce". Algorithms requiring a nonce tend to be better performing MAC algorithms, and thus have value when used with the TCP Enhanced Authentication Option. A nonce permutes the output of a MAC algorithm such that it returns a unique value for each ICV value generated with a particular key and nonce pair. However, a particular key and nonce pair MUST NOT be used to authenticate two different sets of data. Doing so may weaken the MAC such that an attacker is able to generate properly formed MACs, which is a catastrophic cryptographic failure. Note that this restriction results in the requirement that a single MAC key MUST NOT be used to protect more than one TCP session. In order to guarantee that nonces used with a particular MAC key are unique, a monotonically increasing sequence number is included in the nonce. 3.1. Authentication Data Format If the MAC algorithm requires a nonce for its operation, the sequence number part of the nonce MUST be included at the beginning of the Authentication data, as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Sequence Number (32 bits). A monotonically increasing value used as a base for a nonce for algorithms requiring a unique value for each ICV value generated with a particular key. The first sequence number used with a particular MAC key is typically 1, although it MAY start a higher value. When a sequence number reaches 2**32-1, the key MUST NOT be used to authenticate any further packets. o Message Authentication Code (variable). The size of the MAC varies according to the MAC algorithm definition (see table in a later section). There are no restrictions on the size of the Message Authentication Code field. In all cases, the MAC Weis, et al. Expires August 28, 2006 [Page 9] Internet-Draft Automated TCP Auth Key Selection February 2006 algorithm definition must produce a result that is a multiple of 8 bits. When a MAC algorithm requiring a nonce is used with a TCP Extended Authentication Option where K is 1, the Authentication Data field is as follows, with each field defined as described above: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ In-line Encrypted Key Payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. MAC Algorithm ID Types All Algorithm IDs described in the TCP Authentication Option document are suitable for use with this option. Additionally, the following nonce based MAC algorithms are defined. o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the GMAC [GMAC] mode of operation, with the result truncated to 96 bits. This algorithm requires a 96-bit unique nonce. The nonce is formed as follows. The leftmost 56 bits are all set to zero. The next eight bits contain a direction byte. The binary value of the direction byte is 00000000 for the TCP endpoint sending the segment containing the encrypted key, and 00000001 for the TCP endpoint receiving the segment containing the encrypted key. The rightmost 32 bits are copied from the Sequence Number field. The AES-128-GMAC-96 algorithm MUST be implemented for an implementation to conform to this specification. o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC] with the result truncated to 96 bits. This algorithm also requires a nonce. For the purposes of this document the nonce will be a 40 bit nonce. The nonce is formed as follows. The first eight bits contain a direction byte. The binary value of the direction byte is 00000000 for the TCP endpoint sending the segment containing the encrypted key, and 00000001 for the TCP endpoint receiving the segment containing the encrypted key. The rightmost 32 bits are copied from the Sequence Number field. Weis, et al. Expires August 28, 2006 [Page 10] Internet-Draft Automated TCP Auth Key Selection February 2006 4. Discussion 4.1. MAC Option Size The cumulative number of TCP option bytes is currently limited to 40 bytes. The TCP MAC Option can consume a variable number of bytes, depending on a number of factors. The following sections describe several scenarios. The size of the authentication data field varies depending on the output of the MAC algorithm and whether or not the MAC algorithm requires a sequence number field. The following table lists the MAC algorithms identified in this proposal and the resulting size of the authentication data field. +-----------------+---------------------------------+ | MAC Algorithm | Authentication Data Size (bits) | +-----------------+---------------------------------+ | HMAC-SHA-1-96 | 96 | | AES-128-CMAC-96 | 96 | | AES-128-GMAC-96 | 128 | | AES-128-UMAC-96 | 128 | +-----------------+---------------------------------+ 4.1.1. Authentication Data Only The TCP Enhanced Authentication Option consumes four bytes for the option header. If K is not set to one, then the total size of the TCP MAC option is only the additional number of bytes needed by the MAC algorithm. All MAC algorithms described in the TCP Enhanced Authentication Option and this memo require 12 bytes. This gives a total of 16 bytes for the TCP MAC option. MAC algorithms requiring a nonce need an additional four bytes to carry a sequence number in the authentication data portion of the option. This results in a total of 20 bytes. However, MAC algorithms requiring a nonce tend to consume fewer software and/or hardware resources than other MAC algorithms. Using a MAC algorithm requiring a nonce trades off an additional four bytes in the segment for a faster cryptographic algorithm. 4.1.2. Adding an Encrypted Key If K is set to one, then the encrypted key field is added to the MAC option. This adds the ability to do in-band keying, and simplify key management operations, but with a cost of additional TCP option bytes. When an encrypted key is included, two bytes are always needed to describe the KEK algorithm and KEK Key Identifier used to Weis, et al. Expires August 28, 2006 [Page 11] Internet-Draft Automated TCP Auth Key Selection February 2006 encrypt the MAC key. The KEK algorithm also determines the number of bytes needed for the encrypted MAC key. The one KEK algorithm defined in this proposal requires 16 bytes, which results in a total of 18 bytes for the encrypted key. Thus, 34 bytes total bytes are required when paired with a MAC algorithm not needing a nonce (although 36 bytes may be used if padding is added). A total of 38 bytes are required when paired with a MAC algorithm needing a nonce (or 40 bytes if padding is added). However, the encrypted key is only required when one of the TCP end- points requires a new key (i.e., at the start of a TCP session, or when the security policy mandates a change later on in the session.) All other segments in the TCP session contain only the Authentication Data portion, which remains a modest size. Additional KEK methods that require fewer bytes passed in the In-line Encrypted Key Payload may be defined at a later time, which would reduce the use of TCP Option bytes. 4.2. Insuitability of the TCP Sequence Number as the Sequence Number Using an additional four TCP option bytes for a sequence number dedicated to the MAC option is required in order to satisfy the cryptographic requirement of unique nonces. No other value in a TCP packet is guaranteed to be unique. At first glance, the TCP Sequence Number would appear to be suitable. However, the TCP Sequence Number can wrap, after which it increments back through the same sequence number space. A security system should not depend on an external value when it can be manipulated such that the security constraint of the system is violated. This sort of dependency greatly increases the size of the security boundary (that is, the logical boundary containing all of the security functionality), which makes the validation of the correctness of the security system much more difficult. In this case, the TCP Sequence Number is a value that can be manipulated elsewhere by the TCP module such that it is not actually unique enough for the security constraint. For example, some TCP redundancy solutions may resend TCP segments starting with the same TCP sequence number but with a different length. This violates the security requirement that a key and nonce are never used on TCP segments with different data. 4.3. Retention of automatically generated keys Automatically generated keys MUST NOT be retained after their lifetime has expired. Weis, et al. Expires August 28, 2006 [Page 12] Internet-Draft Automated TCP Auth Key Selection February 2006 Automatically generated keys SHOULD NOT be saved over a reboot. If this advice is ignored, a nonce containing a sequence number greater than the most recently used sequence number MUST be stored with the key. However, a more reliable system would simply generate a new MAC key (and associated nonce, if required) when the system resumes operation. 4.4. TCP sequence number wrapping When a TCP sequence number wraps around (i.e., from a high number to a low number), an automatically generated key MUST be expired irrespective of the time based policy in the key chain and replaced with a new key. If the old key were not expired, there is a slight possibility that the TCP sequence numbers in the segment will both wrap, and both appear to be current in the TCP window. In this case, the segment may be accepted by the receiver as a new segment. Should the replayed segment contain an encrypted MAC key, and if the KEK has not changed, then the receiver will install the old key and no longer communicate properly with the authentic sender of the TCP segments. Weis, et al. Expires August 28, 2006 [Page 13] Internet-Draft Automated TCP Auth Key Selection February 2006 5. IANA Considerations The terms "Standards Action" and "Private Use" in this section indicate the polices described for these terms in [RFC2434]. The TCP Authentication Code header includes an Algorithm ID field. The following two new Algorithm ID types are defined in this document, which require values be assigned to them: AES-128-GMAC-96, AES-128-UMAC-96. The In-line Encrypted Key Payload contains an Algorithm ID, for which IANA is to create and maintain a registry entitled "Key Encrypting Key Algorithm IDs". This document defines the following initial set of IDs: KEK Algorithm ID Value ---------------- ----- RESERVED 0 AES-128-ECB 1 Standards Action 2-47 Private Use 48-63 Weis, et al. Expires August 28, 2006 [Page 14] Internet-Draft Automated TCP Auth Key Selection February 2006 6. Security Considerations This proposal allows for automatic re-keying for the TCP Enhanced Authentication Option, which provides the following key management benefits: o Automated key lifetime management. A system can rollover keys triggered by any means chosen by the system (e.g., volume lifetime, time lifetime). o Automated key selection. Keys chosen with a good random number generator are generally superior in quality to keys chosen by a human operator. o Keys are chosen for use of a particular TCP session, and cannot be shared between TCP session to different peers. Use of automatic key selection requires a static KEK with a long lifetime. Whereas the KEK needs to be changed periodically, the length of the period should be very long, compared to the lifetime of the MAC keys. MAC algorithms requiring a unique nonce per segment (e.g., AES-128- GMAC-96) SHOULD NOT be used be used with manually configured MAC keys. If the sequence number used as an input to the nonce wraps (or is re-initialized after a system reboot), a single nonce would be used multiple times with a single key. This would cause a catastrophic cryptographic failure, with the amount of damage dependant upon the actual algorithm. Weis, et al. Expires August 28, 2006 [Page 15] Internet-Draft Automated TCP Auth Key Selection February 2006 7. References 7.1. Normative References [FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, < http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. [GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation (GCM)", Submission to NIST modes of operation, May 2005, . [I-D.bonica-tcp-auth] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", draft-bonica-tcp-auth-04 (work in progress), February 2006. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., and P. Rogaway, "UMAC: Fast and Secure Message Authentication", Advances in Cryptography -- CRYPTO '99 , September 1999, . 7.2. Informative References [FIPS.140-2.AnnexC] National Institute of Standards and Technology, "Annex C: Approved Random Number Generators for FIPS PUB 140-2, Security Requirements for Cryptographic Modules", FIPS PUB 140-2 Annex C, January 2005, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002. Weis, et al. Expires August 28, 2006 [Page 16] Internet-Draft Automated TCP Auth Key Selection February 2006 [RFC3537] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003. Weis, et al. Expires August 28, 2006 [Page 17] Internet-Draft Automated TCP Auth Key Selection February 2006 Authors' Addresses Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-4796 Email: bew@cisco.com Chandrashekhar Appanna Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-526-6198 Email: achandra@cisco.com David McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-301-349-5815 Email: mcgrew@cisco.com Anantha Ramaiah Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA Phone: +1-408-525-6486 Email: ananth@cisco.com Weis, et al. Expires August 28, 2006 [Page 18] Internet-Draft Automated TCP Auth Key Selection February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Weis, et al. Expires August 28, 2006 [Page 19]