Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)
EAP is no longer only for network access: when it guards applications, channel bindings become mandatory.
Winter, S. and J. Salowey, "Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)", RFC 7057, DOI 10.17487/RFC7057, December 2013, <https://www.rfc-editor.org/info/rfc7057>.
@misc{rfc7057,
series = {Request for Comments},
number = 7057,
howpublished = {RFC 7057},
publisher = {RFC Editor},
doi = {10.17487/RFC7057},
url = {https://www.rfc-editor.org/info/rfc7057},
author = {S. Winter and J. Salowey},
title = {{Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB)}},
pagetotal = 7,
year = 2013,
month = dec,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7057 RESTENA
Updates: 3748 J. Salowey
Category: Standards Track Cisco
ISSN: 2070-1721 December 2013
Update to the Extensible Authentication Protocol (EAP)
Applicability Statement for
Application Bridging for Federated Access Beyond Web (ABFAB)
Abstract
This document updates the Extensible Authentication Protocol (EAP)
applicability statement from RFC 3748 to reflect recent usage of the
EAP protocol in the Application Bridging for Federated Access Beyond
web (ABFAB) architecture.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in 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/rfc7057.
Copyright Notice
Copyright (c) 2013 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 ....................................................2
1.1. Requirements Language ......................................2
2. Uses of EAP for Application-Layer Access ........................2
2.1. Retransmission .............................................4
2.2. Re-authentication ..........................................5
3. Revised EAP Applicability Statement .............................5
4. Security Considerations .........................................6
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
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 some of the reasons for the recommendation against usage of EAP
for bulk data transport are still valid, some of the other provisions
in the applicability statement have turned out to be too narrow.
Section 2 describes the example where EAP is used to authenticate
application-layer access. Section 3 provides new text to update
Section 1.3., "Applicability", 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 [RFC2119].
2. Uses of EAP for Application-Layer Access
Ongoing work in the IETF specifies the use of EAP over Generic
Security Service Application Program Interface (GSS-API) for generic
application layer access [RFC7055]. In the past, using EAP in this
context has met resistance due to the lack of channel bindings
[RFC6677]. Without channel bindings, a peer cannot verify if an
authenticator is authorized to provide an advertised service.
However, as additional services use EAP for authentication, the
distinction of which service is being contacted becomes more
important. Application services might have different properties.
Consider an environment with multiple printers, some of which provide
a confidential service to output documents to a controlled location.
If a peer sent a document to the wrong service, then potentially
sensitive information might be printed in an uncontrolled location
and be disclosed. In addition, 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 validate that the
contacted host is authorized to provide the requested service.
In environments where EAP is used for purposes other than network
access authentication:
o All EAP servers and all application access EAP peers MUST support
channel bindings. All network access EAP peers SHOULD support
channel bindings.
o Channel binding MUST be used for all application authentication.
The EAP server MUST require that either the correct EAP lower-
layer attribute or another attribute indicating the purpose of the
authentication be present in the channel binding data for
application authentication.
o Channel binding SHOULD be used for all network access
authentication, and when channel binding data is present, the EAP
server MUST require that it contain the correct EAP lower-layer
attribute to explicitly identify the reason for authentication.
o Any new usage of EAP MUST use channel bindings including the EAP
lower-layer attribute to prevent confusion with network access
usage.
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 service other than network access. A
device can be created that impersonates a Network Access Service
(NAS) to peers, but actually proxies the authentication to the new
application service that accepts EAP authentications. This may
decrease the security of this service even for users who previously
used non-EAP means of authentication to the service.
It is REQUIRED for the application layer to prove that both the EAP
peer and EAP authenticator possess the EAP Master Session Key (MSK).
Failing to validate the possession of the EAP MSK can allow an
attacker to insert himself into the conversation and impersonate the
peer or authenticator. In addition, the application should define
channel binding attributes that are sufficient to validate that the
application service is being correctly represented to the peer.
2.1. Retransmission
In EAP, the authenticator is responsible for retransmission. By
default, EAP assumes that the lower layer (the application in this
context) is unreliable. The authenticator can send a packet whenever
its retransmission timer triggers. In this mode, applications need
to be able to receive and process EAP messages at any time during the
authentication conversation.
Alternatively, EAP permits a lower layer to set the retransmission
timer to infinite. When this happens, the lower layer becomes
responsible for reliable delivery of EAP messages. Applications that
use a lock-step or client-driven authentication protocol might
benefit from this approach.
In addition to retransmission behavior, applications need to deal
with discarded EAP messages. For example, whenever some EAP methods
receive erroneous input, these methods discard the input rather than
generating an error response. If the erroneous input was generated
by an attacker, legitimate input can sometimes be received after the
erroneous input. Applications MUST handle discarded EAP messages,
although the specific way in which discarded messages will be handled
depends on the characteristics of the application. Options include
failing the authentication at the application level, requesting an
EAP retransmit and waiting for additional EAP input.
Applications designers that incorporate EAP into their application
need to determine how retransmission and message discards are
handled.
2.2. Re-authentication
EAP lower layers MAY provide a mechanism for re-authentication to
happen within an existing session [RFC3748]. Re-authentication
permits security associations to be updated without establishing a
new session. For network access, this can be important because
interrupting network access can disrupt connections and media.
Some applications might not need re-authentication support. For
example, if sessions are relatively short-lived or if sessions can be
replaced without significant disruption, re-authentication might not
provide value. Protocols like HyperText Transfer Protocol (HTTP)
[RFC2616] and Simple Mail Transport Protocol (SMTP) [RFC5321] are
examples of protocols where establishing a new connection to update
security associations is likely to be sufficient.
Re-authentication is likely to be valuable if sessions or connections
are long-lived or if there is a significant cost to disrupting them.
Another factor may make re-authentication important. Some protocols
only permit one party in a protocol (for example, the client) to
establish a new connection. If another party in the protocol needs
the security association refreshed, then re-authentication can
provide a mechanism to do so.
Application designers need to determine whether re-authentication
support is needed and which parties can initiate it.
3. Revised EAP Applicability Statement
The following text is appended to the EAP applicability statement in
[RFC3748].
In cases where EAP is used for application authentication, support
for EAP channel bindings is REQUIRED on the EAP peer and EAP server
to validate that the host is authorized to provide the services
requested. In addition, the application MUST define channel binding
attributes that are sufficient to validate that the application
service is being correctly represented to the peer. The protocol
carrying EAP MUST prove possession of the EAP MSK between the EAP
peer and EAP authenticator. In the context of EAP for application
access the application is providing the EAP lower layer.
Applications protocols vary so their specific behavior and transport
characteristics needs to be considered when determining their
retransmission and re-authentication behavior. Circumstances might
require that applications need to perform conversion of identities
from an application specific character set to UTF-8 or another
character set required by a particular EAP method. See also
[RADEXT-NAI], Section 2.6, for information about normalization of
identifiers.
4. Security Considerations
In addition to the requirements discussed in the main sections of the
document, applications should take into account how server
authentication is achieved. Some deployments may allow for weak
server authentication that is then validated with an additional
existing exchange that provides mutual authentication. In order to
fully mitigate the risk of NAS impersonation when these mechanisms
are used, it is RECOMMENDED that mutual channel bindings be used to
bind the authentications together as described in [RFC7029]. When
doing channel binding it is REQUIRED that the authenticator is not
able to modify the channel binding data passed between the peer to
the authenticator as part of the authentication process.
5. Acknowledgements
Large amounts of helpful text and insightful thoughts were
contributed by Sam Hartman, Painless Security. David Black
contributed to the text clarifying channel bindings usage.
6. References
6.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.
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
Support for Extensible Authentication Protocol (EAP)
Methods", RFC 6677, July 2012.
6.2. Informative References
[RADEXT-NAI] DeKok, A., "The Network Access Identifier", Work in
Progress, November 2013.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Authentication Protocol (EAP) Mutual Cryptographic
Binding", RFC 7029, October 2013.
[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism
for the Extensible Authentication Protocol", RFC 7055,
December 2013.
Authors' Addresses
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.
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, Washington 98121
USA
EMail: jsalowey@cisco.com
AI ELI5
On this page
§1Why the Statement Needed an Update
The applicability statement in RFC 3748 says that the Extensible Authentication Protocol (EAP) is "for use in network access authentication, where IP layer connectivity may not be available". It also says that using EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.
RFC 7057 keeps some of the reasons behind that advice, but finds other provisions too narrow. Its example is EAP used to authenticate access to applications, as in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. The RFC supplies new text to update Section 1.3, "Applicability", of RFC 3748.
The old rule said this login method was only for joining networks. People started using it for apps too, so the rule needed a small addition.
§2Using EAP for Application Access
Ongoing IETF work specifies EAP over the Generic Security Service Application Program Interface (GSS-API) for generic application-layer access (RFC 7055). In the past, this use of EAP met resistance because there were no channel bindings (RFC 6677). Without them, a peer cannot verify whether an authenticator is authorized to provide an advertised service.
The RFC gives an example: an environment with several printers, some of which output confidential documents to a controlled location. If a peer sends a document to the wrong printer service, sensitive information might be printed in an uncontrolled place. A low-value service is also more likely to be compromised than a high-value one. If it could impersonate the high-value service, overall security would be limited by the weaker one.
The problem is most acute in a federated environment, where several organizations with different policies and goals are involved. There, authenticating the EAP server is not enough: the peer must also validate that the contacted host is authorized to provide the requested service.
Imagine sending a secret note to the school office, but a stranger has put up a fake office sign. It is not enough to know the person is nice; you must know they are really the office.
§2Channel Binding Requirements
For environments where EAP is used for purposes other than network access, the RFC sets these rules:
- All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support them.
- Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute, or another attribute indicating the purpose of the authentication, is present in the channel binding data.
- Channel binding SHOULD be used for network access authentication. When channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute.
- Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute, to prevent confusion with network access usage.
Operators are warned to think carefully before relaxing these rules. If channel binding is not required and EAP is introduced into an existing non-network-access service, a device can be built that impersonates a Network Access Service (NAS) to peers while proxying the authentication to the application service. That can lower the security of the service even for users who previously used non-EAP authentication.
The RFC also says it is REQUIRED for the application layer to prove that both the EAP peer and the EAP authenticator possess the EAP Master Session Key (MSK). Otherwise an attacker could insert himself into the conversation and impersonate the peer or authenticator. The application should also define channel binding attributes that show the service is correctly represented to the peer.
The rule is: always check that the person you are talking to really is who they claim to be for this job, and prove you both know the same secret. Do not skip the check just because it looks fine.
§2.1Retransmission and Discarded Messages
In EAP, the authenticator is responsible for retransmission. By default EAP assumes the lower layer, which here is the application, is unreliable. The authenticator can send a packet whenever its retransmission timer fires, so applications need to be able to receive and process EAP messages at any time during the conversation.
Alternatively, EAP lets a lower layer set the retransmission timer to infinite. The lower layer then becomes responsible for reliable delivery. Applications that use a lock-step or client-driven authentication protocol might benefit from this.
Some EAP methods discard erroneous input instead of answering with an error. If an attacker caused the bad input, legitimate input can sometimes arrive afterwards. Applications MUST handle discarded EAP messages, but how depends on the application. Options include failing the authentication at the application level, requesting an EAP retransmit, and waiting for more EAP input.
If a letter gets lost, someone has to send it again. EAP says the checker does that by default, but an app can choose to take over the job of making sure letters arrive.
§2.2Re-authentication
EAP lower layers MAY provide a way to re-authenticate within an existing session. This lets security associations be updated without setting up a new session, which matters for network access because interrupting it can disrupt connections and media.
Some applications may not need it. If sessions are short-lived or can be replaced without much disruption, a new connection may be enough. The RFC names HTTP and SMTP as protocols where establishing a new connection to refresh security associations is likely to be sufficient.
Re-authentication is likely to be valuable when sessions or connections are long-lived or costly to disrupt. It can also matter when only one party in a protocol, for example the client, is allowed to open a new connection but the other party needs the security association refreshed. Application designers must decide whether to support it and which parties can start it.
Sometimes you can show your ticket again without leaving the ride. Short rides do not need that; long rides you do not want to stop might.
§3The Revised Applicability Statement
The RFC appends new text to the applicability statement in RFC 3748. When EAP is used for application authentication, support for EAP channel bindings is REQUIRED on the EAP peer and EAP server, to validate that the host is authorized to provide the requested services. The application MUST define channel binding attributes sufficient to validate that the service is correctly represented to the peer.
The protocol carrying EAP MUST prove possession of the EAP MSK between the peer and the authenticator. For application access, the application is providing the EAP lower layer. Because application protocols vary, their transport characteristics must be considered when deciding retransmission and re-authentication behavior.
The text also notes that applications may need to convert identities from an application-specific character set to UTF-8 or another character set required by a particular EAP method.
This is the actual sentence added to the old rulebook: if you use the login method for apps, you must check the app is the right one and prove you share the secret.
§4Security Considerations
Beyond the requirements above, applications should consider how server authentication is achieved. Some deployments may allow weak server authentication that is then validated by an additional, existing exchange providing mutual authentication.
To fully mitigate the risk of NAS impersonation in that case, it is RECOMMENDED that mutual channel bindings be used to bind the authentications together, as described in RFC 7029. When doing channel binding, it is REQUIRED that the authenticator cannot modify the channel binding data passed between the peer and the authenticator as part of authentication.
If the first check of who you are talking to is weak, add a second check and tie the two together, so no one in the middle can change the details.