[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03
Mobile IP Working Group Charles Perkins
INTERNET DRAFT Sun Microsystems
20 November 1997 David B. Johnson
Carnegie Mellon University
Registration Keys for Route Optimization
draft-ietf-mobileip-regkey-00.txt
Status of This Memo
This document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@SmallWorks.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
Route optimization [6] defines extensions to Mobile IP [7]
registration requests that allow datagrams in flight when a mobile
node moves, and datagrams sent based on an out-of-date cached
binding, to be forwarded directly to the mobile node's new binding.
These extensions for smooth handoff require a registration key to be
established between the mobile node and foreign agent. This document
defines additional extensions to the registration requests to allow
for the establishment of single-use registration keys between a
mobile node and foreign agent.
Perkins and Johnson Expires 20 May 1998 [Page i]
Internet Draft Registration Keys 20 November 1997
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. Terminology 1
3. Establishing Registration Keys 2
3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . . 3
3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 4
3.3. Using Diffie-Hellman with the Foreign Agent . . . . . . . 5
4. Messages Requesting A Registration Key 7
4.1. Foreign Agent Key Request extension . . . . . . . . . . . 7
4.2. Mobile Node Public Key extension . . . . . . . . . . . . 8
4.3. Foreign Agent Public Key extension . . . . . . . . . . . 8
4.4. Registration Key Request Extension . . . . . . . . . . . 9
5. Extensions to Supply A Registration Key 10
5.1. Home-Mobile Key Reply Extension . . . . . . . . . . . . . 10
5.2. Foreign Agent Key Reply Extension . . . . . . . . . . . . 11
5.3. Mobile Node Public Key Reply Extension . . . . . . . . . 12
5.4. Foreign Agent Public Key Reply Extension . . . . . . . . 13
5.5. Diffie-Hellman Key Reply Extension . . . . . . . . . . . 14
5.6. SPI Extension . . . . . . . . . . . . . . . . . . . . . . 15
6. Mobile Node Key Requests 15
7. Miscellaneous Home Agent Operations 16
7.1. Receiving Registration Key Requests . . . . . . . . . . . 16
7.2. Home Agent Supplying Registration Keys . . . . . . . . . 17
8. Miscellaneous Foreign Agent Operations 17
8.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 17
9. Security Considerations 18
10. Summary 19
References 19
Chairs' Addresses 20
Perkins and Johnson Expires 20 May 1998 [Page ii]
Internet Draft Registration Keys 20 November 1997
1. Introduction
All Route Optimization messages that change the routing of IP
datagrams to the mobile node are authenticated using the same
mechanisms used in the base Mobile IP protocol. The authentication
relies on a mobility security association established in advance
between the sender and receiver of such messages. However, when a
mobile node registers with a foreign agent, typically it does not
share a security association with the foreign agent. Nevertheless,
in order for the foreign agent to process future binding updates that
it may receive from the mobile node, it needs to have such a securiyt
assocation. Binding updates provide a mechanism for accomplishing
smooth handoffs between a previous foreign agent to a new foreign
agent. Such smooth handoffs rely on the Previous Foreign Agent
Notification extension [6], which requires the transmission of an
authentic binding update to the previous foreign agent created by the
mobile node after it moves.
2. Terminology
This document uses the following terminology, in addition to that
used to describe the base Mobile IP protocol:
Binding cache
A cache of mobility bindings of mobile nodes, maintained by a
node for use in tunneling datagrams to those mobile nodes.
Binding update
A message indicating a mobile node's current mobility binding,
and in particular its care-of address.
Registration Key
A secret key shared between a mobile node and a foreign
agent, that may optionally be established during registration
with that foreign agent. When later moving and registering
a new care-of address elsewhere, the mobile node uses the
registration key shared with its previous foreign agent to send
it an authenticated Binding Update to this foreign agent.
Registration Lifetime
The registration lifetime is the time duration for which a
binding is valid. The term remaining registration lifetime
means the amount of time remaining for which a registration
Perkins and Johnson Expires 20 May 1998 [Page 1]
Internet Draft Registration Keys 20 November 1997
lifetime is still valid, at some time after the registration
was approved by the home agent.
Security Parameters Index (SPI)
An index identifying a security context between a pair of
nodes among the contexts available in the Mobility Security
Association. SPI values 0 through 255 are reserved and MUST
NOT be used in any Mobility Security Association.
Triangle Routing
A situation in which a Correspondent Host's packets to a Mobile
Host follow a path which is longer than the optimal path
because the packets must be forwarded to the Mobile Host via a
Home Agent.
3. Establishing Registration Keys
Foreign agents are expected to be cheap and widely available, as
Mobile IP becomes fully deployed. Mobile nodes will likely find it
difficult to manage long-term security relationships with so many
foreign agents. To securely perform the operations needed for smooth
handoffs from one foreign agent to the next, however, any careful
foreign agent should require assurance that it is getting authentic
handoff information, and not arranging to forward in-flight datagrams
to a bogus destination. The messages described in this document are
used with the Mobile IP Registration Request and Registration Reply
messages to create (sufficient) trust between mobile node and foreign
agent when none exists beforehand, while allowing the use of fully
trustworthy security associations between foreign agents and mobile
nodes whenever they do exist.
Note that the mobile node can only rarely verify the identity of
the foreign agent in any absolute terms. It can only act on the
presumption that the foreign agent is performing its duties by
correct adherence to protocol. The exact identity of the foreign
agent is not crucial to the process of establishing a registration
key. Only an agreement to follow protocol can be expected or
enforced. If the mobile node has a way to obtain a certified public
key for the foreign agent, then the identity may be established in a
firmer fashion, but the needed public key infrastructure seems to be
at least five years distant. Therefore, the methods in this document
enable a mobile node to create a registration key with an anonymous
foreign agent (i.e., one whose identity we cannot establish) during
the registration process. There are several proposed methods for
establishing a registration key, discussed in order of declining
Perkins and Johnson Expires 20 May 1998 [Page 2]
Internet Draft Registration Keys 20 November 1997
preference. Other methods of establishing keys may become available
in the future.
1. If the foreign agent and mobile node share a security
association, it can be used to secure the Previous Foreign Agent
Notification without need to establish a registration key.
2. If the home agent and foreign agent share a security association,
the home agent can choose the new registration key.
3. If the foreign agent has a public key, it can again use the home
agent to supply a registration key.
4. If the mobile node includes its public key in its Registration
Request, the foreign agent can choose the new registration key.
5. The mobile node and its foreign agent can execute a
Diffie-Hellman key exchange protocol [2] as part of the
registration protocol.
Once the registration key is established, the method for performing
smooth handoff seems natural. The following sections give a
brief overview of the above listed methods for establishing the
registration key.
If a request for key establishment cannot be accommodated by
the foreign agent and/or the home agent, then the mobile node's
key request must go unfulfilled. This does not mean that the
Registration Request itself fails, so it has no effect on the status
code returned by the home agent to the mobile node. The mobile node
has to be able to handle the case in which it has requested a key but
the Registration Reply arrives without any key reply extension.
3.1. The Home Agent as a KDC
Crucial to methods (2) and (3) listed above is that the home agent
and mobile node already are known to share a mobility security
association, which can be used to encode the registration key for
delivery to the mobile node. Thus, if the home agent can securely
deliver the key to the foreign agent, it can be used as a Key
Distribution Center (KDC) for the mobile node and its new foreign
agent. The mobile node requests this by including a Registration
Key Request extension in its Registration Request message. When the
home agent chooses the registration key, it sends it back in two
different extensions to the Registration Reply. One extension has
the encrypted key for the foreign agent, and the other extension has
the same key encrypted differently for the mobile node.
Perkins and Johnson Expires 20 May 1998 [Page 3]
Internet Draft Registration Keys 20 November 1997
For the registration key to be established using this method, the
home agent must be able to securely transmit an encrypted copy of the
registration key to the foreign agent. This is straightforward if
the foreign agent already has a mobility security association with
the home agent. If mobile nodes from some home network often visit a
foreign agent, then the effort of creating such a mobility security
association between that foreign agent and the home agent serving
their home network may be worthwhile.
Note that MD5 can be used here for the purpose of transmitting
registration keys, secure against eavesdroppers. The expression
expr1 = MD5(secret | regrep | secret) XOR (key)
(where regrep is the Registration Reply message payload, and XOR is
exclusive-or) can be included within the appropriate Registration
Reply extension and encodes the key in a way which allows recovery
only by the recipient. It is secure against replay because of the
identification field within the Registration Reply message. The
recipient recovers the key by computing
expr2== MD5(secret | regrep | secret)
which then yields key = expr1XOR expr2. Use of MD5 avoids
entanglements with the legal issues surrounding the export of
encryption technology, and reducing the computational power needed to
secure the password against eavesdroppers.
If no such mobility security association exists, but the foreign
agent has a public key available, it can still ask the home agent to
use it to pick a registration key. This is preferable than asking
the mobile node to pick a good registration key, because doing so
may depend upon using resources not available to all mobile nodes.
Just selecting pseudo-random numbers is by itself a significant
computational burden. Moreover, allowing the home agent to pick the
key fits well into the existing registration procedures. On the
other hand, it is possible that a mobile node could do with less than
perfect pseudo-random numbers as long as the registration key were to
be used in the restricted fashion envisioned for smooth handoffs.
3.2. Using the Foreign Agent as a KDC
When the foreign agent and mobile node share a mobility security
association, there is no need to pick a registration key. The mobile
node can secure its Binding Update to the foreign agent whenever it
needs to, by using the existing security association. This is the
most desirable case.
Otherwise, if available, the mobile node can include its public key
(such as RSA [8]) in its Registration Request to the foreign agent,
using a mobile node public key extension. The foreign agent chooses
the new registration key and returns a copy of it encrypted with the
Perkins and Johnson Expires 20 May 1998 [Page 4]
Internet Draft Registration Keys 20 November 1997
mobile node's public key, using a foreign-mobile registration key
reply extension.
3.3. Using Diffie-Hellman with the Foreign Agent
The Diffie-Hellman key-exchange algorithm [2] can be used.
Diffie-Hellman is a public key cryptosystem that allows two parties
to establish a shared secret key, such that the shared secret key
cannot be determined by other parties overhearing the messages
exchanged during the algorithm. It is already used, for example, in
other protocols that require a key exchange, such as in the Cellular
Digital Packet Data (CDPD) system [1].
This technique is known to suffer from a man-in-the-middle attack.
In other words, a malicious agent could pretend to the foreign agent
to be the mobile node, and pretend to the mobile node to be the
foreign agent, and participate as an unwanted third member in the
key exchange. Armed with knowledge of the registration key, the
malicious agent could at a later time disrupt the smooth handoff, or
initiate the handoff prematurely. The man-in-the-middle attack is no
worse than a malicious agent pretending to be a foreign agent in any
other circumstance; that is, it is no worse than already exists with
the base Mobile IP specification [7]. In route optimization, the
man-in-the-middle attack is prevented in most circumstances because
each registration key produced by the techniques in this chapter is
effectively authenticated by the home agent.
If Diffie-Hellman were not computationally expensive, it could
likely serve the needs of many mobile nodes. Diffie-Hellman results
are authenticated by the home agent to frustrate man-in-the-middle
attacks. Moreover, the mobile node and/or the foreign agent are
presumably in direct contact, so that such an attack is detectable if
either of the nodes notices the reception of duplicate packets, and
corrective action taken.
But, the algorithm itself uses exponentiations involving numbers
with hundreds of digits. That may take a long time for some mobile
nodes to do, time which would come at the expense of interactivity
or convenient operation of user application programs. For this
reason, Diffie-Hellman is considered the least desirable alternative
for establishing registration keys. Since it requires no other
configuration, it is nevertheless required in all implementations of
foreign agents that advertise support for smooth handoffs.
Briefly, the Diffie-Hellman algorithm involves the use of two large
public numbers, a prime number (p) and a generator (g). The prime
number and the generator must be known by both parties involved
in the algorithm, but do not have to be secret; these values may
Perkins and Johnson Expires 20 May 1998 [Page 5]
Internet Draft Registration Keys 20 November 1997
be the same or different for each execution of the algorithm and
are not used once the algorithm completes. Each party chooses a
private random number, produces a computed value based on this random
number, the prime and the generator, and sends the computed value in
a message to the other party. The computed value is the number g**x
mod p, where x is the private random number, p is the prime which is
sent as part of the transaction, and g is the generator. Each party
then computes the (same) shared secret key using its own private
random number, the computed value received from the other party, and
the prime and generator values. The shared secret is the number c**y
mod p, where c is the computed value which uses the other party's
private number, p is the same as before, and y is the receiver's
private number. Since (g**x)**y == (g**y)**x, and since knowing the
computed values mod p does not enable passive listeners to determine
the private values, the algorithm allows the two parties to agree on
an otherwise undetectable secret.
To use this algorithm during registration with a foreign agent, the
mobile node includes a Registration Key Request extension in its
Registration Request message, containing its nonzero values for
the prime and generator, along with the computed value from its
own private random number. If no other strategy is available, the
foreign agent then chooses its own private random number and includes
a Diffie-Hellman Registration Key Reply extension in its Registration
Reply message to the mobile node; the extension includes the foreign
agent's own computed value based on its chosen random number and the
supplied prime and generator values from the mobile node. The mobile
node and foreign agent each independently form the (same) shared
secret key from their own chosen random number, the computed value
supplied by the other party, and the prime and generator values.
Establishing a registration key using Diffie-Hellman is
computationally more expensive than most methods described in
Section 3. The use of Diffie-Hellman described here, though, is
designed to allow the Diffie-Hellman computations to be overlapped
with other activities. The mobile node may choose (or be manually
configured with) the prime and generator values at any time, or
may use the same two values for a number of registrations. The
mobile node may also choose its private random number and calculate
its computed value at any time. For example, after completing
one registration, the mobile node may choose the private random
number for its next registration and begin the computation of
its new computed value based on this random number, such that it
has completed this computation before it is needed in its next
registration. Even more simply, the mobile node may use the
same private random number and computed value for any number of
registrations. The foreign agent may choose its private random
number and begin computation of its computed value based on this
number as soon as it receives the mobile node's Registration Request
Perkins and Johnson Expires 20 May 1998 [Page 6]
Internet Draft Registration Keys 20 November 1997
message, and need only complete this computation before it sends
the matching Registration Reply message for the mobile node's
registration.
This could be extended to support other similar key exchange
algorithms, either by adding a new request and reply extension for
each, or by adding a field in the extensions to indicate which
algorithm is to be used. Diffie-Hellman currently seems the only
obvious choice, though; an implementation is available in the free
RSAREF toolkit from RSA Laboratories [5].
4. Messages Requesting A Registration Key
The following extensions may be used by mobile nodes or foreign
agents to request the establishment of a registration key. See
sections 6,7.2, and 8 for appropriate algorithms which allow each
node to tailor the use of these extensions to most closely fit its
configured requirements.
113 Foreign Agent Key Request Extension
114 Mobile Node Public Key Extension
115 Foreign Agent Public Key Extension
116 Diffie-Hellman Key Request Extension
4.1. Foreign Agent Key Request extension
If the foreign agent receives a Registration Key Request from
a mobile node, and it has a security association with the home
agent, it may append the Foreign Agent Key Request extension to
the Registration Request after the mobile-home authentication
extension. The home agent will use the SPI specified in the key
request extension to encode the registration key in the subsequent
Registration Reply message. The format of the Foreign Agent Key
Request extension is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 113
Length 4
Perkins and Johnson Expires 20 May 1998 [Page 7]
Internet Draft Registration Keys 20 November 1997
SPI Security Parameters Index (4 bytes). An opaque
identifier.
4.2. Mobile Node Public Key extension
If the mobile node has a public key, it can ask its prospective
foreign agent to choose a registration key, and to use the mobile
node's public key to encode the chosen registration key. No
eavesdropper will be able to decode the registration key, even if
it is broadcast to all entities with access to the network medium
used by the mobile node. If using the public key, the foreign
agent should still include the selected key in the Registration
Request before it goes to the home agent. Then, the home agent can
authenticate the selected encoded registration key as part of the
Registration Reply message. The format of the mobile node public key
extension is as illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |MN Public Key ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Mobile Node Public Key, continued ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 114
Length The length (typically larger than 255) of the mobile
node's public key
4.3. Foreign Agent Public Key extension
The format of the foreign agent public key extension is as
illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) |FA Public Key ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent Public Key (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the foreign agent has a public key, it can ask the home agent to
choose a registration key, and to use the foreign agent's public key
Perkins and Johnson Expires 20 May 1998 [Page 8]
Internet Draft Registration Keys 20 November 1997
to encode the chosen registration key. Then, the home agent can
authenticate the selected encoded registration key as part of the
Registration Reply message.
Type 115
Length 4 plus the length (typically larger than 255) of the
foreign agent's public key
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Foreign Agent's Public Key
The SPI is provided for the home agent to transcribe into the
eventual Foreign Agent Public Key Reply extension to the Registration
Reply message.
4.4. Registration Key Request Extension
The Registration Key Request extension, illustrated below, may be
included in a Registration Request message sent to a foreign agent.
If the length of the parameters in the key request extension are all
zero, then the mobile node is asking the foreign agent to supply a
key by any means it has available except for Diffie-Hellman.
If the lengths are nonzero, then the mobile node is enabling the
foreign agent to also perform the Diffie-Hellman key exchange
algorithm (as described in Section 3.3) if the other possible key
establishment methods are not available. The foreign agent should
then select a good pseudo-random registration key, and include a
Diffie-Hellman Registration Key Reply extension, in the Registration
Request message sent to the home agent to complete the key exchange.
The home agent will also include same extension in the Registration
Reply sent to the mobile node, and then it will be authenticated as
part of the reply message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prime ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Prime (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Computed Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins and Johnson Expires 20 May 1998 [Page 9]
Internet Draft Registration Keys 20 November 1997
Type 116
Length 3 times the length (in bytes) of each of prime,
generator, and computed value. The values prime,
generator, and computed value must all be the same
length, which must be a multiple of 8 bits.
Prime One of the two public numbers involved in the
Diffie-Hellman key exchange algorithm. The prime should
be a large prime number.
Generator
One of the two public numbers involved in the
Diffie-Hellman key exchange algorithm. If p is the value
of the prime used for this Diffie-Hellman exchange,
the generator should be less than p, and should be a
primitive root of p.
Computed Value
The public computed value from the mobile node for this
Diffie-Hellman exchange. The mobile node chooses a large
random number, x. If g is the value of the generator and
p is the value of the prime, the computed value in the
extension is g**x mod p.
5. Extensions to Supply A Registration Key
The following extensions are used to supply a registration key to
a requesting entity, either a foreign agent or a mobile node, and
are the counterparts to corresponding extensions used to request
registration keys that are described in the last section.
120 Home-Mobile Key Reply Extension
121 Foreign Agent Key Reply Extension
122 Mobile Node Public Key Reply Extension
123 Foreign Agent Public Key Reply Extension
124 Diffie-Hellman Key Reply Extension
125 SPI Extension
5.1. Home-Mobile Key Reply Extension
The home-mobile key reply extension may be used in Registration Reply
messages to send a registration key from the mobile node's home agent
to the mobile node. When used, the home agent is required to also
include a key reply extension in the Registration Reply message,
which gives a copy of the same key to the mobile node's new foreign
agent. The home-mobile key reply extension, illustrated below, is
Perkins and Johnson Expires 20 May 1998 [Page 10]
Internet Draft Registration Keys 20 November 1997
authenticated along with the rest of the Registration Reply message,
and thus no additional authenticator is included in the extension.
The SPI used to encode the registration key may be different than the
SPI used to authenticate the Registration Reply message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) | MN Enc. Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Encrypted Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 120
Length 4 plus the length of the encrypted key for the mobile
node
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Mobile Node Encrypted Key
(variable length) The registration key, chosen by
the home agent, encrypted under the mobility security
association between the home agent and the mobile node.
The same key must be sent, encrypted for the foreign
agent in a foreign agent registration key extension in
this Registration Reply message.
5.2. Foreign Agent Key Reply Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) | FA Enc. Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent Encrypted Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The home-foreign registration key reply extension may be used in
Registration Reply messages to send a registration key from the
mobile node's home agent to the mobile node's new foreign agent.
When used, the home agent is required to also include a home-mobile
Perkins and Johnson Expires 20 May 1998 [Page 11]
Internet Draft Registration Keys 20 November 1997
registration key reply extension in the Registration Reply message,
giving a copy of the same key to the mobile node.
Type 121
Length 4 plus the length of the encrypted foreign agent's key
plus the length of the authenticator
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Foreign Agent Encrypted Key
(variable length) The registration key, chosen by
the home agent, encrypted under the mobility security
association between the home agent and the foreign agent.
The key which is sent in this extension must also be sent by the
home agent to the mobile node, encoded for the mobile node in a
mobile node registration key extension in the same Registration Reply
message.
Authentication of the key is performed by use of data within a HA-FA
Authentication extension to the Registration Reply message which is
required when the Foreign Agent Key Reply extension is used. Replay
protection is accomplished using the identification field in the
Registration Request message, which is also used by the foreign agent
to identify the pending registration data.
5.3. Mobile Node Public Key Reply Extension
The Mobile Node Public Key Reply message is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) | MN Enc. Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Mobile Node's Encoded Key (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the mobile node sends a Mobile Node Public Key Request to its
prospective foreign agent, the foreign agent can immediately select
a registration key. The foreign agent encodes this registration key
into the Mobile Node Public Key Reply extension to the Registration
Request, along with an SPI for future reference. The home agent
subsequently transcribes the extension without change into the
Perkins and Johnson Expires 20 May 1998 [Page 12]
Internet Draft Registration Keys 20 November 1997
Registration Reply message. This procedure allows the mobile node to
be protected against common man-in-the-middle attacks.
Type 122
Length The length (in bytes) of the computed value.
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Mobile Node's Encoded Key
The foreign agent chooses a suitable key, possibly a
pseudo-random number, and encodes it using the mobile
node's public key.
5.4. Foreign Agent Public Key Reply Extension
In response to a foreign agent public key request extension, the home
agent will select a registration key and encode it twice into two
separate key reply extensions of the Registration Reply message. The
Foreign Agent Public Key Reply extension contains the registration
key encoded with the public key of the foreign agent.
The Foreign Agent Public Key Reply message is illustrated below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) | FA Enc. Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Foreign Agent's Encoded Key (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 123
Length 4 plus the length (in bytes) of the Foreign Agent's
Encoded Key.
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Foreign Agent's Encoded Key
The foreign agent chooses a suitable pseudo-random
number, and encodes it using the mobile node's public
key.
Perkins and Johnson Expires 20 May 1998 [Page 13]
Internet Draft Registration Keys 20 November 1997
The SPI, provided by the foreign agent for transcribing into this
extension, is ultimately targeted for use by the mobile node.
5.5. Diffie-Hellman Key Reply Extension
The Diffie-Hellman Registration Key Reply extension, illustrated
below, should be included in a Registration Request message sent by
a foreign agent to the home agent, when the following conditions are
met:
- mobile node has included a Registration Key Request extension
with nonzero prime and generator in its Registration Request
message to the foreign agent, and
- the foreign agent has no public key or security association with
the home agent or mobile node.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) |Computed Val....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Computed Value (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 124
Length 4 plus the length (in bytes) of the computed value.
SPI Security Parameters Index (4 bytes). An opaque
identifier.
Computed Value
The foreign agent chooses a large random number, y. If g
is the value of the generator and p is the value of the
prime, the computed value in the extension is gymod p.
The values of the generator and prime, if nonzero, are
taken from the Registration Key Request extension from
the mobile node's Registration Request message.
The foreign agent supplies a new SPI along with the new registration
key, so that the new key will be useful in the same way as
registration keys created by any other method.
Perkins and Johnson Expires 20 May 1998 [Page 14]
Internet Draft Registration Keys 20 November 1997
5.6. SPI Extension
The SPI Extension is included in Registration Reply messages when
needed to specify the SPI to be associated with the registration key.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SPI (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 125
Length 4 plus the length (in bytes) of the computed value.
SPI Security Parameters Index (4 bytes). An opaque
identifier.
6. Mobile Node Key Requests
If the mobile node detects that its new foreign agent supports
smooth handoffs, it may initiate that process with its previous
foreign agent, as well as asking its new foreign agent to aid in
supplying a registration key for the new registration. The following
code fragment illustrates a good algorithm for the mobile node
to use during registration, to allow the maximum flexibility in
the selection of the new registration key. Any particular mobile
node may be configured to use one, none, or any subset of the
key establishment procedures made available as part of the Route
Optimization protocol.
if (got 'S' bit from advertisement) {
if (have registration key with previous FA) {
; /* append Previous Foreign Agent Notification */
}
/* Set up registration key */
if (have security association with current FA) {
; /* Don't need to create a registration key */
}
else if (have a public key) {
; /* append MN Public Key request */
}
else if (want D-H exchange) {
/* compute a value for prime p and generator g */
/* use it and append MN Key request */
}
Perkins and Johnson Expires 20 May 1998 [Page 15]
Internet Draft Registration Keys 20 November 1997
else /* append MN key request with null computed value, etc */
}
In this way, the mobile node can get a registration key whenever one
is available by any mechanism specified in this document.
7. Miscellaneous Home Agent Operations
7.1. Receiving Registration Key Requests
When the home agent receives a Registration Request message, an
extension requesting a registration key (Section 4) may be present in
the message, requesting the home agent to provide a registration key
to the mobile node and its foreign agent, as described in Section 3.
In that event, the home agent employs a good algorithm for producing
random keys [3] and encrypts the result separately for use by the
foreign agent and by the mobile node. The chosen key is encrypted
under the mobility security association shared between the home
agent and the mobile node, and the encrypted key is placed in a
home-mobile registration key reply extension (Section 5.1) in the
Registration Reply message. The same key also is encrypted under
the mobility security association shared between the home agent and
the foreign agent, and the encrypted key is placed in a home-foreign
registration key reply extension (Section 5.2) in the Registration
Reply message. When the home agent transmits the Registration Reply
message containing reply extensions to the foreign agent, the message
has the overall structure as follows:
-------------------------------------------------------------
|IP|UDP| Reg-Reply| MN Key| FA Key| HA-MH Auth.| HA-FA Auth.|
-------------------------------------------------------------
The mobile node gets the registration key, typically encoded using an
algorithm such as that described in Section 3.1. The encoding of the
foreign agent's copy of the key depends on the particular key request
made by the foreign agent, and may depend upon the SPI specified
along with the encoded key. The HA-FA authentication extension is
only included if the home agent and foreign agent share a mobility
security association.
If the home agent cannot satisfy a request to select a registration
key, it MAY still satisfy the registration attempt. In this case,
the home agent returns a Registration Reply message indicating
success, but does not include any key reply extension.
Perkins and Johnson Expires 20 May 1998 [Page 16]
Internet Draft Registration Keys 20 November 1997
7.2. Home Agent Supplying Registration Keys
When the home agent receives a Registration Request message
with registration key extensions, it usually performs one of two
operations:
- select and encode a registration key for both the mobile node and
the foreign agent, or
- transcribe the registration key already selected by the foreign
agent into the appropriate extension to the Registration Reply
message.
Both operations ensure that the mobile node and home agent are
dealing with the same foreign agent.
When building the Registration Reply, the home agent should follow
an algorithm such as the one illustrated below, to be as useful as
possible for the range of registration key establishment scenarios
that are possible given the current route optimization protocol.
/* Set up registration key */
if (Foreign Agent Key Request) { /* then have security assn. */
/* append MN Key Reply to Registration Reply */
/* append FA key reply to Registration Reply */
}
else if ((have foreign agent public key) ||
(have FA Public Key Reply)) {
/* append MN Key Reply to Registration Reply */
/* append FA Public Key Reply to Registration Reply */
}
else {
/* do nothing */
}
/* append mobile-home authentication extension at end */
8. Miscellaneous Foreign Agent Operations
This section details various operational considerations important
for foreign agents wishing to support smooth handoff, including
algorithms for establishment of registration keys.
8.1. Foreign Agent Handling Key Requests
The foreign agent, when it receives a request from a mobile node for
a registration key, is faced with a variety of possible actions. The
action selected by the foreign agent depends on the resources it has
Perkins and Johnson Expires 20 May 1998 [Page 17]
Internet Draft Registration Keys 20 November 1997
available. The foreign agent typically attempts to reduce as much
as possible the computational burden placed on the mobile node, but
relies on the security association with the greatest cryptographic
strength to encode the registration key. Furthermore, if the foreign
agent performs the key selection, it still supplies the encoded key
in an extension to the Registration Request message, so that the
process of registration will also have the effect of authenticating
its choice of registration key to the mobile node. This strategy
reduces the opportunity for interlopers to mount man-in-the-middle
attacks.
The following code fragment, executed when the foreign agent receives
a key request of some variety, exhibits an algorithm which may be
useful for implementors of foreign agents. The algorithm is supposed
to be used when a foreign agent gets a Registration Request with one
of the key request extensions included.
if (Previous Foreign Agent Notification) {
/* build the Binding Update and authentication extension */
}
/* Set up registration key */
if (have security association with HA) {
/* Append FA key request to Registration Request */
}
else if (have a public key) {
/* append FA Public Key request to Registration Request */
}
else if (have mobile node's public key) {
/* pick a good key */
/* append FA Public Key Reply to Registration Request */
}
else if (want D-H exchange) {
/* start the computation */
/* append the result to the Registration Key Request */
else {
/* do nothing */
}
9. Security Considerations
Whenever the foreign agent is involved with the production of a
registration key by use of the Diffie-Hellman algorithm, the process
is susceptible to the "man-in-the-middle" attack, as detailed in
Section 3.3. This attack is not known to produce further difficulty,
and susceptibility is already inherent in the operation of the base
Mobile IP specification [7]. Attention to this detail is warranted
Perkins and Johnson Expires 20 May 1998 [Page 18]
Internet Draft Registration Keys 20 November 1997
during any future changes to the Route Optimization protocol, and
ways to reduce the risk of direct interest for inclusion into future
revisions of this document.
The calculation of the authentication data described in Section 3.1
is specified to be the same as in the base Mobile IP document for
ease of implementation. There is a better method available (HMAC),
specified in RFC 2104 [4]. If the base Mobile IP specification is
updated to use HMAC, then this route optimization specification
should also be updated similarly.
Registration keys should typically NOT be used as master keys for
producing other derived keys, because of the man-in-the-middle attack
associated with unidentifiable foreign agents.
10. Summary
In this document, we have presented the methods for establishing
registration keys for use by mobile nodes and foreign agents
supporting smooth handoffs. The ways provided for the mobile node
and foreign agent to obtain a registration key are as follows:
- Use the mobility security association they share if it exists
- Use the mobile node's public key if it exists
- Use the foreign agent's public key, if it exists, to enable the
home agent to create public keys for both entities, or
- Use the security association between the foreign agent and home
agent, if it exists, to enable the home agent to create the
registration keys for both entities, or
- Use the Diffie-Hellman key exchange algorithm.
References
[1] CDPD consortium. Cellular Digital Packet Data Specification.
P.O. Box 809320, Chicago, Illinois, July 1993.
[2] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE
Transactions on Information Theory, 22:644--654, November 1976.
[3] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller.
Randomness Recommendations for Security. RFC 1750, December
1994.
Perkins and Johnson Expires 20 May 1998 [Page 19]
Internet Draft Registration Keys 20 November 1997
[4] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997.
[5] RSA Laboratories. Rsaref: A cryptographic toolkit, version 2.0,
1994. http://www.consensus.com/rsaref/index.html.
[6] Charles E. Perkins and David B. Johnson. Route Optimization in
Mobile-IP. draft-ietf-mobileip-optim-06.txt, July 1997. (work
in progress).
[7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[8] Bruce Schneier. Applied Cryptography: Protocols, Algorithms,
and Source Code in C. John Wiley, New York, NY, USA, 1994.
Chairs' Addresses
The working group can be contacted via the current chairs:
Jim Solomon Erik Nordmark
Motorola, Inc. Sun Microsystems, Inc.
1301 E. Algonquin Road 901 San Antonio Road
Schaumburg, IL 60196 Palo Alto, California 94303
USA USA
Phone: +1-847-576-2753 Phone: +1 650 786-5166
Fax: Fax: +1 650 786-5896
E-mail: solomon@comm.mot.com E-mail: nordmark@sun.com
Questions about this document can also be directed to the authors:
Charles E. Perkins David B. Johnson
Technology Development Group Computer Science Department
Mail Stop MPK15-214
Room 2682
Sun Microsystems, Inc. Carnegie Mellon University
901 San Antonio Road 5000 Forbes Avenue
Palo Alto, California 94303 Pittsburgh, PA 15213-3891
USA USA
Phone: +1-650-786-6464 Phone: +1-412-268-7399
Fax: +1-650-786-6445 Fax: +1-412-268-5576
E-mail: charles.perkins@Sun.COM E-mail: dbj@cs.cmu.edu
Perkins and Johnson Expires 20 May 1998 [Page 20]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/