PPPEXT Working Group Adrian Buckley Internet Draft Prasanna Satarasinghe Vladmir Alperovich Transat Technologies Document: draft-buckley-pppext-eap-sim-gmm-00.txt Jose Puthenkulam August 2002 Jesse Walker Victor Lortz Intel Corporation EAP SIM GMM Authentication draft-buckley-pppext-eap-sim-gmm-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Abstract This document specifies an Extensible Authentication Protocol (EAP) method for authentication using the GSM Subscriber Identity Module (SIM) and standard GPRS Security and Mobility Management(GMM) messages. This method uses standard GPRS authentication and is recommended to be used within a secure transport layer channel established using another EAP method like PEAP. Buckley et al. Expires in six months [Page 1] Internet Draft EAP SIM GMM Authentication August 2002 Table of Contents Status of this Memo.........................................1 Abstract....................................................1 Table of Contents...........................................2 1. Introduction.............................................2 2. Terms....................................................4 3. Protocol Overview........................................6 3.1 GPRS Authentication.....................................6 3.2 EAP-SIM-GMM ............................................7 4. Protocol Operation.......................................7 4.1 PEAP Server Authentication and Session Establishment....7 4.2 EAP-SIM-GMM Client Authentication.......................8 5. Protocol Messages.......................................10 5.1 EAP Request/Identity...................................10 5.2 EAP-Response/Identity..................................11 5.3 EAP-Request/SIM-GMM/Start..............................12 5.4 EAP-Response/SIM-GMM/SIM-GMM Attach Request............12 5.5 EAP-Request/SIM-GMM/SIM-GMM Identity Request...........14 5.6 EAP-Response/SIM-GMM/SIM-GMM Identity Response.........15 5.7 EAP-Request/SIM-GMM/SIM-GMM Auth.& Ciphering Request...16 5.8 EAP-Response/SIM-GMM/SIM-GMM Auth.& Ciphering Response.17 5.9 EAP-Request/SIM-GMM/SIM-GMM Attach Accept..............19 5.10 EAP-Response/SIM-GMM/SIM-GMM Attach Complete..........20 5.11 EAP Success...........................................21 5.12 Unsuccessful Cases....................................21 5.13 EAP-Response/SIM-GMM/Attach Reject....................23 5.14 EAP-Response/SIM-GMM/Acknowledge......................24 5.15 EAP Failure...........................................25 6. IANA Considerations.....................................25 7. Security Considerations.................................26 8. References..............................................27 Acknowledgements...........................................28 Authors Information........................................29 Intellectual Property Statement............................30 Full Copyright Statement...................................30 1. Introduction This document specifies an Extensible Authentication Protocol (EAP) [1] method for authentication using the GSM Subscriber Identity Module(SIM). The messages used to encapsulate the SIM credentials are based on the GPRS Security and Mobility Management Protocol(GMM) [2]. This provides consistent authentication interfaces for GPRS/UMTS and other wireless local area networks. This method relies on a secure transport layer channel established using PEAP for reliable link layer security [3]. Buckley et al. Expires in six months [Page 2] Internet Draft EAP SIM GMM Authentication August 2002 We rely on PEAP for session key derivation so that any other EAP client authentication method could be utilized without duplicating the complexity of generating a secure key hierarchy. Though PEAP is the recommended method in this draft, alternate methods like EAP-TTLS may also be used in place of PEAP. Though this method is generic enough to be used for most networks, the typical scenario intended is the 802.1X based [4] wireless networks where a common authentication and billing infrastructure provided by the GPRS/UMTS network can be utilized on the backend. Addressing the necessity for providing consistent connection management capabilities for applications while roaming between these wireless networks is another intended objective. This is accomplished by utilizing the GPRS Attach and Detach procedures that are consistent in GPRS and UMTS networks, in 802.1X based networks. The usage of USIM is currently beyond the scope of this current draft. But the architecture is consistent with backend UMTS networks [5]. The Figure 1 lays out the entities in the discussion. It also illustrates the architectural assumptions made for using the proposed authentication method. The subscriber running the EAP Client uses a GPRS SIM credential for authentication. The Network Access Server or NAS supports EAP methods transparently between the EAP Client and the EAP Server. The EAP Server terminates the EAP protocol. The Inter-Working Function or IWF is responsible for protocol translation between the HLR located in the home PLMN and the EAP Server. The location of the network AAA server function for the EAP client when using SIM authentication is beyond the scope of this draft but could be implemented in the IWF or the EAP Server. The full functionality of the EAP Server and the IWF and their interconnection is beyond the scope of this draft, but we presume its implementation will address the needs of the roaming subscriber. We assume that as part of provisioning, the EAP Server has the server certificates necessary to establish PEAP sessions with the client. The client also needs to be provisioned to be able to trust the server certificates. The EAP-SIM-GMM method is used within the PEAP session which provides strong link layer encryption using a cipher suite negotiated between the EAP Client and the NAS. For information on PEAP session establishment please refer to [3]. Buckley et al. Expires in six months [Page 3] Internet Draft EAP SIM GMM Authentication August 2002 +--------------------------+ | Home PLMN | | GPRS Network | | | | +---------+ | | | | | | +-----+ HLR/AuC | | | | | | | | | +---------+ | | +--------+ | | | | | +---| IWF |-------------+ | | +---+----+ | | | +------------+ +-------------+ +-----+-----+ | <==========PEAP Session============> | | | | | | | | EAP | | NAS | | EAP | | Client |------| |---------+ Server | | (with SIM) | | | | | +------------+ +-------------+ +-----------+ Figure 1 : Architecture Overview 2. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This document frequently uses the following terms and abbreviations: AAA Authentication, Authorization and Accounting functions AuC Authentication Centre. The GSM network element that can authorize the subscriber. Buckley et al. Expires in six months [Page 4] Internet Draft EAP SIM GMM Authentication August 2002 NAS The NAS which is the entity EAP Extensible Authentication Protocol. EAP Server The network element that terminates the EAP protocol. Typically, the EAP server functionality is implemented in an Authentication server. GMM GPRS Mobility Management GPRS General Packet Radio Services GSM Global System for Mobile communications. HLR Home Location Register which contains the subscriber details database. It also provides the authentication triplets composed of RAND, SRES and Kc. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. IWF Inter-working Function NAI Network Access Identifier Buckley et al. Expires in six months [Page 5] Internet Draft EAP SIM GMM Authentication August 2002 PEAP Protected EAP. Using TLS to establish a secure channel to carry EAP messages and distribute 128 bit WEP [JP8]Encryption keys. PLMN Public Land Mobile Network P-TMSI Packet Temporary Mobile Subscriber Identity the temporary identifier used in place of IMSI for privacy reasons. It is equivalent in function and corresponds to the IMSI. SIM Subscriber Identity Module. SIM cards are smart cards distributed by GSM operators. TLS Transport Layer Security. UMTS The Universal Mobile Telecommunications System addressing 3GPP Release 99 to Release 5 specifications. 3. Protocol Overview 3.1 GPRS Authentication When a Mobile Subscriber requests Authentication from the AAA entities in the GPRS network, the Subscriber performs an Attach that contains the subscribers identity, IMSI [6]. The network then authenticates the subscriber based on a challenge-response mechanism. The authentication algorithm that runs on the SIM can be given a 128-bit random number (RAND) as a challenge. The SIM runs a specific confidential algorithm which takes the RAND and a secret key Ki stored on the SIM as input, and produces a 32-bit response (SRES) and a 64-bit long key Kc as output. The Kc key is originally intended to be used as an encryption key over the air interface. Buckley et al. Expires in six months [Page 6] Internet Draft EAP SIM GMM Authentication August 2002 We do not recommend using Kc for link layer encryption instead we suggest the usage of PEAP session keys. Please find more information about GSM authentication in [7]. If the Authentication is successful the subscriber is allowed to connect by the attach procedure being completed. When the subscriber loses connectivity or intentionally disconnects the Detach procedure takes place but it happens within the data channel here and hence is beyond the scope of this draft. Please find more information about the GSM GPRS Attach/Detach procedures in [2]. 3.2 EAP-SIM-GMM In EAP-SIM-GMM, the GPRS GMM messages for authentication are tunneled in the EAP messages. The procedures as specified in [2] are performed with respect to GPRS Attach, Authentication and Attach Accepts or Rejects. This mechanism allows to use existing GSM, GPRS authentication mechanisms without any modifications to SIM behavior and is consistent with the GPRS Network functionality. The premise for using GMM messages is the capability for a EAP client application to able to implement functionality for consistent network interface behavior across 802.1X, GPRS and UMTS wireless networks. Instead of changing the existing GSM, GPRS security mechanisms, for addressing security issues in 802.1X [4] based wireless networks it relies on more robust and open security mechanisms such as PEAP [3] to carry out the additional security requirements (e.g. mutual authentication, origin authentication, stronger encryption, dynamic key distribution) between the EAP Client, NAS and the EAP Server. Another goal is to avoid any changes to the NAS while employing this proposed method as long as PEAP is supported. 4. Protocol Operation The EAP-SIM-GMM protocol relies on PEAP for server authentication and provides only client authentication on its own. The overall operation is described in two steps, PEAP Session establishment, and EAP-SIM-GMM Client Authentication. 4.1 PEAP Server Authentication and Session Establishment The establishment of PEAP being another EAP method requires the client identity to be sent as part of the initial EAP exchange. We suggest the usage of any implementation specific user identifier for this purpose in the form of an NAI. The details of the PEAP Buckley et al. Expires in six months [Page 7] Internet Draft EAP SIM GMM Authentication August 2002 session establishment and resultant server authentication is described in [3]. If the PEAP session establishment fails then the EAP-SIM-GMM protocol is never started. 4.2 EAP-SIM-GMM Client Authentication The PEAP session MUST be successfully established for EAP-SIM-GMM to start. Figure 2 shows an overview of the EAP-SIM-GMM authentication procedure. The EAP-SIM/GMM exchange uses four roundtrips to authenticate the user and allow access to the network. The first EAP Request issued by the EAP Server after the PEAP establishment is EAP-Request/Identity. The client response includes the user's Packet Temporary Mobile Subscriber Identity (P-TSMI). If the client has no valid P-TMSI the client MUST respond with its International Mobile Subscriber Identity (IMSI). This is sent in NAI form [11]. e.x. GMM@ or GMM@ The 'GMM' prefix MUST be used to as part of the NAI to help the EAP server recognize the EAP-SIM-GMM method it needs to use. The generation of realm portion of the NAI from IMSI is described in [12]. Recognizing the NAI to be EAP-SIM-GMM the EAP Server will send the EAP-Request/SIM-GMM/Start message to the client; this will be of EAP Type . All the following EAP-Request/Response SIM-GMM messages MUST have this Type value. The client responds to this with the EAP-Response/Attach Request with attributes which includes the IMSI or P-TMSI. If the P-TMSI is unknown to the network, the optional messages (a) and (b) are used to resend the Attach with the IMSI. Note that as PEAP is used to establish a secure channel, the user privacy features afforded by the P-TMSI may not be needed. This could reduce the number of roundtrips needed for authentication. The next EAP Request the server issues is the Authentication and Ciphering Request and contains the attributes RAND, other attributes and Ciphering Algorithm. On receipt of this message, the client runs the GSM authentication algorithm on the SIM and calculates a authentication value SRES. The client responds with the EAP-Response/Authentication and Ciphering Response, containing the authentication value SRES. The network authentication function verifies that the SRES is correct and it causes the EAP Server to sends an EAP-Request/Attach Accept with attributes including the P-TMSI. The EAP Client acknowledges the receipt of EAP-Request/Attach Accept with EAP-Response/Attach Complete. The EAP server verifies that the authentication was successful by sending an EAP-Success packet. This message also bears the keying material for performing the link layer encryption between the client and the NAS based on the master session keys derived as part of the PEAP session. Buckley et al. Expires in six months [Page 8] Internet Draft EAP SIM GMM Authentication August 2002 Client Network Access Server (NAS) | | | EAP-Request/Identity | |<-------------------------------------------------------------| | | | EAP-Response/Identity | |(Includes user's IMSI or P-TMSI in NAI form) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/Start | |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/Start/SIM-GMM Attach Request | | (Includes user's IMSI or P-TMSI) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/SIM-GMM Identity Request (optional)(a)| |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/SIM-GMM Identity Response (optional)(b) | | (Includes IMSI) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/SIM-GMM Authen. & Ciphering Request | | (RAND, CKSN, Ciphering Algorithm) | |<-------------------------------------------------------------| | | +-------------------------------------+ | | Client runs GSM algorithms on SIM | | | | | | | | +-------------------------------------+ | | | |EAP-Response/SIM-GMM/SIM-GMM Authen. & Ciphering Response | | (SRES) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/SIM-GMM Attach Accept (P-TMSI) | |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/SIM-GMM Attach Complete | |------------------------------------------------------------->| | | | | | EAP-Success | |<-------------------------------------------------------------| | | Figure 2 EAP-SIM/GMM authentication procedure Buckley et al. Expires in six months [Page 9] Internet Draft EAP SIM GMM Authentication August 2002 5. Protocol Messages 5.1 EAP-Request/Identity The first EAP Request is of type Identity. In the beginning of EAP authentication, the NAS issues the EAP-Request/Identity packet to the client. The format of the EAP Request/Identity packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Type 1 Type Data This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required. Buckley et al. Expires in six months [Page 10] Internet Draft EAP SIM GMM Authentication August 2002 5.2 EAP-Response/Identity In response to the EAP-Request/Identity the client responds with EAP-Response/Identity, which contains the user's identity. The format of the initial EAP-Response/Identity is specified in [1]. GSM subscribers are identified with the International Mobile Subscriber Identity (IMSI) [6]. The IMSI is composed of a three digit Mobile Country Code (MCC), a two or three digit Mobile Network Code (MNC) and a not more than 10 digit Mobile Subscriber Identification Number (MSIN). In other words, the IMSI is a string of not more than 15 digits. MCC and MNC uniquely identify the GSM operator. To protect a subscribers identity the GSM subscriber may also identify itself with a Packet Temporary Mobile Subscriber Identity (P-TMSI). The P-TMSI is composed of 4 octets and has only local significance. It can be coded using a full hexadecimal representation. If the EAP Server is unable to derive the IMSI either from itself it needs to ask for the IMSI using messages (a) and (b) in Figure 2. The format of the EAP Response/Identity packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 for Response Identifier See [1]. Length The length of the EAP packet. Type 1 Buckley et al. Expires in six months [Page 11] Internet Draft EAP SIM GMM Authentication August 2002 Type Data IMSI or P-TMSI in NAI format 5.3 EAP-Request/SIM-GMM/Start The format of the EAP-Request/SIM-GMM/Start packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Reserved | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. Reserved From 0 to 20 bytes. 5.4 EAP-Response/SIM-GMM/SIM-GMM Attach Request The format of the EAP Response/SIM-GMM/SIM-GMM Attach Request packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Attach Request | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Buckley et al. Expires in six months [Page 12] Internet Draft EAP SIM GMM Authentication August 2002 Code 2 for Response Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Buckley et al. Expires in six months [Page 13] Internet Draft EAP SIM GMM Authentication August 2002 Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Attach Request This is a complete GPRS Attach message as specified in [2]. 5.5 EAP-Request/SIM-GMM/SIM-GMM Identity Request The format of the EAP-Request/SIM-GMM/SIM-GMM Identity Request packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Identity Request | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Buckley et al. Expires in six months [Page 14] Internet Draft EAP SIM GMM Authentication August 2002 Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Identity Request This is a complete SIM-GMM Identity Request message as specified in [2]. 5.6 EAP-Response/SIM-GMM/SIM-GMM Identity Response The format of the EAP-Response/SIM-GMM/SIM-GMM Identity Response packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Identity Response | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 for Response Buckley et al. Expires in six months [Page 15] Internet Draft EAP SIM GMM Authentication August 2002 Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Identity Response This is a complete GPRS Identity Response message as specified in [2]. 5.7 EAP-Request/SIM-GMM/SIM-GMM Authentication and Ciphering Request The format of the EAP-Request/SIM-GMM/SIM-GMM Authentication and Ciphering Request packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Authentication Request | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Buckley et al. Expires in six months [Page 16] Internet Draft EAP SIM GMM Authentication August 2002 Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Authentication Request This is a complete GPRS Authentication and Ciphering Request message as specified in [2]. 5.8 EAP-Response/SIM-GMM/SIM-GMM Authentication Response The format of the EAP-Response/SIM-GMM/SIM-GMM Authentication and Ciphering Response packet is shown below. Buckley et al. Expires in six months [Page 17] Internet Draft EAP SIM GMM Authentication August 2002 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 | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Authentication and | | Ciphering Response | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 for Response Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Authentication Response This is a complete GPRS Authentication and Ciphering Response message as specified in [2]. Buckley et al. Expires in six months [Page 18] Internet Draft EAP SIM GMM Authentication August 2002 5.9 EAP-Request/SIM-GMM/SIM-GMM Attach Accept The format of the EAP-Request/SIM-GMM/SIM-GMM Attach Accept packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SIM-GMM Attach Accept | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Attach Accept This is a complete GPRS Attach Accept message as specified in [2]. Buckley et al. Expires in six months [Page 19] Internet Draft EAP SIM GMM Authentication August 2002 5.10 EAP-Response/SIM-GMM/SIM-GMM Attach Complete The format of the EAP-Response/SIM-GMM/SIM-GMM Attach Complete packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Attach Complete | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 for Response Identifier See [1]. Length The length of the EAP packet. Type Subtype See section 6 for definition and setting. Buckley et al. Expires in six months [Page 20] Internet Draft EAP SIM GMM Authentication August 2002 Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Attach Complete This is a complete GPRS Attach Complete message as specified in [2]. 5.11 EAP Success See [1]. 5.12 Unsuccessful Cases As normally in EAP, the client is sent the EAP-Failure packet when the authentication procedure fails on the EAP Server. In EAP/SIM-GMM, this may occur for example, if the network authentication function fails. All error handling for SIM-GMM procedures is described in [2]. Buckley et al. Expires in six months [Page 21] Internet Draft EAP SIM GMM Authentication August 2002 Client Network Access Server (NAS) | | | EAP-Request/Identity | |<-------------------------------------------------------------| | | | EAP-Response/Identity | |(Includes user's IMSI or P-TMSI in NAI form) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/Start | |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/Start/SIM-GMM Attach Request | | (Includes user's IMSI or P-TMSI) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/SIM-GMM Identity Request (optional)(a)| |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/SIM-GMM Identity Response (optional)(b) | | (Includes IMSI) | |------------------------------------------------------------->| | | | EAP-Request/SIM-GMM/SIM-GMM Authen. & Ciphering Request | | (RAND, CKSN, Ciphering Algorithm) | |<-------------------------------------------------------------| | | +-------------------------------------+ | | Client runs GSM algorithms on SIM | | | | | | | | +-------------------------------------+ | | | |EAP-Response/SIM-GMM/SIM-GMM Authen. & Ciphering Response | | (SRES) | |------------------------------------------------------------->| | | | | | EAP-Request/SIM-GMM/SIM-GMM Attach Reject | |<-------------------------------------------------------------| | | | EAP-Response/SIM-GMM/Acknowledge | |------------------------------------------------------------->| | | | EAP-Failure | |<-------------------------------------------------------------| | | Figure 3 EAP/SIM-GMM authentication procedure failure Buckley et al. Expires in six months [Page 22] Internet Draft EAP SIM GMM Authentication August 2002 As specified in [1], the EAP client MUST respond with EAP- Response/Nak when it receives an EAP Request of an undesired or unrecognized authentication type. Also if the SIM-GMM message cannot be processed, the EAP client MUST respond with EAP-Response/Nak. 5.13 EAP-Request/SIM-GMM/SIM-GMM Attach Reject The format of the EAP-Request/SIM-GMM/SIM-GMM Attach Reject packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SIM-GMM Attach Reject | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Type Buckley et al. Expires in six months [Page 23] Internet Draft EAP SIM GMM Authentication August 2002 Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. SIM-GMM Attach Reject This is a complete GPRS Attach Reject message as specified in [2]. 5.14 EAP-Response/SIM-GMM/Acknowledge This message is specific to the EAP-SIM-GMM protocol and is not part of the GMM message set. The format of the EAP-Response/SIM-GMM/Acknowledge packet is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version (major, minor) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GMM Session Identity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Request Identifier See [1]. Length The length of the EAP packet. Buckley et al. Expires in six months [Page 24] Internet Draft EAP SIM GMM Authentication August 2002 Type Subtype See section 6 for definition and setting. Version 2 byte field for the version of the EAP-SIM-GMM protocol. The first byte indicating the major and the second minor versions. GMM Session Identity 4 byte field to uniquely identify the GMM session. Reserved From 0 to 4 bytes. 5.15 EAP Failure See [1]. 6. IANA Considerations The realm name "owlan.org" that has been reserverd for NAI realm names generated from the IMSI is used here. IANA has assigned the EAP type number for this protocol. EAP/SIM-GMM messages include a Subtype field. The following Subtypes are specified: Start.............................................10 SIM-GMM Attach Request............................11 SIM-GMM Identity Request..........................12 SIM-GMM Identity Response.........................13 SIM-GMM Authentication & Ciphering Request........14 SIM-GMM Authentication & Ciphering Response.......15 SIM-GMM Attach Accept.............................16 SIM-GMM Attach Complete...........................17 SIM-GMM Attach Reject.............................18 Acknowledge.......................................19 Buckley et al. Expires in six months [Page 25] Internet Draft EAP SIM GMM Authentication August 2002 7. Security Considerations Although they are both wireless technologies, GPRS and 802.11 networks have different characteristics that render GSM-SIM authentication vulnerable when used with 802.11. a. The cost of deploying a rogue access point is significantly lower than the cost of deploying a rogue GPRS tower. b. The 802.11 platform is usually an open platform such as a personal computer, while a GPRS platform is typically closed, such as a cellular phone. There is a well-developed suite of tools for an attacker to use against the open platform, while those to attack a GPRS platform are more obscure and more expensive to locate. c. Voice communication is the most common traffic carried over a GPRS network, and the human ear can usually detect when the phone does not connect to the intended recipient. In a computer network it is difficult or impossible to determine whether the communication peer is the intended party without mutual authentication. d. The most common reason to attack a GPRS network is to steal service. A platform participating in an 802.11 network typically contains content (e.g., an enterprise's intellectual property) or can be easily compromised to serve as a platform for criminal activity (e.g., launching distributed denial of service attacks), so faces a different set of threats. Because of these differences, GSM-SIM by itself cannot meet the security requirements for authentication and key management in an 802.11 LAN. Additionally, GSM algorithms are comparatively weak and are vulnerable to attack when run exposed in open systems [20]. Accordingly, this specification requires PEAP to add the mutual authentication missing from basic GSM-SIM, and to protect the GSM-SIM authentication from direct attack. EAP-SIM-GMM due to the use of PEAP protects the privacy of the subscriber identity against passive eavesdropping and also active attacks. Buckley et al. Expires in six months [Page 26] Internet Draft EAP SIM GMM Authentication August 2002 8. References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998 [2] GSM Technical Specification GSM 04.08 (ETS 300 940): "Digital cellular telecommunication system (Phase 2+); Mobile radio interface layer 3 specification", European Telecommunications Standards Institute, June 2000 Version 7.8.0 [3] S. Josefsson, H. Anderson, G. Zorn, D. Simon, A. Palekar, "Protected EAP Protocol (PEAP)",draft-josefsson-pppext-eap- tls-eap-02.txt, February 2002, work in progress. [4] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [5] 3GPP. 3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; General Packet Radio Service (GPRS); Service Description; Stage 2. Technical Specification 3G TS 23.060 version 3.6.0 (2001-01), 2000. [6] GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997 [7] GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital cellular telecommunication system (Phase 2); Security related network functions", European Telecommunications Standards Institute, August 1997 [8] 3GPP. 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Radio Interface Layer 3 Specification; Core Network Protocols Stage 3 for Release 1999. 3G TS 24.008 version 3.6.0 (2000-12), 2000. [9] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [10] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. Buckley et al. Expires in six months [Page 27] Internet Draft EAP SIM GMM Authentication August 2002 [12] J. Arkko, H. Haverinen, "EAP AKA Authentication", draft-arkko- pppext-eap-aka-04.txt, June 2002 (work in progress). [13] Federal Information Processing Standard (FIPS) draft standard, "Advanced Encryption Standard (AES)", http://csrc.nist.gov/publications/drafts/dfips-AES.pdf, September 2001 [14] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, December 1980. [15] GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997 [16] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, November 1998. [17] Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, April 17, 1995. [18] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [19] 3GPP TS 03.60 V7.7.0 3rd Generation Partnership Project "Digital cellular telecommunication system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2 [20] L. Pesonen, GSM Interception, http://www.dia.unisa.it/ads.dir/ corso-security/www/CORSO-9900/a5/Netsec/netsec.html, Nov. 1999 Acknowledgments Authors wish to thank Prakash Iyer, Uttam Sengupta, Shelagh Callahan, Jim Rosa and Yung Hahn of Intel, also Jim Goss, Yong Zhou, Christina Kim, Abid Inam and David Hui of Transat Technologies for ideas and useful discussions which helped us in this effort. Buckley et al. Expires in six months [Page 28] Internet Draft EAP SIM GMM Authentication August 2002 Authors Information Adrian Buckley 180 State St, Suite 240 Southlake, TX 76092 USA E-mail: abuckley@transat-tech.com Phone: +1 817 481 4412 Fax: +1 817 481 4461 Prasanna Satarasinghe 180 State St, Suite 240 Southlake, TX 76092 USA E-mail: prasannas@transat-tech.com Phone: +1 817 481 4412 Fax: +1 817 481 4461 Vladmir Alperovich 180 State St, Suite 240 Southlake, TX 76092 USA E-mail: vlad@transat-tech.com Phone: +1 817 481 4412 Fax: +1 817 481 4461 Jose Puthenkulam 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 E-mail: jose.p.puthenkulam@intel.com Phone: +1 503 264 6121 Fax: +1 503 264 8154 Jesse Walker 2111 NE 25th Avenue, JF3-466 Hillsboro, OR 97124 E-mail: jesse.walker@intel.com Phone: +1 503 712 1849 Fax: +1 503 712 2026 Victor Lortz 2111 NE 25th Avenue, JF3-206 Hillsboro, OR 97124 E-mail: victor.lortz@intel.com Phone: +1 503 264 3253 Fax: +1 503 264 3483 Buckley et al. Expires in six months [Page 29] Internet Draft EAP SIM GMM Authentication August 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Buckley et al. Expires in six months [Page 30]