Internet DRAFT - draft-le-aaa-lsa-tsk
draft-le-aaa-lsa-tsk
AAA WG Stefano M. Faccin
INTERNET-DRAFT Franck Le
Date: July 2001 Nokia Research Center
Expires: January 2002
AAA Local Security Association (LSA): The Temporary Shared Key (TSK)
<draft-le-aaa-lsa-tsk-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
This document describes a mechanism to set up a Local Security
Association (LSA) between a user and the visited network when the
user is roaming. It defines all the required related functionalities
such as the key generation, distribution and update procedures; it
also describes the reasons and the benefits of the adoption of such
LSA. The applicability of this draft is mainly for AAA Diameter and
for URP (User Registration Protocol), but the mechanism can be
adopted more in general in each case where the user (or mobile node)
needs to establish a security association with a foreign domain while
roaming.
Faccin, Le [Page i]
INTERNET-DRAFT AAA LSA TSK July 2001
Faccin, Le [Page ii]
INTERNET-DRAFT AAA LSA TSK July 2001
1. Introduction
When roaming to foreign domains, users need to be authorized by the
foreign domain to get access to the local resources. The
authorization generally implies that the user offers her/his
credentials to a local agent (e.g. a local AAA server) in order to
verify if the user is authorized (e.g. by roaming agreement between
ISPs) and to authenticate the user.
In general, when a user is roaming security associations (SA), may
need to be set up between the user and agents of the visited domain.
E.g. an SA may be needed between the user and the access router to
protect data (confidentiality and integrity protection) over the
access link.
As another example, in the context of Mobile IP, an SA may be
needed between the Mobile Node (MN) and the Home Agent (HA) when
the Home Agent is assigned in the visited network, or between the
MN and Mobility Agents when a Localized Mobility Management
solution such as [1] or [2] is deployed).
These security associations typically have a restricted lifetime, and
when expired, they need to be refreshed.
In addition, in order to avoid frauds, service providers need the
ability to force a user to provide authentication information anytime
during a session. Both the home service provider and the visited
service provider need to have this capability.
In the same way, to achieve better overall security the mobile node
may want to challenge the network at any time e.g. to avoid network
impersonation attacks, man in the middle attacks, etc. All these
procedures require the involvement of the Home AAA server, AAAh,
since only the user and its home domain share a long-term key. This
implies that several message round trips are needed between the
visited and home domains in order to support the above mentioned
authorization/authentication and key distribution procedures. If the
authentication and key distribution procedures are abused (e.g.
performed too often), these message exchanges between the home and
visited networks may create an excessive signaling load between the
AAAh and AAAv, and may add delay in the procedure. Although
authentication/authorization procedures require in some situation the
involvement of home and visited domains (e.g. when the user roams for
the first time to a foreign ISP and tries to get access), in several
cases the adoption of an LSA allows for optimizations and empowers
the visited service provider to authenticate the user at any time and
perform key distribution without the involvement of the home domain,
Faccin, Le [Page 1]
INTERNET-DRAFT AAA LSA TSK July 2001
while still maintaining a good level of security.
In some cellular systems such as the ones built according to the
IS-41 standards, concepts similar to the Local Security Association
have been defined. In IS-41 the functionality defined for LSA
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 mobile station by
creating a temporary key that the mobile node and the visited system
will share, and providing mechanisms to distribute it, refresh it and
withdraw it. The sharing of this key gives the visited system
significant local control over the authentication of a visiting
mobile station. Moreover, it introduces optimizations in terms of
signaling load towards the home system and delay involved in the
authentication procedure.
This document introduces the concept of a user specific LSA called
Temporary Shared Key (TSK) established between between the visited
network and the user. The TSK is established between the user and the
visited domain with the involvement of the home domain, and allows to
delegate functions such as entity authentication and key derivation
to the visited domain, while performing such procedures securely
because the user-specific Temporary Shared Key was created under the
control of the home domain and securely distributed to the visited
domain and the user.
This document moreover specifies the extensions for the Diameter
protocol to support the establishment of an LSA through the TSK.
2. Assumptions
2.1. Assumptions
The security model for the TSK is represented in Figure 1 and is
based on a set of key entities:
The AAA Client (AAAc) is the function that allows the user to be
authenticated and authorized by the visited network service provider
in order to gain access to IP connectivity in the visited domain. In
order to achieve this, the user provides its identity and
authentication data to the AAAc in the local network, which then uses
an AAA infrastructure to authenticate and authorize the user for
usage of resources, and eventually transport other information. The
specific details of the exchange between the user and the AAAc of
authentication data (e.g. type of data, number of exchanges) is based
on the specific authentication algorithm adopted. The AAAc can be an
attendant, e.g. located in the default router or access router (the
Faccin, Le [Page 2]
INTERNET-DRAFT AAA LSA TSK July 2001
first router visible to the user in the network), the Registration
Agent as defined in [12], [13], or can be any server located in the
network. The mechanism defined in this draft applies to all this
cases. In the rest of the document, this entity will be referred to
AAAc for sake of generality.
Visited Domain Home Domain
+--------+ +--------+
|abc.com | (SA1) |xyz.com |
| AAAv |<------------------->| AAAh |
+->| server | server-server | server |
| +--------+ communication +--------+
| ^
(SA2)| | (SA4)
| |
v v
+---------+ (SA4)+---------+
| AAA |<---->| Agent |
| Client | |(peer-entity)
+---------+ +---------+
^
|
|
v
+--------+
| Mobile |
| Node | mn@xyz.com
+--------+
Figure 1. The Security Model
The AAA infrastructure assumed in this draft is based on a network of
AAA servers, and in particular the model considers the AAAv, i.e. the
AAA server in the visited network, and the AAAh, i.e. the AAA server
in the home network of the MN.
Number of protocols also locates an "agent" (peer entity) in the
network in order to deliver data packets to, or exchange protocol-
specific signaling messages with, the user terminal. Mobile IP, IP
Paging and SIP are examples of such protocols. Any of those agent-
based protocols have a requirement or a recommendation to have a
security key between a user terminal and an agent, which is used by
the agent and the user terminal to authenticate and/or encrypt
signaling messages exchanged between them. This shared key, between
the user terminal and the agent of each protocol in the visited
domain, usually cannot be pre-established but must be dynamically
established. Authentication may be required before the key
distribution is performed.
Faccin, Le [Page 3]
INTERNET-DRAFT AAA LSA TSK July 2001
The security model is based on a set of security associations between
the entities in the model. Some of these security associations are
pre-established i.e. are and constitute the basis of the security
model:
* it is assumed that the home and the visited domains share a long-
term security association (shown in Figure 1 as SA1) that is not
specific to any particular user and that can be either dynamically
set up or established off line as a result of a roaming agreement
between the two networks. The mechanism adopted to set up such SA
is outside the scope of this draft. In this document it is assumed
in particular that SA1 exists between AAAh and AAAv. This security
association is used by the AAA servers in the two networks to
exchange information in a secure and mutually authenticated
fashion;
* it is assumed that each network has its own security mechanism and
security associations (shown in Figure 1 as SA2 and SA4) allowing
entities in the same network to communicate in a secure and
mutually authenticated way (e.g. using IPSEC and a local Public
Key Infrastructure);
* it is assumed that each user, as a result of a subscription
agreement with a home domain, has a long-term security association
(SA3) with her/his home domain. Such security association allows
the mutual authentication between the user and the home domain. In
this document, it is assumed in particular that the user and the
AAA home server (AAAh) share a common set of algorithms and a
common set of keys. These algorithms and keys will be used to
authenticate the user to the home domain and the home domain to
the user. In case multiple algorithms are available, a negotiation
may need to take place between the user and AAAh to select one
when the user is authenticated and the TSK is
established/refreshed. SA3 can also be used to derive other
dynamic security associations as described in [4] and [7], and
this document describes the Temporary shared Key set up and update
based on SA3.
2.2. Common Algorithms
In order for an LSA to be adopted between the user and the visited
domain, the user and the visited domain must have a set of common
security algorithms that can be used to support the LSA. If the user
and the visited domain do not have algorithm in common, no LSA can be
adopted.
Faccin, Le [Page 4]
INTERNET-DRAFT AAA LSA TSK July 2001
Such algorithms are needed for:
* mutual authentication between the user and the visited domain
* ciphering and integrity protection of messages between the user
and agent in the visited domain, if such feature is required
* distribution of dynamic keys between the user and agents in the
visited domain based on the LSA.
One single algorithm could be used for these functions, thus at least
one common algorithm must be available to the user and the visited
domain. In this document it is assumed that at least one common
algorithm is available and known a priori. The case where negotiation
is needed to determine whether there is a common algorithm and what
this algorithm is, is outside the scope of this version of this
draft. It is opinion of the authors that MD5 could be the default
common algorithm used both for authentication and establishment of
dynamic keys.
3. Usage scenarios
3.1. Use of TSK
The Temporary Shared Key (TSK) is established between the user and
the visited domain with the involvement of the home domain. This
means that, during the user authentication, a TSK can be generated
and distributed as described in the following sections. Once the TSK
is available to the visited domain and the user, TSK is used for:
* authentication of the user by the visited domain, at any time;
* authentication of the visited domain by the user, at any time;
* control by the visited domain of key distribution between the user
and agents in the visited domain. Usage scenario include (but are
not limited to):
- key distribution between the user and an agent in visited
domain (e.g. Access Router) to protect the data (e.g.
encryption and integrity protection) exchanged over the access
link;
- key distribution between the user and mobility agents in the
visited domain. In the context of Mobile IP, if a Local
Mobility Management scheme is adopted (e.g. as in [1] and [2]),
the temporay key can be used to authenticate the Binding
Faccin, Le [Page 5]
INTERNET-DRAFT AAA LSA TSK July 2001
Update/Binding Acknowledgement messages
Through the use of TSK, the above functionality are performed without
the involvement of the home domain, yet such procedures are performed
securely because the user-specific Temporary Shared Key is created
under the control of the home domain and securely distributed to the
visited domain and the user.
The agent in the visited domain to which the TSK is distributed to,
could be the AAAv server, or a AAA client such as the Registration
Agent mentioned in the discussion on URP ([12], [13]).
3.2. Distribution of TSK in Visited Domain
The TSK is distributed by the home domain to the visited domain, and
in particular by the AAAh to the AAAv. Depending on the capabilities
and type of the AAAc (e.g. AAAc is an URP RA versus a MIPv4 Foreign
Agent), the TSK may or may not be provided by the AAAv to the AAAc.
Accordingly to where the TSK is distributed, the authentication and
key distribution procedures based on TSK will be performed in
different entities (e.g. AAAv versus AAAc).
4. TSK sharing option
The TSK should be considered as an optional feature, so that the use
of an LSA based on TSK can depend on network policies and roaming
agreements. In fact, 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
user moves to a visited domain that the home domain does not trust
sufficiently.
The TSK is a possible and suggested optimization to the security
procedures in particularly when considering the signaling involved
between the visited and the home domains, but whether an LSA is used
(i.e. the Temporary Shared Key is provided to the visited domain)
should depend on the home network policies.
5. Computation and Distribution of the TSK
This document focuses on the extensions to the Diameter protocol to
support the TSK mechanism, but does not specify the protocol nor the
message format used between the user and the AAAc. However, the
document identifies the parameters that need to be exchanged by the
user and the AAAc. These parameters can be carried in many ways: in
Faccin, Le [Page 6]
INTERNET-DRAFT AAA LSA TSK July 2001
IPv6 Destination Options, in ICMPv6 messages, in URP messages, by
EAP, etc. The specific protocol used to exchange such information is
outside the scope of this document.
When the user enters a new visited domain and first registers, its
AAAh server is invoked to verify the validity of the user
([10],[11])and if the visited and home domains policies allow and
suggest the use of the Temporary Shared Key, the TSK must be:
* generated: if no TSK had been previously established and
distributed, a new TSK must be generated by the home domain;
* updated: if a TSK previously established and distributed to the
user and visited domain is expired (e.g. limited lifetime) or it
was previously used in a different visited domain and for sake of
security it is policy of the home domain to generate a new TSK;
* distributed to the user and the visited domain: this applies both
to the case where the TSK is generated/updated and the case where
a previous value of TSK is used. In the latter scenario, the TSK
need only to be distributed to the visited domain, since the user
already has it, and the user needs to be informed that the
previous TSK is still valid.
It is opinion of the authors that the AAAh SHOULD update the
Temporary Shared Key update process at least every time the MN is
entering a new visited domain, otherwise the previous visited domain
has the value of the Temporary Shared Key and could act on behalf of
the user and carry out undesirable actions. The final choice should
anyway be left to network policies.
5.1. Creation and Distribution of Temporary Shared Key at Initial
Authentication
The TSK computation and distribution can be integrated with the agent
authentication at the first registration as indicated in the
following sections.
The TSK establishment procedure is independent of the authentication
mechanism used to authenticate the user. Different EAP types or
protocols can be adopted for authentication and are not described in
this draft. For sake of clarity, two cases are illustrated:
* TSK establishment combined with Mutual Challenge Response
Authentication based on Local Challenge
Faccin, Le [Page 7]
INTERNET-DRAFT AAA LSA TSK July 2001
* TSK establishment combined with Challenge Response Authentication
based on Home Challenge
5.1.1. Mutual Challenge Response Authentication based on Local
Challenge
User AAA client AAAv AAAh
| LC, VN_ID | | |
|<--------------------| | |
| ID, AUTHU, LC, HC | | |
|-------------------->| | |
| | LC,ID,AUTHU,HC,VN_ID
| |------------->| |
| | |------>|
| | RANDTSK,TSK,AUTHNET,HC
| | |<------|
| RANDTSK,AUTHNET,HC |
| |<-------------| |
| | | |
| RANDTSK,AUTHNET,HC | | |
|<--------------------| | |
| | | |
LC = Local Challenge
HC = Host Challenge
AUTHU = User authentication data
ID = User Identifier
VN_ID = Visited Network Identifier
AUTHNET = Network authentication data
This flow illustrates the TSK generation and distribution when a
mutual authentication based on challenge response is used.
As mentioned previously this document does not specify the protocol
nor the messages format between the user and the attendant but
identifies the parameters that need to be exchanged on that interface
and describes the diameter extensions and network entities
behaviours.
In this case, the user e.g. uses the Local Challenge, the Visited
Network Identifier, and the long-term key to compute some
authentication data, AUTHU.
The user may also generate a Host challenge, HC, to require network
authentication.
Faccin, Le [Page 8]
INTERNET-DRAFT AAA LSA TSK July 2001
The AAA-V forwards the message to the AAAh including the Local
Challenge and the Visited Network ID. From the Local Challenge, the
Visited Network ID and the user specific shared long-term key
retrieved thanks to the user's NAI, the AAAh verifies the validity of
the user
It then computes the network authentication data, AUTHNET, from the
Host Challenge, and eventually generates some keying material if the
AAA servers are requested to play a role in the key distribution.
At that point, if the AAAh and AAAv decide to use the Temporary
Shared Key, the AAAh generates a new random number called the the
RandomVariableTSK (RANDTSK) and executes the algorithm shared with
the MN using the long term shared key (SA3) to compute the new
"pending" TSK. The AAAh sends the RANDTSK to the MN and sends the
corresponding Temporary Shared Key to the AAAv:
The TSK-AVP can be sent in any already defined command code such as
the Diameter-EAP-Answer (DEA) Command or the AA-Mobile-Node-Answer
(AMA) Command. This AVP will carry the "pending" TSK to the visited
domain (AAAv) and therefore, the messages need to be protected
between the AAAh and the AAAv. This inter AAA security association is
out of the scope of this document.
The RandomVariableTSK (RANDTSK) can be sent, in a RANDTSK-AVP, in the
same way as the TSK-AVP, i.e. in any already defined command code
such as the Diameter-EAP-Answer (DEA) Command or the AA-Mobile-Node-
Answer (AMA) Command. The RANDTSK is intended to the user so it can
derive the corresponding TSK. The AAAc will therefore convert the
RANDTSK-AVP to the appropriate protocol to send it to the user.
As mentioned previously, the protocol between the user and the AAAc
is out of the scope of this document: The RANDTSK could be sent to
the client in a Destination Option, ICMPv6 message, BURP protocol,
etc.
The AAAh MUST use inter AAA servers security to protect the message
to the AAAv
The MN verifies the authenticity of the network thanks to the network
authentication data, AUTHNET, 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 AAAh server, the
corresponding TSK to use for subsequent agent authentication and
key distribution procedures.
Faccin, Le [Page 9]
INTERNET-DRAFT AAA LSA TSK July 2001
The User receives the RANDTSK in the message carrying the network
authentication data, AUTHNET, and can therefore be sure that the
information is coming from its Home network.
5.1.2. Challenge Response Authentication based on Home Challenge
Before distributing the TSK, authentication may be required. The
previous figure described how TSK generation and distribution can be
combined. But TSK procedures are independent to the authentication
methods and for sake of generality, TSK generation and distribution
is described combined with a Challenge Response Auethntication based
on Home Challenge such as the Authentication and Key Agreement
protocol [14]:
User AAA client AAAv AAAh
| User_ID | User_ID | |
|-------------------->|------------->|------>|
| RAND, AUTN | RAND, AUTN |RAND, AUTN
|<--------------------|<-------------|<------|
| RANDTSK | RANDTSK |RANDTSK, TSK
| | | |
| | | |
| RES | | |
|-------------------->|------------->|------>|
|<--------------------|<-------------|<------
| | | |
The authentication method SHOULD allow both user and network
authentication.
5.2. Temporary Shared Key Update Function
The previous sections described the TSK generation and distribution
but te Home network MUST also 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.
The Temporary Shared Key (TSK) Update function encompasses the
process by which the current TSK used by a user and the visited
domain is changed to a new value under the direction of the AAAh.
TSK Update applies also to the case where a user and the visited
domain do not share a TSK and a new TSK needs to be generated. Only
Faccin, Le [Page 10]
INTERNET-DRAFT AAA LSA TSK July 2001
the AAAh may initiate the update of the current value of TSK, and
AAAh can do this at any time during a session according to the home
domain policies.
On the network side, a user authentication process could be executed
immediately after the TSK Update to confirm that the target User has
successfully changed its TSK: the network sends a challenge to the MN
and based on the expected received authentication data that MUST be
from the TSK, the network can make sure the TSK update had been
successful and the User is having the new TSK value. This would
ensure that the User will be able to authenticate itself and the
network in the future.
On the User side, the User initiates a network authentication
procedure when the User is directed by the network to change its TSK.
This authentication procedure allows the User to authenticate the
network issuing the TSK Update, thus preventing a fraudulent network
from disrupting the normal network operation by forcing the User's
TSK out of alignment with the legitimate network TSK.
The TSK update includes AAAh TSK update process and the serving
system TSK update process.
5.2.1. TSK update process in AAAh
The AAAh may initiate the TSK update process at any moment when the
User 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 AAAh to execute the algorithm shared with the User using the
long term shared key and a random number, called the
RandomVariableTSK (RANDTSK). The result is the new "pending" TSK.
The AAAh then sends respectively the RANDTSK and the new TSK to the
AAAv in a RANDTSK-AVP and TSK-AVP to the AAAv: Those AVPs can be sent
in any already defined command code such as the Re-Auth-Request
(RAR). The AAAh then waits for a report from the AAAv. With the
RANDTSK and the new TSK, the AAAv can:
- update the TSK in the MN
- respond to the network authentication request from the MN
Faccin, Le [Page 11]
INTERNET-DRAFT AAA LSA TSK July 2001
- verify the update by issuing a user specific authentication
procedure to the MN
5.2.2. TSK update process in AAAv/AAAc
The serving system begins the TSK update process when it receives the
RANDTSK parameter from the AAAh. The message also contains the new
TSK Key.
- The AAAv 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 AAAv 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 AAAv
- If successful, the serving system executes the user specific
authentication procedure: It challenges the user sending it a
randomly generated number RANDU to authenticate him and make sure
the User now has the correct TSK value. The User takes RANDU and
the newly derived TSK as inputs to a shared algorithm with the
serving system and computes AUTHU. The AAAv performs the same
steps and can thus verify that the user has updated the TSK value.
Otherwise AAAv reports the failure to the AAAh.
Faccin, Le [Page 12]
INTERNET-DRAFT AAA LSA TSK July 2001
User AAA Client/AAAv AAAh
| | |
| | RANDTSK, TSK |
| |<------------------|
| | |
| | |
| RANDTSK | |
|<---------------| |
| | |
| RANDNET | |
|--------------->| |
| | |
| AUTHNET | |
|<---------------| |
| | |
| success | |
|--------------->| |
| | |
| RANDU | |
|<---------------| |
| | |
| AUTHU | |
|--------------->| AAA Report |
| |------------------>|
| | |
| | AAA Report ack |
| |<------------------|
| | |
The AAA Report can be sent in a Diameter-EAP-Request (DER) Command, and
the AAA Report ack in a Diameter-EAP-Answer (DEA) Command.
5.3. Distribution of Previously Established TSK
As described in section 5, there is the case where the User and its
Home network already have a TSK set up and want to re-use when
entering in the Visited domain. In that case:
* the TSK needs to be distributed to the visited network (from AAAh
to AAAv)
* the TSK does not need to be sent to the user since he already has
knowledge of it. But an indication still need to be provided to
the user to inform him to start using the TSK. This can e.g. be
achieved by setting a specific value in the RANDTSK field sent to
the user.
Faccin, Le [Page 13]
INTERNET-DRAFT AAA LSA TSK July 2001
User AAA client AAAv AAAh
| LC, VN_ID | | |
|<--------------------| | |
| ID, AUTHU, LC, HC | | |
|-------------------->| | |
| | LC,ID,AUTHU,HC,VN_ID
| |------------->| |
| | |------>|
| | RANDTSK,TSK,AUTHNET,HC
| | |<------|
| RANDTSK,AUTHNET,HC |
| |<-------------| |
| | | |
| RANDTSK,AUTHNET,HC | | |
|<--------------------| | |
| | | |
6. 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.
6.1. User authentication using TSK
In many current authentication mechanisms, the user computes the
authentication data based on a long-term key shared with its AAAh.
For Challenge Response based authentication mechanism, the user e.g.
takes the challenge and eventually some additional informational with
the long-term key to a hash function and thus compute the
authentication data.
The exact algorithm used to compute the AAA Credential depends on the
security association between the user and AAAh.
The authentication data is thus computed using a long-term key shared
between the user and the AAAh, some other information and an
algorithm.
When the TSK mechanism is used, the user takes the same inputs but
instead of using the long term key it shares with its AAAh, the user
uses the TSK it shares with the AAAv and the shared algorithm. The
visited system having the TSK and the shared algorithm can then
authenticate the user without invoking its home network.
Faccin, Le [Page 14]
INTERNET-DRAFT AAA LSA TSK July 2001
6.2. Network authentication using TSK
The user may want to authenticate the network and thus generates a
random number, the Host Challenge, to challenge the network. In such
case, the user expects a network authentication data computed by the
AAAh 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 user and AAAh.
If the TSK mechanism is used, the user sends the Host Challenge to
authenticate the network and the AAAv 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 AAAh.
6.3. Key distribution using TSK
Without the use of an LSA, key distribution between the user and
agents in the visited domain is usually based on the long-term
security association between the user and its AAAh. This security
association is used to create derivative security associations
between the mobile node and agents in the visited domain.
When TSK is adopted, the user receives the indication that TSK is to
be used, and therefore the user uses the TSK instead of the long-term
key to compute the keys. In this way, since the AAAc/AAAv (depending
on what agent the TSK was provided to as indicated in section 3.2)
uses the TSK as well for the key distribution, the keys will be
available to the user and to AAAc/AAAv and AAAh does not need to be
involved in the procedure.
The method used by the AAAc/AAAv to distribute the generated keys to
other agents in the visited domain is outside the scope of this
draft.
The key distribution can be based on random numbers (as e.g.
described in [4]) and in this case, the AAAc/AAAv generates the
random number and combines it with some other data such as the user
identity or IP address to form an input with the TSK to a key
derivation algorithm. The random number is transmitted to the user
which by performing the same operations and having knowledge of the
TSK, ends up with the same derived session key.
As another key distribution possibility, the user and the agent in
the visited network can decide to set up a key based on Diffie
Hellman. The major vulnerability of this mechanism is authentication
Faccin, Le [Page 15]
INTERNET-DRAFT AAA LSA TSK July 2001
to prevent man in the middle attacks and the TSK shared between the
user and the visited network can provide this Diffie Hellman value
authentication.
Random number and Diffie Hellman based key distributions are
described are examples but other key distribution schemes can apply.
7. 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 user e.g. the mobile node and other entities
such as 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 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 agent authentication for the mobile
node based on challenge response based mechanism [6]. The Temporary
Shared Key enables to perform that user entity authentication, and
network entity authentication without involving the Home network.
8. 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 user 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
Faccin, Le [Page 16]
INTERNET-DRAFT AAA LSA TSK July 2001
load.
This mechanism enables to provide strong network authentication such
as challenge response based mechanism without having to involve the
AAAh.
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 User and the AAAv to perform authentication and
key distribution.
9. Messages format
This document introduces 8 new AVPs to the Diameter Protocol. They
are currently suggested as extensions to the Diameter NASREQ
Extensions [8] or to the Diameter Base Protocol but if preferred, a
new Application to the Diameter Base Protocol could be specified with
its own Command Codes to perform the TSK Update procedures and all
the other functions described above. Having a new Application to the
Diameter Base Protocol allows the AAA servers to identify which ones
support the TSK mechanism; otherwise the TSK should be part of an
Application such as the Diameter Base Protocol, or the Diameter
NASREQ Application.
As mentioned previously, this document defines additions to the
Diameter Protocol but does not focuses on the protocol between the
user and the AAA Client: it only describes that need to be exchanged
over that interface. The identified information can then be carried
as IPv6 Destination Options, ICMPv6 messges or any other means.
9.1. RANDTSK-AVP
The RANDTSK-AVP (AVP Code TBD) is of type OctetString. It is used to
carry the RANDTSK value from the AAA server to the User in two cases:
* to indicate to the Client to use the TSK
* to update the TSK
This AVP is therefore used from the AAAh to the AAAv, and from the
AAAv to the AAA User.
The RANDTSK can be carried in a RAR [10], DEA [8], or AMA command
[9]. In the case of a TSK Update procedure, the RANDTSK should be
Faccin, Le [Page 17]
INTERNET-DRAFT AAA LSA TSK July 2001
sent in a RAR [10] command.
A well defined, a priori known, specific value of the RANDTSK (TBD)
allows the home network to indicate the user to start using the
current TSK value without updating it as described in section 5.3.
Another well defined, a priori known, specific value of the RANDTSK
(TBD) allows the home network to indicate the user to stop using the
current TSK.
9.2. TSK-AVP
The TSK-AVP (AVP Code TBD) is of type OctetString. It is used by the
AAAh to indicate the utilization and inform of the value of the TSK
to the AAAv. The TSK-AVP carries the Temporary shared Key value and
therefore must be protected (P bit set to 1). When the AAAh wants to
update the TSK, it also sends the TSK-AVP to the AAAv to inform it to
perform a TSK Update procedure. In such case, the TSK-AVP carries the
value of the new TSK.
The TSK can be carried in a RAR [10], DEA [8], or AMA command [9]. In
the case of a TSK Update procedure, the TSK should be sent in a RAR
[10] command.
9.3. RANDNET-AVP
The RANDNET-AVP (AVP Code TBD) is of type OctetString. It carries the
challenge randomly generated by the User to authenticate the network.
This RANDNET-AVP is therefore sent from the AAA Client to the AAAv:
it can be carried e.g. in a DER Command [8] and in response the AAAv
should compute the AUTHNET.
9.4. AUTHNET-AVP
The AUTHNET-AVP (AVP Code TBD) is of type OctetString. It carries the
network authentication data and is sent in response to a RANDNET. The
AUTHNET-AVP can thus be carried from the AAAv to the AAA Client in a
DEA or RAR [10].
9.5. RANDU-AVP
The RANDU-AVP (AVP Code TBD) is of type OctetString. It carries the
challenge randomly generated by the AAAv to authenticate the User and
make sure the User has updated the TSK. This RANDU-AVP is therefore
Faccin, Le [Page 18]
INTERNET-DRAFT AAA LSA TSK July 2001
sent from the AAAv to the AAA client: it can be carried in a DEA or
RAR [10] and in response the User should compute the AUTHU.
9.6. AUTHU-AVP
The AUTHU-AVP (AVP Code TBD) is of type OctetString. It carries the
user authentication data and is sent in response to a RANDU. The
AUTHU-AVP can thus be carried from the AAA Client to the AAAv in a
DER command [8].
9.7. AAA-Report-AVP
The AAA-Report-AVP (AVP Code TBD) is of type Unsigned32. It carries
the result (failure/success) from the AAAv to the AAAh and can
therefore be sent in a DER Command [8].
9.8. AAA-Report-ack-AVP
The AAA-Report-ack-AVP (AVP Code TBD) is of type Unsigned32. This AVP
is sent from the AAAh to the AAAv and can thus be carried in a DEA
command [8].
10. 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 AAAV and AAAh may decide to use or
not based on policies and roaming agreements.
In the case the Home network decides neither to generate nor to
update but to reuse the existing TSK while the user is roaming to a
new domain as described in section 5.3, the previously visited domain
still having knowledge of the current TSK value may perform
undesirable operations on behalf of the user. It is therefore
opinion of the authors that the AAAh SHOULD update the Temporary
Shared Key update process at least every time the MN is entering a
new visited domain.
Faccin, Le [Page 19]
INTERNET-DRAFT AAA LSA TSK July 2001
11. 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.
Faccin, Le [Page 20]
INTERNET-DRAFT AAA LSA TSK July 2001
12. 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, July 2001.
[5] Alfred J. Menzes, Paul C. van Oorschot, Scott A. Vanstone,
"Hamndbook of Applied Cryptography" Kerberos Authentication
protocol, p 501-502
[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. Faccin, Key distribution for
Mobile IPv6. Internet Draft, Internet Engineering Task
Force, February 2001.
[8] Pat R. Calhoun, William Bulley, Allan C. Rubens, Tut
Systems, Jeff Haag, Glen Zorn, "Diameter NASREQ
Extensions", Internet Draft, Internet Engineering Task
Force, May 2001.
[9] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile IPv4
Extensions" , Internet Draft, Internet Engineering Task
Force, May 2001.
[10] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman,
Allan C. Rubens, Glen Zorn, "Diameter Base Protocol",
Internet Draft, Internet Engineering Task Force, June 2001.
[11] Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E.
Perkins, "Diameter Mobile IPv6 Application, Internet Draft,
Internet Engineering Task Force, July 2001.
Faccin, Le [Page 21]
INTERNET-DRAFT AAA LSA TSK July 2001
[12] Subir Das, Anthony McAuley, Basavaraj Patil, Henry
Haverinen, Yoshihiro Ohba, Shinichi Baba, "Basic User
Registration Protocol (BURP) Requirements", Internet Draft,
Internet Engineering Task Force, January 2001.
[13] Yoshihiro Ohba, James Kempf, Phil Roberts, Barani Subbiah,
Basavaraj Patil, Henry Haverinen, Hesham Soliman, "Usage
Scenarios of a User Registration Protocol (URP)", Internet
Draft, Internet Engineering Task Force, July 2001.
[14] J. Arkko, H. Haverinen, "EAP AKA Authentication", Internet
Draft, Internet Engineering Task Force, May 2001.
Faccin, Le [Page 22]
INTERNET-DRAFT AAA LSA TSK July 2001
13. Authors' Addresses
Stefano M. Faccin
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4994
E-mail: stefano.faccin@nokia.com
Franck Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-1256
E-mail: franck.le@nokia.com
Faccin, Le [Page 23]
INTERNET-DRAFT AAA LSA TSK July 2001
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. The Security Model . . . . . . . . . . . . . . . . . . . . . 2
2.2. Common Algorithms . . . . . . . . . . . . . . . . . . . . . 4
3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use of TSK . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Distribution of TSK in Visited Domain . . . . . . . . . . . 6
4. TSK sharing option . . . . . . . . . . . . . . . . . . . . . . . 6
5. Computation and Distribution of the TSK . . . . . . . . . . . . . 6
5.1. Creation and Distribution of Temporary Shared Key at
Initial Authentication . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Mutual Challenge Response Authentication based on
Local Challenge . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.2. Challenge Response Authentication based on Home
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Temporary Shared Key Update Function . . . . . . . . . . . . 10
5.2.1. TSK update process in AAAh . . . . . . . . . . . . . . 11
5.2.2. TSK update process in AAAv/AAAc . . . . . . . . . . . . 12
5.3. Distribution of Previously Established TSK . . . . . . . . . 13
6. Entity authentication and key distribution using the TSK . . . . 14
6.1. User authentication using TSK . . . . . . . . . . . . . . . 14
6.2. Network authentication using TSK . . . . . . . . . . . . . . 15
6.3. Key distribution using TSK . . . . . . . . . . . . . . . . . 15
7. Comparison with existing earlier solutions . . . . . . . . . . . 16
8. Pros and Cons of the Temporary Shared Key sharing . . . . . . . . 16
9. Messages format . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. RANDTSK-AVP . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. TSK-AVP . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. RANDNET-AVP . . . . . . . . . . . . . . . . . . . . . . . . 18
9.4. AUTHNET-AVP . . . . . . . . . . . . . . . . . . . . . . . . 18
9.5. RANDU-AVP . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.6. AUTHU-AVP . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.7. AAA-Report-AVP . . . . . . . . . . . . . . . . . . . . . . . 19
Faccin, Le [Page xxiv]
INTERNET-DRAFT AAA LSA TSK July 2001
9.8. AAA-Report-ack-AVP . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
11. Intellectual Property Considerations . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Faccin, Le [Page xxv]
