Mobile IP Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
25 October 1999 Pat R. Calhoun
Sun Microsystems Laboratories
Mobile IP Challenge/Response Extensions
draft-ietf-mobileip-challenge-04.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 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 April 2000 [Page i]
Internet Draft Mobile IP Challenge/Response 25 October 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 April 2000 [Page 1]
Internet Draft Mobile IP Challenge/Response 25 October 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 MUST include the MN-AAA Authentication
extension as defined in section 4.2, or the MN-RADIUS extension as
defined in section 4.3. 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. The
MN-RADIUS extension only supports CHAP-style authentication [13]
using MD5 [12], and the SPI field MAY be set to any value.
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 April 2000 [Page 2]
Internet Draft Mobile IP Challenge/Response 25 October 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 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, a MN-AAA Authentication, or a MN-RADIUS 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 5 in the Appendix).
If the MN-RADIUS extension (see Section 4.3) is present, the foreign
agent SHOULD forward the request to the Home Agent, and does not need
to interact with the verification infrastructure.
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
Perkins, Calhoun Expires 25 April 2000 [Page 3]
Internet Draft Mobile IP Challenge/Response 25 October 1999
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]. 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 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.
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.
Perkins, Calhoun Expires 25 April 2000 [Page 4]
Internet Draft Mobile IP Challenge/Response 25 October 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 | Length | Challenge...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The MN-FA Challenge Extension
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).
4.2. MN-AAA Authentication Extension
The mobile node MAY include this extension in the Registration
Request. If the mobile node does not include a Mobile-Foreign
Authentication extension, then it MUST include the MN-AAA
Authentication extension [11] or the MN-RADIUS extension
(section 4.3) whenever the Challenge extension is present.
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
Perkins, Calhoun Expires 25 April 2000 [Page 5]
Internet Draft Mobile IP Challenge/Response 25 October 1999
Type 36 (not skippable) (see [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.
4.3. MN-RADIUS Extension
The mobile node MAY include this extension in the Registration
Request if it has a security association with a RADIUS server. If
the mobile node does not include a Mobile-Foreign Authentication
extension, then it MUST include either the MN-AAA or the MN-RADIUS
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 4: The MN-RADIUS Extension
Perkins, Calhoun Expires 25 April 2000 [Page 6]
Internet Draft Mobile IP Challenge/Response 25 October 1999
Type 37 (not skippable) (see [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 || 240 bytes (or less) of preceding Mobile IP data ||
Type, Length, SPI
where the Type, Length, and SPI are as shown above. Since the
RADIUS protocol cannot carry objects greater than 253 in size, it is
necessary that only the first 240 bytes of the preceding Mobile IP
data be used. The challenge extension MUST be present in the first
240 bytes of the Registration Request.
5. 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
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 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
Perkins, Calhoun Expires 25 April 2000 [Page 7]
Internet Draft Mobile IP Challenge/Response 25 October 1999
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).
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). 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).
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 each case.
Perkins, Calhoun Expires 25 April 2000 [Page 8]
Internet Draft Mobile IP Challenge/Response 25 October 1999
10. 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.
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-04.txt,
September 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.
[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.
Perkins, Calhoun Expires 25 April 2000 [Page 9]
Internet Draft Mobile IP Challenge/Response 25 October 1999
[12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992.
[13] W. Simpson. RFC 1994: PPP challenge handshake authentication
protocol (CHAP), August 1996. Obsoletes RFC1334. Status: DRAFT
STANDARD.
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 5. 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 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.
Perkins, Calhoun Expires 25 April 2000 [Page 10]
Internet Draft Mobile IP Challenge/Response 25 October 1999
+----------------------------------------------------+
| |
| Verification and Key Management Infrastructure |
| |
+----------------------------------------------------+
^ | ^ |
| | | |
| v | v
+---------------+ +---------------+
| | | |
| Foreign Agent | | Home Agent |
| | | |
+---------------+ +---------------+
Figure 5: The Verification Infrastructure
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 April 2000 [Page 11]
Internet Draft Mobile IP Challenge/Response 25 October 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 April 2000 [Page 12]