Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: December 1, 2008 JAIST May 30, 2008 EAP Fast Re-Authentication Protocol (EAP-FRAP) draft-zrelli-eap-frap-03 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 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Zrelli & Shinoda Expires December 1, 2008 [Page 1] Internet-Draft EAP-FRAP May 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. EAP-FRAP Bootstrapping procedure . . . . . . . . . . . . . . . 5 4. EAP-FRAP exchanges . . . . . . . . . . . . . . . . . . . . . . 7 4.1. EAP-FRAP Packet format . . . . . . . . . . . . . . . . . . 7 4.2. The EAP-FRAP AP AP Exchange . . . . . . . . . . . . . . . 8 4.2.1. The EAP-FRAP AP-Request message . . . . . . . . . . . 8 4.2.2. The EAP-FRAP AP-Reply message . . . . . . . . . . . . 9 4.3. The EAP-FRAP TGS Exchange . . . . . . . . . . . . . . . . 9 4.3.1. The EAP-FRAP TGS-REQ message . . . . . . . . . . . . . 9 4.3.2. The EAP-FRAP TGS-REP message . . . . . . . . . . . . . 10 4.4. The EAP-FRAP AS Exchange . . . . . . . . . . . . . . . . . 11 4.4.1. The EAP-FRAP AS-REQ message . . . . . . . . . . . . . 11 4.4.2. The EAP-FRAP AS-REP message . . . . . . . . . . . . . 11 4.5. The EAP-FRAP INIT message . . . . . . . . . . . . . . . . 12 4.6. The EAP-FRAP FINISH message . . . . . . . . . . . . . . . 12 5. Derivation of EFPP and EFRK . . . . . . . . . . . . . . . . . 13 6. Derivation of MSK and EMSK after termination of EAP-FRAP . . . 14 7. EAP-FRAP illustrated . . . . . . . . . . . . . . . . . . . . . 15 7.1. EAP-FRAP Bootstrapping . . . . . . . . . . . . . . . . . . 15 7.2. EAP-FRAP Initial handoff . . . . . . . . . . . . . . . . . 16 7.3. EAP-FRAP Intra-zone handoff . . . . . . . . . . . . . . . 17 7.4. EAP-FRAP Inter-zone handoff . . . . . . . . . . . . . . . 18 7.5. EAP-FRAP Inter-domain handoff . . . . . . . . . . . . . . 19 8. Security considerations . . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Zrelli & Shinoda Expires December 1, 2008 [Page 2] Internet-Draft EAP-FRAP May 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 1, 2008 [Page 3] Internet-Draft EAP-FRAP May 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 consists of a Kerberos realm information as specified in [RFC4120]. The second component is a client principal name of type NT-PRINCIPAL as defined 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. EFPS (EAP-FRAP Peer State) A state information created and maintained by the EAP peer. The EFPS 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 EFPS 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 [TBD] for details on EFPS derivation. Zrelli & Shinoda Expires December 1, 2008 [Page 4] Internet-Draft EAP-FRAP May 2008 3. EAP-FRAP 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 State (EFPS). In the case where a valid EFPS 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 EFPS, 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 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 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 EFPS Zrelli & Shinoda Expires December 1, 2008 [Page 5] Internet-Draft EAP-FRAP May 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 EFPS are derived from the AAA User-Name and the EMSK (Section [TBD]) respectively. 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 1, 2008 [Page 6] Internet-Draft EAP-FRAP May 2008 4. 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 EFPSes. If the Ticket exists, the EAP peer uses it to perform an EAP-FRAP AP Exchange [Section TBD] 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 EFPSes, then the EAP peer MUST first perform an EAP-FRAP TGS Exchange [Section TBD] 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 TBD] 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. 4.1. EAP-FRAP Packet format EAP-FRAP extends the EAP protocol 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. Zrelli & Shinoda Expires December 1, 2008 [Page 7] Internet-Draft EAP-FRAP May 2008 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) See Section [TBD] for more details. 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?] 4.2. The EAP-FRAP AP AP Exchange 4.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. Zrelli & Shinoda Expires December 1, 2008 [Page 8] Internet-Draft EAP-FRAP May 2008 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. --------------------+---------------------------------------------- 4.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 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) --------------------+---------------------------------------------- 4.3. The EAP-FRAP TGS Exchange 4.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 Zrelli & Shinoda Expires December 1, 2008 [Page 9] Internet-Draft EAP-FRAP May 2008 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. 4.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 EFPS. Zrelli & Shinoda Expires December 1, 2008 [Page 10] Internet-Draft EAP-FRAP May 2008 4.4. The EAP-FRAP AS Exchange 4.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 EFPS 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 --------------------+---------------------------------------------- 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. 4.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 --------------------+---------------------------------------------- Zrelli & Shinoda Expires December 1, 2008 [Page 11] Internet-Draft EAP-FRAP May 2008 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 EFPS. 4.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) --------------------+---------------------------------------------- 4.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 1, 2008 [Page 12] Internet-Draft EAP-FRAP May 2008 5. Derivation of EFPP and EFRK The EFRK 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 : [TBD] The EFPP which simply corresponds to the EAP peer's AAA identity. Zrelli & Shinoda Expires December 1, 2008 [Page 13] Internet-Draft EAP-FRAP May 2008 6. 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. [TBD] Zrelli & Shinoda Expires December 1, 2008 [Page 14] Internet-Draft EAP-FRAP May 2008 7. EAP-FRAP illustrated 7.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 7.2. EAP-FRAP Initial handoff Zrelli & Shinoda Expires December 1, 2008 [Page 15] Internet-Draft EAP-FRAP May 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 1, 2008 [Page 16] Internet-Draft EAP-FRAP May 2008 7.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 1, 2008 [Page 17] Internet-Draft EAP-FRAP May 2008 7.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 1, 2008 [Page 18] Internet-Draft EAP-FRAP May 2008 Figure 4: EAP-FRAP inter-zone handoff 7.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 1, 2008 [Page 19] Internet-Draft EAP-FRAP May 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 1, 2008 [Page 20] Internet-Draft EAP-FRAP May 2008 8. Security considerations [RFC4120] highlights several security considerations. Most of these considerations (except dictionary attack against user shosen passwords) apply to the framework using EAP-FRAP. The current version of the document does not analyze possible security threats and considerations introduced by the EAP-FRAP. Zrelli & Shinoda Expires December 1, 2008 [Page 21] Internet-Draft EAP-FRAP May 2008 9. Normative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. Zrelli & Shinoda Expires December 1, 2008 [Page 22] Internet-Draft EAP-FRAP May 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 1, 2008 [Page 23] Internet-Draft EAP-FRAP May 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 1, 2008 [Page 24]