Internet DRAFT - draft-perkins-netext-eapbu
draft-perkins-netext-eapbu
NETLMM extensions [netext] C. Perkins
Internet-Draft Tellabs
Intended status: Informational B. Patil
Expires: April 28, 2012 Nokia
Oct 26, 2011
Optimizing IP Mobility Authentication with EAP
draft-perkins-netext-eapbu-01.txt
Abstract
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.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 28, 2012.
Copyright Notice
Perkins & Patil Expires April 28, 2012 [Page 1]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. EAP subtype for Binding Authentication Data . . . . . . . . . . 5
5. Binding Acknowledgement Authentication Data option . . . . . . 5
6. Example of use with EAP-AKA . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informational References . . . . . . . . . . . . . . . . . 8
Perkins & Patil Expires April 28, 2012 [Page 2]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] 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 [RFC6275], the Binding Authentication Data option
[RFC4285] 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.
2. Problem Statement
Mobile IPv6 [RFC6275] 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
[RFC5213] 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
Perkins & Patil Expires April 28, 2012 [Page 3]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
combine the access authentication with the authentication required
for obtaining mobility service is the problem dealt with in this
document.
3. Proposed Solution
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.
3.1. Example
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.
MN NAS HA AAA
| | | |
|<--Attach=-------->| | |
| | | |
|<---Access Authentication routed via the HA-------->|
| | | |
| | |<-Auth Resp---|
|<------------------------------------| |
| | |HA Updates |
| | |Binding cache |
| | | |
Perkins & Patil Expires April 28, 2012 [Page 4]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
Figure 1: Example of combined authentication and registration
4. EAP subtype for Binding Authentication Data
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Please consult the EAP specification [RFC3748] for details about
these header fields.
5. Binding Acknowledgement Authentication Data option
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
Perkins & Patil Expires April 28, 2012 [Page 5]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
6. Example of use with EAP-AKA
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 [RFC4187]. A very similar
procedure will also work for EAP-AKA' [RFC5448].
Peer Authenticator LMA AAA Server
| | | |
| EAP-Request/Identity | | |
|<---------------------------| | |
| | | |
| EAP-Response/Identity | | |
| (Includes user''s NAI) | | |
|--------------------------->+------------------------->|
| | | +-----------+
| | | | Process A |
| | | +-----------+
| EAP-Request/AKA-Challenge | | |
| (AT_RAND, AT_AUTN, AT_MAC) | | |
|<---------------------------+<-------------------------|
+-----------+ | | |
| Process B | | | |
+-----------+ | | |
| EAP-Response/AKA-Challenge | PBU | EAP |
| (AT_RES, AT_MAC) |(EAP-Response) | Response |
|--------------------------->+-------------->+--------->|
| | | +-----------+
| | | | Process C |
| | PBAck | EAP +-----------+
| | (EAP-Success)| Success |
|<---------------------------+<--------------+<---------|
Figure 2: Use of EAPAD and BAckAD in EAP-AKA Authentication
where:
Process A
means "Server runs AKA algorithms, generates RAND and AUTN."
Process B
means "Peer runs AKA algorithms, verifies AUTN and MAC, derives
RES and session key"
Perkins & Patil Expires April 28, 2012 [Page 6]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
Process C
means "Server checks the given RES, and MAC and finds them
correct."
7. Security Considerations
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.
8. IANA Considerations
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.
9. References
9.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Perkins & Patil Expires April 28, 2012 [Page 7]
Internet-Draft Optimizing MIP/PMIP EAP Authentication Oct 2011
9.2. Informational References
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, May 2009.
Authors' Addresses
Charles E. Perkins
Tellabs
Phone: +1-408-970-6560
EMail: charliep@tellabs.com
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nokia.com
Perkins & Patil Expires April 28, 2012 [Page 8]
