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

Versions: 00 01 02 03

Mobile IP Working Group                               Charles E. Perkins
INTERNET DRAFT                                     Nokia Research Center
27 February 2000                                        David B. Johnson
                                              Carnegie Mellon University



                Registration Keys for Route Optimization
                   draft-ietf-mobileip-regkey-01.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@STANDARDS.NORTELNETWORKS.COM mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.


Abstract

   Route optimization defines extensions to Mobile IP 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 27 August 2000            [Page i]


Internet Draft            Registration Keys             27 February 2000




                                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 . . . . . . . . . . . . . . . . .    4
     3.2. Using the Foreign Agent as a KDC  . . . . . . . . . . . .    5

 4. Registration Key Request Extension Subtypes                        5
     4.1. Registration Key Request Subtype  . . . . . . . . . . . .    7
     4.2. Foreign Agent Registration Key Request Subtype  . . . . .    7
     4.3. Mobile Node Request Via Public Key Subtype  . . . . . . .    8
     4.4. Foreign Agent Public Key Request Subtype  . . . . . . . .    8
     4.5. Diffie-Hellman Registration Key Request Subtype . . . . .    8
     4.6. Diffie-Hellman Elliptic Curve Registration Key Request  .    9

 5. Generalized MN-FA Key Reply Subtypes                              10
     5.1. Registration Key Reply from Home Agent Subtype  . . . . .   11
     5.2. Mobile Node Public Key Reply Subtype  . . . . . . . . . .   11
     5.3. Foreign Agent Public Key Reply Subtype  . . . . . . . . .   12
     5.4. Diffie-Hellman Key Reply Subtype  . . . . . . . . . . . .   12

 6. Mobile Node Key Requests                                          13

 7. Miscellaneous Home Agent Operations                               14
     7.1. Receiving Registration Key Requests . . . . . . . . . . .   14
     7.2. Diffie-Hellman Considerations . . . . . . . . . . . . . .   15
     7.3. Home Agent Supplying Registration Keys  . . . . . . . . .   16

 8. Miscellaneous Foreign Agent Operations                            17
     8.1. Foreign Agent Handling Key Requests . . . . . . . . . . .   17
     8.2. Advertising Digestified Diffie-Hellman Computations . . .   19

 9. Security Considerations                                           19

References                                                            20

 A. Using Diffie-Hellman with the Foreign Agent                       21

 B. Diffie-Hellman Key Exchange in the Field of Integers mod p        23



Perkins and Johnson           Expires 27 August 2000           [Page ii]


Internet Draft            Registration Keys             27 February 2000


 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups              23

Addresses                                                             26


1. Introduction

   The Binding Update is a Route Optimization [12] message that
   changes the routing of IP datagrams to the mobile node.  It can
   be authenticated using mechanisms similar to those specified for
   the base Mobile IP protocol [11].  The authentication relies on
   a mobility security association established in advance between
   the sender and receiver of such messages.  The Binding Update
   message can be used to accomplish a smooth handoff for a mobile node
   moving from a previous foreign agent to a new foreign agent.  Such
   smooth handoffs rely on the Previous Foreign Agent Notification
   extension [12], which requires the transmission of a Binding Update
   to the previous foreign agent created by the mobile node after
   it moves.  However, when a mobile node registers with a foreign
   agent, typically it does not share a security association with the
   foreign agent.  In order for the foreign agent to process future
   Binding Updates that it may receive from the mobile node, it needs to
   establish such a security association.

   This document is a specification for some useful methods for
   establishing the necessary mobility security association between the
   mobile node and its new foreign agent.


2. Terminology

   This document makes use of many terms defined in RFC 2002 [11] to
   describe the base Mobile IP protocol, as well as terms defined in
   the specification for Route Optimization [12].  In addition, the
   following terms are used:

      Binding cache

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

      Field Element

         an element of one of the fields used to define the
         Diffie-Hellman key exchange extensions.  This usage must be
         carefully distinguished from the use of the word "field" to
         denote a designated part of the data for a protocol unit.





Perkins and Johnson           Expires 27 August 2000            [Page 1]


Internet Draft            Registration Keys             27 February 2000


      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.  The
         registration key forms the basis for the mobility security
         association needed between the mobile node and the 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
         lifetime is still valid, at some time after the registration
         was approved by the home agent.

      Triangle Routing

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

   In formulas requiring exponentiation, the `^' character is used.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].


3. Establishing Registration Keys

   Foreign agents may become 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.



Perkins and Johnson           Expires 27 August 2000            [Page 2]


Internet Draft            Registration Keys             27 February 2000


   Note that the mobile node may often be unable to verify the identity
   of the foreign agent.  It must then act only 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 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 mobile node can transfer key information between foreign
       agents that trust each other, it can use the same key as it had
       used with its previous foreign agent [2].

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

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

    6. The mobile node and its foreign agent can execute a
       Diffie-Hellman key exchange protocol [5], using the method
       for elliptic curves [7, 9], or using the more familiar method
       involving exponentiations.

   Once the registration key is established, the smooth handoff method
   can be used [12].  The following sections give a brief overview of
   the above enumerated 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 the same status code will be
   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.



Perkins and Johnson           Expires 27 August 2000            [Page 3]


Internet Draft            Registration Keys             27 February 2000


   This could happen even when the foreign agent has advertised its
   willingness to offer smooth handoffs, and the mobile node has
   supplied all the necessary parameters.  The effect will likely be a
   less than smooth handover.


3.1. The Home Agent as a KDC

   Crucial to methods (2) and (4) 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 returns the key 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.

   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.

   If the home agent does not have such a mobility security association,
   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; simply 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 conceivable 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.

   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)





Perkins and Johnson           Expires 27 August 2000            [Page 4]


Internet Draft            Registration Keys             27 February 2000


   (where regrep is the Registration Reply message payload up to but
   not including the encoded key data, and XOR is exclusive-or) can be
   included within the appropriate Registration Reply extension.  This
   encodes the key in a way which allows recovery only by the recipient.
   It is secure against replay because of the Identification within
   the Registration Reply message.  The recipient recovers the key by
   computing

      expr2 == MD5(secret | regrep | secret)

   which then yields (key == expr1 XOR 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.


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 [14]) in its Registration Request to the foreign agent,
   using a Mobile Node Public Key Request extension (see section 4.3).
   The foreign agent chooses the new registration key and includes a
   copy of it encrypted with the mobile node's public key, using a
   Foreign-Mobile Public Key Reply extension (see section 5.3).  This is
   sent to the home agent for inclusion with the Registration Reply.


4. Registration Key Request Extension Subtypes

   A Generalized MN-FA Key Request extension has been specified [13].
   This generalized extension contains the SPI that the mobile node
   wishes to use with the registration key.  Thus, it is guaranteed that
   the SPI will not collide with another existing Mobility Security
   Association already in place for the mobile node.

   To simplify the discussion for protocol operations involving a
   particular subtype, the generalized extension with a particular
   subtype will typically be denoted as a specific extension, instead of
   a generalized extension with a specific subtype.  So, for instance,
   there will be discussion using the terminology "Registration Key
   Request extension", which should be interpreted to mean "Generalized
   Key Request extension with subtype 1".  Note that a key requested by
   any subtype of this Generalized Registration Key Request extension



Perkins and Johnson           Expires 27 August 2000            [Page 5]


Internet Draft            Registration Keys             27 February 2000


   is, by definition, for use between the mobile node and the foreign
   agent handling its Mobile IP Registration Request.  The foreign
   agent stores the SPI from the registration key request extension
   sent by the mobile node as part of its pending registration request
   information.  The SPI will be needed if the registration key reply
   extension is returned in the Registration Reply message from the home
   agent.

   In this document, the following subtypes of the Generalized MN-FA Key
   extension are defined:

    1. Registration Key Request subtype (see section 4.1)

    2. Foreign Agent Registration Key Request subtype (see section 4.2)

    3. Mobile Node Request Via Public Key subtype (see section 4.3)

    4. Foreign Agent Public Key Request subtype (see section 4.4)

    5. Diffie-Hellman Registration Key Request subtype (see section 4.5)

    6. Diffie-Hellman Elliptic Curve Registration Key Request extension
       (see section 4.6)

   Handling for these subtypes is specified in this section.  These
   may be used by mobile nodes or foreign agents to request the
   establishment of a registration key.  For each subtype, the MN-FA
   Key Request Subtype Data of the Generalized Key Request extension
   has to be specified.  In this section, the MN-FA Key Request
   Subtype Data will generally be referred as "the subtype data".  See
   sections 6, 7.3, and 8 for appropriate algorithms which allow each
   node to use the extensions that most closely fit its configured
   requirements.

   There are two Diffie-Hellman Key Request subtypes that may be
   included by a foreign agent in a Registration Request message sent
   to a home agent, if the other possible key establishment methods are
   not available.  For either subtype, the foreign agent should then
   select a good pseudo-random registration key.  The foreign agent
   initiates the Diffie-Hellman key exchange algorithm (as described in
   Appendix A), and includes a Diffie-Hellman Registration Key Request
   extension in the Registration Request message sent to the home agent
   to initiate the key exchange.  The home agent will then complete the
   key exchange and include the computed value in the Diffie-Hellman
   Registration Key Reply extension in the Registration Reply sent to
   the mobile node, where that extension can be authenticated as part of
   the reply message.





Perkins and Johnson           Expires 27 August 2000            [Page 6]


Internet Draft            Registration Keys             27 February 2000


   The two Diffie-Hellman key request subtypes differ in the creation
   and processing of the Computed Value which appears in the subtype
   data.

      Note that I am not certain that the name "Diffie-Hellman"
      applies to key exchanges using elliptic curve groups.


4.1. Registration Key Request Subtype

   The Registration Key Request subtype may be included in a
   Registration Request to ask the foreign agent to supply a key by
   any means it has available.  The foreign agent may have a public
   key, or it might have a security association with the home agent.
   Otherwise, the foreign agent will attempt to employ a Diffie-Hellman
   key exchange.

   If the foreign agent has advertised a Challenge value, and also
   sets the `S' bit in its Agent Advertisements, then the mobile node
   MUST include that Challenge value in its registration request [3].
   Furthermore, in this case, the Challenge value represents a digested
   form of the next value that would be used, if needed, by the foreign
   agent in its next key exchange with a home agent.  Thus, if the
   foreign agent sets the `S' bit but does NOT include a Challenge
   value, the mobile node cannot be certain that the foreign agent is
   taking steps to protect against the man-in-the-middle attack that can
   sometimes be mounted against Diffie-Hellman key exchanges.  While
   this is normally not an issue for registration keys, some mobile
   nodes MAY be configured to avoid using the Registration Key Request
   extension when the foreign agent does not advertise the Challenge
   value.

   For this extension, the subtype data is empty.


4.2. Foreign Agent Registration Key Request Subtype

   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 select a registration key and append the Foreign Agent
   Registration Key Request extension to the Registration Request after
   the mobile-home authentication extension.  For this extension, the
   SPI in the Generalized Key Request extension refers to the SPI of the
   security association between the home agent and the foreign agent.

   For this extension, the subtype data is the key selected by
   the foreign agent and encoded according to the FA-HA security
   association.




Perkins and Johnson           Expires 27 August 2000            [Page 7]


Internet Draft            Registration Keys             27 February 2000


4.3. Mobile Node Request Via Public Key Subtype

   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 the
   encoded key is broadcast to all entities with access to the network
   medium used by the mobile node.  The foreign agent then includes the
   encoded registration key in a Mobile Node Public Key Reply extension
   (see section 5.2) to the Registration Request as it goes to the home
   agent.  Then, the home agent can authenticate the selected encoded
   registration key as part of the Registration Reply message.

   For the Mobile Node Request Via Public Key subtype, the subtype data
   contains the mobile node's public key.


4.4. Foreign Agent Public Key Request Subtype

   If the foreign agent has a public key, it can ask the mobile node's
   home agent to choose a registration key, and then to use the foreign
   agent's public key to encode the chosen registration key.  As before,
   no eavesdropper will be able to decode the registration key, even
   if the encoded key is broadcast to all entities with access to
   the network medium used by the home agent and the foreign agent.
   The home agent then includes the encoded registration key in a
   Foreign Agent Public Key Reply extension (see section 5.3) to the
   Registration Reply.

   For the Foreign Agent Public Key subtype, the subtype data contains
   the foreign agent's public key.


4.5. Diffie-Hellman Registration Key Request Subtype

   The foreign agent may send the Diffie-Hellman Registration
   Key Request extension to initiate key exchange by use of the
   exponentiation algorithm in the field of integers mod p, as described
   in Appendix A.  To initiate the key exchange the foreign agent
   chooses a large random number, N. If g is the value of the generator
   and p is the value of the prime, the computed value in the extension
   is g^N mod p.  See appendix B for details on the algorithm.

   The foreign agent then appends the extension to the Registration
   Request message, containing the values for the prime and generator,
   along with the computed value (F) from its own private random number
   N. The home agent will then choose its own private random number
   M and creates its own computed value (H). The foreign agent will
   complete the key exchange by extracting the home agent's computed



Perkins and Johnson           Expires 27 August 2000            [Page 8]


Internet Draft            Registration Keys             27 February 2000


   value H from the Diffie-Hellman Registration Key Reply extension in
   the registration request.

   The format of the subtype data contained in this 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Prime  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Generator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Computed Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Generator
               The other public number 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 [14] of p.

      Computed Value
               The public computed value from the foreign agent for this
               Diffie-Hellman exchange.

   The values indicated for the prime, generator, and computed value are
   all the same length, which must be a integral number of bytes.


4.6. Diffie-Hellman Elliptic Curve Registration Key Request

   All foreign agents that support smooth handovers SHOULD support the
   Diffie-Hellman Elliptic Curve Registration Key Request.

   To initiate the key exchange the foreign agent chooses a large random
   number, N. If the generating point is (X,Y), then the computed value
   is N*(X,Y), where the integer multiplication is accomplished by
   adding the point to itself N times.  The algorithm for adding points
   in the elliptic curve group is given in section C.  The default value
   for the generating point (X,Y) is (24,13).  Note that for any point
   (X,Y) in the elliptic curve group, both X and Y are elements of the
   underlying field, which in the default case specified below will be
   the Galois Field GF[2^185].



Perkins and Johnson           Expires 27 August 2000            [Page 9]


Internet Draft            Registration Keys             27 February 2000


   The foreign agent then inserts the extension in the Registration
   Request message, containing the values for the prime and generator,
   along with the computed value (F) from its own private random number
   N. The home agent will then choose its own private random number and
   creates its own computed value (H). The foreign agent will complete
   the key exchange by extracting the home agent's computed value H
   from the Diffie-Hellman Registration Key Reply extension in the
   registration request.

   The format of the subtype data contained in this 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Y0      |     First Coordinate of (V,W) = N*(X,Y) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Y0       Either 02 or 03, depending upon the least significant bit
               of the computed value N*(X,Y)

      First Coordinate of (V,W) = N*(X,Y)
               If the chosen random number is N, and the chosen
               generator is (X,Y), and if (V,W) = N*(X,Y), then this
               value is V.

   See section C for details about the computation of N*(X,Y), its
   compressed representation as illustrated above, and recovery of
   N*(X,Y) given this compressed representation.


5. Generalized MN-FA Key Reply Subtypes

   Key reply extensions in this document are subtypes of the Generalized
   MN-FA Key Reply extension [13].

   The following subtypes are defined:

    1. Registration Key Reply from Home Agent
    2. Mobile Node Public Key Reply
    3. Foreign Agent Public Key Reply
    4. Diffie-Hellman Key Reply

   For each subtype, the format of the MN-FA Key Reply Subtype Data
   has to be separately defined according to the particular method
   required to set up the security association.  In this section, the
   term "subtype data" refers to the MN-FA Key Reply Subtype Data of the
   Generalized MN-FA Key Reply extension.




Perkins and Johnson           Expires 27 August 2000           [Page 10]


Internet Draft            Registration Keys             27 February 2000


   For the subtypes specified in this document, the Registration Key
   supplied in the subtype data comes as a result of a request which was
   sent using a subtype of the Generalized MN-FA Key Request Extension.
   The SPI to be used when employing the security association defined by
   the registration key is supplied in the original request.

   The keys obtained by the mobile node from the Key Reply extension
   subtypes defined in this document are expected to remain valid for as
   long as the mobile node continuously uses the same care-of address.
   The purpose of the registration key is to facilitate smooth handoffs,
   as well as secure subsequent registrations.  Since it would typically
   take a huge number of encryptions with the same registration key for
   an attacker to gain enough information to compromise the key, such
   intended uses are unlikely to make the registration key insecure.
   Similarly, the mobile node is unlikely to use the same registration
   key for enough registrations to make the single smooth handover
   insecure.  Thus, the registration key does not need to have any
   particular lifetime unless it is used for purposes of data hiding in
   addition to registration and smooth handover.


5.1. Registration Key Reply from Home Agent Subtype

   The home agent uses the Registration Key Reply from Home Agent
   extension in Registration Reply messages to securely deliver a
   registration key to the mobile node.  For this extension, the
   subtype data is the registration key encoded using the SPI in the
   Registration Reply.  The method used is specified in section 3.1,
   where the registration reply payload used in the encoding includes
   all the data up to and including the SPI field in the Generalized
   Key Reply extension for which this is a subtype.  This key reply
   extension is authenticated along with the rest of the Registration
   Reply message, and thus no additional authenticator is included in
   the extension.

   The home agent SHOULD also include another key reply extension which
   delivers the same key to the mobile node's new foreign agent.


5.2. Mobile Node Public Key Reply Subtype

   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.  The foreign agent also stores the key and the SPI from
   the Mobile Node Public Key Request for future reference as a
   potential security association with the mobile node.  The home agent
   subsequently transcribes this extension without change into the



Perkins and Johnson           Expires 27 August 2000           [Page 11]


Internet Draft            Registration Keys             27 February 2000


   Registration Reply message.  Thus, the mobile node is protected
   against common man-in-the-middle attacks.

   The subtype data for this subtype is the Registration Key encoded by
   using the mobile node's public key.


5.3. Foreign Agent Public Key Reply Subtype

   This extension is sent in response to a Foreign Agent Public Key
   Request extension.  The home agent selects a registration key and
   encodes 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 also stores the SPI from the registration key
   request extension sent by the mobile node, for future reference
   as a potential security association with the mobile node if the
   registration is successful.

   The subtype data for this extension is the Registration Key encoded
   by using the foreign agent's public key.


5.4. Diffie-Hellman Key Reply Subtype

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

    -  the mobile node has included a Registration Key Request extension
       in its registration request message,

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

    -  the foreign agent has included one of the Diffie-Hellman
       Registration Key Request extensions in its Registration Request
       message to the home agent (see sections 4.5 and 4.6).

   The home agent uses the same reply extension subtype (namely, the
   Diffie-Hellman Key Reply subtype), in response to either of the
   Diffie-Hellman key exchange request messages.

   The subtype data for the Diffie-Hellman Registration Key Reply
   extension, is just the Computed Value resulting from the requested
   Diffie-Hellman computation.




Perkins and Johnson           Expires 27 August 2000           [Page 12]


Internet Draft            Registration Keys             27 February 2000


6. Mobile Node Key Requests

   If the mobile node receives an Agent Advertisement from a foreign
   agent with the `S' bit set, the mobile node may attempt a smooth
   handoff 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
   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 specified in this
   document.

   The Mobile Node executes the following algorithm upon new FA
   registration.  This algorithm is intended to reduce complexity at
   the mobile node.  But, the Home Agent MAY require that the mobile
   node use Public Key if required by the policy of the home domain
   administration, instead of relying on other means for generating
   keys.

































