PANA Stefano M. Faccin INTERNET-DRAFT Franck Le Date: February 2002 Nokia Research Center Expires: August 2002 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 local network where the user is attaching to the Internet. 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. Faccin, Le [Page i] INTERNET-DRAFT LSA February 2002 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. The model and assumptions . . . . . . . . . . . . . . . . . . . . 3 3. The Temporary Shared Key . . . . . . . . . . . . . . . . . . . . 5 3.1. Use of the TSK . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. TSK sharing option . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Creation and Distribution of Temporary Shared Key at Initial Authentication . . . . . . . . . . . . . . . . . . . . . 6 4.2. Temporary Shared Key Update Function . . . . . . . . . . . . 8 4.2.1. TSK Update procedure . . . . . . . . . . . . . . . . . 9 4.2.2. Distribution of previously established TSK . . . . . . 10 4.3. Entity authentication and key distribution using the TSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. User authentication using TSK . . . . . . . . . . . . . 11 4.3.2. Network authentication using TSK . . . . . . . . . . . 11 4.3.3. Key distribution using TSK . . . . . . . . . . . . . . 12 5. Extensions to Diameter . . . . . . . . . . . . . . . . . . . . . 12 6. Extensions to EAP . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. TSK Type . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Extensions to CHAP . . . . . . . . . . . . . . . . . . . . . 15 7. Applicability to CHAP . . . . . . . . . . . . . . . . . . . . . . 15 7.1. TSK establishment at initial registration . . . . . . . . . 16 7.2. TSK update . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security considerations . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Faccin, Le [Page ii] INTERNET-DRAFT LSA February 2002 1. Introduction In order to get access to the local resources, a user generally needs to get authorized and authenticated by the local network: This implies that the user presents some credentials to a local attendant which invokes the AAA infrastructure to verify the validity of the user. In addition, many security associations may need to be set up between the user and agents of the local 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. And, in order to avoid frauds, service providers need the ability to force a user to provide authentication information anytime during a session. The local service provider needs 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. Several message round trips are therefore needed between the local and home domains in order to support the above mentioned authorization/authentication and key distribution procedures. But these message exchanges between the home and visited networks may create an excessive signaling load between the AAAH and AAAL, and may add delay in the procedure. As described in RFC 2977, messages round trips between the AAAH and AAAL SHOULD be avoided if possible: the time taken for communications between the AAA servers, and more particularly, the time taken to traverse the wide-area Internet that is likely to separate the AAAL and the AAAH brings some extra delay that SHOULD be reduced. Although authentication/authorization procedures require in some situation the involvement of home and local domains (e.g. when the Faccin, Le [Page 1] INTERNET-DRAFT LSA February 2002 user roams for the first time to a foreign ISP and tries to get access - initial authentication), in several cases the adoption of an LSA allows for optimizations and empowers the local service provider to authenticate the user at any time and perform key distribution without the involvement of the home domain, while still maintaining a good level of security. Thanks to an LSA, the authentication centers in the home network and the local network manage the sharing of authentication responsibilities for a roaming mobile node by creating a temporary key that the mobile node and the local system will share. The sharing of this key gives the local network significant local control over the authentication of a roaming mobile node. 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 local network and the user. The TSK is established between the user and the local domain with the involvement of the home domain, and allows to delegate functions such as entity authentication and key derivation to the local 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 local domain and the user. This draft describes all the entities behaviours as well as the required functionalities in order to set up, distribute, refresh and withdraw the TSK. Instead of defining the protocol overview and the extensions in separate documents, all the mechanisms and protocol extensions are described in this single document: as the experience has shown, this allows any party interested in this feature to have all the required information to inplement it in this document instead of having to collect the information from different documents which may lead in some cases to ambiguity and make it more difficult. After a presentation of the model and the assumptions (section 2), section 3 introduces the Temporary Shared Key (TSK usage, benefits) before section 4 describes the protocol overview (TSK establishment, TSK update, etc.). The following sections describe the extensions to the protocols (section 5: extensions to Diameter and section 6: extensions to EAP). Finally a last section (section 7) will present how the TSK can be applied to different scenarios. Faccin, Le [Page 2] INTERNET-DRAFT LSA February 2002 2. The model and 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 local network service provider in order to gain access to IP connectivity in the local 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 first router visible to the user in the network), the PANA Agent as defined in [12], [13], or can be any server located in the network. The mechanism defined in this draft applies to all these cases. In the rest of the document, this entity will be referred to AAAc for sake of generality. Local Domain Home Domain +--------+ +--------+ |abc.com | (SA1) |xyz.com | | AAAL |<------------------->| 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 Faccin, Le [Page 3] INTERNET-DRAFT LSA February 2002 The AAA infrastructure assumed in this draft is based on a network of AAA servers, and in particular the model considers the AAAL, i.e. the AAA server in the local 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 local domain, usually cannot be pre-established but must be dynamically established. Authentication may be required before the key distribution is performed. 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 and constitute the basis of the security model: * it is assumed that the home and the local domains share a security association (shown in Figure 1 as SA1) that is not specific to any particular user. This SA can either be 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 AAAL. 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. 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. Faccin, Le [Page 4] INTERNET-DRAFT LSA February 2002 3. The Temporary Shared Key 3.1. Use of the TSK The Temporary Shared Key (TSK) is established between the user and the local 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 local domain and the user, TSK is used for: * authentication of the user by the local domain, at any time; * authentication of the local domain by the user, at any time; * control by the local domain of key distribution between the user and agents in the local domain. Usage scenarios include (but are not limited to): - key distribution between the user and an agent in the local 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 local domain. In the context of Mobile IP, if a Local Mobility Management scheme is adopted (e.g. as in [1] and [2]), a session key is required to authenticate the Binding Update/Binding Acknowledgement messages Through the use of TSK, the above functionalities 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 local domain and the user. The agent in the local domain to which the TSK is distributed to, could be the AAAL server, or a AAA client such as the PANA Agent as the one defined in PANA [x]. 3.2. 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 local domain. This may happen when, as an example, the user Faccin, Le [Page 5] INTERNET-DRAFT LSA February 2002 moves to a local 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 time delay of these procedures and the signaling involved between the local and the home domains, but whether an LSA is used (i.e. the Temporary Shared Key is provided to the local domain) should depend on the home network policies. 4. Protocol Overview 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 local 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 local domain and for sake of security it is policy of the home domain to generate a new TSK; * 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 local domain, otherwise the previous local 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. 4.1. Creation and Distribution of Temporary Shared Key at Initial Authentication The TSK computation and distribution can be integrated to the authentication procedure at the initial registration as indicated in the following sections. This reduces the number of round trip messages. 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 illustration of the concept, the TSK establishment is Faccin, Le [Page 6] INTERNET-DRAFT LSA February 2002 first described with a Mutual Challenge Response authentication. In section 7, the TSK applicability will be described with other authentication schemes such as CHAP [RFC 1994]. User AAA client AAAL AAAH | LC, VN_ID | | | |<--------------------| | | | ID, AUTHU, LC, HC | | | |-------------------->| | | | | LC,ID,AUTHU,HC,VN_ID | |------------->| | | | |------>| | | RANDTSK,TSK,AUTHNET,HC | | |<------| | RANDTSK,TSK,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 Figure 2: TSK establishment with a Mutual Challenge Response Authentication based on Local Challenge This flow illustrates the TSK generation and distribution when a mutual authentication based on challenge response is used. 1) The user takes the advertised Local Challenge and Visited Network Identifier, with the long-term key shared with its home network to compute the authentication data, AUTHU. The user also generates a Host challenge, HC, to require network authentication. 2) The AAAc 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. Faccin, Le [Page 7] INTERNET-DRAFT LSA February 2002 Then, if the AAAH and AAAc decide to use the Temporary Shared Key, the AAAH generates a new random number called the the RandomVariableTSK (RANDTSK) and executes an 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 AAAc. The AAAH MUST use inter-AAA servers security to protect the message to the foreign domain. AAAH also computes the network authentication data AUTHNET from the Host Challenge, the long term key and optionally other information. Actually, if present the RANDTSK SHOULD also be taken as an input. This will allow the MN to make sure that no one has modified its value. 3) 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. 4.2. Temporary Shared Key Update Function The previous sections described the TSK generation and distribution but the Home network MUST also be able to update the TSK at any time when the MN is in a local 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 local 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 local domain do not share a TSK and a new TSK needs to be generated. Only the AAAH may initiate the update of the current value of TSK, and the AAAH can do this at any time during a session according to the home domain policies. On the network side, a user authentication process SHOULD 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 Faccin, Le [Page 8] INTERNET-DRAFT LSA February 2002 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 SHOULD initiate 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. 4.2.1. TSK Update procedure 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 the RANDTSK and the new TSK to the AAAL. With those information, the AAAL 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 The local system begins the TSK update process when it receives the RANDTSK parameter from the AAAH. The message also contains the new TSK Key. - The AAAc sends 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 AAAc executes the shared algorithm using as inputs the MN's challenge RANDNET, and the new TSK. The result of the calculation Faccin, Le [Page 9] INTERNET-DRAFT LSA February 2002 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 AAAc - 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 AAAc performs the same steps and can thus verify that the user has updated the TSK value. Otherwise AAAc reports the failure to the AAAH. User AAA Client/AAAL AAAH | | | | | RANDTSK, TSK | | |<------------------| | | Ack | | |------------------>| | | | | RANDTSK | | |<---------------| | | | | | RANDNET | | |--------------->| | | | | | AUTHNET | | |<---------------| | | | | | success | | |--------------->| | | | | | RANDU | | |<---------------| | | | | | AUTHU | | |--------------->| | 4.2.2. Distribution of previously established TSK As described previously, there may be the case where the User and its Home network already have a TSK set up and want to re-use when entering in the local domain. In that case: Faccin, Le [Page 10] INTERNET-DRAFT LSA February 2002 * the TSK needs to be distributed to the visited network (from AAAH to AAAc) * the TSK does not need to be sent to the user since he already has knowledge of it. But an indication still needs 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. 4.3. Entity authentication and key distribution using the TSK This section describes how the TSK sharing enables the local 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. 4.3.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 AAAL. The local system having the TSK can then authenticate the user without invoking its home network. The applicability of the TSK to CHAP will be described in the next sections. 4.3.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 Faccin, Le [Page 11] INTERNET-DRAFT LSA February 2002 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 AAAc applies the common algorithm to the Host Challenge and the TSK to compute the network authentication data. Network authentication is thus provided without involving the AAAH. 4.3.3. Key distribution using TSK Without the use of an LSA, key distribution between the user and agents in the local 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. [x] When TSK is adopted, the user uses the TSK instead of the long-term key to compute the keys. In this way, since the AAAc has knowledge of the TSK as well, the keys will be available to the user and to AAAc; and AAAH does not need to be involved in the procedure. 5. Extensions to Diameter This document extends the utilization of the NAS-Session-Key AVP (AVP Code 408) defined in [x]: it specifies two more values to the NAS- Key-Binding AVP (AVP Code 404) and suggests to reuse this AVP with the Re-Auth-Request (RAR) (Command-Code 258) defined in [x] to perform the TSK update procedure. The NAS-Key-Binding AVP (AVP Code 404) is of type Enumerated, and defined in [x]. It specifies the purpose for the key. The following values are supported: Faccin, Le [Page 12] INTERNET-DRAFT LSA February 2002 DES 1 The key created is used to secure links using DES 3DES 2 The key created is used to secure links using Triple DES RC4-40 3 The key created is used to secure links using RC4 using 40-bit keys RC4-128 4 The key created is used to secure links using RC4 with 128-bit keys This document defines two more values: TSK 5 The key is carrying the Temporary Shared Key RANDTSK 6 The keying material is used to derive the TSK 6. Extensions to EAP This document defines one new type EAP Type used in Request/Response exchanges and some extensions to CHAP [RFC 1994] to allow the utilization of the TSK. If other authentication mechanisms want to take advantage of the benefits of an LSA, more extensions MAY need to be defined. 6.1. TSK Type The current EAP Types are defined: 1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One-Time Password (OTP) (RFC 1938) 6 Generic Token Card Faccin, Le [Page 13] INTERNET-DRAFT LSA February 2002 This document suggests one new Type 7 TSK Description The TSK Type is used to perform the necessary procedures related to the TSK utilization: it is more particularly used to notify the client to use, to stop using, to update the TSK, and to report any problem. A Response MUST be sent in reply to the Request with a Type field of 7 to acknowledge the reception of the message. Type 7 Type-Data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subtype Faccin, Le [Page 14] INTERNET-DRAFT LSA February 2002 1 RANDTSK - This can be used to update the TSK. The Length indicates the length of the RANDTSK Value and the Value field carries it. Two values are reserved and have specific meanings (0): This value is used to inform the Client to start using the current TSK value (1): This Value is used to ask the Client to stop using the TSK. 2 TSK Identifier: the Local domain assigns the TSK an Identifier and uses this field to inform the Client of the assigned value. The TSK Identifier SHOULD be 32 bits long. 3 Report: This is used to notify the other end that there is some synchronization problem with the TSK. The Home domain SHOULD then either issue a new TSK Update or order to stop using it. The Value field is zero octets in length. 6.2. Extensions to CHAP This draft specifies the Message field of the Success and Failure payloads. Currently, the Message content is implementation dependent. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 RANDTSK - the Length indicates the length of the RANDTSK and the value contains the RANDTSK 2 TSK Identifier - The AAAc assigns the user a TSK Identifier the user will put in the NAME field when using the TSK 7. Applicability to CHAP Faccin, Le [Page 15] INTERNET-DRAFT LSA February 2002 7.1. TSK establishment at initial registration User AAA Client/AAAL AAAH +---------------------------------------------+ | | +---------------------------------------------+ | | | | | 1. Challenge | | 2. Challenge |<------------------+ |<---------------+ | | 3. Response | | +--------------->| 4. Response | | +------------------>| | | | | | 5. Success, RANDTSK, TSK | |<------------------+ | Stores TSK | | | | | 6. Success, RANDTSK, TSK Id. | |<---------------+ | | | | +- - - - - - - - - - - - - - - - - - - - - - --+ | | | | 7. Challenge, TSK Id. | |--------------->| | | | | | 8. Response, TSK Id. | |<---------------| | | | | | 9. Success | | |--------------->| | | | | | 10. Challenge, TSK Id. | |<---------------| | | | | | 11. Response, TSK Id. | |--------------->| | | | | | 12. Sucess | | |<---------------| | 1: The Authenticator generates a Challenge and sends it to the AAAc to authenticate the Client. 2: The AAAc transmits the Challenge in a EAP-CHAP packet with the Code field set to 1 as specified in [x] Faccin, Le [Page 16] INTERNET-DRAFT LSA February 2002 3: The Client computes the authentication response and sends it in a EAP-CHAP packet - Code field set to 2 (Response) as specified in [x] 4: The AAA Client forwards the authentication response to the Authenticator to have it verified. The authenticator compares the Response Value with its own calculation of the expected value. Based on this comparison, the authenticator sends a Success or Failure packet. As described in section x.x, if the Client is correctly authenticated and based on the security policies the Home domain decides to share the TSK, it may: - either sends a notification to the Client to use the current TSK value (RANDTSK=0) and distribute the current TSK value to the Local domain - or generate a new RANDTSK and derive the corresponding TSK value. 5: The TSK is sent to the Local domain in the NAS-Session-Key AVP (AVP Code 408) with the NAS-Key-Binding AVP (AVP Code 404) set to 5. The RANDTSK is carried in the Message Field of the EAP-Success Payload. The AAA client stores the TSK and assigns a TSK Identifier for subsequent uses of this TSK between the Client and the Local Domain: whenever the TSK is used, the TSK Identifier MUST be carried in the Name Field of the EAP Request/Response Payloads [x] 6: The AAAc then forwards the EAP-Success carrying also the RANDTSK and TSK Identifier in the Message Field to the Client. The following steps are optional but since CHAP does not allow mutual authentication, the Client can not make sure any third party modified the RANDTSK value or not. For these reasons, in order to make sure of the integrity of the RANDTSK, the Client SHOULD perform the following steps: 7: the Client Challenges the network sending a ESP-CHAP Payload with a Name Field set to the TSK Identifier so the Local domain knows to use the TSK to process this request locally. 8: the AAAc uses the TSK to compute the Response, sent back to the Client in a EAP-CHAP (Code set to 2) Payload with the Name field Faccin, Le [Page 17] INTERNET-DRAFT LSA February 2002 set to the TSK Identifier 9: The Client compares the Response Value with its own calculation of the expected value. Based on this comparison, the Client sends a Success or Failure packet. If the authentication fails, the Client SHOULD sent a Report (EAP Code set to 1, Type 7, Subtype 3). After a success, the Local domain SHOULD in the same way challenge the Client to make sure they both have the same value for subsequent uses. 7.2. TSK update User AAA Client/AAAL AAAH | | | | | 1. RANDTSK, TSK | | |<------------------| | | 2. Ack | | +-----------------e>| | | | | 3. RANDTSK, TSK Id. | |<---------------| | | | | | 4. Acknowledgement | |--------------->| | | | | | 5. Challenge, TSK Id. | |--------------->| | | | | | 6. Response, TSK Id. | |<---------------| | | | | | 7. Success | | |--------------->| | | | | | 8. Challenge, TSK Id. | |<---------------| | | | | | 9. Response, TSK Id. | |--------------->| | | | | | 10. Sucess | | |<---------------| | The home domain can decide to update the TSK based on network policies or different other reasons; the procedure will be as Faccin, Le [Page 18] INTERNET-DRAFT LSA February 2002 follows: 1. The Home Domain generates a random number, RANDTSK and derives the corresponding TSK. It sends the RANDTSK and the TSK values in NAS- Session-Key AVP: NAS-Key-Binding AVP 5 and NAS-Key-Binding AVP 6 to the Local Domain in a RAR Command (Command code 258). 2. The Local domain acknowledges the receipt of the message by responding with a RAA Command (Commande Code 258). 3. The AAAc then stores the TSK and informs the Client to update the TSK by sending an EAP TSK Packet (Code=1, Type=7, Subtype 1 carrying the RANDTSK and Subtype 2 carrying the TSK Identifier) 4. The Client acknowledges the request by sending a EAP TSK Response (Code=2, Type=7). 5. The Client then challenges the network to make sure the TSK Update order is coming from the valid network. The Client thus challenge the Local domain sending a EAP CHAP Packet (Code=1, Type=4) with the Name field set to the TSK Identifier. 6. The AAA Client computes the authentication data and responds sending a EAP CHAP Response (Code=2, Type=4) with the Name field set to the TSK Identifier. 7. The client compares the Response Value with its own calculation of the expected value. Based on this comparison, the Client sends a Success or Failure packet. 8. After a success, the Local domain SHOULD in the same way challenge the Client to make sure they both have the same value for subsequent uses. 8. 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 AAAL 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 x.x, the previously visited domain still having knowledge of the current TSK value may perform Faccin, Le [Page 19] INTERNET-DRAFT LSA February 2002 undesirable operations on behalf of the user. For this reason, 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 20] INTERNET-DRAFT LSA February 2002 9. 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, "Handbook 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 LSA February 2002 [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 LSA February 2002 10. 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]