INTERNET-DRAFT Home Agent Cookies Michael Thomas Dave Oran Cisco Systems July 12, 2001 Home Agent Cookies for Binding Updates draft-thomas-mobileip-ha-cookies-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes a means of performing authentication and authorization of Mobile IP V6 binding updates. It takes advantage of the pre-existing security relationship between the mobile node and its home agent to allow a correspondent node to decide wether or not it should believe a binding update, and to perform key distribution for authorizing future binding updates. The mechanism employs authenticated cookies created by the mobile node using a key which it shares with its home agent. The cookie is included in a binding update message to the correspondent node. The Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 1] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 correspondent node extracts the cookie and sends it in a verification request sent toward the mobile node using the mobile node's home address. If routing tables have not been compromised, this message will visit the mobile node's home agent. The home agent intercepts the verification request and cryptographically determines whether the binding update was generated by one of its mobile nodes. Assuming it verifies correctly, the home agent can vouch for the mobile node thereby authorizing the binding update. The home agent and mobile node may optionally generate a new (symmetric) key to be used by the correspondent node in subsequent binding updates. This is shipped back to the correspondent node in an acknowledgment message from the home agent so that the correspondent node can directly verify future binding updates. 1. Introduction The advent of Mobile IPv6 brings the protential elimination of triangular routing between a mobile node and its correspondent nodes. In standard Mobile IPv6, this is achieved through the use of Binding Update messages sent by the mobile node to the correspondent node to update the mobile node's current location -- it's care of address -- in the correspondent node's binding cache. Binding Updates, however, introduce a security hazard. In the absence of some means to authenticate and authorize Binding Updates, an unauthorized host could spoof a Binding Update to the correspondent node causing all further traffic send by the correspondent node to be routed to the care of address that the attacker chose. At the very least, this could lead to a trivial denial of service attack, an active man in the middle attack, or a passive snooping attack. For this reason, [MOBILEIPV6] requires that binding update destination options be protected by an IPsec security association using an authentication header to insure that there is end to end (i.e. MN->CN) integrity of the binding messages. There is a presumption made in [MOBILEIPV6] that the correspondent node will be able to authenticate and authorize binding updates. The object being authenticated is, in fact, the home IP address of the mobile node. Therefore, in order to deploy [MOBILEIPV6] widely, there is a presumption that there will exist a pervasive and well established global PKI for asserting the ownership and validity of IP addresses. This is what would allow any corresponent node to authenticate and authorize a binding updates from a mobile node based on its provable right to assert a particular home IP address. Such a PKI for IP addresses does not today exist, and it is not clear that such a system could be deployed quickly enough to meet the needs Mobile IP users and providers. There is a lot of compelling evidence that this, is either extremely difficult or even less charitably, a Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 2] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 fantasy. We therefore agree with the general premise put forth in the Purpose-based Keys draft [PBK] that a solution which has weaker properties than provable rights to assert an IP address, but which foils easy attack on Binding Updates is vitally necessary to the successful deployment of Mobile IPv6. The proposal put forth in the [PKB] draft, as we understand it, enforces the following security property: o If a mobile node successfully communicates with a correspondent node some moment in time (i.e. an attacker has not yet spoofed a binding update) then future communication cannot be subverted by a subsequent attack. This Home Agent Cookies proposal enforces a different property: o If a correespondent node can successfully communicate with a Mobile node using mobile node's home IP address (i.e. neither routing via the home agent nor home IP address assignment has been subverted), then communicating directly with the mobile using its current care of address is no less secure. We offer the following observations to support our contention that this property is appropriate and the mechanism we propose to ensure it makes a reasonable tradeoff among security, proto- col complexity, and deployability. o We observe that while it is difficult to deploy a global PKI, PKI's within more confined bounds are a reasonable expectation. o To wit, we believe that the current method of doing binding updates between the mobile node and its home agent provides ade- quate protection against malicious subversion since the home agent can through local policy means determine whether a partic- ular mobile node is authorized to change its reachability for one of the subnets that the home agent subtends. o We can use the property that the home agent has the responsibil- ity of the reachablity of the subnets it subtends to also act as an authority for other nodes which may need knowledge of a mobile node's current binding status. o We can also use the property that correspondent nodes will, in the absence of a binding cache entry, send packets to the mobile node using it's home IP address. We can use this routing Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 3] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 property to discover which router contains the mobile node's current binding by simply sending a packet to the mobile node itself. o We generally make the observation that the routing infrastruc- ture needs to be secure enough such that attacks based upon being able to subvert the routing infrastructure will be viewed as serious in their own right and countered. We also note that home agents which do not act toward the eventual goal of routing packets to their destination make little sense, especially in light of routers which route packets destined for subnets which have been delegated to their administrative realm. Given the above observations, this memo describes a means of performing authentication and authorization as well as key dis- tribution for binding updates which takes advantage of the pre- existing security relationship between the mobile node and its home agent. The mechanism employs authenticated cookies created by the mobile node using a key which it shares with its home agent. The cookie is included in a binding update message to the correspondent node. The correspondent node extracts the cookie and sends it in a verification request sent toward the mobile node using the mobile node's home address. If routing tables have not been compromised, this message will visit the mobile node's home agent. The home agent intercepts the verification request and cryptographically determines whether the binding update was generated by one of its mobile nodes. Assuming it verifies correctly, the home agent can vouch for the mobile node thereby authorizing the binding update. The home agent and mobile node may optionally generate a new (symmetric) key to be used by the correspondent node in subsequent binding updates. This is shipped back to the correspondent node in an acknowledg- ment message from the home agent so that the correspondent node can directly verify future binding updates. 2. Message Flows Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 4] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 2.1 Message Flow from Mobile Node to Correspondent Node MN CN HA ---------------------------------------------------------------------- 0 <===============================================================> normal HA/MN security association establishment 1 --------------------------------> BU+cookie[mn,ha]+cookie[mn,cn] 2 --------- -----------------------> BU_QUERY+cookie[mn,ha]+PK[cn] 3 <--------- ----------------------- BU_QUERY_RESP+E(key[mn,cn],PK[cn]) 4 [ <-------------------------------- ] [ BU_ACK ] ~~~~~ ~~~~~ 5 --------------------------------> BU+cookie[mn,ha]+cookie[mn,cn] 6 <-------------------------------- BU_ACK Step_0 The mobile node and its home agent create a security associa- tion. In addition to the keys generated for the base security association, another set of keys derived from the SA's keys are generated by both the mobile node and the home agent. In addi- tion, a session identifier is also devived by both the home agent and the mobile node. The derivation functions are described in section 4. Step_1 When the mobile node discovers that it needs to send a binding update for which it cannot create a normal IPsec security asso- ciation, it creates two cookies to be placed in the binding update. Each cookie contains a keyed hash over the contents of the binding update described in section 5. The first cookie is Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 5] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 generated for the home agent, the second cookie is generated for the correspondent node itself. The mechanism for generating the key for the correspondent node is described in section 4. Step_2 The correspondent node receives the binding update and deter- mines that it does not currently have the ability to verify the update. It then takes the cookie destined for the home agent and creates a Binding Update Query option -- and places either in a stand alone message, or piggy backed on another message destined for the mobile node. The destination address of the binding update query is the mobile node itself. The Binding Update Query option is inserted into the IP header to alert all of the routers along the way. In this way, we make certain that the mobile node's Home Agent will have an opportunity to process the Binding Update Query. Step_3 The Home Agent receives the packet destined for the mobile node and processes the Binding Update Query option. It does this by first examining the cookie and determines whether the integrity check and contents are valid and fresh. If the correspondent node placed its public key into the Binding Update Query mes- sage, the Home Agent will generate a key for the correspondent node and place it in the Binding Update Query Response message. The key is generated as described in lsection 4 and contents are encrypted and integrity protected per section 5. Step_4 The correspondent node receives the Binding Update Query Response and performs a message integrity check over the message and decrypts the contents, including the key. The correspondent node SHOULD use the newly shipped key to verify the contents of the cookie destined for the correspondent node in the initial binding update. In this way, the correspondent node can cross check that the home agent which sent the BUQR shares a relation- ship with the mobile node. This key is subsequently used by the correspondent node to directly validate the correspondent node cookie signed by the mobile node. The correspondent node now alters its binding cache and replies to the original binding update and the tran- saction is complete. As noted above in the flow diagrams, the correspondent node only sends a binding update acknowledgement if the mobile node requested one. Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 6] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 Step_5 On subsequent changes to its care of address, the mobile node behaves identically as in step 1, creating two cookies for use by the home agent and correspondent node. Step_6 The correspondent node, since it received a key in step 4 now has a key which it can use to verify its cookie when it receives a Binding Update from the Mobile Node. Assuming the cookie veri- fies correctly, the correspondent node alters its binding cache and ackowledges the Binding Update. 2.2. A Lighter Weight Alternative The previous section describes a means of authenticating the original binding update as well as creating a shared secret so that subsequent binding updates can be directly verified by the correspondent node. There is an implicit presumption is that the cost of public key operations to encrypt the key payload at the home agent, and decrypt it at the correspondent node is not too onerous. There may, however, be situations where this cost is not acceptible. If this situation arises, the act of encrypting the key payload can be omitted. Either the correspondent node can request that the key payload not be encrypted by omitting the public key, or the home agent can refuse to create the encrypted payload. In this scenario, the correspondent node will need to repeat step 2 for each movement of the mobile node since it will not share a key. The correspondent node also loses the ability to cross verify the home agent's response, but this may be an acceptible tradeoff given the propertiy we are ensuring, since this property trusts the routing system to deliver packets correctly. 2.3 Some Attacks This section outlines some of the attacks that could be mounted by an adversary against this scheme. They should be considered in any scheme which attempts to solve the same problem. 2.3.1 Attacks by Listeners on the Mobile Network The network that the mobile node is attached to may be susceptible to eavesdropping in which case an attacker could capture an outgoing binding update. As such, the attacker could respond to the binding update with its own public key. If the mobile node is configured to operate in the home agentless mode, it could unwittingly reveal the secret to the attacker on its own network. This could lead to the attacker forging binding updates to the unwitting correspondent node. For this reason, a mobile node operating in home agentless mode SHOULD NOT encrypt the key for the correspondent node cookie unless Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 7] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 it has reasonable assurance that snooping attacks are not an issue on its current set of interfaces (ie, L2 mechanisms that provide ade- quate privacy). [there may also be ways to defend against this by correlating the return address with the key somehow. I think that that might run afoul of the NAT friendly stuff though, so for now I've not taken the time to work that out. /mat] 2.3.2 Attacks by Listeners on the Correspondent Node Network Likewise, the network that the correspondent node is attached to may be subject to attacks mounted by listeners. In this case, the attacker may capture both the initial Binding Update as well as the corresponent node's Binding Update Query. This leads to two possible attacks. CapturingLike the attack on the mobile node's network above, an attacker could capture the Binding Update and send a binding update request to the home agent using its own public key. Likewise as above, if the Correspondent Node believes the ingress interface is not suitably secure given layer 2 protection, it SHOULD NOT request an encrypted key to validate subsequent binding updates. SpoofingIn addition, an attacker could spoof a response to the correspondent node since it will know the transaction identifier of the query. If a correspondent node receives a response with a positive acknowledgement followed by a response with a negative acknowledgement, the correspondent node MUST accept the negative acknowledgement so long as it's within the replay window. The correspondent node MAY defer sending packets on the new binding in order to give the intended recipient an adequate amount of time to respond. This leads to a potential denial of service attack, but only leads to degraded service due to having to do triangular routing. 2.3.3 Attacks by Rogue Correspondent Nodes Since there is no direct authentication between the home agent and the correspondent node it may be possible for a rogue correspondent node to capture a legitimate signed and fresh cookie from the mobile node and either act as a man in the middle or just mount an active eavesdropping attack. Such an attacker could in theory obtain the verification key and use that verification key to generate signed and fresh binding updates to the victim correspondent node. Note that the Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 8] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 key used to generate cookies between the mobile node and its home agent is not at risk from this attack. This attack requires a fair degree of sophistication and can only be mounted by an attacker on the routing path between the mobile node at the correspondent node. To be successful, an attacker would first need to be able to capture the fresh cookie from the mobile node's binding update and not only spoof the Binding Update Query to the home agent, but also receive the response. Only then could it create bogus cookies, and even then it would only allow it to create bogus cookies to the victimized correspondent node. 2.4 Message Flow from Mobile Node to Home Agent MN CN HA ---------------------------------------------------------------------- 0 <===============================================================> normal HA/MN security association establishment 1 ----------------------------------------------------------------> BU+cookie[mn,ha] 2 <---------------------------------------------------------------- BU_ACK+cookie[ha,mn] Step_0 The mobile node and its home agent create a security associa- tion. In addition to the keys generated for the base security association, another set of keys derived from the SA's keys are generated by both the mobile node and the home agent. In addi- tion, a session identifier is also devived by both the home agent and the mobile node. The derivation functions are described in section 4. Step_1 When the mobile node discovers that it needs to send a binding update to its Home Agent, it creates a cookie to be placed in the binding update. The cookie contains a keyed hash over the contents of the binding update described in section 5. The lone cookie in this case is generated for the home agent. The mechanism for generating the key for the correspondent node is Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 9] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 described in section 4. Step_2 The Home Agent receives the binding update and verifies the cookie in the same manner as when it receives it in the binding update query message. In response, the Home Agent places a cookie in the binding update acknowledgment created in the same manner as the mobile node. This is used by the mobile node to verify that the Home Agent produced the acknowledgment. 2.5. Home Agentless Operation It should be observed that the basic trust arrangement being enforced by this memo is the return routability. While this property can be enforced by a mobile node's home agent and has some desirable charac- teristics such as the possibility of a disinterested third party in the verification process of a binding update, this property cannot be relied upon. The reason is simple: there may not be a Home Agent in the path between the a supposedly mobile node and the correspondent node. Also: since we are using a shared key between the home agent and mobile node and the correspondent node has no means to determine whether the home agent or correspondent node created the message in question. This is a direct consequence of not having strong third party authentication. However, this could be viewed as a feature. If a Home Agent is not willing or unable to authorize binding updates, we can still use the mobile node itself to provide the base level return routability. In fact, there are many schemes which provide this kind of test, so this memo is hardly unique in that respect. For completeness, this memo provides the protocol machinery which for that which was inevitable consequence of the protocol. MN CN HA ---------------------------------------------------------------------- 0 <===============================================================> normal HA/MN security association establishment 1 --------------------------------> BU+cookie[mn,ha]+cookie[mn,cn] 2 <--------------------------------- BU_QUERY+cookie[mn,ha]+PK[cn] 3 ---------------------------------> Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 10] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 BU_QUERY_RESP+E(key[mn,cn],PK[cn]) 4 [ <---------------------------- ] [ BU_ACK ] ~~~~~ ~~~~~ 5 --------------------------------> BU+cookie[mn,ha]+cookie[mn,cn] 6 <-------------------------------- BU_ACK Note that this flow is identical to the flow in section 2.1 with the exception that the mobile node takes the place of the home agent. In fact, since the "home agent" functionality is discovered in the rout- ing path, there is no difference in implemenation on the correspon- dent node's part. Also: the mobile node may, like the home agent, decide whether it wants to create a shared key with the correspondent node if it supplies its public key. In some sense, this memo is really just extends the base level return routability test to potentially involve a disinterested third party in the form of a real home agent. When the home agent is either miss- ing or not willing to perform verification requests the mobile node SHOULD expect that it will perform verification requests from time to time. If it is incapable or unwilling to receive verification requests, it MUST NOT send home agent cookies. 2.6. NAT Considerations To understand NAT considerations, we use the following diagram to describe the various possibilities of where NAT's may reside. Since NAT's must do stateful inspection, we consider that the gateway from which a message originates from behind a NAT is the same NAT that the response will traverse. It should be noted up front that as currently specified in [MOBILEIPV6], Binding Updates cannot traverse NAT's whatsover when they are protected by [AH] since [AH] includes the source address in its authenticator calculation. We also consider that basic issues with [MOBILEIPV6] with NAT's such as the Alterna- tive Care of Address binding update suboption are out of scope for this discussion since they have considerations for mobile IPv6 in general which need to be sorted out. Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 11] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 +------+ | | | HA | | | +------+ -----N1------ | | +------+ | | | N2 | CN | | | | | +------+ | -----N3------ +------+ | | | MN | | | +------+ In addition, we consider the special case where the Home Agent and Mobile Node are behind a single NAT; this will be denoted as N1+N3. To illustrate the interactions of Mobile IP with NAT's, we first declare as out of scope any situation which would produce a server behind a NAT since this is not a well defined property of NAT's. Thus the cases that seem important are: MN->HA: MN behind N3 HA->MN: MN behind N3 CN->MN: CN behind N2, MN server behind N1 MN->CN: MN behind N1, CN server behind N2 CN->HA: CN behind N2 HA->CN: CN behind N2 MN This situation may occur if a mobile node finds itself roamed into another network, but can only get a private address. It is expected that NAT N3 will perform address translation on the binding update's IP headers to reflect the proper address both to the home agent and the correspondent nodes. This case poses no additional issues for the methods described in this memo. MN This case is probably the common case where a mobile device is behind the same NAT as its home agent. This situation would Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 12] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 arise, for example, if a mobile device were roamed away from its home, but still behind a NAT'ing firewall of a corporation. This case poses no issues for the methods described in this memo. CN In this case, the correspondent node is the client initiating a conversation to the mobile node acting as a server. Since the key agreement function between HA and MN for subsequent keys which are given out to correspondent nodes is based in part on the correspondent's apparent IP address, an identifier similar to the session identifier is created so that the correspondent node can always use the correct key. The main motivation here is that the correspondent node might lose its NAT binding within the lifetime of the key, and reacquire a new binding unbeknownst to it. By using both the SessionID and CorrID to find the key, this situation can be avoided. The only other consideration here is that NAT N2 would need to translate and pass the Binding Update Query Response back from the home agent. This is similar to the considerations for ICMP ECHO REPLY messages. MN This mode violates the "no servers behind NAT". We expect that this is reasonable for the general case because a NAT may reap any current address binding at any time unbeknownst to the mobile node thus it is unlikely that a stable binding could for the mobile node could be maintained. If it could, this memo would not add any additional issues. CN While this strictly violates the "no servers behind NAT" dictum, there may be situations where this is actually a reasonable scenario. Specifically, servers which are well known to the NAT where the NAT is performing a load balancing function seem plau- sible. This memo does not introduce any additional issues, how- ever. 2.7. Comparison to Purpose Built Key Draft Both this memo and draft-bradner-pbk-frame-00 are in agreement that depending on a pervasive PKI for IP-address addresses to secure Mobile IPv6 may be unwise, and that a means of securing binding updates with weaker security properties should be considered. This section tries to outline the difference in the approaches and their different ramification without trying to draw any value judgements as to which is preferable. For simplicity, the PBK draft will be refered to as PBK and this memo will be refered to as COOKIE. Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 13] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 o PBK relies on the principle that authentication between two nodes for the purpose of binding updates is not as important as insurance that once a flow is initiated between two nodes, that it continue to flow across binding updates. COOKIE relies on a previously established security association between the mobile node and the mobile node's home agent. One ramification of PBK's approach is that there is an opportunity for a "first in" attack where a spoofed initial binding update could cause a denial of service attack for subsequent legitimate binding updates. o PBK does not rely on any third party infrastructure whatsoever. It accepts the man in the middle risk inherent in authentication-less schemes as an acceptible risk. COOKIE relies on third party authentication, namely that of the home agent. It uses the routing system provide a implicit means of delivery to the proper home agent as opposed to explicit naming mechanisms. o PBK as current proposed requires public key operations on the ini- tial binding and subsequent rebindings when the mobile node changes care of addresses. It seems feasible that PBK can be modified to remove the necessity for subsequent public key operations, however the initial public key operation is always necessary. COOKIE uses the security association between the home agent and the mobile node to create further symmetric keys. In its simplest form of operation, COOKIE does not require public key operations on either the initial or subsequent binding updates. COOKIE does require a public key encryption to transfer a key to the correspon- dent node, but this is an explicit tradeoff of computation versus message efficiency that can be made by the home agent and correspondent node. o COOKIE specifically delegates the problem of updating care of addresses to the mobile node. Since a mobile node may, in fact, be a mobile router it is important to consider the affect on the potentially non-mobile hosts behind the mobile router. COOKIE in particular does not require any special action on the part of non- mobile hosts behind a mobile router. It's action is similar in nature to any other router sending advice on the reachability of the subnets it subtends. The actual authorization for mobile Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 14] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 subnets is implicit between the mobile router and its home agent, and as has been previously discussed, can be made into a local pol- icy matter. It is unclear how the PBK draft would view the mobile router issue. o [placeholder for futher comparisons............] 3. Home Agent Discovery [MOBILEIPV6] describes a means for a mobile node to discover its home agent. This is known as the Home Agent Discovery ICMP message and is sent to the Home Agents Anycast address. When the HAV bit is set in the home agent cookie, the correspondent node MUST form the home agent anycast address by appending the subnet prefix of the source address with the Home Agent Anycast address in [MOBILEIPV6]. The binding update verification request message is, in fact, Home Agent Discovery message with the home agent cookie appended. See section 6 for details. 3.1 Verification Without the Home Agent If the HAV bit is not set, the correspondent node may perform a verification directly with the mobile node. To do this, the correspondent node simply addresses the binding update verification request to the mobile node instead of the home agent anycast address. The mobile node MUST process the message in this case. 4. Key Derivation [this entire section needs more work. it should be viewed as a general means to arrive at shared keys. /mat] This scheme derives keys by employing the base keying material which was used to create a security association between the a mobile node and its home agent. We append identifying information as well as an iterator to generate enough keying material. The entire string is hashed using MD5 to create the new keying material. The keying material is generated as follows: iterator = 0; newkey [iterator] = MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator); Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 15] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 iterator++; newkey [iterator] = MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator); [...] Where "targ" is the 128 bit IP address of the target of the cookie, and key[mn,ha] is the shared key between the mobile node and the home agent. "Interator" is a 32 bit integer, and "SessionID" is the Ses- sionID described below. The iteration function is performed as many times as is required to generate enough keying material to encrypt and sign the cookies. For 128 bits of keying material for use with MD5, a single crank of the generating function is needed. If 256 bits of keying material is needed, two cranks of the generating function is necessary and so on. sp 4.1 Session and Correspondent Identifiers In order to work properly through NAT's and other situations where the home address may not be globally unique, a keyed hash of the home address is generated instead of using the IP address directly. This identifier is generated simultaneously by the Home Agent and the Mobile Node each time they establish a shared secret. The mechanism to generate the session identifier is: sessionID = MD5(key[mn,ha]+home_address[mn]); Where "key" is the key that will be used by the mobile node to gen- erate cookies to the home agent, and "home_address" the home address of the mobile node for this home agent. IPv4 addresses would use the IPv6 address range dedicated to IPv4 address as described in [ADDRARCH]. In addition, to avoid missynchronization problems with key genera- tion, especially if the correspondent node loses a NAT binding, we creates a hash to identify the correspondent node for subsequent com- munication. corrID = MD5(key[mn,ha]+dest_address[cn]); The corr 4.2 Key Schedules It is necessary to allow keying material to be periodically refreshed. When the mobile node and the home agent rekey their secu- rity association, the mobile node MUST refresh the keying material Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 16] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 used to create cookies, as well as creating a new session identifier. The mechanism used to refresh keying material is simply to start sending new cookies based upon a different session ID. Since the correspondent node will not have a binding for that session ID, it will as in normal operation send the Binding Update Query message toward the mobile node's home agent. To expediate generation of the keying material, the mobile node MAY proactively send a binding update with a cookie reflecting the new session ID. 5. Encryption, Authenticators, Replays and Conformance Cookies are actually keyed authenticators. This section describes how the checksums are generated and verified. To generate a cookie authenticator, the hashing algorithm is run over the entire Binding Update except with all of the checksums in the cookie suboptions zeroed. The hashing algorithm is then run over the binding update and is then XOR'ed with the key this cookie is bound to. If the length of the autheticator is longer than the length of the key, the key should be XOR'ed with the subsequent parts of the authenticator interatively with the last fraction of the authentictor padded with zeros as necessary. [is this totally bogus? need to get out a crypto book to do this right. mainly trying to capture the needs of the unkeyed digest to the HA /mat] To verify a cookie, the same process is undertaken and the contents of the checksum for that cookie are compared. If they are equal, the verify operation succeeds. In the special case of the Binding Update Query, the correspondent node computes the hash of the binding update and places it in the Binding Update Query message. The Home Agent removes the checksum, performs the key XOR as above, and completes the verification against the cookie's checksum. 5.1 Public Key Encryption [describe how the symmetric key is encrypted using the public key supplied in the BUQ] [In general, we may just want to use DH here to generate a shared secret between the HA and CN instead of doing public key encryption. Honestly, it's whichever is cheapest since there isn't any 3rd party Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 17] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 authentication between HA and CN. There are legitimate questions of DoS attacks against HA's. Since we aren't requiring the HA to sign anything, it's not quite as bad as standard PK make-work DoS attacks since public key encryptions aren't as expensive signatures/decryptions. Also, we have the fact that the cookie must be verified successfully, and since this uses relatively cheap sym- metric key crypto, it would seemingly only open a DoS opportunity during the replay window which doesn't seem very credible.] 5.2 Crypto Conformance To insure interoperability, the following crypto algorithms MUST be supported: All: [MD5], [SHA-1] The following SHOULD be supported by the correspondent node and Home Agent: HA, CN: [RSA-1024] [should we specify ECC as a SHOULD too? it's a lot cheaper /mat] 5.3 Replay Attacks There are several notable replay attacks present in this memo. We will first describe the attacks, describe the method to detect replays, and then describe the method to counter the attacks. The first attack is between the mobile node and the correspondent node. If an attacker captures a Binding Update, it may at a later time replay the legitimate Binding Update causing the correspondent node to erroneously use a stale care of address. The next attack is a potential make-work attack against the home agent. If a legitimate Binding Update Query message is replayed -- especially if the correspondent node has requested a key to be gen- erated -- the home agent may perform unnecessary public key opera- tions. The last attack is against the correspondent node. If an attacker replays a binding update query response, it may needlessly perform expensive public key decryptions. 5.3.1 Home Agent to Correspondent Node Attack Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 18] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 This attack is easy to counter. The correspondent node places a unique XID in the Binding Update Query message and only accepts Bind- ing Update Query Responses for XID's for which it has not received a reply. 5.3.2 Cookie Replay Detection Each cookie contains a sequence number. The mobile node generates an initial sequence number of its choice for each new key it generates. The destination (either Home Agent of Correspondent Node) MUST accept the initial sequence number when it see a new key, and it MUST store the current sequence number. The mobile node MUST insure that subse- quent cookies generated are monotonically incrementing and MUST NOT wrap around. The receiver MUST first check the validity of the cookie and them MUST check its current sequence number. It MUST NOT accept packets which are less than or equal to the current sequence number. If a sequence number jumps forward non-monotonically but is otherwise valid, the receiver MUST adjust its sequence number as well and reject any stale packets. 5.3.3 Correspondent Node to Home Agent Attack If the Home Agent detects a replay, it may in fact just be a retransmission of a binding update query. Since the Correspondent Node cannot recreate the cookie itself, the Home Agent SHOULD keep a replay cache of Binding Update Query Responses to accommodate normal retransmissions. The Home Agent prunes its replay cache by both a timer based method, as well as deleting cached responses for which a newer message sequence number has been detected. 5.3.4 Mobile Node to Correspondent Node Attack For this type of replay, the Correspondent Node upon detection of a replay MUST ignore the binding update as it is likely an attack. The Mobile Node MUST NOT send cookies with the same sequence number. 6. Message Formats 6.1 Cookies 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | SessionID | Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 19] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 | | +-------------------------------+-------------------------------+ | | | | | CoorID | | | +-------------------------------+-------------------------------+ | Sequence | +---------------+---------------+-+-+-----------+---------------+ | CksumLen | CkAlgorithm |H|A| Resv | +---------------+---------------+-+-+-----------+---------------+ | | ~ Cksum ~ | | +-------------------------------+-------------------------------+ Figure 1: Cookie Format SessionID The Session ID is genererated as in section 4.1 CorrID The CorresponentID as genererated as in section 4.1 and is used by the correspondent node to select the proper key if it previously requested a key in a binding update query. To select the proper key, the correspondent node MUST select the key based on both the SessionID and the CorrID. Sequence A monotonically incrementing number whose initial sequence is set by the mobile node. See section 5.3 CksumLen The length of the authenticator CkAlgorithmThe hashing algorithm used to compute the checksum as speci- fied by [AH? IKE?]. H H is the Home Agent flag. If the cookie is destined for the Home Agent, this flag is set, otherwise it is zero. A A is the Home Agent Anycast flag. When this flag is set, the correspondent node MUST send the binding update query to the home agent anycast address instead of directly to the mobile node. Resv Reserved for future use. Cksum The checksum over the entire binding update. Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 20] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 6.2 Cookie Suboption The Cookie Suboption is used for both binding updates as well as binding update acknowledgments when a home agent wants to send the mobile node a cookie. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | length | +---------------+---------------+---------------+---------------+ | | ~ Cookie ~ | | +-------------------------------+-------------------------------+ Figure 2: Binding Update Cookie Suboption Cookie The cookie destined for the home agent that the correspondent node received from the mobile node 6.3 Binding Update Query The binding update query is in the home agent discovery ICMP message as described in [MOBILEIPV6] with the addition of the cookies, etc for the query. When used as a discovery message and cookies are not present, the cookie, checksum and public key lengths must be set to zero. [mat: I've extended Identifier to 32 bits here? is that bogus in ICMP? It would be better to have more to make guessing attacks harder] 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved + | | Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 21] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +---------------+---------------+---------------+---------------+ | CookieLen | CkSumLen | PKAlgorithm | PKlen | +---------------+---------------+---------------+---------------+ | | ~ Cookie ~ | | +-------------------------------+-------------------------------+ | | ~ CkSum ~ | | +-------------------------------+-------------------------------+ | | ~ PublicKey ~ | | +-------------------------------+-------------------------------+ Figure 3: Binding Update Query Type Code 0 Checksum The ICMP checksum [5]. IdentifierAn identifier to aid in matching Binding Update Query Reply messages to this Binding Update Query message. Resv Reserved bits CookieLen The length in octets of the cookie. CkSumLen The length in octets of the checksum. PKAlgorithmThe Public Key encryption algorithm used. [reference ISAKMP/IKE IANA numbers /mat] PKlen The length in octets of the public key. Cookie The cookie destined for the home agent that the correspondent Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 22] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 node received from the mobile node CkSum The checksum is generated by the correspondent node by running the hashing algorithm specified in the cookie. This is not a keyed hash. The home agent verifies this hash against the checksum in the cookie as described in section 5. [this is in lieu of sending the whole BU /mat] PublicKey The public key that the correspondent node desires to have the key encrypted with. 6.4 Binding Update Query 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddressLen | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . Home Agent Addresses . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ResponseCode | EAlgorithm | Elen | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Key ~ | | +-------------------------------+-------------------------------+ Figure 4: Binding Update Query Response Type Code 0 Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 23] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 Checksum The ICMP checksum [5]. IdentifierAn identifier to aid in matching Binding Update Query Reply messages to this Binding Update Query message. Resv Reserved bits AddressLenThe length in bytes of the home agent addresses that follow. Home A list of addresses of home agents on the home link for the mobile node. ResponseCode The response for the BindingUpdateQuery. Currently defined responses are: VALID: The cookie was valid INVALID: The cookie was invalid for some reason EXPIREDSID: The session id has expired [what does the CN do??? /mat] EAlgorithmThe public key encryption algorithm used as defined in [IKE] for the keying material supplied. Elen The length in octets of the encrypted key. EncryptedKey The symmetric key that the correspondent node should use to authenticate subsequent binding update messages with correspondent node cookies in them. 7. Processing Considerations To minimize work, the following section describes some of the con- siderations that should be taken into account when implementing this memo. 8. Security Considerations This entire memo is aimed at fulfilling the security considerations of [MOBILEIPV6]. There are a few other considerations which bear Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 24] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 mentioning. Because of the desire to traverse NAT's, strong one-way hashes are performed to create identifiers which are used instead of directly using IP addresses. While these identifiers ought to be unique in practice, it is remotely possible that the same identifier created by one mobile node is collides with another mobile node on the same correspondent node. We note that the same considerations apply to [PBK]. The net result of such a collision is that a verify operation -- either locally at the correspondent node, or at the home agent will fail for the new mobile node requesting a binding cache update. This will only result in the second mobile node not being able to create a binding cache entry which will result in triangular routing for the losing mobile node. Given the remoteness of the pos- sibility, this does not seem to be a large problem. References [MOBILEIPV6] Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-03.txt [IPSEC] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- ture for the Internet Protocol", RFC 2401, November 1998 [IKE]The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998 [PBK]Mobile IP Working Group, Bradner, Mankin, Schiller, "A Frameworks for Purpose Built Keys (PBK)" draft-bradner-pbk-frame-00.txt Author's Address Michael Thomas Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA Tel: +1 408-525-5386 email: mat@cisco.com Dave Oran Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA email: oran@cisco.com Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 25] INTERNET-DRAFT Home Agent Cookies for Binding Updates 12 July 2001 Thomas draft-thomas-mobileip-ha-cookies-00.txt [Page 26]