Perkins and Johnson           Expires 27 August 2000           [Page 13]


Internet Draft            Registration Keys             27 February 2000


    If (Challenge advertised) {
         Add challenge data to Registration Request
         /* If NewFA uses Elliptic, challenge is MD5 (N*(X,Y)) */
    }
    If (NewFA advertises 'S') {
         if (have registration key with previous FA) {
                /* append Previous Foreign Agent Notification (PFAN) */
                If (received opaque-data) { /* See [2] */
                       append opaque-data extension after PFAN;
                }
         }
         if (have security association with current FA) {
                ;      /* Don't need to create a registration key */
         }
         else if (HA expects Public Key) {
                Add public key extension; /* FA will choose key */
         }
         else if (opaque-data || SA with NewFA) {
                create MN-FA extension;
         }
         else {
                Send Registration Key Extension; /* Let them do it */
         }
    }


   In this way, the mobile node can get a registration key whenever one
   can be produced 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.  Then the home agent is expected to provide a
   registration key to the mobile node and its foreign agent, as
   described in Section 3.  When needed, the home agent employs a good
   algorithm for producing random keys [6] and encrypts the result
   separately for use by the foreign agent and by the mobile node.
   The chosen key is encoded under the mobility security association
   shared between the home agent and the mobile node as described in
   section 3.1.  The regrep data used as part of the encoding includes
   all the preceding Registration Reply data up to and including the
   Length field of the Generalized MN-FA Reply extension for which the
   Registration Key Reply is the subtype.  The encrypted key is the
   placed as the Subtype Data of the Registration Key Reply from Home
   Agent extension (section 5.1) in the Registration Reply message.



