Optimizing IP Mobility Authentication with EAPTellabs+1-408-970-6560charliep@tellabs.comNokia6021 Connection DriveIrving,TX 75039USAbasavaraj.patil@nokia.com
Internet
NETLMM extensions [netext]I-DInternet Draft
The Extensible Authentication Protocol (EAP) is commonly
used for access authentication in many wireless networks.
EAP methods often involve AAA servers to effect the
required authentications; notifications about success or
failure are then relayed back to a functional module in
the access network known as the Network Access Server.
The Binding Authentication Data option has been defined
for enabling alternative methods for authentication in the
context of Mobile IPv6, and there is a subtype allocated for
AAA-based authentication methods such as EAP. However, some
EAP methods require additional handling
that requires specification not yet available in the existing
documentation for the Binding Authentication Data option.
This document provides the required specification for at least
some very widely deployed EAP methods. In many situations requiring
the use of EAP, this enables much faster operation for Mobile IPv6
tunnel redirection to a wireless device's new care-of address
by avoiding having to do multiple authentications.
The Extensible Authentication Protocol (EAP)
is commonly used for access authentication in many wireless
networks.
EAP methods often involve AAA servers to effect the
required authentications; notifications are then relayed back to
a functional module in the access network known as the Network
Access Server.
For Mobile IPv6 , the
Binding Authentication Data option
has been defined for enabling alternative methods for authentication,
and a subtype has been allocated for AAA-based authentication methods
such as EAP. However, some EAP methods require additional handling
that requires specification not yet available in the existing
documentation for the Binding Authentication Data option.
This document provides the required specification for at least
some very widely deployed EAP methods. In many situations requiring
the use of EAP, this enables much faster operation for Mobile IPv6
tunnel redirection to a wireless device's new care-of address.
Mobile IPv6 requires the mobile node (MN) to
authenticate with its assigned home agent. Establishing an IPsec
SA is accomplished after the MN has been authenticated. EAP
methods may be used within IKEv2 to authenticate the MN and then
establish the MN's IPsec security association (SA). The authentication
and establishment of
the IPsec SA is required in addition to access network
authentication. Most networks require a user/device to authenticate
prior to be being connected to the network. This results in the MN
having to perform two authentications. The MN has to first
perform access authentication and then authenticate again for a
second time with the home agent to establish the IPsec SA. This
causes significant delay in the MN being registered with the
HA. It should be noted that when the MN moves to a different
access network, access network authentication is typically
performed. However, when the IPsec SA already exists, that SA only needs
to be updated with the changed end-point. This can be achieved by
setting the 'K' bit in the
binding update sent from the new care-of-address.
In the case of network based mobility, i.e Proxy Mobile IPv6
the Mobility Access Gateway (MAG)
performs registration with the Local Mobility Agent (LMA)
following access authentication. The MAG receives confirmation
from a AAA server if the MN is authorized for mobility service and
only after that does it send the proxy binding update to the
LMA.
Combining access authentication with mobility authentication
results in an optimization and faster connectivity. How to
optimize or combine the access authentication with the
authentication required for obtaining mobility service is the
problem dealt with in this document.
The proposal contained in this I-D is to combine access
authentication with Mobile IPv6 authentication. As a result it
saves at least one authentication sequence and hence speeds up the
process of sending and receiving packets via the home agent or
LMA.
EAP is commonly used for access authentication. Many of the EAP
authentication methods interact with a AAA server which contain
the credentials of the user. The NAS element in an access network
is essentially a AAA relay entity. The proposal contained in this
document aims to utilize the information available to the NAS from
the access authentication phase to perform Mobile IP
authentication as well. The extensions needed to EAP and the
Mobile IP signaling are described in the following sections.
The basic idea is to route the access authentication signaling
messages via the HA/LMA and thereby perform authentication and
registration in a single transaction. The HA acts as a relay
entity in the access authentication procedure and is aware of the
result of the authentication procedure and can act on it by
updating the binding cache.
The figure below shows an example of the solution which combines
access authentication with mobility registration. In the figure
the MN is presumed to already have a binding at the
HA. Additionally the same scenario can be considered applicable
to the network based mobility solution in which case the MAG
routes the access authentication messages via the LMA.
This specification defines a new subtype, called the EAP
Authentication Data [EAPAD] subtype, for the Binding
Authentication Data suboption for Mobile IPv6. The EAPAD
subtype has the following format, which is identical to the
EAP message format:
Please consult the EAP specification for
details about these header fields.
The Binding Acknowledgement Authentication Data option [BAckAD]
is specified to enable the EAP method to return data from the
AAA server back to the Authenticator and the Peer as may
be required by the EAP method specification. The nature of
the data returned in the BAckAD depends on the method. The
EAP message is of type EAP Success or EAP Failure.
The Subtype for the Binding Acknowledgement Authentication
Data option is 0, for EAP methods. There is no need for the
SPI field. The Type-Data is the EAP method-specific data. Since
this option appears in the Binding Acknowledgement
(or Proxy Binding Acknowledgement) message,
the Code will either correspond to EAP-Success or EAP-Failure.
The following figure shows how to use the new Binding
Authentication Data subtype along with the new Binding
Acknowledgement Authentication Data subtype with EAP-AKA
. A very similar procedure will
also work for EAP-AKA' .
where:
means "Server runs AKA algorithms, generates RAND and AUTN."
means "Peer runs AKA algorithms, verifies AUTN and MAC, derives RES and session key"
means "Server checks the given RES, and MAC and finds them correct."
This document introduces a new subtype for the
Binding Authentication Data of Mobile IPv6. The security
characteristics for the authentication data are exactly those
of the base EAP method which defines the data fields and
security parameters for the new subtype.
This document specifies the Binding Acknowledgement Data option,
which is a new option for the Binding Acknowledgement message of
Mobile IPv6. The security characteristics for the new
option are exactly those
of the base EAP method which defines the data fields and
security parameters for the new option.
The Mobile-Home Authentication extension is still also required
for the Binding Acknowledgement, but additional security features
and notifications may be included in the EAP method data
defining the contents of the new option.
PMIP uses the same message format for BAck, and the new
option works in the same way whether or not the 'P' bit is set.
This document requires allocation of a new subtype for the
Binding Authentication Option of Mobile IPv6.
This document specifies the Binding Acknowledgement Data option,
which is a new option for the Binding Acknowledgement message of
Mobile IPv6.