Mobile IP Working Group H. Haverinen Internet Draft Nokia June 2000 GSM SIM Authentication for Mobile IP draft-haverinen-mobileip-gsmsim-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 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 generating Mobile IP authentication keys 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 authentication 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 is a lifetime for these keys and before the lifetime expires, new keys can be generated with the same procedure. Haverinen et al. Expires December 2000 [Page 1] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Table of Contents Status of this Memo.........................................1 Abstract....................................................1 Table of Contents...........................................2 1. Introduction.............................................2 2. Terms....................................................3 3. Protocol Operation.......................................4 3.1. Overview...............................................4 3.2. SIM Key Request........................................6 3.3. SIM Key Reply..........................................6 3.4. SRES Extension.........................................7 3.5. Security Parameter Index Assignment....................8 3.6. Mobile Node Considerations.............................8 3.7. Foreign Agent Considerations...........................8 4. Protocol Extensions......................................9 4.1. MN-FA SIM Key Request Extension........................9 4.2. MN-HA SIM Key Request Extension.......................10 4.3. MN-FA SIM Key Reply Extension.........................11 4.4. MN-HA SIM Key Reply Extension.........................14 4.5. MN-FA SRES Extension..................................17 4.6. MN-HA SRES Extension..................................18 5. IANA Considerations.....................................19 5.1. Well-Known SPI Values.................................19 5.2. Generalized Key Distribution Extension Subtypes.......19 6. Security Considerations.................................20 7. Intellectual Property Right Notice......................20 8. Acknowledgements........................................20 9. References..............................................20 Author's Address...........................................21 1. Introduction This document specifies a mechanism for generating Mobile IP authentication keys using the GSM Subscriber Identity Module (SIM). The specified SIM key exchange mechanism can be used for generating both Mobile-Foreign and Mobile-Home authentication keys. The rationale for generating authentication keys on 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 key exchange, no other preconfigured security association besides the SIM card is required on the mobile node. The SIM key exchange uses new subtypes of the generalized key distribution extensions [1] for Mobile IP Registration Request and Registration Reply. After the authentication keys have been generated, the default Mobile IP authentication with these keys can be used (MD5 in prefix + suffix mode). This document only describes the protocol between a mobile node and a mobility agent. The AAA protocol that the mobility agent and the GSM network use is out of the scope of this document. Haverinen et al. Expires December 2000 [Page 2] Internet Draft GSM SIM Authentication for Mobile IP June 2000 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 SIM key exchange, several RAND challenges are used for generating several 64-bit Kc keys, which are combined to constitute a longer Mobile IP authentication key. The SIM key exchange uses two Mobile IP registration round trips. One reason for using two round trips is to let the GSM infrastructure generate the RANDs. This aims at facilitating the integration with the existing GSM networks. Another reason for using two round trips is to protect against SIM cracking attacks. Since the RANDs given to a mobile node are accompanied with a message authentication code, the mobile node is able to verify that the RANDs 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. GSM subscribers are identified by an IMSI (International Mobile Subscriber Identifier), which is a string of digits. The format of IMSI is specified in [3]. The mobile node sends its IMSI to the mobility agent it is registering with in the first Registration Request. Using the user's IMSI, the mobility agent is able to obtain GSM authentication information, including RANDs. When the mobile node receives the RANDs, it can run the GSM authentication algorithm on the SIM card and generate an authentication key. The second Mobile IP registration can be authenticated with the newly generated key. After the shared session key has been generated, the mobile node is able to register with or through the mobility agent. The key can be used for several subsequent registrations. However, there is a lifetime for this key and before the lifetime expires, a new key 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 [4]. This document uses the same terminology as [5]. In addition, this document frequently uses the following terms: AAA protocol Authentication, Authorization and Accounting protocol, such as RADIUS or DIAMETER. Haverinen et al. Expires December 2000 [Page 3] Internet Draft GSM SIM Authentication for Mobile IP June 2000 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. STC Subject to Change 3. Protocol Operation 3.1. Overview The SIM key exchange messages between a mobile node and a mobility agent are transmitted as extensions to the Registration Request and Registration Reply. Three new extensions to registration messages between the mobile node and the mobility agent are needed in order to agree upon the session key: SIM Key Request extension, SIM Key Reply extension and SRES extension. Figure 1 shows an overview on the session key exchange procedure. Haverinen et al. Expires December 2000 [Page 4] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Mobile Node Mobility Agent | | | Reg. Request + NAI ext. + SIM Key Request ext. | | Auth. ext. calculated with old key (if exists) | |------------------------------------------------>| | | | Obtain RANDs and MAC_RAND. | | | Reg. Reply + SIM Key Reply ext. | | Auth. ext. calculated with old key (if exists) | |<------------------------------------------------| | | Run GSM algorithm on SIM. | Verify that MAC_RAND is valid. | Calculate the new key K and create | or update security association for agent. | Calculate MAC_SRES. | | | | Reg. Request + SRES ext. | | Auth. ext. calculated with the new key K | |------------------------------------------------>| | | | Verify that MAC_SRES is valid. | Obtain the new key K and create or | update security association for MN. | | | Reg. Reply | | Auth. ext. calculated with the new key K | |<------------------------------------------------| | | Figure 1 The SIM key exchange procedure In this context, the NAI extension contains the user's IMSI. The SIM Key Request extension contains a random number picked by the mobile node (nonceMN) and the mobile node's key lifetime proposal. The mobile node SHOULD use a good source of randomness for generating nonceMN. The SIM Key Reply extension contains nonceMN, n RANDs, an authenticator for the RANDs (MAC_RAND) and the key lifetime. The SRES extension contains nonceMN and MAC_SRES, which is an authenticator for the SRES responses calculated by the mobile node. The calculation of the key K and the authenticators MAC_RAND and MAC_SRES is shown below. In the formulas, h denotes a one-way hash function and MAC denotes a function that produces a message authentication code. The default hash function is MD5 [6] and the default MAC function is HMAC-MD5 [7]. K h(n*Kc | nonceMN) Haverinen et al. Expires December 2000 [Page 5] Internet Draft GSM SIM Authentication for Mobile IP June 2000 MAC_RAND MAC(K, n*RAND | key lifetime) MAC_SRES MAC(K, n*SRES) 3.2. SIM Key Request The first message is a Registration Request from the mobile node to the mobility agent. This message contains a SIM Key Request extension and the IMSI in a NAI extension [8]. The SIM Key Request extension contains a random number nonceMN picked by the mobile node and a key lifetime proposal. The NAI extension contains the user's NAI (Network Access Identifier) [9]. The user's IMSI is transmitted in the user part of the NAI as a string of not more than 15 ASCII digits. When the mobility agent receives the Registration Request with the SIM Key Request extension, it obtains n challenges (RANDs) and an authenticator (MAC_RAND) for the RANDs from the GSM network using an AAA protocol. 3.3. SIM Key Reply If an error occurs in the mobility agent after it has received the SIM Key Request extension (for example the GSM network cannot be reached), the mobility agent sends a Registration Reply containing a SIM Key Reply extension with the key lifetime set to zero and an error code. If the mobile node and the mobility 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 authentication extension, the mobile node must consider this message informational. The mobile node must not change its state or react to it in any way except write an entry to a log or show an error message to the user. 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 mobility agent is able to obtain the RANDs and MAC_RAND, it sends a Registration Reply containing a SIM Key Reply extension with a nonzero key lifetime to the mobile node. This message contains the RANDs (n*RAND) and MAC_RAND, so that the mobile node is able to verify that the RANDs are fresh and they were generated by the GSM infrastructure. This message also contains the remaining key lifetime. The GSM network decides the lifetime for the keys. It may, but it doesn't have to, take into account the mobile node's key lifetime proposal. Haverinen et al. Expires December 2000 [Page 6] Internet Draft GSM SIM Authentication for Mobile IP June 2000 If the mobile node and the home agent do not share a security association, the authentication of the first Registration Request and the Registration Reply will fail. The reply code in the Registration Reply is "mobile node failed authentication". The security parameter index (SPI) in the Mobile-Home authentication extension of these registration messages is a special value NEW_SESSION_KEY_SPI (Section 5.1). The authenticator field is empty. Thus, if the home agent doesn't support SIM key exchange, it will simply reply with code 131, "Mobile node failed authentication". Discussion: Instead of sending an empty authenticator, should we omit the Mobile-Home Authentication extension if the mobile node and the home agent do not share an authentication key? This should be clarified once [1] is augmented with a specification of MN-HA Key Request extension. If the mobile node and the foreign agent do not share a security association, authentication extensions are not used in the Registration Request containing the SIM Key Request extension and in the Registration Reply containing the SIM Key Reply. The foreign agent sets the reply code in the Registration Reply to 67, "Mobile node failed authentication". 3.4. SRES Extension After receiving the Registration Reply with the SIM Key Reply extension, the mobile node is able to generate the new authentication key K and verify the validity of MAC_RAND. If MAC_RAND is valid, the mobile node generates MAC_SRES and creates a new security association for the agent, or if such already exists, updates the context with the new key K. This key will be used for authenticating subsequent Mobile IP registrations. The mobile node includes MAC_SRES in a SRES extension in the next registration request it sends to the mobility agent. The mobility agent uses an AAA protocol to send the MAC_SRES to the GSM network, which verifies it and sends an indication to the mobility agent. If MAC_SRES is valid, the GSM network also sends the new authentication key K to the mobility agent. Now the mobility agent can create/update the security association for the mobile node. If the mobility agent fails to update the security association (for example because MAC_SRES was invalid), it sends a Registration Reply with foreign agent error code 67 or home agent error code 131, "mobile node failed authentication". If the mobile node and the mobility 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, the mobile node must consider this message informational. The mobile node must not change its state or react to it in any way except write an entry to a log or show an Haverinen et al. Expires December 2000 [Page 7] Internet Draft GSM SIM Authentication for Mobile IP June 2000 error message to the user. Eventually, the mobile node's retransmission timer will expire and cause the mobile node to retry the key exchange. Since the mobility agent 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. 3.5. Security Parameter Index Assignment The security association created with the session key exchange mechanism described above must have a Security Parameter Index (SPI). We use the well-known SPI SIM_SECURITY_CONTEXT_SPI (Section 5.1) for SIM-generated security association. Since the Mobile IP entities identify security associations with the pair (peer's IP address, SPI), it is possible to use the same SPI between all the entities. 3.6. Mobile Node Considerations Typically the mobile node knows that its home agent supports SIM key exchange. However, the mobile node may not know which authentication methods the current foreign agent supports. To test whether the current foreign agent supports SIM key exchange, the mobile node includes the SIM Key Request extension for the foreign agent in the first Registration Request and omits the Mobile-Foreign authentication extension. The SIM Key Request extension is a non-skippable extension, so if the foreign agent doesn't support it, it silently discards the Registration Request. If the mobile node doesn't receive a Registration Reply, it may retry the registration. If the foreign agent hasn't replied after the mobile node has tried the registration for a couple of times, the mobile node may try registration with other key exchange methods, or without any key exchange extensions or the Mobile-Foreign authentication extension to see if the foreign agent allows unauthenticated registrations. If the foreign agent recognizes the SIM Key Request extension but doesn't require any authentication, it will not include a SIM Key Reply extension in its Registration Reply. In this case, mobile node can send all subsequent registration requests to this foreign agent without any SIM key exchange extensions or Mobile-Foreign Authentication extension. 3.7. Foreign Agent Considerations When a foreign agent that requires Mobile-Foreign authentication using the SIM key exchange receives a Registration Request from a mobile node with which the foreign agent doesn't share a security Haverinen et al. Expires December 2000 [Page 8] Internet Draft GSM SIM Authentication for Mobile IP June 2000 association, and if the Registration Request contains a SIM Key Request extension and no Mobile-Foreign Authentication extension, then the foreign agent doesn't forward the Registration Request to the home agent but replies with error code 67 "mobile node failed authentication" and includes a SIM Key Reply extension in the Registration Reply. If the mobile node then sends another Registration Request with a valid SRES extension and a valid Mobile- Foreign Authentication extension, the foreign agent forwards the request to the home agent. Later, we can specify support for parallel processing of SIM Key Request in the Foreign Agent. This means that the foreign agent may forward a Registration Request to the home agent and do the new session key exchange in parallel. The foreign agent would wait for the home agent's reply and insert the SIM Key Reply extension to it. This would speed up the first registration and allow grace periods. Adding this won't require any changes to the specified protocol messages. 4. Protocol Extensions The SIM key exchange extensions are subtypes of generalized key distribution extensions [1]. Our specification differs from [1] in that we use MN-HA Key Request extensions which are missing from the current version of [1]. Session key exchange between the mobile node and the foreign agent is independent from the session key exchange between the mobile node and the home agent. Thus, a Registration Request may contain: - An MN-FA SIM Key Request extension, or - An MN-HA SIM Key Request extension, or - An MN-FA SIM Key Request extension and an MN-HA SIM Key Request extension, or - An MN-FA SRES extensions, or - An MN-HA SRES extension, or - An MN-FA SRES extension and an MN-HA SRES extension, or - An MN-FA SIM Key Request extension and an MN-HA SRES extension, or - An MN-FA SRES extension and an MN-HA SIM Key Request extension. A Registration Reply may contain: - An MN-FA SIM Key Reply extension, or - An MN-HA SIM Key Reply extension, or - A MN-FA SIM Key Reply extension and an MN-HA SIM Key Reply extension. 4.1. MN-FA SIM Key Request Extension The format of this extension is shown below in Figure 2. The mobile node may place the MN-FA SIM Key Request extension after the Mobile-Home authentication extension and before the Mobile- Haverinen et al. Expires December 2000 [Page 9] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Foreign authentication extension (if present). The foreign agent must remove this extension from the request before forwarding the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime Proposal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 MN-FA SIM Key Request extension Type 40 (not skippable) STC Subtype MN_FA_NEW_SESSION_KEY_REQUEST_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 28 Mobile Node SPI SIM_SECURITY_CONTEXT_SPI (Section 5.1) NonceMN A random number generated by the mobile node (16 bytes). (Section 3.1) Key Lifetime Proposal MN's key lifetime proposal in seconds (four bytes). 4.2. MN-HA SIM Key Request Extension The format of this extension is shown below in Figure 3. Haverinen et al. Expires December 2000 [Page 10] Internet Draft GSM SIM Authentication for Mobile IP June 2000 The mobile node may place the MN-HA SIM Key Request extension before the Mobile-Home authentication extension. 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 3 MN-HA SIM Key Request extension Type 42 (not skippable) STC Subtype MN_HA_NEW_SESSION_KEY_REQUEST_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 28 Mobile Node SPI SIM_SECURITY_CONTEXT_SPI (Section 5.1) NonceMN A random number generated by the mobile node (16 bytes). (Section 3.1) Key Lifetime Proposal MN's key lifetime proposal in seconds (four bytes). 4.3. MN-FA SIM Key Reply Extension The format of this extension is shown below in Figure 4 (successful case) and Figure 5 (unsuccessful case). Haverinen et al. Expires December 2000 [Page 11] Internet Draft GSM SIM Authentication for Mobile IP June 2000 The foreign agent may insert the MN-FA SIM Key Reply extension in a Registration Reply after the Mobile-Home authentication extension and before the Mobile-Foreign authentication extension (if present). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_RAND | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n*RAND ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The MN-FA SIM Key Reply extension (successful case) Type 41 (non-skippable) STC Subtype MN_FA_NEW_SESSION_KEY_REPLY_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 40 + the size of n*RAND Key Lifetime Remaining key lifetime in seconds (4 bytes). Must be greater than zero. Haverinen et al. Expires December 2000 [Page 12] Internet Draft GSM SIM Authentication for Mobile IP June 2000 NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request (16 bytes) MAC_RAND The authenticator for n*RAND and Key Lifetime, 16 bytes. (Section 3.1) n*RAND n GSM RANDs (length n *16 bytes) (Section 3.1). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 The MN-FA SIM Key Reply extension (unsuccessful case) Type 41 (non-skippable) STC Subtype MN_FA_NEW_SESSION_KEY_REPLY_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 26 Key Lifetime 0 (indicates failure) (4 bytes) Haverinen et al. Expires December 2000 [Page 13] Internet Draft GSM SIM Authentication for Mobile IP June 2000 NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request (16 bytes) Error code The MN-FA SIM Key Reply and MN-HA SIM Key Reply extensions use the following error codes: 1 Reason unspecified 2 Operator does not have a roaming agreement with user's home operator. 3 Users calls are barred. 4 Insufficient resources. 5 User does not have the service subscribed. 4.4. MN-HA SIM Key Reply Extension The format of this extension is shown below in Figure 6 (successful case) and Figure 7 (unsuccessful case). The home agent may insert the MN-HA SIM Key Reply in a Registration Reply before the Mobile-Home authentication extension. Haverinen et al. Expires December 2000 [Page 14] Internet Draft GSM SIM Authentication for Mobile IP June 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_RAND | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n*RAND ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The MN-HA SIM Key Reply extension (successful case) Type 43 (non-skippable) STC Subtype MN_HA_NEW_SESSION_KEY_REPLY_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 40 + the size of n*RAND Key Lifetime Remaining key lifetime in seconds (4 bytes). Must be greater than zero. NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request (16 bytes) Haverinen et al. Expires December 2000 [Page 15] Internet Draft GSM SIM Authentication for Mobile IP June 2000 MAC_RAND The authenticator for n*RAND and Key Lifetime, 16 bytes. (Section 3.1) n*RAND n GSM RANDs (length n *16 bytes) (Section 3.1). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 The MN-HA SIM Key Reply extension (unsuccessful case) Type 43 (non-skippable) STC Subtype MN_HA_NEW_SESSION_KEY_REPLY_SUBTYPE (Section 5.2) Length Length of this extension in bytes = 26 Key Lifetime 0 (indicates failure) (4 bytes) NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request (16 bytes) Haverinen et al. Expires December 2000 [Page 16] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Error code The MN-HA SIM Key Reply uses the same error codes as the MN-FA SIM Key Reply (Section 4.3). 4.5. MN-FA SRES Extension The format of the MN-FA SRES extension is shown below in Figure 8. The mobile node may place the MN-FA SRES extension in a Registration Request after the Mobile-Home authentication extension and before the Mobile-Foreign authentication extension (if present). The foreign agent 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_SRES | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 The MN-FA SRES extension Type 40 (not skippable) STC Subtype MN_FA_SRES_ KEY_REQUEST_SUBTYPE (Section 5.2) Length The length of this extension in bytes = 40 Haverinen et al. Expires December 2000 [Page 17] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Mobile Node SPI Not used. Set to 0 on sending, ignored on reception NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request and SIM Key Reply (16 bytes). MAC_SRES The response calculated by the mobile node, 16 bytes (Section 3.1). 4.6. MN-HA SRES Extension The format of the MN-HA SRES extension is shown below in Figure 9. The mobile node may place the MN-HA SRES extension with in a Registration Request before the Mobile-Home authentication extension. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | nonceMN | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MAC_SRES | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 The MN-HA SRES extension Type 42 (not skippable) STC Haverinen et al. Expires December 2000 [Page 18] Internet Draft GSM SIM Authentication for Mobile IP June 2000 Subtype MN_HA_SRES_ KEY_REQUEST_SUBTYPE (Section 5.2) Length The length of this extension in bytes = 40 Mobile Node SPI Not used. Set to 0 on sending, ignored on reception NonceMN NonceMN is used as a "transaction" identifier, so this is the same random number that was used in the SIM Key Request and SIM Key Reply (16 bytes). MAC_SRES The response calculated by the mobile node, 16 bytes (Section 3.1). 5. IANA Considerations 5.1. Well-Known SPI Values GSM SIM authentication support uses the following well-known SPI values, which belong to the reserved SPI numbering space defined in [5]. NEW_SESSION_KEY_SPI 10 SIM_SECURITY_CONTEXT_SPI 11 5.2. Generalized Key Distribution Extension Subtypes GSM SIM authentication support requires the following six 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_NEW_SESSION_KEY_REQUEST_SUBTYPE 15 STC MN_FA_NEW_SESSION_KEY_REPLY_SUBTYPE 16 STC MN_FA_SRES_ KEY_REQUEST_SUBTYPE 17 STC Haverinen et al. Expires December 2000 [Page 19] Internet Draft GSM SIM Authentication for Mobile IP June 2000 MN_HA_NEW_SESSION_KEY_REQUEST_SUBTYPE 18 STC MN_HA_NEW_SESSION_KEY_REPLY_SUBTYPE 19 STC MN_HA_SRES_ KEY_REQUEST_SUBTYPE 20 STC 6. Security Considerations The extensions in this document are intended to provide the appropriate level of security for Mobile IP entities (mobile node, foreign agent, and home agent) to operate Mobile IP registration protocol using authentication 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. 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 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 and Tapio Suihko of VTT Technical Research Centre of Finland for their comments and contributions. 9. References [1] C. Perkins and P. Calhoun, "Generalized Key Distribution Extensions for Mobile IP", draft-ietf-mobileip-gen-key-00.txt, Work in progress, February 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 Haverinen et al. Expires December 2000 [Page 20] Internet Draft GSM SIM Authentication for Mobile IP June 2000 [3] 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 [4] S. Bradner, "Key words for use in RFCs to indicate Requirement Levels", RFC 2119, March 1997. [5] C. Perkins, Editor, "IP Mobility Support", RFC 2002bis, Work in progress, March 2000. [6] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 [7] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC2104, February 1997 [8] C. Perkins and P. Calhoun, "Mobile IP Network Access Identifier Extension", draft-ietf-mobileip-mn-nai-05.txt, Work in progress, October 1999 [9] B. Aboba and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. 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 et al. Expires December 2000 [Page 21]