Optimizing IP Mobility Authentication with EAP
draft-perkins-netext-eapbu-00.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."

Copyright Notice

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.

Table of Contents

• 1. Introduction
• 2. Problem Statement
• 3. Proposed Solution
• 4. EAP subtype for Binding Authentication Data
• 5. Binding Acknowledgement Authentication Data option
• 6. Example of use with EAP-AKA
• 7. Security Considerations
• 8. IANA Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informational References
• Authors' Addresses

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 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.

4. EAP subtype for Binding Authentication Data

    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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

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 [RFC3748] for details about these header fields.

5. Binding Acknowledgement Authentication Data option

    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 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 message, the Code will either correspond to EAP-Success or EAP-Failure.

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       Home     AAA Server
        |                            |             Agent        |
        | 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  |
        |<---------------------------+<--------------+<---------|

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"

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.

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

9.2. Informational References

Authors' Addresses