Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
14 July 2000 David B. Johnson
Carnegie Mellon University
N. Asokan
Nokia Research Center
Registration Keys for Route Optimization
draft-ietf-mobileip-regkey-03.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, Johnson, Asokan Expires 14 January 2001 [Page i]
Internet Draft Registration Keys 14 July 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 6
4.1. Registration Key Request Subtype . . . . . . . . . . . . 7
4.2. Foreign Agent Registration Key Request Subtype . . . . . 8
4.3. Mobile Node Request Via Public Key Subtype . . . . . . . 8
4.4. Foreign Agent Public Key Request Subtype . . . . . . . . 9
4.5. Diffie-Hellman Registration Key Request Subtype . . . . . 9
4.6. Diffie-Hellman Elliptic Curve Registration Key Request . 10
5. Generalized MN-FA Key Reply Subtypes 11
5.1. Registration Key Reply from Home Agent Subtype . . . . . 12
5.2. Mobile Node Public Key Reply Subtype . . . . . . . . . . 12
5.3. Foreign Agent Public Key Reply Subtype . . . . . . . . . 13
5.4. Diffie-Hellman Key Reply Subtype . . . . . . . . . . . . 13
6. Authentication of Foreign Agent 14
7. Mobile Node Key Requests 15
8. Miscellaneous Home Agent Operations 16
8.1. Receiving Registration Key Requests . . . . . . . . . . . 16
8.2. Diffie-Hellman Considerations . . . . . . . . . . . . . . 17
8.3. Foreign Agent Authentication Considerations . . . . . . . 17
8.4. Home Agent Supplying Registration Keys . . . . . . . . . 18
9. Miscellaneous Foreign Agent Operations 19
9.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 19
10. Security Considerations 21
References 22
A. Using Diffie-Hellman with the Foreign Agent 23
Perkins, Johnson, Asokan Expires 14 January 2001 [Page ii]
Internet Draft Registration Keys 14 July 2000
B. Diffie-Hellman Key Exchange in the Group of Integers mod p 25
C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 25
D. Changes since last draft 27
Addresses 29
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.
Group Element
an element of one of the groups used to define the
Diffie-Hellman key exchange extensions.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 1]
Internet Draft Registration Keys 14 July 2000
Field Element
an element of one of the Galois Fields used to define
the elliptic curve group for 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 (e.g., "Length field").
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
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 2]
Internet Draft Registration Keys 14 July 2000
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 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. Even if the identity of
the foreign agent were verifiable, it would be insufficient because the
mobile node would still not have any way of knowing whether the foreign
agent were trustworthy. Only an agreement to follow protocol can be
expected or enforced. If there is appropriate infrastructural support,
the trustworthiness of the foreign agent may be established in firmer
fashion. But the needed public key and trust management infrastructures
seem to be several 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 the need to establish a registration key.
2. If the home agent and foreign agent share a security association,
the home agent can provide the new registration key to the FA.
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 can aid its home agent and its foreign agent
execute a Diffie-Hellman key exchange protocol [5], using the
method for elliptic curves [7, 9], or using the more familiar
method involving modular exponentiations.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 3]
Internet Draft Registration Keys 14 July 2000
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. 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 such a mobility security association between the home agent
and foreign agent does not exist, but the foreign agent has a public
(encryption) key available, it can send this public key to the home
agent and ask the home agent to use it to encode the registration key.
In order for this channel to be confidential, the home agent must be
sure that the public key does in fact belong to the current foreign
agent of the mobile node (the exact identity of the foreign agent is not
important). Otherwise an attacker located between the foreign agent and
the home agent can replace the foreign agent's public key with his own
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 4]
Internet Draft Registration Keys 14 July 2000
public key. This type of attack is known as the ``man-in-the-middle''
attack. We can prevent man-in-the-middle attacks by having the mobile
node effectively certify the foreign agent's public key. This technique
is described in more detail in section 6.
In the absenece of all of the above, the foreign agent and the home
agent can use the Diffie-Hellman key exchange protocol to create the
registration key. The home agent can send this registration key to the
mobile node by including it, suitably encoded, in an extension of the
Registration Reply. The basic Diffie-Hellman key exchange protocol
is susceptible to the man-in-the-middle attack as well. The same
prevention technique as in the foreign agent public key case applies.
Having the home agent choose the registration key is preferable
to 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)
(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
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 5]
Internet Draft Registration Keys 14 July 2000
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 Agent
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 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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 6]
Internet Draft Registration Keys 14 July 2000
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 7, 8.4, and 9 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.
The two Diffie-Hellman key request subtypes differ in the creation
and processing of the Computed Value which appears in the subtype data.
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 7]
Internet Draft Registration Keys 14 July 2000
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 is derived from 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 the key request methods used by the foreign agent.
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.
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 insert the selected encoded registration key as part of the
authenticated data of the Registration Reply message.
However, if the foreign agent has a security association with the
mobile node's home agent, the foreign agent SHOULD use the Foreign Agent
Registration Key Request Subtype (see section 4.2) instead of using the
mobile node's public key to encode a registration key.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 8]
Internet Draft Registration Keys 14 July 2000
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 finite cyclic multiplicative group 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 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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 9]
Internet Draft Registration Keys 14 July 2000
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].
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
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 10]
Internet Draft Registration Keys 14 July 2000
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.
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 11]
Internet Draft Registration Keys 14 July 2000
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 other purposes, such as for 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 MUST 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 Registration
Reply message. Thus, the mobile node is protected against common
man-in-the-middle attacks.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 12]
Internet Draft Registration Keys 14 July 2000
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 Reply 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, Johnson, Asokan Expires 14 January 2001 [Page 13]
Internet Draft Registration Keys 14 July 2000
6. Authentication of Foreign Agent
The Foreign Agent Public Key Request (section 4.4) as well as the the
Diffie-Hellman Registration Key Requests (sections 4.5 and 4.6) require
foreign agent to append additional extensions to the Registration
Request before forwarding it to the home agent. In both cases, there
is no prior security association between the home agent and the foreign
agent, and thus the foreign agent cannot append an FA-HA authentication
extension. Without further measures, the home agent cannot verify the
authenticity of these extensions appended by the foreign agent; these
methods are therefore subject to man-in-the-middle attacks. 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 (note that the exact identity of the foreign agent is
not important).
The authentication of the foreign agent is accomplished as follows
by making use of the Challenge extension [3]. Let p denote the public
data to be included by the foreign agent (e.g., this can be the foreign
agent's public encryption key, or the Diffie-Hellman public computed
value). Let c denote the the randomly chosen challenge that the foreign
agent wants to advertise at that time. Instead the foreign agent
advertises c1 = MD5 (p, c) as the Challenge. The Registration Request
sent by the mobile node will therefore include a Challenge extension
containing c1, followed by the MN-HA Authentication Extension. Before
forwarding the Request, the foreign agent adds the appropriate Key
Request extension, and a new Challenge extension containing c. When
the home agent receives a Registration Request containing two Challenge
extensions and a Key Request extension, it can compute the MD5 checksum
of the public data and the second Challenge, and compare it with the
first Challenge. The home agent also checks the validity of the MN-HA
authentication extension and whether it covers the first Challenge
extension.
This technique allows the foreign agent is free to change p and c
independently of each other (typically p would have a longer life time
than c). If the foreign agent does not need to use a challenge for
other purposes, then c1 can be MD5 (p). In this case, the foreign agent
need not append a Challenge extension to the Registration Request.
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 14]
Internet Draft Registration Keys 14 July 2000
7. 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, Johnson, Asokan Expires 14 January 2001 [Page 15]
Internet Draft Registration Keys 14 July 2000
If (Challenge advertised) {
Add challenge data to Registration Request
/* If NewFA uses Elliptic, challenge is MD5 (N*(X,Y), c) */
}
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.
8. Miscellaneous Home Agent Operations
8.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 then placed as the Subtype Data of the Registration
Key Reply from Home Agent extension (section 5.1) in the Registration
Reply message. The same key may also be encrypted under the mobility
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 16]
Internet Draft Registration Keys 14 July 2000
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.
8.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 applies the group operation Z times 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.
8.3. Foreign Agent Authentication Considerations
When a home agent receives one of the Diffie-Hellman Key Request
subtypes or the Foreign Agent Public Key Request subtype along with two
Challenge extensions, the Challenge Value MUST be checked against the
public value indicated by the foreign agent. The rule by which the
computed value is to be checked is described in section 6.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 17]
Internet Draft Registration Keys 14 July 2000
8.4. 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:
- determine and encode a registration key for the foreign agent,
and when necessary, for the mobile node.
- 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, Johnson, Asokan Expires 14 January 2001 [Page 18]
Internet Draft Registration Keys 14 July 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. */
9. 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.
9.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, Johnson, Asokan Expires 14 January 2001 [Page 19]
Internet Draft Registration Keys 14 July 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, Johnson, Asokan Expires 14 January 2001 [Page 20]
Internet Draft Registration Keys 14 July 2000
10. 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, Johnson, Asokan Expires 14 January 2001 [Page 21]
Internet Draft Registration Keys 14 July 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, Johnson, Asokan Expires 14 January 2001 [Page 22]
Internet Draft Registration Keys 14 July 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 a finite cyclic algebraic group with generator 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. Integers modulo a (large) prime p, with modular multiplication as
the group operation
2. Group of solution points to particular elliptic curves over
(large) fields, with elliptic curve addition as the group
operation
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 23]
Internet Draft Registration Keys 14 July 2000
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.
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, for each mobile node, 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, Johnson, Asokan Expires 14 January 2001 [Page 24]
Internet Draft Registration Keys 14 July 2000
B. Diffie-Hellman Key Exchange in the Group 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^M 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 = h^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 modular 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.
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 25]
Internet Draft Registration Keys 14 July 2000
- 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.
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.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 26]
Internet Draft Registration Keys 14 July 2000
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.
D. Changes since last draft
Apart from minor cosmetics, there are two primary changes
since the last draft. Both have to do with protection against the
man-in-the-middle attack:
- The Foreign Agent Public Key Request method is susceptible to
man-in-the-middle attack as well. The current version allows
the foreign agent to advertise a digest of its public key in
the Challenge extension of Agent Advertisement, similar to the
Diffie-Hellman case.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 27]
Internet Draft Registration Keys 14 July 2000
- The foreign agent may want to use the Challenge extension
for other purposes, too. The current version supports this
possibility by allowing a random challenge to be combined with
the the public value to be authenticated (Diffie-Hellman computed
value or the foreign agent's public key).
The old subsection 8.2 has been moved to the current section 6 and
renamed ``Authentication of the Foreign Agent''. This section explains
how to compute and verify the digest.
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 28]
Internet Draft Registration Keys 14 July 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
N. Asokan
Communications Systems Lab
Nokia Research Center
P.O. Box 407
FIN-00045, NOKIA GROUP
Helsinki
Finland
Phone: +358 40 743 1961
E-mail: n.asokan@nokia.com
Fax: +358 94 376 6852
Perkins, Johnson, Asokan Expires 14 January 2001 [Page 29]
