diff options
Diffstat (limited to 'doc/rfc/rfc5836.txt')
| -rw-r--r-- | doc/rfc/rfc5836.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc5836.txt b/doc/rfc/rfc5836.txt new file mode 100644 index 0000000..30e36de --- /dev/null +++ b/doc/rfc/rfc5836.txt @@ -0,0 +1,1123 @@ + + + + + + +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] + |