Internet Engineering Task Force Internet Draft A. Salkintzis Document: draft-salki-pppext-eap-gprs-00.txt Motorola Expires: June 2003 December 2002 The EAP GPRS Protocol (EAP-GPRS) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. Salkintzis Expires - June 2003 [Page 1] EAP GPRS Authentication December 2002 Conventions used in this document 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 [4]. Table of Contents 1. Introduction and Motivation...................................2 2. Terminology...................................................4 3. Protocol Architecture.........................................6 4. Protocol Overview.............................................7 4.1 Protocol Services.........................................9 5. Packet Format................................................10 6. Detailed Protocol Description................................11 6.1 UA Dialogue Initiation...................................11 6.2 UA Dialogue..............................................12 6.3 UA Dialogue Termination..................................13 7. Examples.....................................................13 8. IANA Considerations..........................................18 9. Security Considerations......................................18 10. References..................................................19 Acknowledgments.................................................20 Author's Addresses..............................................20 1. Introduction and Motivation This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to attach/handover to a GPRS core network through devices that enforce EAP-based access control (such as 802.1X access points). A typical scenario where EAP-GPRS is widely applicable is when a WLAN is tightly-coupled (see section 2) with a GPRS core network and serves as a complimentary GPRS radio access technology. In the case, when a GPRS client enters into the WLAN, it needs to deal with two independent access control procedures: (i) the 802.1X enforced by the WLAN access points and (ii) the GPRS specific access control (in accordance with 3GPP TS 24.008 [6]) enforced by the GPRS core network. With the aid of EAP-GPRS, the GPRS access control (or mobility management) signaling takes place in the context of 802.1X access control signaling, as an embedded procedure. This is accomplished by encapsulating GPRS messages into EAP-GPRS packets. Furthermore, EAP-GPRS determines the outcome of 802.1X procedure based on the outcome of GPRS access control procedure. That is, if the GPRS access control is (un)successful, then the 802.1X procedure is also (un)successful. With these properties, EAP-GPRS becomes a glue mechanism that correlates the above two access control schemes and allows GPRS clients to use the same GPRS Mobility Management Salkintzis Expires - June 2003 [Page 2] EAP GPRS Authentication December 2002 (GMM) mechanisms independently of the underlying radio technology (e.g. GPRS or WLAN). This allows simpler GPRS client implementations and simpler subscriber management, since a single GPRS subscription is required to control both WLAN access and GPRS core network access. By allowing the GMM signaling to be carried out in the context of 802.1X procedure, EAP-GRPS can facilitate inter-RAT handovers (e.g. between GPRS and WLAN) with the use of a single mobility management protocol. For example, when a GPRS client roams from a GPRS radio access network to a WLAN radio access network, the typical GPRS Routing Area Update (RAU) procedure [6] can be carried out in the context of 802.1X procedure. Should the client is allowed to handover to the new area (WLAN), the RAU procedure terminates successfully and in turn the 802.1X procedure terminates successfully as well. EAP-GPRS is not a new authentication mechanism but rather a new transport mechanism for higher-layer protocols. These higher-layer protocols are referred to as EAP-GPRS User Applications (UAs). EAP- GPRS relies on UAs to authenticate a GPRS client and to provide a particular grade of transport service (e.g. error detection, sequence control, flow control, etc.) Note: Although in this document we focus on GPRS specific UAs, EAP- GPRS in general can support non-GPRS specific UAs as well. Therefore, EAP-GPRS can support GPRS clients and non-GPRS clients. Nevertheless, in the rest of this document we explicitly focus on GPRS clients. In general, the advantage of using EAP-GPRS is (i) that GMM procedures can be carried out in the context of an underlying 802.1X procedure and (ii) that a correlation mechanism is created between these procedures. With such a correlation mechanism in place, the 802.1X procedure terminates successfully or not successfully based on the outcome of the embedded GMM procedure. In other words, when a GPRS client manages to attach or handover successfully to the GPRS core network, then the 802.1X procedure terminates successfully and the GPRS client is authorized to use a port in the access network for subsequent data transfer. On the contrary, if a GPRS client is rejected access to the GPRS core network (e.g. due to authentication failure or subscription limitations), then the underlying 802.1X procedure terminates unsuccessfully and the client cannot use the access network for any data transfer. Another advantage of using EAP-GPRS is that multi-RAT mobiles (i.e. mobiles that can support two or more Radio Access Technologies, such as UTRAN, GSM/GPRS, IEEE 802.11, etc) can implement a single set of mobility management procedures across all the supported RATs. With EAP-GPRS the GPRS mobility management procedures can be applied also over networks that enforce 802.1X access control. Salkintzis Expires - June 2003 [Page 3] EAP GPRS Authentication December 2002 2. Terminology authenticator A device that provides a point of entry into the access network and enforces access control based on the EAP protocol. A typical example of an authenticator is a WLAN access point compliant with IEEE 802.1X [3]. GPRS The General Packet Radio Service (GPRS) is a packet-switched bearer service supported in both GSM and UMTS networks. GPRS services in GSM are supported in the so-called Gb mode, whereas GPRS services in UMTS are supported in the so-called Iu mode (see [5]). These two different modes of GPRS operation account for the different characteristics between the GPRS bearers in GSM and the GPRS bearers in UMTS. GPRS Client A mobile device that supports GPRS operation in Gb mode or Iu mode or both Gb and Iu modes. In this document a GPRS client is assumed to be a dual-RAT device that supports both GPRS and 802.11 RATs. GPRS Core Network (GPRS CN) The set of core network elements dedicated to the provision the GPRS bearer services. A GPRS CN can provide GPRS services in Gb mode, Iu mode, or both Gb and Iu mode. The GPRS CN typically provides access control, mobility management and session management procedures, as well as admission control and traffic handling. A GPRS bearer originates at a GPRS client and terminates at an edge of GRPS CN. GPRS dialogue See UA dialogue. GMM message A GPRS Mobility Management (GMM) message compliant with 3GPP TS 24.008 [6]. GMM messages are elements of GMM protocol, which is specified in 3GPP TS 24.008. This protocol is a layer-2 mobility management protocol used specifically for the provision of mobile GPRS services. GPRS AAA server A back-end AAA server that terminates the EAP-GPRS protocol and provides access control to the GPRS core network for GPRS clients in a WLAN area. The GPRS AAA server may be implemented as a separate inter-working device, or in a device that provides GPRS specific functionality, e.g. a Serving GPRS Support Node (SGSN) [5]. Salkintzis Expires - June 2003 [Page 4] EAP GPRS Authentication December 2002 P-TMSI Packet-Temporary Mobile Subscriber Identity. This is a GPRS temporary identity, which together with an associated P-TMSI Signature, provide user identity confidentiality. When the GPRS CN assigns a new P-TMSI to a GPRS client, it typically assigns a corresponding P-TMSI Signature as well. For more information on P-TMSI and P-TMSI Signature the reader is referred to 3GPP TS 23.060 [5]. RAT Radio Access Technology Tight Coupling In this document the term Tight Coupling refers to a coupling mechanism between a WLAN and a GPRS core network, where the WLAN is deployed as a complimentary GPRS radio access network. With this coupling mechanism both the GPRS control- and user- plane traffic passes through the GPRS core network. This is in contrast with the so-called Loose Coupling mechanism, where only access control traffic terminates in the GPRS core network. With this mechanism the WLAN is deployed as an IP access network (i.e. it provides access to an IP network) and user plane traffic bypasses the GPRS core network. More information about tight and loose coupling can be found in [7]. The EAP-GPRS protocol specified in this document is mainly applicable in tight coupling scenarios. UA User Application: That is an application operating on top of EAP-GPRS, which uses the transport service of EAP-GPRS to exchange messages with a peer UA during an 802.1X procedure. UA dialogue A sequence of UA messages exchanged between a GPRS client and a GPRS AAA server in the context of a single EAP-GPRS transaction. In this document, these UA messages encapsulate GPRS messages and therefore the terms æUA dialogueÆ and æGPRS dialogueÆ are used interchangeably. UMTS Universal Mobile Telecommunication Service UTRAN UMTS Terrestrial Radio Access Network Salkintzis Expires - June 2003 [Page 5] EAP GPRS Authentication December 2002 3. Protocol Architecture The general protocol architecture is illustrated in Figure 1 below. As shown, EAP-GPRS runs between a GPRS client and a back-end AAA server, referred to as GPRS AAA server. In this document, the GPRS AAA server is the network element that provides authentication and authorization services for the GPRS clients. EAP-GPRS uses an encapsulation scheme to provide to User Application (UA) entities connectivity services through network elements that enforce 802.1X access control. It also provides a negotiation mechanism with which the two EAP-GPRS peers can negotiate the particular type of UA that will be used in an EAP-GPRS transaction. In the example shown in Figure 1, the GPRS AAA server maintains two UAs (UA-A and UA-B) and therefore can establish EAP-GPRS transactions to GPRS clients supporting either of these UAs or both UAs. EAP-GPRS is not a link-layer protocol, in the sense that it does not provide services such as flow control, error detection / correction, etc. Therefore, it relies on UAs for providing such services. Also, EAP-GPRS does not provide security services such as encryption and/or integrity protection of UA messages. It is important to note that, since security services are provided by GPRS specific UAs, which are already implemented in the GPRS client and GPRS AAA server, there is no need to duplicate this functionality. In fact, EAP-GPRS aims to be a simple protocol that is easily implemented in clients with limited processing and memory resources. +-------+ +-------+ +-------+ +-------+ | UA-A | | UA-B | <------- User --------> | UA-A | | UA-B | +-------+ +-------+ Applications +-------+ +-------+ | | | | +Mode +Mode +Mode +Mode |A |B |A |B +-------------------+ +-------------------+ | EAP-GPRS | | EAP-GPRS | +-------------------+ +------------+ +-------------------+ | EAP | | EAP | | EAP | +-------------------+ +------------+ +-------------------+ | L2/L1 | | L2/L1 | | L2/L1 | +-------------------+ +------------+ +-------------------+ GPRS Client Access Point GPRS AAA Server Figure 1: General Protocol Architecture As shown in Figure 1, EAP-GPRS can support several modes of operation, each one corresponding to a specific type of User Application. For example, in a GPRS client supporting GPRS services Salkintzis Expires - June 2003 [Page 6] EAP GPRS Authentication December 2002 in Gb mode, a user application could be the LLC protocol (see 3GPP TS 04.64 [8]), which provides an unacknowledged transfer service to GMM, including detection of lost and duplicated messages, as well as encryption. On the other hand, in a GPRS client supporting GPRS services in Iu mode, a user application could be the RRC protocol (see 3GPP TS 25.331 [9]), which is also used to transport GMM messages. At the beginning of an EAP-GPRS transaction, the EAP-GPRS peers negotiate a common mode of operation (or type of UA), which will be subsequently used for transferring UA messages. This allows several modes of UA message transfer to be supported including e.g. LLC or RRC transfer mode. By supporting several transfer modes, EAP-GPRS effectively supports several types of data link technologies. Note: The use of GRPS protocols (such as LLC and RRC) in a WLAN radio network might raise several concerns and might call for protocol modifications and/or extensions. However, such concerns are outside the scope of this document. 4. Protocol Overview A simplified EAP-GPRS transaction is illustrated in Figure 2 below. The goal of this figure is to illustrate the general operational features of EAP-GPRS protocol and consequently it refrains from showing very specific details. Such details are discussed in section 6. As in other EAP schemes (see for example [10]), the flow is initiated by the authenticator, which requests the identity of the GPRS client by sending an EAP-Request with type=Identity (see [2]). In response, the GPRS client sends its identity within an EAP-Response message. Subsequently, the authenticator (and/or other elements in the access network) uses the reported identity in order to establish an AAA transaction with the appropriate GPRS AAA server, which will ultimately authenticate the GPRS client. The GPRS AAA server is an element that terminates the EAP-GPRS signaling and typically resides in the GPRS CN. Typically, the clientÆs identity is a NAI [11] in the form æusername@realmÆ. Note that in EAP-GPRS, the æusernameÆ part of NAI can be anything (e.g. a random username) because the real identity of the GPRS client is transmitted later within the GPRS specific messages exchanged during the EAP-GPRS transaction. In Figure 2 the EAP-GPRS transaction is represented as a dashed box. To accommodate roaming however the ærealmÆ part of NAI must be a valid realm. Salkintzis Expires - June 2003 [Page 7] EAP GPRS Authentication December 2002 GPRS Client Authenticator ----------- ------------- <- EAP-Request/Identity EAP-Response/Identity(NAI) -> +------------------------------------------------------------------+ | <- EAP-Request/EAP-GPRS/ | | Start Flag=1, End Flag=0 | | [GPRS message] | | EAP-Response/EAP-GPRS/ -> | | Start Flag=0, End Flag=0 | | GPRS message | | <- EAP-Request/EAP-GPRS/ | | Start Flag=0, End Flag=0 | | GPRS message | | EAP-Response/EAP-GPRS/ -> | | Start Flag=0, End Flag=0 | | GPRS message | | | | ------------------------------------------ | | | Other pairs of EAP-Request/Response | | | | with encapsulated GPRS messages | | | ------------------------------------------ | | | | <- EAP-Request/EAP-GPRS/ | | Start Flag=0, End Flag=0 | | GPRS message | | EAP-Response/EAP-GPRS/ -> | | Start Flag=0, End Flag=1 | | [GPRS message] | +------------------------------------------------------------------+ <- EAP-Success or EAP-Failure Figure 2: General structure of EAP-GPRS signaling flows. After the first two messages, an EAP-GPRS transaction starts when the authenticator sends an EAP-GPRS packet with the START flag set to æ1Æ (see section 5). After that a GPRS dialogue begins wherein a sequence of GPRS messages (or more correctly UA messages) encapsulated into EAP-GPRS messages are exchanged. These messages are typically GPRS Mobility Management (GMM) messages (specified in [6]) and are transparent to EAP-GPRS. The EAP-GPRS transaction terminates when the GPRS client sends an EAP-GPRS message with an END flag set to æ1Æ (see section 5). This message enforces the termination of EAP-GPRS and the authenticator subsequently sends either an EAP-Success or an EAP-Failure based on the outcome of embedded GPRS mobility management procedure. For example, when the client was able to successfully attach/handover to the GPRS CN, an EAP-Success message is sent. Salkintzis Expires - June 2003 [Page 8] EAP GPRS Authentication December 2002 As seen above, an EAP-GPRS transaction is always started by the authenticator side (more precisely, by the GPRS AAA server) with an EAP-GPRS message that includes a START flag equal to æ1Æ, and is always terminated by the GPRS client with an EAP-GPRS message that includes an END flag equal to æ1Æ. 4.1 Protocol Services EAP-GPRS provides the following services: - Initiation and termination of a GPRS dialogue that takes place in the context of an 802.1X access control procedure. - Negotiation of the transfer mode (or user application) that will be used for the GPRS dialogue. For simplicity, this negotiation was not discussed in section 4. It is discussed however in section 6 below. - Encapsulation of UA messages into packets that can pass through network elements, which enforce 802.1X access control. - Point-to-point transfer of UA messages between two EAP-GPRS peers. This transfer service does not provide any kind of error detection, error correction, flow control, identification of lost and duplicated messages, etc. Such services are assumed to be provided by a user application. In a typical usage scenario, UA messages can be GPRS LLC frames, which in turn include GPRS mobility management messages. Salkintzis Expires - June 2003 [Page 9] EAP GPRS Authentication December 2002 5. Packet Format As an extension of EAP, the EAP-GPRS protocol complies with the general EAP packet format specified in [2]. EAP-GPRS packets are identified by a specific Type field in every EAP Request/Response and have the format indicated 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 |S|E| Mode | Reserved | | | |F|F| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | [UA-Payload] | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code, Identifier, Length See [2]. In EAP-GPRS messages the Code field MUST either be Request or Response. Type One octet identifier that corresponds to EAP-GPRS. A particular value will have to be assigned by IANA (see section 8). Subtype One octet value that indicates the particular EAP-GPRS message type as follows: 1 --> NULL 2 --> UA-Message SF (1 bit) The START Flag. This flag is used to initiate an EAP-GPRS transaction. EF (1 bit) The END Flag. This flag is used to terminate an EAP-GPRS transaction. Mode (3 bits) When the START flag is set to æ1Æ, the Mode field indicates all the types of UAs supported by the sender EAP-GPRS entity. When the START flag is set to æ0Æ, the Mode field MUST indicate only Salkintzis Expires - June 2003 [Page 10] EAP GPRS Authentication December 2002 one UA, which is the recipient/sender of the corresponding UA message. UA-Payload The UA-Payload field contains a UA message that MUST transparently be exchanged between two peer UA entities. When the Subtype field indicates NULL, the UA-Payload MUST NOT be included in the packet. 6. Detailed Protocol Description An EAP-GPRS transaction is composed of a UA Dialogue phase, in which UA messages are exchanged between the two EAP-GRPS peers, and the UA Dialogue Initiation and Termination phases. These phases are thoroughly discussed in the following subsections. 6.1 UA Dialogue Initiation An EAP-GPRS protocol transaction MUST be started by the GPRS AAA server upon receiving a new AAA access request message (e.g. from an access point). The GPRS AAA server MUST NOT check the username in the clientÆs NAI as this username MAY be selected arbitrarily. As explained before, the GPRS identity of the GPRS client is included later in a GPRS message. Since EAP-GPRS does not perform authentication, it does not need to have visibility on the clientÆs GPRS identity. This identity is visible to higher layer protocols. The fist EAP-GPRS packet sent by the GPRS AAA server MUST have the START flag set to æ1Æ. For convenience, we use the term æstarting EAP-GPRSÆ packet to refer to such a packet, i.e. with the START flag set to æ1Æ. If appropriate, a starting EAP-GPRS packet MAY contain a UA-message. In this case, the Subtype field MUST be UA-Payload; otherwise it MUST be NULL. For example, when the GPRS AAA server wants to start the UA dialogue, it may send a starting EAP-GRPS packet that contains a GMM message with type Identity-Request (see [6]) for requesting the GPRS client to report the required GPRS identity. A GPRS client MUST always set the START flag to æ0Æ in all outgoing EAP-GPRS packets. The GPRS client checks the value of START flag in all incoming EAP-GPRS packets and MUST NOT send an EAP-GPRS packet with an encapsulated UA message unless it has received a starting EAP-GPRS packet. The Mode field is used to negotiate a particular UA that will be used in the subsequent UA dialogue. In a starting EAP-GPRS packet the Mode field indicates all the UA types supported by the GPRS AAA server. This is accomplished by performing a logical OR operation across all Salkintzis Expires - June 2003 [Page 11] EAP GPRS Authentication December 2002 code-points that correspond to all supported UA types. The mapping between these code-points and the UA types is as follows: Code-Point UA Type ---------- ------- 0001 LLC 0010 RRC 0100 Reserved 1000 Reserved So far, only the first two code-points are valid and may be used. The last two code-points are reserved for future use and SHOULD NOT be used by the GPRS AAA server. A GPRS client MUST ignore the reserved code-points. As an example, when the GPRS AAA server supports both LLC and RRC UA types, it SHOULD encode the Mode field in a starting EAP-GPRS packet as æ0011Æ. Alternatively, the GPRS AAA server may wishes to use only the LLC mode of operation and in this case it MUST encode the Mode field as æ0001Æ. Note: Although in this document we focus particularly on GPRS- specific UAs, EAP-GPRS could also support non GPRS-specific UAs. This would allow non GPRS-specific dialogues to be carried out in the context of 802.1X. 6.2 UA Dialogue After receiving a starting EAP-GPRS packet the GPRS client MUST check the Mode field and identify the common UA types (those supported in both the GPRS client and the GPRS AAA server). In doing so, the GPRS client MUST ignore the code-points of reserved UAs. If no common UA types are identified, the GPRS client MUST close the EAP-GPRS transaction by sending a closing EAP-GPRS packet, i.e. a packet with the END flag set to æ1Æ. In this case, the GPRS client MUST encode the Mode field such as to indicate all UA types it supports. Such encoding is performed again by a logical OR operation across all the code-points corresponding to all UA types supported by the GPRS client. If one or more common UA types are identified, the GPRS client selects a preferred common UA type and includes the code-point corresponding to this UA type in all subsequent outgoing EAP-GPRS packets. When the GPRS AAA server receives the first EAP-GPRS packet from the GPRS client, it records the value of Mode field and MUST use it in all subsequent outgoing EAP-GPRS packets. Therefore, after a starting EAP-GPRS packet and before a closing EAP-GPRS packet, all EAP-GPRS packets MUST have the START and the END flag set to æ0Æ and Salkintzis Expires - June 2003 [Page 12] EAP GPRS Authentication December 2002 the Mode field set to the preferred common code-point value selected by the GPRS client as discussed above. Each EAP-GRPS packet sent by the GPRS client that does not have the END flag equal to æ1Æ MUST be of subtype UA-Payload and therefore MUST contain a UA message. Similarly, each EAP-GRPS packet sent by the GPRS AAA server that has neither the START flag nor the END flag equal to æ1Æ MUST be of subtype UA-Payload and therefore MUST contain a UA message. The contents of UA messages are not inspected by EAP- GPRS entities and depend on the protocol specifications of the corresponding UA entities. During the UA Dialogue phase the EAP-GPRS protocol provides an unreliable UA message transfer mechanism that can pass through network elements, which enforce 802.1X access control. UA messages are exchanged between the UA peers in the GPRS client and the GPRS AAA server. As explain above, EAP-GPRS aims to be a simple protocol and does not provide any error detection, error recovery, flow control or similar data transfer mechanisms. When such data transfer mechanisms are required they must be supported by a UA. Given that GPRS operation in both Gb and Iu mode implements protocols that provide such mechanisms, there was no need for EAP-GPRS to duplicate them. 6.3 UA Dialogue Termination The GPRS message transfer can be terminated either by the GPRS client or the GPRS AAA server by transmitting a closing EAP-GPRS packet (with the END flag set to æ1Æ). Such a closing packet MAY include a UA message. The transmission of a closing EAP-GPRS packet terminates the EAP-GPRS transaction (the dashed box in Figure 1) and triggers the transmission of either an EAP-Success or EAP-Failure packet from the GPRS AAA server based on the outcome of the corresponding UA dialogue. 7. Examples In this section we further explain the operation of EAP-GPRS by means of some typical usage scenarios. It is noted that although the examples focus on the GPRS Attach procedure, similar examples can be illustrated for the Routing Area Update procedure. In the following discussion we mainly discuss the EAP-GPRS aspects and we do not get into the details of the embedded GPRS procedures. These procedures are only roughly discussed in order to enhance the clarity and make the presentation more complete. The few GPRS parameters shown in each GPRS message (included in parentheses) are also used to enhance the Salkintzis Expires - June 2003 [Page 13] EAP GPRS Authentication December 2002 clarity of the presentation. The reader should not infer that these are the only GPRS parameters that may be included in the GPRS message. More details about the GPRS procedures and the GPRS mobility management messages and parameters can be found in 3GPP TS 23.060 [5] and 3GPP TS 24.008 [6]. For simplicity we only show the message exchange between the GPRS client and the authenticator. We note however that all downlink EAP- GPRS packets originate from the GPRS AAA server and are simply relayed by the authenticator. The first example, illustrated in Figure 3 below, is a case where the GPRS client powers up in a WLAN area, successfully attaches to the GPRS CN and is assigned a new P-TMSI value. GPRS Client Authenticator ----------- ------------- <- EAP-Request/Identity EAP-Response/Identity(NAI) -> <- EAP-Request/EAP-GPRS/ SF=1,EF=0,Mode=0011,NULL EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001, UA-Payload(GPRS-Attach-Request (P-TMSI, P-TMSI Signature)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Request (RAND)) EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Response (SRES)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0, Mode=0001 UA-Payload(GPRS-Attach-Accept (nP-TMSI, nP-TMSI Signature)) EAP-Response/EAP-GPRS/ -> SF=0,EF=1,Mode=0001 UA-Payload(GPRS-Attach-Complete (nP-TMSI)) <- EAP-Success Figure 3: Successful GPRS Attach with assignment of new P-TMSI. The EAP-GPRS transaction begins with a starting EAP-GPRS packet, which carries no UA message and indicates that the GPRS AAA server Salkintzis Expires - June 2003 [Page 14] EAP GPRS Authentication December 2002 supports both LLC and RRC modes of operation (Mode=Æ0011Æ). After receiving the starting EAP-GPRS packet the GPRS client sends an EAP- GPRS packet, which indicates the selected mode as æ0001Æ (LLC) and includes an LLC frame (in the UA-Payload field) that contains a GPRS- Attach-Request message. This message includes the GPRS temporary identity of the GPRS client (P-TMSI) as well as the associated P-TMSI Signature (see section 2). After receiving the GPRS-Attach-Request the GPRS AAA server decides to authenticate the GPRS client and consequently it transmits an EAP-GPRS packet with an encapsulated GPRS-Authentication & Ciphering-Request message. This EAP-GPRS packet as well as all the rest EAP-GPRS packets contain a Mode field equal to æ0001Æ (LLC), which represents the negotiated UA entity. The fact that the GPRS-Authentication & Ciphering-Request message includes only a random challenge parameter (RAND) means that the GPRS AAA serve chose to perform a GSM authentication (as opposed to a UMTS authentication, which requires an additional parameter for GPRS CN authentication). In this case, the GPRS client runs the GSM authentication algorithm, generates a challenge response (SRES) and responds with an EAP-GPRS packet that encapsulates a GPRS- Authentication & Ciphering-Request message. Based on the value of SRES the GPRS AAA server determines that the GPRS client is a legitimate client and accepts its attach request by transmitting an EAP-GPRS packet with a GPRS-Attach-Accept message encapsulated in the UA-Payload field. With this message the GPRS AAA server also assigns a new GPRS temporary identity (nP-TMSI) and an associated signature (nP-TMSI Signature). Subsequently, the GPRS client sends another EAP- GPRS packet with an encapsulated GPRS-Attach-Complete message in order to acknowledge the reception of the new P-TMSI value. Since this GPRS message is the last one in the GPRS dialogue, the GPRS client also sets the END flag to æ1Æ in order to terminate the EAP- GPRS transaction. In response, the GPRS AAA server sends an EAP- Success packet to indicate to the successful termination on EAP authentication. This EAP-Success packet is relayed by the authenticator. Salkintzis Expires - June 2003 [Page 15] EAP GPRS Authentication December 2002 The example illustrated in Figure 4 below corresponds again to a case where the GPRS client successfully attaches to the GPRS CN. However, in this case the GPRS client is assigned no new P-TMSI value and therefore it does not need to send the GPRS-Attach-Complete message. For this reason, the closing EAP-GPRS packet does not include a UA- Payload field. GPRS Client Authenticator ----------- ------------- <- EAP-Request/Identity EAP-Response/Identity(NAI) -> <- EAP-Request/EAP-GPRS/ SF=1,EF=0,Mode=0011,NULL EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001, UA-Payload(GPRS-Attach-Request (P-TMSI, P-TMSI Signature)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Request (RAND)) EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Response (SRES)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0, Mode=0001 UA-Payload(GPRS-Attach-Accept) EAP-Response/EAP-GPRS/ -> SF=0,EF=1,Mode=0001,NULL <- EAP-Success Figure 4: Successful GPRS Attach without assignment of new P-TMSI. Salkintzis Expires - June 2003 [Page 16] EAP GPRS Authentication December 2002 In Figure 5 we show an unsuccessful GPRS attach, which leads to an unsuccessful EAP authentication procedure. In this example, the GPRS client failed to authenticate successfully with the GPRS AAA server and therefore the GPRS AAA server sends a GPRS-Attach-Reject message. As usually, the EAP-GPRS dialogue terminates with a closing EAP-GPRS packet from the GPRS client with Subtype equal to NULL. GPRS Client Authenticator ----------- ------------- <- EAP-Request/Identity EAP-Response/Identity(NAI) -> <- EAP-Request/EAP-GPRS/ SF=1,EF=0,Mode=0011,NULL EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001, UA-Payload(GPRS-Attach-Request (P-TMSI, P-TMSI Signature)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Request (RAND)) EAP-Response/EAP-GPRS/ -> SF=0,EF=0,Mode=0001 UA-Payload(GPRS-A&C-Response (SRES)) <- EAP-Request/EAP-GPRS/ SF=0,EF=0, Mode=0001 UA-Payload(GPRS-Attach-Reject) EAP-Response/EAP-GPRS/ -> SF=0,EF=1,Mode=0001,NULL <- EAP-Failure Figure 5: Unsuccessful GPRS Attach. Salkintzis Expires - June 2003 [Page 17] EAP GPRS Authentication December 2002 The last example shown in Figure 6 is a case where the GPRS client and GPRS AAA server fail to negotiate a common UA. In this case, the starting EAP-GPRS packet contains a Mode field equal to æ0010Æ indicating that the GPRS AAA server supports only the RRC UA. The GPRS client supports only the LLC UA and therefore responds with a closing EAP-GPRS packet with a Mode field equal to æ0001Æ. After that the EAP dialogue terminates unsuccessfully. GPRS Client Authenticator ----------- ------------- <- EAP-Request/Identity EAP-Response/Identity(NAI) -> <- EAP-Request/EAP-GPRS/ SF=1,EF=0,Mode=0010,NULL EAP-Response/EAP-GPRS/ -> SF=0,EF=1,Mode=0001,NULL <- EAP-Failure Figure 6: UA Negotiation Failure. 8. IANA Considerations A specific EAP Type value will have to be assigned by IANA for the EAP-GPRS protocol. EAP-GPRS messages include a Subtype field with the following values assigned: NULL............................................1 UA-Payload......................................2 All requests for value assignment from the various number spaces described in this document require proper documentation, according to the "Specification Required" policy described in [12]. Requests must be specified in sufficient detail so that interoperability between independent implementations is possible. Possible forms of documentation include, but are not limited to, RFCs, the products of another standards body (e.g. 3GPP), or permanently and readily available vendor design notes. 9. Security Considerations As mentioned above, EAP-GPRS is not an authentication protocol and therefore does not need to know the GPRS clientÆs identity. This makes it possible to use e.g. a random username in the NAI that is Salkintzis Expires - June 2003 [Page 18] EAP GPRS Authentication December 2002 included in the EAP-Response/Identity packet. This way EAP-GPRS does not disclose the userÆs identity. As also mentioned above, EAP-GPRS does not provide any security mechanisms because it was specified for GPRS clients, which already support GPRS protocols with security features. EAP-GPRS relies on these protocols (or UAs) for the provision of security, and serves mainly as an encapsulation scheme. UA entities in the GPRS AAA server are assumed to be trusted entities. The negotiation feature of EAP-GPRS ensures that a trusted UA in the GPRS AAA server is always involved in an embedded GPRS dialogue and therefore all GPRS clientÆs messages are handled by a trusted UA entity. In general, since EAP-GPRS provides mainly an encapsulation mechanism, it is expected that the EAP-GPRS based access control procedures inherit the security features of the associated UAs. 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Blunk, L. and J. Vollbrecht, ôPPP Extensible Authentication Protocol (EAP)ö, RFC 2284, March 1998. 3 IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5 3GPP Technical Specification 3GPP TS 23.060 v3.13.0: ôGeneral Packet Radio Service (GPRS); Service Description; Stage 2 (Release 1999)ö, 3rd Generation Partnership Project, September 2002 (NORMATIVE) 6 3GPP Technical Specification 3GPP TS 24.008 v3.13.0: ôMobile radio interface layer 3 specification; Core network protocols û stage 3 (Release 1999)ö, 3rd Generation Partnership Project, September 2002 (NORMATIVE) 7 Salkintzis, A. et al., ôWLAN-GPRS Integration for Next Generation Mobile Data Networks,ö IEEE Wireless Communications, vol. 9, no. 5, pp. 112-124, Oct. 2002. 8 3GPP Technical Specification 3GPP TS 04.64 v8.7.0: ôMobile Station û Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) layer specification (Release 1999)ö, 3rd Generation Partnership Project, December 2001 (NORMATIVE) Salkintzis Expires - June 2003 [Page 19] EAP GPRS Authentication December 2002 9 3GPP Technical Specification 3GPP TS 25.331 v3.12.0: ôRadio Resource Control (RRC); Protocol specification (Release 1999)ö, 3rd Generation Partnership Project, September 2002 (NORMATIVE) 10 Aboba, B. and D. Simon, ôPPP EAP TLS Authentication Protocolö, RFC 2716, October 1999. (EXPERIMENTAL) 11 Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. (NORMATIVE) 12 T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. (NORMATIVE) Acknowledgments The author would like to thank all colleagues who supported this work and provided valuable review comments. Author's Addresses Apostolis K. Salkintzis Motorola 32 Kifissias Av., Athens, GR-15125 Greece Phone: +30-210-8172335 Email: salki@motorola.com 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 Salkintzis Expires - June 2003 [Page 20] EAP GPRS Authentication December 2002 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. Notice Regarding Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Salkintzis Expires - June 2003 [Page 21]