Internet DRAFT - draft-salowey-guam-mech
draft-salowey-guam-mech
Network Working Group J. Salowey
Internet-Draft Cisco Systems
Expires: December 27, 2006 June 25, 2006
Guidelines for Creating Generally Useful Authentication Mechanisms
(GUAM)
draft-salowey-guam-mech-01.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 27, 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 December 27, 2006 [Page 1]
Internet-Draft GUAM Mechanism Guidelines June 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 Session Identification . . . . . . . . . . . . . . . . . . 12
3.8 Channel Binding . . . . . . . . . . . . . . . . . . . . . 12
3.9 Principal Naming and Attributes . . . . . . . . . . . . . 14
3.10 Mechanism Negotiation . . . . . . . . . . . . . . . . . 15
3.11 Indentity Protection . . . . . . . . . . . . . . . . . . 16
3.12 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 16
4. Tools for creating GUAM mechanisms . . . . . . . . . . . . . 17
4.1 Mechanism Bridges . . . . . . . . . . . . . . . . . . . . 17
4.2 Protocol Initiation . . . . . . . . . . . . . . . . . . . 17
4.3 Generic PRF . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Generic Per-Message Security Layer . . . . . . . . . . . . 17
4.5 Fragmentation Support . . . . . . . . . . . . . . . . . . 18
4.6 Channel Binding and Authenticated Data . . . . . . . . . . 18
4.7 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 18
4.8 Mechanism Naming . . . . . . . . . . . . . . . . . . . . . 18
4.9 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Interface Specification . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 22
7.1 Same mechanism accessed through different frameworks . . . 22
7.2 Algorithm identification and negotiation . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 Normative References . . . . . . . . . . . . . . . . . . . 24
9.2 Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26
Salowey Expires December 27, 2006 [Page 2]
Internet-Draft GUAM Mechanism Guidelines June 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 December 27, 2006 [Page 3]
Internet-Draft GUAM Mechanism Guidelines June 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. GSS-API is generally applicable in a wide variety
of situations, however it is most often used in application layer
protocols.
+-----------+ +-----------+
| | 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) 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. SASL is
generally applicable within application layer protocols.
+-----------+ +-----------+
| | Authentication | |
| SASL |<---------------------------->| SASL |
| Client | | Server |
| | Octet Stream Protection | |
| |<---------------------------->| |
+-----------+ +-----------+
2.3 EAP Model
The Extensible Authentication Protocol (EAP) [RFC3748] defines a
protocol for performing authentication between two entities. EAP is
generally applicable for network access authentication. The protocol
allows different authentication mechanisms through different EAP
methods. The EAP conversation is carried in a lower layer protocol
Salowey Expires December 27, 2006 [Page 4]
Internet-Draft GUAM Mechanism Guidelines June 2006
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
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 December 27, 2006 [Page 5]
Internet-Draft GUAM Mechanism Guidelines June 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 mechanism 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 December 27, 2006 [Page 6]
Internet-Draft GUAM Mechanism Guidelines June 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.10 and an unprotected way to indicate success or failure.
EAP does not provide a security layer or per-message security
services. EAP also does not define a way to distribute key material
from the EAP server to an EAP authenticator. In the case where the
EAP server and the EAP authenticator are collocated this is a local
interface and in the case where they are separated from one another
the key distribution typically makes use of a AAA protocol such as
RADIUS or Diameter.
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 GUAM mechanism MUST define message flows that can be initiated
from the server/acceptor side or the initiator/client side.
Salowey Expires December 27, 2006 [Page 7]
Internet-Draft GUAM Mechanism Guidelines June 2006
3. When operating in GSS-API mode the first message sent from the
client MUST begin with the GSS-API OID for the mechanism. When
operating in first message sent by client mode in other
frameworks the first message MAY begin with the GSS-API OID for
the mechanism. If the mechanism excludes the OID in certain
frameworks then the absence of the OID MUST NOT create any
difference in the subsequent message or operation of the
mechanism.
4. GUAM mechanisms MUST define how to do fragmentation. In order to
accommodate this a generic fragmentation wrapper should be used.
The Internet community may develop a fragmentation framework as
part of a generic framing facility.
5. A GUAM mechanism MUST define itself as client initiated, server
initiated or variable when operating in SASL mode.
6. If the last message in the core 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 2 SHOULD be the only protocol difference
between the messages used in different frameworks.
7. A GUAM mechanism SHOULD take into consideration 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. Typically it will
be the client side of the conversation that does not have 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 MUST identify the algorithms in use and provide for
algorithm agility. A mechanism SHOULD support ciphersuite
negotiation for the algorithms used in the authentication
exchange.
2. If a mechanism supports ciphersuite negotiation then it SHOULD be
protected
Salowey Expires December 27, 2006 [Page 8]
Internet-Draft GUAM Mechanism Guidelines June 2006
3. A mechanism MUST support mutual authentication. For EAP
mechanisms this means mutual authentication between EAP peer and
EAP server.
4. A mechanism MUST support integrity protection for messages
exchanged within the authenticated key exchange.
5. A mechanism MUST support replay protection for the message
exchanged within the core authenticated key exchange.
6. A mechanism MAY support confidentiality for the message exchanged
within the core authenticated key exchange.
7. A mechanism SHOULD provide passive and active dictionary attack
resistance.
8. A mechanism SHOULD support Session independence so the compromise
of one session does not compromise previous or subsequent
sessions
9. If a mechanism incorporates or uses another mechanism it SHOULD
provide a means to cryptographically bind the mechanism exchanges
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. Mechanisms MUST support a PRF that can interface with the GSS-API
PRF function. A default generic PRF may be defined for this
purpose.
3. A mechanism SHOULD provide a way to provide cryptographic agility
for a PRF.
Salowey Expires December 27, 2006 [Page 9]
Internet-Draft GUAM Mechanism Guidelines June 2006
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.
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 that protects data between the EAP peer and EAP authenticator.
All GUAMs MUST meet the recommendations for general mechanism
security layer 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 MUST provide for replay detection and MAY provide
out-of-sequence detection.
4. A mechanism MUST provide cryptographic agility with respect to
integrity and confidentiality algorithms.
3.6 Target Identification
Specifying the target name of the service is useful when
communicating with an entity which supports multiple virtual
services.
When establishing a security context the GSS-API context initiator
specifies the name of the target service it wants to communicate
Salowey Expires December 27, 2006 [Page 10]
Internet-Draft GUAM Mechanism Guidelines June 2006
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. 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
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 [I-D.adrangi-eap-network-
discovery], 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 channel bindings described in Section 3.8.
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.
Salowey Expires December 27, 2006 [Page 11]
Internet-Draft GUAM Mechanism Guidelines June 2006
3.7 Session Identification
Session identification information provides a way to identify a
particular instance of an authentication transaction. This
information could be used to bind this authentication transaction to
another exchange or it could be used to identify keys generated by
the exchange. GSS-API and SASL frameworks do not provide an external
way to identify a particular authentication transaction. It is
possible that the GSS-API PRF interface could be used for this
purpose, but it may be preferred to generate a value that is a
property of the mechanism execution instead of application specific
information. EAP also does not provide a external way to identify a
particular exchange, however [I-D.ietf-eap-keying] does make
recommendations in this area.
The recommendations for general mechanism session identification are
as follows:
A mechanism SHOULD provide a means to export a value to identify a
particular instance of an authentication transaction. This value
is a public value and must not reveal any secret information.
3.8 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. In the GSS-API
initiator and acceptor applications provide "channel bindings" data,
a strong identifier for a secure channel, to the mechanism which
determines the channel bindings data are the same for both peers,
such as by exchanging and comparing integrity hashes thereof. The
data from channel bindings could be transformations of key material
negotiated by the underlying channel or unique public data that has
been exchanged within and bound to the channel negotiation (such as
the TLS finished messages). In some cases network 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. GSS-API 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
Salowey Expires December 27, 2006 [Page 12]
Internet-Draft GUAM Mechanism Guidelines June 2006
on a AAA server which is physically separated from the authenticator.
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. The contents
of the binding information must be rigidly defined because any
variation will cause the binding to fail. The AAA server will
need to know what binding parameters are associated with the
authenticator in order to correctly compute the binding.
o Authenticated data style bindings - in this case the binding
information is communicated from initiator or vice versa. The
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
Salowey Expires December 27, 2006 [Page 13]
Internet-Draft GUAM Mechanism Guidelines June 2006
approach does not require support from a mechanism and can only be
used when the key material is made use of externally.
SASL does not currently have a concept similar to channel bindings
although it does support specifying a target service identifier.
However there is ongoing work on defining channel bindings for SASL
mechanisms.
The recommendations for general mechanism channel bindings are as
follows:
1. A mechanism MUST support channel bindings compatible with
[RFC2743].
2. A mechanism MUST support authenticated data style channel
bindings.
3.9 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
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
Salowey Expires December 27, 2006 [Page 14]
Internet-Draft GUAM Mechanism Guidelines June 2006
authenticated identity. SASL does not specify the structure or
format of names.
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 an
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.10 Mechanism Negotiation
GSS-API does not provide native support for mechanism negotiation,
however there is a pseudo-mechanism designed to perform negotiation
called Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
[RFC4178]. SPNEGO can negotiate a mechanism in common between the
initiator and acceptor, and, provided the mechanisms negotiated
provide integrity support, then it can also protect the negotiation.
Some GSS-API applications eschew SPNEGO and perform mechanism
negotiation at the application protocol layer. .
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.
Multiple layers of mechanism negotiation can cause problems. The
main problem with multi-layer mechanism negotiation is that security
requirements may not be maintained at all negotiation layers, thus
one layer may select a security mechanism that is too weak or
Salowey Expires December 27, 2006 [Page 15]
Internet-Draft GUAM Mechanism Guidelines June 2006
otherwise inappropriate at a higher layer. It is also 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 specifications should analyze the security implications
of sub mechanism negotiation and include security considerations
to address security issues that may arise from sub-mechanism
negotiation.
3.11 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. In general
mechanisms are more interested in protecting the identity of
clients rather than services.
3.12 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 December 27, 2006 [Page 16]
Internet-Draft GUAM Mechanism Guidelines June 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.
It 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.
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
Salowey Expires December 27, 2006 [Page 17]
Internet-Draft GUAM Mechanism Guidelines June 2006
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 [RFC4121][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 it
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
defined in [I-D.ietf-sasl-gssapi] and specifies a way to create a
SASL name from a GSS-API OID.
Salowey Expires December 27, 2006 [Page 18]
Internet-Draft GUAM Mechanism Guidelines June 2006
4.9 Naming
TBD - Some guidance in naming is needed.
We need at least support for naming services, both domain-wide (AAA
services) and host-based, and we need support for naming users.
Everything else should pretty much be optional, including anonymity
and pseudonymity.
Salowey Expires December 27, 2006 [Page 19]
Internet-Draft GUAM Mechanism Guidelines June 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 December 27, 2006 [Page 20]
Internet-Draft GUAM Mechanism Guidelines June 2006
6. IANA Considerations
To be determined.
Salowey Expires December 27, 2006 [Page 21]
Internet-Draft GUAM Mechanism Guidelines June 2006
7. Security Considerations
7.1 Same mechanism accessed through different frameworks
7.2 Algorithm identification and negotiation
Salowey Expires December 27, 2006 [Page 22]
Internet-Draft GUAM Mechanism Guidelines June 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 December 27, 2006 [Page 23]
Internet-Draft GUAM Mechanism Guidelines June 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-15
(work in progress), January 2006.
[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.adrangi-eap-network-discovery]
Adrangi, F., "Identity selection hints for Extensible
Authentication Protocol (EAP)",
draft-adrangi-eap-network-discovery-14 (work in progress),
August 2005.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-13 (work in
progress), May 2006.
[I-D.ietf-sasl-gssapi]
Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism",
draft-ietf-sasl-gssapi-06 (work in progress), June 2006.
[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.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Salowey Expires December 27, 2006 [Page 24]
Internet-Draft GUAM Mechanism Guidelines June 2006
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005.
Author's Address
Joseph Salowey
Cisco Systems
Email: jsalowey@cisco.com
Salowey Expires December 27, 2006 [Page 25]
Internet-Draft GUAM Mechanism Guidelines June 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 December 27, 2006 [Page 26]
