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) 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]