Network Working Group J. Salowey
Internet-Draft Cisco Systems
Expires: December 28, 2005 June 26, 2005
Generally Useful Authentication Mechanisms (GUAM)
draft-salowey-guam-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Generic Security Services API (GSS-API), the Simple Authentication
and Security Layer (SASL), the Extensible Authentication Protocol
(EAP) and Transport Layer Security (TLS) are examples of four
different security frameworks within the IETF. Each of these
frameworks have evolved separately towards a common goal of
authentication and establishing a cryptographic context. They
support different types of security mechanisms and have historically
evolved to integrate with different security infrastructures. This
document discusses their similarities and differences and how these
Salowey Expires December 28, 2005 [Page 1]
Internet-Draft GUAM June 2005
security mechanisms might start to converge into a more uniform
approach involving generally useful authentication mechanisms that
can be used in any of these frameworks with a variety of different
security infrastructures.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Why unify mechanisms? . . . . . . . . . . . . . . . . . . 5
2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Survey of Authentication Mechanism Frameworks . . . . . . . 7
3.1 GSS-API . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Transport Layer Security . . . . . . . . . . . . . . . . . 12
3.5 Integration with Security Infrastructures . . . . . . . . 13
3.5.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.2 Public Key Infrastructure . . . . . . . . . . . . . . 13
3.5.3 Authentication Authorization and Accounting (AAA)
Services . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Framework Summary . . . . . . . . . . . . . . . . . . . . 15
4. Recommendations for Unifying Mechanisms . . . . . . . . . . 18
4.1 GUAM Mechanism requirements . . . . . . . . . . . . . . . 18
4.1.1 Mutual Authentication . . . . . . . . . . . . . . . . 18
4.1.2 Key Material Access and Security Layer . . . . . . . . 18
4.1.3 Channel Binding (GSS-API) . . . . . . . . . . . . . . 19
4.1.4 Cryptographic Binding . . . . . . . . . . . . . . . . 19
4.1.5 Channel Bindings (EAP) . . . . . . . . . . . . . . . . 19
4.1.6 Mechanism Naming . . . . . . . . . . . . . . . . . . . 19
4.1.7 Identity and Naming . . . . . . . . . . . . . . . . . 20
4.1.8 Mechanism Initiation . . . . . . . . . . . . . . . . . 20
4.1.9 Additional Security Properties . . . . . . . . . . . . 20
4.1.10 Authentication infrastructure integration . . . . . 20
4.2 GUAM Framework Enhancements . . . . . . . . . . . . . . . 21
4.2.1 GSS-API . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 SASL . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 EAP . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.4 TLS . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5 Security Layer . . . . . . . . . . . . . . . . . . . . 22
4.2.6 Negotiation . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Mechanism Gateways . . . . . . . . . . . . . . . . . . 22
4.2.8 Name Mapping . . . . . . . . . . . . . . . . . . . . . 23
4.3 Recommended GUAM Mechanisms . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . 24
5.1 Lying NAS . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Cryptographic binding between mechanisms . . . . . . . . . 24
5.3 Clear text passwords and PAP . . . . . . . . . . . . . . . 24
Salowey Expires December 28, 2005 [Page 2]
Internet-Draft GUAM June 2005
5.4 Exporting Contexts . . . . . . . . . . . . . . . . . . . . 25
5.5 Unauthenticated Identities . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1 Normative References . . . . . . . . . . . . . . . . . . . 28
8.2 Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 31
Salowey Expires December 28, 2005 [Page 3]
Internet-Draft GUAM June 2005
1. 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].
Salowey Expires December 28, 2005 [Page 4]
Internet-Draft GUAM June 2005
2. Introduction
There are many authentication technologies available in the IETF.
This memo specifically focuses on the security frameworks of GSS-API
[RFC2743], SASL [RFC2222], EAP [RFC3748] and TLS [RFC2246]. Each of
these frameworks have evolved somewhat independently towards the same
goal of authentication and cryptographic context establishment.
Historically, though not by design, they support different types of
authentication mechanisms and focus on integrating with different
security infrastructures. This has led to some confusion and
fragmentation within the IETF community. Authentication mechanisms
available to one user community are not available to another leading
to decreased deployment or duplication of effort.
This document examines these four frameworks to identify their
similarities and differences. It also looks at three commonly used
security infrastructures: Kerberos, PKI and AAA. It then provides
suggestions for development of new and/or existing mechanisms to
enable use in any of these frameworks. This set of Generally Usable
Authentication Mechanisms (GUAM) will enable broader use of
authentication mechanisms and infrastructures across the Internet
community.
There are other authentication frameworks used within the IETF such
as those used in IKE, SSH, HTTP and SMIME. GUAM mechanisms may not
be able to easily replace all of these uses, but they provide a
starting point for unifying frameworks used to establish an
authenticated cryptographic context.
2.1 Why unify mechanisms?
o The actual mechanisms in each of these frameworks actually have
very similar goals of authentication and establishing a
cryptographic context. In many cases frameworks are developing
new functionality that bring them closer together. This document
will hopefully help accelerate this process of convergence.
o There is pressure to adopt a particular framework because of the
set of mechanisms available not because of the capabilities and
upper-layer interface of the framework. We should be in a
situation where the choice on mechanism was dictated by the
deployment requirements and the choice of framework dictated by
protocol design and implementation simplicity.
o There is a duplication of effort in the development of security
mechanism that support similar credential types and
infrastructures. This is problematic because the development of
security mechanisms is both difficult and time consuming. It
Salowey Expires December 28, 2005 [Page 5]
Internet-Draft GUAM June 2005
would be good to leverage the work and expertise required for
developing a mechanism across all the frameworks.
o Often the cost of deploying a security mechanism is in the
infrastructure and not the implementation of the mechanism itself.
There limited set of mechanisms available to particular frameworks
makes the coordination and administration of security between
applications that use different frameworks more difficult.
2.2 Terminology
TODO: define terms like security framework, authentication mechanism,
security mechanism, security context, security token, ...
Salowey Expires December 28, 2005 [Page 6]
Internet-Draft GUAM June 2005
3. Survey of Authentication Mechanism Frameworks
This memo specifically focuses on the authentication frameworks of
GSS-API [RFC2743], SASL [RFC2222], EAP [RFC3748] and TLS [RFC2246].
A broader survey of authentication mechanisms has been collected in
[I-D.iab-auth-mech].
3.1 GSS-API
The Generic Security Service Application Programming Interface (GSS-
API) is defined as version 1 in [RFC1508] and version 2 in [RFC2743].
It defines an API to access security services which may be provided
by different underlying security mechanism technologies. This allows
an application written to the GSS-API to adjust to different
mechanism requirements in different environments and therefore the
GSS-API does not define security protocols. In GSS-API peers
exchange data, called security tokens, to establish a security
context which can provide further security services. The GSS-API is
independent of transports and application protocols and therefore
does not provide a means to carry security tokens in a protocol, it
just provides an API to generate and process these tokens. GSS-API
requires the application to provide fragmentation support and framing
of tokens. A goal of the GSS-API is to support a wide variety of
applications and environments.
The GSS-API defines an interface to obtain security tokens that are
to be exchanged between two parties to establish a security context.
The context initiator always issues the first token. The security
context can be used to obtain the name of the authenticated parties
and to perform per-message protection of integrity and
confidentiality. The underlying authentication mechanisms may
require several token exchanges until the context is complete and all
the services are ready. Some security services such as integrity and
confidentiality may be available before the context is complete.
Mechanism negotiation is achieved through the use of special
mechanisms designed for negotiation. One such mechanism is the
simple and protected GSS-API negotiation mechanism (SPNEGO) defined
in [I-D.ietf-kitten-2478bis]. Some applications, such as SSH and
NFS, using GSS-API also provide their own mechanism for negotiating
security mechanism in addition to GSS-API.
GSS-API mechanisms can support mutual authentication where both
parties are explicitly authenticated, or forms of authentication
where either or both parties can remain anonymous. In version 2 GSS-
API did not provide direct access to cryptographic key material from
the underlying security context, however the resulting security
context can provide per-message security services such as
confidentiality, integrity protection, replay detection and out-of-
Salowey Expires December 28, 2005 [Page 7]
Internet-Draft GUAM June 2005
sequence detection. Applications can rekey the security layer by
calling the context establishment APIs. The GSS-API provides support
for channel binding to allow data from lower layers to be bound to
the context exchange. The usage GSS-API style channel bindings will
be identified by "channel bindings (GSS_API)" to differentiate it
from EAP channel bindings which are a slightly different usage. The
underlying security context created by GSS_API has a lifetime
associated with it.
GSS-API uses OIDs to represent mechanisms. GSS-API provides a
formalized framework for representing principal names as mechanism
independent quantities by defining name types. Some example name
types are Host-based service name and user names. GSS-API does not
specify how an application should make use of names, but it does make
available canonical name formats that can be used to compare two
names for equality. Naming is a complex issue that needs to be
further investigated across all the various mechanism frameworks.
There are only a few standard GSS-API mechanisms that are defined in
the IETF. These include Kerberos [I-D.ietf-krb-wg-gssapi-cfx],
Simple Public Key Mechanism (SPKM) [RFC2025], Low Infrastructure
Public Key Mechanism using SPKM [RFC2847]. The only mechanism that
is currently widely implemented in different environments and shown
to be interoperable is the Kerberos mechanism. The initial context
token emitted by a context initiator is required to be prefixed with
a small header containing the ASN.1 OID of the mechanism that
produced the token, other tokens can have any format. GSS-API
mechanisms are not required to support all of the services and
features available in the GSS-API. GSS-API does not provide full
credential management functionality therefore mechanisms are expected
to acquire their initial credentials through some other process. In
some cases, such as Kerberos, initial credential acquisition may
require network requests.
There is ongoing work on GSS-API version 3 [I-D.williams-gssapi-v3-
guide-to]. Some of the enhancements include a means to obtain key
material through a PRF associated with the security context, the
ability to stack multiple mechanisms, and extensions to naming to
support attributes authenticated during the context establishment.
This ongoing work may make it easier for GSSAPIv3 to become the
recommended API for GUAM mechanisms.
The GSS-API provides access to a wider variety of security
functionality. However, its deployment has been limited to specific
environments where its advanced functionality is required. In other
environments with simpler requirements the GSS-API has not seen great
uptake. This is due in part to the limited set of mechanisms
available and to the perceived complexity of the framework. An
Salowey Expires December 28, 2005 [Page 8]
Internet-Draft GUAM June 2005
implementation of the GSS-API may have significant complexity, but it
should be noted that it is possible to write mechanisms that are wire
compatible with GSS-API mechanisms that do not implement the GSS-API
framework on their local platform.
3.2 SASL
The Simple Authentication and Security Layer (SASL) is defined in
[RFC2222]. This specification provided a simpler alternative to GSS-
API for incorporating security functionality into connection oriented
applications. As in GSS-API a SASL exchange requires the exchange on
an arbitrary number of security tokens between two entities. In SASL
either party can send the initial security token. SASL provides a
basic unprotected mechanism negotiation scheme.
SASL is primarily focused on authenticating a user to a server,
however some SASL mechanisms do provide mutual authentication. It is
also possible to support anonymous authentication with the Anonymous
SASL mechanism. SASL does not provide access to key material
exchanged during the authentication, but it can negotiate the use of
a security layer to provide confidentiality and integrity. SASL
security layer is more stream oriented as opposed to GSS-API's
message oriented security services. SASL security layers do not
provide re-keying. SASL can also reference an external security
layer using the "EXTERNAL" mechanism. It is common for SASL
implementations to rely upon TLS as an external security layer for
data protection and sometimes authentication. SASL does not have an
equivalent to GSS-API channel bindings for binding the SASL exchange
to an underlying security channel.
SASL mechanisms are named using 20 character names from a restricted
ASCII character set. SASL also specifies that an mechanism may
transmit an authorization name to represent a name that an
authenticated principal wants to use for authorization purposes. The
mechanism or SASL layer must validate that the authenticated name is
authorized to use the authorization name. SASL does not provide any
specific name types and applications must be prepared to process
names of different types from different mechanisms.
SASL supports a wide variety of authentication mechanisms including
PLAIN user name and password [RFC2595], One-Time password [RFC2444]
and digest challenge response authentication [RFC2831]. SASL also
supports GSS-API mechanisms as a SASL mechanism so that any GSS-API
mechanism can be used as a SASL mechanism. This makes the SASL
mechanism space a superset of the GSS-API mechanism space. SASL
provides less advanced functionality than GSS-API, but it appears to
be easier to integrate into applications. The SASL specification
describes the requirements on an applications protocol profile that
Salowey Expires December 28, 2005 [Page 9]
Internet-Draft GUAM June 2005
uses SASL. Protocols such as IMAP and LDAP have specified SASL as a
means to integrate security into their applications.
3.3 EAP
The Extensible Authentication Protocol (EAP) is defined in [RFC3748].
This specification was originally developed as a way to introduce
support for different authentication mechanisms within the PPP
protocol. EAP has since be applied to other environments such as
wired and wireless LAN environments. EAP has largely been applied to
network access authentication.
As in SASL and GSS-API in an EAP mechanism specific messages are
exchanged between two parties until a security context is
established. EAP defines a slightly different model which involves 3
parties an EAP Peer, an EAP Authenticator and an EAP Server. It is
important to note however that EAP method protocols are
authentication protocols between the EAP Peer and EAP Server, the EAP
Authenticator acts in a pass-through mode with respect to EAP
messages. The ultimate goal of an EAP system is often to establish a
security context between a process on the device hosting the EAP Peer
and a process on a device hosting and EAP Authenticator, however this
cannot be done using EAP alone. . Once the EAP method completes
between the EAP Peer and EAP Server security context information from
the EAP method execution is made available to the EAP Authenticator,
which in turn makes the context information available to the layer
invoking the EAP framework. The context transfer happens outside the
EAP protocol. The EAP Server and EAP Authenticator may be
implemented on the same physical device or on a different physical
devices.In some cases the EAP-server is accessed through a AAA
subsystem in which case the AAA subsystem may augment the transferred
context with additional information that it is important for the
process receiving the context to know. Using the key material from
the transferred context the device hosting the EAP-Peer and the
device hosting the EAP-Authenticator can establish a security
association. This security association does not involve EAP
directly, but rather involves a security association protocol
external to EAP that runs between the process hosting the EAP Peer
and the process hosting EAP Authenticator.
The predominant use cases driving the design and implementation of
EAP are associated with network access. Traditionally each the
entity hosting the EAP-Authenticator is call a network access server
(NAS) and the EAP Server is hosed on a AAA server. EAP is popular in
environments where a AAA infrastructure is used and EAP provides an
extensible authentication interface into AAA servers. Having the EAP
Server remote from the authenticator allows for the network to add
support for different authentication mechanisms without having to
Salowey Expires December 28, 2005 [Page 10]
Internet-Draft GUAM June 2005
upgrade all the authenticators. Since in the basic case network
access servers all provide access to the same network services,
provide similar capabilities and are part of the same trusted
infrastructure the EAP Server and EAP Authenticator are often viewed
as the same logical entity even if they are implemented on different
physical devices. EAP mechanisms were originally designed to
authenticate to a realm and not to differentiate between different
authenticators in the same realm. There are proposals such as
[I-D.arkko-eap-service-identity-auth] that attempt to address this.
Unlike GSS-API and SASL, EAP does not provide support for security
layers, instead it provides access to keying material and other
context information derived from the EAP exchange. This key material
is typically provided to a process on the device hosting EAP
authenticator as described above. It is possible for security
associations with multiple entities to be seeded from a single EAP
exchange, however this is the subject of ongoing work.
The security considerations of [RFC3748] and [RFC4017] describe a
number of potential security properties that EAP methods may possess.
EAP does have a concept called "channel bindings" which will be
identified as "channel bindings (EAP)" in this document. It is
different than channel binding (GSS-API) except that the data
declared as channel binding values are expected to be exposed from
the mechanism. This allows for the EAP Peer to communicate
attributes to an EAP Server in a way that the EAP authenticator or
other third party cannot modify it. This provides a way for the EAP
server or and entity associated with the EAP Server to validate
information provided from the EAP Authenticator to the EAP Peer and
vice versa. This make channel bindings (EAP) more similar to
authenticated attributes or names. EAP also defines a concept called
"cryptographic binding" which attempts to provide assurance that
different authentication transactions carried out between two
entities actually occurred between those two entities and are not
compromised by a man in the middle. These two authentication
transactions may occur at different layers or they may occur
sequentially in the same layer. Channel bindings (GSS-API) are a
mechanism that can be used to achieve cryptographic binding.
Additional security properties defined in [RFC3748] include protected
ciphersuite negotiation, mutual authentication, integrity protection,
replay protection, key strength, dictionary attack resistance, fast
reconnect, session independence, identity protection, and protected
result indicators,
In the EAP model the first security token is sent to EAP Peer from
the EAP authenticator or EAP Server. EAP provides a basic level of
insecure mechanism negotiation. This can be enhanced by mechanism
specific negotiation which establishes a secure tunnel in which to
Salowey Expires December 28, 2005 [Page 11]
Internet-Draft GUAM June 2005
perform negotiation. These secure tunnel mechanisms can also be used
to chain mechanisms together. EAP provides an identity exchange
which may be independent of EAP mechanism. The identity is expressed
as an NAI defined in [RFC2486]. The identity is usually primarily
used for AAA routing and mechanism selection, an EAP mechanism may
arrive at a completely different authenticated identity.
There are only a few published EAP methods including EAP-MD5, EAP-OTP
and EAP-TLS. Of these only EAP-TLS derives keying material. There
are many more EAP methods deployed in the field that work with a wide
range of credential types from passwords to SIM based smart cards.
3.4 Transport Layer Security
Transport Layer Security (TLS) is a framework for providing
authenticated key exchange and security services at the "transport"
layer defined in [RFC2246]. Many applications use it as a way to
provide a security layer for the protection of stream oriented
application data. TLS has a large installed base and a wide variety
of implementations. Because of this it is starting to be seen in
other contexts as well such as DTLS for datagram applications and
EAP-TLS for network access scenarios.
TLS has a handshake protocol that provides a protected negotiation of
ciphersuites. A ciphersuite is an identifier for the combination of
an authenticated key exchange with bulk encryption and integrity
algorithms. The negotiation is initiated by the client and currently
has a fixed number of messages. TLS is often used primarily to
provide a security layer and is often deployed with just server
authentication. The security layer is stream oriented and is
typically implemented as a secure socket interface (hence the name
secure sockets layer, SSL, from which TLS was derived) making it easy
to integrate into TCP based applications. TLS does provide a
mechanism for re-keying the security layer. It is not typical for
TLS to provide key material externally, but EAP-TLS [RFC2716] has be
extended within to do this. TLS does not explicitly provide a
mechanism to bind to a lower layer or for an encapsulated layer to
bind to it. It is possible to use parameters from the handshake such
as the finished messages in channel bindings for security mechanism
that layer on top of TLS.
TLS was originally developed with ciphersuites that support X.509
certificates. It has modes that provide for anonymous, server side
authentication and mutual authentication. TLS also has ciphersuites
defined that support Kerberos credentials and shared secrets. TLS
does not deal explicitly with identities and these are left for each
ciphersuite to deal with.
Salowey Expires December 28, 2005 [Page 12]
Internet-Draft GUAM June 2005
3.5 Integration with Security Infrastructures
In order to make security solutions more scalable and manageable it
is common to make use of authentication services to increase
scalability and manageability. It is desirable for authentication
frameworks to integrate with these systems. This section looks at
three different authentication service infrastructure
infrastructures: Kerberos, PKI and AAA. Each of the frameworks
favors a particular type of infrastructure: GSS-API is associated
strongly with Kerberos, EAP is associated with AAA and TLS is often
associated with PKI. SASL is often used in a hybrid approach that
uses TLS for a security layer and another mechanism for client
authentication.
3.5.1 Kerberos
The Kerberos V network authentication [RFC1510] is an authentication
an key management system based on Needham-Schroeder protocol.
Kerberos is a true integrated 3 party protocol in which the trusted
third party server is a Key Distribution Center (KDC). Communication
with the KDC is not required for every authentication. GSS-API is
the preferred mechanism for applications to integrate with Kerberos.
This means that SASL can support Kerberos through its ability to use
GSS-API mechanisms. TLS does have Kerberos based ciphersuites
defined in [RFC2712], but it is somewhat out of date. EAP does not
currently have Kerberos integration. This is partially because
Kerberos mechanism is not ideally suited for network access
authentication since it requires access to the KDC to authenticate.
Some work has been done in this area in the past with the IAKERB GSS-
API mechanism and an EAP-GSS-API mechanism, but this work has
stalled.
3.5.2 Public Key Infrastructure
Public key infrastructure has several different forms, but the most
common is X.509 public key infrastructure. A profile for public key
certificate use for the Internet is available as [RFC3280]. In PKI
the trusted third party is a certificate authority (CA). The CA does
not typically participate directly in the authentication process.
[RFC2025] is a GSS-API mechanism that supports public key
credentials. TLS can use X.509 certificates for mutual
authentication. SASL does not currently have a public key mechanism
although some have been proposed and it can use an underlying TLS
session for authentication with public keys. The EAP-TLS mechanism
can use public key credentials for authentication and key exchange.
Salowey Expires December 28, 2005 [Page 13]
Internet-Draft GUAM June 2005
3.5.3 Authentication Authorization and Accounting (AAA) Services
The AAA model was originally developed to support network access
requirements. In a AAA system you typically have a network client
which is requesting access, a network access server, which hosts a
AAA client, that is providing access to the client and a AAA server
that is performing authentication, authorization and accounting
service for the network access server. A AAA server is expected to
be online to process authentication, accounting and authorization
requests. AAA services are typically implemented as RADIUS [RFC2865]
or Diameter [RFC3588] servers. The authentication interaction
usually consists of two protocols; an authentication protocol such as
EAP which executes between the network client and the AAA server and
a AAA protocol which executes between the network access server and
the AAA server. There is usually a third protocol, such a PPP, that
carries the authentication protocol between the network client and
the network access server. This model maps directly to the EAP
participants with the client hosting the EAP peer, the network access
server hosting the EAP authenticator and the AAA server hosting the
EAP server. In this model the network client authenticates and
establishes an authenticated context with the AAA server and the AAA
server uses a separate security association with the AAA client under
which to transmit key material and other context data. The network
access server then uses this data to establish a security association
with the network access client. As in the EAP model the AAA client
and AAA server are often viewed as the same logical entity from the
point of view of the network access client.
AAA servers originally started as services that maintained shared
secrets for clients. This capability has evolved over time from
support for clear text password based protocols, to challenge
response protocols, to protocols that are based on public key
credentials instead of shared secrets. One method for integrating
with AAA servers is to use them as validators of a clear text
password. This is often referred to as password authentication
protocol or PAP. There are mechanisms such as GSS-API mechanisms
such as LIPKEY, [RFC2847], plain in SASL, and GTC in EAP which
involve sending a password between the client and server. Although
the password may be transmitted to the network access server in
encrypted form in these schemes it is visible and vulnerable at this
point. The use of one time password and token cards can help
mitigate the risk. In this case the authentication protocol does not
provide mutual authentication or authorization between the client and
AAA server. The second method for integration uses the AAA server as
an endpoint of the authentication communication. Examples of these
types of protocols that are supported by AAA are CHAP, Digest
Authentication and EAP. This is the mechanism that EAP uses to
integrate with the AAA server and is defined for both RADIUS
Salowey Expires December 28, 2005 [Page 14]
Internet-Draft GUAM June 2005
[RFC3579] and Diameter. SASL supports Digest authentication
[I-D.ietf-radext-digest-auth] which can back end directly into AAA
using RADIUS or Diameter attributes. In this case mutual
authentication between network access client and AAA Server can be
achieved through the authentication protocol.
3.6 Framework Summary
All of the authentications frameworks described in this section have
similar goals of authentication and optional establishment of a
cryptographic context. They provide some different features and are
tuned to slightly different environments. These different
environments also influence the availability of different mechanisms
within each framework. The next section describes some of the
different capabilities of the various mechanisms.
Security Layer
A framework provides a security layer if it provides mechanisms to
protect the transfer of bulk data between peers after the context
has been established. GSS-API optionally provides this with wrap
and unwrap functions. SASL provides optional support for a
security layer. TLS always provides support for a security layer.
EAP does not support a security Layer.
Key Material Access
A framework may provide access to key material derived during the
authentication process. This is especially useful when the
framework is used in cases where a security layer is already
defined and needs to obtain keys through a certain mechanism. EAP
provides key material access. GSS-API v3 is working on an API to
a PRF, [I-D.ietf-kitten-gssapi-prf], which would provide similar
functionality. Basic TLS does not provide access to key material
although specific uses, such as EAP-TLS, obtain access to certain
key material derived from the master secret. SASL does not
provide access to key material.
Mechanism Negotiation
EAP and SASL provide a basic unprotected support for negotiating
mechanism which can be vulnerable to man-in-the-middle attacks.
GSS-API does not provide built-in support for mechanism
negotiation, however a specialized mechanism, SPNEGO, is available
for purpose of providing protected mechanism negotiation. EAP
also provides mechanisms such as PEAP which can be used to perform
Salowey Expires December 28, 2005 [Page 15]
Internet-Draft GUAM June 2005
protected negotiation of mechanisms. TLS provides a protected
mechanism to negotiate ciphersuites.
Channel Binding (GSS-API)
GSS-API provides formal support for channel bindings. Channel
bindings provide a mechanism to bind the current authentication
exchange to lower level parameters such as cryptographic keys or
addresses. In GSS-API channel bindings are usually validated
within the mechanism and are part of mechanism functionality. In
EAP there is a similar concept called crypto binding which is used
to bind chained mechanisms together. Mechanisms can also provide
quantities for channel binding in higher layers. EAP provides key
material which can help here. EAP also has discussed deriving a
name to identify the keying material derived from a specific
instance of method execution which may be useful in binding to
upper layers. GSSAPIv3 is specifying a PRF API which may be
helpful here. SASL does not support channel bindings.
Channel Binding (EAP)
EAP channel bindings are conveyed between the EAP Peer and EAP
Server and may contain information about the communication layer
between the entity hosting EAP Peer and the entity hosting EAP
Authenticator. EAP the channel bindings usually consist of
information that is best validated outside the EAP method so the
channel binding information is communicated external to the
method.
Mechanism Chaining
None of the frameworks directly support mechanism chaining. It is
possible for an application using one of the frameworks to define
a mechanism for chaining, but it would typically add complexity to
the application which the framework is trying to eliminate. GSS-
APIv3 has proposed support for stackable mechanisms [GSSSTACK] and
EAP has mechanisms such as [I-D.cam-winget-eap-fast] and
[I-D.funk-eap-ttls-v0] which allow for the chaining of multiple
authentication mechanisms. The ability to chain can introduce
complexity into the framework and can increase the difficult to
analyze the security of the resulting system. However mechanism
chaining can provide powerful building blocks to add functionality
into existing mechanisms and environments in a uniform way. For
example a mechanism can be created with the purpose of providing
encryption and integrity protection of messages. This mechanism
Salowey Expires December 28, 2005 [Page 16]
Internet-Draft GUAM June 2005
could then be chained to any mechanism that provides key material
for external use to provide protection for application data.
Mechanism Naming
All mechanisms provide a name space for identifying mechanisms
which is extensible. A mapping for GSS-API mechanisms into the
SASL name space has been defined. It should also be possible to
create mappings for EAP mechanisms into the GSS-API name space.
Principal Naming
All of the frameworks deal with principal naming to a certain
degree. GSS-API provides the facility for the initiator to
specifically identify the target with which it wants to establish
a security context with. The form of the name that is often used
is host based service name. This name form is also used somewhat
in SASL although it is less formal. EAP uses the NAI to name
principals; however this more often used for message routing than
actual identification. The target in EAP is often a "realm" or
"network" instead of an individual entity. SASL defines an
additional quantity called an authorization identity which can be
an alias or sub-name of the authenticated name specified in the
application protocol.
AAA integration
AAA integration is called out specifically here because
interaction with the server is required at the time of the
authentication. While this mechanism has some disadvantages when
compared with PKI or Kerberos models it is widely deployed and
used. EAP has direct support for integration with AAA, while only
certain SASL and GSS-API mechanisms can interface with a AAA
server.
Salowey Expires December 28, 2005 [Page 17]
Internet-Draft GUAM June 2005
4. Recommendations for Unifying Mechanisms
Each of the frameworks described has a particular scope of for which
it is most applicable. SASL is used in application environments, EAP
in network access environments and GSS-API in applications with
advanced security requirements. Even though the scope of
applicability is different the goals of the frameworks are very
similar. One approach could be to define a new authentication
framework that could be a superset of all the above frameworks. This
would be problematic since it introduces yet another framework which
requires not only a new set of mechanisms, but also would require
modifications to the consumers of these mechanisms as well. Instead
this document recommends that new mechanisms from this point on are
developed so they are generally usable in any of these frameworks.
The components of each of the systems can be mapped directly to one
another. The SASL client, EAP Peer, TLS client and GSS-API initiator
all perform the same role. The SASL Server, EAP Server, TLS server
and GSS-API acceptor all perform the same role.
4.1 GUAM Mechanism requirements
The following sections make some recommendations on requirements for
these mechanisms. A mechanism which adheres to these recommendations
would be a generally useful authentication mechanism (GUAM).
4.1.1 Mutual Authentication
A GUAM mechanism MUST provide the capability for mutual
authentication of two communicating entities. In some cases one or
more of the entities authenticated may be a "realm" instead of an
individual entity. It MAY also provide the ability for either or
both parties of the communication to remain anonymous or
unauthenticated. It may also provide a mechanism to protect the
privacy of the identity of one or more of the parties involved from
external parties.
4.1.2 Key Material Access and Security Layer
A GUAM mechanism MUST provide access to some key material derived
from the authentication exchange. Access to key material that can be
defined as the EAP MSK and EMSK MUST be provided. Access to
additional key material should be provided. Key material MUST be
generated such that keys are cryptographically independent from one
another and keys used during the authentication and in the security
layer. Key material MUST be bound to the authentication exchange and
the two parties MUST derive the same keys regardless of what order
they are requested. Access to certain keys may be restricted or
Salowey Expires December 28, 2005 [Page 18]
Internet-Draft GUAM June 2005
controlled. A mechanism MAY provide a security layer. If a
mechanism does not provide a security layer then it MUST derive an
additional security layer master key. This master key can be used to
key a generic message protection layer. (Is this key equivalent to
the EAP MSK/EMSK?). Note that GSS-API is defining an API to access
key material from GSS-API mechanisms in [I-D.ietf-kitten-gssapi-prf]
4.1.3 Channel Binding (GSS-API)
A GUAM mechanism MUST provide mechanisms to achieve channel binding.
This means a mechanism MUST provide a mechanism to bind underlying
cryptographic key material or other session related parameters to the
authentication exchange in a way that can be verified within the
mechanism (i.e. The mechanism does not know the meaning of the data,
just that the data used in the channel binding on both sides is the
same). This is to support channel bindings as defined in the GSS-
API.
A mechanism MUST also provide session data suitable for use in
identifying a particular instance of a mechanisms execution and to
serve as input to the channel bindings for another mechanism to
facilitate chaining and layering of mechanisms. This is to identify
a particular instance of an mechanism execution and the resulting
context.
4.1.4 Cryptographic Binding
A mechanism to achieve cryptographic binding could use the Channel
Bindings (GSS-API) capability.
4.1.5 Channel Bindings (EAP)
A GUAM mechanism MUST provide mechanisms to carry attribute data
within the authentication exchange. This is to allow for EAP style
channel bindings were authenticated data is exported for validation
outside the mechanism.
4.1.6 Mechanism Naming
A GUAM mechanism MUST have a GSS-API OID, an EAP mechanism ID and a
SASL name assigned. This allows the mechanism to be easily used in
any of these environments. It is possible to create a automatic
mapping between the name spaces. A particular EAP Vendor-ID could be
assigned to GUAM mechanisms and a base GSS-API OID could be assigned
to GUAM mechanisms. Then the mechanism would be identified by an
assigned 4 byte integer which is the EAP ID or the completion of the
GSS-API OID. Then the mapping between GSS-API mechanism names and
SASL mechanism names can be used to create SASL names.
Salowey Expires December 28, 2005 [Page 19]
Internet-Draft GUAM June 2005
4.1.7 Identity and Naming
There are several different types of names used in the various
frameworks. Mechanisms must have ways of exporting authenticated
names for the initiator and acceptor of the conversation.
EAP defines an EAP-Identity Response which is external to the
mechanism. Although the identity response may contain a name and a
realm it is primarily used for routing authentication messages so it
may have little no relation to the actual authenticated name. It
does provide a means for the EAP-Peer to specify the realm it wishes
to authenticate to.
SASL defines an Authorization identity which may be asserted by the
imitator of the conversation in addition to the authenticated name.
This name is to be used by the acceptor for authorization purposes.
A GUAM mechanism SHOULD provide support for transmitting the
authorization name. Authorization names need to have their mapping
to authenticated names validated. While this could be done as part
of the mechanism it may be advantageous to define a mapping service
to provide some abstraction between the mechanism and application
specific names.
4.1.8 Mechanism Initiation
It MUST be possible for an GUAM mechanism to be initiated by either
side of the conversation. This MAY be achieved by adding an "empty"
message to an existing protocol.
4.1.9 Additional Security Properties
[RFC3748] and [RFC4017] describe some security requirements for EAP
mechanisms. EAP mechanism are required to make claims about their
support for the various properties listed. GUAM mechanism should
also document which properties they are designed to meet. GUAM
mechanism SHOULD support the following: generation of keying
material, mutual authentication, shared state equivalence, replay
protection, integrity protection, cryptographic binding, session
independence, and any ciphersuite negotiation should be protected.
It is also desirable for GUAM mechanisms to support the following:
resistance to dictionary attacks, fragmentation, identity privacy,
confidentiality, channel bindings (EAP).
4.1.10 Authentication infrastructure integration
Different authentication infrastructures have different requirements
for access to third parties during authentication. In cases such as
Kerberos and AAA where the third party must be contacted for initial
Salowey Expires December 28, 2005 [Page 20]
Internet-Draft GUAM June 2005
authentication before a security context is established between peers
special consideration is needed. Since communication with the third
party server may not be available a GUAM mechanism SHOULD provide a
means to carry out this initial authentication within the
authentication mechanism exchange so it is possible to support
network access authentication. An example of this was specified in
IAKERB for authentication. In order to interface SASL and GSS-API
mechanism into a AAA server then EAP can be used as the interface
into AAA and specialized mechanisms or framework enhancements could
be used to take the exported EAP-AAA security context into a SASL or
GSS-API context. (This would look like GSS-API between client and
server, and EAP between server and AAA server, the context exported
from the AAA server to the AAA client could then be used to create a
GSS-API security context. Perhaps this could be done using stackable
mechanisms. The client would probably have to know that a AAA server
was in use.)
4.2 GUAM Framework Enhancements
This section discusses enhancements for the various frameworks to
support and take full advantage of the GUAM mechanisms. None of
these enhancements are required, but they described are here are to
enable useful functionality across all the frameworks.
4.2.1 GSS-API
GSS-API SHOULD provide the API to access all GUAM functionality.
o API to PRF to retrieve keys
o API to send and receive channel binding (EAP) data as part of
authentication. This might be done as part of naming
enhancements.
o Enhancements for exporting and value that identifies a particular
execution of the mechanism.
o Enhancements for importing an EAP-AAA context.
o Enhancement to naming to identify realms.
4.2.2 SASL
For the most part SASL is trying to provide a simpler interface to
authentication so additional enhancements would probably be
undesirable. Unless there are serious security or usability
implications the interface should remain unchanged. SASL
Salowey Expires December 28, 2005 [Page 21]
Internet-Draft GUAM June 2005
functionality should be described in terms of GSS-API calls to GUAM
mechanisms. Some existing SASL mechanisms may not be GUAM
mechanisms. It would be good to extend SASL in a backwards
compatible way to support features such as channel bindings,
mechanism execution instance identifiers, and EAP-AAA context
integration.
4.2.3 EAP
Similar to SASL EAP is already widely deployed so changes are costly.
Unless there are serious security or usability implications the
interface should remain unchanged. EAP functionality should be
described in terms of GSS-API calls to a GUAM mechanism. Some
existing EAP mechanisms may not be GUAM mechanisms.
4.2.4 TLS
TLS is already widely deployed so changes are costly. Unless there
are serious security or usability implications the interface should
remain unchanged. Because it is so successful it is probably good to
develop a GUAM mechanism based on TLS.
4.2.5 Security Layer
It may be advantageous to provide a generic security layer/ per-
message protection that can be used by mechanisms that generate keys,
but do not specify a security layer.
4.2.6 Negotiation
It is undesirable to have multiple layers of negotiation, especially
when the different negotiation mechanisms have different security
properties. In general secure negotiation mechanisms should be
favored over insecure ones. Recursive negotiation of methods such as
TLS negotiation a GUAM mechanism which in turn is based on TLS should
be avoided.
4.2.7 Mechanism Gateways
Mechanism gateways provide a way to use one mechanism in another
framework. In general the GUAM provide a consistent set of
functionality in all frameworks so they should work well in mechanism
gateways. This is already possible to map GSS-API mechanisms to
SASL. It would be easy to define mechanisms to map EAP to GSS-API
and probably vice-versa. A set of GSS-API/GUAM ciphersuites should
also be developed for TLS to make it easier for TLS to make use of
different authentication mechanisms and infrastructures.
Salowey Expires December 28, 2005 [Page 22]
Internet-Draft GUAM June 2005
4.2.8 Name Mapping
A name mapping service may be useful to provide an authorized mapping
between authenticated names and attributes and names that are usable
by an application for authorization and auditing.
4.3 Recommended GUAM Mechanisms
The following mechanisms may be good candidates for GUAM mechanisms:
o A TLS based mechanisms similar to EAP-TLS
o A digest authentication mechanism
o A Kerberos V mechanism that provided in-band initial
authentication (i.e. In band AS and TGS exchanges)
o A hybrid public key/protected password mechanism such as one that
allows a one time password to be sent within a TLS channel
o A pre-shared key mechanism.
o An SRP based mechanism
Salowey Expires December 28, 2005 [Page 23]
Internet-Draft GUAM June 2005
5. Security Considerations
5.1 Lying NAS
Traditionally in this case all services providing network access
(network access server or NAS) provide the same server, therefore a
client requesting network access was not concerned as to which NAS
they were talking to, but rather that they were talking to a NAS that
was an authorized member of the network. The means the client may
know the identity of the AAA server or network, but often cannot
differentiate between one service and another. This can cause
problems when different services can be authorized to provide
different resources or functions for clients. This problem is often
referred to as the lying network access server (NAS) problem. It is
possible for the service to advertise capabilities that it is not
authorized for and the client would not be able to catch this. This
problem is not unique to EAP, any mechanism that integrates with a
AAA server (or other types of back end servers) may have this
problem. In this case it is often necessary for the supplicant to
inform the AAA server of the claimed identity and authorizations of
the service, or to inform the client what capabilities are authorized
to a particular service. The AAA server or client can then verify
that the service is authorized to advertise these resources.
This problem is not unique to AAA and EAP. In SASL digest
authentication a user is typically authenticated to a "realm." There
is no way through the mechanism itself to determine which server in
the realm the client is communicating with.
5.2 Cryptographic binding between mechanisms
When more than one authentication transaction is taking place it is
often a good idea to bind one authentication transaction to another
to ensure that the endpoints are the same in both cases. This can
help to avoid some types man-in-the-middle attacks. Channel Bindings
(GSS-API) can be used for this purpose.
5.3 Clear text passwords and PAP
Clear text passwords are commonly used authentication mechanism on
the Internet today. Increasingly they are used within a secure
tunnel, such as one provided by TLS, which is an improvement.
However the use of clear text passwords is still problematic since it
exposes the clear text password to entities that may not need to know
the password thereby increasing the exposure of the shared secret.
In addition when a clear text password is used in RADIUS it is sent
in a PAP authentication request. RADIUS PAP may provide insufficient
Salowey Expires December 28, 2005 [Page 24]
Internet-Draft GUAM June 2005
protection unless it is used with additional security measures that
prevent password guessing and modification attacks.
5.4 Exporting Contexts
Security contexts may contains sensitive information such as
cryptographic keys so care should be taken when exporting them.
5.5 Unauthenticated Identities
Some of the frameworks discussed support the communication of
identities outside of the authentication exchange. It is important
to realize that these identities are unauthenticated and may have no
relation to the authenticated identity. These identities should be
used with caution.
Salowey Expires December 28, 2005 [Page 25]
Internet-Draft GUAM June 2005
6. IANA Considerations
To be determined.
Salowey Expires December 28, 2005 [Page 26]
Internet-Draft GUAM June 2005
7. Acknowledgements
Nicolas Williams and Sam Hartman provided valuable discussions and
feedback that went into the preparation of this document.
Salowey Expires December 28, 2005 [Page 27]
Internet-Draft GUAM June 2005
8. References
8.1 Normative References
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
8.2 Informative References
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-eap-service-identity-auth-02 (work in
progress), May 2005.
[I-D.cam-winget-eap-fast]
Salowey, J., "EAP Flexible Authentication via Secure
Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work
in progress), April 2005.
[I-D.funk-eap-ttls-v0]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol Version 0 (EAP-TTLSv0)",
draft-funk-eap-ttls-v0-00 (work in progress),
February 2005.
[I-D.iab-auth-mech]
Rescorla, E., "A Survey of Authentication Mechanisms",
draft-iab-auth-mech-03 (work in progress), March 2004.
[I-D.ietf-kitten-2478bis]
Zhu, L., "The Simple and Protected GSS-API Negotiation
Mechanism", draft-ietf-kitten-2478bis-05 (work in
progress), January 2005.
[I-D.ietf-kitten-gssapi-prf]
Williams, N., "A PRF API extension for the GSS-API",
draft-ietf-kitten-gssapi-prf-04 (work in progress),
Salowey Expires December 28, 2005 [Page 28]
Internet-Draft GUAM June 2005
June 2005.
[I-D.ietf-krb-wg-gssapi-cfx]
Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 GSS-API Mechanism: Version 2",
draft-ietf-krb-wg-gssapi-cfx-07 (work in progress),
March 2004.
[I-D.ietf-radext-digest-auth]
Sterman, B., "RADIUS Extension for Digest Authentication",
draft-ietf-radext-digest-auth-02 (work in progress),
April 2005.
[I-D.williams-gssapi-v3-guide-to]
Williams, N., "Guide to the GSS-APIv3",
draft-williams-gssapi-v3-guide-to-00 (work in progress),
October 2004.
[RFC1508] Linn, J., "Generic Security Service Application Program
Interface", RFC 1508, September 1993.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2444] Newman, C., "The One-Time-Password SASL Mechanism",
RFC 2444, October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
Salowey Expires December 28, 2005 [Page 29]
Internet-Draft GUAM June 2005
[RFC2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key
Mechanism Using SPKM", RFC 2847, June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
Author's Address
Joseph Salowey
Cisco Systems
Email: jsalowey@cisco.com
Salowey Expires December 28, 2005 [Page 30]
Internet-Draft GUAM June 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Salowey Expires December 28, 2005 [Page 31]