RFC 7055
A GSS-API Mechanism for the Extensible Authentication Protocol
RFC 7055: A GSS-API Mechanism for the Extensible Authentication Protocol 🎀
Okay bestie, this is the Internet Engineering Task Force (IETF) doc, Request for Comments 7055 📜. It was written by S. Hartman, Ed. of Painless Security and J. Howlett of JANET(UK) 🦋. It's on the Standards Track ✨, which means it's an official Internet standard, and it came out in December 2013 🌸. The ISSN is 2070-1721. The title block doesn't list any Obsoletes or Updates entries, so this doc doesn't claim to replace or amend any other RFC 💅.
Abstract ✨
Okay so this doc is all about the rules and conventions that peers have to follow when they use the Generic Security Service Application Program Interface (GSS-API) together with the Extensible Authentication Protocol mechanism 🔥. Through the GS2 family of mechanisms from RFC 5801, it also explains how Simple Authentication and Security Layer (SASL) applications get to use the Extensible Authentication Protocol 💖.
Status of This Memo
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the whole IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌈.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7055 🦋.
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), as in effect on the date this document was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of 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 📜.
Table of Contents
1. Introduction ....................................................3
1.1. Discovery ..................................................4
1.2. Authentication .............................................4
1.3. Secure Association Protocol ................................6
2. Requirements Notation ...........................................6
3. EAP Channel Binding and Naming ..................................6
3.1. Mechanism Name Format ......................................7
3.2. Internationalization of Names .............................10
3.3. Exported Mechanism Names ..................................10
3.4. Acceptor Name RADIUS AVP ..................................11
3.5. Proxy Verification of Acceptor Name .......................11
4. Selection of EAP Method ........................................12
5. Context Tokens .................................................13
5.1. Mechanisms and Encryption Types ...........................14
5.2. Processing Received Tokens ................................15
5.3. Error Subtokens ...........................................16
5.4. Initial State .............................................16
5.4.1. Vendor Subtoken ....................................17
5.4.2. Acceptor Name Request ..............................17
5.4.3. Acceptor Name Response .............................18
5.5. Authenticate State ........................................18
5.5.1. EAP Request Subtoken ...............................19
5.5.2. EAP Response Subtoken ..............................19
5.6. Extensions State ..........................................20
5.6.1. Flags Subtoken .....................................20
5.6.2. GSS Channel Bindings Subtoken ......................20
5.6.3. MIC Subtoken .......................................21
5.7. Example Token .............................................22
5.8. Context Options ...........................................23
6. Acceptor Services ..............................................23
6.1. GSS-API Channel Binding ...................................24
6.2. Per-Message Security ......................................24
6.3. Pseudorandom Function .....................................24
7. IANA Considerations ............................................25
7.1. OID Registry ..............................................25
7.2. RFC 4121 Token Identifiers ................................26
7.3. GSS-EAP Subtoken Types ....................................26
7.4. RADIUS Attribute Assignments ..............................27
7.5. Registration of the EAP-AES128 SASL Mechanisms ............28
7.6. GSS-EAP Errors ............................................28
7.7. GSS-EAP Context Flags .....................................30
8. Security Considerations ........................................30
9. Acknowledgements ...............................................32
10. References ....................................................32
Appendix A. Pre-publication RADIUS VSA ............................331. Introduction ✨
Okay so the Application Bridging for Federated Access Beyond Web (ABFAB) doc, [ABFAB-ARCH], lays out an architecture for giving federated access management to applications that use the Generic Security Service Application Programming Interface (GSS-API) [RFC2743] and Simple Authentication and Security Layer (SASL) [RFC4422] 🌸. This spec is the core mechanism that brings federated authentication to those apps 💅.
The Extensible Authentication Protocol (EAP) [RFC3748] is a framework for authenticating a network access client and server so the client can get onto a network 🦋. There are loads of different EAP methods out there, and one of EAP's biggest strengths is that for most of the credential types people actually use, there's an EAP method that lets you use that credential 🔥.
EAP usually gets paired with a backend Authentication, Authorization and Accounting (AAA) server, through RADIUS [RFC3579] or Diameter [RFC4072] 💜. In this setup, the Network Access Server (NAS) just tunnels EAP packets over the backend authentication protocol to a home EAP/AAA server for the client 🫶. Once EAP succeeds, the backend protocol is what carries the key material over to the NAS ✨. The NAS doesn't have to know about or specifically support the EAP method being used between the client and the home EAP server 🙈. The client and EAP server share a credential that depends on the EAP method, and the NAS and AAA server share a credential based on whichever backend authentication protocol is in use 🌈. The backend authentication server is a trusted third party, so network access can happen even when the client and NAS don't actually share any common authentication methods 👑. As the architecture document [ABFAB-ARCH] describes, AAA proxies can extend this setup past one organization, giving federated authentication for network access 🎀.
The GSS-API gives applications a generic framework for using security services like authentication and per-message data security 💖. Lots of application protocols can use GSS-API for security, as long as they support GSS-API directly or support SASL [RFC4422] 🧚. But apart from Kerberos [RFC4121], very few GSS-API mechanisms are widely used on the Internet 😭. GSS-API lets you write an application without tying it to one specific GSS-API mechanism, but there's no way to split the server away from the mechanism's implementation like you can with EAP and backend authentication servers 💀.
The goal of this spec is to mash together GSS-API's support for application protocols with EAP/AAA's support for common credential types, and for authenticating to a server without that server needing to specifically support the authentication method in use ⭐. It also supports the architectural goal of carrying attributes about subjects to relying parties 🍓. Put together, this combo gives federated authentication and authorization for GSS-API applications 🔥. This spec also meets the applicability requirements for EAP to application authentication [RFC7057] 💅.
This mechanism is a GSS-API mechanism that encapsulates an EAP conversation 🦋. From RFC 3748's point of view, this spec defines a new lower-layer protocol for EAP ✨. From the application's point of view, it defines a new GSS-API mechanism 👑.
Section 1.3 of [RFC5247] lays out the usual conversation between EAP peers where an EAP key gets derived 🌸:
Phase 0: Discovery
Phase 1: Authentication
1a: EAP authentication
1b: AAA Key Transport (optional)
Phase 2: Secure Association Protocol
2a: Unicast Secure Association
2b: Multicast Secure Association (optional)1.1. Discovery
Okay so GSS-API peers find each other, and find out whether they support GSS-API, using a mechanism that depends on the application 🔍. SASL [RFC4422] describes how a particular SASL mechanism, like a GSS-API EAP mechanism, gets discovered 💜. The Simple and Protected Negotiation mechanism (SPNEGO) [RFC4178] is another way to figure out which GSS-API mechanisms are available 🫶. The specific discovery approach used is out of scope for this mechanism 🙈.
(Part 1 of 9. Part 2 coming up, bestie 🦋)
1.2. Authentication 🔐
Okay so GSS-API authenticates a party called the "GSS-API initiator" to the GSS-API acceptor, and it can optionally prove the acceptor's identity back to the initiator too 💖. Authentication kicks off with a mechanism-specific message called a "context token" that goes from the initiator to the acceptor. The acceptor replies, then the initiator replies, and so on until authentication either succeeds or fails 🦋. GSS-API context tokens get reliably delivered by whatever application is using GSS-API, so that application is the one in charge of in-order delivery and retransmission ✨.
EAP authenticates a party called a "peer" to a party called the "EAP server" 🎀. A third party called an "EAP pass-through authenticator" can decapsulate EAP messages from a lower layer and re-encapsulate them into an AAA protocol. The term "EAP authenticator" means whichever of the pass-through authenticator or the EAP server receives the lower-layer EAP packets 🧚. The first EAP message travels from the authenticator to the peer, but a GSS-API message gets sent from the initiator to the acceptor first, to prompt the authenticator into sending that first EAP message. The EAP peer maps onto the GSS-API initiator, and the GSS-API acceptor role is split between the EAP authenticator and the EAP server. When those two are combined, the division looks a lot like GSS-API acceptors in other mechanisms. In a more typical deployment with a pass-through authenticator, most context establishment happens on the EAP server while per-message operations happen on the authenticator 💅. EAP messages from the peer to the authenticator are called responses, and messages from the authenticator to the peer are called requests.
Since GSS-API applications guarantee delivery of context tokens, the EAP retransmission timeout MUST be infinite, and the EAP layer MUST NOT retransmit a message 🚫.
This spec lets a GSS-API acceptor hand off the processing of the EAP packets to a remote EAP server by using AAA protocols such as RADIUS, Transport Layer Security (TLS) Encryption thereof [RFC6929], or Diameter 🌈. When that happens, the GSS-API acceptor acts as an EAP pass-through authenticator. The pass-through authenticator is responsible for retransmitting AAA messages if a response isn't received from the AAA server. If a response can't be received at all, the authenticator generates an error at the GSS-API level 😭. If EAP authentication succeeds, and the chosen EAP method supports key derivation, EAP keying material may also be derived. If an AAA protocol is being used, it can also be used to replicate the EAP Key from the EAP server to the EAP authenticator.
See Section 5 for details of the authentication exchange 👀.
1.3. Secure Association Protocol 🌸
Once authentication succeeds, GSS-API gives you a bunch of per-message security services you can use:
GSS_Wrap()provides integrity and optional confidentiality for a message.GSS_GetMIC()provides integrity protection for data sent independently of the GSS-API.GSS_Pseudo_random[RFC4401] provides key derivation functionality.
These services do a job that's really similar to secure association protocols in network access 🔑. Just like those protocols, these services need to run near the authenticator/acceptor, even when an AAA protocol is used to separate the authenticator from the EAP server. The key used for these per-message services is derived from the EAP key. The EAP peer and the authenticator both derive this key as a result of a successful EAP authentication. If the EAP authenticator is acting as a pass-through, it gets the key through the AAA protocol instead. See Section 6 for details 🧁.
2. Requirements Notation 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.
3. EAP Channel Binding and Naming 🎀
Okay, big topic. EAP authenticates a user to a realm. The peer knows that it has exchanged authentication with an EAP server in a given realm. Today, though, the peer usually doesn't know which NAS it's talking to securely 🙈. That's often fine for network access. But handing privileges over to a chat server feels super different from handing them over to a file server or a trading site 💀. Also, an EAP peer knows the identity of its home realm, but maybe not even the visited realm.
GSS-API is different: it takes a name for both the initiator and the acceptor as inputs to the authentication process. When mutual authentication is used, both parties get authenticated. How granular these names are depends somewhat on the mechanism. With the Kerberos mechanism, for example, the acceptor name typically identifies both the protocol in use (like IMAP) and the specific instance of the service being connected to. The acceptor name almost always identifies the administrative domain providing the service 🧚.
A GSS-API EAP mechanism needs to provide GSS-API naming semantics so it can work with existing GSS-API applications ✨. EAP channel binding [RFC6677] is what's used to provide those naming semantics. Channel binding sends a set of attributes from the peer to the EAP server, either as part of the EAP conversation or as part of a secure association protocol. Attributes also get sent in the backend authentication protocol from the authenticator to the EAP server. The EAP server then confirms that these attributes are consistent with each other. Confirming attribute consistency also involves checking against a local policy database, as discussed in Section 3.5 📚. Specifically, the peer sends the name of the acceptor it's authenticating to as part of channel binding, and the acceptor sends its full name as part of the backend authentication protocol. The EAP server confirms that the names are consistent 💜.
EAP channel binding is easy to confuse with a facility in GSS-API that's also called "channel binding" 😵💫. GSS-API channel binding protects against man-in-the-middle attacks when GSS-API is used as authentication inside some tunnel, and it's similar to a facility called "cryptographic binding" in EAP. See [RFC5056] for a discussion of the differences between these two facilities, and see Section 6.1 for how GSS-API channel binding is handled in this mechanism 🦋.
3.1. Mechanism Name Format ✨
Okay so before we get into how the initiator and acceptor names get checked in the AAA infrastructure, we need to talk about what a name for an EAP GSS-API mechanism is actually made of 💅. GSS-API lets you import a few different generic name types with GSS_Import_name(). Once you've picked a mechanism, those get converted into a mechanism-specific name called a "Mechanism Name". Quick reminder: a Mechanism Name is the name of an initiator or acceptor, NOT the name of a GSS-API mechanism 🙈. This section covers the mechanism name form first, then which name forms are supported.
The string representation of the GSS-EAP mechanism name has the following ABNF [RFC5234] representation:
char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF
char-escaped = "\" %x2F / "\" %x40 / "\" %x5C
name-char = char-normal / char-escaped
name-string = 1*name-char
user-or-service = name-string
host = [name-string]
realm = name-string
service-specific = name-string
service-specifics = service-specific 0*("/" service-specifics)
name = user-or-service ["/" host [ "/" service-specifics]] [ "@"
realm ]Special characters in a name can be backslash escaped so they don't mean their special thing 🦋. For example, "\" is a literal backslash. Btw this escaping is only a property of the string representation. If the parts of a name get sent through some mechanism that keeps them separate without backslash escaping, then backslash SHOULD have no special meaning. Lowkey a very reasonable vibe 🧚.
The user-or-service part is kind of like the bit of a network access identifier (NAI) that comes before the '@' for initiator names, and for acceptor names it's the service name from the registry of GSS-API host-based services [GSS-IANA] 🌸. The NAI spec has rules for encoding and string preparation so NAIs can support internationalization. Implementations of this mechanism MUST NOT prepare the user-or-service according to those rules, and you'll find the internationalization stuff for this mechanism in Section 3.2 💖. The host part is empty for initiators and usually has the domain name of the system where the acceptor service is running. Some services MAY need extra parameters to tell apart the entity being authenticated against 🎀. Those parameters go in the service-specifics part of the name. The EAP server MUST reject authentication of any acceptor name with a non-empty service-specifics component, UNLESS the EAP server understands the service-specifics and authenticates them 🚫. The meaning of service-specifics is scoped by the user-or-service part. The realm is similar to the realm part of a NAI for initiator names. Again, the NAI internationalization rules MUST NOT be applied to the realm 🙅♀️. For an acceptor name, the realm is the administrative realm of a service.
This name form's string representation is designed to be generally compatible with the string representation of Kerberos names defined in [RFC1964] 🍓.
The GSS_C_NT_USER_NAME form represents an individual user 🧁. From this mechanism's point of view, it can be either an undecorated user name or a name semantically similar to a network access identifier (NAI) [RFC4282]. The name gets split at the first at-sign ('@'). The part before it is the user-or-service portion of the mechanism name, and the part after it is the realm portion of the mechanism name 💅.
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running on a host, and it's textually written as "service@host" 🖥️. This name form is required by most SASL profiles and a bunch of existing apps that use the Kerberos GSS-API mechanism use it too. Supporting it is super important, but it's also kind of a big challenge when it comes to EAP channel binding 😭. Picture this: the server talks to a "server proxy", which is a AAA server near the server. That server proxy talks to the EAP server. The EAP server and server proxy are in different administrative realms. The server proxy is in a position to verify that the request comes from the indicated host. The EAP server can't make that call directly, though 🫠. So the EAP server has to decide whether it trusts the server proxy to verify the host portion of the acceptor name. That trust decision depends on both the host name and the realm of the server proxy. Basically, the EAP server decides whether the server proxy's realm is the right realm for that hostname, and then makes a trust call about the server proxy itself 👑. Kerberos has the same problem, where clients decide which Kerberos realm to trust for a given hostname. The service part of this name goes into the user-or-service part of the mechanism name, and the host part goes into the host part of the mechanism name. The realm part is empty. Authentication will typically fail, though, unless some AAA component tells the EAP server the realm. If the application server knows its realm, it should be indicated in the outgoing AAA request. Otherwise, a proxy SHOULD add the realm 🫶. An alternate form of this name type MAY be used on acceptors. In that case the name form is "service" with no host component. It gets imported with the service as user-or-service and empty host and realm parts. This form is useful when a service isn't sure which name an initiator knows it by 🦋.
If the null name type or the GSS_EAP_NT_EAP_NAME (OID 1.3.6.1.5.5.15.2.1) (see Section 7.1) is imported, then the string representation above should be directly imported ✨. Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) krb5_name(1)}. In a lot of situations, Kerberos GSS-API mechanism names will behave the way you'd expect when used with the GSS-API EAP mechanism, but there are some differences that could cause confusion 🤔. If an implementation does support importing Kerberos names, it SHOULD fail the import if the Kerberos name isn't syntactically a valid GSS-API EAP mechanism name as defined in this section 🚨.
3.2. Internationalization of Names 🌍
For the most part, GSS-EAP names get transported in other protocols, and those protocols define the internationalization semantics 💜. For example, if a AAA server wants to send the user-or-service part of the initiator name to an acceptor, it uses the existing mechanisms in the AAA protocol, and the existing internationalization rules apply. Similarly, inside an application, existing specs like [RFC5178] define how names that get imported and displayed with GSS-API are encoded 🎀.
This mechanism does add a few cases where name components get sent. In those cases, the string is encoded as UTF-8. Senders SHOULD NOT normalize or map strings before sending them. These strings include the RADIUS attributes introduced in Section 3.4 🙈.
When an EAP server compares the host portion of a GSS-EAP acceptor name that a peer supplied in EAP channel binding against the one supplied by an acceptor, EAP servers SHOULD prepare the host portion according to [RFC5891] before the comparison 🌸. Applications MAY prepare domain names before importing them into this mechanism 🧚.
3.3. Exported Mechanism Names 📦
GSS-API has a GSS_Export_name call. You can use it to export the binary representation of a name, and that exported form can be stored on access control lists for binary comparison 🔐.
The exported name token MUST use the format described in Section 3.2 of RFC 2743. The mechanism-specific part of this name token is the string format of the mechanism name described in Section 3.1 💅.
RFC 2744 [RFC2744] puts a requirement on the result of importing a name, canonicalizing it to a Mechanism Name, and then exporting it. That result needs to be the same as importing the name, getting credentials for that principal, initiating a context with those credentials, and exporting the name on the acceptor. In practice, GSS mechanisms often (but not always) meet this requirement. For names expected to be used as initiator names, the requirement is met. Permitting empty host and realm components when importing host-based services, though, might make it possible for an imported name to differ from the exported name that actually gets used 😬. Other mechanisms, like Kerberos, have similar situations where imported and exported names can differ 🫣.
3.4. Acceptor Name RADIUS AVP 🎀
See Section 7.4 for the registrations of RADIUS attribute types that carry the acceptor service name. All the attribute types registered in that section are strings. See Section 3.1 for the details of the values in a name 💖.
If RADIUS is used as the AAA transport, the acceptor MUST send the acceptor name in these attribute types. That means the acceptor breaks its name apart and sends any non-empty portion as a RADIUS attribute 🧩. Except for the service-specifics part of the name, the backslash escaping mechanism isn't used in RADIUS attributes, so backslash has no special meaning there. In the service-specifics part, a literal "/" separates components. In this one attribute, "/" means a slash character that doesn't separate components, and "\" means a literal backslash character 🦋.
The initiator MUST require that the EAP method in use supports channel binding, and it MUST send the acceptor name as part of the channel binding data 🔥. The client MUST NOT indicate mutual authentication in the result of GSS_Init_sec_context unless all of the name elements the client supplied are in a successful channel binding response. For example, if the client supplied a hostname in channel binding data, that hostname MUST be in a successful channel binding response 👑.
If an empty target name is supplied to GSS_Init_sec_context, the initiator MUST fail context establishment unless the acceptor supplies the acceptor name response (Section 5.4.3) 💀. If a null target name is supplied, the initiator MUST use this response to populate EAP channel bindings 🫶.
3.5. Proxy Verification of Acceptor Name 🧚
okay so proxies can totally help check who the acceptor is 💅 like, a AAA proxy sitting near the acceptor might be the one who can verify the acceptor hostname, cuz the EAP server is kinda too far away to check that reliably on its own 🌸
The EAP server (or some proxy the EAP server trusts) is likely the one who can verify the acceptor realm ✨ Basically this proxy is confirming that the right AAA credential is being used for the claimed realm, so the acceptor really is in the organization it says it's part of. It's also usually trusted by the EAP server to make sure the hostname the acceptor claims is a reasonable one for its realm 🫶
A proxy close to the EAP server is unlikely to be able to confirm the acceptor is claiming the correct hostname 🙈 So that job is typically handed off to a proxy near the acceptor 🦋 That proxy is usually expected to verify the acceptor hostname and check that the right AAA credential for that host is being used. It can even insert the acceptor realm if it's missing, which means realm configuration can live at the proxy boundary instead of on every acceptor. iykyk 😭
Ultimately, specific proxy behavior is up to the deployment 👑 The EAP server MUST assure that the appropriate validation has been done before including acceptor name attributes in a successful channel binding response. If the acceptor service is included, the EAP server asserts that the service is plausible for the acceptor. If the acceptor hostname is included, the EAP server asserts that the acceptor hostname is verified. If the realm is included, the EAP server asserts that the realm has been verified, and if the hostname was also included, that the realm and hostname are consistent. Part of this verification MAY be delegated to proxies, but the EAP server configuration MUST guarantee that the combination of proxies meets these requirements. Typically, that delegation involves business or operational measures like cross-organizational agreements, as well as technical measures 💖
It's likely that future technical work will be needed to communicate what verification has been done by proxies along the path 🔥 Technical measures won't release the EAP server from its responsibility to decide whether proxies on the path should be trusted to perform the checks delegated to them. Still, technical measures could prevent misconfigurations and help support diverse environments 🌈
4. Selection of EAP Method 🎀
EAP doesn't have a facility for an EAP server to advertise which methods are available to a peer 🙃 Instead, a server starts with its preferred method selection. If the peer doesn't accept that method, the peer sends a NAK response containing the list of methods supported by the client.
Having multiple ways to negotiate which security mechanism to use is kind of a mess 😭 [RFC4462] describes this problem in Section 7.3, referencing the Secure Shell (SSH) Protocol key exchange negotiation and the SPNEGO GSS-API mechanism. Imagine a client prefers EAP method A, then a non-EAP authentication mechanism B, and then EAP method C. The client would have to commit to using EAP before learning whether A is actually supported. That client might end up using C when B is available 💀
The standard fix is to do all the negotiation at one layer 🧠 In this case, instead of defining a single GSS-API mechanism, you'd define a family of mechanisms, where each mechanism corresponds to an EAP method. The EAP method type should be part of the GSS-API OID. Then a GSS-API facility, rather than EAP, can be used for negotiation.
Unfortunately, using a family of mechanisms causes a bunch of problems 😩 First, GSS-API assumes both the initiator and acceptor know the entire set of mechanisms that are available. Some negotiation mechanisms are driven by the client, and others are driven by the server. With EAP GSS-API, the acceptor doesn't know what methods the EAP server implements, because the EAP server that gets used depends on the identity of the client. So the best solution so far is to accept the downsides of multi-layer negotiation and commit to using EAP GSS-API before picking a specific EAP method. That has two main downsides. First, authentication may fail when other methods might have let it succeed. Second, a non-optimal security mechanism may get chosen 🥲
5. Context Tokens 🦋
All context establishment tokens emitted by the EAP mechanism SHALL have the framing described in Section 3.1 of [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing EAP mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
ENDThe innerToken field starts with a 16-bit network byte order token type identifier. The rest of the innerToken field is a set of type-length-value subtokens. Here's the structure of the inner token 👀
+----------------+---------------------------+
| Octet Position | Description |
+----------------+---------------------------+
| 0..1 | token ID |
| | |
| 2..5 | first subtoken type |
| | |
| 6..9 | length of first subtoken |
| | |
| 10..10+n-1 | first subtoken body |
| | |
| 10+n..10+n+3 | second subtoken type |
+----------------+---------------------------+
Structure of Inner TokenThe inner token continues with length, second subtoken body, and so forth. If a subtoken type is present, its length and body MUST be present.
The length is a four-octet length of the subtoken body in network byte order. The length doesn't include the length of the type field or the length field, so it only covers the body 🍓
Tokens from the initiator to the acceptor use an inner token type with ID 06 01, and tokens from the acceptor to the initiator use an inner token type with ID 06 02. These token types are registered in the registry of RFC 4121 token types; see Section 7.2 🧚
See Section 5.7 for the encoding of a complete token. The next sections cover how mechanism OIDs get chosen and the state machine that defines which subtokens are permitted at each point in the context establishment process 💜
5.1. Mechanisms and Encryption Types 🔐
This mechanism family uses the security services of the Kerberos cryptographic framework [RFC3961]. The root of the OID ARC for mechanisms described in this document is 1.3.6.1.5.5.15.1.1, and a Kerberos encryption type number [RFC3961] gets appended to that root OID to form a mechanism OID. So a particular encryption type needs to be chosen 🫠 By convention, there's a single object identifier arc for the EAP family of GSS-API mechanisms. A specific mechanism is picked by adding the numeric Kerberos encryption type number to the root of this arc. However, to register the SASL name, the specific usage with a given encryption type needs to be registered too. This document defines the EAP-AES128 GSS-API mechanism ✨
5.2. Processing Received Tokens 📬
Whenever a context token is received, the receiver performs the following checks. First, the receiver confirms the object identifier is the one for the mechanism being used. The receiver also confirms that the token type matches the role of the peer: acceptors only process initiator tokens, and initiators only process acceptor tokens 💅
Implementations of this mechanism maintain a state machine for the context establishment process. Both the initiator and acceptor start out in the initial state; see Section 5.4 for a description of this state. Each state has a set of subtoken types that get processed in that state, along with rules for processing them. The receiver examines the subtokens in order and processes any that are appropriate for the current state. Unknown subtokens, or subtokens that aren't expected in the current state, are ignored if their critical bit (see below) is clear 🌸
A state may have a set of required subtoken types. If a subtoken type is required by the current state but no subtoken of that type is present, then the context establishment MUST fail.
The most significant bit (0x80000000) in a subtoken type is the critical bit. If a subtoken with this bit set in the type is received, the receiver MUST fail context establishment unless the subtoken is understood and processed for the current state.
The subtoken type MUST be unique within a given token.
5.3. Error Subtokens 🚨
The acceptor can always end the exchange by generating an error subtoken. The error subtoken has the following format:
+--------+----------------------------------------------------------+
| Pos | Description |
+--------+----------------------------------------------------------+
| 0..3 | 0x80 00 00 01 |
| | |
| 4..7 | length of error token |
| | |
| 8..11 | major status from RFC 2744 as 32-bit network byte order |
| | |
| 12..15 | GSS-EAP error code as 32-bit network byte order; see |
| | Section 7.6 |
+--------+----------------------------------------------------------+Initiators MUST ignore octets beyond the GSS-EAP error code for future extensibility. As indicated, the error token is always marked critical 🙌
5.4. Initial State 🌙
Both the acceptor and the initiator start the context establishment process in the initial state.
The initiator sends a token to the acceptor. It MAY be empty; no subtokens are required in this state. Alternatively, the initiator MAY include a vendor ID subtoken or an acceptor name request subtoken 🍓
The acceptor responds to this message. It MAY include an acceptor name response subtoken. It MUST include a first EAP request; this is an EAP request/identity message (see Section 5.5.1 for the format of this subtoken).
The initiator and acceptor then transition to the authenticate state 🦋
5.4.1. Vendor Subtoken 🎀
okay so the vendor ID subtoken has type 0x0000000B and it's built like this 💅
+-------------+------------------------+
| Pos | Description |
+-------------+------------------------+
| 0..3 | 0x0000000B |
| | |
| 4..7 | length of vendor token |
| | |
| 8..8+length | Vendor ID string |
+-------------+------------------------+The vendor ID string is a UTF-8 string that says who made this implementation ✨. It's unstructured and it's for debugging purposes only 🙈
5.4.2. Acceptor Name Request 🌸
the acceptor name request token is how the initiator tells the acceptor "hey, this is the name I want you to be" 🫶. It's kinda like Transport Layer Security (TLS) Server Name Indication [RFC6066], which lets a client say which of a bunch of virtual services it wants 🦋. The structure goes like this:
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000002 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+ngl this part is sooo important 😭. Channel binding and authentication will likely fail if the acceptor doesn't pick a name that's a superset of the one you sent. So if you send a hostname, the acceptor has to be willing to accept that hostname. No cap, that's the whole vibe 💀
5.4.3. Acceptor Name Response 🧚
the acceptor name response subtoken says which acceptor name is actually being used 💜. It's handy when the initiator didn't give a target name when it started the context, because then the initiator can still find out the acceptor name 👑. EAP channel bindings give confirmation that the acceptor is naming itself correctly ✨.
This token goes from the acceptor to the initiator. In the Initial state, it would typically get sent if the acceptor name request is absent, because if the initiator already sent an acceptor name, then it already knows which acceptor it wants to reach 🍓. This subtoken also shows up in Extensions state (Section 5.6), so the initiator can protect against a man-in-the-middle messing with the acceptor name request subtoken 🛡️🫣.
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000003 |
| | |
| 4..7 | length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+5.5. Authenticate State 🔐
in this state the acceptor sends EAP requests to the initiator, and the initiator makes EAP responses 💬. The goal is a successful EAP authentication, full stop 🏆. Since the acceptor sent an identity request at the end of the initial state, the first half-round-trip here is the initiator answering that request 🙌.
The EAP conversation can end a few different ways:
- If the EAP state machine generates an EAP Success message, then the EAP authenticator believes the authentication worked ✅. The acceptor MUST confirm that a key has been derived (Section 7.10 of [RFC3748]). The acceptor MUST confirm that this success indication is consistent with any protected result indication for combined authenticators, and with AAA indication of success for pass-through authenticators 🧐. If any of these checks fail, the acceptor MUST send an error subtoken and fail the context establishment 💔. If these checks pass, the acceptor sends the Success message using the EAP Request subtoken type and moves on to Extensions state 🎉. When the initiator gets an EAP Success message, it confirms that a key has been derived and that the EAP Success is consistent with any protected result indication. If that's all good, it moves to Extensions state. Otherwise, it returns an error to the caller of GSS_Init_sec_context without producing an output token 😬.
- If the acceptor receives an EAP failure, then the acceptor sends this in the EAP Request subtoken type. If the initiator receives an EAP Failure, it returns GSS failure 🥀.
- If there's some other error, the acceptor MAY return an error subtoken 🤷♀️.
5.5.1. EAP Request Subtoken 💌
the EAP Request subtoken goes from the acceptor to the initiator 📨. This subtoken is always critical and it is REQUIRED in the authentication state 🔥.
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000005 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+5.5.2. EAP Response Subtoken 💖
this subtoken is REQUIRED in authentication state messages from the initiator to the acceptor 🫧. It's always critical, periodt 💅.
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x80000004 |
| | |
| 4..7 | length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+5.6. Extensions State 🌈
after EAP Success, the initiator sends a token to the acceptor with extra subtokens. These either negotiate optional features or provide GSS-API channel binding (see Section 6.1) ✨. The acceptor then answers with a token of its own. When the acceptor makes its final token, it returns GSS_S_COMPLETE, and when the initiator consumes that token, it returns GSS_S_COMPLETE if no errors are detected 🎀.
The acceptor SHOULD send an acceptor name response (Section 5.4.3), so the initiator can get a copy of the acceptor name protected by the Message Integrity Check (MIC) subtoken 🔏. Honestly this is the protective layer that makes the whole thing feel safe 🥹.
Both the initiator and acceptor MUST include and verify a MIC subtoken to protect the extensions exchange 🛡️💜.
5.6.1. Flags Subtoken 🚩
this subtoken carries the initiator's flags over to the acceptor 🏳️🌈. The flags are a 32-bit integer in network byte order 🔢. The only flag defined so far is GSS_C_MUTUAL_FLAG, which means the initiator successfully did mutual authentication of the acceptor 🤝. It gets communicated because some protocols [RFC4462] need the acceptor to know whether the initiator has confirmed its identity 🪪. This flag has the value 0x2 so it stays consistent with RFC 2744 ✨.
+-------+-----------------------+
| Pos | Description |
+-------+-----------------------+
| 0..3 | 0x0000000C |
| | |
| 4..7 | length of flags token |
| | |
| 8..11 | flags |
+-------+-----------------------+Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag octets beyond the first 4, and MUST ignore flag bits other than GSS_C_MUTUAL_FLAG. Initiators MUST send undefined flag bits as zero 🙅♀️✨.
5.6.2. GSS Channel Bindings Subtoken 🦋
this subtoken is always critical when it's sent, and it goes from the initiator to the acceptor 📬. Its contents are an RFC 3961 get_mic token of the application data from the GSS channel bindings structure that was passed into the context establishment call 🧩.
+-------------+-----------------------------------------------+
| Pos | Description |
+-------------+-----------------------------------------------+
| 0..3 | 0x80000006 |
| | |
| 4..7 | length of token |
| | |
| 8..8+length | get_mic of channel binding application data |
+-------------+-----------------------------------------------+Again, only the application data is sent in the channel binding 💅. Any initiator and acceptor addresses an application passes into context establishment calls are ignored and never go over the wire 🙈. The checksum type of the get_mic token SHOULD be the mandatory-to-implement checksum type of the Context Root Key (CRK) 🔑. The key to use is the CRK, and the key usage is 60 (KEY_USAGE_GSSEAP_CHBIND_MIC) 🗝️. An acceptor MAY accept any MIC in the channel bindings subtoken if the channel bindings input to GSS_Accept_sec_context is not provided 🤷♀️. If the channel binding input to GSS_Accept_sec_context is provided, the acceptor MUST return failure if the channel binding MIC in a received channel binding subtoken fails to verify ❌.
The initiator MUST send this token if channel bindings, including application data, are passed into GSS_Init_sec_context, and it MUST NOT send this token otherwise 🫶.
5.6.3. MIC Subtoken
okay so this one is the MIC subtoken and it's literally the closer 💅 It MUST be the last subtoken in the tokens sent in Extensions state, and both the initiator and the acceptor send it 🫶
+-------------+--------------------------------------------------+
| Pos | Description |
+-------------+--------------------------------------------------+
| 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
| | |
| 4..7 | length of RFC 3961 MIC token |
| | |
| 8..8+length | RFC 3961 result of get_mic |
+-------------+--------------------------------------------------+so like, with any get_mic call, you make a token the RFC 3961 way 🧚 You use the CRK (Section 6) as the key, and the mandatory checksum type for the encryption type of the CRK as the checksum type. The key usage is 61 (KEY_USAGE_GSSEAP_ACCTOKEN_MIC) for the subtoken going from the acceptor to the initiator, and 62 (KEY_USAGE_GSSEAP_INITTOKEN_MIC) for the one going from the initiator to the acceptor. The input is built like this:
- The DER-encoded object identifier of the mechanism in use. This value starts with 0x06, which is the tag for object identifier. When it's encoded in an RFC 2743 context token, the object identifier is preceded by the tag and length for [Application 0] SEQUENCE. That tag and the length of the overall token are not included. Only the tag, length, and value of the object identifier itself go in 🌸
- A 16-bit token type in network byte order of the RFC 4121 token identifier (0x0601 for initiator, 0x0602 for acceptor).
- For each subtoken, other than the MIC subtoken itself, the order the subtokens appear in the token is as follows:
- A four-octet subtoken type in network byte order
- A four-byte length in network byte order
- Length octets of value from that subtoken
5.7. Example Token
Time for the example token, bestie 🦋 Here's how the bytes actually look:
+----+------+----+------+-----+-------------------------+
| 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 |
+----+------+----+------+-----+-------------------------+
|App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 |
|Tag |length|Tag |length| Mechanism object ID |
+----+------+----+------+-------------------------------+
+----------+-------------+-------------+
| 06 01 | 00 00 00 02 | 00 00 00 0e |
+----------+-------------|-------------|
|Initiator | Acceptor | Length |
|context | name | (14 octets) |
|token ID | request | |
+----------+-------------+-------------+
+-------------------------------------------+
| 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+-------------------------------------------+
| String form of acceptor name |
| "host/localhost" |
+-------------------------------------------+
Example Initiator Token5.8. Context Options
okay, the GSS-API has a bunch of optional per-context services, and you ask for them with flags on the call to GSS_Init_sec_context. They also come back as outputs from both GSS_Init_sec_context and GSS_Accept_sec_context ✨ This section explains how they get handled. Which services the client picks in GSS_Init_sec_context controls what EAP methods MAY be used by the client 🎀 Section 7.2 of RFC 3748 has a set of security claims for EAP, and the GSS options you pick put requirements on those claims that MUST be met. Read carefully, it's a whole vibe 😭
This GSS mechanism MUST only be used with EAP methods that provide dictionary-attack resistance. Usually you get that by having an EAP tunnel method tunnel an inner method in TLS 🔥
The EAP method MUST support key derivation. Integrity, confidentiality, sequencing, and replay detection MUST be indicated in the output of GSS_Init_sec_context and GSS_Accept_sec_context, no matter which services were requested 🫶
The PROT_READY service defined in Section 1.2.7 of [RFC2743] is never available with this mechanism. Implementations MUST NOT offer this flag, and they MUST NOT permit per-message security services to be used before context establishment. Absolutely not, no notes 🙈
The EAP method MUST support mutual authentication and channel binding. See Section 3.4 for details on what is required for successful mutual authentication. Whether or not mutual authentication is requested, the implementation MUST include channel bindings in the EAP authentication 💜 If mutual authentication is requested and successful mutual authentication takes place as defined in Section 3.4, the initiator MUST send a flags subtoken Section 5.6.1 in Extensions state 👑
6. Acceptor Services ✨
The context establishment process can be passed through to an EAP server via a backend authentication protocol. After the EAP authentication succeeds, though, the acceptor provides the security services directly 💅
This mechanism uses an RFC 3961 cryptographic key called the Context Root Key (CRK). The CRK is derived from the GMSK (GSS-API Master Session Key). The GMSK is the result of the random-to-key [RFC3961] operation of the encryption type of this mechanism, consuming the appropriate number of bits from the EAP MSK. For example, for aes128-cts-hmac-sha1-96, the random-to-key operation consumes 16 octets of key material, so the first 16 bytes of the MSK are the input to random-to-key that forms the GMSK. If the MSK is too short, authentication MUST fail 😭
Here, pseudorandom is the RFC 3961 pseudorandom operation for the encryption type of the GMSK, and random-to-key is the RFC 3961 random-to-key operation for the enctype of the mechanism. The truncate function takes the initial l bits of its input. The goal when constructing a CRK is to call the pseudorandom function enough times to produce the right number of bits of output, then discard any excess bits of output 🌈
The CRK is derived from the GMSK using the following procedure:
Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap")
CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn))
L = random-to-key input sizeWhere n is a 32-bit integer in network byte order, starting at 0 and incremented for each call to the pseudo_random operation.
6.1. GSS-API Channel Binding
GSS-API channel binding [RFC5554] is a protected facility for exchanging a cryptographic name for an enclosing channel between the initiator and the acceptor. The initiator sends channel binding data, and the acceptor confirms that the channel binding data has been checked 🦋
The acceptor SHOULD accept any channel binding provided by the initiator if null channel bindings are passed into gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] depend on this behavior of some Kerberos implementations 🧚
As discussed, the GSS channel bindings subtoken is sent in the Extensions state 🌸
6.2. Per-Message Security
The per-message tokens of Section 4 of RFC 4121 are used. The CRK SHALL be treated as the initiator sub-session key, the acceptor sub-session key, and the ticket session key 💖
6.3. Pseudorandom Function
The pseudorandom function defined in [RFC4402] is used to provide GSS_Pseudo_Random functionality to applications 🎀
7. IANA Considerations 🌸
This specification creates a number of IANA registries, so buckle up 🍓
7.1. OID Registry
IANA has created a registry of ABFAB object identifiers titled "Object Identifiers for Application Bridging for Federated Access". The initial contents of the registry are specified below. The registration policy is IETF Review or IESG Approval [RFC5226]. Early allocation is permitted. IANA has updated the reference for the root of this OID delegation to point to the newly created registry ✨
Decimal Name Description References
------- ---- ---------------------------------- ----------
0 Reserved Reserved RFC 7055
1 mechanisms A sub-arc containing ABFAB RFC 7055
mechanisms
2 nametypes A sub-arc containing ABFAB RFC 7055
GSS-API Name TypesPrefix:
iso.org.dod.internet.security.mechanisms.abfab
(1.3.6.1.5.5.15)NOTE: the following mechanisms registry is the root of the OID for the mechanism in question. As discussed in Section 5.1, a Kerberos encryption type number [RFC3961] is appended to the mechanism version OID below to form the OID of a specific mechanism 💜
Prefix:
iso.org.dod.internet.security.mechanisms.abfab.mechanisms
(1.3.6.1.5.5.15.1) Decimal Name Description References
------- ---- ------------------------------- ----------
0 Reserved Reserved RFC 7055
1 gss-eap-v1 The GSS-EAP mechanism RFC 7055Prefix:
iso.org.dod.internet.security.mechanisms.abfab.nametypes
(1.3.6.1.5.5.15.2) Decimal Name Description References
------- ---- --------------------- ----------
0 Reserved Reserved RFC 7055
1 GSS_EAP_NT_EAP_NAME RFC 7055, Section 3.17.2. RFC 4121 Token Identifiers 🎀
Okay so in the top-level registry called "Kerberos V GSS-API Mechanism Parameters" 💅, there's a subregistry called "Kerberos GSS-API Token Type Identifiers" ✨. Its references are RFC 4121 and this document. Allocation is done by Expert Review [RFC5226]. The Expert's main job is making sure the requester is appropriate for the RFC 4121 mechanism where the identifiers will be used, and that nobody gets two values for the same purpose 🫶. For RFC 4121 and this mechanism, the Expert is currently expected to allocate identifiers from documents in the IETF stream. Basically, the Expert checks that the allocation meets the requirements of the IETF Review process 🌸.
The ID field is a hexadecimal token identifier in network byte order 🧚.
Here are the initial registrations 💖:
+-------+-------------------------------+---------------------------+
| ID | Description | Reference |
+-------+-------------------------------+---------------------------+
| 01 00 | KRB_AP_REQ | RFC 4121, Section 4.1 |
| | | |
| 02 00 | KRB_AP_REP | RFC 4121, Section 4.1 |
| | | |
| 03 00 | KRB_ERROR | RFC 4121, Section 4.1 |
| | | |
| 04 04 | MIC tokens | RFC 4121, Section 4.2.6.1 |
| | | |
| 05 04 | wrap tokens | RFC 4121, Section 4.2.6.2 |
| | | |
| 06 01 | GSS-EAP initiator context | RFC 7055, Section 5 |
| | token | |
| | | |
| 06 02 | GSS EAP acceptor context | RFC 7055, Section 5 |
| | token | |
+-------+-------------------------------+---------------------------+7.3. GSS-EAP Subtoken Types ✨
This document creates a top-level registry called "The Extensible Authentication Protocol Mechanism for the Generic Security Service Application Programming Interface (GSS-EAP) Parameters" 🦋. In any short form of that name, including any URI for this registry, the string GSS has to come before the string EAP 👑. That way, if EAP methods for performing GSS-API authentication are ever defined, it's easy to tell the registries apart 🌈.
Inside that registry is a subregistry of subtoken types. Identifiers are 32-bit integers. The upper bit (0x80000000) is reserved as a critical flag and should not be indicated in the registration 🔥. Assignments are made by Expert Review [RFC5226]. The Expert is expected to require a public specification of the subtoken that's similar in detail to the registrations in this document 💜. GSS-EAP's security depends on subtoken information having adequate protection and on the overall mechanism staying secure 🔐. So the Expert's main responsibility is checking the security and architectural consistency of the proposed registration 💅.
+------------+--------------------------+---------------+
| Type | Description | Reference |
+------------+--------------------------+---------------+
| 0x00000001 | Error | Section 5.3 |
| | | |
| 0x0000000B | Vendor | Section 5.4.1 |
| | | |
| 0x00000002 | Acceptor name request | Section 5.4.2 |
| | | |
| 0x00000003 | Acceptor name response | Section 5.4.3 |
| | | |
| 0x00000005 | EAP request | Section 5.5.1 |
| | | |
| 0x00000004 | EAP response | Section 5.5.2 |
| | | |
| 0x0000000C | Flags | Section 5.6.1 |
| | | |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
| | | |
| 0x0000000D | Initiator MIC | Section 5.6.3 |
| | | |
| 0x0000000E | Acceptor MIC | Section 5.6.3 |
+------------+--------------------------+---------------+7.4. RADIUS Attribute Assignments 🍓
The following RADIUS attribute type values [RFC3575] are assigned 🧁. The allocation instructions in Section 10.3 of [RFC6929] were followed 🙈.
+--------------------------------+-------+--------------------------+
| Description | Value | More Information |
+--------------------------------+-------+--------------------------+
| GSS-Acceptor-Service-Name | 164 | user-or-service portion |
| | | of name |
| | | |
| GSS-Acceptor-Host-Name | 165 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 166 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 167 | Realm portion of name |
+--------------------------------+-------+--------------------------+7.5. Registration of the EAP-AES128 SASL Mechanisms 🌸
Here's the registration template, bestie 📝:
Subject: Registration of SASL mechanisms EAP-AES128 and EAP-AES128-PLUS
SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS
Security considerations: See RFC 5801 and RFC 7055 🔒
Published specification (recommended): RFC 7055
Person & email address to contact for further information: Abfab Working Group, abfab@ietf.org
Intended usage: common
Owner/Change controller: iesg@ietf.org
Note: This mechanism describes the GSS-EAP mechanism used with the aes128-cts-hmac-sha1-96 enctype. The GSS-API OID for this mechanism is 1.3.6.1.5.5.15.1.1.17. ✨
As described in RFC 5801, a PLUS variant of this mechanism is also required 💅.
7.6. GSS-EAP Errors 💀
A new subregistry called "GSS-EAP Error Codes" gets created inside the GSS-EAP parameters registry 🧚. Its error codes are unsigned 32-bit numbers. Values less than or equal to 127 are assigned by Standards Action [RFC5226]. Values 128 through 255 are assigned with the Specification Required assignment policy [RFC5226] 🔥.
Values greater than 255 are reserved. A future update to the registration policy might make these values available for assignment, so implementations MUST be prepared to receive them 🫶.
Here's the initial contents of the registry 📋:
+-------+------------------------------------------------+
| Value | Description |
+-------+------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Buffer is incorrect size |
| | |
| 2 | Incorrect mechanism OID |
| | |
| 3 | Token is corrupted |
| | |
| 4 | Token is truncated |
| | |
| 5 | Packet received by direction that sent it |
| | |
| 6 | Incorrect token type identifier |
| | |
| 7 | Unhandled critical subtoken received |
| | |
| 8 | Missing required subtoken |
| | |
| 9 | Duplicate subtoken type |
| | |
| 10 | Received unexpected subtoken for current state |
| | |
| 11 | EAP did not produce a key |
| | |
| 12 | EAP key too short |
| | |
| 13 | Authentication rejected |
| | |
| 14 | AAA returned an unexpected message type |
| | |
| 15 | AAA response did not include EAP request |
| | |
| 16 | Generic AAA failure |
+-------+------------------------------------------------+7.7. GSS-EAP Context Flags 🦋
Another new subregistry gets created in the GSS-EAP parameters registry 🌈. It holds the flag bits sent in the flags subtoken (Section 5.6.1). There are 32 flag bits available, written as hexadecimal numbers from the most significant bit 0x80000000 down to the least significant bit 0x1 🍓. The registration policy is IETF Review or, in exceptional cases, IESG Approval 👑. The table below shows the initial registrations, and every other value is available for assignment ✨.
+------+-------------------+---------------+
| Flag | Name | Reference |
+------+-------------------+---------------+
| 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 |
+------+-------------------+---------------+8. Security Considerations 🔐✨
okay bestie, this is the part where we get SERIOUS 💅 RFC 3748 covers the security issues around EAP 🔥 and RFC 5247 covers the security and requirements for key management that rides on the AAA infrastructure 🧚. these two docs are literally critical to the security analysis of this mechanism, so go read them, no cap 🫶
RFC 2743 has the generic security considerations for GSS-API 🌸 and RFC 4121 covers the security issues around the specific per-message services this mechanism uses 💜
As discussed in Section 4, this mechanism may introduce multiple layers of security negotiation into application protocols 🦋 and multi-layer negotiations are vulnerable to a bid-down attack 😭 when a mechanism negotiated at the outer layer is preferred to some but not all of the mechanisms negotiated at the inner layer. see Section 7.3 of [RFC4462] for an example 🙈
one possible way to mitigate this is to build your security policy so that the preference for all inner-layer mechanisms falls between the preferences for two outer-layer mechanisms, or falls at one end of the overall ranked list covering both layers 🍓 another approach is to only use this mechanism when it has specifically been selected for a given service ✨ ngl this second approach is probably going to be the common one in practice, because a typical deployment has an EAP supplicant working with a user to pick an identity 🎀 this mechanism only gets attempted once the user has successfully chosen an identity 👑
EAP channel binding is how the GSS-API initiator gets confidence in the identity of the GSS-API acceptor 🌈 so the security of this mechanism depends on EAP channel binding being used AND verified 🔥
okay real talk: EAP channel binding is in very limited deployment right now 😭 if it isn't used, the system may be vulnerable to phishing, where a user gets diverted from one service to another 💀 if the EAP method supports mutual authentication, users can only be diverted between servers that are part of the same AAA infrastructure 🦋 where membership in that infrastructure is limited, this can be a big limit on how useful phishing is as an attack 🌸 but for other deployments, using EAP channel binding is critical to avoid phishing 🚨 these attacks are possible with EAP today, though not typically with common GSS-API mechanisms 💅 which is exactly why implementations are required to implement and use EAP channel binding; see Section 3 for details 🫶
the security considerations of EAP channel binding in [RFC6677] describe its security properties 💜 two attacks are worth calling out here, bestie 👀
first: when a tunneled EAP method is used, it is CRITICAL (okay i'm yelling) that the channel binding is performed with an EAP server the peer trusts 🔥 with existing EAP methods this usually means validating the certificate of the server's tunnel endpoint back to a trust anchor, and confirming the name of the entity that is the subject of that certificate 🧚 EAP methods may also suffer from bid-down attacks, where an attacker can make a peer think a particular EAP server doesn't support channel binding 😭 this doesn't directly cause a problem, because mutual authentication is only offered at the GSS-API level when channel binding to the server's identity succeeds 🎀 however, when an EAP method is NOT vulnerable to these bid-down attacks, you get extra protection 🌈 and this mechanism will benefit a lot from new strong EAP methods like [TEAP] 👑
every proxy in the AAA chain from the authenticator to the EAP server needs to be trusted to help verify channel bindings and to protect the integrity of key material 🫶 GSS-API applications may be built to assume a trust model where the acceptor is directly responsible for authentication 🌸 however, GSS-API is definitely used with trusted-third-party mechanisms like Kerberos 🍓
RADIUS does provide a weak form of hop-by-hop confidentiality for key material, based on using MD5 as a stream cipher 💀 Diameter can use TLS or IPsec, but it has no mandatory-to-implement confidentiality mechanism 🙈 operationally, protecting key material as it's transported between the Identity Provider (IdP) and Relying Party (RP) is critical to per-message security and to verifying GSS-API channel binding [RFC5056] ✨ mechanisms like RADIUS over TLS [RFC6614] give significantly better protection of key material than the base RADIUS spec 🔐
9. Acknowledgements 💖
Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov, and Sujing Zhou gave valuable reviews of this document 🫶 thank you queens 👑
Rhys Smith wrote the text for the OID registry section 💅 and Sam Hartman's work on this document was funded by JANET 🌸
10. References 📚
10.1. Normative References 🦋
- [GSS-IANA] IANA, "GSS-API Service Name Registry",
<http://www.iana.org/assignments/gssapi-service-names>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
- [RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
- [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
- [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
- [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006.
- [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
- [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
- [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
- [RFC7057] 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, December 2013.
10.2. Informative References 🌈
- [ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, July 2013.
- [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
- [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
- [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.
- [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
- [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006.
- [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
- [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
- [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
- [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
- [TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel EAP Method (TEAP) Version 1", Work in Progress, September 2013.
Appendix A. Pre-publication RADIUS VSA ✨
okay so bestie, remember Section 3.4? 🦋 That's where RADIUS attributes come in to carry the acceptor name whenever this family of mechanisms runs over RADIUS. Before this spec got published, though, the acceptor name was carried in a vendor-specific RADIUS attribute instead. 💅 This appendix is non-normative, which just means it's here as a memory lane for the older implementations you might still bump into. 🕰️
Before IANA assigned anything, GSS-EAP used a RADIUS vendor-specific attribute to carry the acceptor name. 🎀 The Vendor-Specific Attribute (VSA) uses enterprise ID 25622 and is formatted as a VSA following the recommendation in the RADIUS specification. 🧚 These are the sub-attributes that were defined:
+--------------------------------+-----------+----------------------+
| Name | Attribute | Description |
+--------------------------------+-----------+----------------------+
| GSS-Acceptor-Service-Name | 128 | user-or-service |
| | | portion of name |
| | | |
| GSS-Acceptor-Host-Name | 129 | host portion of name |
| | | |
| GSS-Acceptor-Service-Specifics | 130 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 131 | Realm portion of |
| | | name |
+--------------------------------+-----------+----------------------+Authors' Addresses 💌
Sam Hartman (editor) Painless Security
EMail: hartmans-ietf@mit.edu
Josh Howlett JANET(UK)
EMail: josh.howlett@ja.net
📦 where this page comes from
- ietf: rfc7055 2013-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms