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]
