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]