One document matched: draft-howlett-eap-gss-00.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-howlett-eap-gss-00.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(UK)</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.
</t></abstract>
</front>
<middle>
<section title="Introduction">
<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 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. Using AAA
proxies, this mode can be extended beyond one organization to
provide federated authentication for network access. </t>
<t>The Generic Security Services Application Programming
Interface (GSS-API) <xref target="RFC2743"/> provides a generic
framework for applications to use security services including
authentication and per-message data security services. 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 use
of the Security Assertion Markup Language to transport
assertions about attributes of client subjects to servers.
Together this combination will provide federated authentication
and authorisation 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.</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 may respond, 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 authentication can be started by either the peer
or the authenticator. The EAP peer maps onto the GSS-API initiator
and the EAP authenticator and EAP server maps onto the GSS-API
acceptor. EAP messages from the peer to the authenticator are
called responses; messages from the authenticator to the peer
are called requests. </t>
<t>This specification permits a GSS-API peer 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 peer acts as an EAP pass-through
authenticator.
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 title="EAP Channel Binding and Naming">
<t> EAP authenticates 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 below. 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 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 name types that need to be imported and then
discusses the structure of the mechanism name.</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 network
access identifier (NAI) <xref target="RFC4282"/>.</t>
<t>The GSS_C_NT_HOSTBASED_SERVICE name form represents a
service running on a host; it is textually represented as
"HOST@SERVICE". 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 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. </t>
<t>Sometimes, the client may know what AAA realm a particular
host should belong to. In this case it would be desirable to
use a name form that included a service, host and realm.
Syntactically, this appears the same as the domain-based name
discussed in <xref target="RFC5178"/>, but the semantics do
not appear sufficiently similar to use the same name form.</t>
<t>A name form is needed to identify a SAML endpoint and a
specific instance of SAML metadata associated with that
endpoint. The metadata describes properties of the endpoint
including public keys. One of the motivating use cases is to
be able to use GSS-API to build trust in this metadata. In
this case it is desirable to authenticate to an acceptor based
on the endpoint and a cryptographic hash of the metadata.</t>
<t>The mechanism name form must be able to represent all
of these names. In addition, the mechanism name form MUST
make it easy for intermediate AAA proxies to extract the
hostname portion when present. One possible starting point is
the Kerberos name form discussed in <xref target="RFC1964"/>.
The major down side of that approach is that there is no
guaranteed way to be able to extract a hostname from a
Kerberos name. Also, Kerberos naming may provide more
flexibility than is needed.</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>This section defines the format of the exported name token
for this mechanism.</t>
</section>
<section title="Acceptor Name RADIUS AVP">
<t>This section defines an attribute-value pair for
transporting the name of the acceptor in a RADIUS or Diameter
message. This AVP is included by the server to indicate the
acceptor name it claims. This AVP is included in channel
bindings by the client to indicate what acceptor is
authenticated against.</t>
</section>
<section title="Proxy Verification of Acceptor Name">
</section>
</section>
<section anchor="NEGO" title="Selection of EAP Method">
<t>The specification currently describes a single GSS-API
mechanism. The peer and authenticator exchange EAP messages.
The GSS-API mechanism specifies no constraints about what EAP
method types are used; text in the specification says that
negotiation of which EAP method to use happens at the EAP
layer.</t>
<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 contains an EAP packet or special token. The first EAP
packet SHALL be a EAP response/identity packet from the
initiator to acceptor. The acceptor SHALL respond either with
an EAP request or an EAP failure packet.</t>
<t>The initiator and acceptor will continue exchanging
response/request packets until authentication succeeds or
fails.</t>
<t>After the EAP authentication succeeds, channel binding tokens
are exchanged; see <xref target="CHANNEL-BINDING"/> for
details. Currently, the channel binding tokens are the only
types of special tokens in use.</t>
<section title="Mechanisms and Encryption Types">
<t>This mechanism family uses the security services of the
Kerberos cryptographic framework <xref target="RFC3961"/>. As
such, a particular encryption type needs to be chosen. A new
GSS-API OID should be defined for EAP GSS-API with a given
Kerberos crypto system. This document defines the
eap-aes128-cts-hmac-sha1-96 GSS-API mechanism. XXX define an
OID for that and use the right language to get that into the
appropriate SASL registry.</t>
</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.</t>
<t>Integrity, confidentiality, sequencing and replay detection
are always available. Regardless of what flags are requested
in GSS_Init_sec_context, implementations MUST set the flag
corresponding to these services in the output of
GSS_Init_sec_context and GSS_Accept_sec_context.</t>
<t>The PROT_READY service 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>Open issue: how is the mutual authentication request and
return handled? The big question here is figuring out how
this interacts with EAP and transporting state back to a
pass-through authenticator.</t>
<t>Open issue: handling of lifetime parameters. </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 the result of the
random-to-key operation 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 CRK.</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 providing by
the initiator if null channel bindings are passed into
gss_accept_sec_context. Protocols such as HTTP Negotiate
depend on this behavior of some Kerberos implementations. It
is reasonable for the protocol to distinguish an acceptor
ignoring channel bindings from an acceptor successfully
validating them. No facility is currently provided for an
initiator implementation to expose this distinction to the
initiator code.</t>
<t>Define a token format, token ID and key usage for this token.</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.</t>
</section>
</section>
<section title="Authorization and Naming Extensions">
<t>One goal of this mechanism is to support retrieving a SAML
assertion as a result of the EAP authentication. The GSS-API
naming extensions will be used to access this message. This
section will be expanded to discuss details.</t>
</section>
<section title="Applicability Considerations">
<t>Section 1.3 of RFC 3748 provides the applicability statement
for EAP. Among other constraints, EAP is scoped for use in
network access. This specification anticipates using EAP beyond
its current scope. The assumption is that some other document
will discuss the issues surrounding the use of EAP for
application authentication and expand EAP's applicability. That
document will likely enumerate considerations that a specific
use of EAP for application authentication needs to handle.
Examples of such considerations might include the multi-layer
negotiation issue, deciding when EAP or some other mechanism
should be used, and so forth. This section serves as a
placeholder to discuss any such issues with regard to the use of
EAP and GSS-API.</t>
</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 involved 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. These
attacks are possible with EAP today although not typically with
common GSS-API mechanisms.</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>
</section>
</middle>
<back>
<references title='Normative References'>&rfc2119;
&RFC2743;
&RFC3748;
&RFC3961;
&RFC4401;
&RFC4402;
&RFC4121;
&RFC4282;
&RFC5056;
&RFC5554;
&CHBIND;
</references>
<references title="Informative References">
&RFC1964;
&RFC4072;
&RFC3579;
&RFC4178;
&RFC4422;
&RFC4462;
&RFC5178;
&RFC5247;
</references>
</back>
</rfc>
<!-- LocalWords: backend metadata
-->
| PAFTECH AB 2003-2026 | 2026-04-22 22:43:41 |