INTERNET-DRAFT Binding Update Security Michael Thomas Cisco Systems 2 Nov 2001 Binding Updates Security draft-thomas-mobileip-bu-sec-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 provides a mechanism for mobile IPv6 nodes to use standard [IPSEC] mechanisms (both [AH] and [ESP]) to authenticate and authorize mobile IP route optmization messages which provide strong crypotographic authentication as well as protection from man in the middle attacks. This protection can be used both between home agents, and correspondent nodes. Given the lack of a universal authentication and authorization infrastructure, this memo also provides a weaker alternative to strong cryptographic based authentication. This mechanism trades off protection from some attacks, such as the man in the middle attack, on the observation that the routing system inherently provides a man in the middle opportunity. Thus it it is acceptible to provide routing optimization mechanisms so long as they Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 1] INTERNET-DRAFT Binding Update Security November 2001 are no less secure than the underlying infrastructure. This memo uses a simple return routability test to provide that weak mechanism. 1. Introduction Previous drafts of [MOBILEIPV6] recommended use of [IPSEC] and [AH] to secure binding updates, both to the mobile node's home agent as well as to correspondent nodes. Two major problems were found with this recommendation: o An assumption was made that the authentication domain for bind- ing updates would be the same as the underlying packet's authen- tication domain. This is not necessarily the case, and the current [IPSEC] selector mechanisms do not provide sufficient flexibility to support two different authentication domains within a single packet. o An assumption was made that IPsec security association would scale not only to the domain of home agent/mobile nodes, but to the any-to-any nature of mobile node/correspondent node communi- cation. This presupposes that there is a global PKI, and more specifically a global PKI which authenticates and authorizes nodes to change their global routability. These assumptions are infeasible and unattractive respectively. Thus mobile IP requires both a strong authentication and author- ization mechanism where it is appropriate, and a weaker variety where it is not. This memo provides those two mechanisms in two ways: o Strong authentication is provided by using IPsec, but by modify- ing [MOBILEIPV6]'s mechanisms to fit within the selector mechan- isms defined in [IPSEC]. This memo also provides a means of using both transport [AH] as well as [ESP]. o Weaker authentication is provided using a basic return routabil- ity test. That is, if a node can respond to a challenge at the home address it claims to be at, it is either very likely to be the node in question, or another node which could have attacked it by virtue of the fact that strong authentication wasn't used to eliminate man in the middle attacks. Both of these methods provide a means for the nodes receiving binding updates and home address options to determine whether they should accept the new binding or substitute the home Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 2] INTERNET-DRAFT Binding Update Security November 2001 address for the source address in the IP header. If neither of these methods are available, the node MUST NOT accept the new binding, or purported home address. 2. Use of IPsec for Strong Authentiction and Authorization The selector mechanism of [IPSEC] is not prepared to deal with dif- ferent security policies within a single IP packet. Therefore, the current mechanism of piggybacking binding messages is incompatible with [IPSEC]. This memo deprecates that mechanism and instead uses a separate UDP based protocol on well known port [XXX -- get from IANA]. Thus, standard IPsec ID selctors may be used to select dif- ferent traffic flows or aggregate them together depending on a site's particular security policy as with standard [IPSEC]. In addition, this memo relaxes the restriction of [AH] only by expli- citly including the home address into the binding update message. This allows [ESP] to also be used which is advantageous in situations where there is a common security policy for binding updates and other traffic between the nodes, but privacy is also desired. See section 5 for the new binding update format. 2.1. IPsec Applicability It is expected that keying within the limited scope of mobile nodes and nodes acting as home agents is feasible with standard key distri- bution mechanism such as [IKE], [KINK] and even pre-shared keys. Thus IPsec MUST be used between mobile nodes and any node acting as a home agent on the mobile node's behalf. The ability to use IPSEC between mobile nodes and correspondent nodes MUST be implemented by the mobile node, and SHOULD be implemented by correspondent nodes. 3. Weak Authentication and Authorization Given the tradeoff of PKI scalability vs man in the middle attacks, it was deemed that authentication and authorization of route optimi- zation which is no worse than the inherent in the current Internet was acceptible so long as the threats are not appreciably worse than current Internet nodes which do not use strong authentication. The current Internet relies on transitive trust in the routing system and explicitly discounts the man in the middle attack against the routing system. As such, it is take as a given that if a packet is destined toward a given location on the net, the routing system -- Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 3] INTERNET-DRAFT Binding Update Security November 2001 modulo configuration errors and other failures -- will make a best effort to forward the packet to its destination given the current topology of the net. Mobile IP can take advantage of that fact to enforce the property that if a datagram from an unknown node desiring route optmization can demonstrate that it exists at the topologically correct address (as determined by the current state of the routing system), there is reasonable assurance that it is, in fact, the rightful owner of that IP address at that point in time. The astute reader will no doubt point out that attacks can come from not only middle of the network, but also at the edges as well. This is true, however, the question is whether those attacks are unique to mobility, or whether they exist in non-mobile environments as well. As far as can be determined, they are not; things like ARP hijacking, etc are still avenues of attack, and shared media present many, many more opportunities than just hijacking of route optimization messages. Thus we can relegate these attacks to the general list of protocols and best common practices required when deploying a given access media. 3.1. Return Routability Test Thus the primary threat of route optimization hijacking can be miti- gated by a simple return routability test. The return routability test at its heart is a challenge by the correspondent node to the mobile node to echo a large, hard to guess number. This memo recom- mends a 32 bit number which is in line with [TCP] and its initial segment sequence for ACK and SEQ which is also protected weakly using this mechanism. Thus, the test is performed as follows: Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 4] INTERNET-DRAFT Binding Update Security November 2001 MN HA CN 1) BU+Nm------------------------------------> The mobile node sends a binding update. Nonce Nc MUST be set to zero. 2) <----------------------<----------BR+Nc+Nm Since Nc is set to zero, the correspondent node challenges it with a nonce, Nc; note that the challenge MUST be sent to the home address of the mobile node. 3) BU+Nc+Nm---------------------------------> The mobile node creates a new binding update with the nonce Nc in it; the CN can now process the binding update upon verification of nonce Nc. [ 4) <---------------------------------BA+Nc+Nm ] [ ] [ The correspondent node sends a binding acknowledgement ] [ to the mobile node with its nonce Nm repeated. ] Operation for a correspondent node initated binding request follows similar rules, except that the mobile node MUST process a binding request with a zero Nc. 3.2. Stateless Operation As with [TCP], there is a potential denial of service attack if a malicious node floods the correspondent node with forged binding updates, the correspondent node may consume resources, potentially exhausting state or resulting in the eviction of legitimate binding cache entries. In addition to the need of a nonce for binding updates, mobile nodes may want the correspondent node to send a bind- ing acknowledgment. To verify incoming binding acknowledgments, the mobile node must also supply a nonce. To prevent these attacks, a slightly modified version of [SYN- COOKIES] is used. In fact this text is a slightly modified and refor- mated version of [SYN-COOKIES]. The implementation MUST maintain two (constant) secret keys, sec1 and sec2 which are generated at boot time and not divulged. It also MUST Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 5] INTERNET-DRAFT Binding Update Security November 2001 maintain a counter that increases slowly over time and never repeats, such as ``number of seconds since 1970, shifted right 6 bits.'' It MUST also keep track of when the last time it generated a binding message. To create a MN-SEQ or CN-SEQ, it obtains its source address and source port, and the destination address and port, and zero's its (MN|CN)-SEQ and computes the following: z = MD5(sec1|saddr|sport|haddr|daddr|dport|sec1) + (MN-SEQ|CN-SEQ) + (counter << 27) + (MD5(sec2|counter|saddr|sport|haddr|daddr|dport|sec2) % (1 << 27)) and sets ``last overflow time'' to the current time. To process an incoming sequence number the node MUST: 1) If the ``last overflow time'' is earlier than a few minutes ago, drop the packet. 2) The node MUST then recompute z as above, for each of the counters that could have been used in the last few minutes (say, the last four counters), and then compare the results to the the sequence number in the packet. If there is a match, the binding message can be accepted as legitimate. If none of match, the node MUST drop the packet. 4. Selecting Weak/Strong Authentication A mobile node MUST be prepared to accept either strong or weak authentication from a correspondent node. It MUST NOT accept binding operations with weak authentication requests from a home agent, and SHOULD silent discard the request. Even when a security association between the mobile node and correspondent node exists, the mobile node MUST prepare the weak authentication fields as well. Correspon- dent nodes SHOULD accept binding updates if the exchange was pro- tected by IPsec with either an explicit policy selector, or a wild- carded policy selector. This behavior MAY be overridden by by policy of the correspondent node, in which case the weak authentication test will also take place. Even if a mobile node can authenticate to an IPsec peer, IPsec policy may not be sufficiently fine to authorize the rebinding of home addresses claimed by the mobile node. This is not a problem for home agents which actually subtends the home prefix, but correspondent nodes and possibly remote foreign agents such as [HMIP], may not have Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 6] INTERNET-DRAFT Binding Update Security November 2001 the same implicit knowledge of any relationship between the presented credentials and the home address that the mobile node is trying to rebind. While this information may be available due to configured policy, or authorization attributes in the credentials exchanged in the key distribution protocol, correspondent nodes or nodes acting as a home agent MUST NOT accept bindings based solely on the existence of an IPsec security association. Thus, the security policy executed during the establishment of the security MUST explicitly have author- ization for the Home Address that the mobile node is trying to rebind. If explicit authorization is not available, correspondent nodes MUST perform the weak test, albeit protected by IPsec, to determine whether the node is authorized to change the binding for a given binding unless the credentials or pre-configuration explicitly authorize a node to change the binding of a given home address. Also: nodes acting as home agents MUST reject any binding updates for which they cannot positively correlate the home address being rebound and the security policy which instantiated the security association. 5. Message Formats The following are the new definitions of the binding messages. Note: unless otherwise noted out, the fields with the same name in [MOBILEIPV6] have identical functionality. Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 7] INTERNET-DRAFT Binding Update Security November 2001 5.1. Binding Update Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |A|H|R|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Options Home-Address The home address of the mobile node. MN-SEQ The hashed sequence number which is generated by the mobile node. CN-SEQ The hashed sequence number which is generated by the correspondent node. Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 8] INTERNET-DRAFT Binding Update Security November 2001 5.2. Binding Acknowledgment Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- MN-SEQ The hashed sequence number which is generated by the mobile node. CN-SEQ The hashed sequence number which is generated by the correspondent node. Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 9] INTERNET-DRAFT Binding Update Security November 2001 5.3. Binding Request Message The Binding Request option is encoded in type-length-value (TLV) format as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CN-Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- MN-SEQ The hashed sequence number which is generated by the mobile node. CN-SEQ The hashed sequence number which is generated by the correspondent node. 6. Future Optimizations This memo purposefully omits any optimization of the weak keying mechanism's three way handshake. Several optimizations have been pro- posed, and this section details how this memo could interoperate with future standards which wanted to allow for optimization. 6.1. Two Message Weak Exchanges This memo recommends two mechanisms for authenticating and authoriz- ing binding updates: strong authentication using IPsec, and a weaker version relying on return routability. Depending on emperical evi- dence, it may be desirable to optimize the three way handshake on subsequent binding updates. This could be achieved in at least two ways: 1) Use public key cryptography to create a shared secret between Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 10] INTERNET-DRAFT Binding Update Security November 2001 the mobile and correspondent nodes, and sign each subsequent binding message with that symmetric key. Addition of this feature could be accomplished by adding a new sub-option(s) to carry the Diffie Hellman exchange, as well as the signature of the binding mechanism. 2) Create and maintain state after the initial handshake by using a TCP-like scheme with the sequence numbers in this draft. The current mechanism could be extended to use the initial exchange in an analogous way as TCP's ISS, and subsequent exchanges could monitonically increment the sequence numbers. Both have their plusses and minuses: (1) is somewhat safer, but is prone to attacks and adds a fair amount of CPU complexity. (2) is more straightforward and certainly well known given TCP, but doesn't provide the security property that [PBK] proposes. 6.2. Proxying [COOKIES] proposes leveraging the necessary home agent security asso- ciation to allow the home agent to act as a proxy for the mobile node. This memo doesn't appear to prevent that possibility as use of anycast addressing would still be possible. 6.3. Mobile Prefix Route Optimization There is some interest in securing not only mobile hosts, but mobile routers. A likely avenue to secure the weak variety is to send the binding request to the anycast address of the router which summarizes the prefix for which the mobile node is trying to change the binding. This memo, again, does not preclude this. 7. Security Considerations This memo outlines many of the security considerations surrounding the appropriate authentication and authorization of binding updates. In particular this memo's use of weak authentication is subject to potential snooping and active man in the middle attacks due to its compromise of strong authentication for scalability. This memo also uses [SYN-COOKIES] in a nearly unchanged form. It should be discussed further whether the guessing space is, in fact, too small as [SYN- COOKIES] alludes to. Thus the suggestion of a 32 bit guessing space is intended to be an initial suggestion for the ultimate solution. Another area of concern is lousy random number generators. This prob- lem is obviously of concern for many other things including TCP's ISS creation, so is not unique to this memo. Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 11] INTERNET-DRAFT Binding Update Security November 2001 References [MOBILEIPV6] Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Sup- port in IPv6" draft-ietf-mobileip-ipv6-15.txt [IPSEC] The IPsec Working Group, S. Kent, R. Atkinson, "Security Archi- tecture 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 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [IPDOI] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998. [ESP]S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 [AH] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 [IPV6]S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998 [SYN-COOKIES] Bernstein, D.J., Schenk, E. "SYN Cookies", http://cr.yp.to/syncookies.html [HMIP]Mobile IP Working Group, H. Soliman, C. Castelluccia, K. El- Malki, L. Bellier, "Hierarchical MIPv6 mobility management (HMIPv6)", 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 Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 12] INTERNET-DRAFT Binding Update Security November 2001 Thomas draft-thomas-mobileip-bu-sec-00.txt [Page 13]