Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: December 5, 2008 JAIST June 3, 2008 EAP Fast Re-Authentication Protocol (EAP-FRAP) draft-zrelli-eap-frap-04 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 December 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Zrelli & Shinoda Expires December 5, 2008 [Page 1] Internet-Draft EAP-FRAP June 2008 Abstract This document specifies an extension to the AAA/EAP authentication and key management framework that allows an EAP peer to perform fast re-authentications with the local EAP server after an initial full EAP authentication using a legacy EAP method with the same or another EAP server. EAP-FRAP eliminates the need for exchanges between the local EAP server and the home EAP server each time the EAP peers is authenticated. In wireless networks, this allows the mobile device to reduce hand-off delays. The EAP-FRAP extension does not require changes in underlying layer protocols. Which makes is back-ward compatible with existing infrastructures and easily deployable with minimal costs. Zrelli & Shinoda Expires December 5, 2008 [Page 2] Internet-Draft EAP-FRAP June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. EAP-FRAP Overview and Bootstrapping procedure . . . . . . . . 6 4. The EAP-FRAP-INIT AVP . . . . . . . . . . . . . . . . . . . . 8 5. EAP-FRAP exchanges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. EAP-FRAP Packet format . . . . . . . . . . . . . . . . . . 9 5.2. The EAP-FRAP AP Exchange . . . . . . . . . . . . . . . . . 10 5.2.1. The EAP-FRAP AP-Request message . . . . . . . . . . . 10 5.2.2. The EAP-FRAP AP-Reply message . . . . . . . . . . . . 10 5.3. The EAP-FRAP TGS Exchange . . . . . . . . . . . . . . . . 11 5.3.1. The EAP-FRAP TGS-REQ message . . . . . . . . . . . . . 11 5.3.2. The EAP-FRAP TGS-REP message . . . . . . . . . . . . . 12 5.4. The EAP-FRAP AS Exchange . . . . . . . . . . . . . . . . . 12 5.4.1. The EAP-FRAP AS-REQ message . . . . . . . . . . . . . 12 5.4.2. The EAP-FRAP AS-REP message . . . . . . . . . . . . . 13 5.5. The EAP-FRAP INIT message . . . . . . . . . . . . . . . . 13 5.6. The EAP-FRAP FINISH message . . . . . . . . . . . . . . . 14 6. Derivation of EFPP and EFRK . . . . . . . . . . . . . . . . . 15 7. Derivation of MSK and EMSK after termination of EAP-FRAP . . . 17 8. EAP-FRAP illustrated . . . . . . . . . . . . . . . . . . . . . 19 8.1. EAP-FRAP Bootstrapping . . . . . . . . . . . . . . . . . . 19 8.2. EAP-FRAP Initial handoff . . . . . . . . . . . . . . . . . 20 8.3. EAP-FRAP Intra-zone handoff . . . . . . . . . . . . . . . 21 8.4. EAP-FRAP Inter-zone handoff . . . . . . . . . . . . . . . 22 8.5. EAP-FRAP Inter-domain handoff . . . . . . . . . . . . . . 23 9. Security considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Generation of Symmetric Keying material . . . . . . . . . 25 9.2. Key strength . . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Mutual authentication . . . . . . . . . . . . . . . . . . 25 9.4. Resistance to dictionary attacks . . . . . . . . . . . . . 25 9.5. Protection against man-in-the-middle attacks . . . . . . . 26 9.6. Protected cipher-suite negotiation . . . . . . . . . . . . 27 10. Normative References . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Zrelli & Shinoda Expires December 5, 2008 [Page 3] Internet-Draft EAP-FRAP June 2008 1. Introduction Network access control with EAP [RFC3748] generally involves an EAP peer, which is the entity requesting the network access service, an EAP authenticator located at the edge of the access network and a back-end EAP server. The EAP authenticator acts as a pass-through. It relays EAP exchange between the EAP peer and the EAP server. Upon successful authentication the EAP server issues a key called Master Session Key (MSK) and deliver it to the EAP authenticator. On the other side, the EAP peer generates the MSK. The MSK is then used to establish a security association between the EAP peer and the EAP authenticator. When the EAP peer performs a hand-over, a full EAP authentication with the back-end EAP server must be performed. In cases where the EAP method requires several round-trips, or when the EAP peer belongs to a remote AAA domain. The EAP authentication may introduce delays that can directly impact the performance of real time applications during hand-overs. More details on hand-over performance problem are developed in [draft-ietf-hokey-reauth-ps-01] This document, specifies an extension to the EAP protocol that enables EAP peers to initially authenticate to the local access network, using any legacy EAP authentication method, then re-use the established security association with the local EAP server to re- authenticate to the local access network in a reduced number of messages. In case of roaming scenario, the initial EAP authentication requires communication between the local AAA server and the home AAA server over the Internet. However, the subsequent EAP authentications that take place in the local access network will not require inter-domain exchanges when EAP-FRAP is used. Zrelli & Shinoda Expires December 5, 2008 [Page 4] Internet-Draft EAP-FRAP June 2008 2. Definitions EFSP (EAP-FRAP Server Principal) An information that uniquely identifies an EAP-FRAP capable EAP server in the Kerberos name space. The EFSP is composed of two components. The first component consists of a Kerberos realm information as specified in [RFC4120]. The second component is a server principal name of type NT-SRV-INST as defined in [RFC4120] Section 6.2. The service identifier used for EFSP is "knas". EFPP (EAP-FRAP Peer Principal) An information that uniquely identifies an EAP peer in the Kerberos name space. The EFPP is composed of two components. The first component is a client principal name of type NT-PRINCIPAL as defined in [RFC4120] The second component consists of a Kerberos realm information as specified in [RFC4120]. EFRK (EAP-FRAP Re-Authentication Key) A Key derived from the EMSK resulting from a successful authentication between the EAP peer and the current EAP-FRAP capable EAP server. This key is derived by the EAP peer and the home AAA server from the EMSK. The home AAA server sends the EFRK key to the visited AAA server if both agree to use the EAP-FRAP extension. Ticket-Cache Can be any storage medium where Kerberos credentials (Tickets and associated session keys) can be stored. EFPC (EAP-FRAP Peer Context) A state information created and maintained by the EAP peer. The EFPC consists of an EFPP (EAP- FRAP Peer Principal), an EFRK, a Kerberos realm name, an EFRK (EAP-FRAP Re-Authentication Key) and a Ticket-Cache. The EAP peer maintains one EFPC per Kerberos realm. EPFS are created by the EAP peer when it performs authentication using a legacy EAP method with an EAP-FRAP capable server. See Section 6 for details on EFPC derivation. Zrelli & Shinoda Expires December 5, 2008 [Page 5] Internet-Draft EAP-FRAP June 2008 3. EAP-FRAP Overview and Bootstrapping procedure The use of the EAP-FRAP extension is negotiated between the EAP peer and the local EAP server. When the EAP server receives the initial EAP-Identity Response message forwarded by the NAS, it MAY issue an EAP-FRAP INIT message to the peer. The decision on whether to use the EAP-FRAP extension or not with a specific EAP peer may depend on AAA policies that are out of the scope of this document. The EAP server may initiate EAP-FRAP even if the peer belongs to a remote AAA domain. The proxy state machine at the AAA layer is thus changed when the EAP-FRAP extension is used; Instead of forwarding the Initial EAP-Identity Response message to the roaming peer's home AAA domain, the message is processed locally and an EAP-FRAP INIT message is issued by the EAP layer then sent back to the EAP peer. The initial EAP-FRAP Request message contains the EAP server's identifier called EAP-FRAP Server Identifier (EFSP). EAP peers that do not support the EAP-FRAP extension negotiate a legacy EAP authentication method using EAP NAK messages as per [RFC3748]. In the remaining of this document, it is assumed that EAP peers as well as EAP servers support the EAP-FRAP extension. Upon reception of the initial EAP-FRAP Request, the EAP peer determines if it has previously performed a full EAP authentication with an EAP-FRAP capable EAP server. This can be verified by checking whether the peer has a valid EAP-FRAP Peer Context (EFPC). In the case where a valid EFPC exists, the EAP peer MAY choose to use the EAP-FRAP extension to perform fast re-authentication with the EAP server. If the EAP peer determines that it doesn't have a valid EFPC, then it MUST negotiate the use of a legacy EAP method by issuing an EAP-NAK message as specified in [RFC3748]. In case of a roaming scenario, when the visited AAA server receives this message it MUST forward it the the EAP peer's home AAA server. In addition the visited AAA server MUST add an EAP-FRAP-INIT AVP or TLV (Section 4) to the message before forwarding it to the remote AAA server. After successful EAP authentication proxied by the visited AAA server, if the visited AAA server included the EAP-FRAP-INIT AVP in the initial message of the current AAA session, then the home AAA server derives the EFRK and sends it along with the MSK and EAP- Success message (e.g. using MS-MPPE AVP [RFC2548] in RADIUS). The home AAA server MAY decide to refuse the use of the EAP-FRAP extension by not sending the EFRK to the visited AAA server. At the end of the EAP authentication, the EAP peer creates a new EFPC Zrelli & Shinoda Expires December 5, 2008 [Page 6] Internet-Draft EAP-FRAP June 2008 with the EAP peer's AAA identity as EFPP and the EFRK derived from the EMSK. The EFPP and the EFRK of the new EFPC are derived from the AAA user-name and the EMSK respectively (Section 6). The local EAP server, on the other hand, securely adds the new EFPP as a new principal in the database of a Kerberos Key Distribution Center serving the local Kerberos realm. The procedure of adding the new principal is out of the scope of this document. (Impl. Note: The EAP server may use tools such as kadmin an interactive command- line interface to the Kerberos V5 administration service for this purpose). The principals have a limited lifetime after which they are removed from the Kerberos database (The procedure of removing or timing out the entries is out of the scope of this document). The lifetime is determined by the EAP server and must be shorter than the EMSK's lifetime. Zrelli & Shinoda Expires December 5, 2008 [Page 7] Internet-Draft EAP-FRAP June 2008 4. The EAP-FRAP-INIT AVP The EAP-FRAP-INIT AVP or TLV is transported from the local AAA server to the home AAA server by the AAA protocol in use (Diameter or RADIUS). This AVP is issued by the visited AAA server to advertise EAP-FRAP capability to the home AAA server and request authorization for it. The data payload carried by this AVP is not specified in this document. Such data may include authorization data and/or pricing information for the EAP-FRAP service. If the home AAA server agrees to allow the roaming client to use EAP-FRAP in the visited domain, then it will derive and send the EFRK key to the visited AAA server. The code or type or this AVP is set to TBD. Zrelli & Shinoda Expires December 5, 2008 [Page 8] Internet-Draft EAP-FRAP June 2008 5. EAP-FRAP exchanges If the EAP peer decides to use EAP-FRAP, it first starts by checking if it has a Kerberos service Ticket for the Kerberos service principal that corresponds to the EFSP in the Ticket cache of its pre-established EFPCes. If the Ticket exists, the EAP peer uses it to perform an EAP-FRAP AP Exchange [Section 5.2] with the EAP server. If the EAP peer does not find a Ticket for the EFSP but finds a valid TGT for the local Kerberos realm in the Ticket cache of one of its EFPCes, then the EAP peer MUST first perform an EAP-FRAP TGS Exchange [Section 5.3] with the EAP server which allows the peer to obtain a Ticket for the current EFSP, followed by an EAP-FRAP AP exchange. If the EAP peer can not find a Ticket for the EFSP nor a TGT for the realm name indicated in the EFSP, then the EAP peer performs an EAP- FRAP AS exchange [Section 5.4] in order to obtain a TGT for the local realm. After obtaining a TGT, the EAP peer performs a TGS Exchange followed by an AP Exchange with the EAP server. After a successful EAP-FRAP AP Exchange, the EAP peer issues an EAP- FRAP FINISH message to which the EAP server replies with an EAP- Success message. 5.1. EAP-FRAP Packet format EAP-FRAP extends the EAP/AAA framework as a 'special' method. The following is the format of the EAP-FRAP packet encapsulated in an EAP packet, the fields are transmitted from left to right. 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 | FRAP-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Possible TLVs are : - KRB5-Payload Carries a DER encoded Kerberos message. - KRB5-Realm Carries an octet string that corresponds to a Kerberos realm name. - KRB5-Principal name (EFSP) Zrelli & Shinoda Expires December 5, 2008 [Page 9] Internet-Draft EAP-FRAP June 2008 Code As defined in [RFC3748]. 1 for EAP-FRAP Request messages issued by the EAP server. 2 for EAP-FRAP Response messages issued by the EAP peer. Identifier, Length, Type As defined in [RFC3748]. The Type field is set to TBD. FRAP-Type Each EAP-FRAP exchange defines two EAP-FRAP Types. Reserved This field is reserved for future uses [Flags? Protocol Version?] 5.2. The EAP-FRAP AP Exchange 5.2.1. The EAP-FRAP AP-Request message The EFAP-REQ message is created by an EAP peer when authenticating to a EAP-FRAP capable EAP server for which the peer has a Ticket. The EAP-FRAP AP-Request message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-AP-REQ (14) --------------------+---------------------------------------------- KRB5-Payload | A DER encoded AP-REQ message for the service | EFSP using the corresponding service Ticket, | with the 'mutual-required' flag must be set. --------------------+---------------------------------------------- 5.2.2. The EAP-FRAP AP-Reply message When the EAP server receives the EAP-FRAP AP-REQ message, it extracts the AP-REQ payload then validates it using the secret key of the EFSP principal (Impl. Note: the key is generally stored in what is called keytab). If the EAP server determines that the AP-REQ message built by the EAP peer is correct, the EAP peer is authenticated. The server then Zrelli & Shinoda Expires December 5, 2008 [Page 10] Internet-Draft EAP-FRAP June 2008 creates a Kerberos AP-REP message as specified in [RFC4120]. The encoded form of the AP-REP message is encapsulated into an EAP-FRAP AP-REP message and sent the EAP peer. The EAP-FRAP AP-REP message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-AP-REP (15) --------------------+---------------------------------------------- KRB5-Payload | A DER encoded AP-REP message | (with the mutual-required flag set) --------------------+---------------------------------------------- 5.3. The EAP-FRAP TGS Exchange 5.3.1. The EAP-FRAP TGS-REQ message The EAP-FRAP TGS-REQ message is issued by the EAP peer when it has a TGT for the EAP server's Kerberos realm. The peer builds a TGS-REQ message for requesting a service ticket for the service principal EFSP. The format of the TGS-REQ message is specified in [RFC4120]. The DER encoding of the TGS-REQ message is carried in a KRB5-Payload TLV. In addition, a KRB5-Realm TLV that contains the Kerberos realm name of the EFSP is added. The EAP-FRAP TGS-REQ message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-TGS-REQ (12) --------------------+---------------------------------------------- KRB5-Realm | Contains the local Kerberos 5 realm name --------------------+---------------------------------------------- KRB5-Payload | A DER encoded TGS-REQ message --------------------+---------------------------------------------- When the EAP server receives an EAP-FRAP message of type EAP-FRAP- TGS-REQ, it extracts the TGS-REQ message then sends it to the KDC of the Kerberos realm indicated in the KRB5-Realm TLV. When the Kerberos exchange with the KDC is uses UDP as transport layer, the EAP Server should retransmit the message after a timeout. Zrelli & Shinoda Expires December 5, 2008 [Page 11] Internet-Draft EAP-FRAP June 2008 5.3.2. The EAP-FRAP TGS-REP message The EAP-FRAP TGS-REP message is issued by the EAP server when it receives a Kerberos TGS-REP message from a Kerberos KDC that matches a pending TGS-REQ message. The EAP server encapsulates the TGS-REP message in a KRB5-Payload TLV and sends it back to the EAP peer in an EAP-FRAP TGS-REP message. The EAP-FRAP TGS-REP message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-TGS-REQ (13) --------------------+---------------------------------------------- KRB5-Payload | A DER encoded TGS-REP message --------------------+---------------------------------------------- When the EAP peer receives an EAP-FRAP message of type EAP-FRAP-TGS- REP, it extracts the Ticket from the TGS-REP message and add it to the Ticket cache of the current EFPC. 5.4. The EAP-FRAP AS Exchange 5.4.1. The EAP-FRAP AS-REQ message The EAP-FRAP AS-REQ message is issued by the EAP peer when it needs to obtain a TGT for the local EAP server's Kerberos realm. The peer builds an AS-REQ using the EFPP and the associated EFRK from the EFPC that corresponds to the local Kerberos realm name. The format of the AS-REQ message is specified in [RFC4120]. The DER encoding of the AS-REQ message is carried in a KRB5-Payload TLV. In addition, a KRB5-Realm TLV that contains the local Kerberos realm name is added. The EAP-FRAP TGS-REQ message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-AS-REQ (10) --------------------+---------------------------------------------- KRB5-Realm | Contains the local Kerberos 5 realm name --------------------+---------------------------------------------- KRB5-Payload | A DER encoded AS-REQ message --------------------+---------------------------------------------- Zrelli & Shinoda Expires December 5, 2008 [Page 12] Internet-Draft EAP-FRAP June 2008 When the EAP server receives an EAP-FRAP message of type EAP-FRAP-AS- REQ, it extracts the AS-REQ message then sends it to the KDC of the Kerberos realm indicated in the KRB5-Realm TLV. When the Kerberos exchange with the KDC is uses UDP as transport layer, the EAP Server should retransmit the message after a timeout. 5.4.2. The EAP-FRAP AS-REP message The EAP-FRAP AS-REP message is issued by the EAP server when it receives a Kerberos AS-REP message from a Kerberos KDC that matches a pending AS-REQ message. The EAP server encapsulates the AS-REP message in a KRB5-Payload TLV and sends it back to the EAP peer in an EAP-FRAP AS-REP message. The EAP-FRAP TGS-REP message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-AS-REP (11) --------------------+---------------------------------------------- KRB5-Payload | A DER encoded AS-REP message --------------------+---------------------------------------------- When the EAP peer receives an EAP-FRAP message of type EAP-FRAP-AS- REP, it extracts the Ticket Granting Ticket from the AS-REP message and add it to the Ticket cache of the current EFPC. 5.5. The EAP-FRAP INIT message This message is issued by an EAP-FRAP capable EAP server in response to an EAP-Identity Response message. The EAP-FRAP INIT message contains a Kerberos5-Realm TLV and a Kerberos5-Principal TLV. The Kerberos5-Realm TLV indicates the Kerberos realm name in the local access network. The EAP-FRAP FINISH message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-INIT (0) --------------------+---------------------------------------------- Zrelli & Shinoda Expires December 5, 2008 [Page 13] Internet-Draft EAP-FRAP June 2008 5.6. The EAP-FRAP FINISH message The EAP-FRAP FINISH message is issued by the EAP peer when it receives a valid EAP-FRAP AP-REP message. The EAP peer must first, extract the AP-REP message issues by the EAP serve and verify it according to [RFC4120]. If the AP-REP is valid, the EAP server is authenticated and the EAP-FRAP exchange comes to its end by the peer sending the EAP-FRAP Finish message. The EAP-FRAP FINISH message is defined as follows. Component | Value =================================================================== FRAP-Type | EAP-FRAP-FINSH (1) --------------------+---------------------------------------------- When the EAP peer receives an EAP-FRAP message of type EAP-FRAP- FINISH, it issues an EAP-Success message Zrelli & Shinoda Expires December 5, 2008 [Page 14] Internet-Draft EAP-FRAP June 2008 6. Derivation of EFPP and EFRK The EFPP's principal name component is built by concatenating the string 'frap/' the EAP peer's AAA identity. e.g. 'frap/someuser' The EFRK has a length of 256 bits and is derived by the EAP peer and the home EAP server after successful EAP authentication using a legacy EAP method. The EFRK is generated from the EMSK as follows : PRF+ : Pseudo random cipher stream generator. See definition in [RFC4306] Section 2.13. DSRK : Domain Specific Root Key [draft-ietf-hokey-emsk-hierarchy] Cname : Concatenation of the principal name portion and the realm portion of the EFPP. e.g. frap/someuser@HOME.COM Sname : Concatenation of the principal name portion and the realm portion of the EFSP. e.g. knas/zone1.visited.com@VISITED.COM MSK = PRF+ (K, S), where K = EMSK or DSRK, and S = 'EAP FRAP Seed'| Cname | Sname The default PRF (Pseudo Random Function) upon which is based the PRF+ key derivation function (see definition in [RFC4306]) used to derive the EFRK is SHA1. After successful EAP authentication using a legacy EAP method, the home AAA server includes session lifetime information (Such as Session-Timeout AVP in RADIUS [RFC2865]), that indicates the EFRK's lifetime. The home AAA server decides the EFRK's lifetime period according to the lifetime of the EMSK exported by the legacy EAP method (e.g. in EAP-TLS, if client certificate is going to expire in 5 hours, the EFRK's lifetime must reflect this time limit) and other policies that are out of the scope of this document. When the visited AAA server adds the new peer entry in the Kerberos KDC. The principal's lifetime and expiry date is computed based on Zrelli & Shinoda Expires December 5, 2008 [Page 15] Internet-Draft EAP-FRAP June 2008 the lifetime information received from the home AAA server. When the entry expires in the Kerberos KDC, the peer will not be able to obtain Tickets for network access, and the entry will be purged when periodic maintenance of the KDC database takes place. Zrelli & Shinoda Expires December 5, 2008 [Page 16] Internet-Draft EAP-FRAP June 2008 7. Derivation of MSK and EMSK after termination of EAP-FRAP After successful EAP-FRAP exchange between the EAP peer and the local EAP server, both entities derive an MSK and an EMSK. The following section describes how these keys are generated. The EAP-FRAP AP exchange (Section 5.2) allows the EAP peer and the local EAP server to perform mutual authentication and share a sub- session key, hereafter referred to as SK, selected by the EAP server and with a lifetime limited to the duration of a single association. The EAP Peer obtains the session key from the AP-REP message's 'subkey' field. The sub-session is randomly generated by the EAP server, its length depends on the cryptographic cipher-suite negotiated between the EAP peer and the Kerberos KDC that issued the Ticket. If AES is used, the subkey's entropy, hereafter called 'SKE' may be 128 or 256 bits [RFC3962]. The MSK and EMSK are derived from the subkey. In order to ensure cryptographic separation, the subkey is divided into two subkeys each with half the entropy of the original subkey. The MSK is derived from the first half of the SK, called MSK-SK. The EMSK is derived from the second half of the MSK. In order to ensure compliance with the 128-bit minimal Key strength requirement of [RFC4017], the EAP peer, KDC and EAP server must support, negotiate and use cipher- suites with 256 bit key lengths (e.g. AES-256) The algorithm for deriving the MSK and EMSK uses keyed hash functions and follow the guidelines of [RFC4306], Section 2.13, to expand parts of the SK into 256-bit keys. Zrelli & Shinoda Expires December 5, 2008 [Page 17] Internet-Draft EAP-FRAP June 2008 PRF+ : Pseudo random cipher stream generator. See definition in [RFC4306] Section 2.13. SK : Kerberos subkey derived by the EAP server MSK-SK : First half of SK EMSK-SK : Second half of SK Cname : Concatenation of the principal name portion and the realm portion of the EFPP. e.g. frap/someuser@HOME.COM Sname : Concatenation of the principal name portion and the realm portion of the EFSP. e.g. knas/zone1.visited.com@VISITED.COM MSK = PRF+ (MSK-SK, S1), where S1 = 'EAP Kerberos Seed'| Cname | Sname EMSK = PRF+ (EMSK-SK, S2), where S2 = 'EAP Kerberos Seed'| Cname | Sname The PRF (Pseudo Random Function) upon which is based the PRF+ key derivation function (see definition in [RFC4306]) used to derive the MSK and EMSK is negotiated between the EAP peer and the KDC. See Section 9.6 for details on cipher-suite negotiation in EAP-FRAP. If EMSK and MSK lifetime need to be computed, the lifetime must be equal or less than the lifetime of the Ticket used in the AP exchange (Section 5.2) to authenticate the EAP peer to the EAP server. The Ticket's lifetime is the difference in time between the current instant and the Ticket's expiration date extracted from the Ticket's 'endtime' field. Zrelli & Shinoda Expires December 5, 2008 [Page 18] Internet-Draft EAP-FRAP June 2008 8. EAP-FRAP illustrated 8.1. EAP-FRAP Bootstrapping EAP peer EAP Local EAP kerberos KDC Home EAP Authenticator Server EXAMPLE.COM Server EAP-Identity Request (1) <-------------- EAP-Identity Response (2) --------------------------------> EAP-FRAP INIT [EFSP= knas/zone1.example.com@EXAMPLE.COM] (3) <-------------------------------- EAP-NAK [EAP-PEAPv0] (4) --------------------------------> EAP-NAK [EAP-PEAPv0], EAP-FRAP-INIT AVP (5) ------------------------> Legacy EAP method [EAP-PEAPv0] authentication (6) <--------------------------------------------------------> EAP Success, MSK, EFRK (7) <------------------------ Add EFPP (8) -----------> EAP Success, MSK (9) <------------ Figure 1: EAP-FRAP bootstrapping 8.2. EAP-FRAP Initial handoff Zrelli & Shinoda Expires December 5, 2008 [Page 19] Internet-Draft EAP-FRAP June 2008 EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request (1) <---------------------- EAP-Identity Response (2) -----------------------------------------> EAP-FRAP INIT [EFSP= knas/zone1.example.com@EXAMPLE.COM] (3) <----------------------------------------- EAP-FRAP [AS-REQ, KRB5-Realm= EXAMPLE.COM] (4) -----------------------------------------> AS-REQ (5) -----------------> AS-REP (6) <---------------- EAP-FRAP [AS-REP] (7) <---------------------------------------- EAP-FRAP [TGS-REQ, KRB5-Realm= EXAMPLE.COM] (8) ----------------------------------------> TGS-REQ (9) -----------------> TGS-REP (10) <---------------- EAP-FRAP [TGS-REP] (11) <---------------------------------------- EAP-FRAP [AP-REQ] (12) ----------------------------------------> EAP-FRAP [AP-REP] (13) <---------------------------------------- EAP-FRAP FINISH (14) ----------------------------------------> EAP Success , MSK (15) <-------------------- Figure 2: EAP-FRAP Initial handoff Zrelli & Shinoda Expires December 5, 2008 [Page 20] Internet-Draft EAP-FRAP June 2008 8.3. EAP-FRAP Intra-zone handoff EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request (1) <---------------------- EAP-Identity Response (2) -----------------------------------------> EAP-FRAP INIT [EFSP= knas/zone1.example.com@EXAMPLE.COM] (3) <----------------------------------------- EAP-FRAP [AP-REQ] (4) -----------------------------------------> EAP-FRAP [AP-REP] (5) <----------------------------------------- EAP-FRAP FINISH (6) -----------------------------------------> EAP Success , MSK (7) <---------------------- Figure 3: EAP-FRAP intra-zone handoff Zrelli & Shinoda Expires December 5, 2008 [Page 21] Internet-Draft EAP-FRAP June 2008 8.4. EAP-FRAP Inter-zone handoff EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request (1) <---------------------- EAP-Identity Response (2) -----------------------------------------> EAP-FRAP INIT [EFSP= knas/zone1.example.com@EXAMPLE.COM] (3) <----------------------------------------- EAP-FRAP [TGS-REQ, KRB5-Realm= EXAMPLE.COM] (4) ----------------------------------------> TGS-REQ (5) -----------------> TGS-REP (6) <---------------- EAP-FRAP [TGS-REP] (7) <---------------------------------------- EAP-FRAP [AP-REQ] (8) -----------------------------------------> EAP-FRAP [AP-REP] (9) <----------------------------------------- EAP-FRAP FINISH (10) -----------------------------------------> EAP Success , MSK (11) <---------------------- Zrelli & Shinoda Expires December 5, 2008 [Page 22] Internet-Draft EAP-FRAP June 2008 Figure 4: EAP-FRAP inter-zone handoff 8.5. EAP-FRAP Inter-domain handoff EAP peer EAP EAP krb5 KDC Krb5 KDC Authenticator Server EXAMPLE2.COM EXAMPLE.COM EAP-Identity Request (1) <---------------- EAP-Identity Response (2) -------------------------------> EAP-FRAP INIT [EFSP= knas/zone1.example2.com@EXAMPLE2.COM] (3) <------------------------------ EAP-FRAP [TGS-REQ, KRB5-Realm= EXAMPLE.COM] (4) ------------------------------> TGS-REQ (5) --------------------------> TGS-REP (6) <------------------------- EAP-FRAP [TGS-REP] (7) <----------------------------- EAP-FRAP [TGS-REQ, KRB5-Realm= EXAMPLE2.COM] (8) ------------------------------> TGS-REQ (9) -----------> TGS-REP (10) <---------- EAP-FRAP [TGS-REP] (11) <---------------------------- Zrelli & Shinoda Expires December 5, 2008 [Page 23] Internet-Draft EAP-FRAP June 2008 EAP-FRAP [AP-REQ] (12) -----------------------------> EAP-FRAP [AP-REP] (13) <--------------------------- EAP-FRAP FINISH (14) -----------------------------> EAP Success, MSK (15) <------------------ Figure 5: EAP-FRAP inter domain handoff Zrelli & Shinoda Expires December 5, 2008 [Page 24] Internet-Draft EAP-FRAP June 2008 9. Security considerations [RFC4120] highlights several security considerations. Most of these considerations (except dictionary attack against user chosen passwords) apply to the framework using EAP-FRAP. In addition, the IETF has established security requirements [RFC4017] with which any new EAP method, intended for use in wireless LANs, must comply. In the following, we show how the EAP-Kerberos method fulfills these requirements. 9.1. Generation of Symmetric Keying material EAP-FRAP uses an AP exchange between the peer and the local EAP server to achieve mutual authentication. The service session key is provided by the KDC to the peer during the TGS Exchange. When EAP server receives the AP-REQ message issued by the peer, it decrypts the service Ticket and obtains the same service session key. This key is then used by the peer and server to derive other keying material. 9.2. Key strength The IETF requirements for EAP methods for wireless networks mandates that the method must derive keying materials with 128 bits of effective key strength. The specification of the Kerberos protocol supports several symmetric-key cryptographic algorithms [RFC3961]. Amongst the available algorithms, the Advanced Encryption Standard (AES) [RFC3962] uses 256-bit length keys. Hence, when using AES, keying material derived by EAP-FRAP meet the 128-bit length requirement. 9.3. Mutual authentication The peer and the EAP server perform the AP exchange through which the server can authenticate the station by validating the Authenticator component of the AP-REQ message. The peer on the other hand verifies the authentication server's identity after validating the AP-REP message. The mutual authentication between application client and service is possible but not mandatory in Kerberos. EAP-FRAP however, requires that the client requests mutual authentication in the AP-REQ message by setting the 'mutual-required' option. 9.4. Resistance to dictionary attacks 'Dictionary attack' is the name for a category of cryptanalysis techniques for recovering user passwords by actively interacting with other entities in the network or by processing a pre-captured data. Zrelli & Shinoda Expires December 5, 2008 [Page 25] Internet-Draft EAP-FRAP June 2008 The vulnerability of the Kerberos protocol to dictionary attacks has being initially documented in [Bellovin90] and experimentally proven in [Wu99]. In short, if an attacker can intercept the AS-REP message from the KDC to the station, he can perform a dictionary attack that eventually yields to the disclosure of the password of the user to whom the AS-REP message was issued. However, EAP-FRAP does not use user chosen passwords for authentication between the peer and the KDC. The EFRK which corresponds to the peer's key is derived from the EMSK and has an entropy of 256-bits (see Section 6). Therefore, the AS exchange in EAP-FRAP can be considered resistant to the off-line dictionary attack. 9.5. Protection against man-in-the-middle attacks The Kerberos authentication protocol is designed to provide mutual authentication and establishment of a security association between a client and a server in open networks. The protocol assumes that any entity in the network can capture any message and send any message to the parties involved in the authentication process. In order to detect replayed messages, Kerberos uses a replay cache, where messages are stored for a pre-determined period of time. If a received message is not fresh enough (the included time stamp is too old) or found to be identical to a message from the replay cache, the message is assessed as a replay and rejected. Moreover, sensitive information in Kerberos exchanges are protected using encryption mechanisms that incorporate integrity protection. Message parts that are not encrypted are integrity protected using encrypted checksums. Furthermore, the Kerberos protocol provides cryptographic binding since the identity of the EAP peer is carried in the Ticket, and the identity of the server is carried in the TGS-REP message. The EAP peer and Server's identities is thus, un-ambiguously known to both parties. Finally, session independence as defined in [RFC3748] is ensured since MSKs are derived using a one-way cryptographic hash function with fresh and randomly generated Kerberos session keys as input Section 7. The compromise of an MSK from a previous session does not yield any information on how to derive future MSKs. Even if a Kerberos session key from a previous EAP session is compromised, the attacker might be able to derive the correspondent previous MSKs, but will not be able to compromise the current MSK since it is derived from a freshly generated session key. By providing integrity protection, replay protection, cryptographic binding and session independence as defined in [RFC3748], EAP-FRAP implements all the measures for protection against man-in-the-middle attacks. Zrelli & Shinoda Expires December 5, 2008 [Page 26] Internet-Draft EAP-FRAP June 2008 9.6. Protected cipher-suite negotiation The IETF requirement for EAP methods for wireless access networks mandates that the EAP method must be able to negotiate different cipher-suites and the negotiation must be integrity protected. EAP- FRAP supports protected cipher-suite negotiation between the peer and the KDC. When obtaining Tickets (TGT or service Tickets) from the KDC, the client includes a list of preferred cipher-suites in the 'etype' field of the AS-REQ or TGS-REQ message. If the KDC or the target service for which the client requested a Ticket cannot accommodate any of these encryption types, then the KDC issues an error message. If one of the cipher-suites proposed by the client is acceptable, then the KDC will issue an AS-REP or TGS-REP message using the selected cipher-suite. The reply message from the KDC contains a Ticket, a session key and the selected cipher-suite. The key and the cipher-suite are encrypted and integrity protected using the client's password shared with the KDC in case of an AS exchange, or the TGS session key in case of a TGS exchange. After decrypting the reply message, the client can check whether the KDC has selected an appropriate cipher-suite from the list of suggested cipher-suites sent in the initial request message. During the AP exchange, the peer uses the cipher-suite negotiated during the TGS exchange assuming that the service supports the cipher-suite since the KDC indicated so. Zrelli & Shinoda Expires December 5, 2008 [Page 27] Internet-Draft EAP-FRAP June 2008 10. Normative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [Bellovin90] Bellovin, S. and M. Merrit, "Limitations of the Kerberos authentication system", Sigcomm Compt. Commun. Rev. ISSN: 0146-4833, March 1990. [Wu99] Wu, T., "A Real-World Analysis of Kerberos Password Security", NDSS, The Internet Society ISBN: 1-891562-04-5; 1-891562-05-3, March 1999. Zrelli & Shinoda Expires December 5, 2008 [Page 28] Internet-Draft EAP-FRAP June 2008 Authors' Addresses Saber Zrelli Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: zrelli@jaist.ac.jp Yoichi Shinoda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 JAPAN Email: shinoda@jaist.ac.jp Zrelli & Shinoda Expires December 5, 2008 [Page 29] Internet-Draft EAP-FRAP June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Zrelli & Shinoda Expires December 5, 2008 [Page 30]