📄 draft-haverinen-pppext-eap-sim-05.txt
字号:
Point-to-Point Extensions Working Group H. Haverinen (editor)
Internet Draft Nokia
June 2002
EAP SIM Authentication
draft-haverinen-pppext-eap-sim-05.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). The mechanism specifies
enhancements to GSM authentication and key agreement whereby
multiple authentication triplets can be combined to create
authentication responses and encryption keys of greater strength
than the individual GSM triplets. The mechanism also includes
network authentication.
Haverinen Expires in six months [Page 1]
Internet Draft EAP SIM Authentication June 2002
Table of Contents
Status of this Memo.........................................1
Abstract....................................................1
Table of Contents...........................................2
1. Introduction.............................................2
2. Terms....................................................3
3. Overview.................................................4
4. Obtaining Subscriber Identity via EAP/SIM Messages.......5
5. Identity Privacy Support.................................6
6. Message Format...........................................9
7. Message Integrity and Privacy Protection................11
7.1. AT_MAC Attribute......................................11
7.2. AT_IV and AT_ENCR_DATA Attributes.....................11
8. EAP-Response/Identity...................................12
9. EAP-Request/SIM/Start...................................14
10. EAP-Response/SIM/Start.................................15
11. EAP-Request/SIM/Challenge..............................17
12. EAP-Response/SIM/Challenge.............................19
13. Unsuccessful Cases.....................................21
14. EAP/SIM Notifications..................................21
15. Calculation of Cryptographic Values....................23
16. IANA Considerations....................................25
17. Security Considerations................................26
18. Intellectual Property Right Notice.....................27
19. Acknowledgements and Contributions.....................27
References.................................................27
Editor's Address...........................................29
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.
EAP/SIM specifies optional support for protecting the privacy of
subscriber identity.
Haverinen Expires in six months [Page 2]
Internet Draft EAP SIM Authentication June 2002
2. Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
This document frequently uses the following terms and abbreviations:
AAA protocol
Authentication, Authorization and Accounting protocol
AAA server
In this document, AAA server refers to the network element that
resides on the border of Internet AAA network and GSM network.
Cf. EAP server
AuC
Authentication Centre. The GSM network element that can
authenticate the subscriber.
EAP
Extensible Authentication Protocol.
EAP Server
The network element that terminates the EAP protocol. Typically,
the EAP server functionality is implemented in a AAA server.
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. The SIM is an application
traditionally resident on smart cards distributed by GSM
operators.
Haverinen Expires in six months [Page 3]
Internet Draft EAP SIM Authentication June 2002
3. Overview
Figure 1 shows an overview of the EAP/SIM authentication procedure.
This version of EAP/SIM exchange uses three roundtrips to
authenticate the user and generate session keys. In this document,
the term EAP Server refers to the network element that terminates
the EAP protocol. The Authenticator typically communicates with the
user's EAP 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 either the user's
International Mobile Subscriber Identity (IMSI) or a temporary
identity (pseudonym), as specified in Section 8.
Following the client's EAP-Response/Identity packet, the client
receives EAP Requests of type 18 (SIM) from the Authenticator and
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 10 (Start). Usually this packet contains no
attributes. (However, see Section 5 for an exception.) The client
responds with the EAP-Response/SIM/Start packet, which includes the
AT_NONCE_MT attribute that contains a random number NONCE_MT, chosen
by the client. The client MUST NOT reuse the NONCE_MT value from
previous sessions but the client MUST choose it freshly for each
EAP/SIM authentication exchange. The client SHOULD use a good source
of randomness to generate NONCE_MT.
In this document, we assume that the EAP 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 EAP server obtains n GSM
triplets from the user's home operator's Authentication Centre (AuC)
on the GSM network, where n = 2 or n = 3. From the triplets, the EAP
server derives the keying material. Section 15 specifies how these
cryptographic values are calculated.
The next EAP Request the Authenticator issues is of the type SIM and
subtype Challenge (11). It contains the RAND challenges and a
message authentication code attribute AT_MAC to cover the
challenges. On receipt of this message, the client runs the GSM
authentication algorithm and calculates a copy of the message
authentication code. The client then verifies that the calculated
MAC equals the received MAC. If the MAC's do not match, then the
client silently ignores the EAP packet and does not send any
authentication values to the network. Eventually, if another EAP-
Request/SIM/Challenge packet with a valid AT_MAC is not received,
the connection establishment will time out.
Since the RAND's given to a client are accompanied with the message
authentication code AT_MAC, the client is able to verify that the
RAND's are fresh and they have been generated by the GSM network.
Haverinen Expires in six months [Page 4]
Internet Draft EAP SIM Authentication June 2002
If all checks out, the client responds with the EAP-
Response/SIM/Challenge, containing the client's response MAC_SRES
(Section 15). The EAP server verifies that the MAC_SRES is correct
and sends the EAP-Success packet, indicating that the authentication
was successful. The EAP server may also include derived keying
material in the message it sends to the Authenticator.
Client Authenticator
| |
| EAP-Request/Identity |
|<---------------------------------------------------------|
| |
| EAP-Response/Identity |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Start |
|<---------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_NONCE_MT) |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Challenge |
| (AT_RAND, AT_MAC) |
|<---------------------------------------------------------|
| |
+-------------------------------------+ |
| Client runs GSM algorithms, | |
| verifies AT_MAC, derives AT_MAC_SRES| |
| and session key | |
+-------------------------------------+ |
| |
| EAP-Response/SIM/Challenge |
| (AT_MAC_SRES) |
|--------------------------------------------------------->|
| |
| |
| EAP-Success |
|<---------------------------------------------------------|
| |
Figure 1 EAP/SIM authentication procedure
4. Obtaining Subscriber Identity via EAP/SIM Messages
It may be useful to obtain the identity of the subscriber through
means other than EAP Request/Identity. This can eliminate the need
for an identity request when using EAP method negotiation. If this
was not possible then it might not be possible to negotiate EAP/SIM
as the second method since it is not specified how to deal with a
new EAP Request/Identity.
Haverinen Expires in six months [Page 5]
Internet Draft EAP SIM Authentication June 2002
If the EAP server does not have any identity (IMSI or pseudonym)
available when sending the first EAP/SIM request (EAP-
Request/SIM/Start), then the EAP server includes the AT_IDENTITY_REQ
attribute (specified in Section 9) in the EAP-Request/SIM/Start
packet. This attribute does not contain any data. It requests the
client to include the AT_IDENTITY attribute (specified in Section
10) in the EAP-Response/SIM/Start packet. The AT_IDENTITY attribute
contains the current identity of the subscriber (IMSI or pseudonym).
The use of pseudonyms for anonymity is specified in Section 5.
This case is illustrated in the figure below.
Client Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP/SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (Includes AT_IDENTITY_REQ) |
|<------------------------------------------------------|
| |
| |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -