RFC 7057

RFC 7057 🎀 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) ✨

okay bestie, the title block 📋: this is RFC 7057, published in December 2013 by the Internet Engineering Task Force (IETF) 💖. The authors are S. Winter (RESTENA) and J. Salowey (Cisco) 🫶. It's a Standards Track document, ISSN 2070-1721 🌈. It updates RFC 3748 and has no Obsoletes line in its header 🦋.

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 🌷

okay so the EAP applicability statement in [RFC3748] sets the scope of the Extensible Authentication Protocol as "for use in network access authentication, where IP layer connectivity may not be available", and it also says "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED" 🙈.

ngl, some of the reasons behind that advice against using EAP for bulk data transport are still valid 💜. But some of the other rules in the applicability statement turned out to be too narrow for what people are actually doing now 😭. Section 2 walks through the example where EAP is used to authenticate application-layer access. Section 3 gives new text that updates 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 more services use EAP for authentication, it matters more which service is being contacted 🔥. Application services can have different properties. Picture an environment with multiple printers, some of which offer a confidential service that outputs documents to a controlled location. If a peer sent a document to the wrong service, sensitive information could end up printed in an uncontrolled location and get disclosed 😱. On top of that, a low-value service is more likely to be compromised than some high-value service. If a low-value service could impersonate the high-value one, then the security of the whole system would only be as strong as the lower-value service 💀.

This distinction shows up in any environment where a peer's security depends on which service it reaches. It's especially intense in a federated environment where multiple organizations are involved 🌈. It's very likely those organizations have different security policies and practices, and very likely their goals aren't fully aligned. In many situations, one organization could gain value by being able to impersonate another. In this setup, authenticating the EAP server is not enough: the peer also has to 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:

• All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings.
• 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.
• 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.
• 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 think carefully about 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 built that impersonates a Network Access Service (NAS) to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This can weaken that service even for users who used non-EAP means of authentication to reach it before 😭💅.

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 possession of the EAP MSK can let an attacker insert themselves into the conversation and impersonate the peer or authenticator 💀. Also, 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 lets a lower layer set the retransmission timer to infinite. When that 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 🌸.

Beyond retransmission behavior, applications also need to deal with discarded EAP messages 🗑️. For example, when some EAP methods receive erroneous input, they discard the input instead of generating an error response. If the erroneous input came from an attacker, legitimate input can sometimes arrive after it 👀. Applications MUST handle discarded EAP messages, although the specific way they handle them depends on the characteristics of the application. Options include failing the authentication at the application level, or requesting an EAP retransmit and waiting for additional EAP input 💖.

Application designers who bring EAP into their application need to work out how retransmission and message discards get handled 🧠.

2.2. Re-authentication 🦋

EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC3748]. Re-authentication lets security associations get updated without establishing a new session ✨. For network access, this can matter a lot, 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 add much value. Protocols like HyperText Transfer Protocol (HTTP) [RFC2616] and Simple Mail Transport Protocol (SMTP) [RFC5321] are examples where establishing a new connection to update security associations is likely to be enough 🌈.

Re-authentication is likely to be valuable when sessions or connections are long-lived, or when disrupting them is costly 💅.

Another factor can make re-authentication important 👑. Some protocols only let one party (for example, the client) establish a new connection. If another party in the protocol needs its security association refreshed, re-authentication can provide a way to do that 🫶.

Application designers need to decide whether re-authentication support is needed, and which parties can initiate it 🎯.

part 1 of 2 done bestie 🦋 Section 3 onward is coming in part 2 💖

3. Revised EAP Applicability Statement 💅

okay so this part is literally new text that gets stuck onto the end of the EAP applicability statement in [RFC3748] 🎀

When EAP is used for application authentication, support for EAP channel bindings is REQUIRED on the EAP peer and the EAP server ✨ That's how they check that the host is actually allowed to provide the services being asked for 🫶 On top of that, the application MUST define channel binding attributes that are strong enough 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 the EAP authenticator 💜 In this EAP-for-application-access setup, the application is the thing providing the EAP lower layer 🌈

Application protocols vary a lot, so you have to think about each one's specific behavior and transport characteristics when you decide how retransmission and re-authentication should work 🦋 Sometimes apps also need to convert identities from an application-specific character set into UTF-8, or into whatever other character set a particular EAP method requires 🍓 For info on normalizing identifiers, peek at [RADEXT-NAI], Section 2.6 📚

---

4. Security Considerations 🚨

Okay bestie, this section is serious, so buckle up 😭 Besides the requirements in the main sections of the document, applications should think about how server authentication is achieved 👀 Some deployments might allow weak server authentication that then gets checked with an extra existing exchange that provides mutual authentication 💀 To fully shut down the risk of NAS impersonation when these mechanisms are used, it is RECOMMENDED that mutual channel bindings be used to tie the authentications together, as described in [RFC7029] 🔥 And when you're doing channel binding, it is REQUIRED that the authenticator is not able to modify the channel binding data passed between the peer and the authenticator during the authentication process 🛡️✨

---

5. Acknowledgements 🌸

Huge thanks to Sam Hartman of Painless Security, who contributed a ton of helpful text and insightful thoughts 🫶 David Black also helped out by clarifying the text about 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