Network Working Group Internet Draft J. Salowey Document:draft-salowey-eap-protectedtlv-01.txt Cisco Systems Expires: September 2003 March 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..............................3 2.1 AES-128-HMAC-SHA1-128......................................3 3. Protected TLV format...........................................3 3.1 Format of Encrypted Data...................................5 4. Key Derivation.................................................6 Salowey Expires - September 2003 [Page 1] Protected EAP TLV March 2003 Security Considerations...........................................7 References........................................................7 Acknowledgments...................................................8 Author's Addresses................................................8 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 an extended master session key, defined in [6] 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. 1.1 Terminology EAP Application A consumer of EAP keying material. Examples include link layer encryption or a protected EAP-TLV. Master Session Key (MSK) Keying material exported by an EAP method. Extended Master Session Key (EMSK) Keying material taken from a specific portion of the MSK that is not used for any other purpose than the derivation of keys for various EAP applications. It is defined in [6]. Usually bytes 64..N of MSK. Application Master Session Key (AMSK) Keying material used to derive ciphering keys (encryption and MAC) for the application in an application specific way. Salowey Expires - September 2003 [Page 2] Protected EAP TLV March 2003 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 covering the entire protected TLV packet 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. 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 In the following formats bits are transmitted from left to right. The format of a protected TLV is as follows: Salowey Expires - September 2003 [Page 3] Protected EAP TLV March 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| Protected TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cipher | Seq No | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 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 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 Salowey Expires - September 2003 [Page 4] Protected EAP TLV March 2003 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, most significant bit first. 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 all above fields and a zeroed out MAC field. The MAC is treated as a bit string, most significant bit first. This includes the header fields such as type, length, cipher and sequence number as well as the encrypted data and IV. 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. 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]) Salowey Expires - September 2003 [Page 5] Protected EAP TLV March 2003 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 extended master session key (EMSK) for application use with the required amount of entropy. The application master session key (AMSK) for Protected EAP TLV is derived according to EAP Key Derivation for multiple applications described in [6]. The key label used for protected TLV is "Protected EAP TLV Master Session Key" No application specific data is used in deriving the key. For AES- 128-HMAC-SHA1-128 the AMSK should be 128 bits. The AMSK is then used to derive the encryption and MAC keys as follows: 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. Salowey Expires - September 2003 [Page 6] Protected EAP TLV March 2003 If more than one previous authentication method has generated a key they are combined in a method described in [6]. These keys are derived locally and not exported out side the EAP Peer or Authenticator. 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 key strength. For AES-128-HMAC-SHA1-128 the required key strength is 128 bits. A different key must be derived for each new EAP session. The key derivation for Protected EAP-TLV makes use of the key derivation in [6]. It should be noted that the keys derived for this purpose should not be exported outside of the EAP Peer or Authenticator as they are not needed elsewhere. In addition the master session key used in deriving these keys should not be exported since that would result in the same effect as exporting the keys themselves. References [1] Hiller, Palekar, and Zorn "A Container Type for the Extensible Authentication Protocol (EAP)", draft-hiller-eap-tlv-00.txt, work-in- progress, October 2002 (NORMATIVE) [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)", 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) Salowey Expires - September 2003 [Page 7] Protected EAP TLV March 2003 [6] P. Eronen and J. Salowey, "EAP Key Derivation for Multiple Application", draft-salowey-eap-key-deriv-00.txt, work-in-progress, February 2003 (NORMATIVE) Acknowledgments Thanks to Glen Zorn for several helpful comments. 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 - September 2003 [Page 8]