Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
25 December 1999 Pat R. Calhoun
Sun Microsystems Laboratories
Mobile IP Challenge/Response Extensions
draft-ietf-mobileip-challenge-07.txt
Status of This Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
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 for the foreign agent, 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 June 2000 [Page i]
Internet Draft Mobile IP Challenge/Response 25 December 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 June 2000 [Page 1]
Internet Draft Mobile IP Challenge/Response 25 December 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 the base
Mobile IP specification [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 MUST include the MN-AAA Authentication
extension as defined in section 6.1. 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. If the SPI value is chosen as 2, then the mobile
node specifies CHAP-style authentication [14] using MD5 [13].
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 the mobile node, then the
Foreign Agent MUST check that the MN-FA Challenge extension exists,
and that it contains a challenge value previously unused by the
Mobile Node. This ensures that the mobile node is not attempting
Perkins, Calhoun Expires 25 June 2000 [Page 2]
Internet Draft Mobile IP Challenge/Response 25 December 1999
to replay a previous advertisement and authentication. If the
challenge extension is needed and does not exist, the Foreign Agent
MUST send a Regstration Reply to the mobile node with the error code
MISSING_CHALLENGE.
If a mobile node retransmits a Registration Request with the same
Identification field and the same Challenge extension, and the
Foreign Agent still has a pending Registration Request record
in effect for the mobile node, then the Foreign Agent forwards
the Registration Request to the Home Agent again. In all other
circumstances, if the Foreign Agent receives a Registration
Request with a Challenge extension containing a Challenge value
previously used by that mobile node, the Foreign Agent SHOULD send
a Registration Reply to the mobile node containing the Code value
STALE_CHALLENGE.
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 7) 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 8).
Furthermore, the Foreign Agent MUST check that there is either a
Mobile-Foreign, or a MN-AAA Authentication 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 8).
If MN-AAA Authentication extension (see Section 6.1) 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.
The appendix provides an example of an action that could be taken by
a foreign agent.
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.
Perkins, Calhoun Expires 25 June 2000 [Page 3]
Internet Draft Mobile IP Challenge/Response 25 December 1999
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]. Also 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 with the same
Challenge Value that was included in the Registration Request. 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 8).
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.
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. MN-FA Challenge Extension
This section specifies a new Mobile IP Registration extension that is
used to satisfy a Challenge in an Agent Advertisement. 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
Perkins, Calhoun Expires 25 June 2000 [Page 4]
Internet Draft Mobile IP Challenge/Response 25 December 1999
Type 132 (skippable) (see [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).
5. SPI For RADIUS AAA Servers
http://www.isi.edu/in-notes/iana/assignments/spi-numbers
contains the list of reserved SPI numbers that is maintained by IANA.
Some AAA servers only admit a single security association, and thus
do not use the SPI numbers for Mobile IP authentication extensions
for use when determining the security association that would be
necessary for verifying the authentication information included with
the Authentication extension.
SPI number (TBD ==? 2) is reserved for indicating the following
procedure for computing authentication data (called the
"authenticator"), which is used by many RADIUS servers today.
To compute the authenticator, apply MD5 [13] computed on the
following data, in the order shown:
High-order byte from Challenge || Key ||
MD5(Preceding Mobile IP data || Type, Length, SPI) ||
Least-order 237 bytes from challenge
where the Type, Length, and SPI are as shown above. Since the
RADIUS protocol cannot carry attributes greater than 253 in size,
the preceding Mobile IP data, type, length and SPI are hashed using
MD5. Finally, the least significant 237 octets of the challenge are
concatenated.
6. Generalized Mobile IP Authentication Extension
Several new authentication extensions have been designed for
various control messages proposed for extensions to Mobile IP (for
example, [12]). A new authentication extension is required for a
mobile node to present its credentials to any other entity other
than the ones already defined; the only entities defined in the base
Mobile IP specification [11] are the home agent and the foreign
agent. It is the purpose of the generalized authentication extension
defined here to collect together data for all such new authentication
applications into a single extension type with subtypes.
Perkins, Calhoun Expires 25 June 2000 [Page 5]
Internet Draft Mobile IP Challenge/Response 25 December 1999
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The Generalized Mobile IP Authentication Extension
Type 36 (not skippable) (see [11])
Subtype a number assigned to identify the particular kind
of endpoints for each particular authentication
requirement
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
In this document, only one subtype is defined:
1 MN-AAA Authentication subtype
The Generalized Authentication extension with subtype 1 will be
referred to as a MN-AAA Authentication extension. If the mobile node
does not include a Mobile-Foreign Authentication [11] extension,
then it MUST include the MN-AAA Authentication extension whenever
the Challenge extension is present. If the MN-AAA Authentication
extension is present, then the Registration Message MAY be sent by
the mobile node without containing the Mobile-HA Authentication
extension [11].
6.1. MN-AAA Authentication subtype
The mobile node MAY include a MN-AAA Authentication extension in the
Registration Request.
The default algorithm for computation of the authenticator is
MD5 [13] computed on the following data, in the order shown:
Perkins, Calhoun Expires 25 June 2000 [Page 6]
Internet Draft Mobile IP Challenge/Response 25 December 1999
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.
7. Configurable Parameters
Every 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
8. 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 of Document
---------------------- ----- -------------------
UNKNOWN_CHALLENGE 104 3.2
BAD_AUTHENTICATION 67 3.2; also see [11]
MISSING_CHALLENGE 105 3.2
STALE_CHALLENGE 106 3.2
9. IANA Considerations
The number for the Mobile IP Agent Advertisement Challenge extension
(section 2) is taken from the numbering space defined for Mobile
IP [11] extensions to the ICMP Router Advertisements [4]. The
number for the MN-FA Challenge extension (section 4) and the
MN-AAA Authentication extension (section 6.1) is taken from the
numbering space defined for Mobile IP registration extensions [11]
as extended in RFC 2356 [9]. The numbering for the extensions
SHOULD NOT conflict with values specified in the Internet Draft for
Route Optimization [12] or the Internet Draft for the Mobile IP
Network Address Identifier Extension. The Code values specified
for errors, listed in section 8, MUST NOT conflict with any other
Perkins, Calhoun Expires 25 June 2000 [Page 7]
Internet Draft Mobile IP Challenge/Response 25 December 1999
code values listed in RFC 2002, RFC 2344 [8], or RFC 2356 [9], 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).
The MN-RADIUS SPI number discussed in section 5 should be taken from
the space of reserved SPI numbers.
A new number space is to be created for enumerating subtypes of the
Generalized Authentication extension (see section 6).
10. 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). Allowing mobile nodes
with different IP addresses or NAIs to use the same Challenge
value does not represent a security vulnerability, because the
authentication data provided by the mobile node will be computed over
data that is different (at least by the bytes of the mobile nodes' IP
addresses).
11. IPv6 Considerations
For use with IPv6 mobility [6], the challenge extension should
be applied to Router Advertisements [10]. 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 each case.
12. Acknowledgements
The authors would like to thank Tom Hiller, Mark Munson, the TIA
TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their
useful discussions. A recent draft [7] by Mohamed Khalil, Raja
Narayanan, Emad Qaddoura, and Haseeb Akhtar has also suggested the
definition of a generalized authentication extension similar to the
specification contained in section 6.
Perkins, Calhoun Expires 25 June 2000 [Page 8]
Internet Draft Mobile IP Challenge/Response 25 December 1999
References
[1] P. Calhoun and C. Perkins. DIAMETER Mobile IP Extensions.
Internet Draft, Internet Engineering Task Force.
draft-calhoun-diameter-mobileip-01.txt, November 1998. Work in
progress.
[2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. Internet
Draft, Internet Engineering Task Force.
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-05.txt, October 1999. (work in
progress).
[4] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[5] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness
Recommendations for Security. Request for Comments
(Informational) 1750, Internet Engineering Task Force, December
1994.
[6] D. Johnson and C. Perkins. Mobility Support in IPv6.
draft-ietf-mobileip-ipv6-08.txt, June 1999. (work in progress).
[7] Mohamed Khalil, Raja Narayanan, Emad Qaddoura, and Haseeb
Akhtar. Mobile IP Extensions Rationalization (MIER).
draft-mkhalil-mobileip-mier-00.txt, October 1999. (work in
progress).
[8] G. Montenegro. Reverse Tunneling for Mobile IP. Request for
Comments (Proposed Standard) 2344, Internet Engineering Task
Force, May 1998.
[9] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for
Mobile IP. Request for Comments (Informational) 2356, Internet
Engineering Task Force, June 1998.
[10] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[11] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
Perkins, Calhoun Expires 25 June 2000 [Page 9]
Internet Draft Mobile IP Challenge/Response 25 December 1999
[12] C. Perkins and D. Johnson. Route Optimization in Mobile IP.
Internet Draft, Internet Engineering Task Force.
draft-ietf-mobileip-optim-08.txt, February 1999. Work in
progress.
[13] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.
[14] W. Simpson. PPP Challenge Handshake Authentication Protocol
(CHAP). Request for Comments (Draft Standard) 1994, Internet
Engineering Task Force, August 1996.
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
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].
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 8), the foreign agent takes actions
indicated for rejected registrations.
Perkins, Calhoun Expires 25 June 2000 [Page 10]
Internet Draft Mobile IP Challenge/Response 25 December 1999
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| Foreign Agent | | Home Agent |
| | | |
+---------------+ +---------------+
Figure 4: The Verification Infrastructure
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 June 2000 [Page 11]
Internet Draft Mobile IP Challenge/Response 25 December 1999
Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nortel Networks Inc. Motorola
2201 Lakeside Blvd. 1501 West Shure Drive
Richardson, TX. 75082-4399 Arlington Heights, IL 60004
USA USA
Phone: +1 972-684-1489 Phone: +1 847-632-3148
EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com
Questions about this memo can be directed to:
Charles E. Perkins Pat R. Calhoun
Nokia Research Center Sun Microsystems Laboratories
313 Fairchild Drive 15 Network Circle
Mountain View, California 94043 Menlo Park, California 94025
USA USA
Phone: +1-650 625-2986 Phone: +1 650-786-7733
EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com
Fax: +1 650 691-2170 Fax: +1 650-786-6445
Perkins, Calhoun Expires 25 June 2000 [Page 12]
