GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5836

Internet Engineering Task Force (IETF) Y. Ohba Request for Comments: 5836 Toshiba Category: Informational Q. Wu, Ed. ISSN: 2070-1721 Huawei

                                                          G. Zorn, Ed.
                                                           Network Zen
                                                            April 2010
              Extensible Authentication Protocol (EAP)
               Early Authentication Problem Statement

Abstract

 Extensible Authentication Protocol (EAP) early authentication may be
 defined as the use of EAP by a mobile device to establish
 authenticated keying material on a target attachment point prior to
 its arrival.  This document discusses the EAP early authentication
 problem in detail.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5836.

Ohba, et al. Informational [Page 1] RFC 5836 Early Authentication PS April 2010

Copyright Notice

 Copyright (c) 2010 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.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Ohba, et al. Informational [Page 2] RFC 5836 Early Authentication PS April 2010

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................4
 3. Problem Statement ...............................................6
    3.1. Handover Preparation .......................................6
    3.2. Handover Execution .........................................6
         3.2.1. Examples ............................................7
    3.3. Solution Space .............................................7
         3.3.1. Context Transfer ....................................7
         3.3.2. Early Authentication ................................8
 4. System Overview .................................................8
 5. Topological Classification of Handover Scenarios ................9
 6. Models of Early Authentication .................................10
    6.1. EAP Pre-Authentication Usage Models .......................10
         6.1.1. The Direct Pre-Authentication Model ................11
         6.1.2. The Indirect Pre-Authentication Usage Model ........11
    6.2. The Authenticated Anticipatory Keying Usage Model .........13
 7. Architectural Considerations ...................................13
    7.1. Authenticator Discovery ...................................13
    7.2. Context Binding ...........................................14
 8. AAA Issues .....................................................14
 9. Security Considerations ........................................16
 10. Acknowledgments ...............................................17
 11. Contributors ..................................................17
 12. References ....................................................17
    12.1. Normative References .....................................17
    12.2. Informative References ...................................18

1. Introduction

 When a mobile device, during an active communication session, moves
 from one access network to another and changes its attachment point,
 the session may be subjected to disruption of service due to the
 delay associated with the handover operation.  The performance
 requirements of a real-time application will vary based on the type
 of application and its characteristics such as delay and packet-loss
 tolerance.  For Voice over IP applications, ITU-T G.114 [ITU]
 recommends a steady-state end-to-end delay of 150 ms as the upper
 limit and rates 400 ms as generally unacceptable delay.  Similarly, a
 streaming application has tolerable packet-error rates ranging from
 0.1 to 0.00001 with a transfer delay of less than 300 ms.  Any help
 that an optimized handoff mechanism can provide toward meeting these
 objectives is useful.  The ultimate objective is to achieve seamless
 handover with low latency, even when handover is between different
 link technologies or between different Authentication, Authorization,
 and Accounting (AAA) realms.

Ohba, et al. Informational [Page 3] RFC 5836 Early Authentication PS April 2010

 As a mobile device goes through a handover process, it is subjected
 to delay because of the rebinding of its association at or across
 several layers of the protocol stack and because of the additional
 round trips needed for a new EAP exchange.  Delays incurred within
 each protocol layer affect the ongoing multimedia application and
 data traffic within the client [WCM].
 The handover process often requires authentication and authorization
 for acquisition or modification of resources assigned to the mobile
 device.  In most cases, these authentications and authorizations
 require interaction with a central authority in a realm.  In some
 cases, the central authority may be distant from the mobile device.
 The delay introduced due to such an authentication and authorization
 procedure adds to the handover latency and consequently affects
 ongoing application sessions [MQ7].  The discussion in this document
 is focused on mitigating delay due to EAP authentication.

2. Terminology

 AAA
    Authentication, Authorization, and Accounting (see below).  RADIUS
    [RFC2865] and Diameter [RFC3588] are examples of AAA protocols
    defined in the IETF.
 AAA realm
    The set of access networks within the scope of a specific AAA
    server.  Thus, if a mobile device moves from one attachment point
    to another within the same AAA realm, it continues to be served by
    the same AAA server.
 Accounting
    The act of collecting information on resource usage for the
    purpose of trend analysis, auditing, billing, or cost allocation
    [RFC2989].
 Attachment Point
    A device, such as a wireless access point, that serves as a
    gateway between access clients and a network.  In the context of
    this document, an attachment point must also support EAP
    authenticator functionality and may act as a AAA client.
 Authentication
    The act of verifying a claimed identity, in the form of a
    preexisting label from a mutually known name space, as the
    originator of a message (message authentication) or as the end-
    point of a channel (entity authentication) [RFC2989].

Ohba, et al. Informational [Page 4] RFC 5836 Early Authentication PS April 2010

 Authenticator
    The end of the link initiating EAP authentication [RFC3748].
 Authorization
    The act of determining if a particular right, such as access to
    some resource, can be granted to the presenter of a particular
    credential [RFC2989].
 Candidate Access Network
    An access network that can potentially become the target access
    network for a mobile device.  Multiple access networks may be
    candidates simultaneously.
 Candidate Attachment Point (CAP)
    An attachment point that can potentially become the target
    attachment point for a mobile device.  Multiple attachment points
    may be candidates simultaneously.
 Candidate Authenticator (CA)
    The EAP authenticator on the CAP.
 EAP Server
    The entity that terminates the EAP authentication method with the
    peer [RFC3748].  EAP servers are often, but not necessarily,
    co-located with AAA servers, using a AAA protocol to communicate
    with remote pass-through authenticators.
 Inter-AAA-realm Handover (Inter-realm Handover)
    A handover across multiple AAA realms.
 Inter-Technology Handover
    A handover across different link-layer technologies.
 Intra-AAA-realm Handover (Intra-realm Handover)
    A handover within the same AAA realm.  Intra-AAA-realm handover
    includes a handover across different authenticators within the
    same AAA realm.
 Intra-Technology Handover
    A handover within the same link-layer technology.
 Master Session Key (MSK)
    Keying material that is derived between the EAP peer and server
    and exported by the EAP method [RFC3748].
 Peer
    The entity that responds to the authenticator and requires
    authentication [RFC3748].

Ohba, et al. Informational [Page 5] RFC 5836 Early Authentication PS April 2010

 Serving Access Network
    An access network that is currently serving the mobile device.
 Serving Attachment Point (SAP)
    An attachment point that is currently serving the mobile device.
 Target Access Network
    An access network that has been selected to be the new serving
    access network for a mobile device.
 Target Attachment Point (TAP)
    An attachment point that has been selected to be the new SAP for a
    mobile device.

3. Problem Statement

 The basic mechanism of handover is a two-step procedure involving
 o  handover preparation and
 o  handover execution

3.1. Handover Preparation

 Handover preparation includes the discovery of candidate attachment
 points and selection of an appropriate target attachment point from
 the candidate set.  Handover preparation is outside the scope of this
 document.

3.2. Handover Execution

 Handover execution consists of setting up Layer 2 (L2) and Layer 3
 (L3) connectivity with the TAP.  Currently, handover execution
 includes network access authentication and authorization performed
 directly with the target network; this may include full EAP
 authentication in the absence of any particular optimization for
 handover key management.  Following a successful EAP authentication,
 a secure association procedure is typically performed between the
 mobile device and the TAP to derive a new set of link-layer
 encryption keys from EAP keying material such as the MSK.  The
 handover latency introduced by full EAP authentication has proven to
 be higher than that which is acceptable for real-time application
 scenarios [MQ7]; hence, reduction in handover latency due to EAP is a
 necessary objective for such scenarios.

Ohba, et al. Informational [Page 6] RFC 5836 Early Authentication PS April 2010

3.2.1. Examples

3.2.1.1. IEEE 802.11

 In IEEE 802.11 Wireless Local Area Networks (WLANs)
 [IEEE.802-11.2007] network access authentication and authorization
 involves performing a new IEEE 802.1X [IEEE.802-1X.2004] message
 exchange with the authenticator in the TAP to execute an EAP exchange
 with the authentication server [WPA].  There has been some
 optimization work undertaken by the IEEE, but these efforts have been
 scoped to IEEE link-layer technologies; for example, the work done in
 the IEEE 802.11f [IEEE.802-11F.2003] and 802.11r [IEEE.802-11R.2008]
 Task Groups applies only to intra-technology handovers.

3.2.1.2. 3GPP TS33.402

 The Third Generation Partnership Project (3GPP) Technical
 Specification 33.402 [TS33.402] defines the authentication and key
 management procedures performed during interworking between non-3GPP
 access networks and the Evolved Packet System (EPS).  Network access
 authentication and authorization happens after the L2 connection is
 established between the mobile device and a non-3GPP target access
 network, and involves an EAP exchange between the mobile device and
 the 3GPP AAA server via the non-3GPP target access network.  These
 procedures are not really independent of link technology, since they
 assume either that the authenticator lies in the EPS network or that
 separate authentications are performed in the access network and then
 in the EPS network.

3.3. Solution Space

 As the examples in the preceding sections illustrate, a solution is
 needed to enable EAP early authentication for inter-AAA-realm
 handovers and inter-technology handovers.  A search for solutions at
 the IP level may offer the necessary technology independence.
 Optimized solutions for secure inter-authenticator handovers can be
 seen either as security context transfer (e.g., using the EAP
 Extensions for EAP Re-authentication Protocol (ERP)) [RFC5296], or as
 EAP early authentication.

3.3.1. Context Transfer

 Security context transfer involves transfer of reusable key context
 to the TAP and can take two forms: horizontal and vertical.

Ohba, et al. Informational [Page 7] RFC 5836 Early Authentication PS April 2010

 Horizontal security context transfer (e.g., from SAP to TAP) is not
 recommended because of the possibility that the compromise of one
 attachment point might lead to the compromise of another (the
 so-called domino effect, [RFC4962]).  Vertical context transfer is
 similar to the initial establishment of keying material on an
 attachment point in that the keys are sent from a trusted server to
 the TAP as a direct result of a successful authentication.  ERP
 specifies vertical context transfer using existing EAP keying
 material obtained from the home AAA server during the initial
 authentication.  A cryptographically independent re-authentication
 key is derived and transmitted to the TAP as a result of successful
 ERP authentication.  This reduces handover delay for intra-realm
 handovers by eliminating the need to run full EAP authentication with
 the home EAP server.
 However, in the case of inter-realm handover, either ERP is not
 applicable or an additional optimization mechanism is needed to
 establish a key on the TAP.

3.3.2. Early Authentication

 In EAP early authentication, AAA-based authentication and
 authorization for a CAP is performed while ongoing data communication
 is in progress via the serving access network, the goal being to
 complete AAA signaling for EAP before the mobile device moves.  The
 applicability of EAP early authentication is limited to the scenarios
 where candidate authenticators can be discovered and an accurate
 prediction of movement can be easily made.  In addition, the
 effectiveness of EAP early authentication may be less significant for
 particular inter-technology-handover scenarios where simultaneous use
 of multiple technologies is not a major concern.
 There are also several AAA issues related to EAP early
 authentication, discussed in Section 8.

4. System Overview

 Figure 1 shows the functional elements that are related to EAP early
 authentication.  These functional elements include a mobile device, a
 SAP, a CAP, and one or more AAA and EAP servers; for the sake of
 convenience, the AAA and EAP servers are represented as being
 co-located.  When the SAP and CAP belong to different AAA realms, the
 CAP may require a different set of user credentials than those used
 by the peer when authenticating to the SAP.  Alternatively, the CAP
 and the SAP may rely on the same AAA server, located in the home
 realm of the mobile device (MD).

Ohba, et al. Informational [Page 8] RFC 5836 Early Authentication PS April 2010

       +------+      +-------+      +---------+      +---------+
       |  MD  |------|  SAP  |------|         |      |         |
       +------+      +-------+      |   IP    |      | EAP/AAA
          .                         |         |------|         |
          . Move                    | Network |      | Server  |
          v          +-------+      |         |      |         |
                     |  CAP  |------|         |      |         |
                     +-------+      +---------+      +---------+
        Figure 1: EAP Early Authentication Functional Elements
 A mobile device is attached to the serving access network.  Before
 the MD performs handover from the serving access network to a
 candidate access network, it performs EAP early authentication with a
 candidate authenticator via the serving access network.  The peer may
 perform EAP early authentication with one or more candidate
 authenticators.  It is assumed that each attachment point has an IP
 address.  It is assumed that there is at least one CAP in each
 candidate access network.  The serving and candidate access networks
 may use different link-layer technologies.
 Each authenticator is either a standalone authenticator or a pass-
 through authenticator [RFC3748].  When an authenticator acts as a
 standalone authenticator, it also has the functionality of an EAP
 server.  When an authenticator acts as a pass-through authenticator,
 it communicates with the EAP server, typically using a AAA transport
 protocol such as RADIUS [RFC2865] or Diameter [RFC3588].
 If the CAP uses an MSK [RFC5247] for generating lower-layer ciphering
 keys, EAP early authentication is used to proactively generate an MSK
 for the CAP.

