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]