One document matched: draft-ietf-abfab-gss-eap-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY CHBIND PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-emu-chbind.xml'>
<!ENTITY RFC1964 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY RFC3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY RFC3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY RFC3961 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
<!ENTITY RFC4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY RFC4121 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml'>
<!ENTITY RFC4282 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml'>
<!ENTITY RFC4401 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4401.xml'>
<!ENTITY RFC4402 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4402.xml'>
<!ENTITY RFC4422 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
<!ENTITY RFC4462 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4462.xml'>
<!ENTITY RFC5056 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY RFC5178 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5178.xml'>
<!ENTITY RFC5247 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml'>
<!ENTITY RFC5554 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5554.xml'>
<!ENTITY RFC4178 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-ietf-abfab-gss-eap-08.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="EAP GSS-API">A GSS-API Mechanism for the Extensible Authentication Protocol</title>
<author initials="S." surname="Hartman" fullname="Sam Hartman" role="editor">
<organization>Painless Security</organization>
<address>
<email>hartmans-ietf@mit.edu</email>
</address>
</author> <author initials="J." surname="Howlett" fullname="Josh Howlett">
<organization>JANET</organization>
<address>
<email>josh.howlett@ja.net</email>
</address>
</author>
<date/>
<abstract>
<t>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 EAP mechanism.
Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol.</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>The ABFAB architecture <xref target="I-D.ietf-abfab-arch"/> describes an architecture for providing federated access management to applications using the Generic Security Services Application Programming Interface (GSS-API) <xref target="RFC2743"/> and Simple Authentication and Security Layers (SASL) <xref target="RFC4422"/>. This specification provides the core mechanism for bringing federated authentication to these applications.</t>
<t>The Extensible Authentication Protocol (EAP) <xref
target="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.</t>
<t>EAP is often used in conjunction with a backend
authentication server via RADIUS <xref target="RFC3579"/> or
Diameter <xref target="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, using AAA
proxies, this mode can be extended beyond one organization to
provide federated authentication for network access. </t>
<t>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 <xref target="RFC4422"/>, many application
protocols can use GSS-API for security services. However, with
the exception of Kerberos <xref target="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. </t>
<t>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.</t>
<t>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 prospective of the application, this specification defines a new GSS-API mechanism.</t>
<t>Section 1.3 of <xref target="RFC5247"></xref> outlines the typical conversation
between EAP peers where an EAP key is derived:<list style="symbols">
<t>Phase 0: Discovery</t>
<t> Phase 1: Authentication</t>
<t> 1a: EAP authentication</t>
<t> 1b: AAA Key Transport (optional)</t>
<t> Phase 2: Secure Association Protocol</t>
<t> 2a: Unicast Secure Association</t>
<t> 2b: Multicast Secure Association (optional)</t>
</list>
</t>
<section title="Discovery">
<t>GSS-API peers discover each other and discover support for
GSS-API in an application-dependent mechanism. SASL <xref
target="RFC4422"/> describes how discovery of a particular
SASL mechanism such as a GSS-API mechanism is conducted.
The Simple and Protected Negotiation mechanism (SPNEGO) <xref
target="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.</t>
</section>
<section title="Authentication">
<t>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. </t>
<t>EAP authenticates a party called a peer to a party called
the EAP server. A third party called an EAP passthrough
authenticator may decapsulate EAP messages from a lower layer
and reencapsulate them into an AAA protocol. The term EAP
authenticator refers to whichever of the passthrough
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 passthrough 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. </t>
<t>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.</t>
<t>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, RadSec 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 recieved, 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 an AAA protocol is used, this can also be used to replicate the EAP Key from the EAP server to the EAP authenticator.</t>
<t>See <xref target="CONTEXT"/> for details of the
authentication exchange.</t>
</section>
<section title="Secure Association Protocol">
<t>After authentication succeeds, GSS-API provides a number of
per-message security services that can be used:<list>
<t>GSS_Wrap() provides integrity and optional
confidentiality for a message.</t>
<t>GSS_GetMIC() provides integrity protection for data
sent independently of the GSS-API</t>
<t>GSS_Pseudo_random <xref target="RFC4401"/> provides key
derivation functionality.</t>
</list>
</t>
<t>These services perform a function similar to security
association protocols in network access. Like security
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 <xref
target="ACCEPTOR-SERVICES"/> for details.</t>
</section>
</section>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section anchor="EAP-CB" title="EAP Channel Binding and Naming">
<t> 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. </t>
<t>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. </t>
<t>An EAP GSS-API mechanism needs to provide GSS-API naming
semantics in order to work with existing GSS-API applications.
EAP channel binding <xref target="I-D.ietf-emu-chbind"/> 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 <xref target="PROXY-CB"/>. 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.</t>
<t>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
<xref target="RFC5056"/> for a discussion of the differences
between these two facilities and <xref
target="CHANNEL-BINDING"/> for how GSS-API channel binding is
handled in this mechanism.</t>
<section anchor="NAME-FORM" title="Mechanism Name Format">
<t>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 name form. This section
first discusses the mechanism name form and then discusses
what name forms are supported.</t>
<t>The string representation of the GSS-EAP mechanism name has
the following ABNF <xref target="RFC5234"/> representation:
<figure>
<artwork>
name-char = %x00-39/%x41-46/%x48-FF
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 ]
</artwork>
</figure>
</t>
<t>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 <xref target="GSS-IANA"/>. The NAI specification provides rules for encoding and string preparation in order to support internationalization of NAIs; specifications of this mechanism MUST NOT prepare the user-or-service according to these rules; see <xref target="I18N"/> 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 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.</t>
<t>The string representation of this name form is designed to
be generally compatible with the string representation of
Kerberos names defined in <xref target="RFC1964"/>.</t>
<t>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 either of an undecorated user name or a name semantically similar to a network
access identifier (NAI) <xref target="RFC4282"/>. The name is
split at the first at-sign ('@') into the part proceeding 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.</t>
<t>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.</t>
<t>If the null name type or the GSS_EAP_NT_EAP_NAME (OID
1.3.6.1.5.5.15.2.1) (see <xref
target="IANA.OID"/> ) 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)}.</t>
</section>
<section anchor="I18N" title="Internationalization of Names">
<t>For the most part, GSS-EAP names are transported in other
protocols; those protocols define the internationalization
semantics. For example, if an 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 <xref target="RFC5178"/> define the
encoding of names that are imported and displayed with the
GSS-API.</t>
<t>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
<xref target="RADIUS_AVP"/>. </t>
<t>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 <xref target="RFC5891"/> prior to
comparison. Applications MAY prepare domain names prior to
importing them into this mechanism.</t>
</section>
<section title="Exported Mechanism Names">
<t>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.</t>
<t>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 <xref target="NAME-FORM"/>.</t>
<t>RFC 2744 <xref target="RFC2744"/> places the requirement
that the result of importing a name, canonicalizing it to a
mechanism 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
hostbased services may make it possible for an imported name
to differ from the exported name actually used. Other
mechanisms such as Kerberos have similar situations where
imported and exported names may differ.</t>
</section>
<section anchor="RADIUS_AVP" title="Acceptor Name RADIUS AVP">
<t>See <xref target="IANA.RADIUS"/> for registrations of RADIUS attribute types to carry the acceptor service name. All the attribute types registered in that section are strings. See <xref target="NAME-FORM"/>
for details of the values in a name.</t>
<t>If RADIUS is used as an 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.</t>
<t>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.</t>
<t>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 (<xref target="TOK.ACCEPTOR-NAME-RESPONSE"/>). If a null target name is supplied, the initiator MUST use this response to populate EAP channel bindings. </t>
</section>
<section anchor="PROXY-CB" title="Proxy Verification of Acceptor Name">
<t>Proxies may play a role in verification of the acceptor identity. For example, an 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.</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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 environments.</t>
</section>
</section>
<section anchor="NEGO" title="Selection of EAP Method">
<t>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.</t>
<t> Providing
multiple facilities to negotiate which security mechanism to use is
undesirable. Section 7.3 of <xref target="RFC4462"/>describes the
problem referencing the SSH 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 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. </t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="CONTEXT" title="Context Tokens">
<t>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:
</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>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: </t>
<texttable title="Structure of Inner Token">
<ttcol>Octet Position</ttcol>
<ttcol>Description</ttcol>
<c>0..1</c>
<c>token ID </c>
<c>2..5</c> <c>first subtoken type</c>
<c>6..9</c> <c>length of first subtoken</c>
<c>10..10+n</c> <c>first subtoken body</c>
<c>10+n+1..10+n+4</c> <c>second subtoken type</c>
<postamble>The inner token continues with length, second subtoken body, and so forth. If a subtoken type is present, its length and body must be present.</postamble>
</texttable>
<t>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.</t>
<t>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 <xref target="IANA.RFC4121"/>.</t>
<t>See <xref target="EXAMPLETOKEN"/> 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.</t>
<section anchor="ENCTYPES" title="Mechanisms and Encryption Types">
<t>This mechanism family uses the security services of the
Kerberos cryptographic framework <xref target="RFC3961"/>. The root of the OID ARC for mechanisms described in this document is 1.3.6.1.5.5.15.1.1; a Kerberos encryption type number <xref target="RFC3961"></xref>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 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 mechanism. </t>
</section>
<section title="Processing received tokens">
<t>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.</t>
<t>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 <xref target="STATE.INITIAL"/> 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 reciever 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.</t>
<t>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.</t>
<t>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.</t>
<t>The subtoken type MUST be unique within a given token.</t>
</section>
<section anchor="SUB.ERROR" title="Error Subtokens">
<t>The acceptor may always end the exchange by generating an error subtoken. The error subtoken has the following format:</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x80 00 00 01</c>
<c>4..7</c> <c>length of error token</c>
<c>8..11</c> <c>major status from RFC 2744 as 32-bit network byte order</c>
<c>12..15</c> <c>GSS EAP error code as 32-bit network byte order; see <xref target="ERRORS"></xref></c>
</texttable>
<t>Initiators MUST ignore octets beyond the GSS EAP error code for future extensibility. As indicated, the error token is always marked critical.</t>
</section>
<section anchor="STATE.INITIAL" title="Initial State">
<t>Both the acceptor and initiator start the context establishment process in the initial state.</t>
<t>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.</t>
<t>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 <xref target="SUB.EAP-REQUEST"/> for the format of this subtoken).</t>
<t>The initiator and acceptor then transition to authenticate state.
</t>
<section anchor="SUB.VENDOR" title="Vendor Subtoken">
<t>The vendor ID token has type 0x0000000B and the following structure:
</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x0000000B</c>
<c>4..7</c> <c>length of vendor token</c>
<c>8..8+length</c> <c>Vendor ID string</c>
</texttable>
<t>The vendor ID string is an UTF-8 string describing the vendor of this implementation. This string is unstructured and for debugging purposes only.</t>
</section>
<section title="Acceptor Name Request" anchor="SUB.ACCEPTOR-NAME">
<t>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 TLS Server Name Indication <xref target="RFC6066"/> which permits a client to indicate which one of a number of virtual services to contact. The structure is as follows:
</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x00000002</c>
<c>4..7</c> <c>Length of subtoken</c>
<c>8..n</c>
<c>string form of acceptor name</c>
</texttable>
<t>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 hosntame.</t>
</section>
<section anchor="TOK.ACCEPTOR-NAME-RESPONSE" title="Acceptor Name Response">
<t>The acceptor name response subtoken indicates what acceptor name is used. This is useful for example if the initiator supplied no target name to context initialization. This allows the initiator to learn the acceptor name. EAP channel bindings will provide confirmation that the acceptor is accurately naming itself.
</t>
<t>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 <xref target="STATE.EXTENSION"/> so the initiator can protect against a man-in-the-middle modifying the acceptor name request subtoken.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x00000003</c>
<c>4..7</c> <c>Length of subtoken</c>
<c>8..n</c>
<c>string form of acceptor name</c>
</texttable>
</section>
</section>
<section anchor="" title="Authenticate State">
<t>In this state, the acceptor sends EAP requests to the initiator and the initiator generates EAP responses. The goal of the state is to perform a successful EAP authentication. Since the acceptor sends an identity request at the end of the initial state, the first half-round-trip in this state is a response to that request from the initiator.</t>
<t>The EAP conversation can end in a number of ways:
<list style="symbols">
<t>If the EAP state machine generates an EAP success
message, then the EAP authenticator believes the authentication is
successful. The Acceptor MUST confirm that a key has been
derived (Section 7.10 of <xref target="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 succeed the acceptor sends the success
message using the EAP Request subtoken type and
transitions to Extensions state. If the initiator
receives 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 so, it
transitions to Extensions state. Otherwise, it returns an
error to the caller of GSS_Init_Sec_context without
producing an output token.</t>
<t>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.</t>
<t>If there is some other error, the acceptor MAY return an error subtoken.</t>
</list>
</t>
<section title="EAP Request Subtoken" anchor="SUB.EAP-REQUEST">
<t>The EAP Request subtoken is sent from the acceptor to the initiator. This subtoken is always critical and is required in the authentication state.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x8000005</c>
<c>4..7</c> <c>Length of EAP message</c>
<c>8..8+length</c> <c>EAP message</c>
</texttable>
</section>
<section title="EAP Response Subtoken" anchor="SUB.EAP-RESPONSE">
<t>This subtoken is required in authentication state messages from the initiator to the acceptor. It is always critical.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x8000004</c>
<c>4..7</c> <c>Length of EAP message</c>
<c>8..8+length</c> <c>EAP message</c>
</texttable>
</section>
</section>
<section anchor="STATE.EXTENSION" title="Extension State">
<t>After EAP success, the initiator sends a token to the
acceptor including additional subtokens that negotiate
optional features or provide GSS-API channel binding (see
<xref target="CHANNEL-BINDING"/>). The acceptor then responds
with a token to the initiator. When the acceptor produces its
final token it returns GSS_S_COMPLETE; when the initiator
consumes this token it returns GSS_S_COMPLETE if no errors are
detected.</t>
<t>The acceptor SHOULD send an acceptor name response (<xref
target="TOK.ACCEPTOR-NAME-RESPONSE"/>) so that the initiator
can get a copy of the acceptor name protected by the MIC subtoken.</t>
<t>Both the initiator and acceptor MUST include and verify a MIC subtoken to protect the extensions exchange.
</t>
<section anchor="TOK.FLAGS" title="Flags Subtoken">
<t>This token is sent to convey initiator flags to the
acceptor. The flags are sent as a 32-bit integer in network
byte order. The only flag defined so far is
GSS_C_MUTUAL_FLAG, indicating that the initiator successfully
performed mutual authentication of the acceptor. This flag is communicated to the acceptor because some protocols <xref target="RFC4462"/> require the acceptor to know whether the initiator has confirmed its identity. This flag has the value 0x2
to be consistent with RFC 2744.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x0000000C</c>
<c>4..7</c>
<c>length of flags token</c>
<c>8..11</c>
<c>flags</c>
</texttable>
<t>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.</t>
</section>
<section title="GSS Channel Bindings Subtoken" anchor="SUB.GSS-CB">
<t>This token is always critical when sent. It is sent from the initiator to the acceptor. The contents of this token are an RFC 3961 get_mic token of the application data from the GSS channel bindings structure passed into the context establishment call.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c>
<c>0x80000006</c>
<c>4..7</c> <c>length of token</c>
<c>8..8+length</c>
<c>get_mic of channel binding application data</c>
</texttable>
<t>Again, only the application data is sent in the channel
binding. Any initiator and acceptor addresses passed by an
application into context establishment calls are ignored and
not sent 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.</t>
<t>The initiator MUST send this token if channel bindings including application data are passed into GSS_Init_Sec_context and MUST NOT send this token otherwise.</t>
</section>
<section title="MIC Subtoken" anchor="SUB.MIC">
<t>This token MUST be the last subtoken in the tokens sent in Extensions state. This token is sent both by the initiator and acceptor.</t>
<texttable>
<ttcol>Pos</ttcol>
<ttcol>Description</ttcol>
<c>0..3</c> <c>0x8000000D for initiator 0x8000000E for acceptor</c>
<c>4..7</c>
<c>Length of RFC 3961 MIC token</c>
<c>8..8+length</c> <c>RFC 3961 result of get_mic</c>
</texttable>
<t>As with any call to get_mic, a token is produced as
described in RFC 3961 using the CRK <xref
target="ACCEPTOR-SERVICES"/> 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 from the
acceptor to the initiator and 62
(KEY_USAGE_GSSEAP_INITTOKEN_MIC) for the subtoken from the
initiator to the acceptor. The input is as follows:
<list style="numbers">
<t>The DER-encoded object identifier of the mechanism in use; this value starts with 0x06 (the tag for object identifier). When encoded in an RFC 2743 context token, the object identifier is preceeded by the tag and length for [Application 0] SEQUENCE. This tag and the length of the overall token is not included; only the tag, length and value of the object identifier itself.</t>
<t>A 16-bit token type in network byte order of the RFC 4121 token identifier (0x0601 for initiator, 0x0602 for acceptor).</t>
<t>For each subtoken other than the MIC subtoken itself in the order the subtokens appear in the token:<list style="numbers">
<t>A four octet subtoken type in network byte order</t>
<t>A four byte length in network byte order </t>
<t>Length octets of value from that subtoken</t>
</list>
</t>
</list>
</t>
<t></t>
</section>
</section>
<section anchor="EXAMPLETOKEN" title="Example Token">
<figure title="Example Initiator Token">
<artwork><![CDATA[
+----+------+----+------+-----+-------------------------+
| 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" |
+-------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="Context Options">
<t>GSS-API provides a number of optional per-context services
requested by flags on the call to GSS_Init_sec_context and
indicated as outputs from both GSS_Init_sec_context and
GSS_Accept_sec_context. This section describes how these
services are handled. Which services the client selects in the
call to GSS_Init_sec_context controls what EAP methods MAY be
used by the client. Section 7.2 of RFC 3748 describes a set of
security claims for EAP. As described below, the selected GSS
options place requirements on security claims that MUST be
met. </t>
<t>This GSS mechanism MUST only be used with EAP methods that
provide dictionary attack resistance. Typically dictionary attack resistance is obtained by using an EAP tunnel method to tunnel an inner method in TLS.</t>
<t>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 regardless of which services are requested.</t>
<t>The PROT_READY service defined in Section 1.2.7 of <xref target="RFC2743"/> is never available with this
mechanism. Implementations MUST NOT offer this flag or permit
per-message security services to be used before context
establishment.</t>
<t>The EAP method
MUST support mutual authentication and channel binding. See
<xref target="RADIUS_AVP"/> for details on what is required
for successful mutual authentication. Regardless of whether 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 <xref target="RADIUS_AVP"/>, the initiator MUST send a flags subtoken <xref target="TOK.FLAGS"/> in Extensions state.</t>
</section>
</section>
<section anchor="ACCEPTOR-SERVICES" title="Acceptor Services">
<t>The context establishment process may be passed through to a
EAP server via a backend authentication protocol. However after
the EAP authentication succeeds, security services are provided
directly by the acceptor. </t>
<t>This mechanism uses an RFC 3961 cryptographic key called the
context root key (CRK). The CRK is derived from the GMSK
(GSS-API MSK). The GMSK is the result of the
random-to-key <xref target="RFC3961"/> operation of the encryption type of this mechanism consuming the appropriate number of bits
from the EAP master session key. For example for
aes128-cts-hmac-sha1-96, the random-to-key operation consumes 16
octets of key material; thus the first 16 bytes of the master
session key are input to random-to-key to form the GMSK.</t>
<t>In the following, pseudo-random is the RFC 3961 pseudo-random operation for the encryption type of the GMSK. The truncate function takes the initial l bits of its input. The goal in constructing a CRK is to call the pseudo-random function enough times to produce the right number of bits of output and discard any excess bits of output.</t>
<t>The CRK is derived from the GMSK using the following
procedure<figure>
<artwork>
Tn = pseudo-random(GMSK, n || "rfc4121-gss-eap")
CRK = truncate(L, T0 || T1 || .. || Tn)
L = output RFC 3961 key size
</artwork>
</figure>
</t>
<t>Where n is a 32-bit integer in network byte order starting at 0 and incremented to each call to the pseudo_random operation.</t>
<section anchor="CHANNEL-BINDING" title="GSS-API Channel
Binding">
<t>GSS-API channel binding <xref target="RFC5554"/> is a
protected facility for exchanging a cryptographic name for an
enclosing channel between the initiator and acceptor. The
initiator sends channel binding data and the acceptor confirms
that channel binding data has been checked.</t>
<t>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 <xref target="RFC4559"/>
depend on this behavior of some Kerberos implementations. </t>
<t>As discussed, the GSS channel bindings subtoken is sent in the extensions state.</t>
</section>
<section title="Per-message security">
<t>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.</t>
</section>
<section title="Pseudo Random Function">
<t>The pseudo random function defined in <xref
target="RFC4402"/> is used to provide GSS_Pseudo_Random functionality to applications.</t>
</section>
</section>
<section title="Iana Considerations">
<t>This specification creates a number of IANA registries.</t>
<section anchor="IANA.OID" title="OID Registry">
<t>IANA is requested to create 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. Early allocation is permitted. IANA is requested to update the reference for the root of this OID delegation to point to the newly created registry.</t>
<figure>
<artwork><![CDATA[
Prefix: iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15)
Decimal Name Description References
------- ---- ------------------------------------ ----------
0 Reserved Reserved
1 mechanisms A sub-arc containing ABFAB mechanisms
2 nametypes A sub-arc containing ABFAB GSS-API Name Types
]]></artwork>
</figure>
<t>NOTE: the following mechanisms registry are the root of the OID for the mechanism in question. As discussed in <xref target="ENCTYPES"/> [draft-ietf-abbfab-gss-eap], a Kerberos encryption type number <xref target="RFC3961"/> is appended to the mechanism version OID below to form the OID of a specific mechanism.</t>
<figure>
<artwork><![CDATA[
Prefix: iso.org.dod.internet.security.mechanisms.abfab.mechanisms
(1.3.6.1.5.5.15.1)
Decimal Name Description References
------- ---- ------------------------------------ ----------
0 Reserved Reserved
1 gss-eap-v1 The GSS-EAP mechanism [this spec
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
Prefix: iso.org.dod.internet.security.mechanisms.abfab.nametypes
(1.3.6.1.5.5.15.2)
Decimal Name Description References
------- ---- ------------------------------------ ----------
0 Reserved Reserved
1 GSS_EAP_NT_EAP_NAME sect 3.1
]]></artwork>
</figure>
</section>
<section anchor="IANA.RFC4121" title="RFC 4121 Token Identifiers">
<t>A new top level registry titled "Kerberos V GSS-API Mechanism Parameters," should be created. This registry should be separate from the existing "Kerberos Parameters" registry. If it has already been created by <xref target="I-D.ietf-krb-wg-gss-cb-hash-agility"/> then that registry should be used.</t>
<t>In this registry a sub-registry called "Kerberos GSS-API
Token Type Identifiers" is created; the overall reference for this
subregistry is section 4.1 of RFC 4121. The allocation
procedure is expert review <xref target="RFC5226"/>. The
expert's primary job is to make sure that token type identifiers
are requested by an appropriate requester for the RFC 4121
mechanism in which they will be used and that multiple values
are not allocated for the same purpose. For RFC 4121 and this
mechanism, the expert is currently expected to make
allocations for token identifiers from documents in the IETF
stream; effectively for these mechanisms the expert currently confirms
the allocation meets the requirements of the IETF review
process.</t>
<t>The initial registrations are as follows:</t>
<texttable>
<ttcol>ID</ttcol> <ttcol>Description</ttcol> <ttcol>Reference</ttcol>
<c>01 00</c> <c>KRB_AP_REQ</c> <c>RFC 4121 sect 4.1</c>
<c>02 00</c> <c>KRB_AP_REP</c> <c>RFC 4121 sect 4.1</c>
<c>03 00</c> <c>KRB_ERROR</c> <c>RFC 4121 sect 4.1</c>
<c>04 04</c> <c>MIC tokens</c> <c>RFC 4121 sect
4.2.6.1</c>
<c>05 04</c> <c>wrap tokens</c> <c>RFC 4121 sect 4.2.6.2</c>
<c>06 01</c> <c>GSS-EAP initiator context token</c> <c><xref
target="CONTEXT"></xref></c>
<c>06 02</c> <c>GSS EAP acceptor context token</c> <c><xref target="CONTEXT"></xref></c>
</texttable>
</section>
<section title="GSS EAP Subtoken Types">
<t>This document creates a top level registry called "The Extensible Authentication Protocol Mechanism for the Generic Security Services Application Programming Interface (GSS-EAP) Parameters". In any short form of that name, including any URI for this registry, it is important that the string GSS come before the string EAP; this will help to distinguish registries if EAP methods for performing GSS-API authentication are ever defined. </t>
<t>In this 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 of GSS EAP subtoken types are made by expert review. The expert is expected to require a public specification of the subtoken similar in detail to registrations given in this document. The security of GSS-EAP depends on making sure that subtoken information has adequate protection and that the overall mechanism continues to be secure. Examining the security and architectural consistency of the proposed registration is the primary responsibility of the expert.</t>
<texttable>
<ttcol>Type</ttcol> <ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0x00000001</c> <c>Error</c>
<c><xref target="SUB.ERROR"></xref></c>
<c>0x0000000B</c> <c>Vendor</c>
<c><xref target="SUB.VENDOR"></xref></c>
<c>0x00000002</c> <c>Acceptor name request</c>
<c><xref target="SUB.ACCEPTOR-NAME"></xref></c>
<c>0x00000003</c> <c>Acceptor name response</c>
<c><xref target="TOK.ACCEPTOR-NAME-RESPONSE"></xref></c>
<c>0x00000005</c> <c>EAP request</c>
<c><xref target="SUB.EAP-REQUEST"></xref></c>
<c>0x00000004</c> <c>EAP response</c>
<c><xref target="SUB.EAP-RESPONSE"></xref></c>
<c>0x0000000C</c> <c>Flags</c>
<c><xref target="TOK.FLAGS"></xref></c>
<c>0x00000006</c> <c>GSS-API channel bindings</c>
<c><xref target="SUB.GSS-CB"></xref></c>
<c>0x0000000D</c> <c>Initiator MIC</c>
<c><xref target="SUB.MIC"></xref></c>
<c>0x0000000E</c> <c>Acceptor MIC</c>
<c><xref target="SUB.MIC"></xref></c>
</texttable>
</section>
<section anchor="IANA.RADIUS" title="RADIUS Attribute Assignments">
<t>The following RADIUS attribute type values <xref target="RFC3575"/> are assigned. The assignment rules in section 9.3 of <xref target="I-D.ietf-radext-radius-extensions" /> may be used if that specification is approved when IANA actions for this specification are processed.</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Attribute</ttcol>
<ttcol>Description</ttcol>
<c>GSS-Acceptor-Service-Name</c> <c>TBD1</c>
<c>user-or-service portion of name</c>
<c>GSS-Acceptor-Host-Name</c> <c>TBD2</c> <c>host portion of
name</c>
<c>GSS-Acceptor-Service-specifics</c> <c>TBD3</c>
<c>service-specifics portion of name</c>
<c>GSS-Acceptor-Realm-Name</c> <c>TBD4</c>
<c>Realm portion of name</c>
</texttable>
</section>
<section title="Registration of the
EAP-AES128 SASL Mechanisms">
<figure><artwork> <![CDATA[
Subject: Registration of SASL mechanisms
EAP-ES128 and EAP-AES128-PLUS
SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS
Security considerations: See RFC 5801 and draft-ietf-abfab-gss-eap
Published specification (recommended): draft-ietf-abfab-gss-eap
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 varient of this mechanism is
also required.
]]></artwork>
</figure>
</section>
<section anchor="ERRORS" title="GSS EAP Errors">
<t>A new subregistry is created in the GSS EAP parameters registry titled "Error Codes". The error codes in this registry are unsigned 32-bit numbers. Values less than or equal to 127 are assigned by standards action. Values 128 through 255 are assigned with the specification required assignment policy. Values greater than 255 are reserved; updates to registration policy may make these values available for assignment and implementations MUST be prepared to receive them.</t>
<t>This table provides the initial contents of the registry.</t>
<texttable>
<ttcol>Value</ttcol> <ttcol>Description</ttcol>
<c>0</c> <c>Reserved</c>
<c>1</c>
<c>Buffer is incorrect size</c>
<c>2</c>
<c>Incorrect mechanism OID</c>
<c>3</c>
<c>Token is corrupted</c>
<c>4</c>
<c>Token is truncated</c>
<c>5</c>
<c>Packet received by direction that sent it</c>
<c>6</c>
<c>Incorrect token type identifier</c>
<c>7</c>
<c>Unhandled critical subtoken received</c>
<c>8</c>
<c>Missing required subtoken</c>
<c>9</c>
<c>Duplicate subtoken type</c>
<c>10</c>
<c>Received unexpected subtoken for current state xxx</c>
<c>11</c>
<c>EAP did not produce a key</c>
<c>12</c>
<c>EAP key too short</c>
<c>13</c>
<c>Authentication rejected</c>
<c>14</c>
<c>AAA returned an unexpected message type</c>
<c>15</c>
<c>AAA response did not include EAP request</c>
<c>16</c>
<c>Generic AAA failure</c>
</texttable>
</section>
<section title="GSS EAP Context Flags">
<t>A new sub-registry is created in the GSS EAP parameters registry. This registry holds registrations of flag bits sent in the flags subtoken <xref target="TOK.FLAGS"/>. There are 32 flag bits available for registration represented as hexadecimal numbers from the most-significant bit 0x80000000 to the least significant bit 0x1. The registration policy for this registry is IETF review or in exceptional cases IESG approval. The following table indicates initial registrations; all other values are available for assignment.</t>
<texttable>
<ttcol>Flag</ttcol>
<ttcol>Name</ttcol>
<ttcol>Reference</ttcol>
<c>0x2</c>
<c>GSS_C_MUTUAL_FLAG</c>
<c><xref target="TOK.FLAGS"/></c>
</texttable>
</section>
</section>
<section title="Security Considerations">
<t>RFC 3748 discusses security issues surrounding EAP. RFC 5247
discusses the security and requirements surrounding key
management that leverages the AAA infrastructure. These
documents are critical to the security analysis of this mechanism.
</t>
<t>RFC 2743 discusses generic security considerations for the
GSS-API. RFC 4121 discusses security issues surrounding the
specific per-message services used in this mechanism.</t>
<t>As discussed in <xref target="NEGO"/>, this mechanism may
introduce multiple layers of security negotiation into
application protocols. Multiple layer negotiations are
vulnerable to a bid-down attack when a mechanism negotiated at
the outer layer is preferred to some but not all mechanisms
negotiated at the inner layer; see section 7.3 of <xref
target="RFC4462"/> for an example. One possible approach to
mitigate this attack is to construct security policy such that
the preference for all mechanisms negotiated in the inner layer
falls between preferences for two outer layer mechanisms or
falls at one end of the overall ranked preferences including
both the inner and outer layer. Another approach is to only use
this mechanism when it has specifically been selected for a
given service. The second approach is likely to be common in
practice because one common deployment will involve an EAP
supplicant interacting with a user to select a given identity.
Only when an identity is successfully chosen by the user will
this mechanism be attempted.</t>
<t>The security of this mechanism depends on the use and
verification of EAP channel binding. Today EAP channel binding
is in very limited deployment. If EAP channel binding is not
used, then the system may be vulnerable to phishing attacks
where a user is diverted from one service to another. If the EAP method in question supports mutual authentication then users can only be diverted between servers that are part of the same AAA infrastructure. For deployments where membership in the AAA infrastructure is limited, this may serve as a significant limitation on the value of phishing as an attack. For other deployments, use of EAP channel binding is critical to avoid phishing. These
attacks are possible with EAP today although not typically with
common GSS-API mechanisms. For this reason, implementations are required to implement and use EAP channel binding; see <xref target="EAP-CB"/> for details.</t>
<t>The security considerations of EAP channel binding <xref
target="I-D.ietf-emu-chbind" /> describe the security properties
of channel binding. Two attacks are worth calling out
here. First, when a tunneled EAP method is used, it is critical
that the channel binding be performed with an EAP server trusted
by the peer. With existing EAP methods this typically requires
validating the certificate of the server tunnel endpoint back to
a trust anchor and confirming the name of the entity who is a
subject of that certificate. EAP methods may suffer from
bid-down attacks where an attacker can cause a peer to think
that a particular EAP server does not support channel
binding. This does not directly cause a problem because mutual
authentication is only offered at the GSS-API level when channel
binding to the server's identity is successful. However when an
EAP method is not vulnerable to these bid-down attacks,
additional protection is available. This mechanism will benefit
significantly from new strong EAP methods such as <xref
target="I-D.ietf-emu-eap-tunnel-method" />.</t>
<t>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
such as Kerberos.</t>
<t>RADIUS does provide a weak form of hop-by-hop confidentiality of key material based on using MD5 as a stream cipher. Diameter can use TLS or IPsec but has no mandatory-to-implement confidentiality mechanism. Operationally, protecting key material as it is transported between the IDP and RP is critical to per-message security and verification of GSS-API channel binding <xref target="RFC5056"/>. Mechanisms such as RADIUS over TLS <xref target="I-D.ietf-radext-radsec"/> provide significantly better protection of key material than the base RADIUS specification.</t>
</section>
<section title="Acknowledgements">
<t>Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov and
Sujing Zhou provided valuable reviews of this document.</t>
<t>Rhys Smith provided the text for the OID registry section. Sam Hartman's work on this draft has been funded by JANET.</t>
</section>
</middle>
<back>
<references title='Normative References'>&rfc2119;
&RFC2743;
&RFC3748;
&RFC3961;
&RFC4401;
&RFC4402;
&RFC4121;
&RFC4282;
&RFC5056;
&RFC5554;
&CHBIND;
<?rfc
include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3575'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2744'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891'?>
<reference anchor="GSS-IANA"
target="http://www.iana.org/assignments/gssapi-service-names/gssapi-service-names.xhtml">
<front>
<title>GSS-API Service Name Registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-abfab-arch'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-radsec'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-krb-wg-gss-cb-hash-agility'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-radius-extensions'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-emu-eap-tunnel-method'?>
&RFC1964;
&RFC4072;
&RFC3579;
&RFC4178;
&RFC4422;
&RFC4462;
&RFC5178;
&RFC5247;
</references>
<section title="Pre-Publication RADIUS VSA">
<t>As described in <xref target="RADIUS_AVP"/>, RADIUS attributes are used to carry the acceptor name when this family of mechanisms is used with RADIUS. Prior to publication of this specification, a vendor-specific RADIUS attribute was used. This non-normative appendix documents that attribute as it may be seen from older implementations.</t>
<t>Prior to IANA assignment, GSS-EAP used a RADIUS vendor-specific attribute
for carrying the acceptor name. The VSA with enterprise ID
25622 is formatted as a VSA according to the recommendation in
the RADIUS specification. The following sub-attributes are
defined:
</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Attribute</ttcol>
<ttcol>Description</ttcol>
<c>GSS-Acceptor-Service-Name</c> <c>128</c>
<c>user-or-service portion of name</c>
<c>GSS-Acceptor-Host-Name</c> <c>129</c> <c>host portion of
name</c>
<c>GSS-Acceptor-Service-specifics</c> <c>130</c>
<c>service-specifics portion of name</c>
<c>GSS-Acceptor-Realm-Name</c> <c>131</c>
<c>Realm portion of name</c>
</texttable>
</section> </back>
</rfc>
<!-- LocalWords: backend metadata
-->
| PAFTECH AB 2003-2026 | 2026-04-23 10:04:23 |