ABFAB Working Group S. Winter
Internet-Draft RESTENA
Intended status: Standards Track June 01, 2011
Expires: December 01, 2011

Update to the EAP Applicability Statement


This document updates the EAP applicability statement from RFC3748 to reflect recent usage of the EAP protocol in unprecedented contexts.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 01, 2011.

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The EAP applicability statement in [RFC3748] defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available.", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.".

While the recommendation against usage of EAP for bulk data transport is still valid, some of the other provisions in the applicability statement have turned out to be too narrow. Section 2 lists numerous examples where EAP is being used for more than authentication and/or more than network access. Section 4 provides new text to update the paragraph 1.3. "Applicablity" in [RFC3748].

1.1. Requirements Language

In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119]

2. Uses of EAP beyond the original applicability statement

2.1. Communication of authorisation information: EAP-MSCHAPv2; more examples solicited

MSCHAPv2 [RFC2759] can be transported over EAP. It contains packet exchanges to authenticate users, which fits into the scope of the original EAP applicability statement. However, MSCHAPv2 also allows to check for and signal (lack of) authorisation of an authenticated user to use a service. For example, an MSCHAPv2 failure packet as defined in section 6 of [RFC2759] can indicate condition 646 "Restricted Logon hours". This determination is an authorisation check which happens subsequent to the authentication step (a user needs to be positively identified to correlate his identity to a list of permitted logon hours).

This use of EAP is not covered by the EAP applicability statement since it goes beyond user authentication. However, EAP-MSCHAPv2 is in massive deployment. It is thus due to extend the EAP applicability statement to include "user authorisation".

2.2. Equipment Auditing: NEA PT over EAP

The IETF working group "Network Endpoint Assessment", nea, is chartered to define exchange information about the state of a user's equipment during network authentication. One of the channels over which to transport this information is EAP; either embedded within other EAP methods or as a stand-alone EAP method. The information exchanged is unrelated to user authentication - the information covers the state of the computing device only, independently of the user who is using it.

This use of EAP is not covered by the EAP applicability statement since it goes beyond user authentication. However, there are multiple implementations of NEA information transport, some in wide deployment (e.g. recent implementations of PEAP with "Statement of Health (SoH)" support. It is thus due to extend the EAP applicability statement to include "Equipment Auditing".

2.3. Account Management: EAP-MSCHAPv2

EAP-MSCHAPv2 has more wide-reaching capabilities than the ones listed in point 1. It includes limited support for user account management, namely the possibility for a user to change his password, should it have expired. This is defined in section 7 of [RFC2759].

This use of EAP is not covered by the EAP applicability statement since it goes beyond user authentication. It is left open in this -00 draft whether such a capability should be considered in the applicability of EAP. The reason being that this use goes dangerously close to the use of EAP as "bulk data transport"; account management typically being a administratively independent action from the actual admission decision. This should be discussed in the relevant working group(s).

2.4. EAP over IP: PANA

The PANA protocol [RFC5191] carries EAP payloads over UDP. The original EAP applicability statement states that EAP is applicable in cases where "IP layer connectivity may not be available". The wording in the applicability statement leaves open whether the transport of EAP over IP is in scope or not. Since protocols which carry EAP over IP already exist and have been deployed, it is due to make this use case explicit and reflect it in the revised applicability statement. The statement needs to take into account though that EAP requires ordering guarantees from its lower layers, which are not delivered by IP in itself. This limits the use of EAP to transport layers which are on top of IP, and provide their own ordering guarantees.

2.5. EAP for application-layer access: ABFAB

Ongoing work in the IETF (abfab working group) specifies the use of EAP over GSSAPI over a AAA protocol for generic application layer access. Using EAP in this context has in the past been repelled due to the lack of channel bindings. Without channel bindings, a peer does not know what service is being contacted. In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server.

However as additional services use EAP for authentication, the distinction of which service is being contacted becomes more important. Consider an environment with multiple printers; if a peer printed a document in the wrong location then potentially sensitive information might be printing in a location where the user associated with the peer would be unable to retrieve it. It is also likely that services might have different security properties. For example, it might be more likely that a low-value service is compromised than some high value service. If the high-value service could be impersonated by a low-value service then the security of the overall system would be limited by the security of the lower value service.

This distinction is present in any environment where peers' security depends on which service they reach. However it is particularly acute in a federated environment where multiple organizations are involved. It is very likely that these organizations will have different security policies and practices. It is very likely that the goals of these organizations will not entirely be aligned. In many situations one organization could gain value by being able to impersonate another. In this environment, authenticating the EAP server is insufficient: the peer must also authenticate which service it contacts. [Discussed: is authentication the right word here?]

For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access services beyond the network. In additon, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non-network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the service that newly accepts EAP auths may decrease the security of this service even for users who previously used non-EAP means of authentication to the service.

In parallel to ABFAB, there is other ongoing work on Channel Binding in the IETF (emu working group). The introduction of channel bindings into EAP mitigates the impersonation threat and makes EAP suitable for use beyond network authentication. Pending issuance of a Channel Binding RFC, it is thus due to extend the EAP applicability statement to include non-network access contexts if - and only if - this context mandates channel bindings.

3. Summary of changes

The new text for the EAP Applicability statement is stated in the next section. It is meant to replace section 1.3 of [RFC3748]. Its main changes are the widened scope (generic resource admission instead of only network authentication), the explicit mention of transporting EAP over IP, and the requirement for channel bindings if used for anything but network access.

This document also updates references to EAP-TLS and SCTP, whose original RFCs have been obsoleted by newer specifications.

With the new text, the acronym EAP can be seen to stand for "Extensible Admission-Control Protocol".

4. Revised EAP applicability statement

EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Under some circumstances, it may also be used for generic resource admission decisions. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.

Generic resource admission decisions may require the transport of any of the following:

The use of EAP over IP is recommended if - and only if - it is transported over a transport layer on top of IP which provides ordering guarantees.

The use of EAP for generic application access is recommended if - and only if - EAP channel bindings are implemented.

Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more.

EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP [RFC0793] or SCTP [RFC4960].

While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported.

Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support.

While authentication methods such as EAP-TLS [RFC5216] provide support for fragmentation and reassembly, the EAP methods defined in this document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties.

EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP.

Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU.

Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable.

5. Security Considerations


6. IANA Considerations

This document has no actions for IANA.

7. Acknowledgements

Large amounts of helpful text and insightful thoughts were contributed by Sam Hartman, Painless Security, and Joe Salowey, Cisco Systems.

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5216] Simon, D., Aboba, B. and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.

8.2. Informational References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.

Author's Address

Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg, 1359 LUXEMBOURG Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu.