Mobile IP Working Group Pat R. Calhoun
INTERNET DRAFT Sun Microsystems, Inc.
25 February 1999 Charles E. Perkins
Sun Microsystems, Inc.
Mobile IP Challenge/Response Extensions
draft-ietf-mobileip-challenge-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@smallworks.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
Mobile IP, as originally specified, defined an authentication
extension (the Mobile-Foreign Authentication Extension) by which
a mobile node could authenticate itself to a foreign agent.
Unfortunately, this extension does not provide ironclad replay
protection, and worse yet does not conform to existing techniques
(such as CHAP) for authenticating transportable computer devices.
In this specification, we define extensions for the Mobile IP
Agent Advertisements and the Registration Request that allow use of
such challenge/response mechanisms for allowing a foreign agent to
authenticate the mobile node.
Calhoun, Perkins Expires 25 August 1999 [Page i]
Internet Draft Mobile IP Challenge/Response 25 February 1999
1. Introduction
In this document, we postulate that the foreign agent has access to
a verification infrastructure that can return a secure notification
to the foreign agent that the authentication has been performed,
along with the results of that authentication. This infrastructure
may be visualized as shown in figure 1. For an example of another
protocol that has been specified to actually carry out the key
creation and challenge verification operations, see [2, 1]. After
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| Foreign Agent | | Home Agent |
| | | |
+---------------+ +---------------+
Figure 1: The Verification Infrastructure
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. 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 challenge
verification and key management infrastructure shown in the figure.
The protocol messages for handling the authentication within the
verification infrastructure, and identity of the agent performing the
verification of the Foreign Agent challenge, are not specified in
this document, because those operations do not have to be performed
by any Mobile IP entity. On the other hand, and consistent with the
Calhoun, Perkins Expires 25 August 1999 [Page 1]
Internet Draft Mobile IP Challenge/Response 25 February 1999
figure, either the foreign agent or the home agent could perform the
verification if configured to do so.
1.1. Operation
This section describes the modifications to the Mobile IP
registration process which occur after the Foreign Agent issues a
Mobile IP Agent Advertisement containing the Challenge on its local
link, which is captured and processed by the mobile node.
1.2. Registration Request Generation
The mobile node extracts the Challenge from the advertisement and
computes the Mobile-Challenge-Response extension using the challenge
and the Registration Request message hashed with a secret which is
known within the verification infrastructure. The mobile node's
Registration Request is forwarded to the Foreign Agent and includes
the following extensions:
<Extensions defined in [7]>
<Mobile-Node-NAI [3]>, if present
<Foreign-Agent-Challenge> (see section 3.1)
<Mobile-Home Authentication [7]>, if present
<Mobile-Challenge-Response> (see section 3.2)
<Mobile-Foreign Authentication [7]>, if present
Upon receipt of the Registration Request, the Foreign Agent MUST
ensure that the Foreign-Agent-Challenge extension contains a
previously unused 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 forwards the Registration
Request to the verification infrastructure (see figure 1).
1.3. Registration Reply Processing
The following actions occur when the foreign agent receives a
Registration Reply containing the information pertinent to the
authentication of the Challenge Response computed by the mobile
node. It then validates the Foreign-Home Authentication extension
as specified in [7]. If the packet is successfully authenticated,
the Foreign Agent adds the Mobile-Foreign Authentication extension.
The Registration Reply message forwarded to the mobile node has the
following format:
Calhoun, Perkins Expires 25 August 1999 [Page 2]
Internet Draft Mobile IP Challenge/Response 25 February 1999
<Extensions defined in [7]>
<Mobile-Home Authentication>
<Mobile-Foreign Authentication>, if present
2. Mobile IP Agent Discovery Extensions
This section will define a new extension to the Router Discovery
Protocol [4] for use by mobility agents that need to issue a
challenge for authenticating mobile nodes. A mobile node can assume
that the Foreign Agent supports this specification if the extensions
in this section are part of the Router Advertisements.
2.1. Challenge Extension
The Challenge Extension is inserted in the Agent Advertisements by
the Foreign Agent, in order to communicate the latest Challenge value
that can be used by the mobile node to compute a Challenge Response.
The Foreign Agent MUST NOT accept any Challenge in the Registration
Request unless it was advertised as one of the last two Challenge
values inserted into the immediately preceding Agent advertisements.
The 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 | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length MUST be at least 18
Challenge A random value of at least 128 bits.
3. Mobile IP Registration Extensions
This section specifies new Mobile IP Registration Extensions that are
used to satisfy a Challenge in an Agent Advertisement.
Calhoun, Perkins Expires 25 August 1999 [Page 3]
Internet Draft Mobile IP Challenge/Response 25 February 1999
3.1. Foreign-Agent-Challenge Extension
The Foreign-Agent-Challenge extension is copied from the Challenge in
the Agent Advertisement.
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 TBD
Length MUST be at least 16
Challenge The Challenge field is copied from the Agent
Advertisement's Challenge.
3.2. Mobile-Challenge-Response Extension
The mobile node MUST include this extension in the Registration
Request if the foreign agent's advertisement contains the Challenge
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.) | Authenticator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length 6 plus the number of bytes in the Authenticator;
MUST be at least 22.
SPI Security Parameters Index
Authenticator The Challenge field consists random value of at
least 128 bits. Variable length hash.
The authenticator is computed on the following data, in the order
shown:
Key || Preceding Mobile IP data || Type, Length, SPI || Key
Calhoun, Perkins Expires 25 August 1999 [Page 4]
Internet Draft Mobile IP Challenge/Response 25 February 1999
where the Type, Length, and SPI are as shown above. Each mobile
node MUST support the ability to produce the authenticator by using
MD5 [8] on the specified data, which is known as "prefix+suffix"
mode. Just as with Mobile IP, MD5 in the prefix+suffix mode MUST be
able to be configured for selection at any arbitrary 32-bit SPI.
4. Security Considerations
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.
5. IPv6 Considerations
For use with IPv6 mobility, the challenge extension would have to be
applied to Router Advertisements [6]. In order to check the response
from the mobile node, the router would need to have a security
relationship with either the mobile node or its home agent. It is
not yet known which security model would be more appropriate, or
whether it would make the most sense to enable maximum flexibility by
specifying the protocol for both cases.
6. 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.
References
[1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions.
draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in
progress).
[2] P. Calhoun and A. Rubens. DIAMETER Base Protocol.
draft-calhoun-diameter-00.txt, February 1998. (work in
progress).
[3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network
Address Identifier Extension. draft-ietf-mobileip-mn-nai-01.txt,
February 1999. (work in progress).
[4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. RFC
1256, September 1991.
Calhoun, Perkins Expires 25 August 1999 [Page 5]
Internet Draft Mobile IP Challenge/Response 25 February 1999
[5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP version 6 (IPv6). RFC 1970, August 1996.
[6] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor
discovery for IP Version 6 (IPv6), December 1998. Obsoletes
RFC1970 [5]. Status: DRAFT STANDARD.
[7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[8] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992.
Calhoun, Perkins Expires 25 August 1999 [Page 6]
Internet Draft Mobile IP Challenge/Response 25 February 1999
Chairs' Addresses
The working group can be contacted via the current chairs:
Jim Solomon Erik Nordmark
Redback Networks, Inc. Sun Microsystems, Inc.
1301 E. Algonquin Road 17 Network Circle
Schaumburg, IL 60196 Menlo Park, California 94025
USA USA
Phone: +1-847-576-2753 Phone: +1 650 786-5166
Fax: Fax: +1 650 786-5896
E-mail: solomon@redbacknetworks.com E-mail: nordmark@sun.com
Author's Addresses
Questions about this memo can be directed to:
Pat R. Calhoun Charles E. Perkins
Sun Microsystems Laboratories Sun Microsystems Laboratories
15 Network Circle 15 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
USA USA
Phone: +1-650-786-7733 Phone: +1 650 786-6464
EMail: pat.calhoun@sun.com EMail: cperkins@eng.sun.com
Fax: +1 650 786-6445
Calhoun, Perkins Expires 25 August 1999 [Page 7]
