in Index   Prev   Next

RFC 7055

A GSS-API Mechanism for the Extensible Authentication Protocol

Pages: 35
Proposed Standard
Part 1 of 2 – Pages 1 to 18
None   None   Next

Top   ToC   RFC7055 - Page 1
Internet Engineering Task Force (IETF)                   S. Hartman, Ed.
Request for Comments: 7055                             Painless Security
Category: Standards Track                                     J. Howlett
ISSN: 2070-1721                                                JANET(UK)
                                                           December 2013

     A GSS-API Mechanism for the Extensible Authentication Protocol


This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at 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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Top   ToC   RFC7055 - Page 2

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 ............................33
Top   ToC   RFC7055 - Page 3

1. Introduction

The Application Bridging for Federated Access Beyond Web (ABFAB) document [ABFAB-ARCH] describes an architecture for providing federated access management to applications using the Generic Security Service Application Programming Interface (GSS-API) [RFC2743] and Simple Authentication and Security Layer (SASL) [RFC4422]. This specification provides the core mechanism for bringing federated authentication to these applications. The Extensible Authentication Protocol (EAP) [RFC3748] defines a framework for authenticating a network access client and server in order to gain access to a network. A variety of different EAP methods are in wide use; one of EAP's strengths is that for most types of credentials in common use, there is an EAP method that permits the credential to be used. EAP is often used in conjunction with a backend Authentication, Authorization and Accounting (AAA) server via RADIUS [RFC3579] or Diameter [RFC4072]. In this mode, the Network Access Server (NAS) simply tunnels EAP packets over the backend authentication protocol to a home EAP/AAA server for the client. After EAP succeeds, the backend authentication protocol is used to communicate key material to the NAS. In this mode, the NAS need not be aware of or have any specific support for the EAP method used between the client and the home EAP server. The client and EAP server share a credential that depends on the EAP method; the NAS and AAA server share a credential based on the backend authentication protocol in use. The backend authentication server acts as a trusted third party, enabling network access even though the client and NAS may not actually share any common authentication methods. As described in the architecture document [ABFAB-ARCH], using AAA proxies, this mode can be extended beyond one organization to provide federated authentication for network access. The GSS-API provides a generic framework for applications to use security services including authentication and per-message data security. Between protocols that support GSS-API directly or protocols that support SASL [RFC4422], many application protocols can use GSS-API for security services. However, with the exception of Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the Internet. While GSS-API permits an application to be written independent of the specific GSS-API mechanism in use, there is no facility to separate the server from the implementation of the mechanism as there is with EAP and backend authentication servers.
Top   ToC   RFC7055 - Page 4
   The goal of this specification is to combine GSS-API's support for
   application protocols with EAP/AAA's support for common credential
   types and for authenticating to a server without requiring that
   server to specifically support the authentication method in use.  In
   addition, this specification supports the architectural goal of
   transporting attributes about subjects to relying parties.  Together
   this combination will provide federated authentication and
   authorization for GSS-API applications.  This specification meets the
   applicability requirements for EAP to application authentication

   This mechanism is a GSS-API mechanism that encapsulates an EAP
   conversation.  From the perspective of RFC 3748, this specification
   defines a new lower-layer protocol for EAP.  From the perspective of
   the application, this specification defines a new GSS-API mechanism.

   Section 1.3 of [RFC5247] outlines the typical conversation between
   EAP peers where an EAP key is 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

GSS-API peers discover each other and discover support for GSS-API in an application-dependent mechanism. SASL [RFC4422] describes how discovery of a particular SASL mechanism such as a GSS-API EAP mechanism is conducted. The Simple and Protected Negotiation mechanism (SPNEGO) [RFC4178] provides another approach for discovering what GSS-API mechanisms are available. The specific approach used for discovery is out of scope for this mechanism.

1.2. Authentication

GSS-API authenticates a party called the "GSS-API initiator" to the GSS-API acceptor, optionally providing authentication of the acceptor to the initiator. Authentication starts with a mechanism-specific message called a "context token" sent from the initiator to the acceptor. The acceptor responds, followed by the initiator, and so on until authentication succeeds or fails. GSS-API context tokens are reliably delivered by the application using GSS-API. The application is responsible for in-order delivery and retransmission.
Top   ToC   RFC7055 - Page 5
   EAP authenticates a party called a "peer" to a party called the "EAP
   server".  A third party called an "EAP pass-through authenticator"
   may decapsulate EAP messages from a lower layer and re-encapsulate
   them into a AAA protocol.  The term EAP authenticator refers to
   whichever of the pass-through authenticator or EAP server receives
   the lower-layer EAP packets.  The first EAP message travels from the
   authenticator to the peer; a GSS-API message is sent from the
   initiator to acceptor to prompt the authenticator to send the first
   EAP message.  The EAP peer maps onto the GSS-API initiator.  The role
   of the GSS-API acceptor is split between the EAP authenticator and
   the EAP server.  When these two entities are combined, the division
   resembles GSS-API acceptors in other mechanisms.  When a more typical
   deployment is used and there is a pass-through authenticator, most
   context establishment takes place on the EAP server and per-message
   operations take place on the authenticator.  EAP messages from the
   peer to the authenticator are called responses; messages from the
   authenticator to the peer are called requests.

   Because GSS-API applications provide guaranteed delivery of context
   tokens, the EAP retransmission timeout MUST be infinite and the EAP
   layer MUST NOT retransmit a message.

   This specification permits a GSS-API acceptor to 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.  In this case, the GSS-API acceptor
   acts as an EAP pass-through authenticator.  The pass-through
   authenticator is responsible for retransmitting AAA messages if a
   response is not received from the AAA server.  If a response cannot
   be received, then the authenticator generates an error at the GSS-API
   level.  If EAP authentication is successful, and where the chosen EAP
   method supports key derivation, EAP keying material may also be
   derived.  If a AAA protocol is used, this 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.
Top   ToC   RFC7055 - Page 6

1.3. Secure Association Protocol

After authentication succeeds, GSS-API provides a number of per- message security services that can be used: 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 perform a function similar to secure association protocols in network access. Like secure association protocols, these services need to be performed near the authenticator/acceptor even when a 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 authenticator derive this key as a result of a successful EAP authentication. In the case that the EAP authenticator is acting as a pass-through, it obtains it via the AAA protocol. 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

EAP authenticates a user to a realm. The peer knows that it has exchanged authentication with an EAP server in a given realm. Today, the peer does not typically know which NAS it is talking to securely. That is often fine for network access. However, privileges to delegate to a chat server seem very different than privileges for a file server or trading site. Also, an EAP peer knows the identity of the home realm, but perhaps not even the visited realm. In contrast, GSS-API takes a name for both the initiator and acceptor as inputs to the authentication process. When mutual authentication is used, both parties are authenticated. The granularity of these names is somewhat mechanism dependent. In the case of the Kerberos mechanism, the acceptor name typically identifies both the protocol in use (such as IMAP) and the specific instance of the service being connected to. The acceptor name almost always identifies the administrative domain providing service.
Top   ToC   RFC7055 - Page 7
   A GSS-API EAP mechanism needs to provide GSS-API naming semantics in
   order to work with existing GSS-API applications.  EAP channel
   binding [RFC6677] is used to provide GSS-API 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.  In addition, attributes are sent in the
   backend authentication protocol from the authenticator to the EAP
   server.  The EAP server confirms the consistency of these attributes.
   Confirming attribute consistency also involves checking consistency
   against a local policy database as discussed in Section 3.5.  In
   particular, the peer sends the name of the acceptor it is
   authenticating to as part of channel binding.  The acceptor sends its
   full name as part of the backend authentication protocol.  The EAP
   server confirms consistency of the names.

   EAP channel binding is easily confused with a facility in GSS-API
   also called "channel binding".  GSS-API channel binding provides
   protection against man-in-the-middle attacks when GSS-API is used as
   authentication inside some tunnel; it is similar to a facility called
   "cryptographic binding" in EAP.  See [RFC5056] for a discussion of
   the differences between these two facilities and Section 6.1 for how
   GSS-API channel binding is handled in this mechanism.

3.1. Mechanism Name Format

