One document matched: draft-salowey-guam-mech-00.txt
Network Working Group J. Salowey
Internet-Draft Cisco Systems
Expires: July 7, 2006 January 3, 2006
Guidelines for Creating Generally Useful Authentication Mechanisms
(GUAM)
draft-salowey-guam-mech-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 July 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Generic Security Services API (GSS-API), the Simple Authentication
and Security Layer (SASL), and the Extensible Authentication Protocol
(EAP) are three authentication and frameworks used within the IETF
that have similar goals. This document describes guidelines for
creating authentication mechanisms that are generally usable in any
of these frameworks.
Salowey Expires July 7, 2006 [Page 1]
Internet-Draft GUAM Mechanism Guidelines January 2006
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 GSS-API Model . . . . . . . . . . . . . . . . . . . . . . 4
2.2 SASL Model . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 EAP Model . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Mechanism Guidelines . . . . . . . . . . . . . . . . . . . . 6
3.1 Mechanism Naming . . . . . . . . . . . . . . . . . . . . . 6
3.2 Framing and Protocol . . . . . . . . . . . . . . . . . . . 6
3.3 Mechanism Security Properties . . . . . . . . . . . . . . 8
3.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Security Layer . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Target Identification . . . . . . . . . . . . . . . . . . 10
3.7 Channel Binding . . . . . . . . . . . . . . . . . . . . . 11
3.8 Principal Naming and Attributes . . . . . . . . . . . . . 13
3.9 Mechanism Negotiation . . . . . . . . . . . . . . . . . . 14
3.10 Indentity Protection . . . . . . . . . . . . . . . . . . 15
3.11 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 15
4. Tools for creating GUAM mechanisms . . . . . . . . . . . . . 16
4.1 Mechanism Bridges . . . . . . . . . . . . . . . . . . . . 16
4.2 Protocol Initiation . . . . . . . . . . . . . . . . . . . 16
4.3 Generic PRF . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Generic Per-Message Security Layer . . . . . . . . . . . . 17
4.5 Fragmentation Support . . . . . . . . . . . . . . . . . . 17
4.6 Channel Binding and Authenticated Data . . . . . . . . . . 17
4.7 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 17
4.8 Mechanism Naming . . . . . . . . . . . . . . . . . . . . . 17
4.9 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Interface Specification . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
7.1 Same mechanism accessed through different frameworks . . . 21
7.2 Algorithm identification and negotiation . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1 Normative References . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 24
Salowey Expires July 7, 2006 [Page 2]
Internet-Draft GUAM Mechanism Guidelines January 2006
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 July 7, 2006 [Page 3]
Internet-Draft GUAM Mechanism Guidelines January 2006
2. Introduction
2.1 GSS-API Model
The Generic Security Service Application Program Interface (GSS-API)
[RFC2743] defines interface into security modules for the purpose of
establish a security context between two peers. The peers are
usually identified as the GSS-API context initiator and the GSS-API
context acceptor.
+-----------+ +-----------+
| | Authentication | |
| GSS-API |<---------------------------->| GSS-API |
| Context | | Context |
| Initiator | Message Protection | Acceptor |
| |<---------------------------->| |
+-----------+ +-----------+
GSS-API can provide optional message protection services between the
GSS-API initiator and Acceptor.
2.2 SASL Model
The Simple Authentication and Security Layer (SASL) [REF] provides a
framework for providing authentication and security services between
a SASL Client and a SASL Server. SASL provides an abstraction layer
between application protocols and authentication mechanisms.
+-----------+ +-----------+
| | Authentication | |
| SASL |<---------------------------->| SASL |
| Client | | Server |
| | Message Protection | |
| |<---------------------------->| |
+-----------+ +-----------+
2.3 EAP Model
The Extensible Authentication Protocol (EAP) [RFC3748] defines a
protocol for performing authentication between two entities. The
protocol allows different authentication mechanisms through different
EAP methods. The EAP conversation is carried in a lower layer
protocol between the EAP Peer and EAP Authenticator, however the EAP
authentication conversation is actually terminated in a logical
entity known as the EAP server. The EAP server may be co-located
with the EAP authenticator or it may be located on a physically
Salowey Expires July 7, 2006 [Page 4]
Internet-Draft GUAM Mechanism Guidelines January 2006
separate device such as a AAA server. When the EAP server is
separated from the EAP authenticator the authenticator device
operates in pass-through mode. Message protection is not provided by
EAP, however it is common for key material from the authentication
exchange to be exported from the EAP server to the EAP authenticator
so it can be used in lower layer message protection schemes. The
export of the key material outside the EAP Server and the message
protection between the EAP Peer and the EAP Authenticator is done
outside the EAP protocol.
+--------+ +-----------+ +---------+
| | Authentication | |
| |<---------------------------------------------->| |
| EAP | | EAP | | EAP |
| Peer | | Authenti- | Key Material | Server |
| | Message Prot. | cator |<----------------| |
| |<---------------->| | | |
+--------+ +-----------+ +---------+
Salowey Expires July 7, 2006 [Page 5]
Internet-Draft GUAM Mechanism Guidelines January 2006
3. Mechanism Guidelines
3.1 Mechanism Naming
Each of the frameworks described in Section 2 provides a means to
identify mechanisms. A SASL mechanism name as 1 to 20 character
string selected from a subset of the ASCII character set. An GSS-API
mechanism is identified by an ASN.1 OID. An EAP mechanism is defined
either by a single by number if it is a normal type mechanism and a 3
byte SMI vendor indicator followed by a 4 byte type indicator if it
is an expanded type mechanism.
The recommendation for general mechanism naming is as follows:
1. A GUAM mechanism must provide a name for use in each of these
frameworks.
3.2 Framing and Protocol
All the frameworks rely upon the authentication mechanism to define
the authentication protocol messages exchanged between the
authenticating peers. All the frameworks treat the tokens that are
exchanged as opaque and can support an arbitrary number of exchanges
to establish a security context. The different frameworks have
different approaches to providing protocol support and framing for
carrying out authentication exchanges. From an authentication
protocol standpoint all the frameworks deal with two entities. The
GSS-API initiator, SASL client and EAP peer are equivalent and the
GSS-API acceptor, SASL server and EAP server are equivalent.
SASL mechanisms are designed to be embedded in an application
protocol and require no special framing of messages as this is
handled in the application layer protocol. Since SASL runs within a
connection oriented application protocol there is no consideration
for the fragmentation or retransmission. SASL allows either the SASL
client or the SASL server to initiate the conversation depending on
the capabilities of the SASL mechanism. In some cases application
protocols do not allow to send a server message with a result
indication. In these cases the SASL client mechanism may need to
respond with an empty message to the final server message. The SASL
security layer assumes it is running under a reliable connection
oriented application protocol.
GSS-API is also designed to be run within the context of another
protocol which will handle framing, fragmentation, retransmission and
message exchange. GSS-API does require that the initial token sent
Salowey Expires July 7, 2006 [Page 6]
Internet-Draft GUAM Mechanism Guidelines January 2006
between GSS-API initiator and acceptor start with the OID that
identifies the mechanism, but this is the only required framing.
GSS-API mechanism exchanges are always initiated by the GSS-API
context initiator. GSS-API provides per-message security services
that may provide replay detection and sequence detection so they may
be used in protocols that are not connection oriented.
EAP was designed to be embedded within lower layer protocols that do
not provide support fragmentation or retransmission. Therefore EAP
provides a protocol outside of the authentication protocol provided
by EAP methods. This protocol provides basic message framing which
is required on every EAP message. The protocol also defines
retransmission behavior that can be used when the underlying protocol
does not provide retransmission of lost packets. EAP does not
provide fragmentation so it is up to the implementation of individual
EAP mechanisms to provide this support. EAP authentication exchanges
are always initiated from the EAP server side of the conversation.
The last EAP message in the method conversation is sent from peer to
server, excluding the EAP Success or failure message. The EAP
protocol also includes a negotiation phase which is described in
Section 3.9 and an unprotected way to indicate success or failure.
EAP does not provide a security layer or per-message security
services.
Another consideration with EAP is often used to perform
authentication to get authorization to a network. This means that
all or some network services may not be available at authentication
time. Therefore if the underlying authentication technology requires
access to network services such as a Kerberos KDC the authentication
may be impossible. Mechanism developers should take this into
consideration and possibly provide additional mechanisms to support
cases in which network services are not available and authentication
exchanges need to be carried out through the authenticator.
The recommendation for handling this in a general mechanism is as
follows.
1. The core authentication protocol messages SHOULD be the same
regardless of which framework is used.
2. A mechanism MUST define message flows that can be initiated from
the server/acceptor side or the initiator/client side. This
along with 6 SHOULD be the only protocol difference between the
messages used in different frameworks.
3. When operating in first message sent by client mode the first
message SHOULD have the GSS-API OID for the mechanism at the
beginning. If the mechanism excludes the OID in certain
Salowey Expires July 7, 2006 [Page 7]
Internet-Draft GUAM Mechanism Guidelines January 2006
frameworks then the absence of the OID MUST NOT create any
difference in the subsequent message or operation of the
mechanism.
4. Mechanisms MUST define how to do fragmentation. In order to
accommodate this a generic fragmentation wrapper should be used.
5. A mechanism MUST define itself as client initiated, server
initiated or variable when operating in SASL mode.
6. If the last message in the authentication exchange is sent by the
server then the client/peer MUST be prepared to send an empty
message to satisfy the SASL application and EAP requirements.
The server/acceptor side of the conversation MUST be prepared to
accept this empty message when operating in these modes. This
along with 1 SHOULD be the only protocol difference between the
messages used in different frameworks.
7. A mechanism SHOULD take into considerations scenarios where
network services are not available to an entity wishing to join
the network and provide mechanisms or modes of operation which do
not require direct access to network services.
3.3 Mechanism Security Properties
This section makes recommendations on the types of security
properties that a mechanism should have. This list is taken from
[RFC3748] and refers to the capabilities of the authentication
exchange itself and not to subsequent per-message protection or
security layers.
1. A mechanism MAY support ciphersuite negotiation for the
algorithms used in the authentication exchange.
2. If a mechanism supports ciphersuite negotiation then it MUST be
protected
3. Mechanisms SHOULD provide a way to indicate the algorithms or
ciphersuites in use so that it is possible to upgrade the
algorithms used without defining a new mechanism.
4. A Mechanism MUST support mutual authentication
5. A Mechanism MUST support integrity protection
6. A Mechanism MUST support replay protection
Salowey Expires July 7, 2006 [Page 8]
Internet-Draft GUAM Mechanism Guidelines January 2006
7. A Mechanism MAY support confidentiality
8. A Mechanism SHOULD provide dictionary attack resistance
9. A mechanism SHOULD support Session independence so the
compromise of one session does not compromise previous or
subsequent sessions
10. If a mechanism incorporates other mechanism it SHOULD provide a
means to cryptographically bind the mechanism results together
if possible.
3.4 Key Derivation
All of the frameworks support an authenticated key exchange. SASL
does not provide access to generated key material, however key
material from a SASL exchange may be used in a SASL security layer.
EAP methods derive two keys, the master session key (MSK) and the
extended master session key (EMSK). GSS-API mechanisms can provide
access to a pseudo-random function that derives keys from the
underlying authenticated key exchange.
The recommendations for key derivation in a general mechanism is as
follows:
1. A mechanism MUST support the derivation of key material.
2. Mechanism MUST support a PRF that can interface with the GSS-API
PRF function. A default PRF may be defined for this purpose.
3. A mechanism SHOULD provide a way to provide cryptographic agility
for a PRF.
4. A mechanism MUST define key material that may be defined as the
EAP MSK and EMSK. It is possible that these keys may be derived
from the GSS-API PRF using well defined strings as input. This
may need more investigation since it is possible that a mechanism
may not export the EMSK but would instead export only keys
derived from the EMSK.
5. Key material exported from mechanisms MUST be cryptographically
separate from keys used for other purposes by the mechanism such
as those used in a security layer.
Salowey Expires July 7, 2006 [Page 9]
Internet-Draft GUAM Mechanism Guidelines January 2006
3.5 Security Layer
SASL and GSS-API provide a security layer that can be used to protect
further information between the two authenticated parties. The SASL
security layer expects to be run over a connection oriented
transport. The GSS-API security services may be used for message
protection and do not necessarily expect to run over a connection
oriented transport. EAP does not provide a security layer, instead
it exports key material that is used to seed an external security
layer.
The recommendations for general mechanism security layer are as
follows:
1. A mechanism MUST support a security layer which provides message
integrity protection at a minimum. A generic security layer may
be defined that can use key material generated from the
authentication exchange.
2. A mechanism SHOULD support confidentiality in the security layer.
3. A mechanism MAY provide for replay detection and out-of-sequence
detection.
4. A mechanism MUST provide cryptographic agility with respect to
integrity and confidentiality algorithms.
3.6 Target Identification
When establishing a security context the GSS-API context initiator
specifies the name of the target service it wants to communicate
with. SASL also allows the specification of the name of a target
service when establishing a security context. What is expected of
the target name is not completely described. A Kerberos mechanism
requires a target service name so it can obtain an select the
appropriate service tickets for the service. In the GSS-API simple
public key mechanism (SPKM) the target service name is included in
the exchanged tokens. Most other mechanism appear not to make use of
a target name. The type of names typically used as target names are
host based service names to represent a service on a host.
EAP does not have a notion of a target service name. Originally EAP
was more concerned with the authentication of the client accessing a
network rather than of a host to a client. In addition EAP has
largely been concerned with clients trying to access a network which
provides a uniform service with all authenticators providing the same
access service. As networks evolve this is changing somewhat so the
Salowey Expires July 7, 2006 [Page 10]
Internet-Draft GUAM Mechanism Guidelines January 2006
need to specify a target type of network service or, in some cases, a
particular instance of an authenticator providing a service. Some
EAP methods such as EAP-SIM and EAP-AKA do not explicitly name the
target but rather rely upon the assumption that an authorized party
has access to a shared secret. In some cases the EAP peer trying to
access the network does not know the identity of the network ahead of
time. Therefore it is desirable for the network to provide a hint of
its identity in its initial message. This can also be done in the
EAP identity request message as in [TBD], however this message is not
specific to a mechanism so it may not be possible to provide accurate
information.
The recommendations for general mechanism target identification are
as follows:
1. A mechanism SHOULD provide a means to bind a target service name
to the authentication exchange so at least the initiator and
acceptor can select the correct credentials and verify that the
target is consistent with the type of request being made. Note
that credential selection is a technique that can help in some
types of Section 3.7.
2. A mechanism SHOULD provide support for host based service names
as defined in [RFC2743]. Note that it may be beneficial to
define name types that identify network based services to support
environments where EAP is currently used.
3. A mechanism SHOULD provide a means for the acceptor to provide a
hint of its identity to the initiator when the acceptor issues
the first message. It SHOULD be possible to suppress this hint
for cases where this information should not be revealed.
3.7 Channel Binding
The term channel binding has been used with various different
meanings in the different frameworks.
GSS-API included the concept of channel binding to bind the context
establishment to an existing underlying cryptographic channel. The
helps to ensure that the end points of the secure channel are the
same as the endpoints of the context establishment and to prevent the
security context from being used outside of its intended scope. In
GSS-API mechanisms channel bindings are usually carried out by having
each side create a hash of application provided parameters and
comparing the hash provided by the other party. If the hashes do not
match channel binding fails. The data from channel bindings could be
transformations of key material negotiated by the underlying channel
Salowey Expires July 7, 2006 [Page 11]
Internet-Draft GUAM Mechanism Guidelines January 2006
or unique public data that has been exchanged within and bound to the
channel negotiation (such as the TLS finished messages). In some
cases addresses have also been used as channel bindings which can be
problematic since address may be translated and are often not bound
to an underlying cryptographic channel. This type of channel binding
has also been referred to cryptographic binding in the context of EAP
method discussions.
In EAP the term channel binding has been used with a different
emphasis. It is common for EAP deployments to locate the EAP server
on a AAA server which is physically separated from the authenticator.
In the case the AAA server typically supports multiple
authenticators. This results in the EAP peer authenticating the
identity of the AAA server and not the identity of the authenticator,
it just knows that the authenticator it is talking to has been
authorized by the AAA server. In many cases this does not cause a
problem since all authenticators provide the same service. However
in the case where authenticators providing different services use the
same AAA server or in cases where the identity of the individual
authenticator is important this does raise an issue. A peer
requesting a particular service may be fooled into accepting service
from an authenticator that is not authorized to provide the service.
In attempt to solve this problem it is recommended that the EAP
authentication method provide a way to bind parameters in the lower
layer request to the authentication protocol so they AAA server can
verify the binding between the service requested by the client and a
service that the authenticator is authorized to provide. This type
of channel binding might be better called service binding. There are
several ways that this type of channel binding may be achieved.
o Credential Selection - by including a target service identifier in
the authentication protocol the initiator and/or acceptor can
select an appropriate credentials to perform authentication as a
particular service. For example this could result in the
acquisition of a Kerberos service ticket for a specific service,
selection of an appropriate certificate to identify a specific
service, or localization of a shared secret for use with a
specific service. This requires each target service to have its
own name and credential. Credential selection may not provide
enough granularity for all the parameters specified by a service.
o GSS-API style channel bindings - in this case each side hashes the
binding information and the two hashes are compared. In this case
the contents of the binding information must be rigidly defined
because any variation will cause the binding to fail.
o Authenticated data style bindings - in this case the binding
information is communicated from initiator or vice versa. The
Salowey Expires July 7, 2006 [Page 12]
Internet-Draft GUAM Mechanism Guidelines January 2006
data can then be exported from the mechanism and compared with
additional parameters communicated out of band. This approach
allows for a more complex comparison where some variation of
binding parameters is allowed.
o Binding through external key derivation - in this case the keys
that are exported from a mechanism are bound to a particular
channel parameters through the key derivation algorithm. This
approach does not require support form in a mechanism and can only
be used when the key material is made use of externally.
SASL does not have a concept similar to channel bindings although it
does support specifying a target service identifier.
The recommendations for general mechanism channel bindings are as
follows:
1. A mechanism MUST support channel bindings compatible with
[RFC2743].
2. A mechanism MAY support authenticated data style channel
bindings.
3.8 Principal Naming and Attributes
GSS-API has a formal system of mechanism independent naming described
in [RFC2743]. The most commonly used name types are host based
service names (GSS_C_NT_HOSTBASED_SERVICE) and user names
GSS_C_NT_USER_NAME. GSS-API also has the concept of a canonical name
representation that can be used for binary comparisons of equality.
There are ongoing investigations into providing a more structured
naming scheme which could provide additional attributes such as group
affiliation.
EAP typically beings with an identity assertion phase where the peer
responds to an EAP-Identity request with an EAP-Identity response
containing an network access identifier (NAI). The NAI is not
authenticated at this point, but provides a hint to the back end
authentication services as how to authenticated the peer, i.e. which
authentication server to contact. In some ways this identifies the
target of the authentication, but it is just specify a realm instead
of a specific service that is being provided. The actual
authentication may or may not authenticate the NAI depending on the
authentication method. In some cases the NAI is anonymous and
completely unrelated to the final authenticated identity. EAP does
not provide a formal way of dealing with authenticated names. EAP
methods may provide a means for exchanging application specified data
Salowey Expires July 7, 2006 [Page 13]
Internet-Draft GUAM Mechanism Guidelines January 2006
which could be possibly be structured as naming attributes.
SASL defines an authorization identity in addition to the
authenticated identity. The authorization identity is the identity
that the client is expected to act as. The SASL implementation must
verify that the authenticated identity is authorized to act as the
authenticated identity. SASL does not specify the structure or
format of names identities.
The recommendations for general mechanism principal naming and
attributes are as follows:
1. A mechanism MUST define how to export names in the GSS-API
mechanism independent and canonical formats.
2. A mechanism MUST support the authenticated communication of and
application specific authorization identity. The mechanism
should provide hooks where appropriate to allow for the
authorization of the authorization identity to authenticated
identity mapping.
3. A mechanism MAY define support for other identity attribute types
as appropriate.
3.9 Mechanism Negotiation
GSS-API does not provide native support for mechanism negotiation,
however there is a specific mechanism designed to perform negotiation
called Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
[REF]. This mechanism can support the protected negotiation of
security mechanism provided the mechanisms provide a security layer
that provide per-message integrity protection.
EAP provides a negotiation mechanism in which the server suggests a
mechanism by sending the initial message in the authentication
exchange and the peer replies with either a response or a NAK message
containing a list of mechanisms it supports. The negotiation is not
protected. Once a particular negotiation method is selected it is
not possible to abort and switch to a new mechanism without
restarting the conversation.
In SASL mechanism negotiation is left to the application. Typically
the server presents a list that the client chooses from. The
negotiation may be protected if a security layer is provided and the
application defines a way to obtain a list of mechanisms after the
security layer is established.
Salowey Expires July 7, 2006 [Page 14]
Internet-Draft GUAM Mechanism Guidelines January 2006
Multiple layers of negotiation often causes problems. It is possible
for the negotiation to fail because a mechanism selected tries to do
negotiation which fails and there is no way to go backwards in the
mechanism tree without restarting the negotiation from the beginning.
The recommendations for general mechanism negotiation are as follows:
1. Mechanism should avoid extensive negotiation after they have been
selected. For example negotiating different credential types
after mechanism selection should be avoided when possible since
an entity may select a particular mechanism thinking it will use
one credential and then find out that the other party does not
support that type of credential in the mechanism.
3.10 Indentity Protection
Some mechanisms provide support for concealing the identity of one of
the parties executing the authentication protocol from an
eavesdropper. The recommendation for general mechanisms support for
identity protection is as follows,
1. A mechanism MAY support identity protection for one of the
participants in the authentication conversation.
3.11 Fast Reconnect
Fast reconnect is defined in [RFC3748]as "The ability, in the case
where a security association has been previously established, to
create a new or refreshed security association more efficiently or in
a smaller number of round-trips." The recommendation for general
mechanisms support for fast reconnect is as follows.
1. A mechanism MAY support fast reconnect for one of the
participants in the authentication conversation.
Salowey Expires July 7, 2006 [Page 15]
Internet-Draft GUAM Mechanism Guidelines January 2006
4. Tools for creating GUAM mechanisms
This section describes tools and techniques that mechanism developers
can use to help them create generally usable mechanism.
4.1 Mechanism Bridges
A mechanism bridge creates an automated way to incorporate mechanisms
from one framework into another framework. An example of such a
bridge is the SASL GSS-API based mechanism [I-D.ietf-sasl-gssapi].
This specification describes how a GSS-API mechanism may be invoked
as a SASL mechanism. This allows any mechanism specified in GSS-API
to be invoked through the SASL framework. When the SASL GSS-API
mechanism was first defined all GSS-API mechanism appeared as one
SASL mechanism within the SASL framework. This incorporation of one
framework within another framework creates a problem with negotiation
since when GSS-API is selected as SASL mechanism the parties cannot
be sure which GSS-API mechanisms are actually supported. This hiding
of one framework in another is NOT RECOMMENDED.
I may be possible to create bridges for other combinations of
mechanisms, but there often exists gaps in functionality between
mechanisms of different frameworks. The following sections describe
techniques that make it easier to overcome these gaps and make it
possible to adapt a candidate mechanism to different frameworks. As
a mechanism is incorporated from one framework into another it should
retain a unique identity so existing negotiation mechanisms of
frameworks and applications are not broken.
4.2 Protocol Initiation
The different frameworks require different entities to start the
authentication conversation. In EAP it is the server/acceptor side
that starts the conversation, in GSS-API it is the opposite and SASL
can operate in either mode. It is often possible to include an
additional message or remove a message without affecting the
protocol. For example to convert a client initiated protocol for use
with EAP an initial message that contains a hint of the identity of
the server could be added. The hint can be useful in EAP where the
peer may not have another means of knowing who it is talking to until
the authentication protocol is underway.
4.3 Generic PRF
For mechanisms that do not define a PRF that can be used in GSS-API
calls a default PRF can be defined.
Salowey Expires July 7, 2006 [Page 16]
Internet-Draft GUAM Mechanism Guidelines January 2006
4.4 Generic Per-Message Security Layer
Mechanisms that are defined as EAP methods do not provide a security
layer. However they do provide cryptographic key material generated
from the EAP exchange in the form of the MSK and EMSK. Key material
derived from these quantities could be used to key a generic security
layer. An generic security layer could be based on Kerberos
encryption and checksum profile [RFC3961] or on IPSec ESP. EAP
methods also do not provide for the negotiation of a ciphersuite for
the security layer. One approach would be to add negotiation into
the generic security layer. Another approach may be to exchange
quality of protection parameters as authenticated data.
4.5 Fragmentation Support
Mechanisms that are defined as GSS-API or SASL mechanisms leave any
fragmentation up to the application itself. In order to support EAP
these mechanisms would have to include fragmentation support. A
generic fragmentation layer could be modelled after EAP-TLS
[RFC2716].
4.6 Channel Binding and Authenticated Data
The ability to carry data that is integrity protected between the
authenticating parties is a useful feature for a mechanism. Channel
binding would certainly be helped by this capability. The data
should be tagged for different purposes. One use could be to carry a
hash of channel binding parameters used for GSS-API style channel
bindings. Another use could be for communicating a SASL
authorization ID or for carry EAP style channel bindings. Having a
common name space for different types of attributes could be useful
in developing mechanisms in a consistent way.
4.7 Fast Reconnect
Some mechanisms provide support for a fast reconnect feature that
optimizes subsequent authentications after an initial authentication.
In some cases this may be best provided by the mechanism, however ti
could be possible for a generic fast reauthentication mechanism be
developed to address this need for general mechanisms.
4.8 Mechanism Naming
It is possible to automatically generate types from a single value.
The recommended approach is to assign an EAP type to a mechanism. A
GSS-API OID can be created from the EAP type by appending the EAP
type as an integer appended to the GUAM mechanism base OID [TBD].
The SASL specification for using GSS-API mechanisms in SASL is
Salowey Expires July 7, 2006 [Page 17]
Internet-Draft GUAM Mechanism Guidelines January 2006
defined in [REF] and specifies a way to create a SASL name from a
GSS-API OID.
4.9 Naming
TBD - Some guidance in naming is needed.
Salowey Expires July 7, 2006 [Page 18]
Internet-Draft GUAM Mechanism Guidelines January 2006
5. Interface Specification
This section outlines how the GSS-API can provide a interface that
could potentially be used by any of the mechanism frameworks. Some
required enhancements to GSS-API to make this happen are discussed.
Salowey Expires July 7, 2006 [Page 19]
Internet-Draft GUAM Mechanism Guidelines January 2006
6. IANA Considerations
To be determined.
Salowey Expires July 7, 2006 [Page 20]
Internet-Draft GUAM Mechanism Guidelines January 2006
7. Security Considerations
7.1 Same mechanism accessed through different frameworks
7.2 Algorithm identification and negotiation
Salowey Expires July 7, 2006 [Page 21]
Internet-Draft GUAM Mechanism Guidelines January 2006
8. Acknowledgements
Nicolas Williams, Sam Hartman, and Glen Zorn provided valuable
discussions and feedback that went into the preparation of this
document.
Salowey Expires July 7, 2006 [Page 22]
Internet-Draft GUAM Mechanism Guidelines January 2006
9. References
9.1 Normative References
[I-D.ietf-sasl-rfc2222bis]
Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-14
(work in progress), November 2005.
[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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
9.2 Informative References
[I-D.ietf-sasl-gssapi]
Melnikov, A., "SASL GSSAPI mechanisms",
draft-ietf-sasl-gssapi-03 (work in progress),
September 2005.
[I-D.salowey-guam]
Salowey, J., "Generally Useful Authentication Mechanisms
(GUAM)", draft-salowey-guam-00 (work in progress),
June 2005.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
Author's Address
Joseph Salowey
Cisco Systems
Email: jsalowey@cisco.com
Salowey Expires July 7, 2006 [Page 23]
Internet-Draft GUAM Mechanism Guidelines January 2006
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 (2006). 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 July 7, 2006 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-24 10:36:44 |