Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Sun Microsystems Laboratories
25 May 1999 Pat R. Calhoun
Sun Microsystems Laboratories
Mobile IP Challenge/Response Extensions
draft-ietf-mobileip-challenge-02.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, defines an authentication
extension (the Mobile-Foreign Authentication extension) by
which a mobile node can authenticate itself to a foreign agent.
Unfortunately, this extension does not provide ironclad replay
protection, and does not conform to existing techniques (such
as CHAP) for authenticating portable computer devices. In this
specification, we define extensions for the Mobile IP Agent
Advertisements and the Registration Request that allow a foreign
agent to use a challenge/response mechanism to authenticate the
mobile node.
Perkins, Calhoun Expires 25 November 1999 [Page i]
Internet Draft Mobile IP Challenge/Response 25 May 1999
1. Introduction
Mobile IP, as originally specified, defines an authentication
extension (the Mobile-Foreign Authentication extension) by
which a mobile node can authenticate itself to a foreign agent.
Unfortunately, this extension does not provide ironclad replay
protection, and does not conform to existing techniques (such
as CHAP) for authenticating portable computer devices. In this
specification, we define extensions for the Mobile IP Agent
Advertisements and the Registration Request that allow a foreign
agent to a use challenge/response mechanism to authenticate the
mobile node.
2. Mobile IP Agent Advertisement Challenge Extension
This section defines a new extension to the Router Discovery
Protocol [4] for use by foreign agents that need to issue a challenge
for authenticating mobile nodes.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Challenge Extension
Type 24
Length MUST be at least 16
Challenge A random value of at least 128 bits.
The Challenge extension, illustrated in figure 1, 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 an authentication for its registration request
message. The challenge is selected by the foreign agent to provide
local assurance that the mobile node is not replaying any earlier
registration request. Eastlake, et al. [5] provides more information
on generating pseudo-random numbers suitable for use as values for
the challenge.
Perkins, Calhoun Expires 25 November 1999 [Page 1]
Internet Draft Mobile IP Challenge/Response 25 May 1999
3. Operation
This section describes modifications to the Mobile IP registration
process which may occur after the Foreign Agent issues a Mobile IP
Agent Advertisement containing the Challenge on its local link.
3.1. Mobile Node Processing for Registration Requests
Whenever the Agent Advertisement contains the Challenge extension,
if the mobile node does not have a security association with the
Foreign Agent, then it MUST include the Challenge value in a MN-FA
Challenge extension to the Registration Request message. If, on the
other hand, the mobile node does have a security association with the
foreign agent, it MAY include the Challenge value in its Registration
Request message.
If the Mobile Node has a security association with the Foreign Agent,
it MUST include a Mobile-Foreign Authentication extension in its
Registration Request message, according to RFC 2002 [11]. When the
Registration Request contains the MN-FA Challenge extension specified
in section 4, the Mobile-Foreign Authentication MUST follow the
Challenge extension in the Registration Request.
If the Mobile Node does not have a security association with
the Foreign Agent, the Mobile Node SHOULD include the MN-AAA
Authentication extension as defined in section 4.2. In addition,
the Mobile Node SHOULD include the NAI extension [3], to enable
the foreign agent to make use of any available verification
infrastructure. The SPI field of the MN-AAA Authentication extension
specifies the particular secret and algorithm (shared between the
Mobile Node and the verification infrastructure) that must be used to
perform the authentication.
In either case, the MN-FA Challenge extension and one of the above
specified authentication extensions MUST follow the Mobile-Home
Authentication extension, if present.
3.2. Foreign Agent Processing for Registration Requests
Upon receipt of the Registration Request, if the Foreign Agent has
issued a Challenge as part of its Agent Advertisements, and it
does not have a security association with mobile node, then the
Foreign Agent MUST check that the MN-FA Challenge extension contains
a challenge value previously unused by the Mobile Node. This
ensures that the mobile node is not attempting to replay a previous
advertisement and authentication.
Perkins, Calhoun Expires 25 November 1999 [Page 2]
Internet Draft Mobile IP Challenge/Response 25 May 1999
The Foreign Agent MUST NOT accept any Challenge in the Registration
Request unless it was advertised as one of the last CHALLENGE_WINDOW
(see section 5) Challenge values inserted into the immediately
preceding Agent advertisements. If the Challenge is not one of
the recently advertised values, the foreign Agent SHOULD send a
Registration Reply with Code UNKNOWN_CHALLENGE (see section 6).
Furthermore, the Foreign Agent MUST check that there is either
a Mobile-Foreign or a MN-AAA Authentication extension after the
Challenge value. Any registration message containing the Challenge
value without either of these authentication extensions MUST
be silently discarded. If the registration message contains
a Mobile-Foreign Authentication extension with an incorrect
authenticator that fails verification, the Foreign Agent MAY
send a Registration Reply to the mobile node with Code value
BAD_AUTHENTICATION (see Section 6).
If the MN-AAA Authentication extension (see Section 4.2) is present
in the message, or if an NAI extension is included indicating that
the mobile node belongs to a different administrative domain, the
foreign agent may take actions outside the scope of this protocol
specification to carry out the authentication of the mobile node.
For instance, the foreign agent MAY forward the Registration Request
to the verification infrastructure (see figure 4 in the Appendix).
Since the Challenge extension, and the authentication extension that
is used by the Mobile Node to satisfy the challenge, both follow
the Mobile-Home Authentication extension whenever the latter is
present, the Foreign Agent MAY remove the Challenge Extension and
the applicable authentication from the Registration Request without
disturbing the authentication value computed by the Mobile Node for
use by the Home Agent.
If the Foreign Agent does not remove those extensions, then the
Foreign Agent SHOULD store the Challenge value as part of the pending
registration request list [11]. In this case, the Foreign Agent MUST
reject any Registration Reply message coming from the Home Agent
that does not also include the Challenge Extension. The Foreign
Agent MUST send the rejected Registration message to the mobile
node, and change the status in the Registration Reply to the value
MISSING_CHALLENGE (see section 6).
If the Foreign Agent does remove the Challenge extension and
applicable authentication from the Registration Request message,
then it SHOULD insert the Identification field from the Registration
Request message along with its record-keeping information about the
particular Mobile Node in order to protect against replays.
Perkins, Calhoun Expires 25 November 1999 [Page 3]
Internet Draft Mobile IP Challenge/Response 25 May 1999
3.3. Home Agent Processing for the Challenge Extensions
If the Home Agent receives a Registration Request with the MN-FA
Challenge extension, and recognizes the extension, the Home Agent
MUST include the Challenge extension in the Registration Reply.
The Challenge Extension SHOULD be included before the Mobile-Home
Authentication extension.
Since the extension type for the Challenge extension is within the
range 128-255, the Home Agent MUST process such a Registration
Request even if it does not recognize the Challenge extension [11].
In this case, the Home Agent will send a Registration Reply to the
Foreign Agent that does not include the Challenge extension.
4. Mobile IP Registration Extensions
This section specifies new Mobile IP Registration Extensions that are
used to satisfy a Challenge in an Agent Advertisement.
4.1. MN-FA Challenge Extension
The Challenge extension to the Registration Request message is used
to indicate the challenge that the mobile node is attempting to
satisfy.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The MN-FA Challenge Extension
Type 132 (skippable) [11]
Length MUST be at least 16
Challenge The Challenge field is copied from the Challenge field
found in the Agent Advertisement Challenge extension
(see section 2).
Perkins, Calhoun Expires 25 November 1999 [Page 4]
Internet Draft Mobile IP Challenge/Response 25 May 1999
4.2. MN-AAA Authentication Extension
The mobile node MAY include this extension in the Registration
Request if the foreign agent's advertisement contains the Challenge
Extension. If the mobile node does not include a Mobile-Foreign
Authentication extension, then it SHOULD include the MN-AAA
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.) | Authenticator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MN-AAA Authentication Extension
Type 36 (not skippable) [11]
Length 4 plus the number of bytes in the Authenticator;
MUST be at least 20.
SPI Security Parameters Index
Authenticator The variable length Authenticator field consists
random value of at least 128 bits.
The default algorithm for computation of the authenticator is
MD5 [12] computed on the following data, in the order shown:
Key || Preceding Mobile IP data || Type, Length, SPI || Key
where the Type, Length, and SPI are as shown above. Each mobile node
MUST support the ability to produce the authenticator by using MD5 as
shown (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.
Perkins, Calhoun Expires 25 November 1999 [Page 5]
Internet Draft Mobile IP Challenge/Response 25 May 1999
5. Configurable Parameters
Every implementation of the Mobile IP agent supporting the extensions
defined in this document SHOULD be able to configure each parameter
in the following table. Each table entry contains the name of the
parameter, the default value, and the section of the document in
which the parameter first appears.
Parameter Name Default Value Section of Document
-------------- ------------- -------------------
CHALLENGE_WINDOW 2 3.2
6. Error Values
Each entry in the following table contains the name of Code [11] to
be returned in a Registration Reply, the value for the Code, and the
section in which the error is first mentioned in this specification.
Error Name Value Section
---------------------- ----- -------------------
UNKNOWN_CHALLENGE 104 3.2
BAD_AUTHENTICATION 67 3.2; also see [11]
MISSING_CHALLENGE 105 3.2
7. IANA Considerations
The number for the Mobile IP Agent Advertisement Challenge extension
(section 2) is taken from the numbering space defined for Mobile
IP extensions to the ICMP Router Advertisements [4] defined in
RFC 2002 [11]. The number for the MN-FA Challenge extension
(section 4.1) and the MN-AAA Authentication extension (section 4.2)
is taken from the numbering space defined for Mobile IP registration
extensions defined in RFC 2002 [11] as extended in RFC 2356 [8].
The numbering for the extensions SHOULD NOT conflict with values
specified in the Internet Draft for Route Optimization [10] or
the Internet Draft for the Mobile IP Network Address Identifier
Extension. The Code values specified for errors, listed in
section 6, MUST NOT conflict with any other code values listed in
RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned
Internet Drafts. They are to be taken from the space of error values
conventionally associated with rejection by the foreign agent (i.e.,
64-127).
Perkins, Calhoun Expires 25 November 1999 [Page 6]
Internet Draft Mobile IP Challenge/Response 25 May 1999
8. Security Considerations
In the event that a malicious mobile node attempts to replay the
authenticator for an old MN-FA Challenge, the Foreign Agent would
detect it since the agent always checks whether it has recently
advertised the Challenge (see section 3.2).
9. IPv6 Considerations
For use with IPv6 mobility [6], the challenge extension should be
applied to Router Advertisements [9]. In order to check the response
from the mobile node, the router would need to have a security
relationship with either the mobile node, its home agent, or another
entity within the IPv6 security infrastructure. 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.
10. 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-07.txt, November 1998. (work in
progress).
[3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network
Address Identifier Extension. draft-ietf-mobileip-mn-nai-02.txt,
May 1999. (work in progress).
[4] Stephen E. Deering, Editor. ICMP Router Discovery Messages.
RFC 1256, September 1991.
[5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller.
Randomness Recommendations for Security. RFC 1750, December
1994.
Perkins, Calhoun Expires 25 November 1999 [Page 7]
Internet Draft Mobile IP Challenge/Response 25 May 1999
[6] D. Johnson and C. Perkins. Mobility Support in IPv6.
draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in
progress).
[7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May
1998.
[8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. RFC 2356, June 1998.
[9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor
discovery for IP Version 6 (IPv6), December 1998. Status:
DRAFT STANDARD.
[10] Charles E. Perkins and David B. Johnson. Route Optimization in
Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999.
(work in progress).
[11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992.
A. Verification Infrastructure
The Challenge extensions in this protocol specification are expected
to be useful to help the Foreign Agent manage connectivity for
visiting mobile nodes, even in situations where the foreign agent
does not have any security association with the mobile node or the
mobile node's home agent. In order to carry out the necessary
authentication, it is expected that the foreign agent will need the
assistance of external administrative systems, which recently have
come to be called AAA systems. For the purposes of this document,
we call the external administrative support the "verification
infrastructure". The verification infrastructure is described
to motivate the design of the protocol elements defined in this
document, and is not strictly needed for the protocol to work. The
foreign agent is free to use any means at its disposal to verify the
credentials of the mobile node. This could, for instance, rely on a
separate protocol between the foreign agent and the Mobile IP home
agent, and still be completely invisible to the mobile node.
In order to verify the credentials of the mobile node, we imagine
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
Perkins, Calhoun Expires 25 November 1999 [Page 8]
Internet Draft Mobile IP Challenge/Response 25 May 1999
shown in figure 4. For an example of another protocol that has
been specified to actually carry out the challenge verification
operations, see [2, 1].
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| Foreign Agent | | Home Agent |
| | | |
+---------------+ +---------------+
Figure 4: The Verification Infrastructure
After the foreign agent gets the Challenge authentication, it MAY
pass the authentication to the (here unspecified) infrastructure,
and await 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 contains Code value
BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions
indicated for rejected registrations.
Implicit in this picture, 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.
Perkins, Calhoun Expires 25 November 1999 [Page 9]
Internet Draft Mobile IP Challenge/Response 25 May 1999
Addresses
The working group can be contacted via the current chairs:
Erik Nordmark Basavaraj Patil
Sun Microsystems, Inc. Nortel Networks Inc.
17 Network Circle 2201 Lakeside Blvd.
Menlo Park, California 94025 Richardson, TX. 75082-4399
USA USA
Phone: +1 650 786-5166 +1 972-684-1489
Fax: +1 650 786-5896
E-mail: nordmark@sun.com bpatil@nortelnetworks.com
Questions about this memo can be directed to:
Charles E. Perkins Pat R. Calhoun
Sun Microsystems Laboratories Sun Microsystems Laboratories
15 Network Circle 15 Network Circle
Menlo Park, California 94025 Menlo Park, California 94025
USA USA
Phone: +1-650 786-6464 Phone: +1 650-786-7733
EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com
Fax: +1 650 786-6445
Perkins, Calhoun Expires 25 November 1999 [Page 10]