5. Topological Classification of Handover Scenarios

 The complexity of the authentication and authorization part of
 handover depends on whether it involves a change in EAP server.
 Consider first the case where the authenticators operate in pass-
 through mode, so that the EAP server is co-located with a AAA server.
 Then, there is a strict hierarchy of complexity, as follows:
 1.  inter-attachment-point handover with common AAA server: the CAP
     and SAP are different entities, but the AAA server is the same.
     There are two sub-cases here:
     (a)  the AAA server is common because both attachment points lie
          within the same network, or

Ohba, et al. Informational [Page 9] RFC 5836 Early Authentication PS April 2010

     (b)  the AAA server is common because AAA entities in the serving
          and candidate networks proxy to a AAA server in the home
          realm.
 2.  inter-AAA-realm handover: the CAP and SAP are different entities,
     and the respective AAA servers also differ.  As a result,
     authentication in the candidate network requires a second set of
     user credentials.
 A third case is where one or both authenticators are co-located with
 an EAP server.  This has some of the characteristics of an inter-AAA-
 realm handover, but offers less flexibility for resolution of the
 early authentication problem.
 Orthogonally to this classification, one can distinguish intra-
 technology handover from inter-technology handover thinking of the
 link technologies involved.  In the inter-technology case, it is
 highly probable that the authenticators will differ.  The most likely
 cases are 1(b) or 2 in the above list.

6. Models of Early Authentication

 As noted in Section 3, there are cases where early authentication is
 applicable while ERP does not work.  This section concentrates on
 providing some models around which we can build our analysis of the
 EAP early authentication problem.  Different usage models can be
 defined depending on whether
 o  the SAP is not involved in early authentication (direct pre-
    authentication usage model),
 o  the SAP interacts only with the CAP (indirect pre-authentication
    usage model), or
 o  the SAP interacts with the AAA server (the authenticated
    anticipatory keying usage model).
 It is assumed that the CAP and SAP are different entities.  It is
 further assumed in describing these models that there is no direct L2
 connectivity between the peer and the candidate attachment point.

6.1. EAP Pre-Authentication Usage Models

 In the EAP pre-authentication model, the SAP does not interact with
 the AAA server directly.  Depending on how the SAP is involved in the
 pre-authentication signaling, the EAP pre-authentication usage model
 can be further categorized into the following two sub-models, direct
 and indirect.

Ohba, et al. Informational [Page 10] RFC 5836 Early Authentication PS April 2010

6.1.1. The Direct Pre-Authentication Model

 In this model, the SAP is not involved in the EAP exchange and only
 forwards the EAP pre-authentication traffic as it would any other
 data traffic.  The direct pre-authentication model is based on the
 assumption that the MD can discover candidate authenticators and
 establish direct IP communication with them.  It is applicable to any
 of the cases described in Section 5.
         Mobile          Candidate Attachment          AAA Server
         Device              Point(CAP)
     +-----------+    +-------------------------+    +------------+
     |           |    |        Candidate        |    |            |
     |   Peer    |    |      Authenticator      |    | EAP Server |
     |           |    |                         |    |            |
     +-----------+    +-------------------------+    +------------+
     | MD-CAP    |<-->| MD-CAP    | | CAP-AAA   |<-->| CAP-AAA    |
     | Signaling |    | Signaling | | Signaling |    | Signaling  |
     +-----------+    +-----------+ +-----------+    +------------+
            Figure 2: Direct Pre-Authentication Usage Model
 The direct pre-authentication signaling for the usage model is shown
 in Figure 3.
  Mobile             Serving             Candidate            AAA/EAP
  Device         Attachment Point      Authenticator          Server
                      (SAP)
    |                   |                    |                   |
    |                   |                    |                   |
    |     EAP over MD-CAP Signaling (L3)     |    EAP over AAA   |
    |<------------------+------------------->|<----------------->|
    |                   |                    |                   |
    |                   |                    |                   |
   Figure 3: Direct Pre-Authentication Signaling for the Usage Model

