Mobile IP Changwen Liu INTERNET DRAFT Intel draft-liu-mobileip-lke-00.txt Nov 2002 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, two new types of mobility headers and one Neighbor Discovery option are defined. All IPv6 nodes MAY support this protocol. Liu Expires May 2003 [Page i] Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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..........................................................7 3.New IPv6 Message Types..............................................8 3.1 New Neighbor Discovery Option.....................................8 3.2 New Mobility Headers and Options..................................9 3.2.1 Key Exchange Request............................................9 3.2.2 Key Exchange Acknowledgement...................................10 4.Access Router Considerations.......................................12 4.1 Configurations...................................................12 4.2 Local Key Exchange...............................................12 4.3 Binding Update Processing........................................12 5.Mobile Node Considerations.........................................12 5.1 Configurations...................................................12 5.2 Local Key Exchange...............................................12 5.3 Binding Update Processing........................................13 6.Security Considerations............................................13 6.1 Trust Model......................................................13 6.2 DoS Against AR...................................................14 6.3 Impersonation Attack Against AR..................................14 6.4 Impersonation Attack Against an IPv6 Node........................14 6.5 Replay Attack....................................................15 6.6 Relationship to Other Security Mechanisms........................15 7.Open Issues to be worked on next...................................15 8.Acknowledgements...................................................16 References...........................................................16 Author's Addresses...................................................17 Full Copyright Statement.............................................17 Liu Expires May/2003 - 1 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 Liu Expires May/2003 - 2 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 Liu Expires May/2003 - 3 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 | |<------------------------------------------------------ | | | | | |<------------- Data Traffic ------------------------->| | | | | | . . . | | | | | | Router advertisement with | | or without LKE extension | |<------------------------------| | | Liu Expires May/2003 - 4 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 | Binding Update | |-------------------------------|----------------------->| | | ------| | | | | | | DAD for 1st time | | | binding update | | | | | | Binding Ack | ------| |<------------------------------|----------------------- | | | | |<------------- 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 shared secret key Kbm by decryption with its RSA private key. AR SHOULD consult its Neighbor cache, e.g. to verify the association of MN's MAC address with CoA and/or link- local address. After that and if all are successful, 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 --------------------------------------------------- Liu Expires May/2003 - 5 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 | 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. If the LBSA is going to expire while MN is at the same link with this AR, MN SHOULD renew LBSA by repeating the above two-way key exchange Procedure. AR MUST always remove old LBSA 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 and binding acknowledgement messages, similar to these for the Return Routability Procedure [3], 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. Liu Expires May/2003 - 6 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 (b)Binding Acknowledgement The Binding Update MUST be acknowledged by the AR. The contents of the message are as follows: --------------------------------------------------- | src | Mobility | Destination Address | | 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 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. 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. If it is the first time for the AR to process binding update with this MN's LBSA, the AR MUST also perform a DAD for the requested home address, regardless whether MN requests the DAD or not. Only when both the Binding Authorization Data verification and DAD are successful, the AR creates a binding cache entry for the MN and sends a successful acknowledgement back to MN. Otherwise, the AR MUST send a proper error acknowledgement back to MN indicating the cause of the failure. In the case that the AR verifies the Binding Authorization Data successfully but fails the DAD, the AR MUST both remove the MN's LBSA and send an acknowledgement message, protected by the binding authorization data option, to MN indicating its termination of providing home agent service to this MN with error code of 134 for DAD failure. 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 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. 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 Liu Expires May/2003 - 7 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 Three new IPv6 messages are defined: one as a new Neighbor Discovery option to be attached to router advertisement. The others are as the new mobility header types. 3.1 New Neighbor Discovery Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length | Maximum Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Public Key ~ ~ ~ Liu Expires May/2003 - 8 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 ~ ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.2 New Mobility Headers and Options The local key exchange messages between MN and AR extends the Mobile IPv6 mobility headers and mobility options as specified in the next two 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liu Expires May/2003 - 9 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 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 | | Liu Expires May/2003 - 10 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 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. 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. Liu Expires May/2003 - 11 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 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 have 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 Binding Update Processing If AR fails MN's binding update, which is based on MN's LBSA, due to DAD failure, AR MUST remove the LBSA for that MN. 5. Mobile Node Considerations 5.1 Configurations 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. Liu Expires May/2003 - 12 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 Binding Update Processing If a LKE-capable MN receives binding acknowledgement indicating DAD failure for a LBSA protected binding update to one of its previous AR, the MN MUST remove the LBSA with that AR. And MN MUST also perform binding update with its HA at its home network if it has not done so. 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 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- Liu Expires May/2003 - 13 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 receives a binding update with a LBSA for the first time, it also immediately performs a DAD for the IPv6 address. Only when the DAD shows that no other on-link IPv6 nodes claim the address, AR will act as the home agent for the IPv6 address. 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 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 Liu Expires May/2003 - 14 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 receives the binding update, the AR is going to perform a DAD, is able to detect the duplication (since the node is still on the link), and upon that, won't act as the home agent for 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 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. -- In the current draft, when an AR receives a binding update from some MN utilizing MN's LBSA for the first time, the AR must perform the DAD before it sends back acknowledgement to MN to be compliant with Mobile IPv6 specification. If LKE-capable MN was be able to process acknowledgement message not for an outstanding binding update, e.g. extending mechanism in [13] to Mobile IPv6, AR could first send an Ack to MN upon successful Binding Authorization Data validation and then perform a DAD. If the DAD fails, AR sends another Ack message to MN, indicating the termination of temporary home agent service by this AR, and the MN Liu Expires May/2003 - 15 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 can still process this acknowledgement based on its LBSA and take proper action, e.g. stop tunneling any packets to the AR. This scheme will achieve better handover performance than what currently in the draft. 8. Acknowledgements The author 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 author 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 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 Liu Expires May/2003 - 16 - Internet Draft draft-liu-mobileip-lke-00.txt Nov 2002 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 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 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. Liu Expires May/2003 - 17 -