Perkins and Johnson           Expires 27 August 2000           [Page 14]


Internet Draft            Registration Keys             27 February 2000


   The same key may also be encrypted under the mobility security
   association shared between the home agent and the foreign agent,
   and the encoding placed in a registration key reply extension 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| MN-HA Auth.| HA-FA Auth.|
     -------------------------------------------------------------
   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, but the other Mobile IP registration requirements are fulfilled,
   it MAY still approve the registration reply.  In this case, the home
   agent returns a Registration Reply message Code indicating success,
   but does not include any key reply extension.


7.2. Diffie-Hellman Considerations

   If the home agent receives one of the Diffie-Hellman key request
   extensions, (see sections 4.5 and 4.6), then it has to pick a good
   random number [6] and use it to complete the key exchange algorithm.
   Suppose the home agent picks the random number Z. Then the home agent
   applies the group operation Z times on the data received from the
   foreign agent, which amounts to either exponentiation to the Zth
   power, or else (in the elliptic case) to multiplication by Z of the
   incoming solution point.  The result of this operation gives the
   registration key, which is then encoded in a Registration Key Reply
   from Home Agent extension and sent to the mobile node.

   In order to deliver the registration key to the foreign agent, the
   home agent takes the same number Z and applies it to the generator
   (or, in the elliptic case, the generating point).  The result of
   that operation is placed in a Diffie-Hellman Key Reply extension and
   sent to the foreign agent so that the foreign agent can compute the
   registration key.

   When a home agent receives one of the Diffie-Hellman Key Request
   subtypes along with a Challenge extension, the Challenge Value MUST
   be checked against the computed value selected by the foreign agent.
   The rule by which the computed value is to be checked is described in
   section 8.2.








Perkins and Johnson           Expires 27 August 2000           [Page 15]


Internet Draft            Registration Keys             27 February 2000


7.3. 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.  Whenever the home agent inserts
   one of the following key reply extensions in the Registration Reply,

    1. Registration Key Reply from Home Agent
    2. Mobile Node Public Key Reply
    3. Foreign Agent Public Key Reply

   each key reply extension MUST precede the MN-HA Authentication
   Extension.  The Diffie-Hellman Key Reply, on the other hand, is
   consumed by the foreign agent, and SHOULD be located after the MN-HA
   Authentication Extension whenever the Challenge value is supplied
   with the Registration Request message.  The Challenge value is
   typically sufficient to protect against man-in-the-middle attacks.

   When building the Registration Reply, the home agent should follow
   an algorithm such as the one illustrated below, which is useful for
   the registration key establishment methods currently specified.  The
   underlying theme of the algorithm is that the home agent just does as
   it is told.



















Perkins and Johnson           Expires 27 August 2000           [Page 16]


Internet Draft            Registration Keys             27 February 2000


        if (Foreign Agent Reg.  Key Request) { /* HA-FA assn_exists */
               /* Pick a key, encode for FA */
               /* append MN Key Reply to Registration Reply */
               /* append FA key reply to Registration Reply */
        }
        If (MN public key) {
               /* Transcribe the encoded key */
               /* append MN Key Reply to Registration Reply */
        }
        If (FA public key) {
               /* Pick a key, encode for FA */
               /* append MN Key Reply to Registration Reply */
               /* append FA Public Key Reply to Registration Reply */
        }
        If (elliptic) {
               /* Pick multiplier `Z', do the D-H algorithm */
        }
        else {
               /* do nothing */
        }
        /* append mobile-home authentication extension at end */

        /* Encode the key for the MN if necessary, use existing SPI */
        /* New registration key will then be invoked by SPI from */
        /* key request extension.  */



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
   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 sufficient 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 home
   agent will authenticate its choice of registration key to the mobile
   node.  This strategy reduces the opportunity for interlopers to mount
   man-in-the-middle attacks.



