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]