[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00 01 02
ABFAB Working Group S. Winter
Internet-Draft RESTENA
Intended status: Standards Track June 01, 2011
Expires: December 3, 2011
Update to the EAP Applicability Statement
draft-winter-abfab-eapapplicability-00
Abstract
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 3, 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.
Winter Expires December 3, 2011 [Page 1]
Internet-Draft EAP Applicability June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Uses of EAP beyond the original applicability statement . . . . 3
2.1. Communication of authorisation information:
EAP-MSCHAPv2; more examples solicited . . . . . . . . . . . 3
2.2. Equipment Auditing: NEA PT over EAP . . . . . . . . . . . . 3
2.3. Account Management: EAP-MSCHAPv2 . . . . . . . . . . . . . 4
2.4. EAP over IP: PANA . . . . . . . . . . . . . . . . . . . . . 4
2.5. EAP for application-layer access: ABFAB . . . . . . . . . . 5
3. Summary of changes . . . . . . . . . . . . . . . . . . . . . . 6
4. Revised EAP applicability statement . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informational References . . . . . . . . . . . . . . . . . 8
Winter Expires December 3, 2011 [Page 2]
Internet-Draft EAP Applicability June 2011
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
Winter Expires December 3, 2011 [Page 3]
Internet-Draft EAP Applicability June 2011
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.
Winter Expires December 3, 2011 [Page 4]
Internet-Draft EAP Applicability June 2011
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
Winter Expires December 3, 2011 [Page 5]
Internet-Draft EAP Applicability June 2011
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:
o user credentials
o machine credentials
o machine configuration details for equipment auditing
o authorisation information
o accessed application properties
The use of EAP over IP is recommended if - and only if - it is
Winter Expires December 3, 2011 [Page 6]
Internet-Draft EAP Applicability June 2011
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.
Winter Expires December 3, 2011 [Page 7]
Internet-Draft EAP Applicability June 2011
5. Security Considerations
Lots.
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.
Winter Expires December 3, 2011 [Page 8]
Internet-Draft EAP Applicability June 2011
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.
Winter Expires December 3, 2011 [Page 9]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/