Perkins and Johnson           Expires 27 August 2000           [Page 17]


Internet Draft            Registration Keys             27 February 2000


   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.  The foreign agent uses
   the elliptic curve Diffie-Hellman key exchange as a last resort,
   with implicit well-known parameters (X-coordinate, Y-coordinate,
   Extension-Field), picking multiplier `N'.

    If (opaque-data) {
           /* extract key/replay protection */
           /* check against replays */
           /* drop registration unless opaque-data passes check */
    }

    if (Previous Foreign Agent Notification (PFAN)) {
           /* Formulate Binding Update */
           /* Send with Smooth Handoff Authentication Extension */
    }

    If (MN-FA authentication extension) {
           /* Verify before proceeding */
    }

    If (Registration Key Extension) {
           /* Set up registration key */
           if (have mobile node's public key) {
                  /* pick a good key */
                  /* append MN Public Key Reply to Reg.  Request */
           }
           If (opaque-data valid) {
                  /* Use old extension */
           }
           if (have security association with HA) {
                  /* Append FA key request to Registration Request */
           }
           If (FA public key) {
                  /* Send it; HA will pick key */
           }
           else {
                  /* pick elliptic point multiplier `N' */
                  /* append result to the Registration Key Request */
           }
    }








Perkins and Johnson           Expires 27 August 2000           [Page 18]


Internet Draft            Registration Keys             27 February 2000


8.2. Advertising Digestified Diffie-Hellman Computations

   When a foreign agent advertises the `S' bit, it is expected to
   support Diffie-Hellman key exchange with the home agent for those
   cases when the mobile node asks for a registration key, but no other
   means are available for producing registration keys.  In order to
   protect against man-in-the-middle attacks, the home agent and the
   mobile node need some way to make sure that they are dealing with
   the same foreign agent.  This can be accomplished by digestifying
   the Diffie-Hellman computed values, and advertising the digest as a
   Challenge Value for the mobile node.  The digest is produced by using
   MD5 on the computed value, with no other data prepended or appended.

   In order to reduce bandwidth requirements for this advertisement, the
   foreign agent MAY truncate the MD5 digest to as few as the initial
   4 bytes.  Since all of the bits of the MD5 digest are considered
   equally random, applying further operations (such as XOR) might even
   reduce the resulting cryptographic strength.


9. Security Considerations

   Whenever a key is exchanged by use of the Diffie-Hellman algorithm,
   the process is susceptible to the "man-in-the-middle" attack, as
   detailed in Appendix A.  This attack is not known to produce further
   difficulty, and susceptibility is already inherent in the operation
   of the base Mobile IP specification [11].  Attention to this detail
   is warranted during any future changes to the Route Optimization
   protocol.  Ways to reduce the risk should be incorporated into future
   revisions of this document.  Already, the risk of such an attack
   against the registration key distribution mechanisms specified in
   this document are greatly reduced by the authentication of the
   Registration Reply by the home agent.

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








Perkins and Johnson           Expires 27 August 2000           [Page 19]


Internet Draft            Registration Keys             27 February 2000


References

    [1] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [2] P. Calhoun, Haseeb Akhtar, Emad Qaddoura, and N. Asokan.
        Minimal Latency Secure Hand-off.
        draft-calhoun-mobileip-min-lat-handoff-01.txt, February 2000.
        (work in progress).

    [3] P. Calhoun and C. E. Perkins.  Mobile IP Foreign Agent
        Challenge/Response Extension.
        draft-ietf-mobileip-challenge-08.txt, January 2000.  (work in
        progress).

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

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

    [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller.  Randomness
        Recommendations for Security.  Request for Comments
        (Informational) 1750, Internet Engineering Task Force, December
        1994.

    [7] N. Koblitz.  Elliptic Curve Cryptosystems.  Mathematics of
        Computation, 48(177):203--209, 1987.

    [8] H. Krawczyk, M. Bellare, and R. Canetti.  HMAC: Keyed-Hashing
        for Message Authentication.  Request for Comments
        (Informational) 2104, Internet Engineering Task Force,
        February 1997.

    [9] V. S. Miller.  Use of Elliptic Curves in Cryptography.  In
        Advances in Cryptology -- CRYPTO '85 Proceedings, pages
        417--426, Berlin, 1986. Springer-Verlag.

   [10] H. Orman.  The OAKLEY Key Determination Protocol.  Request for
        Comments (Informational) 2412, Internet Engineering Task Force,
        November 1998.

   [11] C. Perkins.  IP Mobility Support.  Request for Comments
        (Proposed Standard) 2002, Internet Engineering Task Force,
        October 1996.






Perkins and Johnson           Expires 27 August 2000           [Page 20]


Internet Draft            Registration Keys             27 February 2000


   [12] C. Perkins and D. Johnson.  Route Optimization in Mobile IP.
        Internet Draft, Internet Engineering Task Force, February 1999.
        Work in progress.

   [13] Charles E. Perkins and Pat R. Calhoun.  Generalized Key
        Distribution Extensions for Mobile IP.
        draft-ietf-mobileip-gen-key-00.txt, February 2000.  (work in
        progress).

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

   [15] Richard Schroeppel, Hilarie Orman, and Sean OMalley.  Fast Key
        Exchange with Elliptic Curve Systems.  In Advances in Cryptology
        -- CRYPTO '95 Proceedings. Springer-Verlag, 1995.


A. Using Diffie-Hellman with the Foreign Agent

   Diffie-Hellman public key cryptosystems 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 used in other well-known protocols that
   require a key exchange, such as the Cellular Digital Packet Data
   (CDPD) system [4].  These systems work because they are employed
   where the ``discrete logarithm'' problem is currently intractable.
   The discrete logarithm problem can be stated as follows:  given g
   and g*N (where `*' means repeating the group operation between g and
   itself N times), find the value of N.

   The two group operations of most interest are:

    1. multiplication, in the modular field of integers mod p

    2. addition, in the group of solution points to particular elliptic
       curves

   For a multiplicative group, repeating the group operation by an
   element on itself N times amounts to (integer) exponentiation by N.
   For an additive group, repeating the group operation N times amounts
   to an integer multiplication operation on that group element.  In
   the elliptic curve group, the elements are not integers, but instead
   ordered pairs (X,Y) which represent solutions to the elliptic curve.

   The first groups have the advantage of being easy to understand.  The
   second groups, proposed later than the first, have the advantage of
   being much faster computationally.





Perkins and Johnson           Expires 27 August 2000           [Page 21]


Internet Draft            Registration Keys             27 February 2000


   For the purposes of the explanation in this appendix, suppose that
   the first party in the key exchange is the foreign agent, and the
   second party is the home agent.  This would be the situation whenever
   these key exchanges are used to generate Registration Keys using the
   methods specified in this document.

   In both cases, the result depends on the fact that the group
   operation in the relevant groups is commutative, so that M*(N*g) ==
   N*(M*g).  When the group operation is multiplication, this is more
   conventionally written as (g^M)^N = (g^N)^M.

   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 home agent, and pretend to the home agent 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 [11].  In the key distribution
   mechanisms specified in this document, the man-in-the-middle attack
   is prevented in most circumstances because each registration key is
   effectively authenticated by the home agent.  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.

   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 foreign agent may choose (or be manually
   configured with) the prime and generator values (or, the generating
   point and Galois field values) at any time, or may use the same
   values for a number of registrations.  The home agent may also choose
   its private random number and calculate its computed value at any
   time.  For example, after completing one registration, the foreign
   agent 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 a registration from another mobile node.  Even more
   simply, the foreign agent may use the same private random number and
   computed value for any number of registrations.








Perkins and Johnson           Expires 27 August 2000           [Page 22]


Internet Draft            Registration Keys             27 February 2000


B. Diffie-Hellman Key Exchange in the Field of Integers mod p

   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
   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 registration message extension to the other party.  The
   foreign agent creates the computed value f = g^N mod p, where N is its
   private random number, p is the prime which is sent as part of the
   transaction, and g is the generator.  The home agent then creates
   another computed value h = g^y mod p, where M is its own private
   random number, and p and g are the same as for the foreign agent.
   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.  Since f^M = (g^N)^M = C =
   (g^M)^N = f^N, the foreign agent and the home agent can compute a shared
   value C that is not detectable by other network nodes.  The shared
   secret is the number C mod p, where p is the same prime number as
   before.  Knowing the computed values mod p does not enable passive
   listeners to determine the private values, so the algorithm allows
   the two parties to agree on an otherwise undetectable secret.

   If Diffie-Hellman were substantially less computationally expensive,
   it could likely serve the needs of many mobile nodes.  But, the
   algorithm itself uses exponentiations or strange additions 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.


C. Diffie-Hellman Key Exchange in Elliptic Curve Groups

   In order to multiply a generating point (X,Y) by a large number N, it
   is necessary to add the point to itself N times.  However, addition
   in elliptic curve groups is not simple componentwise addition; (X,Y)
   + (A,B) is NOT EQUAL to (X+A,Y+B). Instead, in order for the group
   addition to yield only points that are solutions to the elliptic
   curve, a special formula for group addition must be used.





Perkins and Johnson           Expires 27 August 2000           [Page 23]


