Internet DRAFT - draft-haverinen-mobileip-gsmsim

draft-haverinen-mobileip-gsmsim





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]