One document matched: draft-perkins-netext-eapbu-01.xml
<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200811" category="info" docName="draft-perkins-netext-eapbu-01.txt">
<front>
<title abbrev="Optimizing MIP/PMIP EAP Authentication">
Optimizing IP Mobility Authentication with EAP</title>
<author initials="C.P." surname="Perkins" fullname="Charles E. Perkins">
<organization>Tellabs</organization>
<address>
<phone>+1-408-970-6560</phone>
<email>charliep@tellabs.com</email>
</address>
</author>
<author initials="B" surname="Patil" fullname="Basavaraj Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection Drive</street>
<city>Irving,</city>
<code>TX 75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<date day='26' month='Oct' year='2011'/>
<area>Internet</area>
<workgroup>NETLMM extensions [netext]</workgroup>
<keyword>I-D</keyword>
<keyword>Internet Draft</keyword>
<!-- <t><vspace blankLines="6" /></t> -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor='introduction' title='Introduction'>
<t>
The Extensible Authentication Protocol (EAP) <xref target="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 <xref target="RFC6275"/>, the
Binding Authentication Data option <xref target="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.
</t>
</section>
<section anchor='PS' title='Problem Statement'>
<t>
Mobile IPv6 <xref target="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.
</t>
<t>
In the case of network based mobility, i.e Proxy Mobile IPv6
<xref target="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.
</t>
<t>
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.
</t>
</section>
<section anchor='Proposal' title='Proposed Solution'>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section anchor='Example' title='Example'>
<t>
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.
</t>
<figure anchor="examplefig" title="Example of combined authentication and registration">
<artwork><![CDATA[
MN NAS HA AAA
| | | |
|<--Attach=-------->| | |
| | | |
|<---Access Authentication routed via the HA-------->|
| | | |
| | |<-Auth Resp---|
|<------------------------------------| |
| | |HA Updates |
| | |Binding cache |
| | | |
]]></artwork>
</figure>
</section>
</section>
<!-- Open questions that we need to think about:
0. Regarding the title "Enabling EAP methods for MIP6:
- MIP6 already supports EAP authentication. IKEv2 is used for
establishing the IPsec SAs between the MN and HA. IKEv2 can perform
authentication using any EAP method.
- I would propose the title as "Optimizing IP Mobility
authentication" (This will make it applicable for MIP6 and PMIP6)
1. Access authentication needs to be performed at every network the MN
attaches to. This model is not going to change since operators who
invest in the infrastructure would like to make sure they are
providing access to users who are authenticated and authorized (in
other words they have a way to charge them).
2. Mobile IPv6 authentication and setup of the SAs happens only at the
time of registration. Once the SAs are setup there is no more MIP6
authentications. Subsequent registrations as a result of change of CoA
utilize the already established SA and in effect there is no 2nd
authentication.
3. In the case of Proxy MIP6, the MAG is the entity which has the SA
with the LMA. The MAG is on the path of the access authentication. The
MAG entity is included within the NAS of the access network. When
access authentication response is received, the MAG triggers the PBU
to the LMA and since this registration is being sent over an existing
SA the LMA will simply accept and process the PBU and create the
binding. So there is no second authentication per se.
4. For the upcoming meeting, I think we should spend time on
discussing the problem and how a more optimal approach can be
specified rather than any specific solution. Hence it would be okay to
go ahead and submit this I-D and then work on it some more in the
coming week.
5. I still have several doubts about the problem and proposed
solution. We need to have a brainstorming discussion. Let me schedule
a meeting at IETF82 and include Sri and Kent as well.
-->
<section anchor='EAP_type' title='EAP subtype for Binding Authentication Data'>
<t>
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:
<figure><artwork>
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure>
</t>
<t>
Please consult the EAP specification <xref target="RFC3748"/> for
details about these header fields.
</t>
<!--
<t>
</t>
-->
</section>
<section anchor="BAck_AD"
title="Binding Acknowledgement Authentication Data option">
<t>
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.
<figure><artwork>
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure>
</t>
<t>
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.
</t>
</section>
<section anchor="EAP_AKA_example"
title="Example of use with EAP-AKA">
<t>
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
<xref target="RFC4187"/>. A very similar procedure will
also work for EAP-AKA' <xref target="RFC5448"/>.
</t>
<t>
<figure><artwork>
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
</artwork>
</figure>
</t>
<t>
where:
<list style='hanging'>
<t hangText='Process A'> <vspace blankLines='1' />
means "Server runs AKA algorithms, generates RAND and AUTN."
</t>
<t hangText='Process B'> <vspace blankLines='1' />
means "Peer runs AKA algorithms, verifies AUTN and MAC, derives RES and session key"
</t>
<t hangText='Process C'> <vspace blankLines='1' />
means "Server checks the given RES, and MAC and finds them correct."
</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This document requires allocation of a new subtype for the
Binding Authentication Option of Mobile IPv6.
</t>
<t>
This document specifies the Binding Acknowledgement Data option,
which is a new option for the Binding Acknowledgement message of
Mobile IPv6.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.3748.xml'?>
<?rfc include='reference.RFC.4285.xml'?>
<?rfc include='reference.RFC.6275.xml'?>
</references>
<references title="Informational References">
<?rfc include='reference.RFC.4187.xml'?>
<?rfc include='reference.RFC.5213.xml'?>
<?rfc include='reference.RFC.5448.xml'?>
</references>
<!--
<section anchor="acknowledgements" title="Acknowledgements">
<t>
This document stems from discussions with the following people,
in alphabetical order:
</t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:18 |