Mobile IP Changwen Liu, Intel INTERNET DRAFT Hesham Soliman, Ericsson draft-liu-mobileip-lke-01.txt March 2003 Local Key Exchange for Mobile IPv6 Local Binding Security Association Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 key management protocol for a mobile computer to securely obtain keying material with an access router in a visited link for use as the local binding security association with the router. The protocol enables an IPv6 node to utilize the access router as its temporary home agent and continue to receive packets destined to its care-of address with the temporary home agent as well as to send packets from this care-of address when the nodes change its access router. To support this operation, a few new mobility headers and Neighbor Discovery options are defined. All IPv6 nodes MAY support this protocol. Changwen, Hesham Expires Sept. 2003 [Page i] Internet Draft draft-liu-mobileip-lke-01.txt March 2003 Contents Status of this Memo...................................................0 Abstract..............................................................0 1.Introduction........................................................2 1.1.Terminology.......................................................3 2.Protocol Overview...................................................4 2.1 Local Key Exchange................................................4 2.2 Benefits..........................................................8 3.New IPv6 Message Types..............................................9 3.1 New Neighbor Discovery Option.....................................9 3.1.1 LKE Capability Option...........................................9 3.1.2 DAD Authentication Request.....................................10 3.1.3 DAD Authentication Reply ......................................11 3.2 New Mobility Headers and Options.................................13 3.2.1 Key Exchange Request...........................................13 3.2.2 Key Exchange Acknowledgement...................................14 3.2.3 Finished Request Message.......................................15 3.2.4 Finished Message...............................................15 4.Access Router Considerations.......................................17 4.1 Configurations...................................................17 4.2 Local Key Exchange...............................................17 4.3 DAD for MN.......................................................17 4.4 Binding Update Processing........................................18 5.Mobile Node Considerations.........................................18 5.1 Configurations...................................................18 5.2 Local Key Exchange...............................................18 5.3 DAD from AR......................................................18 5.4 Binding Update Processing........................................18 6.Security Considerations............................................18 6.1 Trust Model......................................................19 6.2 DoS Against AR...................................................20 6.3 Impersonation Attack Against AR..................................20 6.4 Impersonation Attack Against an IPv6 Node........................20 6.5 Replay Attack....................................................20 6.6 Relationship to Other Security Mechanisms........................21 7.Open Issues to be worked on next...................................21 8.Acknowledgements...................................................21 References...........................................................21 Author's Addresses...................................................21 Full Copyright Statement.............................................22 Changwen, Hesham Expires Sept. 2003 - 1 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 1. Introduction The Mobile IPv6 [3] specifies how the IPv6 Internet operates with mobile computers. It allows a mobile node to move from one link to another without changing the mobile node's IP address. To minimize packet loss during handover time, Mobile IPv6 protocol MAY also support packet forwarding from a previous care-of address: When a mobile node connects to a new link and forms a new care-of address, a path MAY be established for forwarding packets from a previous care-of address to this new care-of address. The Mobile node can send a Binding Update to a temporary home agent on the previous link with the previous care-of address as the home address for the binding, and provide its new care-of address as the binding's care-of address. The mobile node MAY also continue sending packets using the previous care-of address by reversing tunneling packets to the temporary home agent from the new care-of address. In order to achieve these, a binding security association has to be established between the MN and its temporary home agent. As the MN may visit any links, including wired and wireless public or private multi-access links as well as point to point links, a protocol globally scalable to all the situations is needed for enabling the establishment of the binding security association between MN and an arbitrary temporary home agent. However, there are no globally scalable protocols defined for that purpose. IPsec SA as the binding security association has the well-known problem of its dependency on PKI and hence suffers from deployment problems. The Return Routability Protocol in [3], while scalable, is designed only for setting up the binding security association between mobile node and corresponding node for which it communicates with. This document focuses on the issue and proposes a general protocol on how a mobile node chooses a temporary home agent, dynamically creates a local binding security association with the temporary home agent while both are on the same link, and then utilize the local binding security association securely. The protocol assumes no prior relationship between MN and the temporary home agent, has no dependence on PKI, does not need any extensions to the current NAS-based AAA infrastructure, and is scalable in global scope. The protocol can be deployed in any public and private access links, in particular in the following three types of networks (1)A network that has only limited authentication capability such as link level authentication mechanisms (e.g. 802.11 WEP, 802.1x [11]), (2)A network where there is no authorization and/or authentication infrastructures, and (3)A network that has some authorization and/or authentication infrastructures but do not want extend them (e.g. legacy deployment) with other new security mechanisms (such as AAA Changwen, Hesham Expires Sept. 2003 - 2 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 based keys). This protocol is intended to be supplementary to Mobile IPv6 and also provide an alternative way for localized mobility management. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. In addition, this document frequently uses the following terms: CoA Care-of Address in Mobile IPv6. MN Mobile Node in Mobile IPv6. AR Access Router. An Access Router is the last router between the network and the mobile node, i.e., the MN has link Layer connectivity to the Access Router. DAD Duplicate Address Detection as defined in [4]. Local Binding Security Association (LBSA) A security association between MN and AR that is utilized only for binding update procedure. LBSA can be established and renewed only when both MN and AR are at the same link. It includes the MN's CoA, AR address, a shared secret key as the binding management key [3], and a lifetime. LKE Local Key Exchange. A protocol defined in this document for two entities to exchange key material and set up LBSA when both are at the same link as well as to utilize the LBSA properly later. MAC_K(m) Denotes a Message Authentication Code computed on message m with key K. In this draft, HMAC SHA1 function [5] is used to compute these codes. ND Neighbor Discovery as specified in [4]. SEND Changwen, Hesham Expires Sept. 2003 - 3 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 Secure Neighbor Discovery. 2. Protocol Overview This section specifies the proposed mechanism of the local key exchange protocol and its benefits. 2.1 Local Key Exchange When a LKE-capable mobile node MN roams into a new link, the MN first performs IPv6 Neighbor Discovery to discover new access routers and on-link subnet prefixes. The LKE-capable MN MUST choose an appropriate AR that supports the LKE if possible. An AR supports the LKE if it has Home Agent (H) bit set in its router advertisement, has a RSA private/public key pair, and advertises the public key, referred as LKE extension, in its router advertisement (see 3.1). Two cases (1)No ARs exist that support the LKE. MN just performs normal Mobile IPv6 procedure. (2)There is at least one AR that supports the LKE. As illustrated in Figure 2.1 below, MN just chooses one of them. MN then forms LKE-capable New Access Current Access MN Router Router | | | Router advertisement with LKE extension | |<-------------------------------------------------------| | | | Binding update with MN's HA | |<------------------------------------------------------>| | | |<------------- Data Traffic ------------------------->| | | | Key exchange request | |------------------------------------------------------->| | | | Key exchange acknowledgement | |<------------------------------------------------------ | | | | DAD Neighbor Solicitation for MN | |<-------------------------------------------------------| | | | Multicast DAD Neighbor Advertisement for MN | |------------------------------------------------------->| | | | ------| | | | | Cache DAD adv from MN | | and forward it later | | for DAD solicitations | Changwen, Hesham Expires Sept. 2003 - 4 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 | | | | ------| | | | | |<------------- Data Traffic ------------------------->| | | | | | . . . | | | | | | Router advertisement with | | or without LKE extension | |<------------------------------| | | | Binding Update | |-------------------------------|----------------------->| | Binding Ack | | |<------------------------------|----------------------- | | Finished (optional) | | |-------------------------------|----------------------->| | | | |<------------- Data Traffic -|----------------------->| | | | |<------Repeat above or standard Mobile IPv6 process---->| | | | Figure 2.1 Local Key Exchange between MN and an Appropriate AR a primary care-of address from the available subnet prefixes of the AR and registers its primary care-of address with its home agent. Upon successful binding update with its home agent and in parallel to its data traffic going through the AR, MN performs a simple two-way local key exchange with the AR as specified in the next two steps (a)MN generates a key exchange request, including a 16-octect secret key Kbm that is encrypted by advertised RSA public key of AR and the requested lifetime for the key, and places the request within a new type of mobility header (see 3.2). The mobility header is sent to the AR within the following IPv6 packet --------------------------------------------------- | src | Mobility | Home Address | | dst | Header | Option | --------------------------------------------------- where dst is the AR link-local address, src is the MN link- local address, the home address option is MN primary CoA. Upon receiving the key exchange request, AR obtains the Changwen, Hesham Expires Sept. 2003 - 5 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 shared secret key Kbm by decryption with its RSA private key. Then, AR creates a new LBSA for the MN in the local cache, which includes the MN's CoA, AR address, the shared secret key Kbm, and lifetime of the LBSA. And AR MUST also remove any existing LBSA with this MN. (b)Then, the AR MUST generate an acknowledgement, signed by the shared key, as a new type of mobility header with new mobility options (see 3.2), and send back the acknowledgement to MN with the following IPv6 packet --------------------------------------------------- | src | Mobility | Destination Address | | dst | Header | Option | --------------------------------------------------- where dst is the MN link-local address, src is the AR link- local address, and the destination address option is the MN current CoA. Upon receiving the key exchange acknowledgement, MN verifies the integrity of the message using the shared secret key. Only when the verification is successful, MN also creates the LBSA for the AR in the local cache. Notice that in local key exchange request and acknowledgement, the link-local addresses of both MN and AR are utilized as the packet source and destination addresses. The hop number of the packets MUST be 255. The simple key exchange procedure will set up the LBSA between MN and the AR. Immediately following the two-way key exchange, the AR initiates a standard DAD procedure for the MN CoA address. In the DAD procedure, the Neighbor Solicitation from the AR MUST have an authentication request option (see 3.1.2), which is based on the just established LBSA, indicating its request for an authorization data in the reply. When MN receives a Neighbor Solicitation for DAD with such an option, it MUST multicast a Neighbor Advertisement for the Solicitation, and the Advertisement MUST have an authentication reply option (see 3.1.3) which includes an authorization data created by the established LBSA. The AR will verify each received Neighbor Advertisement for its DAD Neighbor Solicitation. If it receives an Advertisement that doesn't have the authentication reply option, it MUST immediately invalidates the LBSA it established with the MN. If it only receives Advertisement with authentication reply option and can validate the option with the established LBSA with MN during the DAD procedure, it will mark the LBSA as valid and MUST cache one of the replies at the end of the DAD procedure. Later when the AR receives any Neighbor Solicitation for DAD for the MN CoA address, it will forward the cached Advertisement to the DAD multicast groups. The cached Changwen, Hesham Expires Sept. 2003 - 6 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 advertisement will be deleted when the LBSA expires or is removed or when the AR performs a successful binding update procedure with the MN. If the LBSA is going to expire while MN is at the same link with this AR, MN SHOULD renew LBSA by repeating the aforementioned two-way key exchange and DAD Procedures. AR MUST always remove old LBSA and the corresponding cached advertisement when it sets up a new LBSA for the same MN. When MN changes to a new link with a new AR, MN first picks a previous AR with which the MN's HA at the home network is still tunneling packets to, e.g. maybe the last previous AR, and then performs a binding update with this AR with the earlier created LBSA to utilize this AR as the temporary home agent for the corresponding CoA. The binding update procedure consists of binding update message, binding acknowledgement message similar to these for the Return Routability Procedure [3], and a new and optional Finished message for MN reachability check. The three messages have the following format (a)Binding Update The mobile node uses the created LBSA to authorize the Binding Update. The contents of the message are as follows: --------------------------------------------------- | src | Mobility | Home Address | | dst | Header | Option | --------------------------------------------------- where dst is the previous AR address, src is MN new care-of address, and the home address option is MN previous primary CoA. The mobility header contains a Binding Update message, which in turn contains a Binding Authorization Data [3] calculated by MAC_Kbm(src | dst | BU), where "BU" is the content of the Binding Update message, excluding (i) the IP header, (ii) any extension headers between the IP header the Mobility Header, and (iii) the Authenticator field inside the Binding Update. The first 96 bits from the MAC result are used as the Authenticator field. The mobility header also contains a sequence number that will be used to match an eventual acknowledgement with this message. The sequence numbers start from a random value. (b)Binding Acknowledgement The Binding Update MUST be acknowledged by the AR. The contents of the message are as follows: -----------------------------------------------------------| | src | Mobility | Destination Address | options | | dst | Header | Option | | -----------------------------------------------------------| where dst is MN's new care-of address, src is AR's address, the destination address option is the MN previous CoA, and the sequence number is directly copied from the Binding Changwen, Hesham Expires Sept. 2003 - 7 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 Update. The Mobility Header contains a Binding Acknowledgement message, which in turn contains a Binding Authorization Data calculated by MAC_Kbm(src | dst | BA), where "BA" is the content of the Binding Acknowledgement message, excluding (i) the IP header, (ii) any extension headers between the IP header the Mobility Header, and (iii) the Authenticator field inside the Binding Acknowledgement. The first 96 bits from the MAC result are used as the Authenticator field. The options field can be null as well as carry additional messages from AR to MN, one of these is request for another Finished message from MN (see 3.2.3). (c)Finished Message The Finished message has the similar format as the binding Acknowledgement. The contents of the message are as follows: -------------------------------------------------| | src | Mobility | Home Address | | dst | Header | Option | -------------------------------------------------| where dst is AR's address, src is MN's new care-of address, the home address option is the MN previous primary CoA, and the sequence number is directly copied from the Binding Acknowledgement. The Mobility Header contains a Finished Message, which in turn contains a Binding Authorization Data calculated by MAC_Kbm(src | dst | F), where "F" is the content of the Finished message, excluding (i) the IP header, (ii) any extension headers between the IP header the Mobility Header, and (iii) the Authenticator field inside the Finished messaget. The first 96 bits from the MAC result are used as the Authenticator field. Upon receiving the binding update, the previous AR will look up for the corresponding LBSA by the MN's previous care-of address and AR address pair. Once the AR finds the LBSA. it will verify the Binding Authorization Data. When the Binding Authorization Data verification is successful, the AR creates a binding cache entry for the MN, remove the cached Neighbor Advertisement for MN, sends a successful acknowledgement back to MN, in which, the AR can optionally have an option to request a Finished message from MN to verifying MN reachability at its new CoA. Otherwise, the AR MUST send a proper error acknowledgement back to MN indicating the cause of the failure. When MN receives a successful binding acknowledgement, it must check the presence of the option for Finished message. If the option is present, it MUST send a Finished message back to AR. 2.2 Benefits No certificates are utilized in the LKE procedure, and hence the LKE has no dependency on PKI. The LBSA is completely dynamically Changwen, Hesham Expires Sept. 2003 - 8 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 set up between MN and an access router. There is no need to have any prior relationship between them. So the protocol is globally scalable. Furthermore, the previous AR won't need to perform DAD at binding update time for MN, and hence the fast handover is facilitated. One direct application of the LKE protocol is the local mobility management for Mobile IPv6. When a LKE-capable MN changes from AR to AR in a defined domain with all of the utilized ARs supporting LKE, there are two ways for MN to utilize the LKE procedure in the domain (1)Always perform bind updates both with its home agent at the home network and with its last previous AR simultaneously. (2)Utilize an AR as its temporary home agent as long as possible. In other words, MN should perform binding update either as the first choice with the oldest AR, with which MN still has a valid LBSA and has already performed successful binding update before, or with the last previous AR. MN needs to perform a binding update with its HA at the home network only when MN switches to a new temporary home agent or its LBSA with its current temporary home agent is going to expire. In this usage, the AR that acts as MN's temporary home agent is similar in some extent to the role of MAP as in [14]. Either way, the binding update to a previous AR is local to the domain. Upon the successful local binding update, MN can then continue receiving packets forwarded by the previous AR and sending packets using previous CoA by reverse tunneling packets to the previous AR. In particular, MN can utilize this service before it finishes its binding update with its home agent at its home network. Therefore, localized mobility management is achieved. 3. New IPv6 Message Types A few new IPv6 messages are defined: Some as new Neighbor Discovery options and the others as the new mobility header types. 3.1 New Neighbor Discovery Options 3.1.1 LKE Capability Advertisement This ND option is attached to the router advertisement as a Neighbor Discovery option so LKE-capable MN can recognize this option and initiate LKE with this AR. This option MUST NOT be included in a Router Advertisement in which the Home Agent (H) bit is not set. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Changwen, Hesham Expires Sept. 2003 - 9 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 | Type = 6 | Length | Maximum Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Public Key ~ ~ ~ ~ ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ND Fields Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Maximum Lifetime The maximum allowed lifetime for valid LBSA to be set up between this AR and MN. The value in this field MUST not exceed the Router Lifetime as well as the Home Agent Lifetime [3] if the latter is present. The Maximum Lifetime must not be forever. Recommended Maximum lifetime is 7200 seconds. Public Key Encoded public key. Currently, only RSA Key is supported. 3.1.2 DAD Authentication Request This option is utilized as a ND option when AR sends a Neighbor Solicitation for performing DAD for MN primary CoA after the key exchange so LKE-capable MN can recognize this option and send back a multicast advertisement with the corresponding DAD authentication reply option. 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 = 7 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Changwen, Hesham Expires Sept. 2003 - 10 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AR Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | HMAC-SHA1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ND Fields Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Reserved Must be zero. Nonce Random number. AR address The AR address. It is the address used to establishing the LBSA for the targeted MN address. HMAC-SHA1 HMAC with SHA1 utilizing the negotiated 16-octct secret key over the whole solicitation packet for integrity. 3.1.3 DAD Authentication Reply This option is utilized as a ND option when MN sends a Neighbor Advertisement for replying to a Neighbor Solicitation with a DAD authentication request. It is for LKE-capable AR to recognize this option and to verify the integrity of the message. 0 1 2 3 Changwen, Hesham Expires Sept. 2003 - 11 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 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 = 8 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AR Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | HMAC-SHA1 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ND Fields Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Reserved Must be zero. AR address The AR address. Copied from the neighbor solicitation. Nonce Random number. Copied from the Neighbor Solicitation. HMAC-SHA1 HMAC with SHA1 utilizing the negotiated 16-octct secret key over the whole advertisement packet for integrity. 3.2 New Mobility Headers and Options Changwen, Hesham Expires Sept. 2003 - 12 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 The local key exchange messages between MN and AR extends the Mobile IPv6 mobility headers and mobility options as specified in the next four subsections 3.2.1 Key Exchange Request The key exchange request from MN to AR has the format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Seq# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Key Exchange Data ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=3 | Option Len=2 | Requested lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address MUST be the AR link-local address at the Router Advertisement. Hop Limit 255 Priority 15 Mobility Header Fields: Seq# The sequence number of this request. It is to be increased monotonically. Key Exchange Data The secret key generated by MN. The secret key length is always 16 octets and is encrypted by the AR's RSA public key. Requested lifetime The requested lifetime for the LBSA. It SHOULD not exceed the Maximum Lifetime value Changwen, Hesham Expires Sept. 2003 - 13 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 advertised in the new ND option as defined in 3.1. 3.2.2 Key Exchange Acknowledgement The key exchange acknowledgement from AR to MN has the format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type = 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq# | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=4 | Option Len=16 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | AR Global/Site Unicast address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=5 | Option Len=20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | HMAC-SHA1 | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address MUST be the MN link-local address at from the LKE request. Hop Limit 255 Priority 15 Mobility Header Fields: Seq# The sequence number copied from the key exchange request that the acknowledgement is for. Changwen, Hesham Expires Sept. 2003 - 14 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 Router Global/Site Unicast Address AR global or site scope unicast address. MN utilizes this address for the Binding Update when it changes to a new AR. It SHOULD has the same prefix as MN CoA. HMAC-SHA1 HMAC with SHA1 utilizing the negotiated 16-octct secret key over the whole acknowledgement IP packet for integrity. Lifetime The granted lifetime for the LBSA, in time units of 4 seconds. 3.2.3 Finished Message Request This mobility option is attached to the Binding Acknowledgement from AR to MN if the AR wants a Finished message from MN. Its presence in the Binding Acknowledgement is optional +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=6 | Option Len=6 |r| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| r If r bit is turned on (1), it indicates that that AR is requesting a Finished message from MN. Nonce Random number. 3.2.4 Finished Message This message is sent from MN to AR upon request from AR as part of the binding update procedure. The Finished Message uses the MH Type value 10. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Changwen, Hesham Expires Sept. 2003 - 15 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | . . . Binding Authorization Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status 8-bit unsigned integer indicating the disposition of the Binding Acknowledgement. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence # The Sequence Number in the Finished message is copied from the Sequence Number field in the Binding acknowledgement. It is used by the mobile node in matching this with an outstanding Binding Acknowledgement. Lifetime The granted lifetime, in time units of 4 seconds, for which this node SHOULD retain the entry for this mobile node in its Binding Cache. It is copied from the lifetime field in the Binding acknowledgement. Nonce Copied from Binding Acknowledgement. Binding Authorization Data Similar to the binding authorization data in the binding update from MN. 4. Access Router Considerations 4.1 Configurations The access router that supports local key exchange MUST generate a proper size RSA key pair in prior. The recommended RSA key length is 1024 bits. The maximum lifetime for the key exchange in AR's router advertisement message should not be too short that may result in frequent key renew requests from mobile nodes and increased power consumption on mobile nodes. It should not be too long that may Changwen, Hesham Expires Sept. 2003 - 16 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 result in too many inactive LBSAs in AR. It should be some value that can give good user experiences. A good lifetime may be 7200 seconds. 4.2 Local Key Exchange If AR already has a valid IPsec SA with MN, it MUST reject any attempts by the MN to set up a LBSA. When receiving repeated LKE requests from MN, AR SHOULD implement exponential time backoff algorithm for processing the request messages. Upon receiving a binding update from some MN, the AR has to look up for the corresponding LBSA by the address pair of MN's previous care-of address specified in the home address option and AR address. If AR has validated Binding Update based on a LBSA for an IPv6 node, then the binding entry created by the binding update can only be deregistered by the LBSA. 4.3 DAD for MN Upon key exchange with MN, the AR MUST immediately performs DAD for MN primary CoA with DAD authentication request in its Neighbor Solicitation request. Unless the AR only receives Neighbor Advertisements that have the DAD authentication reply option and is able to validate the option by looking up for the corresponding LBSA by the address pair of MN's care-of address, which is the source address of the DAD advertisement, and AR address, AR MUST invalidate the LBSA with the MN. After the successful DAD, the AR MUST cache at least a DAD Neighbor Advertisement from the MN, and forward the advertisement later whenever it receives another DAD Solicitation for the MN primary CoA to prevent another node acquires the MN address as its address. The AR MUST remove the cached advertisement for the MN once it receives a Binding Update from the MN or the LBSA expires or is removed. 4.4 Binding Update Processing The AR MUST not perform DAD for MN when the AR receives a binding update from MN in order to facilitate fast handover. The AR Must also remove its cached advertisement for the MN once it receives a Binding Update from the MN. 5. Mobile Node Considerations 5.1 Configurations Changwen, Hesham Expires Sept. 2003 - 17 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 A Mobile IPv6 node MN that supports local key exchange MUST be capable of generating random 16-octet secret key and has the capability of encrypting the key with a RSA public key. 5.2 Local Key Exchange MN that supports local key exchange MUST create a LBSA after it receives and verifies a local key exchange Ack for a request it sent earlier. When one LKE-capable MN does not receive acknowledgement for a local key exchange request, it SHOULD resend the request with the same key but increased sequence number. If one LKE-capable MN receives a local key exchange Ack it cannot verify, it MUST remove any LBSA it has set up with the AR in prior and then SHOULD restart LKE procedure with the AR to set a new LBSA. 5.3 DAD From AR If MN receives a DAD solicitation for its address with an authentication request option from AR, whose address can be identified in the request option, it MUST multicast a DAD advertisement with an authentication reply option based on the LBSA with the AR. If MN receives a DAD advertisement for its address without an authentication reply option for a DAD solicitation with authentication request option from AR, it SHOULD remove any LBSA it has set up with the AR in prior and then SHOULD restart LKE procedure with the AR to set a new LBSA. 5.4 Binding Update Processing And MN MUST also perform binding update with its HA at its home network before its LBSAs with ARs expire. 6. Security Considerations We will show that the LKE based mobility security mechanism is sufficient to satisfy the "do no harm" principle [12]. It is assumed that the visited link by MN allows the following basic operations even in the presence of attackers (1)MN can perform normal ND and configure an IPv6 address as its care-of address; (2)MN and its LKE-capable AR can reach each other at link layer without going through attackers; (3)Both the AR and other normal IPv6 nodes can participate in DAD; (4)Normal IPv6 nodes on the link can send and receive packets using their IPv6 addresses. All the LKE messages are on local link only and both MN and AR reject any LKE messages with non-link-local addresses or the hop count being less than 255. Hence no attacks can be launched from Changwen, Hesham Expires Sept. 2003 - 18 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 other links. Attackers are assumed to be at the local link, have substantial computational resources and cannot obtain secret information from sources outside the protocol. They have the ability to send messages by themselves, capture, modify, replay, and otherwise tamper with messages sent over the local link. This section first analyzes the trust model for the LKE based mobility procedure. Then it outlines how the local key exchange is designed to resist a variety of attacks, and shows that LKE does not introduce additional vulnerability to Mobile IPv6 and IPv6 protocols. 6.1 Trust Model In the LKE procedure, public key is utilized for setting up the LBSA between MN and its AR. MN gets the public key from the AR in its router advertisement. MN's trust for the public key is based on the two factors (1)The "binding" of the public key with AR's link-local and link- layer address pair as seen in the router advertisement. i.e. the public key belongs to the AR's address pair, and (2)The successful routing task performed by AR for MN registration with its HA (as well as for MN data packets later). This verifies the fact that the AR does have the capability to perform what it claims to do: routing packets correctly. AR's trust for the established LBSA is based on the following factor (1)When AR finishes a key exchange with an established LBSA, it also immediately performs a DAD for the IPv6 address. Only when the DAD shows that no other on-link IPv6 nodes other than the node that performs the key exchange claim the address, AR will act as the home agent for the IPv6 address later upon successful binding update. Otherwise, AR won't act as the home agent role for the IPv6 address. In other words, the security of the LKE procedure is hence based on the two sides: (1)The liveness of the AR seen by MN, and (2)The liveness of the MN seen by AR. The first is used to secure the trust of MN to AR's public key and the second is used to secure the trust of AR to MN shared secret key. The two factors together warrant the overall security of the LKE-based mobility procedure. 6.2 DoS Against AR An attacker may flood AR with key exchange requests so that AR is busy on decrypting the key exchange requests. To prevent that, An LKE-capable AR MUST limit key exchange request rate the AR can take from a link-local address and/or link-layer address, e.g. one new request in every 3 seconds from a given link-local Changwen, Hesham Expires Sept. 2003 - 19 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 address. 6.3 Impersonation Attack Against AR An attack may spoof as AR and send router advertisement that has LKE extension on the local link. This is a threat regardless the existence of MN. In other words, it is a problem for non-mobile nodes too. Notice that MN initiates local key exchange with an AR only after MN has performed successful binding update with a HA via this AR. A malicious attacker that does not forward the binding update packets will not be able to launch this attack. So the local key exchange process alleviates this threat. To completely eliminate this threat, one may require router advertisements to be IPsec protected or utilize other secure ND mechanisms. 6.4 Impersonation Attack Against an IPv6 Node An attacker may spoof as an IPv6 node on the link and perform a LKE procedure with the AR. The attacker can then move to another link, perform a binding update with the AR to try to redirect and hijack all the traffic destined to the IPv6 node to the attacker itself. However when the AR finishes the key exchange, the AR is going to perform a DAD, is able to detect the duplication at that time, upon that will invalidate the LBSA, and hence will fail the binding update from the attacker. In this way, the traffic destined to the IPv6 node won't be redirected and hijacked. So the LKE procedure prevents malicious traffic redirection and hijacking for all on-link IPv6 node. In other words, only fully authorized mobile nodes can get the home agent services from their previous access routers. 6.5 Replay Attack An attacker may fake as some MN and replay an old key exchange request between MN and AR. However due to the existence of sequence number in the request, this attacker can be relatively easily foiled. 6.6 Relationship to Other Security Mechanisms The LKE is not dependent on the other security mechanisms such as Secure Neighbor Discovery or NAS-based AAA infrastructure specified in [8][9][10]. The LKE based mobility can be utilized at links where no security mechanisms are supported. However, the LKE based mobility can also work together with these security mechanisms such as SEND or NAS-based AAA infrastructure. For example, if the SEND is supported at a link by both AR and MN, the LKE can take advantage of the additional capability of MN and AR Changwen, Hesham Expires Sept. 2003 - 20 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 to set up the LBSA more securely: AR may sign its advertisement message with its address based key or certificate, and MN may sign its local key exchange request message with its address based key. 7. Open Issues to be worked on next -- On-link attacks against IPv6, e.g. MAC address spoofing, may also work for the LKE procedure. 8. Acknowledgements The authors would like to thank Hani Elgebaly and Prakash Iyer of Intel Corporation and Kevin Miles of Cisco for their review and valuable feedback on an this draft. In particular, the authors would like to express warm thanks to Hani Elgebaly for supporting the draft effort. References [1] Bradner, S., "The Internet Standards Process, Revision 3," RFC 2026, October 1996. [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] David B. Johnson, Charles E. Perkins, and Jari Arkko "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-19.txt, Oct 2002, work in progress. [4] T. Narten, E. Nordmark, and W. Simpson "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, Dec. 1998. [5] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, Feb. 1997 [6] G. Dommety editor "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-04.txt, March 2002. [7] Alex Conta, and Steven Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC2463, December 1998 [8] James Kempf, Craig Gentry, Alice, Silverberg "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", draft-kempf-secure-nd-01.txt, June 2002. [9] Jari Arkko "Effects of ICMPv6 on IKE and IPsec Policies", draft-arkko-icmpv6-ike-effects-01.txt, June 2002. [10]Mitton, D., and Beadles, M., "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000. [11]"802.1x - Port Based Access Control", IEEE Standard for Local and Metropolitan Area Networks, 2001. [12]A. Mankin, B. Patil, D. Harkins, E. Nordmark, P. Nikander, P. Roberts, T. Narten. "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", draft-ietf-mobileip-mipv6-scrty-reqts-02.txt. Work In Changwen, Hesham Expires Sept. 2003 - 21 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 Progress, IETF, November 2001. [13]S. Glass, and M. Chandra, "Registration Revocation in Mobile IPv4", August 2002, draft-ietf-mobileip-reg-revok-04.txt. [14]Hesham Soliman, Claude Castelluccia, Karim El-Malki, and Ludovic Bellier, "Hierarchical MIPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-07.txt, October, 2002. Author's Addresses Changwen Liu Intel R&D 2111 NE 25th Ave, JF3-206 Hillsboro, OR 97124 USA Phone: +1 503 264 9262 FAX: +1 503 264 3483 E-mail: changwen.liu@intel.com Hesham Soliman Ericsson Radio Systems AB Torshamnsgatan 23, Kista, Stockholm 16480 SWEDEN Phone: +46 8 4046619 Fax: +46 8 4047020 E-mail: Hesham.Soliman@era.ericsson.se Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or Changwen, Hesham Expires Sept. 2003 - 22 - Internet Draft draft-liu-mobileip-lke-01.txt March 2003 assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Changwen, Hesham Expires Sept. 2003 - 23 -