📄 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 + -