EAP Working Group Internet Draft J. Salowey Document: draft-salowey-eap-protectedtlv-00.txt Cisco Systems Expires: July 2003 January 2003 Protected EAP TLV Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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. Abstract EAP type-length-value (TLV) message types provide a mechanism for encapsulating additional information in an EAP conversation. In some cases it is useful to cryptographically protect this information to maintain the integrity and/or privacy of the communication. This document defines a TLV type that uses message authentication to maintain the integrity of the data, encryption to protect the privacy of the data and sequence numbers to protect replays or re-sequencing of the data. Although protected TLVs must be chained after an authentication mechanism that generates key material the protection mechanism is independent of any particular authentication mechanism. Table of Contents 1. Introduction...................................................2 2. Message protection and validation..............................2 2.1 AES-128-HMAC-SHA1-128......................................2 3. Protected TLV format...........................................3 3.1 Format of Encrypted Data...................................4 Salowey Expires - July 2003 [Page 1] Protected EAP TLV January 2003 4. Key Derivation.................................................5 Security Considerations...........................................6 References........................................................6 Acknowledgments...................................................7 Author's Addresses................................................7 1. Introduction The EAP-TLV [1] mechanism provides a way to carry various types of information in an EAP [2] conversation. For example it may be used to carry authorization data or status indication. It is often desirable to protect the integrity and privacy of this information. This method must be chained after a previous EAP Authentication exchange that established a root key which can be used to derive a key hierarchy of additional keys. This document describes the derivation of a portion of the key hierarchy to protect additional messages, the format of a protected TLV and the cryptographic operations used to protect and verify the TLV. Protected TLVs must be chained after an authentication mechanism that generates key material. 2. Message protection and validation In general the method for protecting TLVs is defined by various cipher suites. This document defines one cipher suite that must be supported by all implementations: AES-128 with HMAC-SHA1-128. The protected message also contains a sequence number to be used for replay detection. The message format is described in section 3. Verification involves verifying a sequence number, verifying a MAC and decrypting the data. The sequence number is incremented for each message. The exception to this is re-transmissions in which case the sequence number is not incremented. If a duplicate or out of order sequence number is received verification fails and the message is dropped. If the message MAC validation fails it is also silently dropped. 2.1 AES-128 with HMAC-SHA1-128 First a 128 bit initialization vector (IV) is generated. The IV is used to along with the encryption key to initialize the AES 128 [4] cipher in CBC [5]. The encryption key is derived as described in section 4. The encapsulated TLV is padded with 0 to a 16 byte boundary and then encrypted using the cipher. The MAC is calculated use HMAC-SHA1-128 [3] over the protected TLV header, IV, encrypted TLV and the MAC field set to 0. Salowey Expires - July 2003 [Page 2] Protected EAP TLV January 2003 During validation first the sequence number is checked. If it is a duplicate or out of sequence message the receiver drops it. Next the MAC is verified, if the verification fails then the message is dropped. Finally the TLV is decrypted and the unencrypted TLV processed. 3. Protected TLV format The format of a protected TLV is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Protected TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cipher | Seq No | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_ | | | IV | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data... . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M The mandatory bit is always set since the receiver must be able to verify and decode the packet in order to find out the actual contents, which may in fact be optional. R Reserved, set to 0 Type TBD - Encrypted TLV Length Salowey Expires - July 2003 [Page 3] Protected EAP TLV January 2003 Length û 4 + IV Length + Encrypted Data Length + MAC Length Cipher Cipher suite in use, defines both message authentication and encryption algorithms 0x0001 - AES-128 with HMAC-SHA1-128 SeqNo The sequence number starts at 0 for the first protected TLV sent and is incremented for each subsequent protected TLV. Sequence numbers must not be repeated. Reserved Set to 0 IV The IV is an Octet string of random bits. For AES-128 the IV is 16 bytes (128 bits). Encrypted Data Encrypted TLV of variable length. The encrypted data is the encapsulated protected TLV. The format of the encrypted data is described in section 3.1. MAC Data MAC of fixed length depending on Cipher suite in use. The MAC is calculated over the above fields and a zeroed out MAC field. For HMAC-SHA1-128 the MAC is 16 bytes (128 bits). 3.1 Format of Encrypted Data The format of the encrypted data is the unprotected TLV plus 0 padding if required. AES-128 requires padding to a 16 byte boundary. Salowey Expires - July 2003 [Page 4] Protected EAP TLV January 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 0 Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 if Mandatory (See [2]) R Reserved, set to 0 (see [2]) TLV Type Type of TLV (see [2]) Length Length of TLV (see [2]) Value TLV value (see [2]) 0 Padding 0 are appended to the value to pad the TLV to multiple of 16 bytes. 4. Key Derivation Keys are needed for cryptographic message protection. Keys are obtained from EAP authentication methods completed before protected TLVs are sent. A least one previous EAP method must have generated a root key for application use with the required amount of entropy. The root key is taken from the pairwise master key. The required key length for AES-128 with HMAC-SHA1-128 is 128 bits. In order to make the keys independent of other operations they are derived by using HMAC-SHA1 as a PRNG with the pairwise master key (PMK) as the key the ASCII string ôprotected TLV encryption keyö Salowey Expires - July 2003 [Page 5] Protected EAP TLV January 2003 (without quotes) concatenated with the two byte cipher suite number for the data for the encryption key and the ASCII string ôprotected TLV authentication keyö (without quotes) concatenated with the two byte cipher suite number for the MAC key. Encryption Key = HMAC-SHA1 (PMK,öprotected TLV encryption keyö + ciphersuite number) MAC Key = HMAC-SHA1 (PMK,öprotected TLV authentication keyö + ciphersuite number) For AES-128-HMAC-SHA1-128 the keys are truncated to 128 bits. If more than one previous authentication method has generated a key they are combined in a method that is TBD. Security Considerations The keys used in the message protection rely upon keys generated by previous EAP authentication mechanism in the same session. One of the mechanisms must generate a key with the required amount of entropy. A different key must be derived for each new EAP session. It is possible that an application may not use a pairwise master key to derive additional keys for cryptographic functions, but rather use the key directly for encryption and message protection. If the key is used directly this may compromise the security of the protected TLV since if the key is recovered then the TLV protection keys may be recovered as well. References [1] Hiller, Palekar, and Zorn ôA Container Type for the Extensible Authentication Protocol (EAP)ö, http://www.ietf.org/internet- drafts/draft-hiller-eap-tlv-00.txt, October 2002 (work in progress) [2] L. Blunk, J. Vollbrecht, B. Aboba, "Extensible Authentication Protocol (EAP)", draft-ietf-pppext-rfc2284bis-07.txt, work-in- progress, October 2002. (NORMATIVE) [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. (NORMATIVE) [4] Federal Information Processing Standard (FIPS) draft standard, "Advanced Encryption Standard (AES)", Salowey Expires - July 2003 [Page 6] Protected EAP TLV January 2003 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf, September 2001. (NORMATIVE) [5] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, December 1980. (NORMATIVE) Acknowledgments Author's Addresses Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US E-mail: jsalowey@cisco.com Phone: +1 206 256 3380 Salowey Expires - July 2003 [Page 7]