6.1.2. The Indirect Pre-Authentication Usage Model

 The indirect pre-authentication usage model is illustrated in
 Figure 4.

Ohba, et al. Informational [Page 11] RFC 5836 Early Authentication PS April 2010

  Mobile Device      Serving              Candidate          AAA
      (MD)       Attachment Point     Attachment Point      Server
                      (SAP)                 (CAP)
  +----------+                         +----------------+   +--------+
  |          |                         |                |   |        |
  | EAP Peer |                         |    Candidate   |   | EAP    |
  |          |                         |  Authenticator |   | Server |
  |          |                         |                |   |        |
  +----------+   +---------+-------+   +-------+--------+   +--------+
  |  MD-SAP  |<->| MD-SAP  |SAP-CAP|<->|SAP-CAP|CAP-AAA |<->|CAP-AAA |
  +----------+   +---------+-------+   +-------+--------+   +--------+
  {-----------------------------Signaling----------------------------}
           Figure 4: Indirect Pre-Authentication Usage Model
 In the indirect pre-authentication model, it is assumed that a trust
 relationship exists between the serving network (or serving AAA
 realm) and candidate network (or candidate AAA realm).  The SAP is
 involved in EAP pre-authentication signaling.  This pre-
 authentication model is needed if the peer cannot discover the
 candidate authenticators identity or if direct IP communication
 between the MD and CAP is not possible due to security or network
 topology issues.
 The role of the SAP in this pre-authentication model is to forward
 EAP pre-authentication signaling between the mobile device and CAP;
 the role of the CAP is to forward EAP pre-authentication signaling
 between the peer (via the SAP) and EAP server and receive the
 transported keying material.
 The pre-authentication signaling for this model is shown in Figure 5.
  Mobile             Serving              Candidate            AAA/EAP
  Device         Attachment Point     Attachment Point         Server
                      (SAP)                (CAP)
    |                   |                    |                   |
    |     EAP over      |       EAP over     |   EAP over AAA    |
    | MD-SAP Signaling  |  SAP-CAP Signaling |                   |
    |    (L2 or L3)     |        (L3)        |                   |
    |<----------------->|<------------------<|<----------------->|
    |                   |                    |                   |
    |                   |                    |                   |
  Figure 5: Indirect Pre-Authentication Signaling for the Usage Model

Ohba, et al. Informational [Page 12] RFC 5836 Early Authentication PS April 2010

 In this model, the pre-authentication signaling path between a peer
 and a candidate authenticator consists of two segments: peer-to-SAP
 signaling (over L2 or L3) and SAP-to-CAP signaling over L3.

6.2. The Authenticated Anticipatory Keying Usage Model

 In this model, it is assumed that there is no trust relationship
 between the SAP and the CAP, and the SAP is required to interact with
 the AAA server directly.  The authenticated anticipatory keying usage
 model is illustrated in Figure 6.
   Mobile            Serving               AAA Server      Candidate
   Device        Attachment Point                          Attachment
                      (SAP)                                Point (CAP)
 +---------+   +------------------+   +-----------------+  +--------+
 |         |   |                  |   |                 |  |        |
 |  Peer   |   |   Authenticator  |   |   EAP Server    |  |  AAA   |
 |         |   |                  |   |                 |  | Client |
 +---------+   +------------------+   +-----------------+  +--------+
 |  MD-SA  |<->|  MD-SAP |SAP-AAA |<->|SAP-AAA |CAP-AAA |<>|CAP-AAA |
 +---------+   +------------------+   +--------+--------+  +--------+
 {------------------------------Signaling---------------------------}
        Figure 6: Authenticated Anticipatory Keying Usage Model
 The SAP is involved in EAP authenticated anticipatory keying
 signaling.
 The role of the serving attachment point in this usage model is to
 communicate with the peer on one side and exchange authenticated
 anticipatory keying signaling with the EAP server on the other side.
 The role of the candidate authenticator is to receive the transported
 keying materials from the EAP server and to act as the serving
 attachment point after handover occurs.  The MD-SAP signaling is
 performed over L2 or L3; the SAP-AAA and AAA-CAP segments operate
 over L3.

7. Architectural Considerations

 There are two architectural issues relating to early authentication:
 authenticator discovery and context binding.

7.1. Authenticator Discovery

 In general, early authentication requires the identity of a candidate
 attachment point to be discovered by a peer, by a serving attachment
 point, or by some other entity prior to handover.  An attachment
 point discovery protocol is typically defined as a separate protocol

Ohba, et al. Informational [Page 13] RFC 5836 Early Authentication PS April 2010

 from an early authentication protocol.  For example, the IEEE 802.21
 Information Service (IS) [IEEE.802-21] provides a link-layer-
 independent mechanism for obtaining neighboring network information
 by defining a set of Information Elements (IEs), where one of the IEs
 is defined to contain an IP address of an attachment point.  IEEE
 802.21 IS queries for such an IE may be used as a method for
 authenticator discovery.
 If IEEE 802.21 IS or a similar mechanism is used, authenticator
 discovery requires a database of information regarding the target
 network; the provisioning of a server with such a database is another
 issue.

7.2. Context Binding

 When a candidate authenticator uses different EAP transport protocols
 for normal authentication and early authentication, a mechanism is
 needed to bind link-layer-independent context carried over early
 authentication signaling to the link-layer-specific context of the
 link to be established between the peer and the candidate
 authenticator.  The link-layer-independent context includes the
 identities of the peer and authenticator as well as the MSK.  The
 link-layer-specific context includes link-layer addresses of the peer
 and the candidate authenticator.  Such context binding can happen
 before or after the peer changes its point of attachment.
 There are at least two possible approaches to address the context
 binding issue.  The first approach is based on communicating the
 link-layer context as opaque data via early authentication signaling.
 The second approach is based on running EAP over the link layer of
 the candidate authenticator after the peer arrives at the
 authenticator, using short-term credentials generated via early
 authentication.  In this case, the short-term credentials are shared
 between the peer and the candidate authenticator.  In both
 approaches, context binding needs to be securely made between the
 peer and the candidate authenticator.  Also, the peer is not fully
 authorized by the candidate authenticator until the peer completes
 the link-layer-specific secure association procedure with the
 authenticator using link-layer signaling.

8. AAA Issues

 Most of the AAA documents today do not distinguish between a normal
 authentication and an early authentication, and this creates a set of
 open issues:

Ohba, et al. Informational [Page 14] RFC 5836 Early Authentication PS April 2010

 Early authentication authorization
    Users may not be allowed to have more than one logon session at
    the time.  This means that while such users actively engage in a
    session (as a result of a previously valid authentication), they
    will not be able to perform early authentication.  The AAA server
    currently has no way of distinguishing between a normal
    authentication request and an early authentication request.
 Early authentication lifetime
    Currently, AAA protocols define attributes carrying lifetime
    information for a normal authentication session.  Even when a user
    profile and the AAA server support early authentication, the
    lifetime for an early authentication session is typically valid
    only for a short amount of time because the peer has not completed
    its authentication at the target link layer.  It is currently not
    possible for a AAA server to indicate to the AAA client or a peer
    the lifetime of the early authenticated session unless AAA
    protocols are extended to carry early authentication session
    lifetime information.  In other words, it is not clear to the peer
    or the authenticator when the early authentication session will
    expire.
 Early authentication retries
    It is typically expected that, shortly following the early
    authentication process, the peer moves to the new point of
    attachment and converts the early authentication state to a normal
    authentication state (the procedure for which is not the topic of
    this particular subsection).  However, if the peer has not yet
    moved to the new location and realizes that the early
    authentication session is expiring, it may perform another early
    authentication.  Some limiting mechanism is needed to avoid an
    unlimited number of early authentication attempts.
 Completion of network attachment
    Once the peer has successfully attached to the new point of
    attachment, it needs to convert its authentication state from
    early authenticated to fully attached and authorized.  If the AAA
    server needs to differentiate between early authentication and
    normal authentication, there may need to be a mechanism within the
    AAA protocol to provide this indication to the AAA server.  This
    may be important from a billing perspective if the billing policy
    does not charge for an early authenticated peer until the peer is
    fully attached to the target authenticator.
 Session resumption
    In the case where the peer cycles between a network N1 with which
    it has fully authenticated and another network N2 and then back to
    N1, it should be possible to simply convert the fully

Ohba, et al. Informational [Page 15] RFC 5836 Early Authentication PS April 2010

    authenticated state on N1 to an early authenticated state.  The
    problems around handling session lifetime and keying material
    caching need to be dealt with.
 Multiple candidate attachment points
    There may be situations where the peer needs to choose from a
    number of CAPs.  In such cases, it is desirable for the peer to
    perform early authentication with multiple candidate
    authenticators.  This amplifies the difficulties noted under the
    point "Early authentication authorization".
 Inter-AAA-realm handover support
    There may be situations where the peer moves out of the home AAA
    realm or across different visited AAA realms.  In such cases, the
    early authentication should be performed through the visited AAA
    realm with the AAA server in the home AAA realm.  It also requires
    AAA in the visited realm to acquire the identity information of
    the home AAA realms for routing the EAP early authentication
    traffic.  Knowledge of realm identities is required by both the
    peer and AAA to generate the early authentication key for mutual
    authentication between the peer and the visited AAA server.
 Inter-technology support
    Current specifications on early authentication mostly deal with
    homogeneous 802.11 networks.  AAA attributes such as Calling-
    Station-ID [RADEXT-WLAN] may need to be expanded to cover other
    access technologies.  Furthermore, inter-technology handovers may
    require a change of the peer identifier as part of the handover.
    Investigation on the best type of identifiers for peers that
    support multiple access technologies is required.

9. Security Considerations

 This section specifically covers threats introduced to the EAP model
 by early authentication.  Security issues on general EAP and handover
 are described in other documents such as [RFC3748], [RFC4962],
 [RFC5169], and [RFC5247].
 Since early authentication, as described in this document, needs to
 work across multiple attachment points, any solution needs to
 consider the following security threats.
 First, a resource consumption denial-of-service attack is possible,
 where an attacker that is not on the same IP link as the legitimate
 peer or the candidate authenticator may send unprotected early
 authentication messages to the legitimate peer or the candidate
 authenticator.  As a result, the latter may spend computational and
 bandwidth resources on processing early authentication messages sent

Ohba, et al. Informational [Page 16] RFC 5836 Early Authentication PS April 2010

 by the attacker.  This attack is possible in both the direct and
 indirect pre-authentication scenarios.  To mitigate this attack, the
 candidate network or authenticator may apply non-cryptographic packet
 filtering so that only early authentication messages received from a
 specific set of serving networks or authenticators are processed.  In
 addition, a simple solution for the peer side would be to let the
 peer always initiate EAP early authentication and not allow EAP early
 authentication initiation from an authenticator.
 Second, consideration for the channel binding problem described in
 [RFC5247] is needed as lack of channel binding may enable an
 authenticator to impersonate another authenticator or communicate
 incorrect information via out-of-band mechanisms (such as via a AAA
 or lower-layer protocol) [RFC3748].  It should be noted that it is
 relatively easier to launch such an impersonation attack for early
 authentication than normal authentication because an attacker does
 not need to be physically on the same link as the legitimate peer to
 send an early authentication trigger to the peer.

10. Acknowledgments

 The editors would like to thank Preetida Vinayakray, Shubhranshu
 Singh, Ajay Rajkumar, Rafa Marin Lopez, Jong-Hyouk Lee, Maryna
 Komarova, Katrin Hoeper, Subir Das, Charles Clancy, Jari Arkko, and
 Bernard Aboba for their valuable input.

11. Contributors

 The following people all contributed to this document: Alper E.
 Yegin, Tom Taylor, Srinivas Sreemanthula, Madjid Nakhjiri, Mahalingam
 Mani, and Ashutosh Dutta.

12. References

