IETF Mobile IP Working Group M. Roe INTERNET DRAFT G. O'Shea T. Aura Microsoft J. Arkko Ericsson Expires: April 2002 November 2001 Authentication of Mobile IPv6 Binding Updates and Acknowledgments Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes three protocols that may be used for authenticating binding updates in mobile IPv6. These protocols have the following goals: · To prevent malicious nodes from forging binding updates for other nodes; Roe [Page 1] INTERNET DRAFT Authentication of Binding Updates November 2001 · To prevent old binding updates being replayed; · To protect correspondents against denial of service attacks in which they are flooded with a large number of invalid binding updates; · To protect other nodes on the Internet from denial of service attacks in which a correspondent is tricked into sending them a large amount of data that they do not want. The three protocols differ in the amount of computation that they require and the assumptions that they make about the environment in which they are used. The symmetric key method is efficient, but can only be used if the mobile and the correspondent have previously agreed a long-term secret. The BAKE/2 method is also efficient, but only works if some of the messages in the protocol take a route which is protected from attack by means outside the protocol. The CAM-DH protocol needs more processing power, because it involves asymmetric cryptography, but it can be used in situations where the other two protocols cannot. 1 Background to the Protocol Designs 1.1 IP Addresses derived from Cryptographic Keys In the CAM-DH protocol (which will be described later), a node uses a home address that is derived from the node's public key. The idea behind this is that if the address is the same as the public key, nodes can work out which key corresponds to an address without needing to use a secure key distribution mechanism such as X.509 certificates. Such key distribution mechanisms typically need to be configured manually, and this conflicts with the design goal of IPv6 that it should be possible to configure hosts automatically. However, it is not possible to set the IP address equal to the public key, because they will normally be of different length, and the network part of the address must be set to the right value for the packet to be routed correctly. Instead, we use a more complex relationship between the address and the key, in which the last 64 bits of the address (the "Interface ID") are defined as follows: InterfaceId = First64(SHA1(Route Prefix | M | RFU | Public Key)) & 0xfcffffffffffffff The field "RFU" is reserved for future use, and shall be set to zero. The field "M" is a modifier, which is used in the following way. A node generates a private/public key pair, and then attempts duplicate address detection for an address generated using the above equation Roe [Page 2] INTERNET DRAFT Authentication of Binding Updates November 2001 with M set to zero. It is very unlikely that a collision will occur except as a result of an attack on the protocol. However, if a collision is detected the host MAY attempt duplicate address detection again with a different address, generated using the same public key and with M equal to one. If necessary, this process may be be repeated with M equal to 2 and M equal to 3. Nodes MUST NOT use values of M greater than three. Four collisions in a row are very, very unlikely to occur by chance, and are almost certainly the result of either an attack on the protocol or an error in the implementation. Bit 6 of the host part of the address is the universal/local bit [RFC2373]. It is set to zero to indicate that the address generated is not guaranteed to be globally unique. This ensures that it will not collide with an IP address derived from an ethernet address. It is important to avoid such collisions, because hosts that use their MAC address to derive their IP address will not expect such collisions, and they might not have a means to recover from them when they occur. Bit 7 of the host part of the address is the individual/group bit [RFC2373]. It is set to zero to indicate that it is the address of an individual node, not a group of nodes. The route prefix is included in the input to the hash function to prevent an attack in which the attacker expends a very large initial set-up cost, but is then able to attack many different nodes at a relatively low cost per node. If the route prefix was not included, an attacker could, at great expense, compute a lookup table that contains a suitable key pair for each of the 2^62 possible values of the InterfaceId. Such a lookup table could then be used to masquerade as any mobile node. Including the route prefix makes this attack not economically viable (from the point of view of the attacker), because it means that such a look-up table can only be used to masquerade as nodes which have the same route prefix. Typically, there will not be enough nodes with the same route prefix to justify the expense of constructing the lookup table. 1.2 Resource Exhaustion and other Denial of Service Attacks When designing these protocols, we found it useful to distinguish between two different types of denial of service attack. Resource exhaustion attacks are attacks in which the victim has only a limited amount of some resource (such as network bandwidth or CPU cycles), and the attack consumes some of this resource, leaving the victim with not enough of it left to carry out the other work it needs to do. There are denial of service attacks that are not resource exhaustion attacks. For example, forged binding updates can lead to Roe [Page 3] INTERNET DRAFT Authentication of Binding Updates November 2001 denial of service, because packets will be sent to the wrong care-of address. This is not an example of resource exhaustion; a host with an unlimited supply of network bandwidth and CPU would still be vulnerable to denial of service attacks based on forged binding updates. This attack works by corrupting a host's state (its binding cache), not by running it out of resources. That is, a failure of integrity and authentication then leads to denial of service. The binding updates that are used in mobile IPv6 are only an optimisation. A mobile node can communicate with a correspondent node even if the correspondent refuses to accept any of its binding updates. However, performance will suffer because packets from the correspondent from the mobile will be routed via the mobile's home agent rather than a more direct route. A correspondent can protect itself against some of the resource exhaustion attacks by stopping processing biding updates when it is flooded with a large number of binding updates that fail the cryptographic integrity checks. If a correspondent finds that it is spending more resources on checking bogus binding updates than it is likely to save by accepting genuine binding updates, then it can decide to reject all binding updates without checking the cryptography. Nodes that are willing to expend significant resources responding to anyone, no matter who they are, will often be vulnerable to resource exhaustion attacks. The DoS protection mechanisms described in this memo will only be useful if each node has some means of deciding whether it should expend resources on behalf of a particular peer. This information needed to make this decision will usually originate in layers above IP. For example, TCP knows if the node has a queue of data that it is trying to send to a peer. It is possible to produce a conforming implementation of the protocols in this memo without making use of information from higher protocol layers, but implementations may be able to manage resources more effectively by making use of such information. In general, a node will be willing to devote resources to a run of an authentication protocol for one of two reasons. In the first case, the node itself is trying to carry out some work, and knows that completing the authentication protocol run is necessary (or helpful) in getting that work done. In the second case, the node's peer is trying to carry out some work for which the authentication protocol run is necessary or helpful. In this case, the node does not know directly that the protocol run is worthwhile, but may be prepared to expend resources on behalf of certain peers when they ask it to. There is a problem with this case that is specific to authentication protocols, and does not occur with other types of protocol. The node will only know that is is worthwhile expending resources on a protocol run when it knows that the run has been initiated by a peer Roe [Page 4] INTERNET DRAFT Authentication of Binding Updates November 2001 that is willing to devote resources to. However, it will only know this when the peer has been successfully authenticated, that is when protocol run has been completed and the resources have already been spent. One way in which this situation may be improved is to divide the authentication protocol in to two phases. The first phase is consumes very little resources, but does not provide a very high level of security. The second phase provides a higher level of security, but requires more resources to provide this level of security. The second phase is only started if the first phase completes sucessfully. In this way, only attackers who can break the security of the first phase can cause a resource exhaustion attack using the second phase. We have used this approach in the protocols described in this memo. 1.3 Piggybacking and Jitter The mobile IPv6 specification allows for "piggybacking". That is, control messages such as binding updates may be combined with other messages. Piggybacking will delay these other messages in two ways. Firstly, it will make them larger, and larger messages usually take longer to transmit. Secondly, it will increase the amount of processing that is needed to send and receive the messages because the mobility information in the message will need to be processed as well. When the control messages are authenticated with assymmetric cryptography, they will add a large amount of jitter, because digital signatures requires many bytes to represent and take many CPU cycles to compute or verify. Some applications, for example real-time voice, are very sensitive to jitter. Some networks have "quality of service" facilities whereby an application can reserve a particular amount of bandwidth. Piggybacking can interfere with these quality of service facilities, because when packets are made bigger by adding mobility headers they may exceed the size that has been reserved, and this may cause them to be discarded or severely delayed by the network. Accordingly, we recommend that piggybacking should not be used when quality of service facilities are in use (e.g. the IPv6 flow id is nonzero) and should not be used when assymetric cryptography is being used to protect the mobility control portion of the message. This recommendation has affected the design of the procotols described in this memo; digital signatures are carried in UDP messages, not IPv6 destination options. UDP messages cannot be piggybacked, but this is not a serious problem as we recommend that these messages should not be piggybacked. Roe [Page 5] INTERNET DRAFT Authentication of Binding Updates November 2001 1.4 Length of Suboptions The IPv6 option length limits the amount of data that may be passed in a destination option or as a suboption within a destination option. The maximum length of a suboption is 255 bytes, or 2040 bits excluding any other data in the protocol. Since both a public key and a Diffie-Hellman value needs to be passed in the CAM-DH protocol, passing these in a suboption would limit the key size to 1020 bits. These values are just about enough for current security needs, but seem low in view of future developments. They also preclude the use of the same long key for both MIPv6 and other purposes. Therefore, we have chosen to run the authentication protocol as an independent protocol on top of UDP. 2 Notation This memo uses the following notation: MN A mobile node CN A correspondent node A -> B A sends a message to B A -> B(HoA) A sends a message to B at its home address A -> B(CoA) A sends a message to B at its care-of address ADDRS A node's home address and care-of address MAC(m;K) A message authentication code computed on message m with key K H(m) A hash of message m 3 Abstract Protocols 3.1 Bake/2 Properties of the Protocol The "Bake/2" protocol establishes a session key that is then used to authenticate binding updates sent from a mobile node to a correspondent node. The session key established by the protocol is not intended to be used for confidentiality, and is not intended to be used for authentication of messages in the reverse direction (e.g. binding acknowledgements). In particular, the correspondent node is not authenticated to the mobile node, which would be necessary if either of these two services were desired. Roe [Page 6] INTERNET DRAFT Authentication of Binding Updates November 2001 This protocol is only suitable for use in an environment where communication from the correspondent through the home agent to the mobile, and between the home agent and the mobile node are protected from eavesdropping by means outside of the protocol. Examples of ways in which this protection could be provided include the use of IPSEC Encapsulating Security Payload, or a physically protected network. An example of a situation where it would be appropriate to use this protocol is when the home agent and the correspondent node are both on a physically protected corporate intranet, the mobile node is connected via a public wireless network, and the mobile node has an encrypted tunnel between itself and the home agent. This protocol may also provide a low level of protection when the correspondent node is (for example) a web server connected to the public Internet by a wired connection and the mobile node is connected via a wireless network. The protocol can be broken by an attacker on the route between the home and the correspondent node, but not by attackers on the wireless network or elsewhere on the Internet. Our motivation for designing this protocol was that we wanted to add support for mobile IP without creating major new security problems. We wanted a protocol that would protect against the new vulnerabilities that were introduced by IP mobility. It was not our goal to protect against attacks that were already possible before the introduction of IP mobility. This protocol does not defend against an attacker who can monitor the home agent to correspondent node route. Our justification for this is that if such an attacker exists, they are able to attack the system before IP mobility is enabled, because they can mount an active attack against the mobile node when it is at its home location. Prevention of such attacks is outside the scope of this protocol. The possibility of such attacks is not an impediment to the deployment of mobile IP, because these attacks are possible irrespective of whether mobile IP is in use or not. Some our earlier protocols for authenticating binding updates, such as CAM, ran the complete protocol for each binding update. The protocol described here establishes a session key which can then be used for many binding updates between the same nodes without running the whole protocol again. This can result in an efficiency saving, because binding updates are resent at regular intervals. This efficiency saving will usually be realised when a mobile node communicates with the same correspondent node for an extended period of time. If the mobile node communicates with a correspondent briefly and then never talks to it again, then the establishment of a session key does not result in efficiency savings. Roe [Page 7] INTERNET DRAFT Authentication of Binding Updates November 2001 This protocol protects the correspondent node against denial of service attacks in which the correspondent is flooded with many bogus messages. The correspondent does not have to store state or consume a large amount of processing time handling messages from a source which has not yet been authenticated. The protocol does not protect the mobile against these attacks. This means that this protocol is suitable for use when a client on a mobile node accesses a server on a non-mobile node, but may not be suitable for use when accessing a server on a mobile node. It is an assumption of the protocol that at the start of a run the mobile node already has stored state about the correspondent (perhaps at a level above IP, such as TCP or the application), and knows that it is worthwhile expending resources on the run. There is a clear need for a protocol for the opposite case, where the correspondent has pre-exisiting stored state about the correspondent and knows that it os worthwhile expending resources on the protocol run. This is a matter for further study. This protocol also protects against denial of service attacks in which the attacker pretends to be a mobile, but uses the victim's address as the care of address, and so causes the correspondent to send the victim traffic that it does not want. For example, suppose that the correspondent is a news site that will send a high-bandwidth stream of video to anyone who asks for it. Note that the use of flow- control protocols such as TCP does not necessarily defend against this type of attack, because the attacker can fake the acknowledgements. Even keeping TCP initial sequence numbers secret doesn't help, because the attacker can receive the first few segments (including the ISN) at its own address, and then redirect the stream to the victim's address. This protocol defends against these attacks by only completing if packets sent by the correspondent to the care of address are received and processed by an entity that is willing to participate in the protocol. Normally, this will be the mobile node. Walkthrough Each correspondent node has a secret key, KCN. This key does not need to be shared with any other entity, so no key distribution mechanism is needed for it. Each correspondent node also generates a nonce, Nj, at regular intervals, for example every few minutes. A correspondent node uses the same KCN and Nj with all the mobiles it is in communication with, so that it does not need to generate and store a new Nj when a new mobile contacts it. Changing the value of Nj protects the correspondent against the replay of old messages. Each value of Nj is identified by the subscript j. j is communicated in the protocol, so that if Nj is replaced by N(j+1) part way through a Roe [Page 8] INTERNET DRAFT Authentication of Binding Updates November 2001 run of a protocol, the correspondent can distinguish messages that should be checked against the old nonce from messages that should be checked against the new nonce. Correspondent nodes keep both the current value of Nj and the previous value N(j-1). Older values can be discarded, as messages using them will in any case be rejected as replays. KCN can be either a fixed value or regularly updated. An update of KCN can be done at the same time as an update of Nj, so that j identifies both the nonce and the key. A correspondent node can generate a fresh KCN each time that it boots to avoid the need for secure persistent storage for KCN. 1. MN -> CN : ADDRS In the first message, the mobile node contacts the correspondent node, giving both the mobile's home address and its care of address. 2. CN -> MN(HoA) : K0, j K0 = MAC(HoA | Nj | 0; KCN) The correspondent then generates two parts of a session key. One part of the session key is sent to the mobile node via its home agent; it is an assumption of the protocol that this route is secure. 3. CN -> MN(CoA) : K1, j K1 = MAC(CoA | Nj | 1; KCN) In parallel with step 2, the other half of the session key is sent directly to the mobile at its care of address. To obtain both halves of the key, the mobile needs to be able to receive messages that are sent via its home address, and able to receive messages sent to its care of address. 4. MN -> CN : ADDRS, 0, MAC(ADDRS, 0; K2), j K2 = H(K0 | K1) The mobile node hashes together the two halves of the key to form the session key, and then uses the session key to authenticate a binding update. Each binding update contains a sequence number, to prevent an attacker from replaying old binding updates. In the first binding update, the sequence number is zero. The first binding update contains j, so that the correspondent knows which value of Nj to use to recompute the session key. Once it has verified the MAC, the correspondent can create state for the mobile. The correspondent Roe [Page 9] INTERNET DRAFT Authentication of Binding Updates November 2001 should remember the session key K2 and the mobile's addresses. 5. MN -> CN : ADDRS, i, MAC(ADDRS, i; K2) In subsequent binding updates, the mobile node increments the sequence number by one each time. It is no longer necessary to include j, because the correspondent will have remembered the session key. Including j would not help because Nj is no longer fresh, and the correspondent node might have forgotten it. Optimisations The binding update only needs to include the bottom few bits if the sequence number, as long as the MAC is computed over the full sequence number. The network might discard or re-order messages even when it is not under attack, but messages will not encounter very long delays. On the other hand, a malicious attacker might replay a very old message. The bottom few bits are sufficient to detect non- malicious re-ordering hence to determine the full value of the sequence number to use in computing the MAC. The MAC must be computed over the full sequence number to prevent malicious replays. We explain this optimisation because in draft 14 of the mobile IP specification the sequence number field is only 8 bits wide. If this optimisation is used, the last message is replaced with the following: MN -> CN : ADDRS, i mod 256, MAC(ADDRS, i; K2) It is not necessary to encode all the bits of j in the protocol messages; just the least significant bit is sufficient for the correspondent to tell whether to use Nj or N(j-1). 3.2 CAM-DH The "CAM-DH" combines the Bake/2 protocol with a digitally signed Diffie-Hellman key exchange. In CAM-DH, each mobile node's home address is algorithmically related to its public signature key. The use of key-related addresses avoids the need for X.509 certificates or similar mechanisms that associate keys with addresses [OShea2001]. The mobile node uses its private signature key to sign a Diffie- Hellman exponent which is then used to negotiate a session key. The underlying Bake/2 protocol provides the correspondent node with protection against denial of service attacks - the correspondent will Roe [Page 10] INTERNET DRAFT Authentication of Binding Updates November 2001 not perform any asymmetric cryptographic operations until it knows it is talking to a mobile which has been authenticated with Bake/2 - while the signature mechanism provides a higher level of security than would be available with Bake/2 used on its own. This protocol could have been simplified by deriving mobile's home address from the Diffie-Hellman exponent, rather than deriving it from the public key that verifies the signature on the Diffie- Hellman exponent. However, the extra level of indirection allows the signature key to be used to sign messages that are used with other protocols. We anticipate that there will be other protocols that would like to use key-related addresses. Our approach allows a node to use several such protocols simultaneously. Each signed key is accompanied by a tag that indicates the protocol it is used for, to prevent attacks based on interactions between protocols. Walkthrough 1. MN -> CN : ADDRS In the first message, the mobile node contacts the correspondent node, giving the mobile's home and care-of addresses. 2. CN -> MN(HoA) : K0, j, g^y K0 = MAC(HoA, Nj, 0 ; KCN) In the second and third messages, the correspondent node sends the mobile node a key in two parts, one half being sent to the care-of address and the other being sent via the home agent. The correspondent also sends the mobile a Diffie-Hellman exponent. The correspondent can use the same exponent with all mobiles it is communicating with, so there is no need to generate a new exponent for each protocol run. Like KCN, y can be constant (eliminating the need for the correspondent node to perform a modular exponentiation) or periodically updated. If y is changed, the subscript j indicates which version of y to use (as well as which KCN and Nj). 3. CN -> MN(CoA) : K1, j K1 = MAC(CoA, Nj, 1; KCN) 4. MN -> CN : 0, ADDRS, MAC(0, ADDRS ; K3), g^x, Signature(TypeTag, g^x, HoA; PK), PK, MAC(... ; K2), j Roe [Page 11] INTERNET DRAFT Authentication of Binding Updates November 2001 K2 = h(K0, K1) K3 = h(K0, g^{xy}) When it has received the two halves of the key, the mobile hashes them together to form a key that will authenticate the fourth message. The mobile also uses Diffie-Hellman key agreement to calculate a session key that can be used to authenticate binding updates. The fourth message consists of a binding update, a message authentication code on the binding update computed using the session key, the mobile's public signature key, the mobile's Diffie-Hellman exponent signed with its private signature key, and a message authentication code on all of the aforementioned data, computed using the key that was sent in two pieces. When the correspondent receives the fourth message, it should check the outer MAC with K2 first. It should only attempt to compute K3 and verify the inner MAC with it if the outer MAC verifies correctly. This protects the correspondent against denial of service attacks in which it is flooded with many bogus fourth messages. If both MACs verify correctly, the correspondent should store state related to the mobile, including the session key K3. 5. MN -> CN : i, ADDRS, MAC(i, ADDRS ; K3) Subsequent binding updates only need to be protected with K3. They include a sequence number to protect against replay attacks. Optimizations All of the asymmetric cryptographic operations that the mobile carries out can be performed instead by the home agent, provided that the home agent is given access to the appropriate keys. An example of a situation where the optimisation might be useful is a low-power wireless mobile device that does not have enough computational power for asymmetric cryptography. If this optimisation is used, the home agent intercepts the second message (which is routed via the home agent) and performs certain processing on in before forwarding it on to the mobile node. That is, the second message is replaced with the following: CN -> HA : K0, j, g^y HA -> MN : K0, K3, j Roe [Page 12] INTERNET DRAFT Authentication of Binding Updates November 2001 In the case when the correspondent node is also a mobile node, all of the asymmetric cryptographic operations that the correspondent performs can instead be performed by the correspondent's home agent. To enable this optimisation, the second message of the protocol should contain an additional flag that indicates to the mobile node that the correspondent is using this optimisation. When this flag is present in the second message, the mobile should send the third message to the correspondent's home address, rather than its care-of address. That is, the mobile should disable route optimisation when sending the third message. 3.3 Shared Key Properties of the Protocol The shared key protocol is used to authenticate binding updates between a mobile node and a correspondent node that already share a symmetric key. For example, a mobile node might use this protocol to send binding updates to its home agent. This protocol protects binding updates against replays by using the long-term shared key and a random challenge to derive a fresh session key. This protocol also checks that messages sent to the care of address reach an entity that is willing to participate in the protocol; this helps prevent denial of service attacks in which a mobile sets their care of address to the victim's address and then causes them to be flooded with data sent by a third party. Walkthrough 1. MN -> CN : ADDRS 2. CN -> MN(CoA) : K1, j K1 = MAC(CoA | Nj | 1 ; KCN) 3. MN -> CN : ADDRS, 0, MAC(ADDRS, 0 ; K2), j K2 = H(K0, K1) 4. MN -> CN : ADDRS, i, MAC(ADDRS, i ; K2) Roe [Page 13] INTERNET DRAFT Authentication of Binding Updates November 2001 The variables KCN and j are the same as in the BAKE/2 protocol. K0 is the secret shared between the mobile node and the correspondent node. 4 New IPv6 Sub-option Types This memo defines the following IPv6 destination option sub-option types: 4.1 Challenge Serial Number Alignment requirement: none 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | Length | Nonce Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The challenge serial number sub-option is valid in a Binding Update destination option. The Nonce Identifier field contains the variable j in the BAKE/2 and CAM-DH protocols. That is, it tells the correspondent node that receives the suboption which of the challenge values (Nj) are to be used to authenticate the binding update. 4.2 Home Address Key Component Alignment requirement: none 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce Identifier | Algorithm Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Component (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Home Address Key Component sub-option is valid in a Binding Request destination sub-option. The The Nonce Identifier field contains the variable j in the BAKE/2 and CAM-DH protocols. The Algorithm Identifier field indicates which cryptographic algorithm Roe [Page 14] INTERNET DRAFT Authentication of Binding Updates November 2001 should be used to compute the authentication information field in the Binding Update that is sent in response to this option. The Key Component field contains the key component K0 in the BAKE/2 and CAM- DH protocols; it is the first of two components which are to be concatenated and hashed to form a key which is then used to authenticate binding updates. 4.3 Care-of Address Key Component Alignment requirement: none 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce Identifier | Algorithm Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Component (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Care-of Address Key Component sub-option is valid in a Binding Request destination sub-option. The The Nonce Identifier field contains the variable j in the BAKE/2 and CAM-DH protocols. The Algorithm Identifier field indicates which cryptographic algorithm should be used to compute the authentication information field in the Binding Update that is sent in response to this option. The Key Component field contains the key component K1 in the BAKE/2 and CAM- DH protocols; it is the second of two components which are to be concatenated and hashed to form a key which is then used to authenticate binding updates. 4.4 Address-related RSA Public Key Sub-option Alignment requirement: none 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBA | Length | M | RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Roe [Page 15] INTERNET DRAFT Authentication of Binding Updates November 2001 The Address-related RSA Public Key sub-option is valid only in Home Address destination options. The Public Key field contains an RSA public key, encoded as the ASN.1 Basic Encoding Rules [ISO8825] representation of the type PublicKey. PublicKey ::= SEQUENCE { modulus INTEGER, exponent INTEGER } The RFU (reserved for future use) field SHALL contain zero bits. Packets in which these bits are non-zero MUST be rejected as invalid. (See the security considerations section of this memo for the rationale for this) The following relationship SHALL hold between the public key field and the network part of the home address, where SHA1 is the SHA-1 message digest algorithm [SHA1] and First64 extracts the first 64 bits of the 160 bit hash value. InterfaceId = First64(SHA1(Route Prefix | M | RFU | Public Key)) & 0xfcffffffffffffff Packets where this relationship does not hold MUST be rejected as invalid. 5 Other Message Formats NB: This protocol specification is currently incomplete, as it does not fully described how the abstarct protocols of section 4 are encoded, This information will be provided in the next version of the document. 6 Intellectual Property Rights Notice The CAM-DH variant of our protocols uses public keys and hashes to prove address ownership [Nikander2001,OShea2001]. In case there would be any Ericsson IPR on such methods, the Ericsson policy on IPR issues can be checked from the Ericsson General IPR statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General. Roe [Page 16] INTERNET DRAFT Authentication of Binding Updates November 2001 7 Security Considerations 7.1 Risks of unauthenticated binding updates If a node accepts binding updates without authentication, then it is vulnerable to several attacks in which an attacker sends forged binding updates for other nodes. These include a denial of service attack in which the attacker sends the victim a forged binding update for a service that the victim relies on (e.g. the domain name service), and sets this service's care of address to a non-existent address. The victim will be unable to contact the service at the falsified care of address, and henceforth will be unable to make use of the service. A variation on this attack with consequences beyond denial of service is when the attacker sets the service's care of address to the attackers own address, and the attacker then provides a maliciously modified version of the service. For this reason, it is recommended that nodes on the Internet SHOULD use some form of authentication for binding updates. Nodes on private intranets that use other means to exclude potential attackers MAY accept binding updates without authentication. 7.2 Risks of unauthenticated binding acknowledgements The consequences of forged binding acknowledgements are, in general, less serious that those of forged binding updates. The usual consequence of forging a binding acknowledgement is that the victim's correspondent will fail to obtain an up-to-date binding for the victim, the correspondent's previous binding for the victim will expire, and the correspond will revert to sending packets via the victim's home agent. Communications between the victim and its correspondent will still work, but may suffer degraded performance. In some circumstances this degradation of performance will be sufficiently severe to constitute a denial of service attack. Forged binding acknowledgements that appear to come from the victim's home agent have more serious consequences than forged acknowledgements that appear to come from other correspondent nodes. If a mobile node is away from home, and its home agent does not have a valid binding for it, then the mobile node will become uncontactable. As a result, it is possible to carry out a denial of service attack on a mobile node by blocking the binding updates it Roe [Page 17] INTERNET DRAFT Authentication of Binding Updates November 2001 sends to its home agent and forging the acknowledgements. Even if the attacker cannot prevent packets getting through, they may still be able to use forged acknowledgements to cause denial of service some of the time; if a binding update is lost for normal reasons (not as a result of the attack), then the forged acknowledgements will prevent it from being retransmitted. This attack might also make it possible to intercept packets destined for a mobile node. Suppose that a particular network does not allow two nodes to have the same address at the same time, but will allow one node to take over another's address when the original user of the address has left the network. (This assumption does not hold with many network technologies). Then the attacker waits for a mobile node to leave the network, takes over its old care-of address, and uses forged binding acknowledgements and/or blocks the binding updates so that the mobile's home agent never learns that mobile's care-of address has changed. Packets sent to the mobile's home address will continue to be forwarded to the old care-of address, which is now under the control of the attacker. One possible security policy that takes into account these considerations is to require authenticated binding updates from a home agent, but to accept unauthenticated binding updates from other correspondents. 7.3 Risks of not verifying the care-of address The BAKE/2 and CAM-DH protocols described in this memo verify that that packets sent to a mobile node's claimed care-of address reach an entity that is willing to participate in the protocol. If this check was not performed, a malicious mobile node could perform a denial of service attack by asking a correspondent node to send it a high volume stream of data, and then sending the correspondent a binding update that redirects the stream of data to the victim of the denial of service attack. The acknowledgements and initial sequence number of TCP do not protect against this attack. A malicious mobile node can send the acknowledgements for the stream of data even if it is not actually receiving it. Unpredictable initial sequence numbers do not prevent a malicious mobile forging acknowledgements because the mobile sees the beginning of the stream of data (including the initial sequence number) before it redirects it to the victim. The BAKE/2 and CAM-DH do not authenticate the care-of address. An attacker who can intercept packets sent to the care-of address can complete the protocol and cause the care-of address to be flooded with data, even if the host that actually owns the care-of address is not willing to participate in the protocol. Roe [Page 18] INTERNET DRAFT Authentication of Binding Updates November 2001 An alternative method of authenticating the care-of address would have been to derive the care-of address (as well as the home address) from the node's public key. We did not adopt this approach, because some subnetworks may impose constraints on the care-of addresses that can be used. 7.4 Risks of Not Authenticating Home Agents If a mobile node is willing to allow anyone to act as its home agent (for example. suppose that it uses multicast to locate a suitable home agent) then it is vulnerable to a number of attacks in which the attacker pretends to be a home agent. For example, by acting as a node's home agent the attack can intercept packets sent to the node (a threat to confidentiality), and can cause denial of service. We observe that if an attacker is in a position to carry out these attacks, then it is also in a position to carry out other attacks of equal or greater seriousness, for example pretending to be a router. In environments where this is a concern, the mobile should authenticate its home agent (and the next hop router, and many other services it relies on). In this case, it is not sufficient to check that the home agent's address is statistically unique; it is also necessary to check that the address corresponds to a "good" home agent, that is one that will behave in a particular way. This means that the technique of deriving addresses from public keys is not sufficient for authenticating the home agent to the mobile, because it only guarantees that the address is almost certainly not being used by anyone else. An IPSEC security association established using certificate-based key management may not be sufficient either; it is not enough to know that some authority has associated a particular key with a particular IP address, as this on its own does not provide assurance that the node at that address is a good home agent. 7.5 Denial of Service Attacks against Home Agents Home agents are vulnerable to denial of service attacks carried out by mobile nodes for which they are the home agent. For example, a malicious mobile node that has two different home addresses from two different home agents can create a routing loop by sending the first home agent a binding update with the mobile's second home address as a care-of address, and sending the second home agent a binding update with the mobile's first home address as a care-of address. Packets caught in this routing loop will eventually time out, but there is consideration degree of traffic amplification: for each packet that the attacker sends into the routing loop, the home agents will have Roe [Page 19] INTERNET DRAFT Authentication of Binding Updates November 2001 to send and receive many packets. Home agents can defend against these attacks in several ways. A home agent that will only act as home agent for mobile nodes that it knows to be trustworthy will not be vulnerable to these attacks. References [ISO8825] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). ISO 8825, International Organization for Standardization, 1987. [SHA1] Secure Hash Standard. FIPS PUB 180-1, NIST, April 1995 [RFC2373] R. Hinden and S. Deering, IP Version 6 Addressing Architecture. RFC 2372, July 1998. [Nikander2001] P. Nikander, A Scaleable Architecture for IPv6 Address Ownership. Internet Draft, March 2001. [OShea2001] Greg O'Shea and Michael Roe, Child-proof authentication for MIPv6 (CAM). Computer Communications Review, April 2001. 8 Author's Addresses Michael Roe Microsoft Research Limited 7 J J Thomson Avenue Cambridge CB3 0FB UK Email: mroe@microsoft.com Tuomas Aura Microsoft Research Limited 7 J J Thomson Avenue Cambridge CB3 0FB UK Email: tuomaura@microsoft.com Greg O'Shea Microsoft Research Limited 7 J J Thomson Avenue Cambridge CB3 0FB UK Email: gregos@microsoft.com Roe [Page 20] INTERNET DRAFT Authentication of Binding Updates November 2001 Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 EMail: jari.arkko@ericsson.com Roe [Page 21]