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]