A GSS-API Mechanism for the Extensible Authentication Protocol
Extracted elements (32)
Rather than defining a family of per-EAP-method GSS-API mechanisms (one OID per method), a single mechanism was chosen to avoid forcing clients to commit to EAP before learning whether a preferred EAP method is available, at the cost of potential bid-down to a non-optimal EAP method. The EAP encryption type is encoded in the OID only to allow SASL name registration.
Prior to IANA assignment, GSS-EAP used a vendor-specific RADIUS attribute (VSA enterprise ID 25622) with sub-attributes 128–131 for the same four acceptor name components now assigned standard attribute values 164–167. Older implementations may send the VSA form.
Because GSS-API applications guarantee delivery of context tokens, the EAP retransmission timeout MUST be infinite and the EAP layer MUST NOT retransmit a message.
Both the initiator and acceptor MUST include and verify a MIC subtoken in Extensions state. The MIC subtoken MUST be the last subtoken in Extensions-state tokens.
If a received subtoken has its most-significant bit (0x80000000) set in the type field (the 'critical bit'), the receiver MUST fail context establishment unless the subtoken is understood and processed for the current state. A required subtoken absent from a token also causes MUST-fail.
If RADIUS is used as the AAA transport, the acceptor MUST send its decomposed name in the registered RADIUS attributes (GSS-Acceptor-Service-Name, GSS-Acceptor-Host-Name, GSS-Acceptor-Service-Specifics, GSS-Acceptor-Realm-Name). The initiator MUST require that the EAP method support channel binding and MUST send the acceptor name as part of channel binding data.
Implementations MUST NOT apply NAI (RFC 4282) internationalization preparation rules to the user-or-service or realm components of the mechanism name. EAP servers SHOULD prepare host portions using RFC 5891 (IDNA) before comparing them.
On receipt of EAP Success, the acceptor MUST confirm that a key has been derived and that the success is consistent with any protected result indication and AAA indication. If checks fail, the acceptor MUST send an error subtoken and fail context establishment.
The EAP method used with this mechanism MUST support dictionary-attack resistance, key derivation, mutual authentication, and channel binding. Integrity, confidentiality, sequencing, and replay detection MUST be indicated in GSS_Init/Accept_sec_context outputs regardless of which services are requested.
The EAP server MUST assure that appropriate acceptor name validation has been performed before including acceptor name attributes in a successful channel binding response; delegation to proxies is allowed only if the EAP server configuration guarantees the combination of proxies meets verification requirements.
The initiator MUST NOT indicate mutual authentication unless all name elements it supplied are returned in a successful channel binding response. If an empty target name is supplied, context establishment MUST fail unless the acceptor supplies an acceptor name response subtoken.
The PROT_READY service (RFC 2743 §1.2.7) is never available with this mechanism. Implementations MUST NOT offer this flag or permit per-message security services before context establishment is complete.
Per-message tokens use RFC 4121 Section 4 token formats, with the CRK treated as both the initiator sub-session key and the acceptor sub-session key (and ticket session key). GSS_Pseudo_random uses the PRF defined in RFC 4402.
The Context Root Key (CRK) is derived from the GMSK (itself produced by RFC 3961 random-to-key over the first L bytes of the EAP MSK) using iterated pseudorandom calls: Tn = pseudorandom(GMSK, n || "rfc4121-gss-eap"); CRK = random-to-key(truncate(L, T0||T1||…||Tn)). If the MSK is too short, authentication MUST fail.
The GSS-EAP mechanism name has an ABNF string form of 'user-or-service [ "/" host [ "/" service-specifics ] ] [ "@" realm ]', where special characters '/', '@', and '\' may be backslash-escaped. This form is compatible with RFC 1964 Kerberos name strings.
The mechanism OID root is 1.3.6.1.5.5.15.1.1; a Kerberos RFC 3961 encryption type number is appended to form a specific mechanism OID. The document defines EAP-AES128 using aes128-cts-hmac-sha1-96 (enctype 17), with OID 1.3.6.1.5.5.15.1.1.17.
A 'GSS-EAP Error Codes' subregistry (unsigned 32-bit values) was created: values ≤127 require Standards Action, 128–255 require Specification Required, >255 are reserved. Initial codes include 1–16 covering buffer errors, OID mismatches, token corruption, missing subtokens, EAP key derivation failures, and AAA failures.
A new 'GSS-EAP Parameters' top-level registry was created, containing a 'GSS-EAP Subtoken Types' subregistry. The upper bit (0x80000000) is the critical flag and is not included in registrations. Assignment policy is Expert Review requiring a public specification.
Four RADIUS attribute type values were assigned: GSS-Acceptor-Service-Name (164), GSS-Acceptor-Host-Name (165), GSS-Acceptor-Service-Specifics (166), and GSS-Acceptor-Realm-Name (167), carrying the corresponding components of the GSS-EAP acceptor name.
IANA created the 'Object Identifiers for Application Bridging for Federated Access' registry under arc 1.3.6.1.5.5.15, with sub-arcs for mechanisms (1.3.6.1.5.5.15.1) and nametypes (1.3.6.1.5.5.15.2). Registration policy is IETF Review or IESG Approval.
SASL mechanisms EAP-AES128 and EAP-AES128-PLUS were registered (via GS2/RFC 5801). EAP-AES128 uses the GSS-EAP mechanism with aes128-cts-hmac-sha1-96 (OID 1.3.6.1.5.5.15.1.1.17); the PLUS variant provides GSS channel bindings.
The 'Kerberos GSS-API Token Type Identifiers' subregistry was updated to include 0x0601 (GSS-EAP initiator context token) and 0x0602 (GSS-EAP acceptor context token). Allocation policy is Expert Review.
Every proxy in the AAA chain from the authenticator to the EAP server must be trusted to verify channel bindings and protect key material integrity. RADIUS provides only weak MD5-based hop-by-hop confidentiality; RADIUS over TLS (RFC 6614) or Diameter with TLS/IPsec provides significantly better protection of key material in transit.
If EAP channel binding is not used, the system is vulnerable to phishing attacks where users are diverted to a different service. For deployments where AAA membership is broad, EAP channel binding is critical; implementations are therefore required to implement and use it. Without mutual authentication via channel binding, an attacker can only divert users between servers within the same AAA infrastructure.
Multi-layer security negotiation (GSS-API outer, EAP method inner) introduces bid-down attack risk. Mitigations include constructing policy so that inner-layer mechanism preferences fall between two outer-layer preferences, or restricting use of this mechanism only to services where it has been explicitly selected.
GSS-EAP context establishment proceeds through three states: Initial (exchange of vendor/acceptor-name tokens and first EAP identity request), Authenticate (EAP request/response exchange until Success or Failure), and Extensions (MIC-protected negotiation of optional features and GSS channel bindings). Both initiator and acceptor begin in Initial state.
All GSS-EAP context tokens carry an RFC 2743 [APPLICATION 0] IMPLICIT SEQUENCE wrapper. The innerToken begins with a 2-octet network-byte-order token type ID (0x0601 initiator→acceptor, 0x0602 acceptor→initiator), followed by TLV subtokens each consisting of a 4-octet type, 4-octet body length, and the body.
The EAP Request subtoken (type 0x80000005, always critical, REQUIRED in Authenticate state) and EAP Response subtoken (type 0x80000004, always critical, REQUIRED in Authenticate state) each carry a raw EAP message in their body.
The Error subtoken (type 0x80000001, always critical) encodes a 4-octet RFC 2744 major status followed by a 4-octet GSS-EAP error code, both in network byte order. Initiators MUST ignore octets beyond the error code for extensibility.
The Flags subtoken (type 0x0000000C) carries a 4-octet network-byte-order integer. The only defined flag is GSS_C_MUTUAL_FLAG (0x2). Acceptors MUST ignore flag octets beyond 4 and MUST ignore undefined flag bits; initiators MUST send undefined bits as zero.
The GSS Channel Bindings subtoken (type 0x80000006, always critical when present) carries an RFC 3961 get_mic token over the application data from the GSS channel bindings structure, using the CRK with key usage 60 (KEY_USAGE_GSSEAP_CHBIND_MIC). Only application data is sent; initiator/acceptor addresses are ignored.
The MIC subtoken is type 0x8000000D for the initiator and 0x8000000E for the acceptor. Its body is an RFC 3961 get_mic result computed over the DER-encoded mechanism OID, the 16-bit token type, and the concatenated type/length/value of all preceding subtokens. Key usages are 61 (acceptor→initiator) and 62 (initiator→acceptor).