Mobile IP Working Group H. Haverinen (editor) Internet Draft Nokia April 2001 GSM SIM Authentication and Key Generation for Mobile IP draft-haverinen-mobileip-gsmsim-02.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 mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. Abstract This document specifies a mechanism for Mobile IP network access authentication and key distribution using the GSM Subscriber Identity Module (SIM). The mechanism uses new subtypes of the generalized key distribution extensions [1] for Mobile IP Registration Request and Registration Reply. After the registration keys have been generated, the default Mobile IP authentication with these keys can be used (MD5 in prefix + suffix mode). The keys can be used for several subsequent registrations. However, there are lifetimes for the keys and before the lifetimes expire, new keys can be generated with the same procedure. Haverinen et al. Expires October 2001 [Page 1] Internet Draft GSM SIM Authentication for Mobile IP April 2001 Table of Contents Status of this Memo.........................................1 Abstract....................................................1 Table of Contents...........................................2 1. Introduction.............................................2 2. Terms....................................................3 3. AAA Considerations.......................................4 3.1. AAA Network............................................4 3.2. IMSI and NAI...........................................5 4. Protocol Operation.......................................6 4.1. Overview...............................................6 4.2. SIM Key Request.......................................10 4.3. SIM Key Reply.........................................10 4.4. SRES Extension........................................11 4.5. Distributing the Mobile-Home Registration Key.........12 4.6. Foreign Agent Considerations..........................13 5. Protocol Extensions.....................................13 5.1. MN-FA SIM Key Request Extension.......................13 5.2. MN-FA SIM Key Reply Extension.........................14 5.3. MN-FA SRES Extension..................................15 6. Calculation of Cryptographic Values.....................16 7. IANA Considerations.....................................17 7.1. Mobile IP Registration Reply Codes....................17 7.2. Well-Known SPI Value..................................18 7.3. Generalized Key Distribution Extension Subtypes.......18 8. Security Considerations.................................18 9. Intellectual Property Right Notice......................18 10. Acknowledgements.......................................19 References.................................................19 Editor's Address...........................................20 1. Introduction This document specifies a mechanism for Mobile IP network access authentication and registration key generation using the GSM Subscriber Identity Module (SIM). The rationale for using the GSM SIM with Mobile IP is to leverage the existing GSM authorization infrastructure with the existing user base and the existing SIM card distribution channels. By using the SIM key exchange, no other preconfigured security association besides the SIM card is required on the mobile node. The idea is not to use the GSM radio access technology, but to use GSM SIM authorization with Mobile IP over any link layer, for example on Wireless LAN access networks. The SIM key exchange uses new subtypes of the generalized key distribution extensions [1] for Mobile IP Registration Request and Registration Reply to agree on a MN-AAA key, a Mobile-Foreign key and a Mobile-Home key. After the keys have been generated, the default Mobile IP authentication with this key can be used (MD5 in Haverinen et al. Expires October 2001 [Page 2] Internet Draft GSM SIM Authentication for Mobile IP April 2001 prefix + suffix mode). This document only describes the Mobile IP protocol extensions. The AAA protocol that the foreign agent and the GSM network use is out of the scope of this document. However, Section 3 of this document contains some AAA considerations, and Section 4.6 contains foreign agent considerations that are related to AAA. 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 Mobile IP SIM key exchange, several RAND challenges are used for generating several 64-bit Kc keys, which are combined to constitute a longer Mobile IP registration key. After the session keys have been generated, the mobile node is able to register using the Mobile-Foreign and Mobile-Home Authentication extensions. The keys can be used for several subsequent registrations. However, there are lifetimes for the keys and before the lifetimes expire, new keys can be generated with the same procedure. 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 same terminology as [4]. In addition, this document frequently uses the following terms: AAA protocol Authentication, Authorization and Accounting protocol, such as RADIUS or DIAMETER. AAAF The AAA server or the AAA network of the foreign domain. AAAH The AAA server that can authorize the user, and probably charge/bill the user where necessary. Haverinen et al. Expires October 2001 [Page 3] Internet Draft GSM SIM Authentication for Mobile IP April 2001 AuC Authentication Centre. The GSM network element that can authorize the subscriber. GSM Global System for Mobile communications. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. LAN Local Area Network SIM Subscriber Identity Module. SIM cards are smart cards distributed by GSM operators. STC Subject to Change 3. AAA Considerations 3.1. AAA Network In this document, we use the term AAAH to denote the AAA server that can authorize the user, and probably charge/bill the user where necessary. In the GSM SIM case, the AAAH is the Authentication Centre (AuC) which resides deep inside the GSM network. The home agent and AAAH are not necessarily under the same administrative control, and are not co-located. They are probably not even close to each other There is a GSM/AAA gateway on the border of the Internet AAA network and the GSM authorization network. Thanks to GSM roaming, the GSM/AAA gateway doesn't need to reside on the GSM home network of the mobile subscriber. The GSM infrastructure is able to route the authorization request from the gateway operator's GSM network to the subscriber's home AuC based on the subscriber's International Subscriber Identity Number (IMSI) (Section 3.2). Figure 1 illustrates the AAA architecture we assume in this document. The important point is that the AAAH and the home agent are in separate domains, and we do not necessarily need a AAA infrastructure that spans from the foreign domain to the Mobile IP home domain of the mobile node. It is sufficient if the AAA network of the foreign domain is able to reach a GSM/AAA gateway. Haverinen et al. Expires October 2001 [Page 4] Internet Draft GSM SIM Authentication for Mobile IP April 2001 However, if there is no AAA connectivity between the foreign AAA network and the Mobile IP home domain, then the mechanism specified in this document cannot be used to allocate a home agent or to distribute the Mobile-Home registration key. In this case, some other mechanism, such as static configuration, must be used. GSM Authorization Infrastructure +----------------------------------+ | +------+ | | | | | | +---------------+ AAAH | | | | | | | | | +------+ | | +-+-----+ | | | | | +---|GSM/AAA|----------------------+ |Gateway| | | +--+----+ | +------|-------+ +--------------+ | +--+---+ | | | | | | | | | | | AAAF + | | | | | | | | | | +--+---+ | | | | | | | | | | | | | +------+ | +--+---+ | | +------+ | | | | | | | | | | | | MN +- -|- -+ FA + -- -- -- - + HA | | | | | | | | | | | | +------+ | +------+ | | +------+ | +--------------+ +--------------+ Foreign Domain Home Domain Figure 1 AAA architecture 3.2. IMSI and NAI GSM subscribers are identified with the International Mobile Subscriber Identity (IMSI) [5]. 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. Internet AAA protocols identify users with the Network Access Identifier (NAI) [8]. When used with Mobile IP and AAA, the NAI is composed of a username and a realm, separated with "@". The username portion identifies the subscriber within the realm. Haverinen et al. Expires October 2001 [Page 5] Internet Draft GSM SIM Authentication for Mobile IP April 2001 When using the mechanisms specified in this document, the mobile node transmits the user's IMSI as a NAI in a MN-NAI extension to the Registration Request. 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. More precisely, the NAI is of the format "0imsi@realm". The first character is the digit zero (ASCII 0x30), followed by the IMSI, followed by the @ character and the realm. Here, the IMSI is represented an ASCII string that consists of not more than 15 decimal digits (ASCII values between 0x30 and 0x39). The AAA nodes use the realm portion of the NAI to route AAA requests to the correct AAA server. However, this protocol can be used even when the AAA network of the foreign domain is able to reach the AAA server the mobile node is using. This is possible because the IMSI itself contains enough information to identify the GSM operator and to route the authorization requests to the subscriber's home GSM operator. Therefore, the AAA foreign network may use special AAA routing rules that direct GSM SIM related requests to the local GSM/AAA gateway. The foreign domain may have a local disjoint AAA network, which includes a gateway AAA server with an interface to the GSM network. In this case the local AAA network is able to reach the AAAH, but the local AAA network isn't able to reach the home agent. 4. Protocol Operation 4.1. Overview The SIM key exchange messages between a mobile node and a foreign agent are transmitted as extensions to the Registration Request and Registration Reply. Three new extensions to registration messages between the mobile node and the foreign agent are needed in order to authorize the mobile node and agree upon the session keys: SIM Key Request extension, SIM Key Reply extension and SRES extension. Figure 2 and Figure 3 show two examples of the SIM key exchange procedure. In Figure 2, the mobile node and the home agent already share a Mobile-Home registration key. The AAA network of the foreign domain is not able to reach the home agent. Haverinen et al. Expires October 2001 [Page 6] Internet Draft GSM SIM Authentication for Mobile IP April 2001 MN FA HA | | | | Reg. Request | | | + MN-NAI ext. | | | + SIM Key Req. ext. | | | + MN-AAA Auth. ext. | | |------------------------------->| | | | | | +----------------------------+ | | |FA invokes an AAA operation.| | | |Response from AAA | | | |indicates failure but | | | |includes a key reply ext. | | | +----------------------------+ | | | | | Reg. Reply (failure Code) | | | + SIM Key Reply ext. | | |<-------------------------------| | | | | | Reg. Request | | | + MN-NAI ext. | | | + M-H Auth. ext. | | | + SRES ext. | | | + MN-AAA Auth. ext. | | |------------------------------->| | | | | | +-----------------------------+ | | |FA invokes an AAA operation. | | | |Successful response from | | | |AAA includes Mobile-Foreign | | |key but no Reg. Reply. | | | |FA forwards Reg.Request to HA| | | +-----------------------------+ | | | | | | Reg. Request | | | + M-H Auth. ext. | | |------------------------>| | | | | | Reg. Reply | | Reg.Reply | + M-H Auth. ext. | | + M-H Auth. ext. |<------------------------| | + M-F Auth. ext. | | |<-------------------------------| | | | | Figure 2 SIM key exchange procedure (without global AAA infrastructure) In Figure 3, the AAA network is able to reach the home agent. Because the mobile node doesn't have a Mobile-Home registration key, both Mobile-Foreign and Mobile-Home registration keys are distributed. Haverinen et al. Expires October 2001 [Page 7] Internet Draft GSM SIM Authentication for Mobile IP April 2001 MN FA HA | | | | Reg. Request | | | + MN-NAI ext. | | | + SIM Key Req. ext. | | | + MN-AAA Auth. ext. | | |------------------------------->| | | | | | +----------------------------+ | | |FA invokes an AAA operation.| | | |Response from AAA | | | |indicates failure but | | | |includes a key reply ext. | | | +----------------------------+ | | | | | Reg. Reply (failure Code) | | | + SIM Key Reply ext. | | |<-------------------------------| | | | | | Reg. Request | | | + MN-NAI ext. | | | + SRES ext. | | | + MN-AAA Auth. ext. | | |------------------------------->| | | | | | +------------------------------------+ | |FA invokes an AAA operation, which | | |distributes both M-H and M-F keys. | | |Response from AAA is successful and | | |includes Reg. Reply from HA. | | +------------------------------------+ | Reg.Reply | | | + Unsolicited MN-HA Key From AAA ext. | | + M-H Auth. ext. | | | + M-F Auth. ext. | | |<-------------------------------| | | | | Figure 3 SIM key exchange procedure (global AAA infrastructure) As shown in Figure 2 and Figure 3, the SIM key exchange uses two Mobile IP registrations to authorize the user and distribute the keys. The AAA operation the foreign agent invokes after receiving the first Registration Request fetches the GSM authentication parameters (RAND challenges, SRES responses and Kc keys) from the subscriber's home AuC. Because the first Registration Request never goes to the home agent, the mobile node doesn't have to include the Mobile-Home Authentication extension in it even if shares a key with the home agent. When the mobile node receives the RAND's with the first Registration Reply, it runs the GSM authentication algorithm on the SIM card and generates the MN-AAA key K_MN_AAA. The second Registration Request can be authenticated with the new MN-AAA key. The second AAA Haverinen et al. Expires October 2001 [Page 8] Internet Draft GSM SIM Authentication for Mobile IP April 2001 operation issued by the foreign agent doesn't need to involve the GSM network at all, since the GSM/AAA gateway can provide the AAA response. Note that only the second Registration Request needs to travel to the home agent. The second Registration Reply is authenticated with the new Mobile- Foreign key, and (in Figure 3) the new Mobile-Home key. The mobile node and the AAA server derive the new Mobile IP registration keys from the MN-AAA key. Thus the keys do not need to be transported to the mobile node. They are only transported to the mobility agents. One reason for using two Registration Requests in the SIM key exchange is to let the AuC of the subscriber's home operator generate the RAND's, as normally in GSM. This aims at facilitating the integration with the existing GSM networks, because no changes (besides the GSM/AAA gateway) are required in the GSM network. Another reason for using two registrations is to protect against SIM cracking attacks. Since the RAND's given to a mobile node are accompanied with a message authentication code (MAC_RAND), the mobile node is able to verify that the RAND's are fresh and they have been generated by the GSM network. If the message authentication code is invalid, the mobile node does not send any authentication values calculated on the SIM to the network. In Figure 2 we show the case where the AAA network isn't able to reach the home agent that the mobile node is using in the Home Agent field of the Registration Request. The mobile node and the home agent already share a mobility security association, and the mobile node includes the Mobile-Home Authentication extension in the seconds Registration Request. In this case, the foreign agent has to forward the Registration Request to the home agent after receiving the response from AAA. If the AAA network is able to reach the home agent, as in Figure 3, then the second AAA operation issued by the foreign agent results in the request going all the way to the home agent. In this case, the AAA response received by the foreign agent includes the Registration Reply from the home agent. The mobile node may also request the allocation of the home agent in foreign domain. If the foreign domain supports this, then the second Registration Request sent by the mobile node results in the allocation of the home agent, as with other Mobile IP/AAA mechanisms. The SIM key exchange procedure always results in a new Mobile- Foreign registration key. If the mobile node doesn't share a mobility security association with its home agent, it doesn't include the Mobile-Home Authentication extension in the second Registration Request, and hence it requests a Mobile-Home Registration key to be generated too. Following sections discuss the GSM SIM authentication and key exchange in detail. Haverinen et al. Expires October 2001 [Page 9] Internet Draft GSM SIM Authentication for Mobile IP April 2001 4.2. SIM Key Request The first message in Figure 2 is a Registration Request from the mobile node to the foreign agent. This request includes a MN-NAI extension [6], a SIM Key Request extension and a MN-AAA Authentication extension. The SIM Key Request extension contains a random number nonceMN picked by the mobile node and a key lifetime proposal for the new Mobile-Foreign key. The mobile node SHOULD use a good source of randomness for generating nonceMN. Please see [7] for recommendations how to generate good random numbers. The NAI extension contains the user's NAI (Network Access Identifier) [8]. The user's IMSI is transmitted in the user part of the NAI, as described in Section 3.2. When the mobile node is sending the first Registration Request, it does not yet have any MN-AAA key available to authenticate the request. Thus, the MN-AAA Authentication extension included in the first Registration Request is dummy. It is there just to cause the foreign agent to invoke an AAA operation to forward the request to AAA. Thus, when the foreign agent receives this Registration Request, it invokes an AAA operation. Although the mobile node and AAAH share the secret master key Ki, the master key is only known to the SIM card on the mobile node and the GSM AuC (authentication center), neither of which directly participates in the Mobile IP authorization process. The SIM card is not allowed to disclose Ki, and the AuC resides deep within the GSM network. Therefore we cannot use the key Ki to authenticate this Registration Request. The MN-AAA Authentication extension is specified in [9]. When used in combination with the SIM Key Request, the mobile node uses the SPI value GSMSIM_SPI (Section 7.2), to tell the AAA server that the mobile node is requesting GSM SIM authentication and key exchange. Because the Authenticator field is not used, it is set to 20 zero bytes on sending and ignored on reception. 4.3. SIM Key Reply If an error occurs on the foreign agent or on the AAA network when processing a Registration Request with the SIM Key Request extension (for example the GSM network cannot be reached), the foreign agent sends the mobile node a Registration Reply with a Code value indicating failure. The foreign agent may use a reply code specified in [4] or one of the new code values specified in Section 7.1. If the mobile node and the foreign agent share a non-expired session key from the previous key exchange, this Registration Reply is authenticated with it. In this case, the mobile node may retry the key exchange immediately. If, however, the Registration Reply doesn't contain a valid Mobile-Foreign Authentication extension, Haverinen et al. Expires October 2001 [Page 10] Internet Draft GSM SIM Authentication for Mobile IP April 2001 receiving such a message SHOULD be logged or ignored. Eventually, the mobile node's retransmission timer will expire and the mobile node will retransmit the Registration Request with the SIM Key Request extension. If the mobile node has received an unauthenticated Registration Reply with one of the new error codes listed in Section 7.1 when the retranmission timer expires, the mobile node MAY show an error message to the user. If things work out, the foreign agent receives an AAA response which indicates failure but contains a SIM Key reply extension. The foreign agent sends the mobile node a Registration Reply with an error code including the key reply extension. The SIM Key Reply extension contains the RAND challenges (n*RAND) and an authenticator MAC_RAND, so that the mobile node is able to verify that the RAND's are fresh and they were generated by the GSM infrastructure. The calculation of MAC_RAND is specified in Section 7.2. The SIM Key Reply extension also contains the remaining key lifetime for the new Mobile-Foreign registration key that will be generated in this key exchange. The AAA server decides the lifetime for the key. It may, but it doesn't have to, take into account the mobile node's key lifetime proposal. If the mobile node and the foreign agent do not share a security association, the Mobile-Foreign Authentication extension is not used in the Registration Reply containing the SIM Key Reply extension. The foreign agent sets the Code field in the Registration Reply to an error value, such as 67, "Mobile node failed authentication". 4.4. SRES Extension After receiving the Registration Reply with the SIM Key Reply extension, the mobile node is able to generate the new MN-AAA key K_MN_AAA and verify the validity of MAC_RAND, using the formulas of Section 7.2. If MAC_RAND is valid, the mobile node calculates the response MAC_SRES, generates the new Mobile-Foreign key K_MN_FA (Section 7.2) and creates a new security association for the foreign agent with the new Mobile-Foreign key and an SPI picked up by the mobile node. The key K_MN_FA will be used for authenticating subsequent Mobile IP registrations. In the next Registration Request to the foreign agent, the mobile node includes a MN-NAI extension, a SRES extension and a MN-AAA Authentication extension. The MN-NAI extension is identical to the MN-NAI extension of the first Registration Request. The SRES extension contains the response MAC_SRES and the SPI that will be used with the new Mobile-Foreign key. The mobile node may also include the Mobile-Home authentication extension, if it shares a Mobile-Home key with its home agent. When the mobile node uses the MN-AAA Authentication extension in combination with the SRES extension, the mobile node uses the SPI value GSMSIM_SPI and calculates the Authenticator field using the new key K_MN_AAA and the default method specified in [9]. The Haverinen et al. Expires October 2001 [Page 11] Internet Draft GSM SIM Authentication for Mobile IP April 2001 K_MN_AAA key is a one-time key -- every time new session keys need to be distributed, a new MN-AAA key is first generated with the exchange of a SIM Key Request extension and a SIM Key Reply extension. When the foreign agent receives the second Registration Request from the mobile node, the foreign agent sends the Registration Request to AAA, because the Registration Request includes the MN-AAA Authentication extension. The AAA server verifies the mobile node's request and sends a response to the foreign agent. If MAC_SRES is valid, the AAA server also sends the new Mobile-Foreign registration key K_MN_FA and the associated SPI to the foreign agent. Now the foreign agent can create a mobility security association for the mobile node. When the foreign agent (eventually) forwards the Registration Reply to the mobile node, it includes a Mobile-Foreign Authentication extension using this mobility security association. Because the AAA network may no be able to reach the home agent, the AAA response doesn't necessarily contain a Registration Reply from the home agent. In this case, the foreign agent must forward the Registration Request to the home agent itself. If the AAA network is able to reach the home agent (or allocate one if the mobile node is requesting a home agent), then the AAA response contains the Registration Reply from the home agent. If the foreign agent fails to create a mobility security association (for example because MAC_SRES was invalid), it sends a Registration Reply with an error code, such as 67, "mobile node failed authentication". If the mobile node and the foreign agent share a non-expired session key from the previous key exchange, this Registration Reply is authenticated with it. In this case, the mobile node may immediately retry the key exchange starting with a Registration Request including a SIM Key Request extension. However, if the Registration Reply doesn't contain a valid authentication extension, receiving such a message SHOULD be logged or ignored. Eventually, the mobile node's retransmission timer will expire and cause the mobile node to retry the key exchange. Since the AAA network may need to get the SRES extension quickly and since it is a good idea to make the time between the transmission of the RAND and the transmission of the SRES as small as possible, the mobile node should send the Registration Request with the SRES extension right after receiving the SIM Key Reply extension. 4.5. Distributing the Mobile-Home Registration Key If the mobile node doesn't include the Mobile-Home Authentication extension in the Registration Request that contains the SRES extension, it is requesting a Mobile-Home registration key to be generated and distributed. If a Mobile-Home registration key is successfully generated, then the corresponding Registration Reply received by the mobile node includes an Unsolicited MN-HA Key From Haverinen et al. Expires October 2001 [Page 12] Internet Draft GSM SIM Authentication for Mobile IP April 2001 AAA extension [10] and the Mobile-Home Authentication extension calculated with the new Mobile-Home key. The Unsolicited MN-HA Key from AAA extension is only used to communicate the SPI and lifetime of the new key. Because the mobile node derives the new Mobile-Home key K_MN_HA from the MN-AAA key K_MN_AAA with the formulas given in Section 6, the MN-HA Encoded Key data field of the Unsolicited MN-HA Key from AAA extension is not used. The Lifetime field indicates duration for which the MN-HA key is valid. The AAA SPI field is set to GSMSIM_SPI (Section 7.2) and the HA SPI field specifies the SPI that will be used with the new key. 4.6. Foreign Agent Considerations Although the GSM SIM authentication support doesn't require the foreign agent to know GSM SIM authentication, this document introduces two new rules in the operation of the foreign agent, as explained in the previous sections. These rules are not GSM SIM specific but they may be useful for other purposes as well. The first new rule says that if the response the foreign agent receives from AAA indicates failure but contains a key distribution extension, then the foreign agent must include the key distribution extension in the Registration Reply it sends to the mobile node. The second new rule says that if the response the foreign agent receives from AAA indicates success but doesn't contain a Registration Reply from the home agent, then the foreign agent must forward the Registration Request in question to the home agent. 5. Protocol Extensions The SIM key exchange extensions are subtypes of generalized key distribution extensions [1]. 5.1. MN-FA SIM Key Request Extension The format of this extension is shown below in Figure 4. The mobile node may place the MN-FA SIM Key Request extension before the MN-AAA Authentication extension. Haverinen et al. Expires October 2001 [Page 13] Internet Draft GSM SIM Authentication for Mobile IP April 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime Proposal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 MN-FA SIM Key Request extension Type 40 (not skippable) STC Subtype MN_FA_SIM_KEY_REQUEST_SUBTYPE (Section 7.3) Length Length of this extension in bytes = 28 Mobile Node SPI Not used. Set to 0 on sending, ignored on reception. NonceMN A random number generated by the mobile node (16 bytes). Key Lifetime Proposal MN's key lifetime proposal in seconds (four bytes). 5.2. MN-FA SIM Key Reply Extension The format of this extension is shown below in Figure 5. The foreign agent may insert the MN-FA SIM Key Reply extension in a Registration Reply before the Mobile-Foreign authentication extension (if present). Haverinen et al. Expires October 2001 [Page 14] Internet Draft GSM SIM Authentication for Mobile IP April 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_RAND | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n*RAND ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 The MN-FA SIM Key Reply extension (successful case) Type 41 (non-skippable) STC Subtype MN_FA_SIM_KEY_REPLY_SUBTYPE (Section 7.3) Length Length of this extension in bytes = 24 + the size of n*RAND Key Lifetime Remaining key lifetime of the new Mobile-Foreign registration key in seconds (4 bytes). Must be greater than zero. MAC_RAND The authenticator for n*RAND and Key Lifetime, 16 bytes. (Section 6) n*RAND n GSM RAND's (length n *16 bytes) 5.3. MN-FA SRES Extension The format of the MN-FA SRES extension is shown below in Figure 6. The mobile node may place the MN-FA SRES extension in a Registration Request after the Mobile-Home authentication extension (if present) and before the MN-AAA Authentication extension. The foreign agent Haverinen et al. Expires October 2001 [Page 15] Internet Draft GSM SIM Authentication for Mobile IP April 2001 must remove this extension before forwarding the Registration Request to the home agent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_SRES | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The MN-FA SRES extension Type 40 (not skippable) STC Subtype MN_FA_SRES_ KEY_REQUEST_SUBTYPE (Section 7.3) Length The length of this extension in bytes = 40 Mobile Node SPI The SPI that will be used with the new Mobile-Foreign key. MAC_SRES The response calculated by the mobile node, 16 bytes (Section 6). 6. Calculation of Cryptographic Values This section specifies how the SIM-generated session keys K_MN_AAA, K_MN_FA, K_MN_HA and the authenticators MAC_RAND and MAC_SRES are calculated. The mobile node requests these formulas and functions to be used when it uses the SPI value GSMSIM_SPI in the MN-AAA Authentication extension. When calculating K_MN_AAA and MAC_SRES, the IMSI is packed into 8 bytes. The most significant nibble of the first byte is the first digit in the IMSI, the least significant nibble the second digit in IMSI etc. The least significant nibble of the 8th byte is 'F' as the Haverinen et al. Expires October 2001 [Page 16] Internet Draft GSM SIM Authentication for Mobile IP April 2001 IMSI typically is 15 digits. Unused nibbles are filled with 'F' in case the IMSI is less than 15 digits. For example, the IMSI 244070100000112 is coded as follows: the first byte is 0x24, the second byte is 0x40, ..., and the eighth byte is 0x2F. 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). When using GSMSIM_SPI, the prf is HMAC-MD5 [11]. K_MN_AAA prf(n*Kc, n*RAND | IMSI | nonceMN) K_MN_FA prf(K_MN_AAA, foreign agent IP address) K_MN_HA prf(K_MN_AAA, home agent IP address) MAC_RAND prf(n*Kc, n*RAND | NONCE_MT | key lifetime) MAC_SRES prf(n*Kc, n*SRES | IMSI | NONCE_MT) Note that when calculating K_MN_AAA, the pseudo-random function prf is used as a mixing function to combine several session keys (Kc's) generated by the GSM authentication procedure and the random number nonceMN into a single key to be used in Mobile IP/AAA. 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 hash function to combine the keys, we are assured that even if an attacker manages to learn the key used in Mobile IP, it doesn't help him in learning the original GSM Kc's. In addition, since we include the random number nonceMN in the calculation, the mobile node is able to verify that the SIM authentication values it receives from the network are fresh and not a replay. 7. IANA Considerations 7.1. Mobile IP Registration Reply Codes This document specifies the following new values to be used within the Code field of the Registration Reply. The numbering space for the Code values is defined in [4]. Haverinen et al. Expires October 2001 [Page 17] Internet Draft GSM SIM Authentication for Mobile IP April 2001 Registration denied by foreign agent due to an AAA error: 100 AAA server unreachable 101 service for user is barred 102 user does not have the service subscribed 7.2. Well-Known SPI Value GSM SIM authentication support specifies the following new Security Parameter Index (SPI) value to be used in combination with the MN- AAA Authentication extension. The SPI numbering space for this extension is defined in [9]. GSMSIM_SPI 3 STC 7.3. Generalized Key Distribution Extension Subtypes GSM SIM authentication support requires the following three new subtypes to be used in combination with the generalized key distribution extensions. The subtype numbering space for these extension is defined in [1]. MN_FA_SIM_KEY_REQUEST_SUBTYPE 15 STC MN_FA_SIM_KEY_REPLY_SUBTYPE 16 STC MN_FA_SRES_KEY_REQUEST_SUBTYPE 17 STC 8. Security Considerations The extensions in this document are intended to provide the appropriate level of security for Mobile IP entities (mobile node and foreign agent) to operate Mobile IP registration protocol using registration keys that are generated on the GSM SIM. The security associations resulting from use of these extensions do not offer any higher level of security than what is already implicit in use of the GSM authentication algorithms. 9. 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. Haverinen et al. Expires October 2001 [Page 18] Internet Draft GSM SIM Authentication for Mobile IP April 2001 10. Acknowledgements Special thanks to N. Asokan of Nokia Research Center for his substantial contributions to this document. Thanks to Patrik Flykt and Jari T. Malinen of Nokia Research Center, Tapio Suihko of VTT Technical Research Centre of Finland and Pat R. Calhoun of Sun Microsystems Laboratories for their useful discussions and contributions. References [1] C. Perkins and P. Calhoun, "Generalized Key Distribution Extensions for Mobile IP", draft-ietf-mobileip-gen-key-02.txt, Work in progress, July 2000 [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] C. Perkins, Editor, "IP Mobility Support for IPv4, revised", draft-ietf-mobileip-rfc2002-bis-03.txt, Work in progress, September 2000. [5] 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 [6] C. Perkins and P. Calhoun, "Mobile IP Network Access Identifier for IPv4", RFC 2794, March 2000 [7] D. Eastlake, 3rd, S. Crocker, J. Schiller, "Randomness Recommendations for Security", RFC 1750 (Informational), December 1994 [8] B. Aboba and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [9] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", draft-ietf-mobileip-challenge-13.txt, Work in progress, June 2000 [10] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", draft-itef-mobileip-aaa-key-01.txt, work in progress, January 2000 Haverinen et al. Expires October 2001 [Page 19] Internet Draft GSM SIM Authentication for Mobile IP April 2001 [11] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC2104, February 1997 Editor'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 et al. Expires October 2001 [Page 20]