[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

   IETF Mobile IP Working Group
   INTERNET DRAFT

                                                                   M. Roe
                                                                  T. Aura
                                                                G. O'Shea
                                                                Microsoft
                                                                 J. Arkko
                                                                 Ericsson
                                                            February 2002
                                                   Expires: 1 August 2002

       Authentication of Mobile IPv6 Binding Updates and Acknowledgments
                    <draft-roe-mobileip-updateauth-02.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
   [1]http://www.ietf.org/1id-abstracts.html

   The  list  of  Internet-Draft  Shadow  Directories  can be accessed at
   [2]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;
     * 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;
     * To  make it difficult for an attacker to exhaust a node's resource
       by causing it to process large numbers of binding updates;
     * To  prevent  binding  updates  being replayed for any of the above
       purposes.

   The  three  protocols  differ  in  the amount of computation that they
   require  and  the assumptions made 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

Roe                                                             [Page  1]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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. Threats addressed by the protocols in this memo

   We have identified the following threats to the mobile IPv6 protocol:

    1. A malicious mobile node might lie about its home address.
       A  malicious  mobile  node might send a correspondent node binding
       updates in which the home address is set to the address of another
       node  ("the  victim").  If  the  correspondent  node accepted this
       forged   binding   update,   then   communications   between   the
       correspondent  node  and  the  victim  would be disrupted, because
       packets that the correspondent node intended to send to the victim
       would be sent to the wrong care-of address.
       This  is  a  threat  to  confidentiality  as well as availability,
       because  an attacker might redirect packets meant for another node
       to itself in order to learn the content of those packets.
    2. A malicious mobile node might lie about its care-of address.
       A  malicious  mobile  node might send a correspondent node binding
       updates  in  which  the  care-of  address is set to the address of
       another  node  ("the  victim  node")  or an address within another
       network ("the victim network"). If the correspondent node accepted
       this  forged binding update, then the malicious mobile could trick
       the  correspondent  into  sending  data  to the victim node or the
       victim  network;  the  correspondent's replies to messages sent by
       the  malicious  mobile will be sent to the victim host or network.
       This  could  be  used  to  cause  a  distributed denial of service
       attack; the malicious mobile could trick a large number of servers
       so  that  they  all send a large amount of data to the same victim
       node or network.
       There are several variations of this threat:
          + A   malicious   mobile   might   start  off  by  sending  the
            correspondent  node  binding updates containing its true care
            of address, and then later (once its initial home and care of
            addresses   had  been  authenticated)  send  binding  updates
            containing the victim's care of address.
          + A   malicious   mobile   might   start   of  by  sending  the
            correspondent  node binding updates contains its true care of
            address, and then continue to send binding updates containing
            that care-of address even after that care of address had been
            reallocated  to a different node (the victim). This variation
            of  the  threat  might  be  regarded as less serious than the
            previous  two,  because  the  attacker's  choice of victim is
            restricted  to  nodes  that  are  currently  using  a care of
            address that the attacker has used in the past.
    3. A  malicious  node  might  send  a large number of invalid binding
       updates to a victim correspondent node.
       If  each  invalid  binding  update  took  a  significant amount of
       resources  (such  as CPU) to process before it could be recognized
       as invalid, then it might be possible to cause a denial of service

Roe                                                             [Page  2]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

       attack by sending the correspondent so may invalid binding updates
       that it has no resources left for other tasks.
    4. An attacker might reply an old binding update.
       An   attacker   might   attempt   to   disrupt   a  mobile  node's
       communications  by  replaying  a  binding update that the node had
       sent  earlier.  If  the  old  binding update was accepted, packets
       destined for the mobile node would be sent to its old location and
       not its current location.

   All  of  the  above  threats are concerned with denial of service. The
   first  threat is the denial of service caused when the correspondent's
   state  (its binding cache) contains incorrect information derived from
   forged  messages. The second threat is the denial of service caused to
   a third party when the correspondent is tricked into consuming network
   resources.  The  third threat is the denial of service caused when the
   correspondent  must  consume  a significant amount of resource such as
   CPU and memory to distinguish genuine updates from forged ones.

2. Abstract Protocols

  2.1 Notation

   This memo uses the following notation:

   MN A mobile node
   CN A correspondent node
   A -> B Node A sends a message to B
   A -> B(HoA) Node A sends a message to B at its home address
   A -> B(CoA) Node A sends a message to B at its care-of address
   HoA Mobile node's home address
   CoA Mobile node's care-of address
   MAC[K](m) A message authentication code computed on message m with key
   K
   H(m) A hash of message m

  2.2 The Shared Key Protocol

    Properties of the Protocol

   The  shared  key  protocol  is  used  to  authenticate binding updates
   between  a mobile node and a correspondent node that share a symmetric
   key  (K[h]). There are several different ways in which a correspondent
   and  a  mobile  can  agree on a shared key for use with this protocol;
   these will be described later.

   The protocol has the following properties:

     * A node needs to know the shared secret (K[h]) in order to create a
       binding  update  that  will be accepted by the correspondent. This
       prevents   a   malicious   mobile  from  forging  binding  updates
       containing  another node's home address; the malicious mobile will
       not know the correct key.
     * To create a binding update for a care-of address that is not equal
       to  its  home  address,  a mobile node needs to be able to receive

Roe                                                             [Page  3]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

       messages sent to that care-of address.
     * To  create  a binding update that deletes a binding cache entry, a
       mobile  node needs to know the secret K[h] but does not need to be
       able to receive messages sent to a particular address.

    Walkthrough

   Each  correspondent  node  has  a secret key, K[CN]. 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,  N[j],  at  regular intervals, for example every few minutes. A
   correspondent  node  uses the same K[CN] and N[j] with all the mobiles
   it  is in communication with, so that it does not need to generate and
   store  a new N[j] when a new mobile contacts it. Each value of N[j] is
   identified  by  the subscript j. j is communicated in the protocol, so
   that  if  N[j]  is  replaced  by  N[j+1]  part  way through a 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  N[j] and the previous value N[j-1]. Older values can be discarded,
   as  messages using them will in any case be rejected as replays. K[CN]
   can  be  either a fixed value or regularly updated. An update of K[CN]
   can  be  done  at  the  same  time  as  an  update  of N[j], so that j
   identifies  both  the  nonce  and  the  key.  A correspondent node can
   generate  a  fresh K[CN] each time that it boots to avoid the need for
   secure persistent storage for K[CN].

    1. MN -> CN : HoA, CoA
       In  step 1, the mobile node informs the correspondent node that it
       is  mobile,  and  gives  both  the  mobile's  home address and its
       care-of address.
    2. CN -> MN(CoA) : r[c], j
       r[c] = MAC[K[CN]](CoA | N[j] | 1)
       In  step  2, the correspondent node sends a binding request to the
       mobile  node. The binding request contains a challenge (r[c]), and
       a  serial number (j) that indicates which version of N[j] was used
       to generate the challenge. The challenge is generated from N[j] so
       that  the  correspondent  does not need to store state to remember
       which  challenges  it  has  sent  to which mobiles --- r[c] can be
       recomputed from N[j] as it is needed.
    3. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]] (T[0] | HoA | CoA | i), j
       K[BU] = H(K[h] | r[c])
       In  step  3, the mobile node hashes together the shared secret and
       the  challenge  to  form a session key (K[BU]), and then uses this
       session  key  to authenticate a binding update. The binding update
       contains j, so that the correspondent knows which value of N[j] to
       use  to  recompute  the session key. Once it has verified the MAC,
       the correspondent can create a binding cache entry for the mobile.
       This message contains a tag (T[0]) so that it can be distinguished
       from  message  1 of the variant version of the protocol (described
       below).  The binding update also contains a sequence number (i) so
       that  if  more than one binding update is sent within the lifetime
       of  a  single  value  of  N[j],  it is possible to determine their
       relative ordering.

Roe                                                             [Page  4]
INTERNET DRAFT      Authentication of Binding Updates       February 2001


   When  the  correspondent's  binding  cache  entry  for the mobile node
   expires,  the  correspondent  can  refresh  it  by  running  the above
   protocol again, starting at step 2. The message sent in step 2 of this
   new  run  of  the  protocol  will usually use a different value of the
   challenge  from  message  that  was sent in step 2 of the previous run
   with the same mobile, because the value of N[j] has changed.

   If  the  mobile  changes  its  care-of  address,  but is still able to
   receive  messages  sent  to  the old care-of address, then it runs the
   above protocol again using its new care-of address.

   If  the  mobile  changes its care-of address, and is unable to receive
   messages  sent  to  the  old  address,  then  it uses a variant of the
   protocol  to  give  the correspondent an earlier notification that the
   old address is no longer valid:

    1. MN  ->  CN  :  T[1], HoA, CoA', i', MAC[K[BU]] (T[1] | HoA | CoA',
       i'), j
       In  step  1,  the mobile node sends a binding update authenticated
       using  the  key  K[BU]  derived  from the key that was sent to the
       mobile's old care-of address, CoA. (At this point in the protocol,
       the  mobile  has  not  yet  received  a  challenge sent to its new
       care-of  address, CoA). This message contains a tag (T[1]) so that
       it  can be distinguished from the binding update sent in message 3
       of the previous protocol.
       If the correspondent has a binding cache entry for the mobile, and
       it  is  able  to verify the MAC correctly, then it should mark the
       binding  cache  entry as invalid. Note that the correspondent will
       only be able to verify the MAC if it has an existing binding cache
       entry  for  the  mobile,  because  it  will  need  to know the old
       care-old   address   to   reconstruct   the   key  K[BU].  If  the
       correspondent  does  not  have an existing binding cache entry for
       the  mobile  node, then it does not need to verify the MAC because
       the binding cache entry has already been deleted.
    2. CN -> MN(CoA') : r'[c], j'
       r'[c] = MAC[K[CN]](CoA' | N[j'] | 1)
       In  step  2,  the  correspondent  sends a new challenge to the new
       care-of  address.  It  should  send  this challenge even if it was
       unable  to  verify the MAC on message 1. The reason for doing this
       is  that  it  allows  the protocol to resynchronise after messages
       have been lost or nodes have lost their state.
    3. MN  ->  CN : T[0], HoA, CoA', i'', MAC[K'[BU]] (T[0] | HoA | CoA',
       i''), j'
       K'[BU] = H(K[h] | r'[c])
       The  third  step if this protocol is the same as the third step of
       the  previous  protocol.  Once  the correspondent has verified the
       MAC,  it  can  create a new binding cache entry for the mobile (or
       update the existing one).

    Optimizations

    1. It  is  not  necessary to encode all the bits of j in the protocol
       messages;  just  the  least  significant bit is sufficient for the

