One document matched: draft-ietf-abfab-gss-eap-04.txt
Differences from draft-ietf-abfab-gss-eap-03.txt
Network Working Group S. Hartman, Ed.
Internet-Draft Painless Security
Intended status: Standards Track J. Howlett
Expires: May 2, 2012 JANET(UK)
October 30, 2011
A GSS-API Mechanism for the Extensible Authentication Protocol
draft-ietf-abfab-gss-eap-04.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hartman & Howlett Expires May 2, 2012 [Page 1]
Internet-Draft EAP GSS-API October 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Secure Association Protocol . . . . . . . . . . . . . . . 6
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 8
3. EAP Channel Binding and Naming . . . . . . . . . . . . . . . . 9
3.1. Mechanism Name Format . . . . . . . . . . . . . . . . . . 9
3.2. Exported Mechanism Names . . . . . . . . . . . . . . . . . 11
3.3. Acceptor Name RADIUS AVP . . . . . . . . . . . . . . . . . 12
3.4. Proxy Verification of Acceptor Name . . . . . . . . . . . 13
4. Selection of EAP Method . . . . . . . . . . . . . . . . . . . 15
5. Context Tokens . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Mechanisms and Encryption Types . . . . . . . . . . . . . 17
5.2. Processing received tokens . . . . . . . . . . . . . . . . 17
5.3. Error Subtokens . . . . . . . . . . . . . . . . . . . . . 18
5.4. Initial State . . . . . . . . . . . . . . . . . . . . . . 18
5.4.1. Vendor Subtoken . . . . . . . . . . . . . . . . . . . 18
5.4.2. Acceptor Name Request . . . . . . . . . . . . . . . . 19
5.4.3. Acceptor Name Response . . . . . . . . . . . . . . . . 19
5.5. Authenticate State . . . . . . . . . . . . . . . . . . . . 20
5.5.1. EAP Request Subtoken . . . . . . . . . . . . . . . . . 21
5.5.2. EAP Response Subtoken . . . . . . . . . . . . . . . . 21
5.6. Extension State . . . . . . . . . . . . . . . . . . . . . 21
5.6.1. Flags Subtoken . . . . . . . . . . . . . . . . . . . . 21
5.6.2. GSS Channel Bindings Subtoken . . . . . . . . . . . . 22
5.6.3. MIC Subtoken . . . . . . . . . . . . . . . . . . . . . 22
5.7. Example Token . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Context Options . . . . . . . . . . . . . . . . . . . . . 24
6. Acceptor Services . . . . . . . . . . . . . . . . . . . . . . 26
6.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 26
6.2. Per-message security . . . . . . . . . . . . . . . . . . . 26
6.3. Pseudo Random Function . . . . . . . . . . . . . . . . . . 26
7. Applicability Considerations . . . . . . . . . . . . . . . . . 27
8. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. RFC 4121 Token Identifiers . . . . . . . . . . . . . . . . 28
8.2. GSS EAP Subtoken Types . . . . . . . . . . . . . . . . . . 29
8.3. RADIUS Attribute Assignments . . . . . . . . . . . . . . . 30
8.4. GSS EAP Errors . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Hartman & Howlett Expires May 2, 2012 [Page 2]
Internet-Draft EAP GSS-API October 2011
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Hartman & Howlett Expires May 2, 2012 [Page 3]
Internet-Draft EAP GSS-API October 2011
1. Introduction
The ABFAB architecture [I-D.lear-abfab-arch] describes an
architecture for providing federated access management to
applications using the Generic Security Services Application
Programming Interface (GSS-API) [RFC2743] and Simple Authentication
and Security Layers (SASL) [RFC4422]. This specification provides
the core mechanism for bringing federated authentication to these
applications.
The Extensible Authentication Protocol (EAP) [RFC3748] defines a
framework for authenticating a network access client and server in
order to gain access to a network. A variety of different EAP
methods are in wide use; one of EAP's strengths is that for most
types of credentials in common use, there is an EAP method that
permits the credential to be used.
EAP is often used in conjunction with a backend authentication server
via RADIUS [RFC3579] or Diameter [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. As described in the architecture
document, using AAA proxies, this mode can be extended beyond one
organization to provide federated authentication for network access.
The GSS-API provides a generic framework for applications to use
security services including authentication and per-message data
security. Between protocols that support GSS-API directly or
protocols that support SASL [RFC4422], many application protocols can
use GSS-API for security services. However, with the exception of
Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the
Internet. While GSS-API permits an application to be written
independent of the specific GSS-API mechanism in use, there is no
facility to separate the server from the implementation of the
mechanism as there is with EAP and backend authentication servers.
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
Hartman & Howlett Expires May 2, 2012 [Page 4]
Internet-Draft EAP GSS-API October 2011
addition, this specification supports the architectural goal of
transporting attributes about subjects to relying parties. Together
this combination will provide federated authentication and
authorization for GSS-API applications.
This 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.
Section 1.3 of [RFC5247] outlines the typical conversation between
EAP peers where an EAP key is derived:
o Phase 0: Discovery
o Phase 1: Authentication
o 1a: EAP authentication
o 1b: AAA Key Transport (optional)
o Phase 2: Secure Association Protocol
o 2a: Unicast Secure Association
o 2b: Multicast Secure Association (optional)
1.1. Discovery
GSS-API peers discover each other and discover support for GSS-API in
an application-dependent mechanism. SASL [RFC4422] describes how
discovery of a particular SASL mechanism such as a GSS-API mechanism
is conducted. The Simple and Protected Negotiation mechanism
(SPNEGO) [RFC4178] provides another approach for discovering what
GSS-API mechanisms are available. The specific approach used for
discovery is out of scope for this mechanism.
1.2. Authentication
GSS-API authenticates a party called the GSS-API initiator to the
GSS-API acceptor, optionally providing authentication of the acceptor
to the initiator. Authentication starts with a mechanism-specific
message called a context token sent from the initiator to the
acceptor. The acceptor responds, followed by the initiator, and so
on until authentication succeeds or fails. GSS-API context tokens
are reliably delivered by the application using GSS-API. The
application is responsible for in-order delivery and retransmission.
Hartman & Howlett Expires May 2, 2012 [Page 5]
Internet-Draft EAP GSS-API October 2011
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 referrs 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.
Because GSS-API provides guaranteed delivery, the EAP retransmission
timeout MUST be infinite and the EAP layer MUST NOT retransmit a
message.
This specification permits a GSS-API acceptor to hand-off the
processing of the EAP packets to a remote EAP server by using AAA
protocols such as RADIUS, RadSec or Diameter. In this case, the GSS-
API peer 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.
See Section 5 for details of the authentication exchange.
1.3. Secure Association Protocol
After authentication succeeds, GSS-API provides a number of per-
message security services that can be used:
GSS_Wrap() provides integrity and optional confidentiality for a
message.
GSS_GetMIC() provides integrity protection for data sent
independently of the GSS-API
Hartman & Howlett Expires May 2, 2012 [Page 6]
Internet-Draft EAP GSS-API October 2011
GSS_Pseudo_random [RFC4401] provides key derivation functionality.
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 Section 6 for details.
Hartman & Howlett Expires May 2, 2012 [Page 7]
Internet-Draft EAP GSS-API October 2011
2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hartman & Howlett Expires May 2, 2012 [Page 8]
Internet-Draft EAP GSS-API October 2011
3. EAP Channel Binding and Naming
EAP authenticates a user to a realm. The peer knows that it has
exchanged authentication with an EAP server in a given realm. Today,
the peer does not typically know which NAS it is talking to securely.
That is often fine for network access. However privileges to
delegate to a chat server seem very different than privileges for a
file server or trading site. Also, an EAP peer knows the identity of
the home realm, but perhaps not even the visited realm.
In contrast, GSS-API takes a name for both the initiator and acceptor
as inputs to the authentication process. When mutual authentication
is used, both parties are authenticated. The granularity of these
names is somewhat mechanism dependent. In the case of the Kerberos
mechanism, the acceptor name typically identifies both the protocol
in use (such as IMAP) and the specific instance of the service being
connected to. The acceptor name almost always identifies the
administrative domain providing service.
An EAP GSS-API mechanism needs to provide GSS-API naming semantics in
order to work with existing GSS-API applications. EAP channel
binding [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.
EAP channel binding is easily confused with a facility in GSS-API
also called channel binding. GSS-API channel binding provides
protection against man-in-the-middle attacks when GSS-API is used as
authentication inside some tunnel; it is similar to a facility called
cryptographic binding in EAP. See [RFC5056] for a discussion of the
differences between these two facilities and Section 6.1 for how GSS-
API channel binding is handled in this mechanism.
3.1. Mechanism Name Format
Before discussing how the initiator and acceptor names are validated
in the AAA infrastructure, it is necessary to discuss what composes a
name for an EAP GSS-API mechanism. GSS-API permits several types of
generic names to be imported using GSS_Import_name(). Once a
Hartman & Howlett Expires May 2, 2012 [Page 9]
Internet-Draft EAP GSS-API October 2011
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.
The string representation of the GSS-EAP mechanism name has the
following ABNF [RFC5234] representation:
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 ]
The user-or-service component is the portion of a network access
identifier (NAI) before the '@' symbol for initiator names and the
service name from the registry of GSS-API host-based services in the
case of acceptor names [GSS-IANA]. The 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 the realm
portion of a NAI for initiator names. The realm is the
administrative realm of a service for an acceptor name.
The string representation of this name form is designed to be
generally compatible with the string representation of Kerberos names
defined in [RFC1964].
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) [RFC4282]. The name is split 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.
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
Hartman & Howlett Expires May 2, 2012 [Page 10]
Internet-Draft EAP GSS-API October 2011
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.
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 [RFC5178], but
the semantics are not similar enough semantics to use the same name
form.
If the null name type or the GSS_EAP_NT_EAP_NAME (oid XXX) 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)}.
3.2. Exported Mechanism Names
GSS-API provides the GSS_Export_name call. This call can be used to
export the binary representation of a name. This name form can be
stored on access control lists for binary comparison.
The exported name token MUST use the format described in section 3.2
Hartman & Howlett Expires May 2, 2012 [Page 11]
Internet-Draft EAP GSS-API October 2011
of RFC 2743. The mechanism specific portion of this name token is
the string format of the mechanism name described in Section 3.1.
RFC 2744 [RFC2744] places the requirement that the result of
importing a name, canonicalizing it to a mechanism 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.
3.3. Acceptor Name RADIUS AVP
Currently, GSS-EAP uses 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:
+-------------------------------+-----------+-----------------------+
| Name | Attribute | Description |
+-------------------------------+-----------+-----------------------+
| GSS-Acceptor-Service-Name | 128 | user-or-service |
| | | portion of name |
| | | |
| GSS-Acceptor-Host-Name | 129 | host portion of name |
| | | |
| GSS-Acceptor-Service-specific | 130 | service-specifics |
| | | portion of name |
| | | |
| GSS-Acceptor-Realm-Name | 131 | Realm portion of name |
+-------------------------------+-----------+-----------------------+
All these items are strings. See Section 3.1 for details of the
values in a name.
If RADIUS is used as an AAA transport, the acceptor MUST send the
acceptor name in the VSA. That is, the acceptor decomposes its name
and sends any non-empty portion as a sub-attribute in this VSA.
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
Hartman & Howlett Expires May 2, 2012 [Page 12]
Internet-Draft EAP GSS-API October 2011
example, if the client supplied a hostname in channel binding data,
the hostname MUST be in a successful channel binding response.
If an empty target name is supplied to GSS_Init_Sec_Context, the
initiator MUST fail context establishment unless the acceptor
supplies the acceptor name response Section 5.4.3. If a null target
name is supplied, the initiator MUST use this response to populate
EAP channel bindings.
3.4. Proxy Verification of Acceptor Name
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.
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.
A proxy close to the EAP server is unlikely to be in a position to
confirm that the acceptor is claiming the correct hostname. Instead
this is typically delegated to a proxy near the acceptor. That proxy
is typically expected to verify the acceptor hostname and to verify
the appropriate AAA credential for that host is used. Such a proxy
may insert the acceptor realm if it is absent, permitting realm
configuration to be at the proxy boundary rather than on acceptors.
Ultimately specific proxy behavior is a matter for deployment. The
EAP server MUST assure that the appropriate validation has been done
before including acceptor name attributes in a successful channel
binding response. If the acceptor service is included the EAP server
asserts that the service is plausible for the acceptor. If the
acceptor hostname is included the EAP server asserts that the
acceptor hostname is verified. If the realm is included the EAP
server asserts that the realm has been verified, and if the hostname
was also included, that the realm and hostname are consistent. Part
of this verification MAY be delegated to proxies, but the EAP server
configuration MUST guarantee that the combination of proxies meets
these requirements. Typically such delegation will involve business
or operational measures such as cross-organizational agreements as
well as technical measures.
It is likely that future technical work will be needed to communicate
Hartman & Howlett Expires May 2, 2012 [Page 13]
Internet-Draft EAP GSS-API October 2011
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.
Hartman & Howlett Expires May 2, 2012 [Page 14]
Internet-Draft EAP GSS-API October 2011
4. Selection of EAP Method
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.
EAP does not provide a facility for an EAP server to advertise what
methods are available to a peer. Instead, a server starts with its
preferred method selection. If the peer does not accept that method,
the peer sends a NAK response containing the list of methods
supported by the client.
Providing multiple facilities to negotiate which security mechanism
to use is undesirable. Section 7.3 of [RFC4462]describes the problem
referencing the 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.
The standard solution to this problem is to perform all the
negotiation at one layer. In this case, rather than defining a
single GSS-API mechanism, a family of mechanisms should be defined.
Each mechanism corresponds to an EAP method. The EAP method type
should be part of the GSS-API OID. Then, a GSS-API rather than EAP
facility can be used for negotiation.
Unfortunately, using a family of mechanisms has a number of problems.
First, GSS-API assumes that both the initiator and acceptor know the
entire set of mechanisms that are available. Some negotiation
mechanisms are driven by the client; others are driven by the server.
With EAP GSS-API, the acceptor does not know what methods the EAP
server implements. The EAP server that is used depends on the
identity of the client. The best solution so far is to accept the
disadvantages of multi-layer negotiation and commit to using EAP GSS-
API before a specific EAP method. This has two main disadvantages.
First, authentication may fail when other methods might allow
authentication to succeed. Second, a non-optimal security mechanism
may be chosen.
Hartman & Howlett Expires May 2, 2012 [Page 15]
Internet-Draft EAP GSS-API October 2011
5. Context Tokens
All context establishment tokens emitted by the EAP mechanism SHALL
have the framing described in section 3.1 of [RFC2743], as
illustrated by the following pseudo-ASN.1 structures:
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing EAP mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
The innerToken field starts with a 16-bit network byte order token
type. The remainder of the innerToken field is a set of type-length-
value subtokens. The following figure describes the structure of the
inner token:
+----------------+--------------------------+
| Position | Description |
+----------------+--------------------------+
| 0..1 | token ID |
| | |
| 2..5 | first subtoken type |
| | |
| 6..9 | length of first subtoken |
| | |
| 10..10+n | first subtoken body |
| | |
| 10+n+1..10+n+4 | second subtoken type |
+----------------+--------------------------+
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.
Structure of Inner Token
The length does not include the length of the type field or the
Hartman & Howlett Expires May 2, 2012 [Page 16]
Internet-Draft EAP GSS-API October 2011
length field; the length only covers the value.
Tokens from the initiator to acceptor use an inner token type with ID
06 01; tokens from acceptor to initiator use an inner token type with
ID 06 02. These token types are registered in the registry of RFC
4121 token types; see Section 8.1.
See Section 5.7 for the encoding of a complete token. The following
sections discuss how mechanism OIDs are chosen and the state machine
that defines what subtokens are permitted at each point in the
context establishment process.
5.1. Mechanisms and Encryption Types
This mechanism family uses the security services of the Kerberos
cryptographic framework [RFC3961]. 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-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.
5.2. Processing received tokens
Whenever a context token is received, the receiver performs the
following checks. First the receiver confirms the object identifier
is that of the mechanism being used. The receiver confirms that the
token type corresponds to the role of the peer: acceptors will only
process initiator tokens and initiators will only process acceptor
tokens.
Implementations of this mechanism maintain a state machine for the
context establishment process. Both the initiator and acceptor start
out in the initial state; see Section 5.4 for a description of this
state. Associated with each state are a set of subtoken types that
are processed in that state and rules for processing these subtoken
types. The reciever examines the subtokens in order, processing any
that are appropriate for the current state.
A state may have a set of required subtoken types. If a subtoken
type is required by the current state but no subtoken of that type is
present, then the context establishment MUST fail.
The most-significant bit (0x80000000) in a subtoken type is the
critical bit. If a subtoken with this bit set in the type is
Hartman & Howlett Expires May 2, 2012 [Page 17]
Internet-Draft EAP GSS-API October 2011
received, the receiver MUST fail context establishment unless the
subtoken is understood and processed for the current state.
The subtoken type MUST be unique within a given token.
5.3. Error Subtokens
The acceptor may always end the exchange by generating an error
subtoken. The error subtoken has the following format:
+--------+----------------------------------------------------------+
| Pos | Description |
+--------+----------------------------------------------------------+
| 0..3 | 0x80 00 00 01 |
| | |
| 4..7 | length of error token |
| | |
| 8..11 | major status from RFC 2744 as 32-bit network byte order |
| | |
| 12..15 | GSS EAP error code as 32-bit network byte order; see |
| | Section 8.4 |
+--------+----------------------------------------------------------+
Initiators MUST ignore octets beyond the GSS EAP error code for
future extensibility. As indicated, the error token is always marked
critical.
5.4. Initial State
Both the acceptor and initiator start the context establishment
process in the initial state.
The initiator sends a token to the acceptor. It MAY be empty; no
subtokens are required in this state. Alternatively the initiator
MAY include a vendor ID subtoken or an acceptor name request
subtoken.
The acceptor responds to this message. It MAY include an acceptor
name response subtoken. It MUST include a first eap request; this is
an EAP request/identity message (see Section 5.5.1 for the format of
this subtoken).
The initiator and acceptor then transition to authenticate state.
5.4.1. Vendor Subtoken
The vendor ID token has type 0x0000000B and the following structure:
Hartman & Howlett Expires May 2, 2012 [Page 18]
Internet-Draft EAP GSS-API October 2011
+-------------+------------------------+
| Pos | Description |
+-------------+------------------------+
| 0..3 | 0x0000000B |
| | |
| 4..7 | length of vendor token |
| | |
| 8..8+length | Vendor ID string |
+-------------+------------------------+
The vendor ID string is an UTF-8 string describing the vendor of this
implementation. This string is unstructured and for debugging
purposes only.
5.4.2. Acceptor Name Request
The acceptor name request token is sent from the initiator to the
acceptor indicating that the initiator wishes a particular acceptor
name. This is similar to TLS Server Name Indication. The structure
is as follows:
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000002 |
| | |
| 4..7 | Length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
It is likely that channel binding and thus authentication will fail
if the acceptor does not choose a name that is a superset of this
name. That is, if a hostname is sent, the acceptor needs to be
willing to accept this hosntame.
5.4.3. Acceptor Name Response
The acceptor name response subtoken indicates what acceptor name is
used. This is useful for example if the initiator supplied no target
name to context initialization. This allows the initiator to learn
the acceptor name. EAP channel bindings will provide confirmation
that the acceptor is accurately naming itself.
This token is sent from the acceptor to initiator. Typically this
token would only be send if the acceptor name request is absent.
Hartman & Howlett Expires May 2, 2012 [Page 19]
Internet-Draft EAP GSS-API October 2011
+------+------------------------------+
| Pos | Description |
+------+------------------------------+
| 0..3 | 0x00000003 |
| | |
| 4..7 | Length of subtoken |
| | |
| 8..n | string form of acceptor name |
+------+------------------------------+
5.5. Authenticate State
In this state, the acceptor sends EAP requests to the initiator and
the initiator 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.
The EAP conversation can end in a number of ways:
o If the EAP state machine generates an EAP success message, then
EAP believes the authentication is successful. The ACCEPTOR MUST
confirm that a key has been derived (Section 7.10 [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 receivs 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.
o 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.
o If there is some other error, the acceptor MAY return an error
subtoken.
Hartman & Howlett Expires May 2, 2012 [Page 20]
Internet-Draft EAP GSS-API October 2011
5.5.1. EAP Request Subtoken
The EAP Request subtoken is sent from the acceptor to the initiator.
This subtoken is always critical and is required in the
authentication state.
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x8000005 |
| | |
| 4..7 | Length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
5.5.2. EAP Response Subtoken
This subtoken is required in authentication state messages from the
initiator to the acceptor. It is always critical.
+-------------+-----------------------+
| Pos | Description |
+-------------+-----------------------+
| 0..3 | 0x8000004 |
| | |
| 4..7 | Length of EAP message |
| | |
| 8..8+length | EAP message |
+-------------+-----------------------+
5.6. Extension State
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 Section 6.1). 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.
Both the initiator and acceptor MUST include and verify a MIC
subtoken to protect the extensions exchange.
5.6.1. Flags Subtoken
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
Hartman & Howlett Expires May 2, 2012 [Page 21]
Internet-Draft EAP GSS-API October 2011
flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the
initiator successfully performed mutual authentication. This flag
has the value 0x2 to be consistent with RFC 2744.
+-------+-----------------------+
| Pos | Description |
+-------+-----------------------+
| 0..3 | 0x0000000C |
| | |
| 4..7 | length of flags token |
| | |
| 8..11 | flags |
+-------+-----------------------+
Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag
octets beyond the first 4 and MUST ignore flag bits other than
GSS_C_MUTUAL_FLAG.
5.6.2. GSS Channel Bindings Subtoken
This token is required and always critical. It is sent from the
initiator to the acceptor. The contents of this token are an RFC
4121 GSS wrap token containing the application data from the GSS
channel bindings.
+-------------+-----------------------------------------------------+
| Pos | Description |
+-------------+-----------------------------------------------------+
| 0..3 | 0x80000006 |
| | |
| 4..7 | length of wrap token |
| | |
| 8..8+length | Wrap token containing channel binding application |
| | data |
+-------------+-----------------------------------------------------+
Again, only the application data is sent in the channel binding. The
initiator and acceptor addresses are ignored.
5.6.3. MIC Subtoken
This token MUST be the last subtoken in the tokens sent in Extensions
state. This token is sent both by the initiator and acceptor.
Hartman & Howlett Expires May 2, 2012 [Page 22]
Internet-Draft EAP GSS-API October 2011
+-------------+--------------------------------------------------+
| Pos | Description |
+-------------+--------------------------------------------------+
| 0..3 | 0x8000000D for initiator 0x8000000E for acceptor |
| | |
| 4..7 | Length of RFC 4121 MIC token |
| | |
| 8..8+length | RFC 4121 result of GSS_GetMIC |
+-------------+--------------------------------------------------+
As with any call to GSS_GetMIC, a token is produced as described in
RFC 4121 using the CRK Section 6 as the key. The input to GSS_GetMIC
is as follows:
1. 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 inclded; only
the tag, length and value of the object identifier itself.
2. A 16-bit token type in network byte order of the RFC 4121 token
identifier (0x0601 for initiator, 0x0602 for acceptor).
3. For each subtoken other than the MIC subtoken itself:
1. A four octet subtoken type in network byte order
2. A four byte length in network byte order
3. Length octets of value from that subtoken
Hartman & Howlett Expires May 2, 2012 [Page 23]
Internet-Draft EAP GSS-API October 2011
5.7. Example Token
+----+------+----+------+-----+----------------------------+
| 60 | 24 | 06 | 0a | 2b | 06 01 04 01 a9 4a 16 01 12 |
+----+------+----+------+-----+----------------------------+
|App0|Token |OID |OID | 1 3 | 6 1 4 1 5322 22 1 18 |
|Tag |length|Tag |length| Mechanism object id |
+----+------+----+------+----------------------------------+
+----------+-------------+-------------+
| 06 01 | 00 00 00 02 | 00 00 00 0e |
+----------+-------------|-------------|
|Initiator | Acceptor | Length |
|context | name | (14 octets) |
|token id | request | |
+----------+-------------+-------------+
+-------------------------------------------+
| 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 |
+-------------------------------------------+
| String form of acceptor name |
| "host/localhost" |
+-------------------------------------------+
Example Initiator Token
5.8. Context Options
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.
This GSS mechanism MUST only be used with EAP methods that provide
dictionary attack resistance.
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.
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.
Hartman & Howlett Expires May 2, 2012 [Page 24]
Internet-Draft EAP GSS-API October 2011
The EAP method MUST support mutual authentication and channel
binding. See Section 3.3 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 Section 3.3, the initiator MUST send a flags subtoken
Section 5.6.1 in Extensions state.
Open issue: handling of lifetime parameters.
Hartman & Howlett Expires May 2, 2012 [Page 25]
Internet-Draft EAP GSS-API October 2011
6. Acceptor Services
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.
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 [RFC3961] 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 GMSK.
The CRK is derived from the GMSK using the following procedur
Tn = pseudo-random(GMSK, n || "rfc4121-gss-eap")
CRK = truncate(L, T1 || T2 || .. || Tn)
L = output RFC 3961 key size
6.1. GSS-API Channel Binding
GSS-API channel binding [RFC5554] is a protected facility for
exchanging a cryptographic name for an enclosing channel between the
initiator and acceptor. The initiator sends channel binding data and
the acceptor confirms that channel binding data has been checked.
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.
As discussed, the GSS channel bindings subtoken is sent in the
extensions state.
6.2. Per-message security
The per-message tokens of section 4 of RFC 4121 are used. The CRK
SHALL be treated as the initiator sub-session key, the acceptor sub-
session key and the ticket session key.
6.3. Pseudo Random Function
The pseudo random function defined in [RFC4402] is used.
Hartman & Howlett Expires May 2, 2012 [Page 26]
Internet-Draft EAP GSS-API October 2011
7. Applicability Considerations
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.
Hartman & Howlett Expires May 2, 2012 [Page 27]
Internet-Draft EAP GSS-API October 2011
8. Iana Considerations
This specification creates a number of IANA registries.
8.1. RFC 4121 Token Identifiers
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 [I-D.ietf-krb-wg-gss-cb-hash-agility] then that
registry should be used.
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 [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.
The initial registrations are as follows:
+-------+---------------------------------+-----------------------+
| ID | Description | Reference |
+-------+---------------------------------+-----------------------+
| 01 00 | KRB_AP_REQ | RFC 4121 sect 4.1 |
| | | |
| 02 00 | KRB_AP_REP | RFC 4121 sect 4.1 |
| | | |
| 03 00 | KRB_ERROR | RFC 4121 sect 4.1 |
| | | |
| 04 04 | MIC tokens | RFC 4121 sect 4.2.6.1 |
| | | |
| 05 04 | wrap tokens | RFC 4121 sect 4.2.6.2 |
| | | |
| 06 01 | GSS-EAP initiator context token | Section 5 |
| | | |
| 06 02 | GSS EAP acceptor context token | Section 5 |
+-------+---------------------------------+-----------------------+
Hartman & Howlett Expires May 2, 2012 [Page 28]
Internet-Draft EAP GSS-API October 2011
8.2. GSS EAP Subtoken Types
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
authenitication are ever defined.
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.
+------------+--------------------------+---------------+
| Type | Description | Reference |
+------------+--------------------------+---------------+
| 0x00000001 | Error | Section 5.3 |
| | | |
| 0x0000000B | Vendor | Section 5.4.1 |
| | | |
| 0x00000002 | Acceptor name request | Section 5.4.2 |
| | | |
| 0x00000003 | Acceptor name response | Section 5.4.3 |
| | | |
| 0x00000005 | EAP request | Section 5.5.1 |
| | | |
| 0x00000004 | EAP response | Section 5.5.2 |
| | | |
| 0x0000000C | Flags | Section 5.6.1 |
| | | |
| 0x00000006 | GSS-API channel bindings | Section 5.6.2 |
| | | |
| 0x0000000D | Initiator MIC | Section 5.6.3 |
| | | |
| 0x0000000E | Acceptor MIC | Section 5.6.3 |
+------------+--------------------------+---------------+
Hartman & Howlett Expires May 2, 2012 [Page 29]
Internet-Draft EAP GSS-API October 2011
8.3. RADIUS Attribute Assignments
XXX register RADIUS attributes.
8.4. GSS EAP Errors
A new subregistry is created in the GSS EAP parameters registry
titled "Error Codes". XXX fill in minor statuses.
Hartman & Howlett Expires May 2, 2012 [Page 30]
Internet-Draft EAP GSS-API October 2011
9. Security Considerations
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.
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.
As discussed in Section 4, 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
[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.
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. For this
reason, implementations are required to implement and use EAP channel
binding; see Section 3 for details.
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.
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
Hartman & Howlett Expires May 2, 2012 [Page 31]
Internet-Draft EAP GSS-API October 2011
the IDP and RP is critical to per-message security and verification
of GSS-API channel binding [RFC5056]. Mechanisms such as RADIUS over
TLS [I-D.ietf-radext-radsec] provide significantly better protection
of key material than the base RADIUS specification.
Hartman & Howlett Expires May 2, 2012 [Page 32]
Internet-Draft EAP GSS-API October 2011
10. References
10.1. Normative References
[GSS-IANA]
IANA, "GSS-API Service Name Registry", <http://
www.iana.org/assignments/gssapi-service-names/
gssapi-service-names.xhtml>.
[I-D.ietf-emu-chbind]
Hartman, S., Clancy, T., and K. Hoeper, "Channel Binding
Support for EAP Methods", draft-ietf-emu-chbind-10 (work
in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
C-bindings", RFC 2744, January 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Hartman & Howlett Expires May 2, 2012 [Page 33]
Internet-Draft EAP GSS-API October 2011
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5554] Williams, N., "Clarifications and Extensions to the
Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554,
May 2009.
10.2. Informative References
[I-D.ietf-krb-wg-gss-cb-hash-agility]
Emery, S., "Kerberos Version 5 GSS-API Channel Binding
Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility-08
(work in progress), October 2011.
[I-D.ietf-radext-radsec]
Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"TLS encryption for RADIUS", draft-ietf-radext-radsec-09
(work in progress), July 2011.
[I-D.lear-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., and E. Lear,
"Application Bridging for Federated Access Beyond Web
(ABFAB) Architecture", draft-lear-abfab-arch-02 (work in
progress), March 2011.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure
Hartman & Howlett Expires May 2, 2012 [Page 34]
Internet-Draft EAP GSS-API October 2011
Shell (SSH) Protocol", RFC 4462, May 2006.
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service
Application Program Interface (GSS-API)
Internationalization and Domain-Based Service Names and
Name Type", RFC 5178, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
Hartman & Howlett Expires May 2, 2012 [Page 35]
Internet-Draft EAP GSS-API October 2011
Authors' Addresses
Sam Hartman (editor)
Painless Security
Email: hartmans-ietf@mit.edu
Josh Howlett
JANET(UK)
Email: josh.howlett@ja.net
Hartman & Howlett Expires May 2, 2012 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-23 09:08:21 |