Mobile IP WG Franck Le
INTERNET-DRAFT Stefano M. Faccin
Date: 23 February 2001
Expires: 23 August 2001 Nokia Research Center
Temporary Shared Key Function for secure delegation of security to the
local network
<draft-le-mobileip-sharedsecret-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
When roaming to other domains, mobile nodes (clients) need to offer
credentials to a local AAA server in order to be granted access to
the local network. Security association may need to be set up
between the mobile nodes and entities of the visited domain (e.g.
between the MN and Home Agent when Home Agent is assigned in the
visited network, or between the MN and Mobility Agents when
extensions [1], [2] to Mobile IP are used). These security
associations have a lifetime that when expired, needs to be
refreshed. In addition, network operators need the ability to force
a MN to provide authentication information anytime during a session.
Le, Faccin [Page i]
INTERNET-DRAFT Mobile IP 23 February 2001
The home network and/or the visited network need to have this
capability. In the same way, the mobile node may want to challenge
the network at any time e.g. to avoid man in the middle attacks. All
these procedures require the involvement of the AAA-H since only the
MN and the home domain share a long term key. This implies that
several message round trips between the visited and home domains are
needed to support the above mentioned authentication and key
distribution procedures. This document introduces the concept of a
MN specific Temporary Shared Key (TSK) between the AAA-L and MN, thus
allowing authentication and key distribution control to be securely
performed by the visited domain. In this way, the AAA-L can set up
security associations to be shared between the MN and entities of the
visited domain, and perform network and user entity authentication
without having to involve the home network, yet, such procedures are
performed securely because the user-specific Temporary Shared Key was
created by the MN and the home domain.
Le, Faccin [Page ii]
INTERNET-DRAFT Mobile IP 23 February 2001
1. Introduction
When roaming to other domains, mobile nodes (clients) need to offer
credentials to a local AAA server in order to be granted access to
the local network. Security association may need to be set up
between the mobile nodes and entities of the visited domain (e.g.
between the MN and Home agent when Home agent is assigned in the
visited network, or between the MN and Mobility agent when extensions
[1], [2] to Mobile IP are used). These security associations have
lifetime and, when expired, need to be refreshed. The visited
network may also want to authenticate the MN at any time and in the
same way, the mobile node may want to challenge the network. All
these procedures require the AAA-L to invoke the AAA-H in order to
perform authentication and key distribution. In fact, only the MN and
the home domain share a long term key that can support authentication
of the MN or of the network, thus AAA-h needs to be involved. This
implies that several message round trips between the visited and home
domains are needed to support the above mentioned authentication
procedures.
This document introduces the concept of a user-specific Temporary
Shared Key (TSK) between the AAA-L and MN, thus allowing
authentication and key distribution control to be securely performed
by the visited domain. In this way, the AAA-L can set up security
associations to be shared between the MN and entities of the visited
domain, and perform network and user entity authentication without
having to involve the home network of the MN but, at the same time,
performing such procedures securely due to the fact that the user-
specific TSK was created by the MN and the home domain.
In some cellular systems such as the ones built according to the
IS-41 standards, concepts similar to the Temporary Shared Key
Function had been defined. Such a function encompasses the processes
by which the authentication center in the home network and the
serving (visited) system manage the sharing of authentication
responsibilities for a visiting MS. Temporary Shared Key (TSK)
sharing gives the visited system significant local control over the
authentication of a visiting MS. Specifically, thanks to TSK, the
visited system can control the following network functions without
having to involve the Home network:
- set up of security keys between the mobile node and entities
within the visited domain (key distribution)
- MN Authentication at any time
- Network authentication at any time.
Le, Faccin [Page 1]
INTERNET-DRAFT Mobile IP 23 February 2001
The concept of Temporary Shared Key Function would enable the AAA-L
to support user authentication, key distribution and network
authentication without having to involve the AAA-H. This would allow
for less round trips between the visited and home domains, thus
reducing time delay and load over the network.
To allow TSK sharing between the MN and AAA-L, the MN and the AAA-L
must have a common algorithm to compute authentication data and
session keys. In case multiple algorithms are available, a
negotiation needs to take place between MN and AAA-L to select one.
2. TSK sharing option
The TSK is optional and can be shared or not between the home domain
and the visited domain depending on network policies and roaming
agreements: In order to maximize the security, there may be cases in
which the home domain will not be willing to share the TSK with the
visited domain. This may happen when, as an example, the mobile node
moves to a visited domain that the home domain does not trust
sufficiently or with which the home domain does not have a roaming
agreement covering the TSK mechanism. Also, there may be cases when
the visited domain does not have an authentication and key
distribution algorithm in common with the mobile node and thus the
TSK cannot be used.
The TSK is a possible optimization to the security procedures in
particularly considering the signaling involved between the Visited
and the Home networks, but whether the Temporary Shared Key is
provided to the Visited Domain depends on the Home network.
3. Definitions
Data Origin Authentication:
Data Origin authentication is a type of authentication whereby a
party is corroborated as the (original) source of specified data
created at some tim in the past. Data origin authentication
includes data integrity.
Entity Authentication:
Entity authentication is the process allowing one party (the
verifier) to gain assurances that the identity of another (the
Le, Faccin [Page 2]
INTERNET-DRAFT Mobile IP 23 February 2001
claimant) is as declared, thereby preventing impersonation.
Perfect forward Secrecy:
A protocol is said to have perfect forward secrecy if compromise
of long-term keys does not compromise past session keys.
4. Computation and Distribution of the TSK
4.1. Initial Authentication and Initiation of Temporary Shared Key
Function
When the MN enters a new visited domain and first registers, its Home
AAA server is invoked to verify the validity of the user and if the
visited and home domains decide to use the Temporary Shared Key
concept, the Temporary Shared Key must be updated and distributed.
It is opinion of the authors that the AAA-H SHOULD perform a
Temporary Shared Key update process at least every time the MN is
entering a new visited domain. Otherwise the pevious visited domain
has the value of the Temporary Shared Key and can act of behalf of
the MN and perform undesirable things.
The Temporary Shared Key computation and distribution can be
integrated to the entity authentication at the first registration as
follow:
Le, Faccin [Page 3]
INTERNET-DRAFT Mobile IP 23 February 2001
Router
+.......................+
Host . UCP CP . AAAL AAAH
| LC . | | . | |
|<--------------------| | . | |
|AAA Req: LC,RPI,ID,CR,HC | . | |
|-------------------->| | . | |
| . | AHR (LC, HC) . | |
| . |- - - - - - - - |- - - - - - - - >|AHR(LC,HC)
| . | | . |- - - >|
| . | | . AHA(RANDTSK,TSK,AUTHNET)
| . | AHA (RANDTSK, AUTHNET) |< - - -|
| . |<- - - - - - - -| -.- - - - - - - | |
| . | Update config | . | |
| . |--------------->| . | |
| . | | . | |
| . | | . | |
| . | | . | |
|AAA Rep: stat,RPI, RANDTSK, AUTHNET) | . | |
|<--------------------| | . | |
| . | | . | |
+.......................+
LC = Local AAA Challenge
HC = Host Challenge generated by the MN to authenticate the network
RPI = Replay Protection Indicator used between host and AAAH
CR = AAA Credential
ID = Client Identifier
AUTHNET = Authentication data computed by the network
UCP = Uncontrolled part
CP = Controlled part
AHR = AAA Host Request (using an AAA protocol)
AHA = AAA Host Answer (using an AAA protocol)
As described in [1] and [7], the MN uses the Local Challenge to
compute some authentication data [1] and can derive some temporary
ciphering and integrity protection keys from that Local Challenge and
the long term key shared between the MN and its Home AAA server [7].
The MN also generates a Host challenge to require network
authentication. Then the MN encrypts and integrity protects the
message using the temporary security keys and leaving its Identity
(e.g. the NAI) in cleartext.
The AAA-V forwards the message to the AAA-H including the Local
Challenge. From the Local Challenge and the user specific shared
Le, Faccin [Page 4]
INTERNET-DRAFT Mobile IP 23 February 2001
long-term key retrieved thanks to the user's NAI, the AAA-H derives
the ciphering and integrity protection keys and decrypts the message.
It verifies the validity of the user, computes some network
authentication data from the Host Challenge, and eventually generates
some keying material. At that point, if the AAA-H and AAA-V decide
to use the Temporary Ciphering Key, the AAA-H generates a new random
number called the the RandomVariableTSK (RANDTSK) and executes the
algorithm shared with the MN using the long term shared key to
compute the new "pending" TSK. The AAA-H sends the RANDTSK to the MN
and sends the corresponding Temporary Shared Key to the AAA-V. The
AAA-H can use the temporal keys to protect the response to the MN and
uses inter AAA servers security to protect the message to the AAA-V.
The MN receiving the response, decrypts it using the Temporal
Ciphering and Integrity protection keys, and verifies the
authenticity of the network thanks to the network authentication data
computed from the Host Challenge. If RANDTSK is provided to the MN,
the MN derives, from the long term key and the common algorithm
shared with its AAA-H server, the corresponding TSK to use for
subsequent entity authentication and key distribution procedures.
The MN receives the RANDTSK in the message carrying the network
authentication data and can therefore be sure that the information is
coming from its Home network. In addition, RANDTSK is protected
using the Temporal ciphering and integrity protection keys thus
increasing the level of security.
The TSK is thus updated every time the MN is entering a new Domain
but in addition, the Home network MUST be able to update the TSK at
any time when the MN is in a visited domain and the TSK is shared: As
an example, the TSK may get corrupted and the Home network MUST be
able to revocate the TSK by performing a new TSK update.
In the following section the description of the procedures relevant
for the TSK update while the MN is in a session is provided.
4.2. Temporary Shared Key Update
The Temporary Shared Key (TSK) Update function encompasses the
processes by which the TSK in a MN is changed to a new value under
the direction of the AAA-H. Only the AAA-H may initiate this
operation when the TSK is shared with the serving system.
On the network side, a user authentication process could be executed
immediately after the TSK Update to confirm that the target MN has
successfully changed its TSK: the network sends a challenge to the MN
Le, Faccin [Page 5]
INTERNET-DRAFT Mobile IP 23 February 2001
and based on the expected received authentication data that MUST be
from the TSK, the network cam make sure the TSK update had been
successful and the MN is having the new TSK value. This would ensure
that the MN will be able to authenticate itself and the network in
the future.
On the MN side, the MN initiates a network authentication procedure
when the MN is directed by the network to change its TSK. This
authentication procedure allows the MN to authenticate the network
issuing the TSK Update, thus preventing a fraudulent network from
disrupting the normal network operation by forcing the MN's TSK out
of alignment with the legitimate network TSK.
The TSK update includes AAA-H TSK update process and the serving
system TSK update process.
4.2.1. AAA-H TSK update process
The AAA-H may initiate the TSK update process at any moment when the
MN is in a visited domain and is sharing TSK. The decision on when
the TSK is updated is based on home domain policies. TSK should not
be changed too often, otherwise the benefits of TSK disappear. At the
same time, TSK must have a lifetime to ensure that the same TSK is
not used for too long. The first step in the TSK update process is
for the AAA-H to execute the algorithm shared with the MN using the
long term shared key and a random number, called the
RandomVariableTSK (RANDTSK). The result is the new "pending" TSK.
The AAA-H then sends the RANDTSK and the new TSK to the AAA-L. The
AAA-H then waits for a report from the AAA-L.
With the RANDTSK and the new TSK, the AAA-L can:
- update the TSK in the MN
- respond to the network authentication request from the MN
- verify the update by issuing a user specific authentication
procedure to the MN
4.2.2. Serving system Temporary Shared Key update process
The serving system begins the TSKupdate process when it receives the
RANDTSK parameter from the AAA-H. The message also contains either
the new TSK Key.
Le, Faccin [Page 6]
INTERNET-DRAFT Mobile IP 23 February 2001
- The AAA-L directs the serving router to send a TSK Key update
order, including RANDTSK, to the MN.
- The MN responds with a network authentication request including
the challenge selected by the MN, RANDNET
- the AAA-L executes the shared algorithm using as inputs the
MN's challenge RANDNET, and the new TSK. The result of the
calculation is AUTHNET which is sent to the MN.
- Depending if AUTHNET equals to the expected corresponding
result the MN indicates a successful or an unsuccessful
TSKupdate in a message to the AAA-L
- If successful, the serving system executes the user specific
authentication procedure; otherwise AAA-L reports the failure
to the AAA-H.
Le, Faccin [Page 7]
INTERNET-DRAFT Mobile IP 23 February 2001
Host AAA-L AAA-H
| | |
| | AAA TSK Update Req
| |<------------------|
| |RANDTSK, AUTHU, RANDU
| | |
| | AAA TSK Reply |
|AAA TSK Update Req----------------->|
|<---------------| |
| [RANDTSK] | |
| | |
| AAA Net. Auth. Request |
|--------------->| |
| [RANDNET] | |
| | |
| | |
|AAA Net.Auth.Rep. |
|<---------------| |
| [AUTHNET] | |
| | |
|AAA TSK update Reply |
|--------------->| |
| [success] | |
| | |
|AAA user auth. req |
|<---------------| |
| [RANDU] | |
| | |
| AAA user auth. Repl. |
|--------------->| AAA Report |
| [AUTHU] |------------------>|
| | |
| | AAA Report ack |
| |<------------------|
| | |
5. Entity authentication and key distribution using the TSK
This section describes how the TSK sharing enables the Visited domain
to perform entity authentication and key distribution without
involving the home network thus reducing the time delay and the
signaling between the two domains.
Le, Faccin [Page 8]
INTERNET-DRAFT Mobile IP 23 February 2001
5.1. User authentication using TSK
Currently, as described in section 3.4 [3], the AAA credential is
created by the client and is verified by AAA-H. The creation and
verification is based on a long-term security association shared
between the client and AAA-H. The credential SHOULD securely bind the
following pieces of information:
- client identifier,
- local AAA challenge, if one was provided by the attendant, and
- depending on the style of replay protection being used between
the host and AAAH, either a timestamp or a pair of challenges.
In specific instantiations, additional data may be included in the
computation of the AAA Credential.
The exact algorithm used to compute the AAA Credential depends on the
security association between the client and AAAH.
The authentication data is thus computed using a long-term key shared
between the MN and the AAA-H, some other information and an
algorithm.
When the TSK mechanism is used, the MN takes the same inputs but
instead of using the long term key it shares with its AAA-H, the MN
uses the TSK it shares with the AAA-L and the shared algorithm. The
visited system having the TSK and the shared algorithm can then
authenticate the MN without invoking its home network.
5.2. Network authentication using TSK
The MN may want to authenticate the network and thus use the Host
Challenge to challenge the network. In such case, the MN expects a
network authentication data computed by the AAA-H using the Host
Challenge and currently, the long term shared key. The exact
algorithm used to compute the AAA Credential depends on the security
association between the client and AAAH.
If the TSK mechanism is used, the MN sends the Host Challenge to
authenticate the network and the AAA-L applies the common algorithm
to the Host Challenge and the TSK to compute the authentication data,
i.e. the network authentication data.
Network authentication is thus provided without involving the AAA-H.
Le, Faccin [Page 9]
INTERNET-DRAFT Mobile IP 23 February 2001
5.3. Key distribution using TSK
The key distribution (e.g. between the MN and HA when HA is assigned
in the visited network, or between the MN and Mobility agent when
extensions [1], [2] to Mobile IP are used) is usually based on the
long-term security association between the MN and its AAA-H. This
security association is used to create derivative security
associations between the mobile node and other entities in the
visited domain.
When TSK is shared, the MN receives the indication that TSK is to be
used, and therefore the MN uses the TSK to compute the keys instead
of the long-term key. In this way, since the AAA-L uses the temporary
shared key as well, the keys will be available to MN and AAA-L and
AAA-L does not need to involve the Home network in the procedures.
6. Comparison with existing earlier solutions
Previous Request For Comments and Internet Drafts documents specify
extensions and suggest mechanisms to distribute the session keys to
be shared between the mobile node and mobility agents. Those
security associations are to provide data origin authentication of
the Binding update and binding acknowledgement messages as required
by Mobile IPv6.
But when the lifetime of these session keys expires, a new key
distribution procedure (e.g. as defined in [4]) needs to be executed
involving the home network. The message round trips between the
serving and home domain imply time delays, and increase the load over
the network. To avoid these issues, one possible solution seems to
give longer lifetime to the session keys. But long lifetime session
keys have higher risks to get compromised and thus, a key revocation
procedure needs to be defined to solve this induced problem.
Refreshing short-time keys is preferrable (same concepts are adopted
in Kerberos [5] and in cellular networks) and the Temporary Shared
Key mechanism enables to refresh short-time session keys without
having to involve the Home network.
The Temporary Shared Key sharing is therefore an enhancement and
optimization of the existing schemes.
In addition, the keys defined in current proposals are used to
provide data origin authentication, but the home and the visited
domain should be able to perform entity authentication for the mobile
node based on challenge response based mechanism [6].
Le, Faccin [Page 10]
INTERNET-DRAFT Mobile IP 23 February 2001
The Temporary Shared Key enables to perform that user entity
authentication, and network entity authentication without involving
the Home network.
7. Pros and Cons of the Temporary Shared Key sharing
The Temporary Shared Key sharing is a function enabling the serving
system to securely perform entity authentication and key distribution
functions with the MN on behalf of the home network but without
having to involve the home network, thus saving round trips between
the visited and home networks and reducing time delay and network
load.
This mechanism enables to provide strong network authentication such
as challenge response based mechanism without having to involve the
AAA-H.
It is a possible optimization and the home and visited system can
decide to use it or not based on policies and common agreements.
The only requirement of this Temporary Shared Key is to have a common
algorithm between the MN and the AAA-L to perform authentication and
key distribution.
8. Messages format
AAA Protocol messages
The Temporary Shared Key sharing requires new messages; they have the
following general structure.
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 = TBD | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message body |
+ +
Le, Faccin [Page 11]
INTERNET-DRAFT Mobile IP 23 February 2001
Type The following new types are defined:
AAA TSK Update Request: TBD
AAA TSK Update Reply: TBD
AAA Network Auth. Request: TBD
AAA Network auth. Reply: TBD
AAA User auth. Request: TBD
AAA User auth. Reply: TBD
AAA Report
Code The Code field depends on the message type.
- AAA TSK Update Reply
SUCCESS: 0
FAILURE: 1
- For AAA Report
SUCCESS: 0
FAILURE: 1
These messages could be defined either as new ICMPv6 messages or as
Destination Option to Mobile IPv6 between the MN and AAA-L and as
DIAMETER messages between AAA-L and AAA-H.
9. Security Considerations
This document introduces the concept of securely delegating part of
the security functions to the Visited domain to avoid delays in
authentication and key distribution procedures and reduce signaling
load between the visited and home Domains. The Temporary Shared Key
mechanism is an optimization that AAA-L and AAA-H may decide to use
or not based on policies and roaming agreements.
10. Intellectual Property Considerations
Nokia Corporation and/or its affiliates hereby declare that they are
in conformity with Section 10 of RFC 2026. Nokia's contributions may
contain one or more patents or patent applications. To the extent
Nokia's contribution is adopted to the specification, Nokia
undertakes to license patents technically necessary to implement the
specification on fair, reasonable and nondiscriminatory terms based
on reciprocity.
Le, Faccin [Page 12]
INTERNET-DRAFT Mobile IP 23 February 2001
11. References
[1] Jari T. Malinen and Charles E. Perkins. Mobile IPv6
Regional Registrations. Internet Draft, Internet
Engineering Task Force, December 2000.
[2] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and
Ludovic Bellier. Hierarchical MIPv6 mobility management.
Internet Draft, Internet Engineering Task Force, September,
2000.
[3] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas
Eklund AAA for IPv6 Network Access. Internet Draft,
Internet Engineering Task Force, January 2000.
[4] Charles E. Perkins and Pat R. Calhoun. AAA Registration
Keys for Mobile IP. Internet Draft, Internet Engineering
Task Force, January 2001.
[5] Clifford Neuman, John Kohl and Theodore Ts'o. The Kerberos
Network Authentication Service (V5). Internet Draft,
Internet Engineering Task Force, November 2000.
[6] Franck Le, Raj Patil and Stefano M. Faccin. Challenge-
Response Authentication Request. Internet Draft, Internet
Engineering Task Force, February 2001.
[7] Franck Le and Stefano M. FaccinKey distribution for Mobile
IPv6. Internet Draft, Internet Engineering Task Force,
February 2001.
Le, Faccin [Page 13]
INTERNET-DRAFT Mobile IP 23 February 2001
12. Authors' Addresses
Franck Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-1256
E-mail: franck.le@nokia.com
Stefano M. Faccin
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4994
E-mail: stefano.faccin@nokia.com
Le, Faccin [Page 14]
INTERNET-DRAFT Mobile IP 23 February 2001
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. TSK sharing option . . . . . . . . . . . . . . . . . . . . . . . 2
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Computation and Distribution of the TSK . . . . . . . . . . . . . 3
4.1. Initial Authentication and Initiation of Temporary
Shared Key Function . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Temporary Shared Key Update . . . . . . . . . . . . . . . . 5
4.2.1. AAA-H TSK update process . . . . . . . . . . . . . . . 6
4.2.2. Serving system Temporary Shared Key update process
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Entity authentication and key distribution using the TSK . . . . 8
5.1. User authentication using TSK . . . . . . . . . . . . . . . 9
5.2. Network authentication using TSK . . . . . . . . . . . . . . 9
5.3. Key distribution using TSK . . . . . . . . . . . . . . . . . 10
6. Comparison with existing earlier solutions . . . . . . . . . . . 10
7. Pros and Cons of the Temporary Shared Key sharing . . . . . . . . 11
8. Messages format . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Intellectual Property Considerations . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Le, Faccin [Page iii]