[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03

Mobile IP Working Group                                  Charles Perkins
INTERNET DRAFT                                          Sun Microsystems
20 November 1997                                        David B. Johnson
                                              Carnegie Mellon University



                Registration Keys for Route Optimization

                   draft-ietf-mobileip-regkey-00.txt


Status of This Memo

   This document is a submission by the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@SmallWorks.COM mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   Route optimization [6] defines extensions to Mobile IP [7]
   registration requests that allow datagrams in flight when a mobile
   node moves, and datagrams sent based on an out-of-date cached
   binding, to be forwarded directly to the mobile node's new binding.
   These extensions for smooth handoff require a registration key to be
   established between the mobile node and foreign agent.  This document
   defines additional extensions to the registration requests to allow
   for the establishment of single-use registration keys between a
   mobile node and foreign agent.







Perkins and Johnson             Expires 20 May 1998             [Page i]


Internet Draft            Registration Keys             20 November 1997




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        1

 3. Establishing Registration Keys                                     2
     3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . .    3
     3.2. Using the Foreign Agent as a KDC  . . . . . . . . . . . .    4
     3.3. Using Diffie-Hellman with the Foreign Agent . . . . . . .    5

 4. Messages Requesting A Registration Key                             7
     4.1. Foreign Agent Key Request extension . . . . . . . . . . .    7
     4.2. Mobile Node Public Key extension  . . . . . . . . . . . .    8
     4.3. Foreign Agent Public Key extension  . . . . . . . . . . .    8
     4.4. Registration Key Request Extension  . . . . . . . . . . .    9

 5. Extensions to Supply A Registration Key                           10
     5.1. Home-Mobile Key Reply Extension . . . . . . . . . . . . .   10
     5.2. Foreign Agent Key Reply Extension . . . . . . . . . . . .   11
     5.3. Mobile Node Public Key Reply Extension  . . . . . . . . .   12
     5.4. Foreign Agent Public Key Reply Extension  . . . . . . . .   13
     5.5. Diffie-Hellman Key Reply Extension  . . . . . . . . . . .   14
     5.6. SPI Extension . . . . . . . . . . . . . . . . . . . . . .   15

 6. Mobile Node Key Requests                                          15

 7. Miscellaneous Home Agent Operations                               16
     7.1. Receiving Registration Key Requests . . . . . . . . . . .   16
     7.2. Home Agent Supplying Registration Keys  . . . . . . . . .   17

 8. Miscellaneous Foreign Agent Operations                            17
     8.1. Foreign Agent Handling Key Requests . . . . . . . . . . .   17

 9. Security Considerations                                           18

10. Summary                                                           19

References                                                            19

Chairs' Addresses                                                     20




Perkins and Johnson            Expires 20 May 1998             [Page ii]


Internet Draft            Registration Keys             20 November 1997


1. Introduction

   All Route Optimization messages that change the routing of IP
   datagrams to the mobile node are authenticated using the same
   mechanisms used in the base Mobile IP protocol.  The authentication
   relies on a mobility security association established in advance
   between the sender and receiver of such messages.  However, when a
   mobile node registers with a foreign agent, typically it does not
   share a security association with the foreign agent.  Nevertheless,
   in order for the foreign agent to process future binding updates that
   it may receive from the mobile node, it needs to have such a securiyt
   assocation.  Binding updates provide a mechanism for accomplishing
   smooth handoffs between a previous foreign agent to a new foreign
   agent.  Such smooth handoffs rely on the Previous Foreign Agent
   Notification extension [6], which requires the transmission of an
   authentic binding update to the previous foreign agent created by the
   mobile node after it moves.


2. Terminology

   This document uses the following terminology, in addition to that
   used to describe the base Mobile IP protocol:

      Binding cache

         A cache of mobility bindings of mobile nodes, maintained by a
         node for use in tunneling datagrams to those mobile nodes.

      Binding update

         A message indicating a mobile node's current mobility binding,
         and in particular its care-of address.

      Registration Key

         A secret key shared between a mobile node and a foreign
         agent, that may optionally be established during registration
         with that foreign agent.  When later moving and registering
         a new care-of address elsewhere, the mobile node uses the
         registration key shared with its previous foreign agent to send
         it an authenticated Binding Update to this foreign agent.

      Registration Lifetime

         The registration lifetime is the time duration for which a
         binding is valid.  The term remaining registration lifetime
         means the amount of time remaining for which a registration




Perkins and Johnson             Expires 20 May 1998             [Page 1]


Internet Draft            Registration Keys             20 November 1997


         lifetime is still valid, at some time after the registration
         was approved by the home agent.

      Security Parameters Index (SPI)

         An index identifying a security context between a pair of
         nodes among the contexts available in the Mobility Security
         Association.  SPI values 0 through 255 are reserved and MUST
         NOT be used in any Mobility Security Association.

      Triangle Routing

         A situation in which a Correspondent Host's packets to a Mobile
         Host follow a path which is longer than the optimal path
         because the packets must be forwarded to the Mobile Host via a
         Home Agent.


3. Establishing Registration Keys

   Foreign agents are expected to be cheap and widely available, as
   Mobile IP becomes fully deployed.  Mobile nodes will likely find it
   difficult to manage long-term security relationships with so many
   foreign agents.  To securely perform the operations needed for smooth
   handoffs from one foreign agent to the next, however, any careful
   foreign agent should require assurance that it is getting authentic
   handoff information, and not arranging to forward in-flight datagrams
   to a bogus destination.  The messages described in this document are
   used with the Mobile IP Registration Request and Registration Reply
   messages to create (sufficient) trust between mobile node and foreign
   agent when none exists beforehand, while allowing the use of fully
   trustworthy security associations between foreign agents and mobile
   nodes whenever they do exist.

   Note that the mobile node can only rarely verify the identity of
   the foreign agent in any absolute terms.  It can only act on the
   presumption that the foreign agent is performing its duties by
   correct adherence to protocol.  The exact identity of the foreign
   agent is not crucial to the process of establishing a registration
   key.  Only an agreement to follow protocol can be expected or
   enforced.  If the mobile node has a way to obtain a certified public
   key for the foreign agent, then the identity may be established in a
   firmer fashion, but the needed public key infrastructure seems to be
   at least five years distant.  Therefore, the methods in this document
   enable a mobile node to create a registration key with an anonymous
   foreign agent (i.e., one whose identity we cannot establish) during
   the registration process.  There are several proposed methods for
   establishing a registration key, discussed in order of declining




Perkins and Johnson             Expires 20 May 1998             [Page 2]


Internet Draft            Registration Keys             20 November 1997


   preference.  Other methods of establishing keys may become available
   in the future.

    1. If the foreign agent and mobile node share a security
       association, it can be used to secure the Previous Foreign Agent
       Notification without need to establish a registration key.

    2. If the home agent and foreign agent share a security association,
       the home agent can choose the new registration key.

    3. If the foreign agent has a public key, it can again use the home
       agent to supply a registration key.

    4. If the mobile node includes its public key in its Registration
       Request, the foreign agent can choose the new registration key.

    5. The mobile node and its foreign agent can execute a
       Diffie-Hellman key exchange protocol [2] as part of the
       registration protocol.

   Once the registration key is established, the method for performing
   smooth handoff seems natural.  The following sections give a
   brief overview of the above listed methods for establishing the
   registration key.

   If a request for key establishment cannot be accommodated by
   the foreign agent and/or the home agent, then the mobile node's
   key request must go unfulfilled.  This does not mean that the
   Registration Request itself fails, so it has no effect on the status
   code returned by the home agent to the mobile node.  The mobile node
   has to be able to handle the case in which it has requested a key but
   the Registration Reply arrives without any key reply extension.


3.1. The Home Agent as a KDC

   Crucial to methods (2) and (3) listed above is that the home agent
   and mobile node already are known to share a mobility security
   association, which can be used to encode the registration key for
   delivery to the mobile node.  Thus, if the home agent can securely
   deliver the key to the foreign agent, it can be used as a Key
   Distribution Center (KDC) for the mobile node and its new foreign
   agent.  The mobile node requests this by including a Registration
   Key Request extension in its Registration Request message.  When the
   home agent chooses the registration key, it sends it back in two
   different extensions to the Registration Reply.  One extension has
   the encrypted key for the foreign agent, and the other extension has
   the same key encrypted differently for the mobile node.




Perkins and Johnson             Expires 20 May 1998             [Page 3]


Internet Draft            Registration Keys             20 November 1997


   For the registration key to be established using this method, the
   home agent must be able to securely transmit an encrypted copy of the
   registration key to the foreign agent.  This is straightforward if
   the foreign agent already has a mobility security association with
   the home agent.  If mobile nodes from some home network often visit a
   foreign agent, then the effort of creating such a mobility security
   association between that foreign agent and the home agent serving
   their home network may be worthwhile.

   Note that MD5 can be used here for the purpose of transmitting
   registration keys, secure against eavesdroppers.  The expression
               expr1 = MD5(secret | regrep | secret) XOR (key)
   (where regrep is the Registration Reply message payload, and XOR is
   exclusive-or) can be included within the appropriate Registration
   Reply extension and encodes the key in a way which allows recovery
   only by the recipient.  It is secure against replay because of the
   identification field within the Registration Reply message.  The
   recipient recovers the key by computing
                    expr2== MD5(secret | regrep | secret)
   which then yields key = expr1XOR expr2.  Use of MD5 avoids
   entanglements with the legal issues surrounding the export of
   encryption technology, and reducing the computational power needed to
   secure the password against eavesdroppers.

   If no such mobility security association exists, but the foreign
   agent has a public key available, it can still ask the home agent to
   use it to pick a registration key.  This is preferable than asking
   the mobile node to pick a good registration key, because doing so
   may depend upon using resources not available to all mobile nodes.
   Just selecting pseudo-random numbers is by itself a significant
   computational burden.  Moreover, allowing the home agent to pick the
   key fits well into the existing registration procedures.  On the
   other hand, it is possible that a mobile node could do with less than
   perfect pseudo-random numbers as long as the registration key were to
   be used in the restricted fashion envisioned for smooth handoffs.


3.2. Using the Foreign Agent as a KDC

   When the foreign agent and mobile node share a mobility security
   association, there is no need to pick a registration key.  The mobile
   node can secure its Binding Update to the foreign agent whenever it
   needs to, by using the existing security association.  This is the
   most desirable case.

   Otherwise, if available, the mobile node can include its public key
   (such as RSA [8]) in its Registration Request to the foreign agent,
   using a mobile node public key extension.  The foreign agent chooses
   the new registration key and returns a copy of it encrypted with the



Perkins and Johnson             Expires 20 May 1998             [Page 4]


Internet Draft            Registration Keys             20 November 1997


   mobile node's public key, using a foreign-mobile registration key
   reply extension.


3.3. Using Diffie-Hellman with the Foreign Agent

   The Diffie-Hellman key-exchange algorithm [2] can be used.
   Diffie-Hellman is a public key cryptosystem that allows two parties
   to establish a shared secret key, such that the shared secret key
   cannot be determined by other parties overhearing the messages
   exchanged during the algorithm.  It is already used, for example, in
   other protocols that require a key exchange, such as in the Cellular
   Digital Packet Data (CDPD) system [1].

   This technique is known to suffer from a man-in-the-middle attack.
   In other words, a malicious agent could pretend to the foreign agent
   to be the mobile node, and pretend to the mobile node to be the
   foreign agent, and participate as an unwanted third member in the
   key exchange.  Armed with knowledge of the registration key, the
   malicious agent could at a later time disrupt the smooth handoff, or
   initiate the handoff prematurely.  The man-in-the-middle attack is no
   worse than a malicious agent pretending to be a foreign agent in any
   other circumstance; that is, it is no worse than already exists with
   the base Mobile IP specification [7].  In route optimization, the
   man-in-the-middle attack is prevented in most circumstances because
   each registration key produced by the techniques in this chapter is
   effectively authenticated by the home agent.

   If Diffie-Hellman were not computationally expensive, it could
   likely serve the needs of many mobile nodes.  Diffie-Hellman results
   are authenticated by the home agent to frustrate man-in-the-middle
   attacks.  Moreover, the mobile node and/or the foreign agent are
   presumably in direct contact, so that such an attack is detectable if
   either of the nodes notices the reception of duplicate packets, and
   corrective action taken.

   But, the algorithm itself uses exponentiations involving numbers
   with hundreds of digits.  That may take a long time for some mobile
   nodes to do, time which would come at the expense of interactivity
   or convenient operation of user application programs.  For this
   reason, Diffie-Hellman is considered the least desirable alternative
   for establishing registration keys.  Since it requires no other
   configuration, it is nevertheless required in all implementations of
   foreign agents that advertise support for smooth handoffs.

   Briefly, the Diffie-Hellman algorithm involves the use of two large
   public numbers, a prime number (p) and a generator (g).  The prime
   number and the generator must be known by both parties involved
   in the algorithm, but do not have to be secret; these values may



Perkins and Johnson             Expires 20 May 1998             [Page 5]


Internet Draft            Registration Keys             20 November 1997


   be the same or different for each execution of the algorithm and
   are not used once the algorithm completes.  Each party chooses a
   private random number, produces a computed value based on this random
   number, the prime and the generator, and sends the computed value in
   a message to the other party.  The computed value is the number g**x
   mod p, where x is the private random number, p is the prime which is
   sent as part of the transaction, and g is the generator.  Each party
   then computes the (same) shared secret key using its own private
   random number, the computed value received from the other party, and
   the prime and generator values.  The shared secret is the number c**y
   mod p, where c is the computed value which uses the other party's
   private number, p is the same as before, and y is the receiver's
   private number.  Since (g**x)**y == (g**y)**x, and since knowing the
   computed values mod p does not enable passive listeners to determine
   the private values, the algorithm allows the two parties to agree on
   an otherwise undetectable secret.

   To use this algorithm during registration with a foreign agent, the
   mobile node includes a Registration Key Request extension in its
   Registration Request message, containing its nonzero values for
   the prime and generator, along with the computed value from its
   own private random number.  If no other strategy is available, the
   foreign agent then chooses its own private random number and includes
   a Diffie-Hellman Registration Key Reply extension in its Registration
   Reply message to the mobile node; the extension includes the foreign
   agent's own computed value based on its chosen random number and the
   supplied prime and generator values from the mobile node.  The mobile
   node and foreign agent each independently form the (same) shared
   secret key from their own chosen random number, the computed value
   supplied by the other party, and the prime and generator values.

   Establishing a registration key using Diffie-Hellman is
   computationally more expensive than most methods described in
   Section 3.  The use of Diffie-Hellman described here, though, is
   designed to allow the Diffie-Hellman computations to be overlapped
   with other activities.  The mobile node may choose (or be manually
   configured with) the prime and generator values at any time, or
   may use the same two values for a number of registrations.  The
   mobile node may also choose its private random number and calculate
   its computed value at any time.  For example, after completing
   one registration, the mobile node may choose the private random
   number for its next registration and begin the computation of
   its new computed value based on this random number, such that it
   has completed this computation before it is needed in its next
   registration.  Even more simply, the mobile node may use the
   same private random number and computed value for any number of
   registrations.  The foreign agent may choose its private random
   number and begin computation of its computed value based on this
   number as soon as it receives the mobile node's Registration Request



Perkins and Johnson             Expires 20 May 1998             [Page 6]


Internet Draft            Registration Keys             20 November 1997


   message, and need only complete this computation before it sends
   the matching Registration Reply message for the mobile node's
   registration.

   This could be extended to support other similar key exchange
   algorithms, either by adding a new request and reply extension for
   each, or by adding a field in the extensions to indicate which
   algorithm is to be used.  Diffie-Hellman currently seems the only
   obvious choice, though; an implementation is available in the free
   RSAREF toolkit from RSA Laboratories [5].


4. Messages Requesting A Registration Key

   The following extensions may be used by mobile nodes or foreign
   agents to request the establishment of a registration key.  See
   sections 6,7.2, and 8 for appropriate algorithms which allow each
   node to tailor the use of these extensions to most closely fit its
   configured requirements.

      113     Foreign Agent Key Request Extension
      114     Mobile Node Public Key Extension
      115     Foreign Agent Public Key Extension
      116     Diffie-Hellman Key Request Extension


4.1. Foreign Agent Key Request extension

   If the foreign agent receives a Registration Key Request from
   a mobile node, and it has a security association with the home
   agent, it may append the Foreign Agent Key Request extension to
   the Registration Request after the mobile-home authentication
   extension.  The home agent will use the SPI specified in the key
   request extension to encode the registration key in the subsequent
   Registration Reply message.  The format of the Foreign Agent Key
   Request extension is illustrated below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           SPI .....           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ... SPI (continued)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     113

      Length   4




Perkins and Johnson             Expires 20 May 1998             [Page 7]


Internet Draft            Registration Keys             20 November 1997


      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.


4.2. Mobile Node Public Key extension

   If the mobile node has a public key, it can ask its prospective
   foreign agent to choose a registration key, and to use the mobile
   node's public key to encode the chosen registration key.  No
   eavesdropper will be able to decode the registration key, even if
   it is broadcast to all entities with access to the network medium
   used by the mobile node.  If using the public key, the foreign
   agent should still include the selected key in the Registration
   Request before it goes to the home agent.  Then, the home agent can
   authenticate the selected encoded registration key as part of the
   Registration Reply message.  The format of the mobile node public key
   extension is as illustrated below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |MN Public Key ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ... Mobile Node Public Key, continued ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     114

      Length   The length (typically larger than 255) of the mobile
               node's public key


4.3. Foreign Agent Public Key extension

   The format of the foreign agent public key extension is as
   illustrated below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               |FA Public Key ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Foreign Agent Public Key (continued) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the foreign agent has a public key, it can ask the home agent to
   choose a registration key, and to use the foreign agent's public key



Perkins and Johnson             Expires 20 May 1998             [Page 8]


Internet Draft            Registration Keys             20 November 1997


   to encode the chosen registration key.  Then, the home agent can
   authenticate the selected encoded registration key as part of the
   Registration Reply message.

      Type     115

      Length   4 plus the length (typically larger than 255) of the
               foreign agent's public key

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Foreign Agent's Public Key

   The SPI is provided for the home agent to transcribe into the
   eventual Foreign Agent Public Key Reply extension to the Registration
   Reply message.


4.4. Registration Key Request Extension

   The Registration Key Request extension, illustrated below, may be
   included in a Registration Request message sent to a foreign agent.
   If the length of the parameters in the key request extension are all
   zero, then the mobile node is asking the foreign agent to supply a
   key by any means it has available except for Diffie-Hellman.

   If the lengths are nonzero, then the mobile node is enabling the
   foreign agent to also perform the Diffie-Hellman key exchange
   algorithm (as described in Section 3.3) if the other possible key
   establishment methods are not available.  The foreign agent should
   then select a good pseudo-random registration key, and include a
   Diffie-Hellman Registration Key Reply extension, in the Registration
   Request message sent to the home agent to complete the key exchange.
   The home agent will also include same extension in the Registration
   Reply sent to the mobile node, and then it will be authenticated as
   part of the reply message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |             Length            |   Prime ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ... Prime (continued) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Generator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Computed Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Perkins and Johnson             Expires 20 May 1998             [Page 9]


Internet Draft            Registration Keys             20 November 1997


      Type     116

      Length   3 times the length (in bytes) of each of prime,
               generator, and computed value.  The values prime,
               generator, and computed value must all be the same
               length, which must be a multiple of 8 bits.

      Prime    One of the two public numbers involved in the
               Diffie-Hellman key exchange algorithm.  The prime should
               be a large prime number.

      Generator
               One of the two public numbers involved in the
               Diffie-Hellman key exchange algorithm.  If p is the value
               of the prime used for this Diffie-Hellman exchange,
               the generator should be less than p, and should be a
               primitive root of p.

      Computed Value
               The public computed value from the mobile node for this
               Diffie-Hellman exchange.  The mobile node chooses a large
               random number, x.  If g is the value of the generator and
               p is the value of the prime, the computed value in the
               extension is g**x mod p.


5. Extensions to Supply A Registration Key

   The following extensions are used to supply a registration key to
   a requesting entity, either a foreign agent or a mobile node, and
   are the counterparts to corresponding extensions used to request
   registration keys that are described in the last section.

      120     Home-Mobile Key Reply Extension
      121     Foreign Agent Key Reply Extension
      122     Mobile Node Public Key Reply Extension
      123     Foreign Agent Public Key Reply Extension
      124     Diffie-Hellman Key Reply Extension
      125     SPI Extension


5.1. Home-Mobile Key Reply Extension

   The home-mobile key reply extension may be used in Registration Reply
   messages to send a registration key from the mobile node's home agent
   to the mobile node.  When used, the home agent is required to also
   include a key reply extension in the Registration Reply message,
   which gives a copy of the same key to the mobile node's new foreign
   agent.  The home-mobile key reply extension, illustrated below, is



Perkins and Johnson            Expires 20 May 1998             [Page 10]


Internet Draft            Registration Keys             20 November 1997


   authenticated along with the rest of the Registration Reply message,
   and thus no additional authenticator is included in the extension.
   The SPI used to encode the registration key may be different than the
   SPI used to authenticate the Registration Reply message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               | MN Enc. Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Mobile Node Encrypted Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     120

      Length   4 plus the length of the encrypted key for the mobile
               node

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Mobile Node Encrypted Key
               (variable length) The registration key, chosen by
               the home agent, encrypted under the mobility security
               association between the home agent and the mobile node.
               The same key must be sent, encrypted for the foreign
               agent in a foreign agent registration key extension in
               this Registration Reply message.


5.2. Foreign Agent Key Reply Extension

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               | FA Enc. Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Foreign Agent Encrypted Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The home-foreign registration key reply extension may be used in
   Registration Reply messages to send a registration key from the
   mobile node's home agent to the mobile node's new foreign agent.
   When used, the home agent is required to also include a home-mobile




Perkins and Johnson            Expires 20 May 1998             [Page 11]


Internet Draft            Registration Keys             20 November 1997


   registration key reply extension in the Registration Reply message,
   giving a copy of the same key to the mobile node.

      Type     121

      Length   4 plus the length of the encrypted foreign agent's key
               plus the length of the authenticator

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Foreign Agent Encrypted Key
               (variable length) The registration key, chosen by
               the home agent, encrypted under the mobility security
               association between the home agent and the foreign agent.

   The key which is sent in this extension must also be sent by the
   home agent to the mobile node, encoded for the mobile node in a
   mobile node registration key extension in the same Registration Reply
   message.

   Authentication of the key is performed by use of data within a HA-FA
   Authentication extension to the Registration Reply message which is
   required when the Foreign Agent Key Reply extension is used.  Replay
   protection is accomplished using the identification field in the
   Registration Request message, which is also used by the foreign agent
   to identify the pending registration data.


5.3. Mobile Node Public Key Reply Extension

   The Mobile Node Public Key Reply message is illustrated below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               | MN Enc. Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ... Mobile Node's Encoded Key (continued) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When the mobile node sends a Mobile Node Public Key Request to its
   prospective foreign agent, the foreign agent can immediately select
   a registration key.  The foreign agent encodes this registration key
   into the Mobile Node Public Key Reply extension to the Registration
   Request, along with an SPI for future reference.  The home agent
   subsequently transcribes the extension without change into the



Perkins and Johnson            Expires 20 May 1998             [Page 12]


Internet Draft            Registration Keys             20 November 1997


   Registration Reply message.  This procedure allows the mobile node to
   be protected against common man-in-the-middle attacks.

      Type     122

      Length   The length (in bytes) of the computed value.

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Mobile Node's Encoded Key
               The foreign agent chooses a suitable key, possibly a
               pseudo-random number, and encodes it using the mobile
               node's public key.


5.4. Foreign Agent Public Key Reply Extension

   In response to a foreign agent public key request extension, the home
   agent will select a registration key and encode it twice into two
   separate key reply extensions of the Registration Reply message.  The
   Foreign Agent Public Key Reply extension contains the registration
   key encoded with the public key of the foreign agent.

   The Foreign Agent Public Key Reply message is illustrated below.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               | FA Enc. Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ...Foreign Agent's Encoded Key (continued) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     123

      Length   4 plus the length (in bytes) of the Foreign Agent's
               Encoded Key.

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Foreign Agent's Encoded Key
               The foreign agent chooses a suitable pseudo-random
               number, and encodes it using the mobile node's public
               key.




Perkins and Johnson            Expires 20 May 1998             [Page 13]


Internet Draft            Registration Keys             20 November 1997


   The SPI, provided by the foreign agent for transcribing into this
   extension, is ultimately targeted for use by the mobile node.


5.5. Diffie-Hellman Key Reply Extension

   The Diffie-Hellman Registration Key Reply extension, illustrated
   below, should be included in a Registration Request message sent by
   a foreign agent to the home agent, when the following conditions are
   met:

    -  mobile node has included a Registration Key Request extension
       with nonzero prime and generator in its Registration Request
       message to the foreign agent, and

    -  the foreign agent has no public key or security association with
       the home agent or mobile node.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Length             |     SPI ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ... SPI (continued)               |Computed Val....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         ... Computed Value (continued) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     124

      Length   4 plus the length (in bytes) of the computed value.

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.

      Computed Value
               The foreign agent chooses a large random number, y.  If g
               is the value of the generator and p is the value of the
               prime, the computed value in the extension is gymod p.
               The values of the generator and prime, if nonzero, are
               taken from the Registration Key Request extension from
               the mobile node's Registration Request message.

   The foreign agent supplies a new SPI along with the new registration
   key, so that the new key will be useful in the same way as
   registration keys created by any other method.






Perkins and Johnson            Expires 20 May 1998             [Page 14]


Internet Draft            Registration Keys             20 November 1997


5.6. SPI Extension

   The SPI Extension is included in Registration Reply messages when
   needed to specify the SPI to be associated with the registration key.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           SPI .....           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ... SPI (continued)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     125

      Length   4 plus the length (in bytes) of the computed value.

      SPI      Security Parameters Index (4 bytes).  An opaque
               identifier.


6. Mobile Node Key Requests

   If the mobile node detects that its new foreign agent supports
   smooth handoffs, it may initiate that process with its previous
   foreign agent, as well as asking its new foreign agent to aid in
   supplying a registration key for the new registration.  The following
   code fragment illustrates a good algorithm for the mobile node
   to use during registration, to allow the maximum flexibility in
   the selection of the new registration key.  Any particular mobile
   node may be configured to use one, none, or any subset of the
   key establishment procedures made available as part of the Route
   Optimization protocol.

    if (got 'S' bit from advertisement) {
         if (have registration key with previous FA) {
                ;      /* append Previous Foreign Agent Notification */
         }
         /* Set up registration key */
         if (have security association with current FA) {
                ;      /* Don't need to create a registration key */
         }
         else if (have a public key) {
                ;      /* append MN Public Key request */
         }
         else if (want D-H exchange) {
                /* compute a value for prime p and generator g */
                /* use it and append MN Key request */
         }



Perkins and Johnson            Expires 20 May 1998             [Page 15]


Internet Draft            Registration Keys             20 November 1997


         else   /* append MN key request with null computed value, etc */
    }


   In this way, the mobile node can get a registration key whenever one
   is available by any mechanism specified in this document.


7. Miscellaneous Home Agent Operations

7.1. Receiving Registration Key Requests

   When the home agent receives a Registration Request message, an
   extension requesting a registration key (Section 4) may be present in
   the message, requesting the home agent to provide a registration key
   to the mobile node and its foreign agent, as described in Section 3.
   In that event, the home agent employs a good algorithm for producing
   random keys [3] and encrypts the result separately for use by the
   foreign agent and by the mobile node.  The chosen key is encrypted
   under the mobility security association shared between the home
   agent and the mobile node, and the encrypted key is placed in a
   home-mobile registration key reply extension (Section 5.1) in the
   Registration Reply message.  The same key also is encrypted under
   the mobility security association shared between the home agent and
   the foreign agent, and the encrypted key is placed in a home-foreign
   registration key reply extension (Section 5.2) in the Registration
   Reply message.  When the home agent transmits the Registration Reply
   message containing reply extensions to the foreign agent, the message
   has the overall structure as follows:

   -------------------------------------------------------------
   |IP|UDP| Reg-Reply| MN Key| FA Key| HA-MH Auth.| HA-FA Auth.|
   -------------------------------------------------------------

   The mobile node gets the registration key, typically encoded using an
   algorithm such as that described in Section 3.1.  The encoding of the
   foreign agent's copy of the key depends on the particular key request
   made by the foreign agent, and may depend upon the SPI specified
   along with the encoded key.  The HA-FA authentication extension is
   only included if the home agent and foreign agent share a mobility
   security association.

   If the home agent cannot satisfy a request to select a registration
   key, it MAY still satisfy the registration attempt.  In this case,
   the home agent returns a Registration Reply message indicating
   success, but does not include any key reply extension.






Perkins and Johnson            Expires 20 May 1998             [Page 16]


Internet Draft            Registration Keys             20 November 1997


7.2. Home Agent Supplying Registration Keys

   When the home agent receives a Registration Request message
   with registration key extensions, it usually performs one of two
   operations:

    -  select and encode a registration key for both the mobile node and
       the foreign agent, or

    -  transcribe the registration key already selected by the foreign
       agent into the appropriate extension to the Registration Reply
       message.

   Both operations ensure that the mobile node and home agent are
   dealing with the same foreign agent.

   When building the Registration Reply, the home agent should follow
   an algorithm such as the one illustrated below, to be as useful as
   possible for the range of registration key establishment scenarios
   that are possible given the current route optimization protocol.

        /* Set up registration key */
        if (Foreign Agent Key Request) { /* then have security assn.  */
               /* append MN Key Reply to Registration Reply */
               /* append FA key reply to Registration Reply */
        }
        else if ((have foreign agent public key) ||
                  (have FA Public Key Reply)) {
               /* append MN Key Reply to Registration Reply */
               /* append FA Public Key Reply to Registration Reply */
        }
        else {
               /* do nothing */
        }
        /* append mobile-home authentication extension at end */


8. Miscellaneous Foreign Agent Operations

   This section details various operational considerations important
   for foreign agents wishing to support smooth handoff, including
   algorithms for establishment of registration keys.


8.1. Foreign Agent Handling Key Requests

   The foreign agent, when it receives a request from a mobile node for
   a registration key, is faced with a variety of possible actions.  The
   action selected by the foreign agent depends on the resources it has



Perkins and Johnson            Expires 20 May 1998             [Page 17]


Internet Draft            Registration Keys             20 November 1997


   available.  The foreign agent typically attempts to reduce as much
   as possible the computational burden placed on the mobile node, but
   relies on the security association with the greatest cryptographic
   strength to encode the registration key.  Furthermore, if the foreign
   agent performs the key selection, it still supplies the encoded key
   in an extension to the Registration Request message, so that the
   process of registration will also have the effect of authenticating
   its choice of registration key to the mobile node.  This strategy
   reduces the opportunity for interlopers to mount man-in-the-middle
   attacks.

   The following code fragment, executed when the foreign agent receives
   a key request of some variety, exhibits an algorithm which may be
   useful for implementors of foreign agents.  The algorithm is supposed
   to be used when a foreign agent gets a Registration Request with one
   of the key request extensions included.

        if (Previous Foreign Agent Notification) {
               /* build the Binding Update and authentication extension */
        }

        /* Set up registration key */
        if (have security association with HA) {
               /* Append FA key request to Registration Request */
        }
        else if (have a public key) {
               /* append FA Public Key request to Registration Request */
        }
        else if (have mobile node's public key) {
               /* pick a good key */
               /* append FA Public Key Reply to Registration Request */
        }
        else if (want D-H exchange) {
               /* start the computation */
               /* append the result to the Registration Key Request */
        else {
               /* do nothing */
        }



9. Security Considerations

   Whenever the foreign agent is involved with the production of a
   registration key by use of the Diffie-Hellman algorithm, the process
   is susceptible to the "man-in-the-middle" attack, as detailed in
   Section 3.3.  This attack is not known to produce further difficulty,
   and susceptibility is already inherent in the operation of the base
   Mobile IP specification [7].  Attention to this detail is warranted



Perkins and Johnson            Expires 20 May 1998             [Page 18]


Internet Draft            Registration Keys             20 November 1997


   during any future changes to the Route Optimization protocol, and
   ways to reduce the risk of direct interest for inclusion into future
   revisions of this document.

   The calculation of the authentication data described in Section 3.1
   is specified to be the same as in the base Mobile IP document for
   ease of implementation.  There is a better method available (HMAC),
   specified in RFC 2104 [4].  If the base Mobile IP specification is
   updated to use HMAC, then this route optimization specification
   should also be updated similarly.

   Registration keys should typically NOT be used as master keys for
   producing other derived keys, because of the man-in-the-middle attack
   associated with unidentifiable foreign agents.


10. Summary

   In this document, we have presented the methods for establishing
   registration keys for use by mobile nodes and foreign agents
   supporting smooth handoffs.  The ways provided for the mobile node
   and foreign agent to obtain a registration key are as follows:

    -  Use the mobility security association they share if it exists

    -  Use the mobile node's public key if it exists

    -  Use the foreign agent's public key, if it exists, to enable the
       home agent to create public keys for both entities, or

    -  Use the security association between the foreign agent and home
       agent, if it exists, to enable the home agent to create the
       registration keys for both entities, or

    -  Use the Diffie-Hellman key exchange algorithm.


References

   [1] CDPD consortium.  Cellular Digital Packet Data Specification.
       P.O. Box 809320, Chicago, Illinois, July 1993.

   [2] W. Diffie and M. Hellman.  New Directions in Cryptography.  IEEE
       Transactions on Information Theory, 22:644--654, November 1976.

   [3] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller.
       Randomness Recommendations for Security.  RFC 1750, December
       1994.




Perkins and Johnson            Expires 20 May 1998             [Page 19]


Internet Draft            Registration Keys             20 November 1997


   [4] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
       for Message Authentication.  RFC 2104, February 1997.

   [5] RSA Laboratories.  Rsaref:  A cryptographic toolkit, version 2.0,
       1994.  http://www.consensus.com/rsaref/index.html.

   [6] Charles E. Perkins and David B. Johnson.  Route Optimization in
       Mobile-IP.  draft-ietf-mobileip-optim-06.txt, July 1997.  (work
       in progress).

   [7] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

   [8] Bruce Schneier.  Applied Cryptography:  Protocols, Algorithms,
       and Source Code in C.  John Wiley, New York, NY, USA, 1994.


Chairs' Addresses

   The working group can be contacted via the current chairs:

       Jim Solomon                         Erik Nordmark
       Motorola, Inc.                      Sun Microsystems, Inc.
       1301 E. Algonquin Road              901 San Antonio Road
       Schaumburg, IL 60196                Palo Alto, California 94303
       USA                                 USA

       Phone:  +1-847-576-2753             Phone:  +1 650 786-5166
       Fax:                                Fax:  +1 650 786-5896
       E-mail:  solomon@comm.mot.com       E-mail:  nordmark@sun.com


   Questions about this document can also be directed to the authors:

       Charles E. Perkins                  David B. Johnson
       Technology Development Group        Computer Science Department
       Mail Stop MPK15-214
       Room 2682
       Sun Microsystems, Inc.              Carnegie Mellon University
       901 San Antonio Road                5000 Forbes Avenue
       Palo Alto, California 94303         Pittsburgh, PA 15213-3891
       USA                                 USA
       Phone:  +1-650-786-6464             Phone:  +1-412-268-7399
       Fax:  +1-650-786-6445               Fax:  +1-412-268-5576
       E-mail:  charles.perkins@Sun.COM    E-mail:  dbj@cs.cmu.edu







Perkins and Johnson            Expires 20 May 1998             [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/