Internet Draft            Registration Keys             27 February 2000


   Suppose, then, that one is given two points (X1, Y1) and (X2, Y2) in
   the elliptic curve group of all solutions to the equation y^2 + x*y
   = x^3 + a*x^2 + b.  The function Plus (X1, Y1, X2, Y2) is defined as
   follows.

    -  if X1 = X2 and Y1 = Y2, then Plus (X1, Y1, X2, Y2) = Double (X1,
       Y1), where Double (X, Y) is as defined below.

    -  otherwise, if X1 = X2 but Y1 != Y2, then
       Plus (X1, Y1, X2, Y2) = (0,0)

    -  otherwise, Plus (X1, Y1, X2, Y2) = (V, W), where

        i. V = L^2 + L + X1 + X2 + a

       ii. W = L*(X1 + V) + V + Y1, and

      iii. L = (Y1 + Y2)/(X1 + X2)

   The function Double (X, Y) is defined as follows:

    -  if X = 0, then Double (X, Y) = (0,0)

    -  otherwise, Double (X, Y) = (V, W), where

        i. V = L^2 + L + a,

       ii. W = X^2 + (L + 1) * X, and

      iii. L = X + Y/X

   The above formulas are given in a publication by Richard Schroeppel,
   Hilarie Orman, and Sean O'Malley [15].  Note that there are many
   computational shortcuts available.  The referenced publication is a
   good start; one should also consult [14].

   The following elliptic curve characteristics are used by default,
   and until a method is specified for offering non-default values.
   This information is taken from appendix E.4 of RFC 2412 [10], and is
   reproduced here only for completeness.

   The elliptic curve is based on the Galois field GF[2^185] with 2^185
   field elements.  The irreducible polynomial for the field is

      u^185 + u^69 + 1.

   The equation for the elliptic curve is

      Y^2 + X Y = X^3 + A X + B.



Perkins and Johnson           Expires 27 August 2000           [Page 24]


Internet Draft            Registration Keys             27 February 2000


   X, Y, A, B are elements of the field.  For the curve specified, A = 0
   and

      B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1.

   B is represented in binary as the bit string 1111011101001; in
   decimal this is 7913, and in hex 1EE9.

   The generator is a point (X,Y) on the curve (satisfying the curve
   equation, mod 2 and modulo the field polynomial);

      X = u^4 + u^3 and Y = u^3 + u^2 + 1.

   For this extension, the subtype data is a standard representation
   using a point compression technique (not defined in RFC 2412) for the
   computed value of (V,W) = N*(X,Y), specified as follows.

   Let (V,W) be a point of the elliptic curve group defined as above.
   Let OCTETS be the representation of V as bits right-justified into an
   integer number of octets.  For instance, if V = 24(decimal), OCTETS
   = 18 shown as two hexadecimal digits.  If V = 317(decimal), OCTETS
   = 013D shown as four hexadecimal digits.  The number of hexadecimal
   digits needed to represent OCTETS will always be an even number since
   every byte of the representation takes two hexadecimal digits to
   represent.

   Then, define W0 to be zero (0) if V == 0; otherwise define W0 to be
   the rightmost bit of the field element W/V. If W0 == 0, then the
   subtype data will be 02 || OCTETS; otherwise the subtype data will be
   03 || OCTETS. Here, "||" means concatenation.

   To recover (V,W) from this standard representation, proceed as
   follows.

   If V == 0, then W = B^(2^184), where B = 7913 from the defining
   elliptic curve.  W is the square root of B. Otherwise, compute the
   field element W = V + a + B/(V^2) = V + 7913/(V^2).  Find Z such
   that Z^2 + Z = W. Let Z0 be the rightmost bit of Z. If the received
   computed value has prefix 02, let W0 be 0; otherwise if the received
   computed value has prefix 02, let W0 be 1.  If W0 != Z0, then let Z =
   Z + 1.  Then, W = Z*V.











Perkins and Johnson           Expires 27 August 2000           [Page 25]


Internet Draft            Registration Keys             27 February 2000


Addresses

   The working group can be contacted via the current chairs:


        Basavaraj Patil               Phil Roberts
        Nokia Corporation             Motorola
        M/S M8-540
        6000 Connection Drive         1501 West Shure Drive
        Irving, TX 75039              Arlington Heights, IL 60004
        USA                           USA
        Phone:  +1 972-894-6709       Phone:  +1 847-632-3148
        EMail:  Raj.Patil@nokia.com   EMail:  QA3445@email.mot.com
        Fax :  +1 972-894-5349



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

        Charles E. Perkins                David B. Johnson
        Communications Systems Lab        Computer Science Department
        Nokia Research Center             5000 Forbes Avenue
        313 Fairchild Drive               Pittsburgh, PA 15213-3891
        Mountain View, California 94043   Carnegie Mellon University
        USA                               USA
        Phone:  +1-650 625-2986           Phone:  +1-412-268-7399
        EMail:  charliep@iprg.nokia.com   E-mail:  dbj@cs.cmu.edu
        Fax:  +1 650 625-2502             Fax:  +1-412-268-5576
























Perkins and Johnson           Expires 27 August 2000           [Page 26]


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