Roe                                                             [Page  5]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

       correspondent to tell whether to use N[j] or N[j-1].
    2. The  values of N[j] should be non-repeating, but do not need to be
       unpredictable.  This  means  that  N[j]  can  be  implemented as a
       counter.  The  secret K[CN] should be changed if the counter wraps
       or is reset (e.g. after a reboot)
    3. It  is not necessary to encode all the bits of the sequence number
       i.  It  is  sufficient  to encode enough of the lower bits of i so
       that  it is possible to determine the relative ordering of binding
       updates sent within the lifetime of a single N[j].

    Manually Configured Keys

   This  protocol  can  be  used  with a shared secret K[h] that has been
   configured  manually. This option might be appropriate for use between
   a  mobile  node  and  its  home  agent;  the home agent can maintain a
   database of the keys that have been issued to the mobile nodes that it
   serves.

    Use with a PKI

   This protocol can also be used with a shared secret K[h] that has been
   agreed   using   a   certificate-based  key  agreement  protocol.  The
   certificates  should  associate  a  node's  public  key  with its home
   address.  That  is,  the  public  key infrastructure should be used to
   authenticate the node's homes address rather than its care-of address.

  2.3 BAKE/2

    Properties of the Protocol

   The  "Bake/2"  protocol extends the shared key protocol of section 2.2
   by providing a means to establish the shared secret dynamically.

   This  protocol  is  only  suitable  for  use  in  an environment where
   communication  from  the  correspondent  through the home agent to the
   mobile  node,  and  between  the  home  agent  and the mobile node are
   protected  from  eavesdropping  by  means  outside  of  this 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 agent and the correspondent node, but not
   by attackers on the wireless network or elsewhere on the Internet.