12.1. Normative References

 [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
            Levkowetz, "Extensible Authentication Protocol (EAP)",
            RFC 3748, June 2004.
 [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
            Authorization, and Accounting (AAA) Key Management",
            BCP 132, RFC 4962, July 2007.
 [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
            Authentication Protocol (EAP) Key Management Framework",
            RFC 5247, August 2008.

Ohba, et al. Informational [Page 17] RFC 5836 Early Authentication PS April 2010

12.2. Informative References

 [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W.  Simpson,
            "Remote Authentication Dial In User Service (RADIUS)",
            RFC 2865, June 2000.
 [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
            Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 [RFC5169]  Clancy, T., Nakhjiri, M., Narayanan, V., and L.  Dondeti,
            "Handover Key Management and Re- Authentication Problem
            Statement", RFC 5169, March 2008.
 [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
            Re-authentication Protocol (ERP)", RFC 5296, August 2008.
 [RADEXT-WLAN]
            Aboba, B., Malinen, J., Congdon, P., and J.  Salowey,
            "RADIUS Attributes for IEEE 802 Networks", Work
            in Progress, February 2010.
 [RFC2989]  Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
            Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
            D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
            S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
            B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
            "Criteria for Evaluating AAA Protocols for Network
            Access", RFC 2989, November 2000.
 [IEEE.802-1X.2004]
            Institute of Electrical and Electronics Engineers,
            "Port-Based Network Access Control", IEEE Standard 802.1X,
            2004.
 [IEEE.802-21]
            Institute of Electrical and Electronics Engineers,
            "Standard for Local and Metropolitan Area Networks: Media
            Independent Handover Services", IEEE Standard 802.21,
            2008.
 [IEEE.802-11.2007]
            Institute of Electrical and Electronics Engineers,
            "Information technology - Telecommunications and
            information exchange between systems - Local and
            metropolitan area networks - Specific requirements - Part
            11: Wireless LAN Medium Access Control (MAC) and Physical
            Layer (PHY) specifications", IEEE Standard 802.11, 2007.

Ohba, et al. Informational [Page 18] RFC 5836 Early Authentication PS April 2010

 [IEEE.802-11R.2008]
            Institute of Electrical and Electronics Engineers,
            "Information technology - Telecommunications and
            information exchange between systems - Local and
            metropolitan area networks - Specific requirements - Part
            11: Wireless LAN Medium Access Control (MAC) and Physical
            Layer (PHY) specifications - Amendment 2: Fast BSS
            Transition", IEEE Standard 802.11R, 2008.
 [IEEE.802-11F.2003]
            Institute of Electrical and Electronics Engineers, "IEEE
            Trial-Use Recommended Practice for Multi-Vendor Access
            Point Interoperability via an Inter-Access Point Protocol
            Across Distribution Systems Supporting IEEE 802.11
            Operation", IEEE Recommendation 802.11F, 2003.
 [TS33.402] 3GPP, "System Architecture Evolution (SAE): Security
            aspects of non-3GPP accesses (Release 8)", 3GPP
            TS33.402 V8.3.1, 2009.
 [ITU]      ITU-T, "General Characteristics of International Telephone
            Connections and International Telephone Circuits: One-Way
            Transmission Time", ITU-T Recommendation G.114, 1998.
 [WPA]      The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)",
            Wi-Fi WPA v3.1, 2004.
 [MQ7]      Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A.
            Skarmeta, "Network-layer Assisted Mechanism to Optimize
            Authentication Delay During Handoff in 802.11 Networks",
            The 4th Annual International Conference on Mobile and
            Ubiquitous Systems: Computing, Networking and
            Services (MOBIQUITOUS 2007), 2007.
 [WCM]      Dutta, A., Famorali, D., Das, S., Ohba, Y., and R. Lopez,
            "Media-independent pre-authentication supporting secure
            interdomain handover optimization", IEEE Wireless
            Communications Volume 15, Issue 2, April 2008.

Ohba, et al. Informational [Page 19] RFC 5836 Early Authentication PS April 2010

Authors' Addresses

 Yoshihiro Ohba
 Toshiba Corporate Research and Development Center
 1 Komukai-Toshiba-cho
 Saiwai-ku, Kawasaki, Kanagawa,   212-8582
 Japan
 Phone: +81 44 549 2230
 EMail: yoshihiro.ohba@toshiba.co.jp
 Qin Wu (editor)
 Huawei Technologies Co., Ltd
 Huawei Nanjing R&D Center, Floor 1F, Software Avenue, No.101.,
 Yuhua District
 Nanjing, JiangSu  210012
 China
 Phone: +86 25 56622908
 EMail: sunseawq@huawei.com
 Glen Zorn (editor)
 Network Zen
 1463 East Republican Street
 Seattle, Washington  98112
 USA
 EMail: gwz@net-zen.net

Ohba, et al. Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5836.txt · Last modified: 2010/04/26 22:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki