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