Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) RFC 7057
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.
Winter & Salowey Standards Track [Page 1]RFC 7057 EAP Applicability December 2013Table 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.
Winter & Salowey Standards Track [Page 2]