Before discussing how the initiator and acceptor names are validated in the AAA infrastructure, it is necessary to discuss what composes a name for an EAP GSS-API mechanism. GSS-API permits several types of generic names to be imported using GSS_Import_name(). Once a mechanism is chosen, these names are converted into a mechanism- specific name called a "Mechanism Name". Note that a Mechanism Name is the name of an initiator or acceptor, not of a GSS-API mechanism. This section first discusses the mechanism name form and then discusses what name forms are supported.
Top   ToC   RFC7055 - Page 8
   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 appearing in a name can be backslash escaped to
   avoid their special meanings.  For example, "\\" represents a literal
   backslash.  This escaping mechanism is a property of the string
   representation; if the components of a name are transported in some
   mechanism that will keep them separate without backslash escaping,
   then backslash SHOULD have no special meaning.

   The user-or-service component is similar to the portion of a network
   access identifier (NAI) before the '@' symbol for initiator names and
   the service name from the registry of GSS-API host-based services in
   the case of acceptor names [GSS-IANA].  The NAI specification
   provides rules for encoding and string preparation in order to
   support internationalization of NAIs; implementations of this
   mechanism MUST NOT prepare the user-or-service according to these
   rules; see Section 3.2 for internationalization of this mechanism.
   The host portion is empty for initiators and typically contains the
   domain name of the system on which an acceptor service is running.
   Some services MAY require additional parameters to distinguish the
   entity being authenticated against.  Such parameters are encoded in
   the service-specifics portion of the name.  The EAP server MUST
   reject authentication of any acceptor name that has a non-empty
   service-specifics component unless the EAP server understands the
   service-specifics and authenticates them.  The interpretation of the
   service-specifics is scoped by the user-or-service portion.  The
   realm is similar to the realm portion of a NAI for initiator names;
   again the NAI specification's internationalization rules MUST NOT be
   applied to the realm.  The realm is the administrative realm of a
   service for an acceptor name.

   The string representation of this name form is designed to be
   generally compatible with the string representation of Kerberos names
   defined in [RFC1964].
