Network Working Group Y. Ohba Internet-Draft Toshiba Expires: September 4, 2007 S. Das Telcordia R. Lopez Univ. of Murcia March 3, 2007 An EAP Method for EAP Extension (EAP-EXT) draft-ohba-hokey-emu-eap-ext-01 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 September 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Ohba, et al. Expires September 4, 2007 [Page 1] Internet-Draft EAP-EXT Method March 2007 Abstract This document describes an EAP method that is used for extending EAP functionality. The extended functionality includes HOKEY re- authentication and MSK channel binding. The proposed EAP method (EAP-EXT) also allows sequencing of multiple EAP methods within itself. EAP-EXT can generate MSK (Master Session Key) and EMSK (Extended Master Session Key) in cases where inner method(s) implementations generate MSK but do not generate EMSK. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. EAP-EXT Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. MSK and EMSK exported from EAP-EXT . . . . . . . . . . . . 8 4.2. EAP-EXT-AUTH-KEY . . . . . . . . . . . . . . . . . . . . . 8 4.3. EAP-EXT-ENC-KEY . . . . . . . . . . . . . . . . . . . . . 8 4.4. HOKEY-REAUTH-KEY . . . . . . . . . . . . . . . . . . . . . 9 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10 6. EAP-EXT TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Method TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. AUTH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Peer-ID TLV . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Server-ID TLV . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Reauth-Key-Lifetime TLV . . . . . . . . . . . . . . . . . 13 6.6. PRF TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.7. Channel-Binding-Mechanism TLV . . . . . . . . . . . . . . 14 6.8. Channel-Binding-Data TLV . . . . . . . . . . . . . . . . . 14 6.9. Encryption-Algorithm TLV . . . . . . . . . . . . . . . . . 14 6.10. Integrity-Algorithm TLV . . . . . . . . . . . . . . . . . 15 6.11. Encrypted TLV . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Ohba, et al. Expires September 4, 2007 [Page 2] Internet-Draft EAP-EXT Method March 2007 1. Introduction EAP (Extensible Authentication Protocol) is an authentication protocol which supports multiple authentication algorithms known as "EAP methods" [RFC3748]. In EAP, an EAP peer and an EAP server generates EAP keying material, i.e., MSK (Master Session Key) and EMSK (Extended Master Session Key) upon successful authentication. A detailed framework for the generation, transport and usage of MSK is described in [I-D.ietf-eap-keying]. Additional functionalities such as HOKEY re-authentication [I-D.vidya-eap-er] and MSK channel binding [I-D.ietf-eap-keying] can be supported by extending EAP functionality. There can be two approaches for extending EAP functionality. One approach is to define new EAP Codes to realize the extended EAP functionality in addition to the existing ones, i.e., Request, Response, Success and Failure. This approach, however, requires changes to [RFC3748] and may also require changes to authenticators and lower layer protocols. The other approach is to define a new EAP method to realize the extended functionality. For both approaches, it may be desirable that these extended functionalities are backward compatible. In such cases, a mechanism for negotiating the capabilities on the extended functionalities between an EAP peer and an EAP server may be needed. This document describes an EAP method that is used for extending EAP functionality. The extended functionality includes HOKEY re- authentication and MSK channel binding. The proposed EAP method (EAP-EXT) also allows sequencing of multiple EAP methods within itself. EAP-EXT can generate MSK and EMSK in cases where inner method(s) implementations generate MSK but do not generate EMSK. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. Ohba, et al. Expires September 4, 2007 [Page 3] Internet-Draft EAP-EXT Method March 2007 2. EAP-EXT Overview EAP-EXT provides capabilities exchange. One bit (R-bit) is used for indicating HOKEY re-authentication capability. One bit (C-bit) is used for indicating channel binding capability. When EAP-EXT is used, the precedent EAP-Identity exchange MAY be omitted if the identity of the peer is known to the server before the server sends the first EAP-Request. Out of band mechanisms for providing the identity of the peer may be used e.g., transferring the identity of the peer between authenticators and servers. In EAP-EXT, extended EAP capabilities such as HOKEY re-authentication and MSK channel binding are exchanged between the peer and the server. At the same time, at least one EAP method (e.g., EAP-TLS) is run inside EAP-EXT for authenticating the peer. Inner method(s) are carried in Method TLVs (Type-Length-Values). Until an inner method generates EAP keying material, no AUTH TLV is included and the capabilities are non-protected. Hence, if there is only one inner EAP method, additional EAP-EXT exchange(s) with an AUTH TLV need(s) to be performed after completion of the inner method and before sending an EAP-Success or an EAP-Failure message. After an inner EAP method generates EAP keying material, EAP-EXT messages MUST be protected with an AUTH TLV. AUTH TLVs in EAP-EXT messages MUST be computed using EAP-EXT-KEY generated from EAP keying material of the latest successful inner method. This means that if there are multiple inner EAP methods that are sequentially run inside EAP-EXT, a new EAP-EXT-KEY is generated each time an inner EAP method in the sequence generates EAP keying material. Any inner EAP method MUST be capable of generating EAP keying material. At the end of a successful EAP-EXT run, EAP keying material is derived from the MSK generated by the last successful inner EAP method and is exported to the EAP layer. The pseudo random function used for deriving the EAP keying material and USRKs (Usage Specific Root Keys) [I-D.salowey-eap-emsk-deriv] MAY be negotiated within EAP- EXT using PRF TLVs. F-bit is used for indicating the end of EXP-EXT exchange. Figure 1 shows an example of EAP-EXT message sequence with a single inner EAP method and with PRF negotiation. Figure 2 shows an example of EAP-EXT message sequence with multiple inner EAP methods and without PRF negotiation. Ohba, et al. Expires September 4, 2007 [Page 4] Internet-Draft EAP-EXT Method March 2007 Peer Server | EAP-Request/Identity (optional) | |<---------------------------------------------------| | EAP-Response/Identity (optional) | |--------------------------------------------------->| | EAP-Request/EXT{Cap.(R,C),PRF(1,2),Method(Type X),| | CBM(1,2),CBD,IAL(x)} | |<---------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),PRF(1),Method(Type X), | | CBM(1)} | |--------------------------------------------------->| | ... | | EAP-Request/EXT{F,Cap.(R,C),PRF(1,2),Enc(Peer-ID, | | Server-ID,Reauth-Key-Lifetime), | | CBM(1,2),CBD,IAL(x),AUTH} | |<---------------------------------------------------| | EAP-Response/EXT{F,Cap.(R,C),PRF(2),CBM(1), | | AUTH} | |--------------------------------------------------->| | EAP-Success | |<---------------------------------------------------| F: F-bit is set Cap.(R,C): R-bit and C-bit of Capabilities field are set PRF(1,2): PRF TLV carrying PRF numbers 1 and 2 PRF(1): PRF TLV carrying PRF numbers 1 Method(Type X): Method TLV carrying method Type X Peer-ID: Peer-ID TLV Server-ID: Server-ID TLV Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV AUTH: AUTH TLV CBM(1,2): Channel-Binding-Mechanism TLV with channel binding mechanism numbers 1 and 2 CBM(1): Channel-Binding-Mechanism TLV with channel binding mechanism number 1 CBD: Channel-Binding-Data TLV IAL(x): Intergrity-Algorithm TLV with algorithm x. Enc(...): Encrypted TLV Figure 1: EAP-EXT message sequence with a single inner method and PRF negotiation Ohba, et al. Expires September 4, 2007 [Page 5] Internet-Draft EAP-EXT Method March 2007 Peer Server | EAP-Request/Identity (optional) | |<----------------------------------------------------| | EAP-Response/Identity (optional) | |---------------------------------------------------->| | EAP-Request/EXT{Cap.(R,C),Method(Type=X),CBM(1,2), | | CBD,IAL(x)} | |<----------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),Method(Type=X),CBM(2), | | CBD} | |---------------------------------------------------->| | .... | | EAP-Request/EXT{Cap.(R,C),Method(Type=Y), | | CBM(1,2),CBD,IAL(x),AUTH} | |<----------------------------------------------------| | EAP-Response/EXT{Cap.(R,C),Method(Type=Y), | | CBM(2),CBD,AUTH} | |---------------------------------------------------->| | .... | | EAP-Request/EXT{F,Cap.(R,C),Method(Type=Y), | | Enc(Peer-ID, Server-ID, | | Reauth-Key-Lifetime), CBM(1,2), | | CBD,IAL(x),AUTH} | |<----------------------------------------------------| | EAP-Response/EXT{F,Cap.(R,C),Method(Type=Y), | | CBM(2),CBD,AUTH} | |---------------------------------------------------->| | EAP-Success | |<----------------------------------------------------| F: F-bit is set Cap.(R,C): R-bit and C-bit of Capabilities field are set Method(Type-X): Method TLV carrying method Type X Method(Type-Y): Method TLV carrying method Type Y Peer-ID: Peer-ID TLV Server-ID: Server-ID TLV Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV AUTH: AUTH TLV CBM(1,2): Channel-Binding-Mechanism TLV with channel binding mechanism numbers 1 and 2 CBM(2): Channel-Binding-Mechanism TLV with channel binding mechanism number 2 CBD: Channel-Binding-Data TLV IAL(x): Intergrity-Algorithm TLV with algorithm x. Enc(...): Encrypted TLV Figure 2: EAP-EXT message sequence with multiple inner methods and without PRF negotiation Ohba, et al. Expires September 4, 2007 [Page 6] Internet-Draft EAP-EXT Method March 2007 3. Error Handling An error may happen for several reasons, e.g., due to failure of inner EAP method authentication or a malformed, unknown or missing EAP-EXT TLV. An error may be detected either by the peer or by the server. An EAP-EXT message that caused an error is referred to as an erroneous message. EAP-EXT messages with E-bit set are used for error indications. These messages are referred to as error indications. An error indication MUST contain an AUTH TLV, and SHOULD NOT contain other TLVs. Any erroneous message (including an erroneous error indication) without a valid AUTH TLV MUST be silently discarded. For an erroneous Request with a valid AUTH TLV, the peer sends an error indication Response. For an erroneous Response with a valid AUTH TLV, the server sends an error indication Request which is responded by the peer with an error indication Response. The server returns an EAP-Failure message in response to an error indication Response with a valid AUTH TLV. Ohba, et al. Expires September 4, 2007 [Page 7] Internet-Draft EAP-EXT Method March 2007 4. Keys EAP-EXT defines the following types of keys. 4.1. MSK and EMSK exported from EAP-EXT A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-EXT is derived from MSK_i, the MSK generated by the last successful inner EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in the following way. (MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128) 4.2. EAP-EXT-AUTH-KEY EAP-EXT-AUTH-KEY is used for computing AUTH TLVs for integrity protecting EAP-EXT messages. EAP-EXT-AUTH-KEY is used within EAP-EXT only and is never exported. The EAP-EXT-AUTH-KEY is derived from the MSK generated by the last successful inner EAP method (MSK_i), using the prf+ defined in [RFC4306] in the following way. EAP-EXT-AUTH-KEY = prf+(MSK_i, "EAP-EXT-Authentication-Key",length); The default hash algorithm for prf+ is PRF_HMAC_SHA2_256. The field length will depend upon the integrity algorithm selected by the EAP Server during the EAP-EXT exchange. When HMAC-SHA-256 [sha256] is used for the integrity algorithm, length=32. 4.3. EAP-EXT-ENC-KEY EAP-EXT-ENC-KEY is used for ciphering the content of Encrypted TLVs. It is derived from MSK_i, the MSK generated by the last successful inner EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in the following way. EAP-EXT-ENC-KEY = prf+(MSK_i, "EAP-EXT-Encryption-Key",length); The PRF used to generate EAP-EXT-AUTH-KEY is determined by the integrity algorithm selected by the EAP server during the EAP-EXT exchange. The default hash algorithm for prf+ is PRF_HMAC_SHA2_256. The field length will depend upon the negotiated encryption algorithm negotiated during EAP-EXT exchange. For example, when AES-CBC-128 is used, length=16. Ohba, et al. Expires September 4, 2007 [Page 8] Internet-Draft EAP-EXT Method March 2007 4.4. HOKEY-REAUTH-KEY HOKEY-REAUTH-KEY is used as the pre-shared key required for the HOKEY re-authentication mechanism [I-D.vidya-eap-er]. The length of HOKEY- REAUTH-KEY depends on the HOKEY re-authentication mechanism. The HOKEY-REAUTH-KEY is derived from the EMSK exported from EAP-EXT using the USRK derivation algorithm defined in [I-D.salowey-eap-emsk-deriv] as follows. HOKEY-REAUTH-KEY = KDF(EMSK, "EAP-EXT-Reauthentication-Key", length) Ohba, et al. Expires September 4, 2007 [Page 9] Internet-Draft EAP-EXT Method March 2007 5. Message Format EAP-EXT uses EAP Type XX (To be assigned by IANA). The message format including the common EAP fields (i.e., Code, Identifier, Length and Type) defined in [RFC3748] is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Version |F|E| Reserved | Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV(s) (optional) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- F This bit MUST be set to indicate that this is the last EAP-EXT message from the sender. Otherwise, this bit MUST NOT be set. E This bit is set when the message is an error indication. When this bit is set, F-bit MUST also be set. See Section 3 for detailed description on error indications. Version This 8-bit field indicates the version of the EAP-EXT method. This document defines Version 1. Reserved This 6-bit field is reserved for future extensions. This field MUST be set to zero by the sender and the recipient MUST ignore this field. Capabilities This field The Capabilities field contains extended EAP capabilities. The Capabilities field the following format. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R C r r r r r r| +-+-+-+-+-+-+-+-+ Ohba, et al. Expires September 4, 2007 [Page 10] Internet-Draft EAP-EXT Method March 2007 Each bit corresponds to a particular capability. The semantics of each bit is as follows. R This bit is set to indicate that the sender supports HOKEY re- authentication [I-D.vidya-eap-er]. When this bit is set in the final Request/EXT message (i.e., the Request/EXT with F-bit is set), the message MUST include a Server-ID TLV and a Peer-ID TLV and MAY include a Reauth-Key-Lifetime AVP. If this bit is set in the final Request/EXT and Response/EXT exchange, the peer and the server MUST generate an HOKEY-REAUTH-KEY. The Server-ID and Peer-ID contained in the Server-ID and Peer-ID TLVs and the HOKEY-REAUTH-KEY is used for HOKEY re- authentication. C This bit is set to indicate that the sender supports a channel binding mechanism for MSK. When this bit is set in a Request/ EXT message, one Channel-Binding-Mechanism TLV MUST also be included to indicate the channel binding mechanism(s) supported by the server. If the peer supports and wants to enable one of the channel binding mechanism(s) supported by the server, it sends a Response/EXT message with this bit set and one Channel- Binding-Mechanism TLV containing the selected channel binding mechanism. If this bit is set in the final Request/EXT and Response/EXT exchange with successful negotiation of one channel binding mechanism and the EAP-EXT method completes with success, the peer and the server MUST enable the negotiated channel binding mechanism. Other bits are reserved for future use, and MUST be set to zero by the sender and MUST be ignored by the recipient. TLV Zero, one or more TLVs (Type-Length-Value's). The TLV format of 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Ohba, et al. Expires September 4, 2007 [Page 11] Internet-Draft EAP-EXT Method March 2007 Type This field indicates the type of this TLV. Length This field indicates the length of this TLV in octets, including the Type and Length fields of the TLV. Value This field contains data specific to the TLV Type. Ohba, et al. Expires September 4, 2007 [Page 12] Internet-Draft EAP-EXT Method March 2007 6. EAP-EXT TLVs The following TLVs are defined. 6.1. Method TLV The Method TLV (Type 1) contains an EAP Method payload starting from Type field. 6.2. AUTH TLV The AUTH TLV (Type 2) contains integrity data used for protecting EAP-EXT messages. The EAP-EXT-KEY is used for computing AUTH TLVs. The TLV-Value field is computed over the entire EAP message including this field. Before computing the integrity data, this field MUST be initialized to all zeros. The length of this field depends on the integrity algorithm in use. When the integrity check fails, the message MUST be silently discarded. The default integrity algorithm is HMAC-SHA-256 [sha256]. 6.3. Peer-ID TLV The Peer-ID TLV (Type 3) contains the identity of the peer used for HOKEY re-authentication. 6.4. Server-ID TLV The Server-ID TLV (Type 4) contains the identity of the server used for HOKEY re-authentication. 6.5. Reauth-Key-Lifetime TLV The Reauth-Key-Lifetime TLV (Type 5) contains the lifetime of HOKEY- REAUTH-KEY in seconds. 6.6. PRF TLV The PRF TLV (Type 6) contains one or more one-octet PRF numbers defined in [I-D.salowey-eap-emsk-deriv]. When this TLV is carried in a Request, it indicates the PRF number(s) supported by the server. When this TLV is carried in a Request/EXT message, the corresponding Response/EXT message MAY contain this TLV. A PRF TLV in a Response/ EXT message MUST contain exactly one PRF number that is supported and selected by the peer among the PRF numbers in the Request/EXT message. If the PRF number is successfully negotiated using the PRF TLV exchange described above, the negotiated PRF number is used for KDF to derive EAP keying material to be exported by EAP-EXT and USRKs. Otherwise, the default PRF specified in Ohba, et al. Expires September 4, 2007 [Page 13] Internet-Draft EAP-EXT Method March 2007 [I-D.salowey-eap-emsk-deriv] is used for KDF. 6.7. Channel-Binding-Mechanism TLV The Channel-Binding-Mechanism TLV (Type 7) contains one or more one- octet channel binding mechanism numbers. When this TLV is carried in a Request/EXT message, it indicates the channel binding mechanism number(s) supported by the server. When this TLV is carried in a Request/EXT message, the corresponding Response/EXT message MAY contain this TLV. A Channel-Binding-Mechanism TLV in a Response/EXT message MUST contain exactly one channel binding mechanism number that is supported and selected by the peer among the channel binding mechanism numbers in the Request/EXT message. If the channel binding mechanism is successfully negotiated using the Channel-Binding- Mechanism TLV exchange described above, the negotiated channel binding mechanism is enabled. The following channel binding mechanism numbers are defined in this document. 1 [I-D.ohba-eap-channel-binding] 2 [arkko-eap-service-identity-auth] For channel binding mechanism 1, the default hash algorithm for prf+ is PRF_HMAC_SHA2_256. For channel binding mechanism 2, an additional Channel-Binding-Data TLV is carried in Requests and Responses. 6.8. Channel-Binding-Data TLV The Channel-Binding-Data TLV (Type 8) contains octet string data used for [arkko-eap-service-identity-auth]. 6.9. Encryption-Algorithm TLV The Encryption-Algorithm TLV allows negotiation of encryption algorithms used for ciphering Encrypted TLVs. When this TLV is carried in a Request/EXT, it indicates the cryptographic algorithms supported by the EAP server. When this TLV is carried in a Request/ EXT message, the corresponding Response/EXT message MAY contain this TLV. An Encryption-Algorithm TLV in a Response/EXT message MUST contain exactly one encryption algorithm number supported and selected by the peer among the options in the Encryption-Algorithm TLV contained in the Request/EXT message. Note that the EAP Server MAY force the EAP Peer to use the default encryption algorithm (AES- CBC-128). In such a case, the EAP peer does not include the Ohba, et al. Expires September 4, 2007 [Page 14] Internet-Draft EAP-EXT Method March 2007 Encryption-Algorithm TLV in the Request/EXT message and, in the same way, the EAP peer does not include it in the Response/EXT either. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Encr-Algorithm TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Algorithms ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It contains one or more one-octet numbers defined in the following list: 0 Reserved 1 AES-CBC-128 (default) 2 AES-CBC-256 3 3DES 4 IDEA Note that if the algorithms are not successfully negotiated using the Encryption-Algorithm TLV, the default encryption algorithm is used instead. 6.10. Integrity-Algorithm TLV The EAP-EXT method does not allow integrity algorithm negotiation for simplicity and in order to avoid bidding-down attacks. However, the EAP server can select from different integrity algorithms and inform the EAP peer about this selection through the Integrity-Algorithm TLV. If the EAP server does not include this TLV the default value is HMAC-SHA-256. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Intgr-Algorithm TLV | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intgr.Algorithm| +-+-+-+-+-+-+-+-+ It contains one or more one-octet numbers defined in the following list: Ohba, et al. Expires September 4, 2007 [Page 15] Internet-Draft EAP-EXT Method March 2007 0 Reserved 1 HMAC-SHA-1 2 HMAC-SHA-224 3 HMAC-SHA-256 (default) 4 HMAC-SHA-384 5 HMAC-SHA-512 6.11. Encrypted TLV The Encrypted TLV (Type 10) contains one or more plaintext TLVs encrypted with EAP-EXT-ENC-KEY. The length of this field depends on the encryption algorithm in use. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=Encrypted TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IV | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Data... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It contains one or more one-octet numbers defined in the following list: Type (10) Encrypted TLV Length 4 + IV Length + Encrypted Data Length. IV The IV is an Octet string of random bits, most significant bit first. The length of IV depends on the encryption algorithm in use. For example, for AES-CBC-128 the IV is 16 bytes (128 bits). Ohba, et al. Expires September 4, 2007 [Page 16] Internet-Draft EAP-EXT Method March 2007 Encrypted Data Encrypted TLV of variable length. The encrypted data consists of one or more plaintext TLVs ciphered with EAP-EXT-ENC-KEY. Note that depending on the encryption algorithm and the length of plaintext data, padding data may be added to the plaintext data before the ciphering operation. Ohba, et al. Expires September 4, 2007 [Page 17] Internet-Draft EAP-EXT Method March 2007 7. Security Considerations Capability exchange before an inner EAP method exports EAP keying material is unprotected. Hence, additional protected message exchange after creation of EAP keying material is mandated to avoid the capabilities information to be altered by an attacker without being detected by the peer and the server. EAP-EXT allows sequencing of multiple EAP methods inside it. It is known that a compound authentication method that consists of multiple nested or sequential authentication methods without cryptographically binding them has a vulnerability to man-in-the-middle attack. EAP- EXT is able to create the required cryptographically binding by protecting each inner EAP method together with the outer EAP method (i.e., EAP-EXT) with a key generated by its precedent successful inner method in the sequence and finally exporting EAP keying material derived from that is generated by the last successful inner EAP method. In order to achieve cryptographic binding, EAP-EXT requires inner EAP methods to be capable of generating EAP keying material. This method exports MSK and EMSK that are computed from MSK of an inner method. Therefore, the strength of exported MSK and EMSK altogether is the same as that of the MSK of the inner method. Ohba, et al. Expires September 4, 2007 [Page 18] Internet-Draft EAP-EXT Method March 2007 8. IANA Considerations TBD. Ohba, et al. Expires September 4, 2007 [Page 19] Internet-Draft EAP-EXT Method March 2007 9. Acknowledgments The authors would like to thank Bernard Aboba and Jari Arkko for their valuable inputs. Ohba, et al. Expires September 4, 2007 [Page 20] Internet-Draft EAP-EXT Method March 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-18 (work in progress), February 2007. [I-D.vidya-eap-er] Narayanan, V. and L. Dondeti, "EAP Extensions for Efficient Re-authentication", draft-vidya-eap-er-02 (work in progress), January 2007. [I-D.ohba-eap-channel-binding] Ohba, Y., "Channel Binding Mechanism based on Parameter Binding in Key Derivation", draft-ohba-eap-channel-binding-02 (work in progress), December 2006. [I-D.salowey-eap-emsk-deriv] Salowey, J., "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006. [sha256] National Institute of Standards and Technology, "Secure Hash Standard", August 2002. 10.2. Informative References [arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", http://tools.ietf.org/html/ draft-arkko-eap-service-identity-auth-04, October 2005. Ohba, et al. Expires September 4, 2007 [Page 21] Internet-Draft EAP-EXT Method March 2007 Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Subir Das Telcordia 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 2483 Email: subir@research.telcordia.com Rafael Marin Lopez Faculty of Computer Science University of Murcia Murcia 30100 Spain Phone: +34968398501 Email: rafa@dif.um.es Ohba, et al. Expires September 4, 2007 [Page 22] Internet-Draft EAP-EXT Method March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ohba, et al. Expires September 4, 2007 [Page 23]