IETF Mobile IP Working Group M. Roe INTERNET DRAFT Microsoft Expires: December 2001 August 2001 Authentication of Mobile IPv6 Binding Updates and Acknowledgments <draft-roe-mobileip-updateauth-00.txt> 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 1 Introduction This memo describes four different protocols that MAY be used for authenticating Binding Update or Binding Acknowledgment destination options [5]. Each protocol provides a different level of security, ranging from no authentication to a challenge-response mechanism using digital signatures. These mechanisms include a negotiation facility that enables nodes to determine which of these mechanisms are acceptable to their peers. Nodes MAY choose a different level of security for Binding Acknowledgments than for Binding Updates. For example, a host MAY accept Binding Acknowledgments with no authentication while requiring the signed challenge-response mechanism for Binding Updates. Nodes MAY vary the level of security that they require dynamically. For example, a node that normally accepts the signature-only mechanism MAY require use of the signed- challenge response mechanism when it has detected that it is being Roe [Page 1]
INTERNET DRAFT Authentication of Binding Updates July 2001 subjected to a denial of service attack. 2 IP Addresses derived from Cryptographic Keys In some of the mechanisms described in this memo, 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 mechanism typically needs 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(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, who use is as follows. A node generates a private/public key pair, and then attempts duplicate address detection for an address generated using the above equation 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 [4]. It is set to zero to indicate that it is not guaranteed to be globally unique. Bit 7 of the host part of the address is the individual/group bit [4]. It is set to zero to indicate that it is the address of an individual node, not a group of nodes. 3 Abstract Protocols This section provides a high-level description of the four authentication protocols. Each of these protocols MAY be used for Roe [Page 2]
INTERNET DRAFT Authentication of Binding Updates July 2001 authenticating Binding Updates or Binding Acknowledgments, although the details of the packet formats are different in these two cases. 3.1 No authentication A -> B : message In this mechanism, messages are sent without authentication. 3.2 Challenge-Response Mechanism B -> A : RA A -> B : RA, message In the challenge-response mechanism, the verifier (B) will only accept messages if they contain a challenge which the verifier has sent to the claimant (A) in a previous message. The challenges should be generated in way that makes them unpredictable, so that an attacker cannot guess the right response to send. This mechanism does not protect against attackers who can monitor messages sent to other parties. It protects against attackers who can forge their source address but are unable to intercept messages. 3.3 Signature Mechanism -1 A -> B : KA, M, { message, HA(A), COA(A), HA(B), COA(B), TA } KA In the signature mechanism, the claimant (A) signs messages with a private key, and uses a home address that is derived from their public key in the way that was described in section 2. The claimant sends their public key (KA), the modifier (M) that was used to derive their home address from the key, and the signed message to the verifier (B). The signed message contains a timestamp (TA) to protect the message against replay. The verifier checks that the timestamp is recent, that the the claimant's home address is derived from the public key, and that the signature matches. This mechanism requires the clocks of the claimant and the verifier to be loosely synchronized. They do not need to be exactly the same, but they SHOULD be within a few seconds of each other. Too large a difference between the sender's and receiver's clocks can cause genuine messages to be rejected as replays and replays to be accepted Roe [Page 3]
INTERNET DRAFT Authentication of Binding Updates July 2001 as genuine. An out of date timestamp can be caused either by an attacker replaying messages or by the clocks not being adequately synchronized. A verifier that detects an out of data timestamp MAY request the claimant to resend the message using an alternative authentication mechanism that does not depend on synchronized clocks. 3.4 Signed Challenge-Response Mechanism B -> A : RA -1 A -> B : KA, M, { message, HA(A), COA(A), HA(B), COA(B), RA } KA The signed challenge-response mechanism combines the features of the challenge-response mechanism and the signature mechanism. The verifier will only accept messages if they contain a challenge that the verifier has previously sent, and are signed with a private key that is related to the claimant's home address as described in section 2. Unlike the signature mechanism, this mechanism does not depend on synchronized clocks. The challenge serves two purposes: it is used as a quick check that will detect many attempted forgeries without needing to perform any public-key operations, and it is also used to detect replays of old messages. Verifiers SHOULD check that the response (RA) is correct before attempting to verify the digital signature. It is typically much quicker to verify RA than to verify the signature, and so verifying RA first provides better protection against denial of service attacks in which the verifier is flooded with many bogus messages. 4 New IPv6 Sub-option Types This memo defines the following IPv6 sub-option types: 4.1 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 4]
INTERNET DRAFT Authentication of Binding Updates July 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 [1] 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 [2] and First64 extracts the first 64 bits of the 128 bit hash value. InterfaceId = First64(SHA1(M | RFU | Public Key)) & 0xfcffffffffffffff Packets where this relationship does not hold MUST be rejected as invalid. 4.2 Time Sub-option Alignment requirement: 4n+2 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 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | +---------------------------------------------------------------+ The Time sub-option is valid only in Binding Update or Binding Acknowledgment destination options. The Time field contains the time that the Binding Update or Acknowledgment was generated, as measured by the sender's clock. The time is represented by the middle 32 bits of the NTP timestamp [6]. 4.3 Challenge Sub-option Alignment requirement: 4n+2 Roe [Page 5]
INTERNET DRAFT Authentication of Binding Updates July 2001 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 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +---------------------------------------------------------------+ The Challenge sub-option is valid only in Binding Acknowledgment, Binding Update or Binding Request destination options. This field MUST NOT occur in a Binding Acknowledgment whose status field is zero (success). The Challenge field contains a challenge which has been generated randomly or pseudo-randomly by the sender. This sub-option is used to request the use of the Challenge-Response Response authentication mechanisms. 4.4 Signature Challenge Sub-option Alignment requirement: 4n+2 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 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +---------------------------------------------------------------+ The Signature Challenge sub-option is valid only in Binding Acknowledgment, Binding Update or Binding Request destination options. This field MUST NOT occur in a Binding Acknowledgment whose status field is zero (success). The Challenge field contains a challenge which has been generated randomly or pseudo-randomly by the sender. This sub-option is used to request the use of the Signed Challenge Response authentication mechanisms. Roe [Page 6]
INTERNET DRAFT Authentication of Binding Updates July 2001 4.5 Response to Challenge Sub-option Alignment requirement: 4n+2 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 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | +---------------------------------------------------------------+ The Response to Challenge sub-option is valid only in Binding Update or Binding Acknowledgment destination options. A Binding Acknowledgment destination option MUST NOT include a Response to Challenge sub-option unless it is generated in response to a Binding Request destination sub-option that includes a Challenge sub-option. A Binding Update destination option MUST NOT include a Response to Challenge sub-option unless it is generated in response to a Binding Request destination option that includes a Challenge sub-option. The Response field contains a copy of the Challenge field from the Challenge (or Signature Challenge) sub-option from the Binding Update (or Request) that caused the Binding Acknowledgment (or Update) to be generated. 5 New Assigned Numbers 5.1 Binding Acknowledgment Status Values The following new values for the Status field within a Binding Acknowledgment sub-option are defined: <TBA> Authentication Required <TBA> Authentication Failed <TBA> Time Error A status of "Authentication Required" indicates that sender requires authentication for Binding Update destination options. If the status is "Authentication Required", then the sub-options field SHALL include one or more sub-options that describe authentication methods that the sender will accept (e.g. a Challenge sub-option) A status of "Authentication Failed" indicates that verification of the authenticator field in the Binding Update failed. If the status is "Authentication Failed", then the sub-options field MUST NOT include sub-options that describe alternative authentication methods. Roe [Page 7]
INTERNET DRAFT Authentication of Binding Updates July 2001 A status of "Time Error" indicates that the Binding Acknowledgment was rejected because the difference between the time as measured by the sender's local and the time as indicated in the Time sub-option of the Binding Update was too great, Possible causes of this situation include: either the sender or the receiver's clock is set incorrectly; an attacker is replaying old Binding Updates. If the status is "Time Error", then the sub-options field SHALL include one or more sub-options that describe authentication methods that the sender will accept and that do not depend on the sender and receiver having synchronized clocks. 5.2 Security Parameters Index The following new value for the Security Parameters Index field within a Binding Update or Binding Acknowledgment destination option is defined: <TBA> Signature with Key related to Address 6 Realization of the Abstract Protocols for Binding Updates 6.1 Challenge-Response Mechanism A correspondent node MAY request use of the Challenge-Response mechanism for binding updates either by sending a Binding Request destination option containing a Challenge sub-option, or by sending a Binding Acknowledgment destination option with the status not equal to zero and containing a Challenge sub-option. To use the challenge-response mechanism for binding updates, a mobile node includes a Response to Challenge sub-option. 6.2 Signature Mechanism This memo does not specify a method for a correspondent node to explicitly request the use of the signature mechanism. It is recommended that the Signed Challenge Response mechanism SHOULD be used in preference to the Signature mechanism in situations where the claimant sends an authenticated message in response to a request from the verifier. The signature mechanism is mainly useful in situations where the claimant sends a message to the verifier without having received a message in the opposite direction first. To use the Signature mechanism for binding updates, a mobile node includes a Time sub-option, sets the Security Parameters Index field of the binding update destination option to Signature with Key Roe [Page 8]
INTERNET DRAFT Authentication of Binding Updates July 2001 Related to Address (defined in section 5), and places a digital signature within the authentication information field of the binding update option. 6.3 Signed Challenge-Response Mechanism A correspondent node MAY request the use of the Signed Challenge- Response mechanism for binding updates either by sending a Binding Request destination option containing a Signature Challenge sub- option, or by sending a Binding Acknowledgment destination option with the status not equal to zero and containing a Signature Challenge sub-option. To use the Signed Challenge-Response mechanism for binding updates, a mobile node includes a Response to Challenge sub-option, sets the Security Parameters Index fielf of the binding update destiantion option to Signature with Key Related to Address (as defined in section 5), and places a digital signature within the authentication information field of the binding update option. 7 Realization of the Abstract Protocols for Binding Acknowledgments 7.1 Challenge-Response Mechanism A mobile node MAY request the use of the Challenge-Response mechanism for a binding acknowledgments by sending a Binding Update containing a Challenge sub-option. To use the challenge-response mechanism for binding acknowledgments, a mobile node includes a Response to Challenge sub-option. 7.2 Signature Mechanism It is recommended that the Signed Challenge Response mechanism SHOULD be used in preference to the Signature mechanism for Binding Acknowledgments, as these acknowledgments are always sent in response to a message in the opposite direction. 7.3 Signed Challenge-Response Mechanism A mobile node MAY request the use of the Signed Challenge-Response mechanism by including a Signature Challenge sub-option within a Binding Update destination option. To use the signed challenge-response mechanism for binding acknowledgments, a node includes a Response to Challenge sub-option, sets the Security Parameters Index to Signature with Key Related to Address, and places a digital signature within the Authentication Roe [Page 9]
INTERNET DRAFT Authentication of Binding Updates July 2001 Information field of the binding acknowledgment. 8 Security Considerations 8.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. 8.2 Risks of unauthenticated binding acknowledgments The consequences of forged binding acknowledgments are, in general, less serious that those of forged binding updates. The usual consequence of forging a binding acknowledgment 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 updates sent to the victim's home agent have more serious consequences than forgeries sent to other correspondents. If victim is away from home, and its home agent does not have a valid binding for it, then the victim will become uncontactable. 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. Roe [Page 10]
INTERNET DRAFT Authentication of Binding Updates July 2001 8.3 Denial of service attacks on the Signature only mechanism The signature mechanism protects hosts against denial of service attacks in which they are sent forged binding updates, but it makes them vulnerable to a new denial of service attack in which the attacker floods them with a very large number of binding updates with invalid signatures. These binding updates will be rejected, but because the signature takes a significant amount of computing time to check, the victim may not have CPU time left in which to do anything else. The Signed Challenge-Response mechanism is not vulnerable to this attack, and it SHOULD be used instead of the Signature Only mechanism in environments where this attack is a concern. 8.4 Challenges must be unpredictable In the Challenge-Response and Signed Challenge-Response mechanisms, the value chosen for the challenge must be difficult for an attacker to predict. RFC 1750 [3] has recommendations on how to choose unpredictable random numbers. 8.5 Meet in the Middle Attacks The Signature Only and Signed Challenge-Response are vulnerable to a meet in the middle attack, where the attacker wishes to masquerade as one of a large number of hosts, but does not care which of those host they are able to impersonate. In this attack. the attacker generates a large number of key pairs and addresses until they obtain an address that collides with one of the possible victims. If the set of possible victims is very large, this is faster than attempting to impersonate one specific victim. In view of this attack, care should be taken when using these mechanisms to authenticate messages other than binding updates or acknowledgments. The use of these mechanisms for other purposes is outside the scope of this memo. 8.6 Risks of making the Modifier field too large This memo restricts the possible values of the modifier field to the range 0 to 3. If the protocol had permitted a wider range of modifier values, it would have been easier to attack. An attacker who wishes to masquerade as a particular address can generate a key pair and then try different values of the modifier to see if any of them hash to the address they wish to impersonate. When all possible values of the modifier have been tried, the attacker can try different keys. Generating a new key pair takes much longer than trying a different modifier, so by restricting the range of modifier values we make the attacker's job harder. If this attack succeeds, the attacker will (with high probability) still not know the victim's private key. The attacker will have a different private key who corresponding public Roe [Page 11]
INTERNET DRAFT Authentication of Binding Updates July 2001 component happens to hash to the same value as the victim's public key. However, this is sufficient to break the protocol. A variation on this attack is to try public keys which are cryptographically weak (e.g. easy to factorize), and to start work on calculating the corresponding private key when a public key has been found that hashes to the right value. It is quicker to generate a weak key than a strong one (at least with RSA), and so this may speed up the attack. 8.7 Strength of Mechanism The Signature and Signed Challenge-Response mechanism construct a home address using 62 bits out of the 160 bit output of SHA-1. Only 62 bits can be used, because the host part of an address is 64 bits long, and two of those bits are the universal/local and the individual/group bit. The number of address bits is fixed by the IPv6 addressing architecture [4] and cannot be increased. Using only some of the bits of the SHA-1 output reduces the cryptographic security of the hash function. It is much easier for an attacker to find an input which gives particular values for 62 of the output bits than it is to find an input which gives particular values for all 160 of the output bits. Accordingly, users of these mechanism should take care that the reduced level of security of these mechanisms is appropriate for the environment in which they are being used. When evaluating the strength of these mechanisms, it is important to bear in mind that SHA-1 is designed to have two properties (non- invertability and collision-freedom), and that the mechanisms described in this memo only rely on the non-invertability property. To achieve a particular level of security,it takes approximately twice as many bits of the hash output to provide the non-invertabiity property as it does to provide the collision-freedom property. Mechanisms that only rely on non-invertability can get away with using half as many bits of the hash output as mechanisms that rely on collision-freedom. 9 References [1] 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. [2] Secure hash standard. FIPS PUB 180-1, NIST, April 1995 [3] D. Eastlake, S. Crocker and J. Schiller. Randomness Roe [Page 12]
INTERNET DRAFT Authentication of Binding Updates July 2001 recommendations for security. RFC 1750, December 1994. [4] R. Hinden and S. Deering. Ip Version 6 Addressing Architecture. RFC 2373, July 1998. [5] D. B. Johnson and C. Perkins. Mobility Support in IPv6. Internet draft, July 2001. [6] D. L. Mills. Network time protocol (version 3) specification, implementation and analysis. RFC 1305, March 1992. 10 Author's Address Michael Roe Microsoft Research Limited St George House 1 Guildhall Street Cambridge CB2 3NH UK Roe [Page 13]