INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Charles E. Perkins
Title: draft-ietf-mobileip-challenge-00.txt Sun Laboratories, Inc.
Date: November 1998
Mobile IP Foreign Agent Challenge/Response Extension
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 view the entire list of current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
RFC2002, which defines the base Mobile IP protocol, assumes that a
shared secret exists with all mobility agents and the Mobile Node.
However, in larger networks, this assumption can lead to scalability
problems, especially in situations where the Mobility Agents are
owned by different administrative domains. This document specifies
the Router Advertisement and Mobile IP extensions necessary to
integrate Mobile IP with Key Distribution Centers (KDC).
Calhoun, Perkins expires April 1999 [Page 1]
INTERNET DRAFT November 1998
Table of Contents
1.0 Introduction
1.1 Terminology
2.0 Operation
2.1 Intra-Domain Mobile IP
2.2 Inter-Domain Mobile IP
2.3 Allocation of a Home Agent in a Foreign Network
2.4 Smooth Handoff
2.5 Key Expiration
2.6 Interaction with Home Agent Allocation
3.0 Router Discovery Extensions
3.1 Foreign Agent Challenge Extension
3.2 Foreign Agent NAI Extension
4.0 Mobile IP Registration Extensions
4.1 Foreign-Agent-Challenge Extension
4.2 Mobile-Challenge-Response
4.3 Mobile-Foreign-SPI Extension
4.4 Mobile-Home-SPI Extension
4.5 Mobile-Foreign-Key Extension
4.6 Mobile-Home-Key Extension
4.7 Previous-Foreign-Agent-NAI Extension
4.8 Key-Lifetime Extension
5.0 Security Analysis
5.1 Challenge/Response Replay
5.1 Malicious FA
5.2 Malicious Foreign KDC
6.0 References
7.0 Acknowledgements
8.0 Chairs' Addresses
9.0 Author's Address
1.0 Introduction
RFC2002, which defines the base Mobile IP protocol, assumes that a
shared secret exists with all mobility agents and the Mobile Node.
However, in larger networks, this assumption can lead to scalability
problems, especially in situations where the Mobility Agents are
owned by different administrative domains.
In this proposal, we recommend the integration of Mobile IP and KDCs
to solve the problem. Our primary design goal is to minimize the
number of security associations that a given Mobility Agent requires
in order to get service. In fact, this proposal requires that
Mobility Agent and Node have only a single security association with
the Key Distribution Center, known as the Home Domain Allocation
Agency (HDAA).
Calhoun, Perkins expires April 1999 [Page 2]
INTERNET DRAFT November 1998
In order to make this proposal scale in larger networks, we propose
that if the Mobility Agents are not owned by the same administrative
domain, that only the HDAAs share a security association. This allows
cross domain mobility with a single security association between both
networks.
The document [9] describes the extensions necessary for a Home Agent
to be dynamically assigned to a Mobile Node during the first
Registration Request. Making use of the security extensions defined
in RFC 2002, would require the Home Agent to share a security
association with the Mobile Node, which means that the Home Agent
must be owned by the same administrative domain as the Mobile Node.
This extension will describe the security extensions necessary for
the Home Agent to be assigned within the foreign network.
This proposal will also specify how the Mobile Node can move to
another foreign domain and must keep the same Home Agent that was
assigned within the initial foreign domain. This can be achieved even
though both foreign domains do not share any security associations,
but both share one with the home domain.
The extensions described here are designed for new generation
cellular networks.
1.1 Terminology
KDC
Key Distribution Center is a central server that issues short-
lived keys to requesting agents in order to grant access to the
visiting network's foreign agent as well as access to the home
network.
KEYID
Key ID is an ID that references a key instance.
ICV
The Integrity Check Vector is the message authentication code of
the Registration message and the long lived shared secret. The
Mobile IP [2] document refers to this field as the authenticator.
SS1
A secret of up to 16 octets in length shared between the Mobile
Node and the HDAA.
Calhoun, Perkins expires April 1999 [Page 3]
INTERNET DRAFT November 1998
SS2
A secret of up to 16 octets in length shared between the Foreign
Agent and its HDAA.
SS3
A secret of up to 16 octets in length shared between the Home
Agent and its HDAA.
2.0 Operation
The extensions in this document are specified to enable Mobile IP to
interoperate with another protocol that can create keys for use
between the foreign agent and mobile node, the foreign agent and the
home agent, and the mobile node and its home agent. The protocol
messages for key creation, and verification of the Foreign Agent
challenge, are not specified in this document, because they are part
of a different protocol that processes messages sent to a port other
than 434. Therefore, those key creation and challenge verification
messages are not considered to be part of Mobile IP, and are not
processed by Mobile IP software. All of the extensions specified in
this document are expected to be processed by Mobile IP software that
has been updated to handle the additional syntax presented in these
extensions. For an example of another protocol that has been
specified to actually carry out the key creation and challenge
verification operations, see [3] [6].
The shared secrets (SS1, SS2, and SS3) indicated in this document are
shared with a KDC agent in the home domain. SS2 may be shared
between this KDC agent and the foreign agent, or more likely between
the KDC agent and a proxy acting in concert with the foreign agent.
For an example of how this works, consider the following diagram:
------------------------------------------------------
| |
| Verification and Key Management Infrastructure |
| |
------------------------------------------------------
^ | ^|
| | ||
| v |v
----------------- -----------------
| | | |
| Foreign Agent | | Home Agent |
| | | |
----------------- -----------------
Calhoun, Perkins expires April 1999 [Page 4]
INTERNET DRAFT November 1998
After the foreign agent gets the Challenge Response, it passes the
Response along to the (here unspecified) infrastructure, and awaits a
a Registration Reply. If the reply has a positive status (indicating
that the registration was accepted), the foreign agent accepts the
registration, and decodes the Mobile IP keys and SPIs for use with
future Mobile IP registration messages. If the reply does not have a
positive status code, then the foreign agent assumes that the
challenge did not pass verification, for reasons that may or may not
be specified by the infrastructure agents.
Implicit in this picture, however, is the important observation that
the Foreign Agent and the Home Agent have to be equipped to make use
of whatever protocol is made available to them by the key management
and challenge verification shown in the figure.
2.1 Intra-Domain Mobile IP
In the simplest case, the Mobility Agents and the Mobile Node are
owned by the same administrative domain. In this following example,
all Mobility Agents MUST share a security association with the Home
Domain Allocation Agency (HDAA).
+------+ +------+ +------+
| | | | | |
| MN |- - - -| FA |- - - - - - - - - -| HA |
| | | | | |
+---+--+ +---+--+ +---+--+
| | | SS3
| | SS2 +---+--+
| +----------------------+ |
| SS1 | HDAA |
+-------------------------------------+ |
+------+
In this example, the Foreign Agent issues a Router Advertisement on
its local link, which is captured by the Mobile Node. The Router
Advertisement message includes the Foreign Agent Challenge and the
Foreign Agent NAI extensions.
The Mobile Node extracts the Foreign Agent NAI, and uses the NAI to
determine whether it is attached to its home network.
The Mobile Node then extracts the Foreign Agent Challenge from the
advertisement and computes the Mobile-Challenge-Response extension
using the challenge and the Registration Request message hashed with
SS1, but not including the UDP and IP headers. The Registration
Calhoun, Perkins expires April 1999 [Page 5]
INTERNET DRAFT November 1998
Request is forwarded to the Foreign Agent and has the following
format:
<Registration-Request> ::= <Mobile IP Registration Request Header>
<Extensions defined in [2]>
<Mobile-Node-NAI>
<Foreign-Agent-Challenge>
[<Previous-Foreign-Agent NAI>]
[<Mobile-Home Authentication>]
<Mobile-Challenge-Response>
[<Mobile-Foreign Authentication>]
Upon receipt of the Registration Request, the Foreign Agent MUST
ensure that the Foreign-Agent-Challenge extension contains a recently
advertised challenge value. This ensures that the Mobile Node is not
attempting to replay a previous Mobile-Challenge-Response. If the
Mobile-Challenge-Response extension is present in the message, or if
the Mobile-Node-NAI shows that it belongs to a different
administrative domain, the foreign agent (or its proxy) forwards the
Registration Request to the HDAA.
Note that the Foreign Agent MAY provide the Mobile-Challenge-
Response extension in the KDC message. The HDAA can then easily find
the authenticator necessary to authenticate the user.
The HDAA will extract the Mobile-Challenge-Response extension and
compute a response using the Foreign Agent Challenge, SS1 and the
packet. If the response matches the authenticator in the Mobile-
Challenge-Response extension, the user is authenticated. The HDAA may
also perform some additional access control checks such as:
- Whether the Mobile Node can use the Foreign Agent.
- Whether the Mobile Node can use the Foreign Network.
- Whether the Mobile Node can use the network at the requested
day and time.
If successfully authenticated and authorized, the HDAA will generate
three separate short-lived sessions keys, associated Security
Parameter Index (SPI) values and key lifetime, which are sent to the
Home Agent in the KDC response message. The three keys have the
following properties (see figure 1 for the distribution of keys SS1,
SS2 and SS3):
- K1 is used to authenticate Mobile IP messages between the Mobile
Node and the Home Agent, and is encrypted using SS1 for the Mobile
Node (Mobile-Home-Key) and using SS3 for the Home Agent.
- K2 is used to authenticate Mobile IP messages between the Mobile
Calhoun, Perkins expires April 1999 [Page 6]
INTERNET DRAFT November 1998
Node and the Foreign Agent, and is encrypted using SS1 for the
Mobile Node (Mobile-Foreign-Key) and using SS2 for the Foreign
Agent (Foreign-Mobile-Key).
- K3 is used to authenticate Mobile IP messages between the
Foreign Agent and the Home Agent, and is encrypted using SS2 for
the Foreign Agent (Foreign-Home-Key) and using SS3 for the Home
Agent.
The HDAA will forward the response to the Home Agent which includes
all of the Security Parameter Index and Keys.
Upon receipt of the response from the HDAA, the Home Agent will
proceed to process the Registration Request as defined in [2] and
will construct a Registration Reply message in the following format:
<Registration-Reply> ::= <Mobile IP Registration Reply Header>
<Extensions defined in [2]>
<Key-Lifetime>
<Mobile-Foreign-SPI>
<Mobile-Foreign-Key>
<Mobile-Home-SPI>
<Mobile-Home-Key>
<Mobile-Home Authentication>
<Foreign-Home Authentication>
The Mobile-Home Authentication extension will be computed by the Home
Agent using the decrypted version of K1, and the Foreign-Home
Authentication extension is computed using the decrypted version of
K3. The Registration Reply is then sent back to the HDAA in the KDC
message, which forwards it to the Foreign Agent.
The Foreign Agent processes the Registration Reply by extracting the
Foreign-Home-Key and decrypting it using SS2. It then validates the
Foreign-Home Authentication extension by ensuring that the SPI value
matches the value that was provided in the Foreign-Home-SPI, and that
the authenticator was computed using the key (K3). If the packet is
successfully authenticated, the Foreign Agent adds the Mobile-Foreign
Authentication extension using the decrypted version of the key found
in the Foreign-Mobile-Key extension, and includes the SPI value found
in Foreign-Mobile-SPI. The Registration Reply message forwarded to
the Mobile Node has the following format:
Calhoun, Perkins expires April 1999 [Page 7]
INTERNET DRAFT November 1998
<Registration-Reply> ::= <Mobile IP Registration Reply Header>
<Extensions defined in [2]>
<Key-Lifetime>
<Mobile-Foreign-SPI>
<Mobile-Foreign-Key>
<Mobile-Home-SPI>
<Mobile-Home-Key>
<Mobile-Home Authentication>
<Mobile-Foreign Authentication>
Upon receipt of the Registration Reply, the Mobile Node must extract
the Mobile-Foreign-Key and Mobile-Home-Key and decrypt the session
key using the secret shared with the HDAA (SS1). The Registration
Reply's Mobile-Foreign Authentication and Mobile-Home Authentication
extensions are computed using the decrypted version of the keys. The
Mobile Node MUST also ensure that the SPIs used in these extensions
are consistent with the values returned in the Mobile-Foreign-SPI and
Mobile-Home-SPI extensions.
All subsequent Registration Requests sent by the Mobile Node to the
Foreign Agent MUST include the Mobile-Foreign Authentication and the
Mobile-Home Authentication computed using K2 and K1, respectively.
The authentication extensions MUST include the SPIs that refer to the
session keys used, Mobile-Foreign-SPI (K2) and Mobile-Home-SPI (K1).
The keys may be used until either the Mobile Node registers with a
new Foreign Agent, or until the keys expire which is known through
the Key-Lifetime extension. Once the keys expire, the Mobile Node
must request a new key by including the Foreign-Agent-Challenge and
the Mobile-Challenge-Response extensions.
2.2 Inter-Domain Mobile IP
In the previous section, we discussed how the extensions described in
this document could be used in a network where all mobility entities
were owned by the same administrative domain. There is a typical
requirement to have Foreign Agents, owned by a different
administrative domain from the home network, provide service to the
Mobile Nodes.
Unfortunately the scheme described in the previous section cannot be
used in this network configuration since it would require the HDAA to
have a security association with Foreign Agents that are not under
its administrative control, which would introduce serious scalability
and security problems.
In order to be able to support such a configuration, the KDC must
Calhoun, Perkins expires April 1999 [Page 8]
INTERNET DRAFT November 1998
support proxying capabilities, one such method is described in [7].
Proxying means that a KDC receives a request and is able to forward
the request to another KDC for processing in a secure fashion.
In the following figure we introduce a foreign network which consists
of a Foreign Agent which shares a security association with its
Visiting VDAA 1 (VDAA-1). Both of these network entities are owned by
the same administrative domain. Notice that HDAA and VDAA-1 share a
security association, which means that these domains can provide
Mobile IP services to each other with a single association.
+------+ +------+ +------+
| | | | | |
| MN |- - - -| FA |- - - - - - - - - -| HA |
| | | | | |
+---+--+ +---+--+ +---+--+
| | SS2 | SS3
+------------------------------+ |
| | |
+---+--+ | SS1 +---+--+
| | +------+ |
|VDAA-1| | HDAA |
| +--------------SS4--+ |
+------+ +------+
In this example, the Foreign Agent advertises its service in the same
manner as previously discussed. The Mobile Node adds the Challenge
and the Mobile-Challenge-Response extensions to the Registration
Request as previously explained.
When the Foreign Agent receives the Mobile Node's Registration
Request, it validates the challenge and forwards the request to
VDAA-1, which includes the Registration Request, the Mobile Node's
NAI, the Challenge and the Mobile-Challenge-Response extensions.
VDAA-1 uses the domain portion of the Mobile Node's NAI to identify
the Mobile Node's Home KDC, and forwards the request to the HDAA.
At this point, the HDAA authenticates the user and generates the
session keys as described in the previous section. The only
difference are that all keys destined for the Foreign Agent are
encrypted using SS4, which is the security assocation shared between
HDAA and VDAA-1. HDAA then forwards all keys, and the Registration
Request to the Home Agent within the Home network.
Upon receipt of this message, the Home Agent decrypts all keys which
belong to the Home Agent using SS3 and generates the Registration
Reply in the following format:
Calhoun, Perkins expires April 1999 [Page 9]
INTERNET DRAFT November 1998
<Registration-Reply> ::= <Mobile IP Header>
<Extensions defined in [2]>
<Key-Lifetime>
<Mobile-Foreign-SPI>
<Mobile-Foreign-Key>
<Mobile-Home-SPI>
<Mobile-Home-Key>
<Mobile-Home Authentication>
<Foreign-Home Authentication>
The Home Agent forwards the Registration Reply back to the HDAA in a
KDC message, which also includes the encrypted version of the session
keys destined for the Foreign Agent (which was present in the KDC
request to the Home Agent). The HDAA forwards this response back to
the VDAA-1, which descrypts the keys for the Foreign Agent using SS4,
and re-encrypts the keys using SS2, then forwards the response to the
Foreign Agent. Note that in this case the keys destined for the
Foreign Agent are carried within the KDC messages, and not in the
Mobile IP messages.
The Foreign Agent extracts the session keys and the Registration
Reply from the KDC message. The keys are decrypted using SS2 and the
Registration Reply's Foreign-Home Authentication extension is
authenticated using the decrypted version of the Foreign-Home-Key
extension. The Foreign Agent then adds the Foreign-Home
Authentication extension and forwards the Reply to the Mobile Node,
in the following format:
<Registration-Reply> ::= <Mobile IP Header>
<Extensions defined in [2]>
<Key-Lifetime>
<Mobile-Foreign-SPI>
<Mobile-Foreign-Key>
<Mobile-Home-SPI>
<Mobile-Home-Key>
<Mobile-Home Authentication>
<Mobile-Foreign Authentication>
Once the keys have been distributed, the Mobile Node can proceed to
issue Registration Requests using the new session keys until either
the Mobile Node uses a new Foreign Agent, or the keys expire.
2.3 Allocation of a Home Agent in a Foreign Network
The document [9] describes the method of dynamically assigning a Home
Agent to a Mobile Node. The examples provided in the earlier sections
would work well if the Home Agent allocated belonged within the home
Calhoun, Perkins expires April 1999 [Page 10]
INTERNET DRAFT November 1998
network. Here we will look at the how a Home Agent could be allocated
within a foreign network.
In the following figure, we show the Mobile Node which shares the
security association with its HDAA, and the Foreign and Home Agents
share one with their VDAA-1. When the HDAA receives the KDC message
from VDAA-1, the Mobile Node is authenticated using the Challenge and
the Response and additional authorization checks may be performed.
The keys are generated and returned to the VDAA-1, however all keys
for the Foreign and the Home Agent are encrypted using SS4.
Upon receipt of the response, VDAA-1 decrypts all keys for the
Foreign and Home Agent using SS4, and re-encrypts them using SS2 and
SS5, respectively, and the processing continues as previously
described.
+------+ +------+ +------+
| | | | | |
| MN |- - - -| FA |- - - - -| HA |
| | | | +---+ |
+---+--+ +---+--+ | +------+
| | SS2 |
+-----------------------|------+
| | |
+---+--+ SS5 | | SS1 +------+
| +-----+ +------+ |
|VDAA-1| | HDAA |
| +--------------SS4--+ |
+------+ +------+
It is desirable for the Mobile Node to maintain the same Home Agent
within the Foreign Network, even if the Mobile Node enters a new
Foreign Network. However, it is possible that both Foreign Network's
KDCs do not share a security association, and it is also mandatory
that the HDAA be involved since ultimately it will be responsible for
any payments.
In the following figure the Mobile Node enters a new network which
includes the new Foreign Agent and VDAA-2. The Mobile Node receives
the Router Advertisement that inclues the new Foreign Agent's NAI
(and domain). The Mobile Node will determine that it has entered a
new network and will therefore issue a Registration Request that
includes the Old Foreign Agent's NAI, the old Home Agent, the
Challenge and the Response.
Calhoun, Perkins expires April 1999 [Page 11]
INTERNET DRAFT November 1998
+------+
| |
+- -+ HA +
| |
| +---+--+
| SS5
| |
+---+--+ +------+
| | +--------------SS4--+ |
|VDAA-1| | HDAA |
| | | +------+ |
+------+ | SS1 +---+--+
| | |
+------------------------------+ |
| | |
+------+ +------+ +---+--+ |
| | +- -+ | SS7 | | SS6 |
| MN |- - - -| FA +--------+VDAA-2+-------+
| | | | | |
+------+ +------+ +------+
The Foreign Agent will forward this request to its VDAA-2, which will
forward the request towards HDAA. HDAA will determine that the Mobile
Node was already registered with a Home Agent in the old Foreign
Network and will therefore create a new set of session keys. In this
case the session keys destined for the Home Agent will be encrypted
using SS4 and the ones for the Foreign Agent will be encrypted using
SS6.
Upon receipt of the request, VDAA-1 will decrypt the keys for the
Home Agent and re-encrypt them using SS5. Further processing of the
packet will occur as previously described. When the KDC response is
received by VDAA-2, the session keys for the Foreign Agent will be
decrypted using SS6, and re-encrypted using SS7. The message will
then be forwarded to the Foreign Agent and further processing will
occur as previously described.
In the event that the Mobile Node does NOT wish to maintain the Home
Agent within the Foreign Network, the Home Agent field within the
Registration Request is set to zero.
2.4 Smooth Handoff
In order to support smooth hand-off, the Mobile Node MUST examine the
Foreign Agent NAI within the Router Advertisement when it receives
advertisements from a new Foreign Agent. If the Mobile Node
determines that both the old and the new Foreign Agents belong to the
Calhoun, Perkins expires April 1999 [Page 12]
INTERNET DRAFT November 1998
same administrative domain it can attempt to request smooth hand-off.
The Mobile Node MUST include the Challenge and Response as previously
described as well as the Mobile-Foreign Authentication and Mobile-
Home Authentication extensions.
Upon receipt of this Request, the new Foreign Agent (FA-2) can issue
the KDC request to its local KDC (VDAA-1), which can determine if it
is able to provide smooth hand-off. If VDAA-1 had kept state
information that included the session keys previously distributed by
the HDAA, VDAA-1 can re-encrypt the session keys using SS5 and return
these to the Foreign Agent. At this point, the Foreign Agent can add
authenticate the request from the Mobile-Node through the Mobile-
Foreign Authentication extension, and can add the Foreign-Home
Authentication extension prior to forwarding the request to the Home
Agent.
+------+ +------+ +------+
| | | | | |
| MN |- - - -| FA-2 |- - - - - - - - - -| HA |
| | | | | |
+---+--+ +---+--+ +---+--+
| | SS5 | SS3
+------------------------------+ |
| | |
+------+ +---+--+ | SS1 +---+--+
| | | | +------+ |
| FA-1 +-------+VDAA-1| | HDAA |
| | SS2 | +--------------SS4--+ |
+------+ +------+ +------+
If VDAA-1 was not able to provide smooth hand-off services, either
because it did not have the functionality or because it no longer had
a copy of the session keys, it can opt to simply forward the KDC
message to HDAA as previously described and the Challenge and
Response extensions would be used to authenticate the Mobile Node.
2.5 Key Expiration
The Key-Lifetime extension, which MUST be present in the Registration
Reply if any of the Key extensions are present in the reply, contains
the time at which the keys are considered expired. The value of this
extension is the high-order 32 bit value of the NTP timstamp.
When the Mobile Node needs to re-register and the keys have expired,
it MUST request a that new keys be distributed by including ONLY the
Foreign-Agent-Challenge and Mobile-Node-Response extensions without
any other authentication extension.
Calhoun, Perkins expires April 1999 [Page 13]
INTERNET DRAFT November 1998
2.6 Interaction with Home Agent Allocation
Earlier we described that the authentication extensions defined in
this specification lends well with the Dynamic Home Agent Allocation
as described in [9]. In fact, if the Foreign Agent initiates the KDC
request, it is envisioned that the KDC also include the functionality
that would dynamically assign the Home Agent to the Mobile Node.
3.0 Router Discovery Extensions
This section will define the extensions necessary to the Router
Discovery Protocol [8]. The Mobile Node can assume that the Foreign
Agent supports this specification if the extensions in this section
are part of the Router Advertisements.
3.1 Foreign Agent Challenge Extension
The Foreign Agent Challenge Extension is present in the Router
Advertisements by the Foreign Agent in order to communicate the
latest Challenge value that can be used by the Mobile Node to compute
the Challenge Response.
The Foreign Agent is responsible for ensuring that the Challenge
Value in the Registration Request is current (the Foreign Agent may
wish to accept the last two challenge values advertised).
The Foreign Agent Challenge Extension is defined as follows:
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 | Foreign Agent Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
(4 + N), where N is the length of the challenge value.
Challenge
The Challenge field consists random value of at least 128 bits.
Calhoun, Perkins expires April 1999 [Page 14]
INTERNET DRAFT November 1998
3.2 Foreign Agent NAI Extension
The Foreign Agent NAI Extension contains the Foreign Agent's Network
Access Identifier. This value is used by the Mobile Node to determine
if it has entered a new Administrative Domain.
For smooth hand-off, the Mobile Node may wish to use the same Session
Key and SPI it shared with a previous Foreign Agent if both Foreign
Agents are part of the same administrative domain.
The Foreign Agent NAI Extension is defined as follows:
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 | Foreign Agent NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
N, where N is the length of the NAI.
FA NAI
Foreign Agent's Network Access Identifier
4.0 Mobile IP Registration Extensions
This section will define new Mobile IP Registration Extensions that
must be used in order to use the functionality described in this
document.
This extension requires that the following new Code be supported in
the Registration Reply:
SPI_IN_USE TBD
The Foreign Agent uses this error code to indicate to the
Mobile Node that the SPI received by the HDAA is already in use
for another key (one chance in 2^32). Upon receiving this error
code the Mobile Node SHOULD re-issue a new Registration
Request.
Calhoun, Perkins expires April 1999 [Page 15]
INTERNET DRAFT November 1998
4.1 Foreign-Agent-Challenge Extension
The Foreign-Agent-Challenge extension is copied from the Challenge in
the Foreign Agent's Router Advertisement. This extension SHOULD only
be present while there are no keys shared between the Mobile Node and
the Foreign Agent (upon initial contact, or upon once the keys have
expired).
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 | Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
Must be at least 18
Challenge
The Challenge field is copied from the Router Advertisement's
Foreign Agent Challenge.
4.2 Mobile-Challenge-Response Extension
This Extension MUST be included in the Registration Request if either
the Home Agent or the Home Address fields are set to zero (0). The
authenticator is computed as shown below:
FA-Challenge || Packet || Timestamp || Shared Secret
Note that the authentication does NOT cover this 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 | Timestamp ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Timestamp (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Calhoun, Perkins expires April 1999 [Page 16]
INTERNET DRAFT November 1998
TDB
Length
2 plus the number of bytes in the Authenticator.
Timestamp
Contains a monotonically increasing value and is used in the hash
calculation. This field SHOULD be used to detect replay attacks.
Authenticator
Variable length hash.
4.3 Mobile-Foreign-SPI Extension
The Mobile-Foreign-SPI extension contains the Key Identifier created
by the HDAA and is used to identify the Mobile-Foreign-Key and the
Foreign-Mobile-Key. This SPI is to be used in subsequent Registration
Request and Replies within the Mobile-Foreign Authentication
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 (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
fi
Type
TDB
Length
Must be 6
SPI
The SPI field contains the Security Parameter Index (or Key
Identifier) that was created by the HDAA which is used to identify
the key found in the Mobile-Foreign-Key extension.
Calhoun, Perkins expires April 1999 [Page 17]
INTERNET DRAFT November 1998
4.4 Mobile-Home-SPI Extension
The Mobile-Home-SPI extension contains the Key Identifier created by
the HDAA and is used to identify the Mobile-Home-Key. This SPI is to
be used in subsequent Registration Request and Replies within the
Mobile-Home Authentication 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 (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
Must be 6
SPI
The SPI field contains the Security Parameter Index (Or Key
Identifier) that was created by the HDAA which is used to identify
the key found in the Mobile-Home-Key extension.
4.5 Mobile-Foreign-Key Extension
The Mobile-Foreign-Key extension contains the encrypted version of
the session key that the Mobile Node is to share with the Foreign
Agent in subsequent Registration Request. The key is created by the
HDAA and is used in the computation of the Mobile-Foreign
Authentication 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 | MN-FA-KEY...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Calhoun, Perkins expires April 1999 [Page 18]
INTERNET DRAFT November 1998
Length
Must be at least 3
MN-FA-Key
The MN-FA-Key field contains the encrypted version of the session
key created by the HDAA.
4.6 Mobile-Home-Key Extension
The Mobile-Home-Key extension contains the encrypted version of the
session key that the Mobile Node is to share with the Home Agent in
subsequent Registration Request. The key is created by the HDAA and
is used in the computation of the Mobile-Home Authentication
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 | MN-HA-KEY...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
Must be at least 3
MN-HA-KEY
The MN-HA-KEY field contains the encrypted version of the session
key created by the HDAA.
4.7 Previous-FA-NAI Extension
The Previous-FA-NAI Extension contains the NAI which provided service
to the Mobile Node prior to the hand-off. The presence of this
extension informs the Foreign Agent that smooth hand-off should be
done, if possible.
The Mobile Node MUST assume that the new Foreign Agent cannot perform
smooth hand-off, and therefore MUST include the Foreign-Agent-
Challenge and the Mobile-Node-Response extensions as well as the
Calhoun, Perkins expires April 1999 [Page 19]
INTERNET DRAFT November 1998
normal authentication extensions.
The Previous-FA-NAI Extension is defined as follows:
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 | Previous-FA-NAI...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
Must be at least 3
Previous-FA-NAI
The Previous-FA-NAI field contains the NAI of the Foreign Agent
that was servicing the Mobile Node before detecting a new Foreign
Agent.
4.8 Key-Lifetime Extension
The Key-Lifetime extension contains the timestamp at which the keys
include in the Registration Reply will be considered expired. The
value of the number of seconds before the key expires.
Once the keys have expired they can no longer be used. Therefore a
request for new keys must be made on behalf of the Mobile Node by
including the Challenge and Response
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 | Key-Lifetime ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key-Lifetime .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TDB
Length
Calhoun, Perkins expires April 1999 [Page 20]
INTERNET DRAFT November 1998
Must be 6
Lifetime
The Lifetime field contains the number of seconds before the key
expires.
5.0 Security Analysis
This section, although incomplete, attempts to illustrate a few
attacks the authors have thought of and how they are dealt with when
using the extensions defined in this specification:
5.1 Challenge/Response Replay
In the event that a malicious Mobile Node attempts to replay an old
Foreign-Agent-Challenge and Mobile-Node-Response pair, the Foreign
Agent would detect it since the Foreign Agent would be able to verify
that it had not recently advertised the Challenge.
In the event that both the Mobile Node and the Foreign Agent were
malicious, the KDC would recognize the Challenge as being a replay
since the timestamp would be invalid.
5.2 Malicious FA
The possible attack here is where a malicious FA keeps an old KEY and
attempts to create a Registration Request on behalf of the Mobile
Node using the old KEY.
Since both the Mobile Node and the Home Agent share a different key
than the Foreign Agent does with both the Mobile Node and the Home
Agent this attack is not possible.
5.3 Malicious Foreign KDC
It is possible for a foreign KDC (perhaps proxying between both the
home and the visiting network's KDC) to either keep the KEY for some
time to be replayed at a later time, or changes the contents of the
KEY.
In the case of replay of old keys, the problem is already addressed
in section 5.1. In the case where the malicious KDC attempts to alter
the KEY, the Home Agent will notice that the Registration Request was
Calhoun, Perkins expires April 1999 [Page 21]
INTERNET DRAFT November 1998
not authenticated using the correct KEY and will reject the request.
Although this can cause a denial of service attack, the culprit can
be traced using the KDC logs.
6.0 References
[1] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment
Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, March 1998.
[2] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[3] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-00.txt, February 1998.
[4] B. Aboba. "The Network Access Identifier." Internet-Draft,
August 1997.
[5] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework",
draft-calhoun-diameter-framework-01.txt, August 1998.
[6] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension",
draft-calhoun-diameter-mobileip-00.txt, July 1998.
[7] P. Calhoun, W. Bulley, "DIAMETER Proxy Extension".
Internet-Draft, draft-calhoun-diameter-proxy-00.txt,
August 1998.
[8] Deering, S., Editor, "ICMP Router Discovery Messages",
RFC 1256, September 1991.
[9] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Agent
Allocation", draft-ietf-mobileip-ha-alloc-00.txt,
November 1998.
7.0 Acknowledgements
The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6
WG, Gabriel Montenegro and Vipul Gupta for their useful discussions.
8.0 Chairs' Addresses
The working group can be contacted via the current chairs:
Calhoun, Perkins expires April 1999 [Page 22]
INTERNET DRAFT November 1998
Jim Solomon
RedBack Networks
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
USA
Phone: +1 408 548-3583
Fax: +1 408 548-3599
E-mail: solomon@rback.com
Erik Nordmark
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK17-202
Mountain View, California 94303
Phone: +1 650 786-5166
Fax: +1 650 786-5896
E-Mail: erik.nordmark@eng.sun.com
9.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Center
Sun Microsystems Laboratories, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pat.calhoun@eng.sun.com
Charles E. Perkins
Network and Security Center
Sun Microsystems Laboratories, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-6464
Fax: 1-650-786-6445
E-mail: charles.perkins@eng.sun.com
Calhoun, Perkins expires April 1999 [Page 23]
INTERNET DRAFT November 1998
Calhoun, Perkins expires April 1999 [Page 24]
