IP Security Remote Access Working Group J. Rinnemaa Internet Draft Nokia July 2000 GSM SIM Authentication Mode for IKE draft-rinnemaa-ipsra-gsmsimmode-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. Abstract This document presents a challenge-response authentication method based on the GSM Subscriber Identity Module (SIM). The method is used for authenticating a remote IPSec user to a security gateway. The examples in the document are based on modified IKE main mode. In the authentication phase a shared secret is generated utilizing the GSM SIM and then used to authenticate the IKE exchange as well. Rinnemaa Expires January 2001 [Page 1] Internet Draft GSM SIM Authentication Mode for IKE July 2000 Table of Contents Status of this Memo.........................................1 Abstract....................................................1 Table of Contents...........................................2 1. Introduction.............................................2 2. Terms....................................................3 3. Protocol Operation.......................................3 3.1. Overview...............................................3 3.2. Wrapping the Information in ISAKMP Messages............5 4. The Protocol in Pre-IKE Mode.............................6 5. Alternative Usage Scenarios..............................6 6. Security Considerations..................................7 7. Intellectual Property Right Notice.......................7 8. Acknowledgements.........................................7 9. References...............................................7 Author's Address............................................8 1. Introduction This document presents a challenge-response authentication method that uses the GSM Subscriber Identity Module (SIM). The method is aimed at providing authentication for roaming users utilizing IPSec solutions. The rationale for using the GSM SIM is to leverage the existing user base, the existing SIM card distribution channels and the existing GSM authentication infrastructure. By using the SIM authentication method, no other preconfigured security association besides the SIM card is required on the user device (client). The SIM authentication method uses ISAKMP messages and IKE mechanisms. The GSM SIM authentication specific information is relayed in the ISAKMP messages, and the exchange is authenticated using the generated shared secret. This document only describes the exchange between the client and the gateway. The AAA protocol the gateway and the GSM network uses is out of the scope of this document. 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 [1]. In the SIM authentication method, several RAND challenges are used for generating several 64-bit Kc keys, which are combined to constitute a longer authentication key. The RANDs sent to a client are accompanied with a message authentication code, so that the client is able to verify that the RANDs are fresh and they have been generated by the GSM network. If the message authentication code is Rinnemaa Expires January 2001 [Page 2] Internet Draft GSM SIM Authentication Mode for IKE July 2000 invalid, the client does not send any authentication values calculated on the SIM to the network. GSM subscribers are identified by an IMSI (International Mobile Subscriber Identifier), which is a string of digits. The format of IMSI is specified in [2]. The client sends its IMSI to the gateway which, based on the user's IMSI, is able to obtain GSM authentication information, including RANDs. When the client receives the RANDs, it can run the GSM authentication algorithm on the SIM card and generate an authentication key used for authenticating the exchange. 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 uses the following terms: AAA protocol Authentication, Authorization and Accounting protocol, such as RADIUS or DIAMETER. GSM Global System for Mobile communications. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. SIM Subscriber Identity Module. SIM cards are smart cards distributed by GSM operators. 3. Protocol Operation 3.1. Overview The SIM exchange messages between a client and a gateway are transmitted as ISAKMP messages. Figure 1 shows as an overview the messages needed for the SIM authentication. The Gateway uses the AAA protocol when communicating with the AAA server that handles the GSM-specific information. Rinnemaa Expires January 2001 [Page 3] Internet Draft GSM SIM Authentication Mode for IKE July 2000 Client Gateway | | | | | NAI, nonce_i | |------------------------------------------------>| | | | Obtain RANDs and MAC_RAND | from AAA server. | | | | | RANDs, MAC_RAND, nonce_i, key lifetime | |<------------------------------------------------| | | Run GSM algorithm on SIM. | Calculate the key K. | Verify that MAC_RAND is valid. | Calculate MAC_SRES. | | | |MAC_SRES, nonce_i | |------------------------------------------------>| | | | Obtain the key K. | and MAC_RESULT from | AAA server. | | | MAC_RESULT | |<------------------------------------------------| | | Check MAC_RESULT | | | Figure 1 The SIM exchange procedure In the exchange, the NAI (Network Access Identifier) contains the user's IMSI. The nonce_i is a random number picked by the client to identify the authentication session, and it is the client's input to the message authentication codes. The gateway sends the client n number of RANDs, an authenticator for the RANDs (MAC_RAND) and the key lifetime. The MAC_SRES is an authenticator for the SRES responses calculated by the client. In case the authentication was valid, the MAC_RESULT is sent to the client, otherwise an error is returned. The calculation of the key K and the authenticators MAC_RAND, MAC_SRES, and MAC_RESULT are shown below. In the formulas, h denotes a one-way hash function and MAC denotes a function that produces a message authentication code. K h(n*Kc | nonce_i) Rinnemaa Expires January 2001 [Page 4] Internet Draft GSM SIM Authentication Mode for IKE July 2000 MAC_RAND MAC(K, n*RAND | key lifetime) MAC_SRES MAC(K, n*SRES) MAC_RESULT MAC(K, n*SRES | IMSI | key lifetime) 3.2. Wrapping the Information in ISAKMP Messages The information presented in Figure 1 can be wrapped in IKE messages as illustrated in Figure 2. Messages (1) and (2) contain the SA and Diffie-Hellman public values. Messages(3), (4), (5), and (6) contain the information presented in Figure 1, respectively. # Client Gateway (1) HDR, SA, KE -> (2) <- HDR, SA, KE (3) HDR*, ID_i, N_i -> (4) <- HDR*, N_r, SIG(1), SA, [, NOTIFY] (5) HDR*, SIG(2), SIG(3)[, SIG(4)] -> (6) <- HDR*, SIG(5), SIG(6) Figure 2 The ISAKMP message exchange The first two messages, (1) and (2), initiate the exchange. Message (3) contains the user's NAI (Network Access Identifier) [4]. The user's IMSI is transmitted in the user part of the NAI as a string of not more than 15 ASCII digits. The domain part of the NAI indicates the location of the AAA server to be used by the gateway. Additionally, the nonce generated by the client is transmitted. When the gateway receives the NAI, it obtains n number of challenges (RANDs) and an authenticator (MAC_RAND) for the RANDs from the GSM network using an AAA protocol. In case the AAA server in the GSM network cannot identify the user's IMSI, the gateway should send a notify message to the client. Rinnemaa Expires January 2001 [Page 5] Internet Draft GSM SIM Authentication Mode for IKE July 2000 Message (4) contains in nonce payload the RANDs received from the GSM network. The SIG(1) payload contains the MAC_RAND. In case the received MAC_RAND does not match with the one the client generates, the client aborts the authentication sequence after a timeout period. Because the lifetime of the SA is decided by the GSM network, it is relayed to the client. The client will then set the life time of the SA to the valued received from the gateway (originates in the GSM network). In the notify payload, the gateway may transmit other application dependent information, for example billing information. If more than one RAND is sent, they are concatenated in the same nonce payload since the GSM RAND is assumed to be fixed at 16 bytes. In message (5) the client responds with the MAC_SRES. SIG(3) is used for authenticating the exchange with the freshly generated secret key K. The authentication is calculated over the HDR, SA and the MAC_SRES payload. This enables the GSM network's AAA server to detect if the messages have been altered in the way. SIG(4) may contain optionally transmitted data, for example an answer related to the billing information received by the client. Message (6) contains the positive authentication result received from the AAA server in SIG(5). SIG(6) contains the payload to authenticate the exchange. The authentication data is calculated over the header and the SA and the key K is used in this since only the GSM network and the user's SIM can generate the K. 4. The Protocol in Pre-IKE Mode The basic SIM authentication information presented in Figure 1 could be exchanged prior to standard IKE exchange specified in [5]. In this 'pre-IKE' mode, the generated secret key would then be used as a pre-shared key for IKE. In this case, however, the generated secret key needs to be conveyed to the IKE implementation thus requiring changes to it. 5. Alternative Usage Scenarios The presented authentication method is aimed to be used between a client and a gateway requiring user authentication in IPSec. The method can also be used for example for authenticating to an Internet access point that requires the use of AH. This case maps to the AAA framework, in which case the IPsec gateway acts as the service equipment, or attendant, in the local domain [6]. After successful authentication to the Internet access point, the client might connect to a corporate IPSec entry point using the same authentication method. The method could be extended with the optional payloads to cover a case in which the roaming client connects to an Internet access point which relays location dependent data for the client. For example, cost of the connection could be presented to the user before the user decides to accept the connection. Rinnemaa Expires January 2001 [Page 6] Internet Draft GSM SIM Authentication Mode for IKE July 2000 6. Security Considerations The method uses the GSM SIM mechanisms in which the user is typically required to take part in the authentication process as the SIM card typically needs to be unlocked with the PIN code. Several triplets (Kc, RAND, SRES) can be obtained from the GSM network to increase the entropy in the generated key. To protect the client's identity, the client could use the AAA server's public key which it has obtained beforehand to encrypt the IMSI. This requires further study. 7. Intellectual Property Right Notice Nokia may or may not have patents or patent applications that are applicable for some or all of the aspects discussed in this document. In case that such patents exists or are subsequently granted, Nokia is willing to grant licenses on these patents on terms according to RFC 2026, section 10. 8. Acknowledgements Thanks to Jukka-Pekka Honkanen, Henry Haverinen and Jorma Stenman for their contributions to the document. 9. References [1] 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 [2] 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 [3] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [4] B. Aboba and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [5] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [6] J. Vollbrecht et al, "AAA Authorization Framework", draft- ietf-aaa-authz-arch-00.txt, Work in progress, October 1999. Rinnemaa Expires January 2001 [Page 7] Author's Address Jyri Rinnemaa Nokia Mobile Phones P.O. Box 88 FIN-33721 Tampere Finland E-mail: jyri.rinnemaa@nokia.com Rinnemaa Expires January 2001 [Page 8]