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]