Top   ToC   RFC7055 - Page 9
   The GSS_C_NT_USER_NAME form represents the name of an individual
   user.  From the standpoint of this mechanism, it may take the form of
   either an undecorated user name or a name semantically similar to a
   network access identifier (NAI) [RFC4282].  The name is split at the
   first at-sign ('@') into the part preceding the realm, which is the
   user-or-service portion of the mechanism name, and the realm portion,
   which is the realm portion of the mechanism name.

   The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
   on a host; it is textually represented as "service@host".  This name
   form is required by most SASL profiles and is used by many existing
   applications that use the Kerberos GSS-API mechanism.  While support
   for this name form is critical, it presents an interesting challenge
   in terms of EAP channel binding.  Consider a case where the server
   communicates with a "server proxy," or a AAA server near the server.
   That server proxy communicates with 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.  However, the EAP server cannot make this
   determination directly.  So, the EAP server needs to determine
   whether to trust the server proxy to verify the host portion of the
   acceptor name.  This trust decision depends both on the host name and
   the realm of the server proxy.  In effect, the EAP server decides
   whether to trust that the realm of the server proxy is the right
   realm for the given hostname and then makes a trust decision about
   the server proxy itself.  The same problem appears in Kerberos:
   there, clients decide what Kerberos realm to trust for a given
   hostname.  The service portion of this name is imported into the
   user-or-service portion of the mechanism name; the host portion is
   imported into the host portion of the mechanism name.  The realm
   portion is empty.  However, authentication will typically fail unless
   some AAA component indicates the realm to the EAP server.  If the
   application server knows its realm, then 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 this
   case, the name form is "service" with no host component.  This is
   imported with the service as user-or-service and an empty host and
   realm portion.  This form is useful when a service is unsure which
   name an initiator knows it by.

   If the null name type or the GSS_EAP_NT_EAP_NAME (OID (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 many circumstances, Kerberos
   GSS-API mechanism names will behave as expected when used with the
   GSS-API EAP mechanism, but there are some differences that may cause
Top   ToC   RFC7055 - Page 10
   some confusion.  If an implementation does support importing Kerberos
   names it SHOULD fail the import if the Kerberos name is not
   syntactically a valid GSS-API EAP mechanism name as defined in this

3.2. Internationalization of Names

For the most part, GSS-EAP names are transported in other protocols; those protocols define the internationalization semantics. For example, if a AAA server wishes to communicate the user-or-service portion of the initiator name to an acceptor, it does so using existing mechanisms in the AAA protocol. Existing internationalization rules are applied. Similarly, within an application, existing specifications such as [RFC5178] define the encoding of names that are imported and displayed with the GSS-API. This mechanism does introduce a few cases where name components are sent. In these cases, the encoding of the string is UTF-8. Senders SHOULD NOT normalize or map strings before sending. These strings include RADIUS attributes introduced in Section 3.4. When comparing the host portion of a GSS-EAP acceptor name supplied in EAP channel binding by a peer to that supplied by an acceptor, EAP servers SHOULD prepare the host portion according to [RFC5891] prior to comparison. Applications MAY prepare domain names prior to importing them into this mechanism.

3.3. Exported Mechanism Names

GSS-API provides the GSS_Export_name call. This call can be used to export the binary representation of a name. This name 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 portion of this name token is the string format of the mechanism name described in Section 3.1. RFC 2744 [RFC2744] places the requirement that the result of importing a name, canonicalizing it to a Mechanism Name and then exporting it needs to be the same as importing that name, obtaining 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, this requirement is met. However, permitting empty host and realm components when importing host-based services may make it possible for an imported name to
Top   ToC   RFC7055 - Page 11
   differ from the exported name actually used.  Other mechanisms such
   as Kerberos have similar situations where imported and exported names
   may differ.

3.4. Acceptor Name RADIUS AVP

See Section 7.4 for registrations of RADIUS attribute types to carry the acceptor service name. All the attribute types registered in that section are strings. See Section 3.1 for details of the values in a name. If RADIUS is used as a AAA transport, the acceptor MUST send the acceptor name in these attribute types. That is, the acceptor decomposes its name and sends any non-empty portion as a RADIUS attribute. With the exception of the service-specifics portion of the name, the backslash escaping mechanism is not used in RADIUS attributes; backslash has no special meaning. In the service- specifics portion, a literal "/" separates components. In this one attribute, "\/" indicates a slash character that does not separate components and "\\" indicates a literal backslash character. The initiator MUST require that the EAP method in use support channel binding and 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 name elements that the client supplied are in a successful channel binding response. For example, if the client supplied a hostname in channel binding data, the 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

Proxies may play a role in verification of the acceptor identity. For example, a AAA proxy near the acceptor may be in a position to verify the acceptor hostname, while the EAP server is likely to be too distant to reliably verify this on its own. The EAP server or some proxy trusted by the EAP server is likely to be in a position to verify the acceptor realm. In effect, this proxy is confirming that the right AAA credential is used for the claimed realm and thus that the acceptor is in the organization it claims to
Top   ToC   RFC7055 - Page 12
   be part of.  This proxy is also typically trusted by the EAP server
   to make sure that the hostname claimed by the acceptor is a
   reasonable hostname for the realm of the acceptor.

   A proxy close to the EAP server is unlikely to be in a position to
   confirm that the acceptor is claiming the correct hostname.  Instead,
   this is typically delegated to a proxy near the acceptor.  That proxy
   is typically expected to verify the acceptor hostname and to verify
   the appropriate AAA credential for that host is used.  Such a proxy
   may insert the acceptor realm if it is absent, permitting realm
   configuration to be at the proxy boundary rather than on acceptors.

   Ultimately, specific proxy behavior is a matter for 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, such delegation will involve business
   or operational measures such as cross-organizational agreements as
   well as technical measures.

   It is likely that future technical work will be needed to communicate
   what verification has been done by proxies along the path.  Such
   technical measures will not release the EAP server from its
   responsibility to decide whether proxies on the path should be
   trusted to perform checks delegated to them.  However, technical
   measures could prevent misconfigurations and help to support diverse

4. Selection of EAP Method

EAP does not provide a facility for an EAP server to advertise what methods are available to a peer. Instead, a server starts with its preferred method selection. If the peer does not accept that method, the peer sends a NAK response containing the list of methods supported by the client. Providing multiple facilities to negotiate which security mechanism to use is undesirable. Section 7.3 of [RFC4462]describes the problem referencing the Secure Shell (SSH) Protocol key exchange negotiation and the SPNEGO GSS-API mechanism. If a client preferred an EAP method A, a non-EAP authentication mechanism B, and then an EAP
Top   ToC   RFC7055 - Page 13
   method C, then the client would have to commit to using EAP before
   learning whether A is actually supported.  Such a client might end up
   using C when B is available.

   The standard solution to this problem is to perform all the
   negotiation at one layer.  In this case, rather than defining a
   single GSS-API mechanism, a family of mechanisms should be defined.
   Each mechanism corresponds to an EAP method.  The EAP method type
   should be part of the GSS-API OID.  Then, a GSS-API rather than EAP
   facility can be used for negotiation.

   Unfortunately, using a family of mechanisms has a number of problems.
   First, GSS-API assumes that both the initiator and acceptor know the
   entire set of mechanisms that are available.  Some negotiation
   mechanisms are driven by the client; others are driven by the server.
   With EAP GSS-API, the acceptor does not know what methods the EAP
   server implements.  The EAP server that is used depends on the
   identity of the client.  The best solution so far is to accept the
   disadvantages of multi-layer negotiation and commit to using EAP GSS-
   API before a specific EAP method.  This has two main disadvantages.
   First, authentication may fail when other methods might allow
   authentication to succeed.  Second, a non-optimal security mechanism
   may be 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 } END
Top   ToC   RFC7055 - Page 14
   The innerToken field starts with a 16-bit network byte order token
   type identifier.  The remainder of the innerToken field is a set of
   type-length-value subtokens.  The following figure describes 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 Token

   The inner token continues with length, second subtoken body, and so
   forth.  If a subtoken type is present, its length and body MUST be

   The length is a four-octet length of the subtoken body in network
   byte order.  The length does not include the length of the type field
   or the length field; the length only covers the body.

   Tokens from the initiator to acceptor use an inner token type with ID
   06 01; tokens from acceptor to 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 following
   sections discuss how mechanism OIDs are chosen and the state machine
   that defines what 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; a Kerberos encryption type number [RFC3961] is appended to that root OID to form a mechanism OID. As such, a particular encryption type needs to be chosen. By convention, there is a single object identifier arc for the EAP family of GSS-API mechanisms. A specific
Top   ToC   RFC7055 - Page 15
   mechanism is chosen by adding the numeric Kerberos encryption type
   number to the root of this arc.  However, in order to register the
   SASL name, the specific usage with a given encryption type needs to
   be registered.  This document defines the EAP-AES128 GSS-API

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 that of the mechanism being used. The receiver confirms that the token type corresponds to the role of the peer: acceptors will only process initiator tokens and initiators will 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. Associated with each state are a set of subtoken types that are processed in that state and rules for processing these subtoken types. The receiver examines the subtokens in order, processing any that are appropriate for the current state. Unknown subtokens or subtokens that are not 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.
Top   ToC   RFC7055 - Page 16

5.3. Error Subtokens

The acceptor may 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 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 authenticate state.
Top   ToC   RFC7055 - Page 17

5.4.1. Vendor Subtoken

The vendor ID subtoken has type 0x0000000B and the following structure: +-------------+------------------------+ | Pos | Description | +-------------+------------------------+ | 0..3 | 0x0000000B | | | | | 4..7 | length of vendor token | | | | | 8..8+length | Vendor ID string | +-------------+------------------------+ The vendor ID string is an UTF-8 string describing the vendor of this implementation. This string is unstructured and for debugging purposes only.

5.4.2. Acceptor Name Request

The acceptor name request token is sent from the initiator to the acceptor indicating that the initiator wishes a particular acceptor name. This is similar to Transport Layer Security (TLS) Server Name Indication [RFC6066] that permits a client to indicate which one of a number of virtual services to contact. The structure is as follows: +------+------------------------------+ | Pos | Description | +------+------------------------------+ | 0..3 | 0x00000002 | | | | | 4..7 | length of subtoken | | | | | 8..n | string form of acceptor name | +------+------------------------------+ It is likely that channel binding and thus authentication will fail if the acceptor does not choose a name that is a superset of this name. That is, if a hostname is sent, the acceptor needs to be willing to accept this hostname.
Top   ToC   RFC7055 - Page 18

5.4.3. Acceptor Name Response

The acceptor name response subtoken indicates what acceptor name is used. This is useful, for example, if the initiator supplied no target name to the context initialization. This allows the initiator to learn the acceptor name. EAP channel bindings will provide confirmation that the acceptor is accurately naming itself. This token is sent from the acceptor to initiator. In the Initial state, this token would typically be sent if the acceptor name request is absent, because if the initiator already sent an acceptor name, then the initiator knows what acceptor it wishes to contact. This subtoken is also sent in Extensions state Section 5.6, so the initiator can protect against a man-in-the-middle modifying the acceptor name request subtoken. +------+------------------------------+ | Pos | Description | +------+------------------------------+ | 0..3 | 0x00000003 | | | | | 4..7 | length of subtoken | | | | | 8..n | string form of acceptor name | +------+------------------------------+

(page 18 continued on part 2)

Next Section