Network Working Group S. Zrelli Internet-Draft Y. Shinoda Expires: January 31, 2008 JAIST July 30, 2007 EAP Fast Re-Authentication Protocol (EAP-FRAP) draft-zrelli-eap-frap-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 January 31, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Zrelli & Shinoda Expires January 31, 2008 [Page 1] Internet-Draft EAP-FRAP July 2007 Abstract This document specifies an extension to the EAP protocol that allows an EAP peer to perform fast re-authentication with an EAP server with which it has previously performed a full EAP authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Kerberos authentication protocol . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. EAP-FRAP message format . . . . . . . . . . . . . . . . . . . 15 6. Bootstrapping of EAP-FRAP . . . . . . . . . . . . . . . . . . 17 7. Creation of an EAP-FRAP / AS-REQ message . . . . . . . . . . . 19 8. Receipt of an EAP-FRAP / AS-REQ message . . . . . . . . . . . 20 9. Creation of an EAP-FRAP / TGS-REQ message . . . . . . . . . . 21 10. Receipt of an EAP-FRAP / TGS-REQ message . . . . . . . . . . . 22 11. Creation of an EAP-FRAP / AP-REQ message . . . . . . . . . . . 23 12. Receipt of an EAP-FRAP / AP-REQ message . . . . . . . . . . . 24 13. Derivation of MSK after termination of EAP-FRAP . . . . . . . 25 14. Derivation of Kerberos principal . . . . . . . . . . . . . . . 26 15. Payload formatting of the alternative EAP Identity Request . . 27 16. Inter access network roaming . . . . . . . . . . . . . . . . . 28 16.1. Inter Kerberos realm roaming . . . . . . . . . . . . . . 28 16.2. Inter AAA realm roaming . . . . . . . . . . . . . . . . . 28 17. Security considerations . . . . . . . . . . . . . . . . . . . 29 18. Normative References . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Zrelli & Shinoda Expires January 31, 2008 [Page 2] Internet-Draft EAP-FRAP July 2007 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 EAP-FRAP, a Kerberos realm is associated to each access network. The network access service corresponds to a Kerberos service in the Kerberos realm. Clients that support the EAP-FRAP extension, perform an initial full EAP authentication when they use the first access point of the access network. When the client performs a hand-over within the same access network, the EAP-FRAP extension can be used to create a temporary Kerberos principal in the local realm and obtain sufficient Kerberos credentials from the Key Distribution Center (KDC) serving the local access network to authenticate to the local EAP server and gain network access. When the EAP peer roams to a new access network, using the EAP-FRAP extension in the new access network, the EAP peer can obtain a Ticket Granting Ticket (TGT) for the new access network through Kerberos cross-realm authentication proxied by the new EAP server. Zrelli & Shinoda Expires January 31, 2008 [Page 3] Internet-Draft EAP-FRAP July 2007 2. Assumptions o The EAP-FRAP extension does not require client to belong to any Kerberos realm. However the client must have some other kind of credentials that allows it to authenticate to the visited realm using a certain EAP method. o The EAP method used the first time the EAP peer connects to the local access network must derive an EMSK on the EAP server and the EAP peer. o Since Kerberos uses time-tamps for protection against replay attacks, there must be a reasonably small time skew between the clocks of the EAP server, the EAP peer and the KDC. Zrelli & Shinoda Expires January 31, 2008 [Page 4] Internet-Draft EAP-FRAP July 2007 3. The Kerberos authentication protocol Kerberos [RFC4120] is a widely deployed authentication system. The authentication process in Kerberos involves principals and a Key Distribution Center (KDC). The principals can be users or services. Each KDC maintains a database of principals and shares a long term secret key with each registered principal. Kerberos is a third-party based authentication protocol. Kerberos exchanges, allow a user to acquire credentials and authenticate to a certain service registered in the Kerberos realm. An important part of the credentials are called Tickets. There are two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket (ST). The TGT is obtained periodically from the KDC and has a limited lifetime, after which it must be renewed. The TGT only allows users to obtain the second type of tickets (Service Tickets) which are used to authenticate to the desired application services. The process of obtaining a TGT is referred to as Authentication Service Exchange (AS exchange) which consists of one exchange (AS-REQ, AS-REP). The AS- REQ message includes the identity of the user a nonce and an optional pre-authentication component which consists of an encrypted timestamp. When a TGT request (AS-REQ) is issued by the user, the AS responds by sending a reply packet (AS-REP) containing the credentials which consists of the TGT along with a random key called 'TGS Session Key'. The TGS Session key is sent to the client encrypted using the key shared between the client and the KDC. On the other hand, the TGT contains the same 'TGS session key' encrypted using a secret key of a special service referred to as TGS "Ticket Granting Service" (TGS). The TGS is the service that delivers Service Tickets to clients. After an AS exchange, clients use the TGT and the TGS session key to authenticate to the TGS and obtain service tickets. Clients with valid TGTs perform a "TGS exchange" (TGS-REQ, TGS-REP), with the TGS in order to obtain service tickets. For that, the client starts by decrypting the TGS session key using long term the key secret secret shared with the KDC. The TGS-REQ message consists includes information about the desired service, the TGT and an Authenticator. The Authenticator, is used to prove the possession of the "TGS session key". The TGS uses its secret key to decrypt the TGT, then it verifies the Authenticator using the "TGS session key" extracted from the TGT. Finally, the TGS issues a TGS-REP message that contains the service ticket (ST) and a service session key. The ST is encrypted using the long term secret key shared between the KDC and the desired service. The service session key is encrypted usin the TGS session key. Zrelli & Shinoda Expires January 31, 2008 [Page 5] Internet-Draft EAP-FRAP July 2007 When the client recieves the TGS-REP message, it decrypts the service session key using the TGS session key, then authenticates to the application service. The authentication exchange ,referred to as an AP-Exchange, consists of tow messages (AP-REQ, AP-REP). The AP-REP message is optional and used when the client requests mutual authentication with the server. The AP-REQ message issued by the client, contains the ST and an Authenticator that proves the possession of the service session key. When the application server recieves the AP-REQ message, it uses its secret key to decrypt the ST, then uses the service session key to verify the authenticator. If the Authenticator is valid, the client is authenticated and granted access to the service. Figure 1 shows the different exchanges between the client, the KDC and the service. Zrelli & Shinoda Expires January 31, 2008 [Page 6] Internet-Draft EAP-FRAP July 2007 KDC +-------------------------------+ +---------+ Client | AS TGS | | SVC | | +----+--------------------+-----+ +----+----+ | | | | | AS-REQ [1] | | | | -----------------------> | | | | | | | | AS-REP [2] | | | | <----------------------- | | | | | | | | TGS-REQ [3] | | | --------------------------------------------> | | | | | | | TGS-REP [4] | | | <-------------------------------------------- | | | | | | | | | | | | | | | AP-REQ [5] | | -----------------------------------------------------------> | | | | | | AP-REP [6] | | <----------------------------------------------------------- | | | | | | | | | Zrelli & Shinoda Expires January 31, 2008 [Page 7] Internet-Draft EAP-FRAP July 2007 [1] Client -> AS : Client_ID, Nonce1, [TimeStamp1]_Client_K [2] AS -> Client : [Client_ID, ExpTime, TGS_SK]_TGS_K, [Nonce1, TGS_SK]_Client_K [3] Client -> TGS : [Client_ID, ExpTime, TGS_SK]_TGS_K, [Client_ID, TimeStamp1]_TGS_SK, SVC_ID, Nonce2 [4] TGS -> Client : [Client_ID, ExpTime, AP_SK]_SVC_K, [Nonce2, AP_SK]_TGS_SK [5] Client -> SVC : [Client_ID, ExpTime, AP_SK]_SVC_K, [Client_ID, TimeStamp2]_AP_SK, [6] SVC -> Client : [Client_ID, TimeStamp3]_AP_SK Notation : ---------- Client_ID : Principal name of the client [A]_x : Content A is encrypted using secret key x A_K : Secret key of principal A (shared with the KDC) TGS_SK : TGS session key AP_SK : Service Session key ExpTime : Time after which the Ticket expires SVC : An application service SVC_ID : Principal name of the application service Figure 1: The Kerberos Protocol exchanges (simplified) Zrelli & Shinoda Expires January 31, 2008 [Page 8] Internet-Draft EAP-FRAP July 2007 4. Overview A Kerberos realm and a AAA name are associated to each access network. An access network is thus uniquely defined by these two parameters. Two access networks may have the same Kerberos realm name, but in that case they can not have the same AAA realm name. Also, we assume that an access network may have more than one EAP server. However, the access network uses only one Kerberos KDC (unless the databases of the two KDCs are synchronized). The EAP server of the access network knows the Kerberos realm name. A Kerberos KDC serving the realm is deployed and ready to process standard Kerberos requests. The Kerberos KDC should be considered as a HOKEY server (as defined in [draft-ietf-hokey-key-mgm]) serving one or more access networks (that may or may not have the same AAA realm name). The Kerberos KDC includes special Kerberos service referred to as "knas" with the Kerberos principal name "knas/ AAA-realm@KRB5-realm", where the "AAA-realm" is the AAA realm name an access network and "KRB5-realm" is the Kerberos realm name of that same access network. Since a single Kerberos KDC can serve more that one access network, each with different AAA-realm and KRB5-realm, the KDC may have several instances of the service "knas". The Kerberos keytab (or equivalent) of the "knas" service, which contains a key only known to the KDC, is transferred to EAP server(s) of the access networks using out of band means (a keytab is a file that needs to be transferred manually into the filesystem of the EAP server). Zrelli & Shinoda Expires January 31, 2008 [Page 9] Internet-Draft EAP-FRAP July 2007 EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request [AAA-Realm = net1.example.com, KRB5-Realm = EXAMPLE.COM] (1) <---------------------- EAP-Identity Response (2) -----------------------> Eap-Identity Response (3) ------------------> EAP method exchange (4) <-----------------------------------------> EAP Success , MSK (5) <--------------------- Add principal (6) <--------------------> Figure 2: EAP Authentication when the EAP peer connects to an access network for the first time (i.e. No EMSK shared with any of the EAP servers) Typically, when an EAP peer uses an access network for the first time, it would perform a full EAP authentication (unless there is possibility of cross-realm authentication in which case the EAP peer should use EAP-FRAP, refer to Section 16 for roaming support). Upon successful completion of an initial EAP authentication, the EAP server and the EAP peer derive a Kerberos principal whose name is derived from the EAP peer identifier and whose secret key is derived from the EMSK (This secret key corresponds to the HRK). Details on how the Kerberos principal is constructed are in Section 14. The EAP peer securely adds the new principal to the database of the KDC using directory services, or Kerberos administration protocols such as kadmin (The procedure of adding new principal may depend on the back- end used as a KDC database. Therefore it is out of the scope of EAP- FRAP to specify how to add principals and how to remove them. Any back-end can be used as a Kerberos database as long as it provides an API that allows EAP-FRAP to add and remove principals from the Zrelli & Shinoda Expires January 31, 2008 [Page 10] Internet-Draft EAP-FRAP July 2007 Kerberos KDC in a secure manner). The EAP peer creates an entry in its EAP context that includes the new principal, the AAA realm name and the Kerberos realm name of the access network. Note that the EAP peer may have different Kerberos principals in its context as it roams between different access networks. When the EAP peer attempts to use an access network that supports EAP-FRAP, the EAP will obtain an initial EAP Identity Request message from the EAP authenticator. The EAP-Identity message includes the AAA realm name and the Kerberos realm name of the local access network in a fashion similar to [RFC4284]. This information is used by the EAP peer to check whether it can use EAP-FRAP or if it should use a full EAP authentication using any EAP authentication method. Details on how the EAP peer takes this decision can be found in Section 6. In the basic case (ignoring cross-realm support) the EAP peer can use EAP-FRAP if it can find a Kerberos principal in the EAP context that was created for the current access network identified by the AAA realm name and Kerberos realm name information recieved in the EAP Identity Request message. Zrelli & Shinoda Expires January 31, 2008 [Page 11] Internet-Draft EAP-FRAP July 2007 EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request [AAA-Realm = example.com, [KRB5-Realm = EXAMPLE.COM] (1) <---------------------- EAP-Identity Response (2) ----------------------> Eap-Identity Response (3) ------------------> EAP-FRAP (4) <----------------------------------------- EAP-FRAP [ AS-REQ (realm = EXAMPLE.COM), Authenticator ] (5) -----------------------------------------> AS-REQ (6) -----------------> AS-REP (7) <---------------- EAP-FRAP [ AS-REP ] (8) <---------------------------------------- EAP-FRAP [ TGS-REQ (sname = knas/example.com@EXAMPLE.COM)] (9) ----------------------------------------> TGS-REQ (10) -----------------> TGS-REP (11) <---------------- EAP-FRAP [ TGS-REP ] (12) <---------------------------------------- EAP-FRAP [ AP-REQ ] (13) ----------------------------------------> EAP Success , MSK (14) <--------------------- Figure 3: EAP Authentication using EAP-FRAP during first handover in the local access network (i.e. no TGT and no service ticket) Zrelli & Shinoda Expires January 31, 2008 [Page 12] Internet-Draft EAP-FRAP July 2007 When the EAP peer decides to use EAP-FRAP it negociates it as an EAP method and recieves an initial EAP-FRAP message. This message does not contain any specific information except the Kerberos realm name of the access network that the EAP peer already knows from the EAP Identity Request message. The EAP peer checks whether it has a valid Kerberos Ticket Granting Ticket (TGT) for the local Kerberos realm in its ticket cache. If it doesn't, then the EAP peer must obtain the TGT. The way of obtaining the TGT depends on wheter the EAP peer has a Kerberos principal for the Kerberos realm of the local access network or not. In the former case, the EAP peer will issue an AS-REQ message that will be forwarded by the EAP server to to the KDC serving the local access network. If the EAP peer have a Kerberos principal for a Kerberos realm different that the Kerberos realm of the local access network, then Kerberos cross-realm operations enter in action to obtain a TGT for the local access network. The details of cross-realm operations can be found in Section 16. The creation of an EAP-FRAP message encapsulating a Kerberos AS-REQ message is detailed in Section 7 When the local EAP server gets an EAP-FRAP message containing a Kerberos AS-REQ message, it extracts the AS-REQ message then sends it to the appropriate KDC. The the AS-REP relpy from the KDC is forwarded to the EAP peer. The processing of the the AS-REQ message is detailed in Section 8 If the EAP peer already has a TGT for the local Kerberos realm, it checks whether it has a service ticket for the service "knas/ AAA-realm@KRB5-realm" of the local access network. If such ticket does not exist, then an EAP-FRAP message encapsulating a TGS-REQ message is sent to the EAP server. The EAP server forwards the TGS- REQ message to the KDC and sends the TGS-REP reply message from the KDC back to the EAP peer. The acquisition of the service ticket trough the Kerberos TGS exchange with the KDC of the local access network is described in Section 9 and Section 10 Zrelli & Shinoda Expires January 31, 2008 [Page 13] Internet-Draft EAP-FRAP July 2007 EAP peer EAP authenticator EAP server kerberos KDC ~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~ EAP-Identity Request [AAA-Realm = example.com, [KRB5-Realm = EXAMPLE.COM] (1) <---------------------- EAP-Identity Response (2) ----------------------> Eap-Identity Response (3) ------------------> EAP-FRAP [KRB5-Realm=EXAMPLE.COM] (4) <----------------------------------------- EAP-FRAP [ AP-REQ ] (5) ----------------------------------------> EAP Success , MSK (6) <--------------------- Figure 4: EAP Authentication using EAP-FRAP after the first handover in the local access network (i.e. service ticket exists) If the EAP peer has a ticket for the service "knas", then it issues a EAP-FRAP Response message that contains an AP-REQ message using this ticket. The AP-REQ message will be processed by the EAP Server. For that the EAP server uses the keytab of the "knas" service to decrypt the ticket and authenticate the EAP peer. If authentication succeeds, the EAP peer issues an EAP Success message. Along with the EAP Success message, the EAP peer delivers the MSK to the EAP authenticator. The authentication of the EAP peer using the service ticket and the termination of EAP-FRAP is described in Section 11 and Section 12 Zrelli & Shinoda Expires January 31, 2008 [Page 14] Internet-Draft EAP-FRAP July 2007 5. EAP-FRAP message format EAP-FRAP encapsulates Kerberos5 [RFC4120] messages in EAP-Request and Response messages. The payload of the EAP message is formatted 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type | Reserved | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KRB5-Realm-Length | KRB5-Realm ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of the EAP-FRAP message The EAP peer and the EAP server use additional TLVs for carrying other components such as Kerberos messages and Authenticators. The fixed elements of the EAP-FRAP message are defined as follows : o Msg-Type : Indicates the type of the EAP-FRAP message. This field may take one of the following values KRB5-INIT, KRB5-AS-REQ, KRB5- AS-REP, KRB5-TGS-REQ, KRB5-TGS-REP, KRB5-AP-REQ, KRB-AP-REP, KRB5- FINISH. o Reserved : This field contains flags. The current version does not define any flags yet. The field is just reserved for future use. o Msg-Length : The length of the payload EAP-FRAP message. This length includes all parts of the message except the fields Msg- type, Reserved and Msg-Length. o KRB5-Realm-Length : Contains the length in bytes of the Kerberos5 realm name field. o KRB5-Realm : Contains a Kerberos5 realm name. Additional Type-Length-Value pairs are used in EAP-FRAP messages. Zrelli & Shinoda Expires January 31, 2008 [Page 15] Internet-Draft EAP-FRAP July 2007 These TLVs will be defined throughout the document. All the TLVs start by a 8 bit Type which is an integer indicating the type of TLV, followed by 16 bit Length field, finally a value field of variable length. Zrelli & Shinoda Expires January 31, 2008 [Page 16] Internet-Draft EAP-FRAP July 2007 6. Bootstrapping of EAP-FRAP The EAP peer is responsible of bootstrapping EAP-FRAP, it must decide whether it can use EAP-FRAP or not. This section describes how this decision is made by the EAP peer. When the EAP peer changes of access point, it is queried for its identity by the EAP authenticator with an initial EAP-Identity Request message. EAP-FRAP mandates that the AAA realm name and the Kerberos realm name to be included in the payload of the EAP-Identity Request message. EAP-FRAP uses the same syntax defined in [RFC4284]. The format of the payload of the alternative EAP Identity Request message is described in Section 15 The client may use EAP-FRAP in the following cases : o According to the EAP peer's context, the EAP peer has already authenticated to an EAP server of the access network. The EAP peer can determine this by looking in its EAP context for a Kerberos principal entry created for the local access network. kerberos principals are created by the EAP peer for each access netowrk with which the peer achieves a full EAP authentication for the first time. Refer to Section 14 for details of creation of Kerberos principals. o The EAP peer does not have a Kerberos principal for the local access network, but the EAP peer has a Kerberos principal for another access network with the same Kerbros realm name. o The EAP peer does not have a Kerberos principal for the local access network, but the EAP peer has a Kerbeos principal for another access network with different Kerberos realm name and different AAA realm name. (This case, the EAP peer will use Kerberos cross-realm authentication to obtain credentials in the new AAA realm). If the EAP peer does not have any Kerberos principal for any access network, then the EAP-FRAP can not be used. The EAP peer must perform a full EAP authentication using any legacy EAP authentication method. Clients that decide to use EAP-FRAP must negotiate the use of EAP- FRAP with an EAP server of the local access network as it would do with any other EAP authentication method, using the EAP-NAK message when necessary. When if the EAP server accepts the use of EAP-FRAP, it issues an initial EAP-FRAP Request message of type KRB5-INIT. The initial EAP- Zrelli & Shinoda Expires January 31, 2008 [Page 17] Internet-Draft EAP-FRAP July 2007 FRAP Request message does not contain additional TLVs. The KRB5- Realm field contains the Kerberos realm name of the access network. Zrelli & Shinoda Expires January 31, 2008 [Page 18] Internet-Draft EAP-FRAP July 2007 7. Creation of an EAP-FRAP / AS-REQ message After negotiating the use of EAP-FRAP and reception of the initial EAP-FRAP message (Msg-Type KRB5-INIT), the client checks if it has a TGT for the realm indicated in the KRB5-Realm field. If such TGT does not exist or exists but is expired, then the EAP peer must issue a EAP-FRAP Response encapsulating an AS-REQ message. The Msg-Type field of the EAP-FRAP message is set to KRB5-AS-REQ. An additional TLV or type "KRB5-MSG" (Type=0) is added. The value field of this TLV contains the DER encoding of a Kerberos AS-REQ message as defined in [RFC4120]. The AS-REQ message should contain a pre-authentication component that pre-authenticates the EAP peer to the Kerberos KDC. EAP-FRAP does not mandate a specific Kerberos pre-authentication mechanism. In order to build the AS-REQ message, the EAP uses the Kerberos principal that corresponds to the local access network. The EAP peer fills the AS-REQ message using the Kerberos realm name of the access network in the "realm" field of the AS-REQ. The "addresses" field of the AS-REQ message is left empty. Figure Figure 6 shows the layout of an EAP-FRAP message of type KRB5- AS-REQ (Msg-type 1) that encapsulates an AS-REQ and an Authenticator. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-type = 1 | Reserved | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KRB5-Realm-Length | KRB5-Realm ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Length | AS-REQ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of the EAP-FRAP AS-REQ message Zrelli & Shinoda Expires January 31, 2008 [Page 19] Internet-Draft EAP-FRAP July 2007 8. Receipt of an EAP-FRAP / AS-REQ message Upon reception of an AS-FRAP message of type KRB5-AS-REQ, the EAP server verifies the authenticator. If the authenticator is valid, then the EAP server will derive a Kerberos principal from the EAP peer's identity and EMSK. The EAP server may add or update the Kerberos principal in the database of the KDC serving the local access network. The maximum ticket lifetime and maximum total lifetime for renewable tickets must be equal or smaller than the remaining lifetime of the EMSK. The secret key of the new principal is the Handover Root Key (HRK). The EAP server adds the principal to the Kerberos KDC (Acting as a Hokey Server) using a secure protocol such as kadmin or directory services. The EAP server keeps track of the kerberos principals that were added in the database of Kerberos realm. Principals are removed from the Kerberos database when their corresponding HRK expire. After the EAP server has ensured the existence of the Kerberos principal, the AS-REQ message is extracted from the EAP-FRAP message and forwarded to the KDC of the local access network. The AS-REP message from the KDC is sent to the EAP peer in an EAP-FRAP message of type KRB5-AS-REP. The EAP-FRAP message contains a TLV of type "KRB5-MSG" that contains the DER encoding of the AS-REP message. Zrelli & Shinoda Expires January 31, 2008 [Page 20] Internet-Draft EAP-FRAP July 2007 9. Creation of an EAP-FRAP / TGS-REQ message If the EAP peer does not have a service ticket for the network access service. It must obtain one. The EAP peer prepares a TGS-REQ message as specified in [RFC4120]. The TGT for the local access network is used to build the TGS-REQ message. The "sname" field must be set to "knas/AAA-Realm", where AAA-Realm if the AAA realm name of the local access network. The "realm" field of the TGS-REQ message is set to the Kerberos realm name of the local access network. The TGS-REQ message is sent to the EAP server in an EAP-FRAP message. The Msg-Type field of the EAP-FRAP message is set to "KRB5-TGS-REQ". The EAP-FRAP message contains a TLV of type "KRB5-MSG". The payload of this TLV contains the DER encoding of the TGS-REQ message. Zrelli & Shinoda Expires January 31, 2008 [Page 21] Internet-Draft EAP-FRAP July 2007 10. Receipt of an EAP-FRAP / TGS-REQ message When the EAP server receives an EAP-FRAP message of type KRB5-TGS- REQ, it extracts the TGS-REQ message then proxies it to the KDC serving the local access network. The TGS-REP message from the KDC is encapsulated in an EAP-FRAP message with Msg-Type field equal to "KRB5-TGS-REP". The TGS-REP message is carried in a "KRB5-MSG" TLV. Zrelli & Shinoda Expires January 31, 2008 [Page 22] Internet-Draft EAP-FRAP July 2007 11. Creation of an EAP-FRAP / AP-REQ message The EAP peer creates an AP-REQ message as specified in [RFC4120]. The ticket for the service "knas/AAA-realm@KRB5-Realm" is used to build the AP-REQ message which will be shipped to the EAP server in an EAP-FRAP message where Msg-Type is set to "KRB5-AP-REQ". A TLV of type "KRB5-MSG" is used to carry the DER encoding of the AP-REQ message. Zrelli & Shinoda Expires January 31, 2008 [Page 23] Internet-Draft EAP-FRAP July 2007 12. Receipt of an EAP-FRAP / AP-REQ message When the EAP server receives an EAP-FRAP message of type "KRB5-AP- REQ", it starts by validating the ticket and the Authenticator included in the AP-REQ message. If the authentication of the EAP peer is successful, the EAP server may issue an AP-REP message if the flag "mutual-required" of the AP-REQ message is set. In this case, the EAP server sends the AP-REP message to the EAP peer. The AP-REP message is encapsulated in an EAP-FRAP message of type "KRB5-AP-REP". A TLV of type "KRB5-MSG" is used in the EAP-FRAP message to carry the DER encoded AP-REP message. If the flag "mutual-required" is not set, then the EAP server issues an EAP Success message. Along with the EAP Success message, the EAP server delivers an MSK to the EAP authenticator. If an AP-REP message was sent, the EAP peer will process the AP-REP as specified in [RFC4120]. If the AP-REP message is successfully verified, then the EAP peer issues an EAP-FRAP message with Msg-Type equal to "KRB5-FINISH". This EAP-FRAP message does not have any extra TLVs. The EAP peer can then derive the MSK. When the EAP server receives this EAP-FRAP message, it issues an EAP Success message. Along with the EAP Success message, the EAP server delivers an MSK to the EAP authenticator. The derivation of the MSK is detailed in Section 13 Zrelli & Shinoda Expires January 31, 2008 [Page 24] Internet-Draft EAP-FRAP July 2007 13. Derivation of MSK after termination of EAP-FRAP [TBD] Zrelli & Shinoda Expires January 31, 2008 [Page 25] Internet-Draft EAP-FRAP July 2007 14. Derivation of Kerberos principal [TBD] Zrelli & Shinoda Expires January 31, 2008 [Page 26] Internet-Draft EAP-FRAP July 2007 15. Payload formatting of the alternative EAP Identity Request [TBD] Zrelli & Shinoda Expires January 31, 2008 [Page 27] Internet-Draft EAP-FRAP July 2007 16. Inter access network roaming [TBD] 16.1. Inter Kerberos realm roaming [TBD] 16.2. Inter AAA realm roaming [TBD] Zrelli & Shinoda Expires January 31, 2008 [Page 28] Internet-Draft EAP-FRAP July 2007 17. Security considerations [RFC4120] highlights several security considerations. Most of these considerations 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 January 31, 2008 [Page 29] Internet-Draft EAP-FRAP July 2007 18. Normative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Zrelli & Shinoda Expires January 31, 2008 [Page 30] Internet-Draft EAP-FRAP July 2007 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 January 31, 2008 [Page 31] Internet-Draft EAP-FRAP July 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). Zrelli & Shinoda Expires January 31, 2008 [Page 32]