idnits 2.17.1 draft-salowey-guam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1169. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2005) is 6877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GSSSTACK' is mentioned on line 639, but not defined == Unused Reference: 'I-D.williams-gssapi-v3-guide-to' is defined on line 1081, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) == Outdated reference: A later version (-04) exists of draft-arkko-eap-service-identity-auth-02 == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-02 == Outdated reference: A later version (-05) exists of draft-funk-eap-ttls-v0-00 == Outdated reference: A later version (-07) exists of draft-iab-auth-mech-03 == Outdated reference: A later version (-07) exists of draft-ietf-kitten-gssapi-prf-04 == Outdated reference: A later version (-09) exists of draft-ietf-radext-digest-auth-02 -- Obsolete informational reference (is this intentional?): RFC 1508 (Obsoleted by RFC 2078) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Salowey 3 Internet-Draft Cisco Systems 4 Expires: December 28, 2005 June 26, 2005 6 Generally Useful Authentication Mechanisms (GUAM) 7 draft-salowey-guam-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Generic Security Services API (GSS-API), the Simple Authentication 41 and Security Layer (SASL), the Extensible Authentication Protocol 42 (EAP) and Transport Layer Security (TLS) are examples of four 43 different security frameworks within the IETF. Each of these 44 frameworks have evolved separately towards a common goal of 45 authentication and establishing a cryptographic context. They 46 support different types of security mechanisms and have historically 47 evolved to integrate with different security infrastructures. This 48 document discusses their similarities and differences and how these 49 security mechanisms might start to converge into a more uniform 50 approach involving generally useful authentication mechanisms that 51 can be used in any of these frameworks with a variety of different 52 security infrastructures. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1 Why unify mechanisms? . . . . . . . . . . . . . . . . . . 5 59 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Survey of Authentication Mechanism Frameworks . . . . . . . 7 61 3.1 GSS-API . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.3 EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.4 Transport Layer Security . . . . . . . . . . . . . . . . . 12 65 3.5 Integration with Security Infrastructures . . . . . . . . 13 66 3.5.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.5.2 Public Key Infrastructure . . . . . . . . . . . . . . 13 68 3.5.3 Authentication Authorization and Accounting (AAA) 69 Services . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.6 Framework Summary . . . . . . . . . . . . . . . . . . . . 15 71 4. Recommendations for Unifying Mechanisms . . . . . . . . . . 18 72 4.1 GUAM Mechanism requirements . . . . . . . . . . . . . . . 18 73 4.1.1 Mutual Authentication . . . . . . . . . . . . . . . . 18 74 4.1.2 Key Material Access and Security Layer . . . . . . . . 18 75 4.1.3 Channel Binding (GSS-API) . . . . . . . . . . . . . . 19 76 4.1.4 Cryptographic Binding . . . . . . . . . . . . . . . . 19 77 4.1.5 Channel Bindings (EAP) . . . . . . . . . . . . . . . . 19 78 4.1.6 Mechanism Naming . . . . . . . . . . . . . . . . . . . 19 79 4.1.7 Identity and Naming . . . . . . . . . . . . . . . . . 20 80 4.1.8 Mechanism Initiation . . . . . . . . . . . . . . . . . 20 81 4.1.9 Additional Security Properties . . . . . . . . . . . . 20 82 4.1.10 Authentication infrastructure integration . . . . . 20 83 4.2 GUAM Framework Enhancements . . . . . . . . . . . . . . . 21 84 4.2.1 GSS-API . . . . . . . . . . . . . . . . . . . . . . . 21 85 4.2.2 SASL . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 4.2.3 EAP . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 4.2.4 TLS . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.2.5 Security Layer . . . . . . . . . . . . . . . . . . . . 22 89 4.2.6 Negotiation . . . . . . . . . . . . . . . . . . . . . 22 90 4.2.7 Mechanism Gateways . . . . . . . . . . . . . . . . . . 22 91 4.2.8 Name Mapping . . . . . . . . . . . . . . . . . . . . . 23 92 4.3 Recommended GUAM Mechanisms . . . . . . . . . . . . . . . 23 93 5. Security Considerations . . . . . . . . . . . . . . . . . . 24 94 5.1 Lying NAS . . . . . . . . . . . . . . . . . . . . . . . . 24 95 5.2 Cryptographic binding between mechanisms . . . . . . . . . 24 96 5.3 Clear text passwords and PAP . . . . . . . . . . . . . . . 24 97 5.4 Exporting Contexts . . . . . . . . . . . . . . . . . . . . 25 98 5.5 Unauthenticated Identities . . . . . . . . . . . . . . . . 25 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 8.1 Normative References . . . . . . . . . . . . . . . . . . . 28 103 8.2 Informative References . . . . . . . . . . . . . . . . . . 28 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . 30 105 Intellectual Property and Copyright Statements . . . . . . . 31 107 1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Introduction 115 There are many authentication technologies available in the IETF. 116 This memo specifically focuses on the security frameworks of GSS-API 117 [RFC2743], SASL [RFC2222], EAP [RFC3748] and TLS [RFC2246]. Each of 118 these frameworks have evolved somewhat independently towards the same 119 goal of authentication and cryptographic context establishment. 120 Historically, though not by design, they support different types of 121 authentication mechanisms and focus on integrating with different 122 security infrastructures. This has led to some confusion and 123 fragmentation within the IETF community. Authentication mechanisms 124 available to one user community are not available to another leading 125 to decreased deployment or duplication of effort. 127 This document examines these four frameworks to identify their 128 similarities and differences. It also looks at three commonly used 129 security infrastructures: Kerberos, PKI and AAA. It then provides 130 suggestions for development of new and/or existing mechanisms to 131 enable use in any of these frameworks. This set of Generally Usable 132 Authentication Mechanisms (GUAM) will enable broader use of 133 authentication mechanisms and infrastructures across the Internet 134 community. 136 There are other authentication frameworks used within the IETF such 137 as those used in IKE, SSH, HTTP and SMIME. GUAM mechanisms may not 138 be able to easily replace all of these uses, but they provide a 139 starting point for unifying frameworks used to establish an 140 authenticated cryptographic context. 142 2.1 Why unify mechanisms? 144 o The actual mechanisms in each of these frameworks actually have 145 very similar goals of authentication and establishing a 146 cryptographic context. In many cases frameworks are developing 147 new functionality that bring them closer together. This document 148 will hopefully help accelerate this process of convergence. 150 o There is pressure to adopt a particular framework because of the 151 set of mechanisms available not because of the capabilities and 152 upper-layer interface of the framework. We should be in a 153 situation where the choice on mechanism was dictated by the 154 deployment requirements and the choice of framework dictated by 155 protocol design and implementation simplicity. 157 o There is a duplication of effort in the development of security 158 mechanism that support similar credential types and 159 infrastructures. This is problematic because the development of 160 security mechanisms is both difficult and time consuming. It 161 would be good to leverage the work and expertise required for 162 developing a mechanism across all the frameworks. 164 o Often the cost of deploying a security mechanism is in the 165 infrastructure and not the implementation of the mechanism itself. 166 There limited set of mechanisms available to particular frameworks 167 makes the coordination and administration of security between 168 applications that use different frameworks more difficult. 170 2.2 Terminology 172 TODO: define terms like security framework, authentication mechanism, 173 security mechanism, security context, security token, ... 175 3. Survey of Authentication Mechanism Frameworks 177 This memo specifically focuses on the authentication frameworks of 178 GSS-API [RFC2743], SASL [RFC2222], EAP [RFC3748] and TLS [RFC2246]. 179 A broader survey of authentication mechanisms has been collected in 180 [I-D.iab-auth-mech]. 182 3.1 GSS-API 184 The Generic Security Service Application Programming Interface (GSS- 185 API) is defined as version 1 in [RFC1508] and version 2 in [RFC2743]. 186 It defines an API to access security services which may be provided 187 by different underlying security mechanism technologies. This allows 188 an application written to the GSS-API to adjust to different 189 mechanism requirements in different environments and therefore the 190 GSS-API does not define security protocols. In GSS-API peers 191 exchange data, called security tokens, to establish a security 192 context which can provide further security services. The GSS-API is 193 independent of transports and application protocols and therefore 194 does not provide a means to carry security tokens in a protocol, it 195 just provides an API to generate and process these tokens. GSS-API 196 requires the application to provide fragmentation support and framing 197 of tokens. A goal of the GSS-API is to support a wide variety of 198 applications and environments. 200 The GSS-API defines an interface to obtain security tokens that are 201 to be exchanged between two parties to establish a security context. 202 The context initiator always issues the first token. The security 203 context can be used to obtain the name of the authenticated parties 204 and to perform per-message protection of integrity and 205 confidentiality. The underlying authentication mechanisms may 206 require several token exchanges until the context is complete and all 207 the services are ready. Some security services such as integrity and 208 confidentiality may be available before the context is complete. 209 Mechanism negotiation is achieved through the use of special 210 mechanisms designed for negotiation. One such mechanism is the 211 simple and protected GSS-API negotiation mechanism (SPNEGO) defined 212 in [I-D.ietf-kitten-2478bis]. Some applications, such as SSH and 213 NFS, using GSS-API also provide their own mechanism for negotiating 214 security mechanism in addition to GSS-API. 216 GSS-API mechanisms can support mutual authentication where both 217 parties are explicitly authenticated, or forms of authentication 218 where either or both parties can remain anonymous. In version 2 GSS- 219 API did not provide direct access to cryptographic key material from 220 the underlying security context, however the resulting security 221 context can provide per-message security services such as 222 confidentiality, integrity protection, replay detection and out-of- 223 sequence detection. Applications can rekey the security layer by 224 calling the context establishment APIs. The GSS-API provides support 225 for channel binding to allow data from lower layers to be bound to 226 the context exchange. The usage GSS-API style channel bindings will 227 be identified by "channel bindings (GSS_API)" to differentiate it 228 from EAP channel bindings which are a slightly different usage. The 229 underlying security context created by GSS_API has a lifetime 230 associated with it. 232 GSS-API uses OIDs to represent mechanisms. GSS-API provides a 233 formalized framework for representing principal names as mechanism 234 independent quantities by defining name types. Some example name 235 types are Host-based service name and user names. GSS-API does not 236 specify how an application should make use of names, but it does make 237 available canonical name formats that can be used to compare two 238 names for equality. Naming is a complex issue that needs to be 239 further investigated across all the various mechanism frameworks. 241 There are only a few standard GSS-API mechanisms that are defined in 242 the IETF. These include Kerberos [I-D.ietf-krb-wg-gssapi-cfx], 243 Simple Public Key Mechanism (SPKM) [RFC2025], Low Infrastructure 244 Public Key Mechanism using SPKM [RFC2847]. The only mechanism that 245 is currently widely implemented in different environments and shown 246 to be interoperable is the Kerberos mechanism. The initial context 247 token emitted by a context initiator is required to be prefixed with 248 a small header containing the ASN.1 OID of the mechanism that 249 produced the token, other tokens can have any format. GSS-API 250 mechanisms are not required to support all of the services and 251 features available in the GSS-API. GSS-API does not provide full 252 credential management functionality therefore mechanisms are expected 253 to acquire their initial credentials through some other process. In 254 some cases, such as Kerberos, initial credential acquisition may 255 require network requests. 257 There is ongoing work on GSS-API version 3 [I-D.williams-gssapi-v3- 258 guide-to]. Some of the enhancements include a means to obtain key 259 material through a PRF associated with the security context, the 260 ability to stack multiple mechanisms, and extensions to naming to 261 support attributes authenticated during the context establishment. 262 This ongoing work may make it easier for GSSAPIv3 to become the 263 recommended API for GUAM mechanisms. 265 The GSS-API provides access to a wider variety of security 266 functionality. However, its deployment has been limited to specific 267 environments where its advanced functionality is required. In other 268 environments with simpler requirements the GSS-API has not seen great 269 uptake. This is due in part to the limited set of mechanisms 270 available and to the perceived complexity of the framework. An 271 implementation of the GSS-API may have significant complexity, but it 272 should be noted that it is possible to write mechanisms that are wire 273 compatible with GSS-API mechanisms that do not implement the GSS-API 274 framework on their local platform. 276 3.2 SASL 278 The Simple Authentication and Security Layer (SASL) is defined in 279 [RFC2222]. This specification provided a simpler alternative to GSS- 280 API for incorporating security functionality into connection oriented 281 applications. As in GSS-API a SASL exchange requires the exchange on 282 an arbitrary number of security tokens between two entities. In SASL 283 either party can send the initial security token. SASL provides a 284 basic unprotected mechanism negotiation scheme. 286 SASL is primarily focused on authenticating a user to a server, 287 however some SASL mechanisms do provide mutual authentication. It is 288 also possible to support anonymous authentication with the Anonymous 289 SASL mechanism. SASL does not provide access to key material 290 exchanged during the authentication, but it can negotiate the use of 291 a security layer to provide confidentiality and integrity. SASL 292 security layer is more stream oriented as opposed to GSS-API's 293 message oriented security services. SASL security layers do not 294 provide re-keying. SASL can also reference an external security 295 layer using the "EXTERNAL" mechanism. It is common for SASL 296 implementations to rely upon TLS as an external security layer for 297 data protection and sometimes authentication. SASL does not have an 298 equivalent to GSS-API channel bindings for binding the SASL exchange 299 to an underlying security channel. 301 SASL mechanisms are named using 20 character names from a restricted 302 ASCII character set. SASL also specifies that an mechanism may 303 transmit an authorization name to represent a name that an 304 authenticated principal wants to use for authorization purposes. The 305 mechanism or SASL layer must validate that the authenticated name is 306 authorized to use the authorization name. SASL does not provide any 307 specific name types and applications must be prepared to process 308 names of different types from different mechanisms. 310 SASL supports a wide variety of authentication mechanisms including 311 PLAIN user name and password [RFC2595], One-Time password [RFC2444] 312 and digest challenge response authentication [RFC2831]. SASL also 313 supports GSS-API mechanisms as a SASL mechanism so that any GSS-API 314 mechanism can be used as a SASL mechanism. This makes the SASL 315 mechanism space a superset of the GSS-API mechanism space. SASL 316 provides less advanced functionality than GSS-API, but it appears to 317 be easier to integrate into applications. The SASL specification 318 describes the requirements on an applications protocol profile that 319 uses SASL. Protocols such as IMAP and LDAP have specified SASL as a 320 means to integrate security into their applications. 322 3.3 EAP 324 The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. 325 This specification was originally developed as a way to introduce 326 support for different authentication mechanisms within the PPP 327 protocol. EAP has since be applied to other environments such as 328 wired and wireless LAN environments. EAP has largely been applied to 329 network access authentication. 331 As in SASL and GSS-API in an EAP mechanism specific messages are 332 exchanged between two parties until a security context is 333 established. EAP defines a slightly different model which involves 3 334 parties an EAP Peer, an EAP Authenticator and an EAP Server. It is 335 important to note however that EAP method protocols are 336 authentication protocols between the EAP Peer and EAP Server, the EAP 337 Authenticator acts in a pass-through mode with respect to EAP 338 messages. The ultimate goal of an EAP system is often to establish a 339 security context between a process on the device hosting the EAP Peer 340 and a process on a device hosting and EAP Authenticator, however this 341 cannot be done using EAP alone. . Once the EAP method completes 342 between the EAP Peer and EAP Server security context information from 343 the EAP method execution is made available to the EAP Authenticator, 344 which in turn makes the context information available to the layer 345 invoking the EAP framework. The context transfer happens outside the 346 EAP protocol. The EAP Server and EAP Authenticator may be 347 implemented on the same physical device or on a different physical 348 devices.In some cases the EAP-server is accessed through a AAA 349 subsystem in which case the AAA subsystem may augment the transferred 350 context with additional information that it is important for the 351 process receiving the context to know. Using the key material from 352 the transferred context the device hosting the EAP-Peer and the 353 device hosting the EAP-Authenticator can establish a security 354 association. This security association does not involve EAP 355 directly, but rather involves a security association protocol 356 external to EAP that runs between the process hosting the EAP Peer 357 and the process hosting EAP Authenticator. 359 The predominant use cases driving the design and implementation of 360 EAP are associated with network access. Traditionally each the 361 entity hosting the EAP-Authenticator is call a network access server 362 (NAS) and the EAP Server is hosed on a AAA server. EAP is popular in 363 environments where a AAA infrastructure is used and EAP provides an 364 extensible authentication interface into AAA servers. Having the EAP 365 Server remote from the authenticator allows for the network to add 366 support for different authentication mechanisms without having to 367 upgrade all the authenticators. Since in the basic case network 368 access servers all provide access to the same network services, 369 provide similar capabilities and are part of the same trusted 370 infrastructure the EAP Server and EAP Authenticator are often viewed 371 as the same logical entity even if they are implemented on different 372 physical devices. EAP mechanisms were originally designed to 373 authenticate to a realm and not to differentiate between different 374 authenticators in the same realm. There are proposals such as 375 [I-D.arkko-eap-service-identity-auth] that attempt to address this. 377 Unlike GSS-API and SASL, EAP does not provide support for security 378 layers, instead it provides access to keying material and other 379 context information derived from the EAP exchange. This key material 380 is typically provided to a process on the device hosting EAP 381 authenticator as described above. It is possible for security 382 associations with multiple entities to be seeded from a single EAP 383 exchange, however this is the subject of ongoing work. 385 The security considerations of [RFC3748] and [RFC4017] describe a 386 number of potential security properties that EAP methods may possess. 387 EAP does have a concept called "channel bindings" which will be 388 identified as "channel bindings (EAP)" in this document. It is 389 different than channel binding (GSS-API) except that the data 390 declared as channel binding values are expected to be exposed from 391 the mechanism. This allows for the EAP Peer to communicate 392 attributes to an EAP Server in a way that the EAP authenticator or 393 other third party cannot modify it. This provides a way for the EAP 394 server or and entity associated with the EAP Server to validate 395 information provided from the EAP Authenticator to the EAP Peer and 396 vice versa. This make channel bindings (EAP) more similar to 397 authenticated attributes or names. EAP also defines a concept called 398 "cryptographic binding" which attempts to provide assurance that 399 different authentication transactions carried out between two 400 entities actually occurred between those two entities and are not 401 compromised by a man in the middle. These two authentication 402 transactions may occur at different layers or they may occur 403 sequentially in the same layer. Channel bindings (GSS-API) are a 404 mechanism that can be used to achieve cryptographic binding. 405 Additional security properties defined in [RFC3748] include protected 406 ciphersuite negotiation, mutual authentication, integrity protection, 407 replay protection, key strength, dictionary attack resistance, fast 408 reconnect, session independence, identity protection, and protected 409 result indicators, 411 In the EAP model the first security token is sent to EAP Peer from 412 the EAP authenticator or EAP Server. EAP provides a basic level of 413 insecure mechanism negotiation. This can be enhanced by mechanism 414 specific negotiation which establishes a secure tunnel in which to 415 perform negotiation. These secure tunnel mechanisms can also be used 416 to chain mechanisms together. EAP provides an identity exchange 417 which may be independent of EAP mechanism. The identity is expressed 418 as an NAI defined in [RFC2486]. The identity is usually primarily 419 used for AAA routing and mechanism selection, an EAP mechanism may 420 arrive at a completely different authenticated identity. 422 There are only a few published EAP methods including EAP-MD5, EAP-OTP 423 and EAP-TLS. Of these only EAP-TLS derives keying material. There 424 are many more EAP methods deployed in the field that work with a wide 425 range of credential types from passwords to SIM based smart cards. 427 3.4 Transport Layer Security 429 Transport Layer Security (TLS) is a framework for providing 430 authenticated key exchange and security services at the "transport" 431 layer defined in [RFC2246]. Many applications use it as a way to 432 provide a security layer for the protection of stream oriented 433 application data. TLS has a large installed base and a wide variety 434 of implementations. Because of this it is starting to be seen in 435 other contexts as well such as DTLS for datagram applications and 436 EAP-TLS for network access scenarios. 438 TLS has a handshake protocol that provides a protected negotiation of 439 ciphersuites. A ciphersuite is an identifier for the combination of 440 an authenticated key exchange with bulk encryption and integrity 441 algorithms. The negotiation is initiated by the client and currently 442 has a fixed number of messages. TLS is often used primarily to 443 provide a security layer and is often deployed with just server 444 authentication. The security layer is stream oriented and is 445 typically implemented as a secure socket interface (hence the name 446 secure sockets layer, SSL, from which TLS was derived) making it easy 447 to integrate into TCP based applications. TLS does provide a 448 mechanism for re-keying the security layer. It is not typical for 449 TLS to provide key material externally, but EAP-TLS [RFC2716] has be 450 extended within to do this. TLS does not explicitly provide a 451 mechanism to bind to a lower layer or for an encapsulated layer to 452 bind to it. It is possible to use parameters from the handshake such 453 as the finished messages in channel bindings for security mechanism 454 that layer on top of TLS. 456 TLS was originally developed with ciphersuites that support X.509 457 certificates. It has modes that provide for anonymous, server side 458 authentication and mutual authentication. TLS also has ciphersuites 459 defined that support Kerberos credentials and shared secrets. TLS 460 does not deal explicitly with identities and these are left for each 461 ciphersuite to deal with. 463 3.5 Integration with Security Infrastructures 465 In order to make security solutions more scalable and manageable it 466 is common to make use of authentication services to increase 467 scalability and manageability. It is desirable for authentication 468 frameworks to integrate with these systems. This section looks at 469 three different authentication service infrastructure 470 infrastructures: Kerberos, PKI and AAA. Each of the frameworks 471 favors a particular type of infrastructure: GSS-API is associated 472 strongly with Kerberos, EAP is associated with AAA and TLS is often 473 associated with PKI. SASL is often used in a hybrid approach that 474 uses TLS for a security layer and another mechanism for client 475 authentication. 477 3.5.1 Kerberos 479 The Kerberos V network authentication [RFC1510] is an authentication 480 an key management system based on Needham-Schroeder protocol. 481 Kerberos is a true integrated 3 party protocol in which the trusted 482 third party server is a Key Distribution Center (KDC). Communication 483 with the KDC is not required for every authentication. GSS-API is 484 the preferred mechanism for applications to integrate with Kerberos. 485 This means that SASL can support Kerberos through its ability to use 486 GSS-API mechanisms. TLS does have Kerberos based ciphersuites 487 defined in [RFC2712], but it is somewhat out of date. EAP does not 488 currently have Kerberos integration. This is partially because 489 Kerberos mechanism is not ideally suited for network access 490 authentication since it requires access to the KDC to authenticate. 491 Some work has been done in this area in the past with the IAKERB GSS- 492 API mechanism and an EAP-GSS-API mechanism, but this work has 493 stalled. 495 3.5.2 Public Key Infrastructure 497 Public key infrastructure has several different forms, but the most 498 common is X.509 public key infrastructure. A profile for public key 499 certificate use for the Internet is available as [RFC3280]. In PKI 500 the trusted third party is a certificate authority (CA). The CA does 501 not typically participate directly in the authentication process. 502 [RFC2025] is a GSS-API mechanism that supports public key 503 credentials. TLS can use X.509 certificates for mutual 504 authentication. SASL does not currently have a public key mechanism 505 although some have been proposed and it can use an underlying TLS 506 session for authentication with public keys. The EAP-TLS mechanism 507 can use public key credentials for authentication and key exchange. 509 3.5.3 Authentication Authorization and Accounting (AAA) Services 511 The AAA model was originally developed to support network access 512 requirements. In a AAA system you typically have a network client 513 which is requesting access, a network access server, which hosts a 514 AAA client, that is providing access to the client and a AAA server 515 that is performing authentication, authorization and accounting 516 service for the network access server. A AAA server is expected to 517 be online to process authentication, accounting and authorization 518 requests. AAA services are typically implemented as RADIUS [RFC2865] 519 or Diameter [RFC3588] servers. The authentication interaction 520 usually consists of two protocols; an authentication protocol such as 521 EAP which executes between the network client and the AAA server and 522 a AAA protocol which executes between the network access server and 523 the AAA server. There is usually a third protocol, such a PPP, that 524 carries the authentication protocol between the network client and 525 the network access server. This model maps directly to the EAP 526 participants with the client hosting the EAP peer, the network access 527 server hosting the EAP authenticator and the AAA server hosting the 528 EAP server. In this model the network client authenticates and 529 establishes an authenticated context with the AAA server and the AAA 530 server uses a separate security association with the AAA client under 531 which to transmit key material and other context data. The network 532 access server then uses this data to establish a security association 533 with the network access client. As in the EAP model the AAA client 534 and AAA server are often viewed as the same logical entity from the 535 point of view of the network access client. 537 AAA servers originally started as services that maintained shared 538 secrets for clients. This capability has evolved over time from 539 support for clear text password based protocols, to challenge 540 response protocols, to protocols that are based on public key 541 credentials instead of shared secrets. One method for integrating 542 with AAA servers is to use them as validators of a clear text 543 password. This is often referred to as password authentication 544 protocol or PAP. There are mechanisms such as GSS-API mechanisms 545 such as LIPKEY, [RFC2847], plain in SASL, and GTC in EAP which 546 involve sending a password between the client and server. Although 547 the password may be transmitted to the network access server in 548 encrypted form in these schemes it is visible and vulnerable at this 549 point. The use of one time password and token cards can help 550 mitigate the risk. In this case the authentication protocol does not 551 provide mutual authentication or authorization between the client and 552 AAA server. The second method for integration uses the AAA server as 553 an endpoint of the authentication communication. Examples of these 554 types of protocols that are supported by AAA are CHAP, Digest 555 Authentication and EAP. This is the mechanism that EAP uses to 556 integrate with the AAA server and is defined for both RADIUS 558 [RFC3579] and Diameter. SASL supports Digest authentication 559 [I-D.ietf-radext-digest-auth] which can back end directly into AAA 560 using RADIUS or Diameter attributes. In this case mutual 561 authentication between network access client and AAA Server can be 562 achieved through the authentication protocol. 564 3.6 Framework Summary 566 All of the authentications frameworks described in this section have 567 similar goals of authentication and optional establishment of a 568 cryptographic context. They provide some different features and are 569 tuned to slightly different environments. These different 570 environments also influence the availability of different mechanisms 571 within each framework. The next section describes some of the 572 different capabilities of the various mechanisms. 574 Security Layer 576 A framework provides a security layer if it provides mechanisms to 577 protect the transfer of bulk data between peers after the context 578 has been established. GSS-API optionally provides this with wrap 579 and unwrap functions. SASL provides optional support for a 580 security layer. TLS always provides support for a security layer. 581 EAP does not support a security Layer. 583 Key Material Access 585 A framework may provide access to key material derived during the 586 authentication process. This is especially useful when the 587 framework is used in cases where a security layer is already 588 defined and needs to obtain keys through a certain mechanism. EAP 589 provides key material access. GSS-API v3 is working on an API to 590 a PRF, [I-D.ietf-kitten-gssapi-prf], which would provide similar 591 functionality. Basic TLS does not provide access to key material 592 although specific uses, such as EAP-TLS, obtain access to certain 593 key material derived from the master secret. SASL does not 594 provide access to key material. 596 Mechanism Negotiation 598 EAP and SASL provide a basic unprotected support for negotiating 599 mechanism which can be vulnerable to man-in-the-middle attacks. 600 GSS-API does not provide built-in support for mechanism 601 negotiation, however a specialized mechanism, SPNEGO, is available 602 for purpose of providing protected mechanism negotiation. EAP 603 also provides mechanisms such as PEAP which can be used to perform 604 protected negotiation of mechanisms. TLS provides a protected 605 mechanism to negotiate ciphersuites. 607 Channel Binding (GSS-API) 609 GSS-API provides formal support for channel bindings. Channel 610 bindings provide a mechanism to bind the current authentication 611 exchange to lower level parameters such as cryptographic keys or 612 addresses. In GSS-API channel bindings are usually validated 613 within the mechanism and are part of mechanism functionality. In 614 EAP there is a similar concept called crypto binding which is used 615 to bind chained mechanisms together. Mechanisms can also provide 616 quantities for channel binding in higher layers. EAP provides key 617 material which can help here. EAP also has discussed deriving a 618 name to identify the keying material derived from a specific 619 instance of method execution which may be useful in binding to 620 upper layers. GSSAPIv3 is specifying a PRF API which may be 621 helpful here. SASL does not support channel bindings. 623 Channel Binding (EAP) 625 EAP channel bindings are conveyed between the EAP Peer and EAP 626 Server and may contain information about the communication layer 627 between the entity hosting EAP Peer and the entity hosting EAP 628 Authenticator. EAP the channel bindings usually consist of 629 information that is best validated outside the EAP method so the 630 channel binding information is communicated external to the 631 method. 633 Mechanism Chaining 635 None of the frameworks directly support mechanism chaining. It is 636 possible for an application using one of the frameworks to define 637 a mechanism for chaining, but it would typically add complexity to 638 the application which the framework is trying to eliminate. GSS- 639 APIv3 has proposed support for stackable mechanisms [GSSSTACK] and 640 EAP has mechanisms such as [I-D.cam-winget-eap-fast] and 641 [I-D.funk-eap-ttls-v0] which allow for the chaining of multiple 642 authentication mechanisms. The ability to chain can introduce 643 complexity into the framework and can increase the difficult to 644 analyze the security of the resulting system. However mechanism 645 chaining can provide powerful building blocks to add functionality 646 into existing mechanisms and environments in a uniform way. For 647 example a mechanism can be created with the purpose of providing 648 encryption and integrity protection of messages. This mechanism 649 could then be chained to any mechanism that provides key material 650 for external use to provide protection for application data. 652 Mechanism Naming 654 All mechanisms provide a name space for identifying mechanisms 655 which is extensible. A mapping for GSS-API mechanisms into the 656 SASL name space has been defined. It should also be possible to 657 create mappings for EAP mechanisms into the GSS-API name space. 659 Principal Naming 661 All of the frameworks deal with principal naming to a certain 662 degree. GSS-API provides the facility for the initiator to 663 specifically identify the target with which it wants to establish 664 a security context with. The form of the name that is often used 665 is host based service name. This name form is also used somewhat 666 in SASL although it is less formal. EAP uses the NAI to name 667 principals; however this more often used for message routing than 668 actual identification. The target in EAP is often a "realm" or 669 "network" instead of an individual entity. SASL defines an 670 additional quantity called an authorization identity which can be 671 an alias or sub-name of the authenticated name specified in the 672 application protocol. 674 AAA integration 676 AAA integration is called out specifically here because 677 interaction with the server is required at the time of the 678 authentication. While this mechanism has some disadvantages when 679 compared with PKI or Kerberos models it is widely deployed and 680 used. EAP has direct support for integration with AAA, while only 681 certain SASL and GSS-API mechanisms can interface with a AAA 682 server. 684 4. Recommendations for Unifying Mechanisms 686 Each of the frameworks described has a particular scope of for which 687 it is most applicable. SASL is used in application environments, EAP 688 in network access environments and GSS-API in applications with 689 advanced security requirements. Even though the scope of 690 applicability is different the goals of the frameworks are very 691 similar. One approach could be to define a new authentication 692 framework that could be a superset of all the above frameworks. This 693 would be problematic since it introduces yet another framework which 694 requires not only a new set of mechanisms, but also would require 695 modifications to the consumers of these mechanisms as well. Instead 696 this document recommends that new mechanisms from this point on are 697 developed so they are generally usable in any of these frameworks. 699 The components of each of the systems can be mapped directly to one 700 another. The SASL client, EAP Peer, TLS client and GSS-API initiator 701 all perform the same role. The SASL Server, EAP Server, TLS server 702 and GSS-API acceptor all perform the same role. 704 4.1 GUAM Mechanism requirements 706 The following sections make some recommendations on requirements for 707 these mechanisms. A mechanism which adheres to these recommendations 708 would be a generally useful authentication mechanism (GUAM). 710 4.1.1 Mutual Authentication 712 A GUAM mechanism MUST provide the capability for mutual 713 authentication of two communicating entities. In some cases one or 714 more of the entities authenticated may be a "realm" instead of an 715 individual entity. It MAY also provide the ability for either or 716 both parties of the communication to remain anonymous or 717 unauthenticated. It may also provide a mechanism to protect the 718 privacy of the identity of one or more of the parties involved from 719 external parties. 721 4.1.2 Key Material Access and Security Layer 723 A GUAM mechanism MUST provide access to some key material derived 724 from the authentication exchange. Access to key material that can be 725 defined as the EAP MSK and EMSK MUST be provided. Access to 726 additional key material should be provided. Key material MUST be 727 generated such that keys are cryptographically independent from one 728 another and keys used during the authentication and in the security 729 layer. Key material MUST be bound to the authentication exchange and 730 the two parties MUST derive the same keys regardless of what order 731 they are requested. Access to certain keys may be restricted or 732 controlled. A mechanism MAY provide a security layer. If a 733 mechanism does not provide a security layer then it MUST derive an 734 additional security layer master key. This master key can be used to 735 key a generic message protection layer. (Is this key equivalent to 736 the EAP MSK/EMSK?). Note that GSS-API is defining an API to access 737 key material from GSS-API mechanisms in [I-D.ietf-kitten-gssapi-prf] 739 4.1.3 Channel Binding (GSS-API) 741 A GUAM mechanism MUST provide mechanisms to achieve channel binding. 742 This means a mechanism MUST provide a mechanism to bind underlying 743 cryptographic key material or other session related parameters to the 744 authentication exchange in a way that can be verified within the 745 mechanism (i.e. The mechanism does not know the meaning of the data, 746 just that the data used in the channel binding on both sides is the 747 same). This is to support channel bindings as defined in the GSS- 748 API. 750 A mechanism MUST also provide session data suitable for use in 751 identifying a particular instance of a mechanisms execution and to 752 serve as input to the channel bindings for another mechanism to 753 facilitate chaining and layering of mechanisms. This is to identify 754 a particular instance of an mechanism execution and the resulting 755 context. 757 4.1.4 Cryptographic Binding 759 A mechanism to achieve cryptographic binding could use the Channel 760 Bindings (GSS-API) capability. 762 4.1.5 Channel Bindings (EAP) 764 A GUAM mechanism MUST provide mechanisms to carry attribute data 765 within the authentication exchange. This is to allow for EAP style 766 channel bindings were authenticated data is exported for validation 767 outside the mechanism. 769 4.1.6 Mechanism Naming 771 A GUAM mechanism MUST have a GSS-API OID, an EAP mechanism ID and a 772 SASL name assigned. This allows the mechanism to be easily used in 773 any of these environments. It is possible to create a automatic 774 mapping between the name spaces. A particular EAP Vendor-ID could be 775 assigned to GUAM mechanisms and a base GSS-API OID could be assigned 776 to GUAM mechanisms. Then the mechanism would be identified by an 777 assigned 4 byte integer which is the EAP ID or the completion of the 778 GSS-API OID. Then the mapping between GSS-API mechanism names and 779 SASL mechanism names can be used to create SASL names. 781 4.1.7 Identity and Naming 783 There are several different types of names used in the various 784 frameworks. Mechanisms must have ways of exporting authenticated 785 names for the initiator and acceptor of the conversation. 787 EAP defines an EAP-Identity Response which is external to the 788 mechanism. Although the identity response may contain a name and a 789 realm it is primarily used for routing authentication messages so it 790 may have little no relation to the actual authenticated name. It 791 does provide a means for the EAP-Peer to specify the realm it wishes 792 to authenticate to. 794 SASL defines an Authorization identity which may be asserted by the 795 imitator of the conversation in addition to the authenticated name. 796 This name is to be used by the acceptor for authorization purposes. 797 A GUAM mechanism SHOULD provide support for transmitting the 798 authorization name. Authorization names need to have their mapping 799 to authenticated names validated. While this could be done as part 800 of the mechanism it may be advantageous to define a mapping service 801 to provide some abstraction between the mechanism and application 802 specific names. 804 4.1.8 Mechanism Initiation 806 It MUST be possible for an GUAM mechanism to be initiated by either 807 side of the conversation. This MAY be achieved by adding an "empty" 808 message to an existing protocol. 810 4.1.9 Additional Security Properties 812 [RFC3748] and [RFC4017] describe some security requirements for EAP 813 mechanisms. EAP mechanism are required to make claims about their 814 support for the various properties listed. GUAM mechanism should 815 also document which properties they are designed to meet. GUAM 816 mechanism SHOULD support the following: generation of keying 817 material, mutual authentication, shared state equivalence, replay 818 protection, integrity protection, cryptographic binding, session 819 independence, and any ciphersuite negotiation should be protected. 820 It is also desirable for GUAM mechanisms to support the following: 821 resistance to dictionary attacks, fragmentation, identity privacy, 822 confidentiality, channel bindings (EAP). 824 4.1.10 Authentication infrastructure integration 826 Different authentication infrastructures have different requirements 827 for access to third parties during authentication. In cases such as 828 Kerberos and AAA where the third party must be contacted for initial 829 authentication before a security context is established between peers 830 special consideration is needed. Since communication with the third 831 party server may not be available a GUAM mechanism SHOULD provide a 832 means to carry out this initial authentication within the 833 authentication mechanism exchange so it is possible to support 834 network access authentication. An example of this was specified in 835 IAKERB for authentication. In order to interface SASL and GSS-API 836 mechanism into a AAA server then EAP can be used as the interface 837 into AAA and specialized mechanisms or framework enhancements could 838 be used to take the exported EAP-AAA security context into a SASL or 839 GSS-API context. (This would look like GSS-API between client and 840 server, and EAP between server and AAA server, the context exported 841 from the AAA server to the AAA client could then be used to create a 842 GSS-API security context. Perhaps this could be done using stackable 843 mechanisms. The client would probably have to know that a AAA server 844 was in use.) 846 4.2 GUAM Framework Enhancements 848 This section discusses enhancements for the various frameworks to 849 support and take full advantage of the GUAM mechanisms. None of 850 these enhancements are required, but they described are here are to 851 enable useful functionality across all the frameworks. 853 4.2.1 GSS-API 855 GSS-API SHOULD provide the API to access all GUAM functionality. 857 o API to PRF to retrieve keys 859 o API to send and receive channel binding (EAP) data as part of 860 authentication. This might be done as part of naming 861 enhancements. 863 o Enhancements for exporting and value that identifies a particular 864 execution of the mechanism. 866 o Enhancements for importing an EAP-AAA context. 868 o Enhancement to naming to identify realms. 870 4.2.2 SASL 872 For the most part SASL is trying to provide a simpler interface to 873 authentication so additional enhancements would probably be 874 undesirable. Unless there are serious security or usability 875 implications the interface should remain unchanged. SASL 876 functionality should be described in terms of GSS-API calls to GUAM 877 mechanisms. Some existing SASL mechanisms may not be GUAM 878 mechanisms. It would be good to extend SASL in a backwards 879 compatible way to support features such as channel bindings, 880 mechanism execution instance identifiers, and EAP-AAA context 881 integration. 883 4.2.3 EAP 885 Similar to SASL EAP is already widely deployed so changes are costly. 886 Unless there are serious security or usability implications the 887 interface should remain unchanged. EAP functionality should be 888 described in terms of GSS-API calls to a GUAM mechanism. Some 889 existing EAP mechanisms may not be GUAM mechanisms. 891 4.2.4 TLS 893 TLS is already widely deployed so changes are costly. Unless there 894 are serious security or usability implications the interface should 895 remain unchanged. Because it is so successful it is probably good to 896 develop a GUAM mechanism based on TLS. 898 4.2.5 Security Layer 900 It may be advantageous to provide a generic security layer/ per- 901 message protection that can be used by mechanisms that generate keys, 902 but do not specify a security layer. 904 4.2.6 Negotiation 906 It is undesirable to have multiple layers of negotiation, especially 907 when the different negotiation mechanisms have different security 908 properties. In general secure negotiation mechanisms should be 909 favored over insecure ones. Recursive negotiation of methods such as 910 TLS negotiation a GUAM mechanism which in turn is based on TLS should 911 be avoided. 913 4.2.7 Mechanism Gateways 915 Mechanism gateways provide a way to use one mechanism in another 916 framework. In general the GUAM provide a consistent set of 917 functionality in all frameworks so they should work well in mechanism 918 gateways. This is already possible to map GSS-API mechanisms to 919 SASL. It would be easy to define mechanisms to map EAP to GSS-API 920 and probably vice-versa. A set of GSS-API/GUAM ciphersuites should 921 also be developed for TLS to make it easier for TLS to make use of 922 different authentication mechanisms and infrastructures. 924 4.2.8 Name Mapping 926 A name mapping service may be useful to provide an authorized mapping 927 between authenticated names and attributes and names that are usable 928 by an application for authorization and auditing. 930 4.3 Recommended GUAM Mechanisms 932 The following mechanisms may be good candidates for GUAM mechanisms: 934 o A TLS based mechanisms similar to EAP-TLS 936 o A digest authentication mechanism 938 o A Kerberos V mechanism that provided in-band initial 939 authentication (i.e. In band AS and TGS exchanges) 941 o A hybrid public key/protected password mechanism such as one that 942 allows a one time password to be sent within a TLS channel 944 o A pre-shared key mechanism. 946 o An SRP based mechanism 948 5. Security Considerations 950 5.1 Lying NAS 952 Traditionally in this case all services providing network access 953 (network access server or NAS) provide the same server, therefore a 954 client requesting network access was not concerned as to which NAS 955 they were talking to, but rather that they were talking to a NAS that 956 was an authorized member of the network. The means the client may 957 know the identity of the AAA server or network, but often cannot 958 differentiate between one service and another. This can cause 959 problems when different services can be authorized to provide 960 different resources or functions for clients. This problem is often 961 referred to as the lying network access server (NAS) problem. It is 962 possible for the service to advertise capabilities that it is not 963 authorized for and the client would not be able to catch this. This 964 problem is not unique to EAP, any mechanism that integrates with a 965 AAA server (or other types of back end servers) may have this 966 problem. In this case it is often necessary for the supplicant to 967 inform the AAA server of the claimed identity and authorizations of 968 the service, or to inform the client what capabilities are authorized 969 to a particular service. The AAA server or client can then verify 970 that the service is authorized to advertise these resources. 972 This problem is not unique to AAA and EAP. In SASL digest 973 authentication a user is typically authenticated to a "realm." There 974 is no way through the mechanism itself to determine which server in 975 the realm the client is communicating with. 977 5.2 Cryptographic binding between mechanisms 979 When more than one authentication transaction is taking place it is 980 often a good idea to bind one authentication transaction to another 981 to ensure that the endpoints are the same in both cases. This can 982 help to avoid some types man-in-the-middle attacks. Channel Bindings 983 (GSS-API) can be used for this purpose. 985 5.3 Clear text passwords and PAP 987 Clear text passwords are commonly used authentication mechanism on 988 the Internet today. Increasingly they are used within a secure 989 tunnel, such as one provided by TLS, which is an improvement. 990 However the use of clear text passwords is still problematic since it 991 exposes the clear text password to entities that may not need to know 992 the password thereby increasing the exposure of the shared secret. 993 In addition when a clear text password is used in RADIUS it is sent 994 in a PAP authentication request. RADIUS PAP may provide insufficient 995 protection unless it is used with additional security measures that 996 prevent password guessing and modification attacks. 998 5.4 Exporting Contexts 1000 Security contexts may contains sensitive information such as 1001 cryptographic keys so care should be taken when exporting them. 1003 5.5 Unauthenticated Identities 1005 Some of the frameworks discussed support the communication of 1006 identities outside of the authentication exchange. It is important 1007 to realize that these identities are unauthenticated and may have no 1008 relation to the authenticated identity. These identities should be 1009 used with caution. 1011 6. IANA Considerations 1013 To be determined. 1015 7. Acknowledgements 1017 Nicolas Williams and Sam Hartman provided valuable discussions and 1018 feedback that went into the preparation of this document. 1020 8. References 1022 8.1 Normative References 1024 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1025 (SASL)", RFC 2222, October 1997. 1027 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1028 RFC 2246, January 1999. 1030 [RFC2743] Linn, J., "Generic Security Service Application Program 1031 Interface Version 2, Update 1", RFC 2743, January 2000. 1033 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1034 Levkowetz, "Extensible Authentication Protocol (EAP)", 1035 RFC 3748, June 2004. 1037 8.2 Informative References 1039 [I-D.arkko-eap-service-identity-auth] 1040 Arkko, J. and P. Eronen, "Authenticated Service 1041 Information for the Extensible Authentication Protocol 1042 (EAP)", draft-arkko-eap-service-identity-auth-02 (work in 1043 progress), May 2005. 1045 [I-D.cam-winget-eap-fast] 1046 Salowey, J., "EAP Flexible Authentication via Secure 1047 Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work 1048 in progress), April 2005. 1050 [I-D.funk-eap-ttls-v0] 1051 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 1052 Authentication Protocol Version 0 (EAP-TTLSv0)", 1053 draft-funk-eap-ttls-v0-00 (work in progress), 1054 February 2005. 1056 [I-D.iab-auth-mech] 1057 Rescorla, E., "A Survey of Authentication Mechanisms", 1058 draft-iab-auth-mech-03 (work in progress), March 2004. 1060 [I-D.ietf-kitten-2478bis] 1061 Zhu, L., "The Simple and Protected GSS-API Negotiation 1062 Mechanism", draft-ietf-kitten-2478bis-05 (work in 1063 progress), January 2005. 1065 [I-D.ietf-kitten-gssapi-prf] 1066 Williams, N., "A PRF API extension for the GSS-API", 1067 draft-ietf-kitten-gssapi-prf-04 (work in progress), 1068 June 2005. 1070 [I-D.ietf-krb-wg-gssapi-cfx] 1071 Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1072 Version 5 GSS-API Mechanism: Version 2", 1073 draft-ietf-krb-wg-gssapi-cfx-07 (work in progress), 1074 March 2004. 1076 [I-D.ietf-radext-digest-auth] 1077 Sterman, B., "RADIUS Extension for Digest Authentication", 1078 draft-ietf-radext-digest-auth-02 (work in progress), 1079 April 2005. 1081 [I-D.williams-gssapi-v3-guide-to] 1082 Williams, N., "Guide to the GSS-APIv3", 1083 draft-williams-gssapi-v3-guide-to-00 (work in progress), 1084 October 2004. 1086 [RFC1508] Linn, J., "Generic Security Service Application Program 1087 Interface", RFC 1508, September 1993. 1089 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 1090 Authentication Service (V5)", RFC 1510, September 1993. 1092 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 1093 (SPKM)", RFC 2025, October 1996. 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", 1099 RFC 2444, October 1998. 1101 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1102 RFC 2486, January 1999. 1104 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1105 RFC 2595, June 1999. 1107 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1108 Suites to Transport Layer Security (TLS)", RFC 2712, 1109 October 1999. 1111 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 1112 Protocol", RFC 2716, October 1999. 1114 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a 1115 SASL Mechanism", RFC 2831, May 2000. 1117 [RFC2847] Eisler, M., "LIPKEY - A Low Infrastructure Public Key 1118 Mechanism Using SPKM", RFC 2847, June 2000. 1120 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1121 "Remote Authentication Dial In User Service (RADIUS)", 1122 RFC 2865, June 2000. 1124 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1125 X.509 Public Key Infrastructure Certificate and 1126 Certificate Revocation List (CRL) Profile", RFC 3280, 1127 April 2002. 1129 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1130 Dial In User Service) Support For Extensible 1131 Authentication Protocol (EAP)", RFC 3579, September 2003. 1133 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1134 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1136 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1137 Authentication Protocol (EAP) Method Requirements for 1138 Wireless LANs", RFC 4017, March 2005. 1140 Author's Address 1142 Joseph Salowey 1143 Cisco Systems 1145 Email: jsalowey@cisco.com 1147 Intellectual Property Statement 1149 The IETF takes no position regarding the validity or scope of any 1150 Intellectual Property Rights or other rights that might be claimed to 1151 pertain to the implementation or use of the technology described in 1152 this document or the extent to which any license under such rights 1153 might or might not be available; nor does it represent that it has 1154 made any independent effort to identify any such rights. Information 1155 on the procedures with respect to rights in RFC documents can be 1156 found in BCP 78 and BCP 79. 1158 Copies of IPR disclosures made to the IETF Secretariat and any 1159 assurances of licenses to be made available, or the result of an 1160 attempt made to obtain a general license or permission for the use of 1161 such proprietary rights by implementers or users of this 1162 specification can be obtained from the IETF on-line IPR repository at 1163 http://www.ietf.org/ipr. 1165 The IETF invites any interested party to bring to its attention any 1166 copyrights, patents or patent applications, or other proprietary 1167 rights that may cover technology that may be required to implement 1168 this standard. Please address the information to the IETF at 1169 ietf-ipr@ietf.org. 1171 Disclaimer of Validity 1173 This document and the information contained herein are provided on an 1174 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1175 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1176 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1177 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1178 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1179 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1181 Copyright Statement 1183 Copyright (C) The Internet Society (2005). This document is subject 1184 to the rights, licenses and restrictions contained in BCP 78, and 1185 except as set forth therein, the authors retain all their rights. 1187 Acknowledgment 1189 Funding for the RFC Editor function is currently provided by the 1190 Internet Society.