Point-to-Point Extensions Working Group H. Haverinen
Internet Draft Nokia
February 2001
EAP SIM Authentication (Version 1)
draft-haverinen-pppext-eap-sim-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.
This document is an individual submission for the Point-to-Point
Extensions Working Group of the Internet Engineering Task Force
(IETF). Comments should be submitted to the ietf-ppp@merit.edu
mailing list.
Distribution of this memo is unlimited.
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the
GSM Subscriber Identity Module (SIM).
Haverinen Expires August 2001 [Page 1]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Table of Contents
Status of this Memo.........................................1
Abstract....................................................1
Table of Contents...........................................2
1. Introduction.............................................2
2. Terms....................................................2
3. Overview.................................................3
4. EAP-Response/Identity....................................5
5. EAP-Request/SIM/Start....................................6
6. EAP-Response/SIM/Start...................................7
7. EAP-Request/SIM/Challenge................................8
8. EAP-Response/SIM/Challenge...............................9
9. Unsuccessful Cases......................................10
9.1. EAP-Response/SIM/Unknown-Subtype......................11
9.2. EAP-Response/SIM/Unsupported-Version..................12
9.3. Other Failures on EAP/SIM Client......................13
10. Calculation of Cryptographic Values....................13
11. IANA Considerations....................................13
12. Security Considerations................................13
13. Intellectual Property Right Notice.....................14
14. Acknowledgements.......................................14
References.................................................14
Author's Address...........................................14
1. Introduction
This document specifies an Extensible Authentication Protocol (EAP)
[1] mechanism for authentication and session key distribution using
the GSM Subscriber Identity Module (SIM).
GSM authentication is 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 an operator-
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.
Please find more information about GSM authentication in [2].
In EAP/SIM, several RAND challenges are used for generating several
64-bit Kc keys, which are combined to constitute a longer session
key. EAP/SIM also enhances the basic GSM authentication mechanism by
accompanying the RAND challenges with a message authentication code
in order to provide mutual authentication.
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].
Haverinen Expires August 2001 [Page 2]
Internet Draft EAP SIM Authentication (Version 1) February 2001
This document frequently uses the following terms and abbreviations:
AAA protocol
Authentication, Authorization and Accounting protocol, such as
RADIUS or DIAMETER.
AAA server
In this document, AAA server refers to the network element that
resides on the border of Internet AAA network and GSM network.
AuC
Authentication Centre. The GSM network element that can authorize
the subscriber.
EAP
Extensible Authentication Protocol.
GSM
Global System for Mobile communications.
IMSI
International Mobile Subscriber Identifier, used in GSM to
identify subscribers.
NAI
Network Access Identifier
SIM
Subscriber Identity Module. SIM cards are smart cards distributed
by GSM operators.
3. Overview
Figure 1 shows an overview of the EAP/SIM authentication procedure.
This version of EAP/SIM exchange uses three roundtrips to authorize
the user and generate a session key. The Authenticator typically
communicates with the user's AAA server using an AAA protocol. The
AAA communications is not shown in the figure.
The first EAP Request issued by the Authenticator is EAP-
Request/Identity. The clients response includes the user's
International Mobile Subscriber Identity (IMSI) (Section 4).
Following the client's EAP-Response/Identity packet, the client
receives EAP Requests of type 18 (SIM) from the Authenticator and
Haverinen Expires August 2001 [Page 3]
Internet Draft EAP SIM Authentication (Version 1) February 2001
sends the corresponding EAP Responses. The EAP packets that are of
the Type SIM also have a Subtype field. The first EAP-Request/SIM
packet is of the Subtype 1 (Start). This packet contains the list of
EAP/SIM protocol version numbers supported by the AAA server. The
client's response (EAP-Response/SIM/Start) contains the version
number selected by the client. The client must select one of the
versions from the EAP Request. The EAP-Response/SIM/Start packet
also contains the client's key lifetime proposal and a random number
NONCE_MT, picked up by the client. All subsequent EAP Request and
Response packets contain the same version as the client's EAP-
Response/SIM/Start packet. This document describes the EAP/SIM
protocol version 1.
In this document, we assume that the AAA server has an interface to
the GSM network and it operates as a gateway between the Internet
AAA network and the GSM authentication infrastructure. After
receiving the EAP Response/SIM/Start, the AAA server obtains n GSM
triplets from the user's home operator's Authentication Centre (AuC)
on the GSM network. From the triplets, the AAA server derives
MAC_RAND and the session key. Section 10 specifies how these
cryptographic values are calculated.
The next EAP Request the Authenticator issues is of the type SIM and
subtype Challenge. It contains the RAND challenges, the key lifetime
decided by the AAA Server, and a message authentication code for the
challenges and the lifetime (MAC_RAND). On receipt of this message,
the client runs the GSM authentication algorithm on the SIM card and
calculates a copy of MAC_RAND. The client then verifies that the
calculated MAC_RAND equals the received MAC_RAND. If the MAC_RAND's
do not match, then the client cancels the authentication procedure
and does not send any authentication values calculated on the SIM to
the network.
Since the RAND's given to a client are accompanied with the message
authentication code MAC_RAND, the client is able to verify that the
RAND's are fresh and they have been generated by the GSM network.
If all checks out, the client responds with the EAP-
Response/SIM/Challenge, containing the client's response MAC_SRES
(Section 10). The AAA server verifies that the MAC_SRES is correct
and sends the EAP-Success packet, indicating that the authentication
was successful. The AAA server may also include the derived session
key in the message it sends to the Authenticator.
In the following sections, we discuss the EAP/SIM authentication and
key distribution mechanism in detail.
Haverinen Expires August 2001 [Page 4]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Client Authenticator
| |
| EAP-Request/Identity |
|<---------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's IMSI) |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Start |
| (Supported versions) |
|<---------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (Version, NONCE_MT, Key lifetime proposal) |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Challenge |
| (Version, n*RAND, MAC_RAND, Key lifetime) |
|<---------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs GSM algorithms on SIM, | |
| verifies MAC_RAND, derives MAC_SRES | |
| and session key | |
+-------------------------------------+ |
| |
| EAP-Response/SIM/Challenge |
| (Version, MAC_SRES) |
|--------------------------------------------------------->|
| |
| |
| EAP-Success |
|<---------------------------------------------------------|
| |
Figure 1 EAP/GSM SIM authentication procedure
4. EAP-Response/Identity
In the beginning of EAP authentication, the Authenticator issues the
EAP-Request/Identity packet to the client. The client responds with
EAP-Response/Identity, which contains the user's identity. The
formats of these packets are specified in [1].
GSM subscribers are identified with the International Mobile
Subscriber Identity (IMSI) [4]. The IMSI is composed of a three
digit Mobile Country Code (MCC), a two 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.
Haverinen Expires August 2001 [Page 5]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Internet AAA protocols identify users with the Network Access
Identifier (NAI) [5]. When used in a roaming environment, the NAI is
composed of a username and a realm, separated with "@". The username
portion identifies the subscriber within the realm. The AAA nodes
use the realm portion of the NAI to route AAA requests to the
correct AAA server.
With EAP/SIM, the client transmits the user's IMSI as a NAI in the
EAP Response/Identity packet. When the IMSI is encoded as a NAI, the
username portion of the NAI contains the IMSI as a string of digits,
and the realm portion identifies the AAA server. The AAA network
routes the AAA request to the correct AAA server using the realm
part of the NAI.
5. EAP-Request/SIM/Start
In EAP/SIM Version 1, the first SIM specific EAP Request is of
subtype Start. The EAP Request/SIM/Start packet contains a list of
EAP/SIM versions supported by the AAA server. The format of the EAP
Request/SIM/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 Count | Version 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..............................................| Version N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Request
Identifier
See [1].
Length
7 + value of Version Count field (number of supported protocol
versions)
Type
18
Subtype
1
Haverinen Expires August 2001 [Page 6]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Version Count
Number of EAP/SIM versions supported by the AAA server. The
supported versions are listed following this field. Version 1 is
the protocol version described in this document.
Version1...Version N
The EAP/SIM versions supported by the AAA Server. Version 1 is
the version described in this document.
6. EAP-Response/SIM/Start
The format of the EAP Response/SIM/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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime Proposal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| NONCE_MT |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 for Response
Identifier
See [1].
Length
28
Type
18
Subtype
1
Haverinen Expires August 2001 [Page 7]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Version
1 (The EAP/SIM version the client is using.)
Reserved
Set to zero when sending, ignored on reception.
Key Lifetime Proposal
Client's key lifetime proposal in seconds (four bytes).
NONCE_MT
A random number generated by the client (16 bytes), which is used
as a seed value for the new key.
7. EAP-Request/SIM/Challenge
The format of the EAP-Request/SIM/Challenge 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| MAC_RAND |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n*RAND ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Request
Identifier
See [1]
Haverinen Expires August 2001 [Page 8]
Internet Draft EAP SIM Authentication (Version 1) February 2001
Length
The length of the EAP Request packet. 28 + n*16 bytes, where n is
the number of RAND challenges given in this EAP Request.
Type
18
Version
1 (the EAP/SIM protocol version)
Subtype
2
Reserved
Set to zero when sending, ignored on reception.
Key lifetime
Remaining key lifetime in seconds (4 bytes), decided by the AAA
Server. The AAA Server may, but it doesn't have to, take into
account the client's key lifetime proposal from EAP-
Response/GSMSIM/Start. The key lifetime must be greater than
zero.
MAC_RAND
A message authentication code for n*RAND and Key Lifetime
(Section 10), 16 bytes.
N*RAND
N GSM RANDs (length n *16 bytes)
8. EAP-Response/SIM/Challenge
The format of the EAP-Response/SIM/Challenge packet is shown below.
Haverinen Expires August 2001 [Page 9]
Internet Draft EAP SIM Authentication (Version 1) February 2001
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| MAC_SRES |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 for Response
Identifier
See [1].
Length
40 bytes
Type
18
Version
1 (the EAP/SIM version)
Subtype
2
Reserved
Set to zero when sending, ignored on reception.
MAC_SRES
The response calculated by the client (Section 10), 16 bytes.
9. Unsuccessful Cases
As normally in EAP, the client is sent the EAP-Failure packet when
the authentication procedure fails on the AAA Server. In EAP/SIM,
Haverinen Expires August 2001 [Page 10]
Internet Draft EAP SIM Authentication (Version 1) February 2001
this may occur for example if the AAA server is not able to obtain
the GSM triplets for the subscriber or the AAA server receives an
incorrect MAC_SRES.
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.
Following subsections describe EAP/SIM specific operations on error
cases.
9.1. EAP-Response/SIM/Unknown-Subtype
If the client receives an EAP Request packet of the type SIM with a
subtype that it does not recognize, the client MUST sends the EAP-
Response/SIM/Unknown-Subtype packet shown below. The Authenticator
(or the AAA server) MAY then proceed with other EAP Requests or it
MAY send an EAP-Failure packet.
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 |Unknown Subtype|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 for Response
Identifier
See [1].
Length
7 + value of Supported Subtype Count (number of supported EAP-
Request/SIM subtypes)
Type
18
Subtype
3
Unknown Subtype
The subtype of the EAP Request that was not recognized by this
client.
Haverinen Expires August 2001 [Page 11]
Internet Draft EAP SIM Authentication (Version 1) February 2001
9.2. EAP-Response/SIM/Unsupported-Version
If the client receives an EAP Request packet of the type SIM and a
subtype that it recognizes, but with a version that it does not
support, then the client MUST sends the EAP-
Response/SIM/Unsupported-Version packet shown below. The
Authenticator (or the AAA server) MAY then proceed with other EAP
Requests or it MAY send an EAP-Failure packet.
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 Count | Version 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..............................................| Version N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
2 for Response
Identifier
See [1].
Length
7 + value of Version Count field (number of supported protocol
versions)
Type
18
Subtype
4
Version Count
Number of EAP/SIM versions supported by the client. The supported
versions are listed following this field. Version 1 is the
protocol version described in this document.
Version1...Version N
The EAP/SIM versions supported by the client. Version 1 is the
version described in this document.
Haverinen Expires August 2001 [Page 12]
Internet Draft EAP SIM Authentication (Version 1) February 2001
9.3. Other Failures on EAP/SIM Client
If some other error besides the ones listed above occurs on the
client, then the client does not send EAP messages to the network
but simply cancels the authentication procedure. An example of such
an error is an invalid MAC_RAND value in the EAP-
Request/SIM/Challenge packet.
10. Calculation of Cryptographic Values
This section specifies how the SIM-generated session key K and the
message authentication codes MAC_RAND and MAC_SRES are calculated.
In the formulae, the notation PRF(key, msg) denotes the keyed
pseudo-random function used to generate a deterministic output that
appears pseudo-random. The PRF() is used both for key derivations
and for authentication (i.e. as a keyed MAC). With EAP/SIM version
1, the PRF() is HMAC-MD5 [6].
K
PRF(n*Kc, n*RAND | IMSI | NONCE_MT)
MAC_RAND
PRF(n*Kc, n*RAND | NONCE_MT | key lifetime)
MAC_SRES
PRF(n*Kc, n*SRES | IMSI | NONCE_MT)
When generating the key K, the PRF is used as a mixing function to
combine several session keys (Kc's) generated by the GSM
authentication procedure and the random number NONCE_MT into a
single session key. There are several reasons for this. The current
GSM session keys are at most 64 bits, so two or more of them are
needed to generate a 128-bit key. By using a one-way function to
combine the keys, we are assured that even if an attacker manages to
learn the EAP/SIM session key, it doesn't help him in learning the
original GSM Kc's. In addition, since we include the random number
NONCE_MT in the calculation, the client is able to verify that the
SIM authentication values it receives from the network are fresh and
not a replay.
11. IANA Considerations
IANA has assigned the EAP type number 18 for EAP/SIM authentication.
12. Security Considerations
The protocol in this document is intended to provide the appropriate
level of security to operate Extensible Authentication Protocol
using the GSM SIM.
Haverinen Expires August 2001 [Page 13]
Internet Draft EAP SIM Authentication (Version 1) February 2001
13. Intellectual Property Right Notice
On IPR related issues, Nokia refers to the Nokia Statement on Patent
licensing, see http://www.ietf.org/ietf/IPR/NOKIA.
14. Acknowledgements
The following people have contributed ideas in this protocol: Juha
Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-Pekka
Honkanen, Antti Kuikka, Jukka Latva, Jyri Rinnemaa, Timo Takam„ki
and Raimo Vuonnala.
References
[1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998
[2] 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
[3] S. Bradner, "Key words for use in RFCs to indicate Requirement
Levels", RFC 2119, March 1997.
[4] 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
[5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[6] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC2104, February 1997
Author's Address
Henry Haverinen
Nokia Mobile Phones
P.O. Box 88
FIN-33721 Tampere
Finland
E-mail: henry.haverinen@nokia.com
Phone: +358 50 594 4899
Fax: +358 3 318 3690
Haverinen Expires August 2001 [Page 14]