Roe                                                             [Page  6]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

    Walkthrough

    1. MN -> CN : HoA, CoA
       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) : K[h], j
       K[h] = MAC[K[CN]](HoA | N[j] | 0)
       In  the  second  step,  the correspondent generates a value (K[h])
       that  will  be  used as a shared secret between the mobile and the
       correspondent.  This  shared secret is sent to the mobile node via
       its  home  agent;  it  is  an assumption of the protocol that this
       route  is  secure.  K[h] also acts as a challenge to test that the
       mobile can receive messages sent to its home address.
    3. CN -> MN(CoA) : r[c], j
       r[c] = MAC[K[CN]](CoA | N[j] | 1)
       The  correspondent  also sends a challenge to the mobile's care-of
       address.  This  step  is  the  same  as  step  2 of the shared key
       protocol described in section 2.2.
    4. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i), j
       K[BU] = H(K[h] | r[c])
       In  the  third  step,  the  mobile  sends an authenticated binding
       update.

  2.4 CAM-DH

    Properties of the Protocol

   The  "CAM-DH"  protocol  combines the BAKE/2 protocol with a digitally
   signed Diffie-Hellman key exchange. In CAM-DH, each mobile node's home
   address  is  generated  from  its  public  signature  key.  The use of
   cryptographically-generated  addresses (CGA) avoids the need for X.509
   certificates  or similar mechanisms that associate keys with addresses
   [5].  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
   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
   cryptographically  generated  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

Roe                                                             [Page  7]
INTERNET DRAFT      Authentication of Binding Updates       February 2001


    1. MN -> CN : HoA, CoA
       In  the  first message, the mobile node contacts the correspondent
       node, giving the mobile's home and care-of addresses.
    2. CN -> MN(HoA) : r[h], j, gy
       r[h] = MAC[K[CN]](HoA | N[j] | 0)
       In the second and third messages, the correspondent node sends the
       mobile  node two challenges, one to the care-of address and one to
       the  home  address.  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 K[CN],
       y  can  be  constant  (this  reduces  by one the number of modular
       exponentiations  that  the  correspondent  needs)  or periodically
       updated.  If y is changed, the subscript j indicates which version
       of y to use (as well as which K[CN] and N[j]).
    3. CN -> MN(CoA) : r[c], j
       r[c] = MAC[K[CN]](CoA | N[j] | 1)
    4. MN  ->  CN  : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i),
       gx, S[PK](TypeTag | gx | HoA), PK, MAC[K[3]](...), j
       K[3] = h(r[h] | r[c])
       K[h] = h(gxy | r[h])
       K[BU] = h(K[h] | r[c])
       When  it  has  received the two challenges, the mobile hashes them
       together to form a key (K[3]), and then uses this key to compute a
       message   authentication   code  on  its  public  key  and  signed
       Diffie-Hellman  parameter.  The purpose of this MAC is to convince
       the  correspondent that the risk of the message being a forgery is
       low enough that it is worthwhile expending computational resources
       on  checking  the  signature  and  calculating  the Diffie-Hellman
       exponent gxy. 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
       K[BU],   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 a key derived from the two challenges.
       When  the  correspondent  receives  the  fourth message, it should
       check  the  outer  MAC  with K[3] first. It should only attempt to
       compute  K[BU]  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 key K[h].
    5. CN -> MN : r'[c], j'
       When  the  correspondent  node's  binding  cache entry is about to
       expire,  the correspondent sends the mobile node a binding request
       containing  a  fresh challenge. (Typically, N[j] will have changed
       since the last time a challenge was sent to the mobile).
    6. MN  ->  CN : T[0], HoA, CoA, i, MAC[K'[BU]](T[0] | HoA | CoA | i),
       j'
       K[h] = h(gxy | r[h])
       K'[BU] = h(K[h] | r'[c])

