[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


   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",
   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

   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

Winter                  Expires December 3, 2011                [Page 7]

Internet-Draft              EAP Applicability                  June 2011

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

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

   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/