Network Working Group Internet Draft J. Salowey Document:draft-salowey-eap-protectedtlv-02.txt Cisco Systems Expires: December 2003 June 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 TLV types that provide 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. This makes them useful for adding generic extensions to EAP methods. Table of Contents 1. Introduction...................................................2 1.1 Terminology................................................2 1.2 Uses.......................................................3 2. Message protection and validation..............................3 2.1 AES-128-CBC with HMAC-SHA1-128.............................4 Salowey Expires - December 2003 [Page 1]
Protected EAP TLV June 2003 3. Protected TLV formats..........................................4 In the following formats bits are transmitted from left to right..4 3.1 SeqNo-TLV..................................................4 3.2 MAC-TLV....................................................5 3.3 Encrypted-TLV..............................................6 3.4 Format of Encrypted Data...................................7 4. Key Derivation.................................................8 Security Considerations...........................................9 References........................................................9 Acknowledgments..................................................10 Author's Addresses...............................................10 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 protected result indications, secret credential information, or channel binding information. 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. A mechanism for the generic chaining of EAP- TLVs after EAP methods is yet to be defined. Protected TLVs are an important part of this framework. 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 for the purpose of link layer ciphering. Extended Master Session Key (EMSK) Keying material separate from the MSK that is not used for any other purpose than the derivation of keys for various EAP applications. It is defined in [6]. Salowey Expires - December 2003 [Page 2]
Protected EAP TLV June 2003 Application Master Session Key (AMSK) Keying material used to derive ciphering keys (encryption and MAC) for the application in an application specific way. 1.2 Uses Protected TLVs can be used to add the following features to a wide variety of EAP mechanisms: . Protected Acknowledged Success and Failure An EAP-TLV message with a MAC-TLV can be used to authenticate the success and in some cases the failure of a mechanism. . Channel Binding An EAP-TLV message with a MAC-TLV can be used to communicate channel binding information such as the MAC addresses of the 802.1x supplicant and authenticator. . Credential Distribution An Encrypted TLV main contain credentials that can optimize re- authentication. 2. Message protection and validation EAP TLV message authentication is provided by the MAC-TLV, encryption is provided in the Encrypted-TLV and sequencing is protected by the SeqNo-TLV. This document defines one cipher and one message authentication code that must be supported by all implementations: AES-128 and HMAC-SHA1-128. 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. Every EAP-TLV message that contains a MAC-TLV SHOULD contain a SeqNo- TLV and every EAP-TLV message that contains an Encrypted TLV SHOULD contain a MAC-TLV. The MAC-TLV and SeqNo-TLV MAY be omitted if the Encrypted-TLV uses a mode that provides both message authentication and sequence protection. Salowey Expires - December 2003 [Page 3]
Protected EAP TLV June 2003 2.1 AES-128-CBC 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 TLVs are 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 entire EAP-TLV message including header, unencrypted TLVs such as seqNo-TLV and the 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 formats In the following formats bits are transmitted from left to right. 3.1 SeqNo-TLV The format of a MAC-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| SeqNo-TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) SeqNo-TLV Salowey Expires - December 2003 [Page 4]
Protected EAP TLV June 2003 Length 4 Sequence Number 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. 3.2 MAC-TLV The format of a MAC-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| MAC-TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 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) MAC TLV Length 4 + MAC Length MAC Type Salowey Expires - December 2003 [Page 5]
Protected EAP TLV June 2003 Message authentication algorithm in use. (0x0001) HMAC-SHA1-128 Reserved Set to 0 MAC Data MAC of fixed length depending on the MAC Type. The MAC is calculated over the entire EAP-TLV message with a zeroed out MAC field. This includes the header, unencrypted TLVs such as sequence number, and the encrypted TLV. The MAC is treated as a bit string, most significant bit first. For HMAC-SHA1-128 the MAC is 16 bytes (128 bits). 3.3 Encrypted-TLV The format of a Encrypted-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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IV | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data... . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Salowey Expires - December 2003 [Page 6]
Protected EAP TLV June 2003 R Reserved, set to 0 Type (TBD) Encrypted TLV Length 4 + IV Length + Encrypted Data Length Cipher Encryption algorithm in use (0x0001) AES-128-CBC 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 consists of one or more plaintext TLVs. The format of the encrypted data is described in section 3.4. 3.4 Format of Encrypted Data The format of the encrypted data is one or more encrypted TLVs plus 0 padding if required. AES-128 requires padding to a 16 byte boundary. Salowey Expires - December 2003 [Page 7]
Protected EAP TLV June 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV (First TLV) | | | . . . . . . | | | TLV (More TLVs) | . . . . . . | TLV (Last TLV) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 0 Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV One or more TLVs to be encrypted 0 Padding 0 are appended to the value to pad the TLV to cipher block size if required. 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: Salowey Expires - December 2003 [Page 8]
Protected EAP TLV June 2003 Encryption Key = HMAC-SHA1 (PMK,"protected TLV encryption key" + cipher number) MAC Key = HMAC-SHA1 (PMK,"protected TLV authentication key" + MAC type number) For AES-128 and 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 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 and 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-04.txt, work-in- progress, June 2003 (NORMATIVE) [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 (NORMATIVE) Salowey Expires - December 2003 [Page 9]
Protected EAP TLV June 2003 [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) [6] P. Eronen and J. Salowey, "EAP Key Derivation for Multiple Application", draft-salowey-eap-key-deriv-01.txt, work-in-progress, June 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 - December 2003 [Page 10]