Roe                                                             [Page  8]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

       The mobile node hashes the old value of K[h] together with the new
       challenge  to compute a new key K'[BU], and sends a binding update
       authenticated using this key.

    Optimizations

    1. 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 : r[h], j, gy
       HA -> MN : CN's address, K[h], j
       K[h] = h(gxy | r[h])
       To  use  this  optimization, communications between the home agent
       and  the mobile node must be protected against eavesdropping (e.g.
       by using IPSEC ESP).
    2. 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 contains a flag that indicates to the mobile node whether
       the  correspondent  is  using this optimisation. When this flag is
       set  in  the  second  message,  the  mobile should send the fourth
       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. New IPv6 Sub-option Types

   This  memo  defines  the  following IPv6 destination option sub-option
   types:

  3.1 Care-of Address Challenge

   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       |   Serial      |   Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Algorithm   |       Challenge (variable length)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The  Care-of  Address  Key  Challenge sub-option is valid in a Binding
   Request destination sub-option. The Serial field contains the variable
   j  in  the  BAKE/2 and CAM-DH protocols. The Algorithm field indicates
   which   cryptographic   algorithm   should  be  used  to  compute  the

Roe                                                             [Page  9]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   authentication information field in the Binding Update that is sent in
   response  to  this  option. The Challenge field contains the challenge
   r[c]  in the shared key, 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.

   The   Protocol  field  indicates  which  authentication  protocol  the
   correspondent requires. The following values are defined:

   1 The shared key protocol
   2 BAKE/2
   3 CAM-DH

   The Algorithm field indicates which cryptographic algorithms are to be
   used in the authentication protocol. The following values are defined:

   1 HMAC-SHA1

   The Challenge field is of variable length. It is recommended that this
   field be 4 bytes long.

  3.2 Response to Challenge

   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       |    Serial     |   Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |K|    RFU      |     Authenticator (variable length)           |
      +---------------------------------------------------------------+

   The  Response  to  Challenge  sub-option  is valid in a Binding Update
   destination option.

   The Serial field contains the variable j in the shared key, BAKE/2 and
   CAM-DH  protocols.  That  is,  it  tells  the  correspondent node that
   receives  the suboption which of the challenge values (N[j]) are to be
   used to authenticate the binding update.

   The  Protocol  field  indicates  which protocol (shared key, BAKE/2 or
   CAM-DH)  was  used  to  construct the authenticator. The value of this
   field  is the same as the value of the Protocol field in the Challenge
   sub-option.

   The  K  bit  corresponds  to  the tags T[0] and T[1] in the shared key
   protocol.  It is set to zero if the MAC on the binding update is to be
   verified  using  the  challenge  that  was  sent  to the mobile node's
   current  care-of  address,  and  is  set to 1 if the binding update is
   authenticated  using  the challenge that was sent to the mobile node's
   previous care-of address.

   The RFU bits are reserved for future use and shall be set to zero. The

Roe                                                             [Page 10]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   Authenticator  field  is  computed  by  applying  HMAC-SHA1-80  to the
   following data:

   AHSD, Reserved 3 bytes
   Sequence Number 1 byte
   Lifetime 4 bytes
   Home Address 16 bytes
   Care-of Address 16 bytes
   K, RFU 1 byte

   The  A,  H,  S,  D, Reserved, Sequence Number and Lifetime fields show
   above  have  the same value as the corresponding fields in the Binding
   Update. The Home Address field contains the Home Address from the Home
   Address  option  earlier  in  the  packet.  The  Care-Of Address field
   contains  the  IP  source  address of the packet. The K and RFU fields
   shown  above  have  the  same value as the corresponding fields in the
   Response To Challenge sub-option.

4. Other Message Formats

  4.1 DHChallenge

HomeAddressChallenge ::=
    [0] SEQUENCE
    {
        serial INTEGER,
        CHOICE
            {
                bake2 [0]  SEQUENCE
                    {
                        key BIT STRING
                    }
                camDH [1] SEQUENCE
                    {
                         challenge BIT STRING,
                         exponential INTEGER,
                         disableRouteOptimization BOOLEAN
                    }
            }
    }

   The serial field contains the value of j. The key field contains K[h].
   The  challenge field contains r[h]. The exponential field contains gy.
   If  the  disableRouteOptimization  field  is  set  to  TRUE,  then the
   response  to  this  message should be sent to the correspondent's home
   address, not its care-of address.

  4.2 DHResponse

DHResponse ::=
    [1] SEQUENCE
    {
        serial INTEGER,
        signedExponential SIGNED SEQUENCE

Roe                                                             [Page 11]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

        {
            tag OBJECT IDENTIFIER,
            homeAddress BIT STRING,
            exponential INTEGER
        }
        publicKey PublicKey,
        innerMAC BIT STRING,
        outerMAC BIT STRING
    }

   The  serial  field  contains  the  value  of  j. The exponential field
   contains  the  value of gx. The innerMAC field contains a MAC computed
   using  K[BU]  with  HMAC-SHA1-80.  The  outerMAC  field contains a MAC
   computed using K[3] with HMAC-SHA1-80.

   The value of the tag field is to be assigned.

5. Assigned Numbers

  5.1 Ports

   UDP_PORT_CAM to be assigned

  5.2 Object Identifiers

   SignedExponent to be assigned

  5.3 Binding Acknowledgement Status Values

   AUTHENTICATION_REQUIRED to be assigned

6. Realisation of the Abstract Protocols

  6.1 The Shared Key Protocol

    1. The  mobile  sends the correspondent a packet containing a Binding
       Update destination option.
    2. The  correspondent  sends the mobile a packet containing a Binding
       Acknowledgment  destination  option,  with the status field set to
       AUTHENTICATION_REQUIRED.  The  Binding  Acknowledgment  contains a
       Care-Of Address Challenge sub-option.
    3. The  mobile  sends the correspondent a packet containing a Binding
       Update  destination  option,  which in turn contains a Response to
       Challenge  sub-option.  The Flags field of this sub-option will be
       set  to 0. The Serial field of this sub-option will be the same as
       the  Serial  field  of the Care-Of Address Challenge sub-option in
       the  previous  step. The other fields are computed as described in
       section 3.2.
    4. The correspondent sends the mobile a Binding Acknowledgement, with
       the status field set to indicate success.
    5. When  the  correspondent's Binding Cache Entry is about to expire,
       the  correspondent sends the mobile a Binding Request containing a
       Care-Of Address Challenge sub-option.
    6. The  mobile  replies  to  the  request by sending a Binding Update

Roe                                                             [Page 12]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

       containing a Response to Challenge sub-option.
    7. When  the  mobile's Binding Entry is about to expire, it sends the
       correspondent  a Binding Update containing a Response to Challenge
       sub-option.
    8. The correspondent replies with a Binding Acknowledgment.
          + If the value of the Serial field in the Binding Update is the
            one  which  the  correspondent is currently using, the status
            field  of  the  Binding  Acknowledgement  is  set to indicate
            success.
          + If the value of the Serial field in the Binding Update is not
            the most recent one, but is recent enough to be acceptable to
            the  correspondent,  then the Binding Acknowledgment's status
            field   is   set   to   indicate   success  and  the  Binding
            Acknowledgment   contains   a   Care-Of   Address   Challenge
            sub-option with the most recent value in the Serial field.
          + If the value of the Serial field in the Binding Update is too
            old  to  be  acceptable,  the  status  field  of  the Binding
            Acknowledgment  is  set  to  indicate failure and the Binding
            Acknowledgment   contains   a   Care-Of   Address   Challenge
            sub-option with the most recent value in the Serial field.
            In  this  case,  the  mobile  will reply with another Binding
            Update containing a Response to Challenge sub-option.

  6.2 BAKE/2

    1. The  mobile  sends the correspondent a packet containing a Binding
       Update destination option.
    2. The    correspondent    sends    a    UDP    packet    of   format
       HomeAddressChallenge  to  the mobile at the port UDP_PORT_CAM. The
       optional exponential field is not present in this packet.
    3. The  correspondent  sends to the mobile (at its care-of address) a
       packet  containing  a  Binding  Acknowledgement destination option
       with  the status field set to AUTHENTICATION_REQUIRED. The Binding
       Acknowledgment contains a Care-Of Address Challenge sub-option.
    4. The  mobile  sends the correspondent a packet containing a Binding
       Update  destination  option,  which in turn contains a Response to
       Challenge  sub-option.  The Authenticator field of this sub-option
       is computed as described in section 3.2.
    5. The  correspondent  sends the mobile a packet containing a Binding
       Acknowledgment, with the status field set to indicate success.

   The  procedures  taken when the correspondent's Binding Cache Entry is
   about  to  expire,  and  when  the  mobile's Binding Entry is about to
   expire, are the same as for the shared key protocol.

  6.3 CAM-DH

    1. The  mobile  sends the correspondent a packet containing a Binding
       Update destination option.
    2. The    correspondent    sends    a    UDP    packet    of   format
       HomeAddressChallenge   to   the  mobile's  home  address  at  port
       PORT_UDP_CAM.
    3. The  correspondent  sends  the  mobile  (at its care-of address) a
       packet containing a Binding Acknowledgment destination option with

Roe                                                             [Page 13]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

       its  status  field  set  to  AUTHENTICATION_REQUIRED.  The Binding
       Acknowledgment contains a Care-Of Address Challenge sub-option.
    4. The  mobile  sends  a  UDP  packet  of  format  DHResponse  to the
       correspondent at port PORT_UDP_CAM.
    5. The  correspondent  sends  the  mobile  (at its care-of address) a
       packet  containing  a Binding Request destination option, which in
       turn contains a Care-Of Address Challenge sub-option.
    6. The  mobile  sends the correspondent a packet containing a Binding
       Update  destination  option,  which  in  turn contains a Challenge
       Serial Number sub-option.

7. Finite State Machines

  7.1 The Shared Key Protocol

    Mobile Node

     * Event: Mobile receives a Binding Request
       Action:  Add  the  correspondent  to the Binding Entry List, if it
       isn't already on it. Send a Binding Update. If the Binding Request
       contained  a  Care-of  Address  Challenge  sub-option,  include  a
       Response  to Challenge sub-option in the Binding Update, and store
       the value of the challenge in the Binding Entry List.
     * Event: Mobile's Care-Of Address changes
       Action: Send a Binding Update to all correspondents in the Binding
       Entry List. If it is no longer possible to receive packets sent to
       the  old  care-of address, set the T[1] tag in the binding update,
       and  compute  the authentication field based on the challenge that
       was  sent  to  the old care-of address. If it is still possible to
       receive  packets  sent  to the old care-of address, send a binding
       update without authentication.
     * Event: Mobile's Binding Entry about to expire
       Action:  Send  a Binding Update containing a Response to Challenge
       sub-option to the correspondent.
     * Event:  Mobile receives a packet from the correspondent routed via
       its home agent
       Action:  Check  the  Binding Entry List to see if a binding update
       has  been sent to this correspondent recently. If a binding update
       has  not  been  sent recently, send one. If the Binding Entry List
       contains  a  recent  challenge from the correspondent, use that to
       construct  a  Response to Challenge sub-option that is included in
       the  Binding  Update;  otherwise,  do  not  include  a Response to
       Challenge sub-option.
     * Event: Mobile receives a Binding Acknowledgment
       If the Binding Acknowledgment contains a Care-Of Address Challenge
       sub-option,  then  the mobile stores the value of the challenge in
       its  binding  entry list. If the Binding Acknowledgment contains a
       Care-Of  Address  Challenge sub-option and the status field is set
       to  indicate  failure,  then  the  mobile  sends  a Binding Update
       containing a Response to Challenge sub-option.

    Correspondent Node

     * Event: Binding Cache Entry about to expire

Roe                                                             [Page 14]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

       Action:  Send  the  mobile  a Binding Request containing a Care-of
       Address Challenge sub-option
     * Event: Receive a Binding Update
       Action:  If  the  Binding  Update contains a Response to Challenge
       sub-option,  and  the Serial field is sufficiently recent, and the
       Authenticator  field  contains  the  right  value, then update the
       Binding  Cache  and  send a Binding Acknowledgment with the status
       field  set  to  indicate success. If the value in the Serial field
       was not the most recent one, include a Challenge sub-option in the
       Binding Acknowledgment.
       Otherwise, send a Binding Acknowledgment with the status field set
       to  indicate  failure  and  containing a Care-of Address Challenge
       sub-option.

8. Background to the Protocol Designs

  8.1 IP Addresses derived from Cryptographic Keys

   In  the  CAM-DH  protocol,  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
   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 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 [3].
   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

Roe                                                             [Page 15]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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 [3].
   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.

  8.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 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 to 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
   binding  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 performing any cryptographic operations.

   Nodes  that  are willing to expend significant resources responding to

Roe                                                             [Page 16]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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 it is worthwhile expending resources on a protocol
   run  when  it  knows that the run has been initiated by a peer 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 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 successfully. 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.

  8.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  asymmetric
   cryptography,  they will add a large amount of jitter, because digital
   signatures require 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

Roe                                                             [Page 17]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   application can reserve a particular amount of bandwidth. Piggybacking
   can  interfere  with  these  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 asymmetric cryptography is being
   used  to  protect  the  mobility  control portion of the message. This
   recommendation  has  affected the design of the protocols 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.

  8.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.

  8.5 Rationale for BAKE/2

   Our  motivation for designing BAKE/2 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 of our earlier protocols for authenticating binding updates, such
   as  CAM  [5],  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

Roe                                                             [Page 18]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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.

   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-existing stored state about the mobile
   and  knows  that  it is 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.

9. Intellectual Property Rights Notice

   The  CAM-DH  variant  of  our protocols uses public keys and hashes to
   prove address ownership [4,5]. 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,
   [3]http://www.ietf.org/ietf/IPR/ERICSSON-General.    Microsoft's   IPR
   statement     concerning     this     memo     is     available     at
   [4]http://www.ietf.org/ietf/IPR/MICROSOFT-MOBILEIP-UPDATEAUTH.txt.

10. Security Considerations

  10.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

Roe                                                             [Page 19]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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.

  10.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 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

Roe                                                             [Page 20]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   of the attacker.

   One   possible   security   policy   that  takes  into  account  these
   considerations  is  to  require  authenticated binding acknowledgments
   from   a   home   agent,   but   to   accept  unauthenticated  binding
   acknowledgments from other correspondents.

  10.3 Risks of not verifying the care-of address

   The  BAKE/2  and  CAM-DH  protocols described in this memo verify 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.

   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.

  10.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,  i.e. one that will behave in a particular way. This means that

Roe                                                             [Page 21]

INTERNET DRAFT      Authentication of Binding Updates       February 2001

   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.

  10.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 a
   considerable degree of traffic amplification: for each packet that the
   attacker  sends  into  the  routing loop, the home agents will have 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

    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. R.  Hinden  and  S. Deering. IP Version 6 Addressing Architecture.
       RFC 2373, July 1998.
    4. P.  Nikander. A Scaleable Architecture for IPv6 Address Ownership.
       Internet draft, March 2001.
    5. Greg  O'Shea and Michael Roe. Child-proof authentication for MIPv6
       (CAM). Computer Communications Review, April 2001.

11. 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

Roe                                                             [Page 22]
INTERNET DRAFT      Authentication of Binding Updates       February 2001

UK
Email: tuomaura@microsoft.com

Greg O'Shea
Microsoft Research Limited
7 J J Thomson Avenue
Cambridge CB3 0FB
UK
Email: gregos@microsoft.com

Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland

Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/