Mobile IP WG Franck Le
INTERNET-DRAFT Stefano M. Faccin
Date: 23 February 2001 Basavaraj Patil
Expires: 23 August 2001 Nokia Research Center
Challenge-Response Authentication Request
<draft-le-mobileip-authreq-00.txt>
Status of This Memo
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
A mobile IP node may share a security association with its home AAA
server to allow the mobile node to be authenticated when roaming to
different visited domains. The Mobile IP framework has defined some
extensions enabling challenge response based authentication
mechanisms. Currently, the challenge used for the authentication is
generated by the visited domain and broadcasted in Router
Advertisements messages. The mobile node uses this challenge to
compute authentication data when it wants to register to the network.
In order to allow for an easy deployment of Mobile IP for cellular
networks, the security of Mobile IP should be enhanced at least to
match the level of security available nowadays in cellular networks.
Le, Faccin, Patil [Page i]
INTERNET-DRAFT Mobile IP 23 February 2001
For this reason, the home domain need the ability to ask a user to
provide authentication information anytime during a session, and thus
to decide whether the session can be continued or has to be
terminated according to the result of the authentication. In
addition, the visited domain should be able as well to to ask a user
to provide authentication information anytime during a session, thus
allowing the visited domain more control on the roaming. In the same
way, the mobile node should also be able to authenticate the network
at any time. This document specifies extensions to Mobile IP
messages to enable the home domain and the visited domain at any time
during a session to ask a mobile node to provide authentication
credentials. This document also defines the extensions to enable the
mobile node to perform network authentication at any time during a
session.
Le, Faccin, Patil [Page ii]
INTERNET-DRAFT Mobile IP 23 February 2001
1. Introduction
A mobile IP node may share a security association with its home AAA
server to allow the mobile node to be authenticated when roaming to
different visited domains. The Mobile IP framework has defined some
extensions [1], [2] enabling challenge response based authentication
mechanisms. Currently, the challenge used for the authentication is
generated by the visited domain and broadcasted e.g. in Router
Advertisements messages. The mobile node uses this challenge to
compute authentication data when it wants to register to the network.
As indicated above, the home and visited domain need the ability to
ask a user to provide authentication information anytime during a
session, and thus to decide whether the session can be continued or
has to be terminated according to the result of the authentication.
This is needed in order to limit frauds, e.g. to avoid that a
fraudulent mobile node impersonates a legitimate mobile node and
accesses the resources of the visited domain. Possible triggers for
a network initiated user authentication procedure include, e.g., a
periodic timer time-out, the presence of the mobile node in a high-
fraud area, a mobile node "marked" as possibly fraudulent by the home
domain, or an authorization request from the mobile node for certain
resources causing the network to require user re-authentication etc.
Challenge-response based authentication mechanisms provide strong
entity authentication, thus the network should be able at any time to
challenge the mobile node by sending an Authentication Request
message carrying a random number (the challenge) and requesting the
mobile node to authenticate.
Differently from the current challenge-response mechanisms, where the
challenge used for the authentication is generated by the visited
domain and broadcasted in Router Advertisements messages, this
mechanism proposed in this document is user specific. In fact, the
challenge generated by the network is directed to a particular MN
(rather than to all MNs able to receive the broadcasted information,
as it is currently defined). Since the random number for the
challenge is changed for each operation, the proposed authentication
mechanism provides a much more secure user authentication. Whether
the first authentication procedure succeeded or failed, the user
specific challenge authentication can serve as a double check on the
authenticity of the MN.
In the same way, the mobile node should also be able to authenticate
the network by generating a challenge at any time during a session
and sending it to the network.
Le, Faccin, Patil [Page 1]
INTERNET-DRAFT Mobile IP 23 February 2001
2. Mobile IP Authentication Request Extension
The Authentication Request destination option is used to request a
mobile node or the network to authenticate. As a destination option,
the Authentication Request MAY be sent in a packet by itself or MAY
be included in any existing packet being sent to the mobile node when
initiated by the network or by the mobile node when iniated by the
mobile node. A packet containing a Authentication Request option is
sent in the same way as any packet to the receiving end point. When
a mobile node or the network receives a packet containing an
Authentication Request option, it SHOULD return an Authentication
Response to the source of the Authentication Request.
The Authentication Request option is encoded the format 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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Subtype a number assigned to identify the way in
which the Challenge is to be used
Length 4 plus the number of bytes in the Subtype
Data; SHOULD be at least 20.
SPI Security Parameters Index
Challenge The Challenge to be used to compute the
Authentication data
3. Mobile IP Authentication Response Extension
The Authentication Response destination option is sent in response to
an Authentication Request option sent by the mobile node or the
Le, Faccin, Patil [Page 2]
INTERNET-DRAFT Mobile IP 23 February 2001
network respectively to the network or the mobile node in order to
provide the authentication data.
Authentication Response destination option MAY be sent in a packet by
itself or MAY be included in any existing packet being sent to the
mobile node by the network or by the mobile node to the network. A
packet containing a Authentication Response option is sent in the
same way as any packet to the receiving end point.
The Authentication Response option is encoded the format 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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Subtype a number assigned to identify the way in
which the Challenge is used
Length 4 plus the number of bytes in the Subtype
Data; SHOULD be at least 20.
SPI Security Parameters Index
Authenticator The variable length Authenticator field
4. Request-Response matching scheme
It is possible that the Home/Visited network or the MN sends an
authentication request respectively to the MN or the Home/Visited
network and, after a few seconds, it sends another authentication
request which has a different challenge encoded in it. The receiving
end point may never receive the first authentication request (e.g. a
message is lost on the access link) and receive only the second
authentication request. In this situation, when an authentication
response is sent back to the Home/Visited network or the MN (i.e. the
Le, Faccin, Patil [Page 3]
INTERNET-DRAFT Mobile IP 23 February 2001
entity initiating the authentication procedure), the Home/Visited
network or the MN needs to know which authentication request the the
authentication response was received for in order to perform the
correct validation of the authentication data received.
Two options are possible: the entity receiving the authentication
request includes the challenge received in the authentication request
in the authentication response message, or the entity initiating the
authentication procedure includes a Challenge_Identifier in the
Authentication Request extension and the entity receiving the
authentication request includes the Challenge_Identifier in the
authentication response.
4.1. Basic Request-Response matching scheme
In this first option, the entity receiving the authentication request
includes the challenge received in the authentication request in the
authentication response message.
Consistently to [1], the additional destination option containing the
challenge used for the authentication is added to the message
containing the authentication response and has the following format.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Optimized Request-Response Matching Scheme
There may be some cases where there is the need to optimize the
information used for authentication over the access link, e.g.
wireless links where the radio resources are limited. In such cases,
including the Challenge in the authentication response may make the
header too large. A solution for this case is that the entity
initiating the authentication procedure includes a
Challenge_Identifier in the Authentication Request extension, e.g. in
the format of a timestamp or a counter, and the entity receiving the
Le, Faccin, Patil [Page 4]
INTERNET-DRAFT Mobile IP 23 February 2001
authentication request includes this Challenge_Identifier in the
authentication response for the authenticator can know which
challenge the response corresponds to.
5. Applicability to Mobile IPv4
The extensions defined in this document are specific to Mobile IPv6
but similar extensions can be defined for Mobile IPv4 enabling any
entity to request authentication at any time. The same concept can
therefore apply to Mobile IPv4.
6. Security Considerations
This document specifies extensions to Mobile IP messages to carry the
parameters to perform either user specific or network challenge
response based authentication mechanism, but does not define the
algorithms to use to process the authentication data.
Le, Faccin, Patil [Page 5]
INTERNET-DRAFT Mobile IP 23 February 2001
7. References
[1] C. Perkins and P. Calhoun. Mobile IPv4 Challenge/Response
Extensions. Request for Comments 3012, Internet Engineering
Task Force, November 2000.
[2] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas
Eklund AAA for IPv6 Network Access. Internet Draft,
Internet Engineering Task Force, January 2000.
Le, Faccin, Patil [Page 6]
INTERNET-DRAFT Mobile IP 23 February 2001
8. Authors' Addresses
Franck Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-1256
E-mail: franck.le@nokia.com
Stefano M. Faccin
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4994
E-mail: stefano.faccin@nokia.com
Basavaraj Patil
Nokia Corporation
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972-894-6709
E-Mail: Raj.Patil@nokia.com
Le, Faccin, Patil [Page 7]
INTERNET-DRAFT Mobile IP 23 February 2001
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Mobile IP Authentication Request Extension . . . . . . . . . . . 2
3. Mobile IP Authentication Response Extension . . . . . . . . . . . 2
4. Request-Response matching scheme . . . . . . . . . . . . . . . . 3
4.1. Basic Request-Response matching scheme . . . . . . . . . . . 4
4.2. Optimized Request-Response Matching Scheme . . . . . . . . . 4
5. Applicability to Mobile IPv4 . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Le, Faccin, Patil [Page iii]