INTERNET DRAFT Pat R. Calhoun Category: Standards Track Charles E. Perkins Title: draft-ietf-mobileip-challenge-00.txt Sun Laboratories, Inc. Date: November 1998 Mobile IP Foreign Agent Challenge/Response Extension Status of this Memo This document is a submission by the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@smallworks.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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.'' To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract RFC2002, which defines the base Mobile IP protocol, assumes that a shared secret exists with all mobility agents and the Mobile Node. However, in larger networks, this assumption can lead to scalability problems, especially in situations where the Mobility Agents are owned by different administrative domains. This document specifies the Router Advertisement and Mobile IP extensions necessary to integrate Mobile IP with Key Distribution Centers (KDC). Calhoun, Perkins expires April 1999 [Page 1] INTERNET DRAFT November 1998 Table of Contents 1.0 Introduction 1.1 Terminology 2.0 Operation 2.1 Intra-Domain Mobile IP 2.2 Inter-Domain Mobile IP 2.3 Allocation of a Home Agent in a Foreign Network 2.4 Smooth Handoff 2.5 Key Expiration 2.6 Interaction with Home Agent Allocation 3.0 Router Discovery Extensions 3.1 Foreign Agent Challenge Extension 3.2 Foreign Agent NAI Extension 4.0 Mobile IP Registration Extensions 4.1 Foreign-Agent-Challenge Extension 4.2 Mobile-Challenge-Response 4.3 Mobile-Foreign-SPI Extension 4.4 Mobile-Home-SPI Extension 4.5 Mobile-Foreign-Key Extension 4.6 Mobile-Home-Key Extension 4.7 Previous-Foreign-Agent-NAI Extension 4.8 Key-Lifetime Extension 5.0 Security Analysis 5.1 Challenge/Response Replay 5.1 Malicious FA 5.2 Malicious Foreign KDC 6.0 References 7.0 Acknowledgements 8.0 Chairs' Addresses 9.0 Author's Address 1.0 Introduction RFC2002, which defines the base Mobile IP protocol, assumes that a shared secret exists with all mobility agents and the Mobile Node. However, in larger networks, this assumption can lead to scalability problems, especially in situations where the Mobility Agents are owned by different administrative domains. In this proposal, we recommend the integration of Mobile IP and KDCs to solve the problem. Our primary design goal is to minimize the number of security associations that a given Mobility Agent requires in order to get service. In fact, this proposal requires that Mobility Agent and Node have only a single security association with the Key Distribution Center, known as the Home Domain Allocation Agency (HDAA). Calhoun, Perkins expires April 1999 [Page 2] INTERNET DRAFT November 1998 In order to make this proposal scale in larger networks, we propose that if the Mobility Agents are not owned by the same administrative domain, that only the HDAAs share a security association. This allows cross domain mobility with a single security association between both networks. The document [9] describes the extensions necessary for a Home Agent to be dynamically assigned to a Mobile Node during the first Registration Request. Making use of the security extensions defined in RFC 2002, would require the Home Agent to share a security association with the Mobile Node, which means that the Home Agent must be owned by the same administrative domain as the Mobile Node. This extension will describe the security extensions necessary for the Home Agent to be assigned within the foreign network. This proposal will also specify how the Mobile Node can move to another foreign domain and must keep the same Home Agent that was assigned within the initial foreign domain. This can be achieved even though both foreign domains do not share any security associations, but both share one with the home domain. The extensions described here are designed for new generation cellular networks. 1.1 Terminology KDC Key Distribution Center is a central server that issues short- lived keys to requesting agents in order to grant access to the visiting network's foreign agent as well as access to the home network. KEYID Key ID is an ID that references a key instance. ICV The Integrity Check Vector is the message authentication code of the Registration message and the long lived shared secret. The Mobile IP [2] document refers to this field as the authenticator. SS1 A secret of up to 16 octets in length shared between the Mobile Node and the HDAA. Calhoun, Perkins expires April 1999 [Page 3] INTERNET DRAFT November 1998 SS2 A secret of up to 16 octets in length shared between the Foreign Agent and its HDAA. SS3 A secret of up to 16 octets in length shared between the Home Agent and its HDAA. 2.0 Operation The extensions in this document are specified to enable Mobile IP to interoperate with another protocol that can create keys for use between the foreign agent and mobile node, the foreign agent and the home agent, and the mobile node and its home agent. The protocol messages for key creation, and verification of the Foreign Agent challenge, are not specified in this document, because they are part of a different protocol that processes messages sent to a port other than 434. Therefore, those key creation and challenge verification messages are not considered to be part of Mobile IP, and are not processed by Mobile IP software. All of the extensions specified in this document are expected to be processed by Mobile IP software that has been updated to handle the additional syntax presented in these extensions. For an example of another protocol that has been specified to actually carry out the key creation and challenge verification operations, see [3] [6]. The shared secrets (SS1, SS2, and SS3) indicated in this document are shared with a KDC agent in the home domain. SS2 may be shared between this KDC agent and the foreign agent, or more likely between the KDC agent and a proxy acting in concert with the foreign agent. For an example of how this works, consider the following diagram: ------------------------------------------------------ | | | Verification and Key Management Infrastructure | | | ------------------------------------------------------ ^ | ^| | | || | v |v ----------------- ----------------- | | | | | Foreign Agent | | Home Agent | | | | | ----------------- ----------------- Calhoun, Perkins expires April 1999 [Page 4] INTERNET DRAFT November 1998 After the foreign agent gets the Challenge Response, it passes the Response along to the (here unspecified) infrastructure, and awaits a a Registration Reply. If the reply has a positive status (indicating that the registration was accepted), the foreign agent accepts the registration, and decodes the Mobile IP keys and SPIs for use with future Mobile IP registration messages. If the reply does not have a positive status code, then the foreign agent assumes that the challenge did not pass verification, for reasons that may or may not be specified by the infrastructure agents. Implicit in this picture, however, is the important observation that the Foreign Agent and the Home Agent have to be equipped to make use of whatever protocol is made available to them by the key management and challenge verification shown in the figure. 2.1 Intra-Domain Mobile IP In the simplest case, the Mobility Agents and the Mobile Node are owned by the same administrative domain. In this following example, all Mobility Agents MUST share a security association with the Home Domain Allocation Agency (HDAA). +------+ +------+ +------+ | | | | | | | MN |- - - -| FA |- - - - - - - - - -| HA | | | | | | | +---+--+ +---+--+ +---+--+ | | | SS3 | | SS2 +---+--+ | +----------------------+ | | SS1 | HDAA | +-------------------------------------+ | +------+ In this example, the Foreign Agent issues a Router Advertisement on its local link, which is captured by the Mobile Node. The Router Advertisement message includes the Foreign Agent Challenge and the Foreign Agent NAI extensions. The Mobile Node extracts the Foreign Agent NAI, and uses the NAI to determine whether it is attached to its home network. The Mobile Node then extracts the Foreign Agent Challenge from the advertisement and computes the Mobile-Challenge-Response extension using the challenge and the Registration Request message hashed with SS1, but not including the UDP and IP headers. The Registration Calhoun, Perkins expires April 1999 [Page 5] INTERNET DRAFT November 1998 Request is forwarded to the Foreign Agent and has the following format: ::= [] [] [] Upon receipt of the Registration Request, the Foreign Agent MUST ensure that the Foreign-Agent-Challenge extension contains a recently advertised challenge value. This ensures that the Mobile Node is not attempting to replay a previous Mobile-Challenge-Response. If the Mobile-Challenge-Response extension is present in the message, or if the Mobile-Node-NAI shows that it belongs to a different administrative domain, the foreign agent (or its proxy) forwards the Registration Request to the HDAA. Note that the Foreign Agent MAY provide the Mobile-Challenge- Response extension in the KDC message. The HDAA can then easily find the authenticator necessary to authenticate the user. The HDAA will extract the Mobile-Challenge-Response extension and compute a response using the Foreign Agent Challenge, SS1 and the packet. If the response matches the authenticator in the Mobile- Challenge-Response extension, the user is authenticated. The HDAA may also perform some additional access control checks such as: - Whether the Mobile Node can use the Foreign Agent. - Whether the Mobile Node can use the Foreign Network. - Whether the Mobile Node can use the network at the requested day and time. If successfully authenticated and authorized, the HDAA will generate three separate short-lived sessions keys, associated Security Parameter Index (SPI) values and key lifetime, which are sent to the Home Agent in the KDC response message. The three keys have the following properties (see figure 1 for the distribution of keys SS1, SS2 and SS3): - K1 is used to authenticate Mobile IP messages between the Mobile Node and the Home Agent, and is encrypted using SS1 for the Mobile Node (Mobile-Home-Key) and using SS3 for the Home Agent. - K2 is used to authenticate Mobile IP messages between the Mobile Calhoun, Perkins expires April 1999 [Page 6] INTERNET DRAFT November 1998 Node and the Foreign Agent, and is encrypted using SS1 for the Mobile Node (Mobile-Foreign-Key) and using SS2 for the Foreign Agent (Foreign-Mobile-Key). - K3 is used to authenticate Mobile IP messages between the Foreign Agent and the Home Agent, and is encrypted using SS2 for the Foreign Agent (Foreign-Home-Key) and using SS3 for the Home Agent. The HDAA will forward the response to the Home Agent which includes all of the Security Parameter Index and Keys. Upon receipt of the response from the HDAA, the Home Agent will proceed to process the Registration Request as defined in [2] and will construct a Registration Reply message in the following format: ::= The Mobile-Home Authentication extension will be computed by the Home Agent using the decrypted version of K1, and the Foreign-Home Authentication extension is computed using the decrypted version of K3. The Registration Reply is then sent back to the HDAA in the KDC message, which forwards it to the Foreign Agent. The Foreign Agent processes the Registration Reply by extracting the Foreign-Home-Key and decrypting it using SS2. It then validates the Foreign-Home Authentication extension by ensuring that the SPI value matches the value that was provided in the Foreign-Home-SPI, and that the authenticator was computed using the key (K3). If the packet is successfully authenticated, the Foreign Agent adds the Mobile-Foreign Authentication extension using the decrypted version of the key found in the Foreign-Mobile-Key extension, and includes the SPI value found in Foreign-Mobile-SPI. The Registration Reply message forwarded to the Mobile Node has the following format: Calhoun, Perkins expires April 1999 [Page 7] INTERNET DRAFT November 1998 ::= Upon receipt of the Registration Reply, the Mobile Node must extract the Mobile-Foreign-Key and Mobile-Home-Key and decrypt the session key using the secret shared with the HDAA (SS1). The Registration Reply's Mobile-Foreign Authentication and Mobile-Home Authentication extensions are computed using the decrypted version of the keys. The Mobile Node MUST also ensure that the SPIs used in these extensions are consistent with the values returned in the Mobile-Foreign-SPI and Mobile-Home-SPI extensions. All subsequent Registration Requests sent by the Mobile Node to the Foreign Agent MUST include the Mobile-Foreign Authentication and the Mobile-Home Authentication computed using K2 and K1, respectively. The authentication extensions MUST include the SPIs that refer to the session keys used, Mobile-Foreign-SPI (K2) and Mobile-Home-SPI (K1). The keys may be used until either the Mobile Node registers with a new Foreign Agent, or until the keys expire which is known through the Key-Lifetime extension. Once the keys expire, the Mobile Node must request a new key by including the Foreign-Agent-Challenge and the Mobile-Challenge-Response extensions. 2.2 Inter-Domain Mobile IP In the previous section, we discussed how the extensions described in this document could be used in a network where all mobility entities were owned by the same administrative domain. There is a typical requirement to have Foreign Agents, owned by a different administrative domain from the home network, provide service to the Mobile Nodes. Unfortunately the scheme described in the previous section cannot be used in this network configuration since it would require the HDAA to have a security association with Foreign Agents that are not under its administrative control, which would introduce serious scalability and security problems. In order to be able to support such a configuration, the KDC must Calhoun, Perkins expires April 1999 [Page 8] INTERNET DRAFT November 1998 support proxying capabilities, one such method is described in [7]. Proxying means that a KDC receives a request and is able to forward the request to another KDC for processing in a secure fashion. In the following figure we introduce a foreign network which consists of a Foreign Agent which shares a security association with its Visiting VDAA 1 (VDAA-1). Both of these network entities are owned by the same administrative domain. Notice that HDAA and VDAA-1 share a security association, which means that these domains can provide Mobile IP services to each other with a single association. +------+ +------+ +------+ | | | | | | | MN |- - - -| FA |- - - - - - - - - -| HA | | | | | | | +---+--+ +---+--+ +---+--+ | | SS2 | SS3 +------------------------------+ | | | | +---+--+ | SS1 +---+--+ | | +------+ | |VDAA-1| | HDAA | | +--------------SS4--+ | +------+ +------+ In this example, the Foreign Agent advertises its service in the same manner as previously discussed. The Mobile Node adds the Challenge and the Mobile-Challenge-Response extensions to the Registration Request as previously explained. When the Foreign Agent receives the Mobile Node's Registration Request, it validates the challenge and forwards the request to VDAA-1, which includes the Registration Request, the Mobile Node's NAI, the Challenge and the Mobile-Challenge-Response extensions. VDAA-1 uses the domain portion of the Mobile Node's NAI to identify the Mobile Node's Home KDC, and forwards the request to the HDAA. At this point, the HDAA authenticates the user and generates the session keys as described in the previous section. The only difference are that all keys destined for the Foreign Agent are encrypted using SS4, which is the security assocation shared between HDAA and VDAA-1. HDAA then forwards all keys, and the Registration Request to the Home Agent within the Home network. Upon receipt of this message, the Home Agent decrypts all keys which belong to the Home Agent using SS3 and generates the Registration Reply in the following format: Calhoun, Perkins expires April 1999 [Page 9] INTERNET DRAFT November 1998 ::= The Home Agent forwards the Registration Reply back to the HDAA in a KDC message, which also includes the encrypted version of the session keys destined for the Foreign Agent (which was present in the KDC request to the Home Agent). The HDAA forwards this response back to the VDAA-1, which descrypts the keys for the Foreign Agent using SS4, and re-encrypts the keys using SS2, then forwards the response to the Foreign Agent. Note that in this case the keys destined for the Foreign Agent are carried within the KDC messages, and not in the Mobile IP messages. The Foreign Agent extracts the session keys and the Registration Reply from the KDC message. The keys are decrypted using SS2 and the Registration Reply's Foreign-Home Authentication extension is authenticated using the decrypted version of the Foreign-Home-Key extension. The Foreign Agent then adds the Foreign-Home Authentication extension and forwards the Reply to the Mobile Node, in the following format: ::= Once the keys have been distributed, the Mobile Node can proceed to issue Registration Requests using the new session keys until either the Mobile Node uses a new Foreign Agent, or the keys expire. 2.3 Allocation of a Home Agent in a Foreign Network The document [9] describes the method of dynamically assigning a Home Agent to a Mobile Node. The examples provided in the earlier sections would work well if the Home Agent allocated belonged within the home Calhoun, Perkins expires April 1999 [Page 10] INTERNET DRAFT November 1998 network. Here we will look at the how a Home Agent could be allocated within a foreign network. In the following figure, we show the Mobile Node which shares the security association with its HDAA, and the Foreign and Home Agents share one with their VDAA-1. When the HDAA receives the KDC message from VDAA-1, the Mobile Node is authenticated using the Challenge and the Response and additional authorization checks may be performed. The keys are generated and returned to the VDAA-1, however all keys for the Foreign and the Home Agent are encrypted using SS4. Upon receipt of the response, VDAA-1 decrypts all keys for the Foreign and Home Agent using SS4, and re-encrypts them using SS2 and SS5, respectively, and the processing continues as previously described. +------+ +------+ +------+ | | | | | | | MN |- - - -| FA |- - - - -| HA | | | | | +---+ | +---+--+ +---+--+ | +------+ | | SS2 | +-----------------------|------+ | | | +---+--+ SS5 | | SS1 +------+ | +-----+ +------+ | |VDAA-1| | HDAA | | +--------------SS4--+ | +------+ +------+ It is desirable for the Mobile Node to maintain the same Home Agent within the Foreign Network, even if the Mobile Node enters a new Foreign Network. However, it is possible that both Foreign Network's KDCs do not share a security association, and it is also mandatory that the HDAA be involved since ultimately it will be responsible for any payments. In the following figure the Mobile Node enters a new network which includes the new Foreign Agent and VDAA-2. The Mobile Node receives the Router Advertisement that inclues the new Foreign Agent's NAI (and domain). The Mobile Node will determine that it has entered a new network and will therefore issue a Registration Request that includes the Old Foreign Agent's NAI, the old Home Agent, the Challenge and the Response. Calhoun, Perkins expires April 1999 [Page 11] INTERNET DRAFT November 1998 +------+ | | +- -+ HA + | | | +---+--+ | SS5 | | +---+--+ +------+ | | +--------------SS4--+ | |VDAA-1| | HDAA | | | | +------+ | +------+ | SS1 +---+--+ | | | +------------------------------+ | | | | +------+ +------+ +---+--+ | | | +- -+ | SS7 | | SS6 | | MN |- - - -| FA +--------+VDAA-2+-------+ | | | | | | +------+ +------+ +------+ The Foreign Agent will forward this request to its VDAA-2, which will forward the request towards HDAA. HDAA will determine that the Mobile Node was already registered with a Home Agent in the old Foreign Network and will therefore create a new set of session keys. In this case the session keys destined for the Home Agent will be encrypted using SS4 and the ones for the Foreign Agent will be encrypted using SS6. Upon receipt of the request, VDAA-1 will decrypt the keys for the Home Agent and re-encrypt them using SS5. Further processing of the packet will occur as previously described. When the KDC response is received by VDAA-2, the session keys for the Foreign Agent will be decrypted using SS6, and re-encrypted using SS7. The message will then be forwarded to the Foreign Agent and further processing will occur as previously described. In the event that the Mobile Node does NOT wish to maintain the Home Agent within the Foreign Network, the Home Agent field within the Registration Request is set to zero. 2.4 Smooth Handoff In order to support smooth hand-off, the Mobile Node MUST examine the Foreign Agent NAI within the Router Advertisement when it receives advertisements from a new Foreign Agent. If the Mobile Node determines that both the old and the new Foreign Agents belong to the Calhoun, Perkins expires April 1999 [Page 12] INTERNET DRAFT November 1998 same administrative domain it can attempt to request smooth hand-off. The Mobile Node MUST include the Challenge and Response as previously described as well as the Mobile-Foreign Authentication and Mobile- Home Authentication extensions. Upon receipt of this Request, the new Foreign Agent (FA-2) can issue the KDC request to its local KDC (VDAA-1), which can determine if it is able to provide smooth hand-off. If VDAA-1 had kept state information that included the session keys previously distributed by the HDAA, VDAA-1 can re-encrypt the session keys using SS5 and return these to the Foreign Agent. At this point, the Foreign Agent can add authenticate the request from the Mobile-Node through the Mobile- Foreign Authentication extension, and can add the Foreign-Home Authentication extension prior to forwarding the request to the Home Agent. +------+ +------+ +------+ | | | | | | | MN |- - - -| FA-2 |- - - - - - - - - -| HA | | | | | | | +---+--+ +---+--+ +---+--+ | | SS5 | SS3 +------------------------------+ | | | | +------+ +---+--+ | SS1 +---+--+ | | | | +------+ | | FA-1 +-------+VDAA-1| | HDAA | | | SS2 | +--------------SS4--+ | +------+ +------+ +------+ If VDAA-1 was not able to provide smooth hand-off services, either because it did not have the functionality or because it no longer had a copy of the session keys, it can opt to simply forward the KDC message to HDAA as previously described and the Challenge and Response extensions would be used to authenticate the Mobile Node. 2.5 Key Expiration The Key-Lifetime extension, which MUST be present in the Registration Reply if any of the Key extensions are present in the reply, contains the time at which the keys are considered expired. The value of this extension is the high-order 32 bit value of the NTP timstamp. When the Mobile Node needs to re-register and the keys have expired, it MUST request a that new keys be distributed by including ONLY the Foreign-Agent-Challenge and Mobile-Node-Response extensions without any other authentication extension. Calhoun, Perkins expires April 1999 [Page 13] INTERNET DRAFT November 1998 2.6 Interaction with Home Agent Allocation Earlier we described that the authentication extensions defined in this specification lends well with the Dynamic Home Agent Allocation as described in [9]. In fact, if the Foreign Agent initiates the KDC request, it is envisioned that the KDC also include the functionality that would dynamically assign the Home Agent to the Mobile Node. 3.0 Router Discovery Extensions This section will define the extensions necessary to the Router Discovery Protocol [8]. The Mobile Node can assume that the Foreign Agent supports this specification if the extensions in this section are part of the Router Advertisements. 3.1 Foreign Agent Challenge Extension The Foreign Agent Challenge Extension is present in the Router Advertisements by the Foreign Agent in order to communicate the latest Challenge value that can be used by the Mobile Node to compute the Challenge Response. The Foreign Agent is responsible for ensuring that the Challenge Value in the Registration Request is current (the Foreign Agent may wish to accept the last two challenge values advertised). The Foreign Agent Challenge Extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Foreign Agent Challenge ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length (4 + N), where N is the length of the challenge value. Challenge The Challenge field consists random value of at least 128 bits. Calhoun, Perkins expires April 1999 [Page 14] INTERNET DRAFT November 1998 3.2 Foreign Agent NAI Extension The Foreign Agent NAI Extension contains the Foreign Agent's Network Access Identifier. This value is used by the Mobile Node to determine if it has entered a new Administrative Domain. For smooth hand-off, the Mobile Node may wish to use the same Session Key and SPI it shared with a previous Foreign Agent if both Foreign Agents are part of the same administrative domain. The Foreign Agent NAI Extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Foreign Agent NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length N, where N is the length of the NAI. FA NAI Foreign Agent's Network Access Identifier 4.0 Mobile IP Registration Extensions This section will define new Mobile IP Registration Extensions that must be used in order to use the functionality described in this document. This extension requires that the following new Code be supported in the Registration Reply: SPI_IN_USE TBD The Foreign Agent uses this error code to indicate to the Mobile Node that the SPI received by the HDAA is already in use for another key (one chance in 2^32). Upon receiving this error code the Mobile Node SHOULD re-issue a new Registration Request. Calhoun, Perkins expires April 1999 [Page 15] INTERNET DRAFT November 1998 4.1 Foreign-Agent-Challenge Extension The Foreign-Agent-Challenge extension is copied from the Challenge in the Foreign Agent's Router Advertisement. This extension SHOULD only be present while there are no keys shared between the Mobile Node and the Foreign Agent (upon initial contact, or upon once the keys have expired). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length Must be at least 18 Challenge The Challenge field is copied from the Router Advertisement's Foreign Agent Challenge. 4.2 Mobile-Challenge-Response Extension This Extension MUST be included in the Registration Request if either the Home Agent or the Home Address fields are set to zero (0). The authenticator is computed as shown below: FA-Challenge || Packet || Timestamp || Shared Secret Note that the authentication does NOT cover this extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Timestamp .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Timestamp (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Calhoun, Perkins expires April 1999 [Page 16] INTERNET DRAFT November 1998 TDB Length 2 plus the number of bytes in the Authenticator. Timestamp Contains a monotonically increasing value and is used in the hash calculation. This field SHOULD be used to detect replay attacks. Authenticator Variable length hash. 4.3 Mobile-Foreign-SPI Extension The Mobile-Foreign-SPI extension contains the Key Identifier created by the HDAA and is used to identify the Mobile-Foreign-Key and the Foreign-Mobile-Key. This SPI is to be used in subsequent Registration Request and Replies within the Mobile-Foreign Authentication extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ fi Type TDB Length Must be 6 SPI The SPI field contains the Security Parameter Index (or Key Identifier) that was created by the HDAA which is used to identify the key found in the Mobile-Foreign-Key extension. Calhoun, Perkins expires April 1999 [Page 17] INTERNET DRAFT November 1998 4.4 Mobile-Home-SPI Extension The Mobile-Home-SPI extension contains the Key Identifier created by the HDAA and is used to identify the Mobile-Home-Key. This SPI is to be used in subsequent Registration Request and Replies within the Mobile-Home Authentication extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length Must be 6 SPI The SPI field contains the Security Parameter Index (Or Key Identifier) that was created by the HDAA which is used to identify the key found in the Mobile-Home-Key extension. 4.5 Mobile-Foreign-Key Extension The Mobile-Foreign-Key extension contains the encrypted version of the session key that the Mobile Node is to share with the Foreign Agent in subsequent Registration Request. The key is created by the HDAA and is used in the computation of the Mobile-Foreign Authentication extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MN-FA-KEY... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Calhoun, Perkins expires April 1999 [Page 18] INTERNET DRAFT November 1998 Length Must be at least 3 MN-FA-Key The MN-FA-Key field contains the encrypted version of the session key created by the HDAA. 4.6 Mobile-Home-Key Extension The Mobile-Home-Key extension contains the encrypted version of the session key that the Mobile Node is to share with the Home Agent in subsequent Registration Request. The key is created by the HDAA and is used in the computation of the Mobile-Home Authentication extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MN-HA-KEY... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length Must be at least 3 MN-HA-KEY The MN-HA-KEY field contains the encrypted version of the session key created by the HDAA. 4.7 Previous-FA-NAI Extension The Previous-FA-NAI Extension contains the NAI which provided service to the Mobile Node prior to the hand-off. The presence of this extension informs the Foreign Agent that smooth hand-off should be done, if possible. The Mobile Node MUST assume that the new Foreign Agent cannot perform smooth hand-off, and therefore MUST include the Foreign-Agent- Challenge and the Mobile-Node-Response extensions as well as the Calhoun, Perkins expires April 1999 [Page 19] INTERNET DRAFT November 1998 normal authentication extensions. The Previous-FA-NAI Extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Previous-FA-NAI... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length Must be at least 3 Previous-FA-NAI The Previous-FA-NAI field contains the NAI of the Foreign Agent that was servicing the Mobile Node before detecting a new Foreign Agent. 4.8 Key-Lifetime Extension The Key-Lifetime extension contains the timestamp at which the keys include in the Registration Reply will be considered expired. The value of the number of seconds before the key expires. Once the keys have expired they can no longer be used. Therefore a request for new keys must be made on behalf of the Mobile Node by including the Challenge and Response 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Key-Lifetime .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key-Lifetime .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length Calhoun, Perkins expires April 1999 [Page 20] INTERNET DRAFT November 1998 Must be 6 Lifetime The Lifetime field contains the number of seconds before the key expires. 5.0 Security Analysis This section, although incomplete, attempts to illustrate a few attacks the authors have thought of and how they are dealt with when using the extensions defined in this specification: 5.1 Challenge/Response Replay In the event that a malicious Mobile Node attempts to replay an old Foreign-Agent-Challenge and Mobile-Node-Response pair, the Foreign Agent would detect it since the Foreign Agent would be able to verify that it had not recently advertised the Challenge. In the event that both the Mobile Node and the Foreign Agent were malicious, the KDC would recognize the Challenge as being a replay since the timestamp would be invalid. 5.2 Malicious FA The possible attack here is where a malicious FA keeps an old KEY and attempts to create a Registration Request on behalf of the Mobile Node using the old KEY. Since both the Mobile Node and the Home Agent share a different key than the Foreign Agent does with both the Mobile Node and the Home Agent this attack is not possible. 5.3 Malicious Foreign KDC It is possible for a foreign KDC (perhaps proxying between both the home and the visiting network's KDC) to either keep the KEY for some time to be replayed at a later time, or changes the contents of the KEY. In the case of replay of old keys, the problem is already addressed in section 5.1. In the case where the malicious KDC attempts to alter the KEY, the Home Agent will notice that the Registration Request was Calhoun, Perkins expires April 1999 [Page 21] INTERNET DRAFT November 1998 not authenticated using the correct KEY and will reject the request. Although this can cause a denial of service attack, the culprit can be traced using the KDC logs. 6.0 References [1] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, March 1998. [2] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [3] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-00.txt, February 1998. [4] B. Aboba. "The Network Access Identifier." Internet-Draft, August 1997. [5] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework", draft-calhoun-diameter-framework-01.txt, August 1998. [6] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension", draft-calhoun-diameter-mobileip-00.txt, July 1998. [7] P. Calhoun, W. Bulley, "DIAMETER Proxy Extension". Internet-Draft, draft-calhoun-diameter-proxy-00.txt, August 1998. [8] Deering, S., Editor, "ICMP Router Discovery Messages", RFC 1256, September 1991. [9] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Agent Allocation", draft-ietf-mobileip-ha-alloc-00.txt, November 1998. 7.0 Acknowledgements The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6 WG, Gabriel Montenegro and Vipul Gupta for their useful discussions. 8.0 Chairs' Addresses The working group can be contacted via the current chairs: Calhoun, Perkins expires April 1999 [Page 22] INTERNET DRAFT November 1998 Jim Solomon RedBack Networks 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 USA Phone: +1 408 548-3583 Fax: +1 408 548-3599 E-mail: solomon@rback.com Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK17-202 Mountain View, California 94303 Phone: +1 650 786-5166 Fax: +1 650 786-5896 E-Mail: erik.nordmark@eng.sun.com 9.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Network and Security Center Sun Microsystems Laboratories, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pat.calhoun@eng.sun.com Charles E. Perkins Network and Security Center Sun Microsystems Laboratories, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-6464 Fax: 1-650-786-6445 E-mail: charles.perkins@eng.sun.com Calhoun, Perkins expires April 1999 [Page 23] INTERNET DRAFT November 1998 Calhoun, Perkins expires April 1999 [Page 24]