RFC 6678
Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
RFC 6678: Requirements for a Tunnel-Based EAP Method 🎀
Title block, the tea ☕: This one is RFC 6678, titled Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method. It was published in July 2012 by K. Hoeper (Motorola Solutions, Inc.), S. Hanna (Juniper Networks), H. Zhou and J. Salowey, Ed. (both Cisco Systems, Inc.). It's Informational, which means it's published for information and is not a standards track spec 🦋. Its ISSN is 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅.
Abstract 🌸
Okay so this doc lays out the requirements for a tunnel-based EAP method 🫶. The tunnel uses Transport Layer Security (TLS) to set up a secure tunnel. Once that tunnel exists, it can support password authentication, EAP authentication, and carrying extra data for other purposes. It's giving full toolkit ✨.
Status of This Memo 🧁
This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 😌.
This is an IETF product. It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.
Info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6678. Bookmark it, bestie 🔖.
Copyright Notice 💜
Copyright (c) 2012 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled from this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Some material in this document may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be made outside it either. The exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌍.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 7
3.7. Client Authentication during Tunnel Establishment . . . . 7
3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
3.9. Certificate-Less Authentication and Generic EAP Method
Extension . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
4.3.4. Vendor-Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 15
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
5.4. Separation of TLS Tunnel and Inner Authentication
Termination . . . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . . 211. Introduction 🦋
Okay so an EAP tunnel method is an EAP method that sets up a secure tunnel and then runs other EAP methods inside that protected tunnel 🔐. It can be used over any lower-layer protocol that supports EAP authentication. There are already a few EAP tunnel methods that use TLS to build the tunnel, like Protected EAP [PEAP], Tunneled Transport Layer Security EAP (TTLS) [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. TLS has worked really well, so the consensus is to keep using it as the base for a tunnel method 💅.
People want a protected tunnel for EAP for lots of reasons. It protects weak authentication exchanges, like username and password. It can also give peer identity protection and EAP method chaining. And honestly, systems have found it super useful to carry other kinds of data inside the protected tunnel too ✨.
This document lays out the requirements for an EAP tunnel method, plus a password protocol that supports legacy password verification inside that tunnel method 🌸.
2. Conventions Used in This Document 🎀
Capitalized words in this doc carry specific meanings during the EAP Method Update (EMU) WG's method selection process. Here's the vibe:
- MUST - indicates an absolute requirement
- MUST NOT - indicates something absolutely prohibited
- SHOULD - indicates a strong recommendation of a desired result
- SHOULD NOT - indicates a strong recommendation against a result
- MAY - indicates a willingness to allow an optional outcome
Lowercase uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" just mean what they normally mean and are not subject to these definitions. So no sneaky lowercase requirements, lol 🙈.
3. Use Cases 🧚
To motivate and explain the requirements, here's a representative set of use cases for the EAP tunnel method. A candidate tunnel method MUST support all of the use cases marked below as "MUST". No skipping the MUST ones, periodt 💀.
3.1. Password Authentication 🔑
Lots of legacy systems only support user authentication with passwords. Some of them need the actual username and password sent to the authentication server. That's the case when the auth server doesn't have the cleartext password, or a consistent transform of it. Examples include some one-time password (OTP) systems, and other systems where the username and password get submitted to an external party for validation 🍓.
The tunnel method MUST support transporting the cleartext username and password to the EAP server. It MUST NOT reveal information about the username and password to parties in the communication path between the peer and the EAP server, so keep that privacy locked in 🔒. Any advantage an attacker gets against the tunnel method when a username and password are used for authentication MUST be gained through interaction and not computation. The tunnel MUST support protection from man-in-the-middle attacks 🛡️. And the combo of tunnel authentication and password authentication MUST enable mutual authentication, so both sides get verified 🫶.
Since EAP authentication happens before network access is granted, the tunnel method SHOULD enable an inner exchange for minimal password management tasks. That includes password change, "new PIN mode", and "next token mode", which some systems require 🧁.
3.2. Protection of Weak EAP Methods ✨
okay so some existing EAP methods have holes 🕳️ that can be patched up, or at least shrunk, by running them inside a protected tunnel 🔒. EAP-MD5 is the classic example, bestie: it doesn't give you mutual authentication OR protection from dictionary attacks 💀. without extra protection, EAP tunnel methods are vulnerable to a special kind of tunnel man-in-the-middle (MitM) attack [TUNNEL-MITM] 🙈. for the rest of this doc we'll just call it "tunnel MitM attack" 🎀.
how much protection you need to stop tunnel MitM attacks depends on the inner method running inside the tunnel 🧚. when the method is weak, you can handle it with security policies that say the method can ONLY be used inside a tunnel 🛡️. on the other hand, there's a technical fix called cryptographic bindings 🔗, and it works whenever the inner method derives key material and isn't vulnerable to attacks outside a tunnel. the bindings are the only one of these two options that can be made an actual requirement for EAP tunnel methods (see Section 4.6.3) 💜. security policies are out of scope for this requirement doc, so they don't get a requirement here 🙃.
if you want the deep dive on security policies and full solutions for stopping tunnel MitM attacks, check out the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120] and [LCN-2010] 📚🤓.
so the actual rules are:
The tunnel method MUST support protection of weak EAP methods. Cryptographic protection from tunnel MitM attacks MUST be provided for all key-generating methods. Combine that with an appropriate security policy and it'll thwart MitM attacks against inner methods 🙌✨.
3.3. Chained EAP Methods
okay this one is giving multi-step authentication 🔗. sometimes it's best to chain EAP methods together, like when you want to authenticate the user AND the device they're using 📱👤. the catch? chained EAP methods from different conversations can get redirected into the same conversation by an attacker 😱. the attacker makes the authenticator think both conversations end at the same endpoint 🥷. the fix is cryptographic binding, which can tie the results of chained key-generating methods together, or tie them to an encompassing tunnel 🔐💅.
so the tunnel method MUST support chained EAP methods AND include protection against attacks on method chaining 👑.
3.4. Identity Protection
when the peer runs an EAP authentication, it might want to keep its identity private 🥹. it should only reveal that identity to an EAP server it trusts 🫶. this helps keep the peer's privacy intact 🌸.
the tunnel method MUST support identity protection, so the identity of the peer used for authentication MUST NOT be obtainable by any entity OTHER than the EAP server that terminates the tunnel method 🙈🔒. the identity protection the tunnel method gives applies to the identities specific to the tunnel method and the inner method being used 🎀. also, in a roaming situation, the peer might have to expose the realm part of the EAP outer identity in the Network Access Identifier (NAI) [RFC4282] so it can reach the right authentication server 🗺️. it's a tradeoff, bestie, but a necessary one 💖.
3.5. Anonymous Service Access
sometimes a network offers service where users need access to limited stuff, like emergency calls or troubleshooting info 🚨🧰. so the user gets network access without fully authenticating 🫠. but to avoid eavesdropping, it's best to negotiate link-layer security, just like with any other authentication 🔐👀.
so the tunnel method SHOULD allow anonymous peers or server-only authentication, while still deriving keys that can be used for link-layer security 🦋. it MAY also allow the client to bypass server authentication processing 🌈.
skipping user or server authentication makes man-in-the-middle and other attacks more likely, and those attacks can compromise the keys used for link-layer security 😬. so passwords and other sensitive info MUST NOT be disclosed to an unauthenticated server, or to a server that isn't authorized to authenticate the user 🚫🔑. not me clinging to my passwords like that 💅.
3.6. Network Endpoint Assessment
the Network Endpoint Assessment (NEA) protocols and reference model in [RFC5209] give you a standard way to check the health ("posture") of a device when it connects to a network, or after 🩺✨. if the device doesn't meet the network's requirements, it can be denied access, or given limited access so it can fix itself 🛠️. EAP is a super convenient place to run an NEA exchange 💜.
the tunnel method SHOULD support carrying NEA protocols, like a Posture Broker protocol compatible with Trusted Network Connect (PB-TNC) [RFC5793] 🍓. depending on the specifics of the tunnel method, these protocols might have to be carried in an EAP method 🤷♀️.
3.7. Client Authentication during Tunnel Establishment
sometimes the peer already has credentials that let it authenticate while the tunnel is being set up 🎟️. those credentials might only partly authenticate the peer's identity, so extra authentication could still be needed INSIDE the tunnel 🧩. like, a communication device could get authenticated during tunnel setup, and then user authentication might still be needed to meet the authentication policy 👩💻✨.
the tunnel method MUST be capable of providing client-side authentication during tunnel establishment 💪.
3.8. Extensibility
the tunnel method MUST provide extensibility, so extra data about authentication, authorization, and network access can be carried inside the tunnel in the future 🔮. this means nobody has to build a brand-new tunneling method for every specific purpose 🙌. iconic efficiency 👑.
one app of extensibility is credential provisioning 🗝️. once a peer has authenticated with EAP, that's the perfect moment to hand it credentials for later authentication exchanges 🎁. for example, the authentication server can give the peer a private key or shared key that the peer can use for rapid re-authentication or roaming 🏃♀️💨. there have also been proposals to do enrollment within EAP, like [EAP-ENROLL] 📝. and another use for extensibility is supporting alternate authentication frameworks inside the tunnel 🧚♀️.
3.9. Certificate-Less Authentication and Generic EAP Method Extension
sometimes the peer can't verify a server certificate, and sometimes the server doesn't even have one 📜🙅♀️. so it's desirable to support certificate-less authentication 🫧. one example is credential provisioning, where the peer and server authenticate each other with a shared password, and then credentials for later authentication (like a key pair and certificate, or a shared key) get passed inside the tunnel 🔑💕. another example is extending existing EAP methods with new features, like EAP channel bindings ⭐.
⚠️ Great care must be taken when using tunnels with no server authentication to protect an inner method. the client might not have the right trust roots to fully authenticate the server, but it can still set up the tunnel to run an inner EAP method for mutual authentication and key derivation 🥺. in these cases, the inner EAP method MUST provide resistance to dictionary attack, and a cryptographic binding between the inner method and the tunnel method MUST be established 🔗. on top of that, the cipher suite used to set up the tunnel MUST derive the master key using contributions from both client and server, like ephemeral Diffie-Hellman cipher suites do 🌊.
the tunnel method MAY allow for certificate-less authentication 💫.
4. Requirements 📋
4.1. General Requirements
4.1.1. RFC Compliance
the tunnel method MUST include a Security Claims section with all the security claims specified in Section 7.2 in RFC 3748 [RFC3748] 🧾. it also MUST meet the requirement in Sections 2.1 and 7.4 of RFC 3748 that tunnel methods MUST support protection against man-in-the-middle attacks 🛡️. and the tunnel method MUST support identity protection as specified in Section 7.3 of RFC 3748 🫶.
the tunnel method MUST be unconditionally compliant with RFC 4017 [RFC4017] (using the definition of "unconditionally compliant" in Section 1.1 of RFC 4017). this means the method MUST satisfy all the "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" requirements in RFC 4017 💅.
the tunnel method MUST meet all the "MUST" and "SHOULD" requirements relevant to EAP methods in the EAP key management framework [RFC5247] or any successor 🗂️. this includes generating the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id, Server-Id, and Session-Id 🔑. these requirements let the tunnel method fit properly into the EAP key management framework, keeping all of that framework's security properties and guarantees 🌸✨.
the tunnel method MUST NOT be tied to any single cryptographic algorithm 🙅♀️. instead, it MUST support run-time negotiation to select among an extensible set of cryptographic algorithms, like the algorithms used with certificates presented during tunnel establishment 🔄. this "cryptographic algorithm agility" has some major perks 🦋. most importantly, when a weakness in an algorithm is discovered, or increased processing power overtakes an algorithm, users can easily switch to a new one 🏃♀️💨. users can also pick whichever algorithm best meets their needs 💖.
the tunnel method MUST meet the SHOULD and MUST requirements pertinent to EAP methods in Section 3 of RFC 4962 [RFC4962] 🧠. this includes cryptographic algorithm independence; strong, fresh session keys; replay detection; keying material confidentiality and integrity; and confirmation of cipher suite selection 🔐🎀.
4.2. Tunnel Requirements
okay so this section talks about requirements for TLS tunnel establishment 🔐🌈.
4.2.1. TLS Requirements
the tunnel-based method MUST support TLS version 1.2 [RFC5246] 💜. it may support earlier versions greater than SSL 2.0 so backwards compatibility is possible 🕰️.
4.2.1.1. Cipher Suites
4.2.1.1.1. Cipher Suite Negotiation
okay bestie, cipher suite negotiations ALWAYS suffer from downgrading attacks when they aren't secured by some kind of integrity protection 😭. the common fix is a post-negotiation integrity check 🔍. as soon as they're available, the established keys (here, the tunnel key) get used to derive integrity keys 🗝️. then the peer and authentication server use those integrity keys to verify whether someone maliciously changed the cipher suite negotiation 🕵️♀️.
integrity checks only prevent downgrading attacks if the derived integrity keys and the integrity algorithms can't be broken in real time 🕰️. see Section 5.1 or [HC07] for more on this 📖. so the tunnel method MUST provide integrity-protected cipher suite negotiation with secure integrity algorithms and integrity keys 🫶✨.
TLS provides protected cipher suite negotiation as long as all the cipher suites supported provide authentication, key establishment, and data integrity protection, as discussed in Section 5.1 🎀💅.
4.2.1.1.2. Tunnel Data Protection Algorithms ✨
Okay bestie, this one is about keeping the inner auth methods safe from crypto attacks 🛡️. The tunnel's protection needs a basic level of algorithm strength, or the inner methods' algorithms are fair game for attackers 💀. So the tunnel method MUST provide at least one mandatory-to-implement cipher suite that gives the equivalent security of 128-bit AES for encryption and message authentication 🔐. If you want the lowdown on how the common algorithms stack up, check out Part 1 of the NIST "Recommendation for Key Management" [NIST-SP-800-57] 📚🌸.
4.2.1.1.3. Tunnel Authentication and Key Establishment 🎀
This is the part where the tunnel has to prove itself 💅. A tunnel method MUST provide unidirectional authentication from the authentication server to the EAP peer, AND mutual authentication between the authentication server and the EAP peer 🫶. The tunnel method MUST also provide at least one mandatory-to-implement cipher suite that gives certificate-based authentication of the server, and it provides optional certificate-based authentication of the client 🔑. Other types of authentication MAY be supported too 🦋.
At least one mandatory-to-implement cipher suite MUST be approved by the NIST "Draft Recommendation for Key Management", Part 3 [NIST-SP-800-57p3]. In other words, the cipher suite MUST be listed in Table 4-1, 4-2, or 4-3 in that document 📋✨.
The mandatory-to-implement cipher suites MUST only include cipher suites that use strong cryptographic algorithms 💪. They MUST NOT include cipher suites that provide mutually anonymous authentication, and they MUST NOT include static Diffie-Hellman cipher suites 🙅♀️. No weak sauce allowed, periodt 🔥.
Other cipher suites MAY be selected, as long as they follow the security requirements for tunnel protocols in the NIST "Recommendation for EAP Methods Used in Wireless Network Access Authentication" [NIST-SP-800-120] 🌈.
4.2.1.2. Tunnel Replay Protection 🔁
Replay attacks are so not it 🙅♀️. To stop them, the message authentication MUST be generated using a time-variant input, like timestamps, sequence numbers, nonces, or a combo of these 🧚. That way, any reuse of the authentication data can be caught and marked as invalid 🚫. TLS gives sufficient replay protection to meet this requirement, as long as the weak cipher suites discussed in Section 5.1 are avoided 💜.
4.2.1.3. TLS Extensions 🧩
To meet the requirements in this document, TLS extensions MAY be used ✨. For example, TLS extensions can be useful for providing certificate revocation information through the TLS Online Certificate Status Protocol (OCSP) extension [RFC6066], which meets the requirement in Section 4.5.1.3 🎀.
4.2.1.4. Peer Identity Privacy 🙈
A tunnel protocol MUST support peer privacy, and honestly this one is huge 😭. It means the username and other attributes tied to the peer are NOT sent in the clear, and they're also not sent to an unauthenticated, unauthorized party 🔒. Peer identity protection from the tunnel method covers both setting up the tunnel and protecting inner-method-specific identities 🫣. If it applies, the peer certificate is sent confidentially, which means encrypted 🤫💖.
4.2.1.5. Session Resumption 🌸
The tunnel method MUST support TLS session resumption as defined in [RFC5246] 💅. The tunnel method MAY also support other session resumption methods, like the ones defined in [RFC5077] 🦋.
4.2.2. Fragmentation 🧁
Sometimes tunnel establishment needs to exchange more info than fits in a single EAP message 📦. Plus, the info carried inside the tunnel can be too big too 😩. So a tunnel method MUST support fragmentation and reassembly 🧩✨.
4.2.3. Protection of Data External to Tunnel 🛡️
A man-in-the-middle attacker can modify cleartext values outside the TLS tunnel, like protocol version and type code info 👀. So the tunnel method MUST provide implicit or explicit protection of the protocol version and type code 🔐. If modifying other info outside the tunnel could cause exploitable vulnerabilities, the tunnel method MUST provide protection against modification of that additional data too 🚨.
4.3. Tunnel Payload Requirements 👑
This section is all about what goes INSIDE the tunnel 🎁. These requirements mostly describe features a candidate protocol has to be able to offer, so a deployer can decide whether to use each one 💅. This section does NOT say which features of each protocol must be used during a deployment 🙅♀️.
4.3.1. Extensible Attribute Types 🧚
The payload MUST be extensible 🌈. Some standard payload attribute types will be defined to meet known requirements, like password authentication, inner EAP method, vendor-specific attributes, and result indication 🎀. Additional payload attributes MAY be defined in the future for new features and data types 🔮.
4.3.2. Request/Challenge Response Operation 🔄
The payload MUST support the request and response type of half-duplex operation that's typical of EAP 🏓. Multiple attributes can be sent in a single payload ✨. The payload MAY also support transporting multiple authentications in a single payload packet 📦.
4.3.3. Indicating Criticality of Attributes 🚩
New attributes are expected to be defined for the tunnel method 🌱. Sometimes the sender needs to know if the receiver didn't understand an attribute 🤔. So there MUST be a way for the sender to mark attributes so the receiver will indicate when an attribute is not understood 📣.
4.3.4. Vendor-Specific Support 🏷️
The payload MUST support communication of an extensible set of vendor-specific attributes 💜. These attributes get segmented into uniquely identified vendor-specific namespaces 🗂️. They can be used for experiments or vendor-specific features 🧪.
4.3.5. Result Indication ✅
The payload MUST support result indication and its acknowledgement, so the EAP peer and server both end up with a synchronized state 🫶. Result indication is needed after each chained inner authentication method and at the end of the whole authentication, so separate result indications for intermediate and final results MUST be supported 🔁.
4.3.6. Internationalization of Display Strings 🌍
The payload MAY provide a standard attribute format that supports international strings 🗺️. This attribute format MUST support encoding strings in UTF-8 [RFC3629] format 💖. Any strings the server sends for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference, as indicated by RFC 5646 [RFC5646] 🌸. Note that in some cases, like transmitting error codes, it's totally fine to exchange numeric codes that the client can translate into the local language 🙌. Those numeric codes are NOT subject to internationalization during transmission 🔢.
4.4. EAP Channel Binding Requirements 🔗
The tunnel method MUST be capable of meeting the EAP channel binding requirements described in [RFC6677] 💅. As discussed in [RFC5056], EAP channel bindings are different from the channel bindings discussed in other contexts 🧐. Cryptographic binding between the TLS tunnel and the inner method, discussed in Section 4.6.3, relates directly to the non-EAP channel binding concepts in RFC 5056 🦋✨.
4.5. Requirements Associated with Carrying Username and Passwords 🔐
This section covers the requirements for tunneled password authentication 🎀. The password authentication here means user or machine auth using a legacy password database or verifier, like the Lightweight Directory Access Protocol (LDAP) [RFC4511], OTP, and so on 🗝️. These usually need the password in its original text form to authenticate the peer 😬. That means the peer has to send the cleartext username and password to the EAP server 🫣.
4.5.1. Security 🛡️
Lots of internal EAP methods have the peer send its password in the clear to the EAP server 😱. Other methods, like challenge-response ones, are vulnerable to attacks if an eavesdropper can intercept the traffic 👀. For any of these methods, the security measures in the following sections MUST be met 🚨.
4.5.1.1. Confidentiality and Integrity 💖
The cleartext password exchange MUST be integrity and confidentiality protected 🔒. As long as the password exchange happens inside an authenticated and encrypted tunnel, this requirement is met ✨.
4.5.1.2. Authentication of Server 🫶
The EAP server MUST be authenticated BEFORE the peer sends the cleartext password to it 🛑. No handing your password to a stranger, bestie 💅.
4.5.1.3. Server Certificate Revocation Checking 📜
When certificate authentication is used during tunnel establishment, the EAP peer may need to present its password to the server BEFORE it has network access to check the revocation status of the server's credentials 😩. So the tunnel method MUST support mechanisms to check the revocation status of a credential 🔍. The tunnel method SHOULD make use of the Online Certificate Status Protocol (OCSP) [RFC2560] or the Server-based Certificate Validation Protocol (SCVP) [RFC5055] to get the revocation status of the EAP server certificate 🌟.
4.5.2. Internationalization 🌏
The password authentication exchange MUST support usernames and passwords in international languages 🗣️. It MUST support encoding of username and password strings in UTF-8 [RFC3629] format 💜. The method MUST specify how username and password normalizations and/or comparisons are performed, in reference to SASLprep [RFC4013], Net-UTF-8 [RFC5198], or their replacements 📝.
Any strings the server sends for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference, as indicated by RFC 5646 [RFC5646] 🌸. Note that, in some cases like transmitting error codes, it's acceptable to exchange numeric codes that the client can translate into the local language 🙌. These numeric codes are NOT subject to internationalization during transmission 🔢.
4.5.3. Metadata 🏷️
The password authentication exchange SHOULD support additional associated metadata that can indicate whether the authentication is for a user or a machine 🧑💻🖥️. This lets the EAP server and peer request and negotiate authentication specifically for a user or a machine 🤝. It's super useful when there are multiple inner authentications and both the user and the machine need to be authenticated 💅.
4.5.4. Password Change 🔑
The password authentication exchange MUST support password change 🔄. The exchange SHOULD be extensible to support other "housekeeping" functions, like managing PINs or other data that some systems need 🧹✨.
4.6. Requirements Associated with Carrying EAP Methods 🦋
The tunnel method MUST be able to carry inner EAP methods WITHOUT modifying them 🎀. EAP methods MUST NOT be redefined inside the tunnel 🙅♀️.
4.6.1. Method Negotiation 🤝
The tunnel method MUST support the protected negotiation of the inner EAP method 🔐. It MUST NOT allow intermediaries to manipulate the inner EAP method negotiation 🚫🧚.
4.6.2. Chained Methods 🔗
The tunnel method SHOULD support chaining multiple EAP methods together 💞. The tunnel method MUST allow for the communication of intermediate results and for verification of compound binding between executed inner methods when chained methods are used 🫶✨.
4.6.3. Cryptographic Binding with the TLS Tunnel ✨
Okay bestie, the tunnel method MUST provide a mechanism to bind the tunnel protocol and the inner EAP method, and that's called cryptographic binding 🔐. Bindings are a huge tool for stopping tunnel MitM attacks [TUNNEL-MITM] 💀. Cryptographic bindings can fully prevent tunnel MitM attacks without extra security policies, as long as the inner method derives keys and isn't vulnerable to attacks outside a protected tunnel [LCN-2010]. Weak or non-key-deriving inner methods may still be permitted, though 🙈. So security policies that prevent tunnel MitM attacks are still needed, and the tunnel method MUST provide cryptographic bindings, because that's what lets you move to more secure, policy-independent implementations 👑.
Cryptographic bindings usually happen by securely mixing the keying material from the tunnel protocol (like tunnel key TK) with the keying material from the inner authentication method(s) (like method key MK), which gives you fresh keying material 🧪. If chained EAP methods run inside the tunnel, all the derived inner keys get combined with the tunnel key into a new compound tunnel key (CTK) 🔗. CTK is then used to derive the EAP MSK, EMSK and other transient keys (shown as "TEK" below), like transient encryption keys and integrity protection keys 🗝️. Figure 1 shows the key hierarchy for tunnel method executions that derive compound keys for binding 🌸.
For sequential executions of n inner methods, a chained compound key CTK_i MUST be computed when each inner method i completes, so that it contains the compound key of all previous inner methods: CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n and CTK_0=TK. Here f() is a key derivation function, such as one that complies with NIST's "Recommendation for Key Derivation Using Pseudorandom Functions" [NIST-SP-800-108] 🤓. CTK_n SHOULD serve as the key to derive further keys. Figure 1 depicts the key hierarchy for a single inner method. Transient keys derived from the compound key CTK are used in a cryptographic protocol to verify the integrity of the tunnel and the inner authentication method 🛡️.
-----------
| TK | MK |
-----------
| |
v v
--------
| CTK |
--------
|
v
----------------
| | |
v v v
------- ------ -------
| TEK | | MSK | | EMSK |
------- ------- --------
Figure 1: Compound KeysFurthermore, all compound keys CTK_i and all keys derived from them SHOULD follow the recommendations for key derivations and key hierarchies in [NIST-SP-800-108] 📚. In particular, every derived key MUST have a lifetime that doesn't exceed the lifetime of any key higher up the hierarchy ⏳. The derivation MUST prevent a compromise in one part of the system from leading to compromises in other parts that rely on keys at the same or higher level in the hierarchy 🚫.
4.6.4. Peer-Initiated EAP Authentication 🙋
The tunnel method SHOULD allow the peer to start an inner EAP authentication, so it can meet its policy requirements for authenticating the server 💖.
4.6.5. Method Metadata 🏷️
The tunnel method SHOULD allow additional data associated with an EAP method to be communicated. This can indicate whether the authentication is for a user or a machine 🧑💻🖥️. That way, the EAP server and peer can request and negotiate authentication specifically for a user or for a machine. It's super useful when there are multiple inner EAP authentications and both the user and the machine need to be authenticated 👯.
5. Security Considerations ✨
A tunnel method is often deployed to provide mutual authentication between EAP Peer and EAP Server and to generate key material for protecting lower-layer protocols 🔒. The tunnel also protects other data, including peer identity, between EAP Peer and EAP Server from disclosure to or modification by an attacker 🫣. These sections cover the considerations that affect whether a method can actually reach these goals 🎯.
5.1. Cipher Suite Selection 🧩
TLS supports a wide range of cipher suites with different security properties, so picking one is critical to the security of the tunnel method 🔑. Choosing a cipher suite with weak or no authentication, like an anonymous Diffie-Hellman-based cipher suite, will greatly increase the risk of system compromise 💀. Since a tunnel method uses the TLS tunnel to transport data, picking a cipher suite with weak data encryption and integrity algorithms also makes the method more vulnerable to attacks 😭.
A tunnel protocol is prone to downgrading attacks if it supports any key establishment algorithm that can be broken on-line. In a successful downgrading attack, an adversary breaks the selected "weak" key establishment algorithm and optionally the "weak" authentication algorithm without being detected. Here, "weak" refers to a key establishment algorithm that can be broken in real time, and to an authentication scheme that can be broken off-line, respectively 🕵️. See [HC07] for more details. The requirements in this document disapprove the use of key establishment algorithms that can be broken on-line 🙅♀️.
Mutually anonymous tunnel protocols are prone to man-in-the-middle attacks described in [HC07]. During such an attack, an adversary establishes one tunnel with the peer and one with the authentication server, while the peer and server believe they've built a tunnel with each other 😱. Once both tunnels are up, the adversary can eavesdrop on all communications within the tunnels, i.e., the execution of the inner authentication method(s). That means the adversary can eavesdrop on the identifiers exchanged as part of the EAP method, so the privacy of the peer and/or authentication server is compromised, along with any other data sent inside the tunnels 🫠. This document requires server authentication to avoid the risks associated with anonymous cipher suites 🛡️.
5.2. Tunneled Authentication 🎭
In many cases, a tunnel method provides mutual authentication by authenticating the server during tunnel establishment and then authenticating the peer inside the tunnel using an EAP method. As [TUNNEL-MITM] describes, this mode of operation can let tunnel man-in-the-middle attackers authenticate to the server as the peer, by tunneling the inner EAP protocol messages to and from a peer that's running the method outside a tunnel or with an untrustworthy server 🫣. Cryptographic binding between the established keying material from the inner authentication method(s) and the tunnel protocol verifies that the endpoints of the tunnel and the inner authentication method(s) are the same. This can thwart the attack if the inner-method-derived keys are strong enough that they can't be broken in real time 💪.
In cases where the inner authentication method doesn't generate any key material or only weak key material, security policies MUST be enforced so the peer can't execute the inner method with the same credentials outside a protective tunnel or with an untrustworthy server 🚨
5.3. Data External to Tunnel 📦
The tunnel method will use data that sits outside the TLS tunnel, like the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values, the tunnel method MUST protect this data from modification. In some cases, external data may not need extra protection, because it's implicitly verified during protocol operation ✅.
5.4. Separation of TLS Tunnel and Inner Authentication Termination 🪓
Terminating the inner method at a different location than the outer tunnel needs careful consideration 🤔. The inner method data may be vulnerable to modification and eavesdropping between the server that terminates the tunnel and the server that terminates the inner method. For example, if a cleartext password is used, it may be sent to the inner method server in a RADIUS password attribute, which uses weak encryption that may not be suitable protection for many environments 🙃.
In some cases, terminating the tunnel at a different location may make it difficult for a peer to authenticate the server and trust it for further communication. For example, if the TLS tunnel is terminated by a different organization, the peer needs to be able to authenticate and authorize the tunnel server to handle secret credentials that the peer shares with the home server that terminates the inner method. This may not meet the security policy of many environments 😬.
6. References 📚
6.1. Normative References
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
W. Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, August
2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management
Framework", RFC 5247, August 2008.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel
Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, July 2012.6.2. Informative References 📚✨
okay so these are the "for your reading list" ones, bestie 🧚 nothing here is a MUST-read, but they're the receipts behind the whole spec. the vibe is research-girlie, and every single entry stays exactly as written 💅
[EAP-ENROLL] Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", Work in Progress, March 2006.
[HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims
Fail", Institute for Computer Sciences, Social
Informatics and Telecommunications Engineering (ICST),
The Fourth International Conference on Heterogeneous
Networking for Quality, Reliability, Security and
Robustness (QShine 2007), August 2007.
[LCN-2010] Hoeper, K. and L. Chen, "An Inconvenient Truth about
Tunneled Authentications", Proceedings of 35th Annual
IEEE Conference on Local Computer Networks (LCN 2010),
September 2009.
[NIST-SP-800-108]
Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", Draft NIST Special Publication
800-108, April 2008.
[NIST-SP-800-120]
Hoeper, K. and L. Chen, "Recommendation for EAP Methods
Used in Wireless Network Access Authentication", NIST
Special Publication 800-120, September 2009.
[NIST-SP-800-57]
Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendation for Key Management - Part 1:
General (Revised)", NIST Special Publication 800-57,
part 1, March 2007.
[NIST-SP-800-57p3]
Barker, E., Burr, W., Jones, A., Polk, W., Rose, S.,
and M. Smid, "Recommendation for Key Management, Part 3
Application-Specific Key Management Guidance", Draft
NIST Special Publication 800-57, part 3, October 2008.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP) Specification", August
2009, <http:// download.microsoft.com/download/9/5/E/
95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-
PEAP%5D.pdf>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
"The Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol Method (EAP-FAST)",
RFC 4851, May 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption
without Server-Side State", RFC 5077, January 2008.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for
Network Interchange", RFC 5198, March 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and
J. Tardo, "Network Endpoint Assessment (NEA): Overview
and Requirements", RFC 5209, June 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
Authentication Protocol Tunneled Transport Layer
Security Authenticated Protocol Version 0 (EAP-
TTLSv0)", RFC 5281, August 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan,
"PB-TNC: A Posture Broker (PB) Protocol Compatible with
Trusted Network Connect (TNC)", RFC 5793, March 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, January
2011.
[TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-
Middle in Tunnelled Authentication Protocols",
Cryptology ePrint Archive: Report 2002/163, November
2002.Authors' Addresses 🎀
and last but not least, the squad that made this happen 🫶 here are the contact details, copied exactly:
Katrin Hoeper
Motorola Solutions, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
USA
EMail: khoeper@motorolasolutions.com
Stephen Hanna
Juniper Networks
3 Beverly Road
Bedford, MA 01730
USA
EMail: shanna@juniper.net
Hao Zhou
Cisco Systems, Inc.
4125 Highlander Parkway
Richfield, OH 44286
USA
EMail: hzhou@cisco.com
Joseph Salowey (editor)
Cisco Systems, Inc.
2901 3rd. Ave
Seattle, WA 98121
USA
EMail: jsalowey@cisco.comthat's the whole document, bestie 🌈💜 literally iconic work from these four 👑
📦 where this page comes from
- ietf: rfc6678 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms