idnits 2.17.1 draft-howlett-eap-gss-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 5167 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: 'APPLICATION 0' is mentioned on line 394, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-emu-chbind-04 ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4402 (Obsoleted by RFC 7802) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman, Ed. 3 Internet-Draft Painless Security 4 Intended status: Standards Track J. Howlett 5 Expires: September 2, 2010 JANET(UK) 6 March 1, 2010 8 A GSS-API Mechanism for the Extensible Authentication Protocol 9 draft-howlett-eap-gss-00.txt 11 Abstract 13 This document defines protocols, procedures, and conventions to be 14 employed by peers implementing the Generic Security Service 15 Application Program Interface (GSS-API) when using the EAP mechanism. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 2, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Secure Association Protocol . . . . . . . . . . . . . . . 5 61 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 62 3. EAP Channel Binding and Naming . . . . . . . . . . . . . . . . 7 63 3.1. Mechanism Name Format . . . . . . . . . . . . . . . . . . 7 64 3.2. Exported Mechanism Names . . . . . . . . . . . . . . . . . 9 65 3.3. Acceptor Name RADIUS AVP . . . . . . . . . . . . . . . . . 9 66 3.4. Proxy Verification of Acceptor Name . . . . . . . . . . . 9 67 4. Selection of EAP Method . . . . . . . . . . . . . . . . . . . 10 68 5. Context Tokens . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Mechanisms and Encryption Types . . . . . . . . . . . . . 11 70 5.2. Context Options . . . . . . . . . . . . . . . . . . . . . 11 71 6. Acceptor Services . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 13 73 6.2. Per-message security . . . . . . . . . . . . . . . . . . . 13 74 6.3. Pseudo Random Function . . . . . . . . . . . . . . . . . . 13 75 7. Authorization and Naming Extensions . . . . . . . . . . . . . 14 76 8. Applicability Considerations . . . . . . . . . . . . . . . . . 15 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 The Extensible Authentication Protocol (EAP) [RFC3748] defines a 86 framework for authenticating a network access client and server in 87 order to gain access to a network. A variety of different EAP 88 methods are in wide use; one of EAP's strengths is that for most 89 types of credentials in common use, there is an EAP method that 90 permits the credential to be used. 92 EAP is often used in conjunction with a backend authentication server 93 via RADIUS [RFC3579] or Diameter [RFC4072]. In this mode, the NAS 94 simply tunnels EAP packets over the backend authentication protocol 95 to a home EAP/AAA server for the client. After EAP succeeds, the 96 backend authentication protocol is used to communicate key material 97 to the NAS. In this mode, the NAS need not be aware of or have any 98 specific support for the EAP method used between the client and the 99 home EAP server. The client and EAP server share a credential that 100 depends on the EAP method; the NAS and AAA server share a credential 101 based on the backend authentication protocol in use. The backend 102 authentication server acts as a trusted third party enabling network 103 access even though the client and NAS may not actually share any 104 common authentication methods. Using AAA proxies, this mode can be 105 extended beyond one organization to provide federated authentication 106 for network access. 108 The Generic Security Services Application Programming Interface (GSS- 109 API) [RFC2743] provides a generic framework for applications to use 110 security services including authentication and per-message data 111 security services. Between protocols that support GSS-API directly 112 or protocols that support SASL [RFC4422], many application protocols 113 can use GSS-API for security services. However, with the exception 114 of Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the 115 Internet. While GSS-API permits an application to be written 116 independent of the specific GSS-API mechanism in use, there is no 117 facility to separate the server from the implementation of the 118 mechanism as there is with EAP and backend authentication servers. 120 The goal of this specification is to combine GSS-API's support for 121 application protocols with EAP/AAA's support for common credential 122 types and for authenticating to a server without requiring that 123 server to specifically support the authentication method in use. In 124 addition, this specification supports the use of the Security 125 Assertion Markup Language to transport assertions about attributes of 126 client subjects to servers. Together this combination will provide 127 federated authentication and authorisation for GSS-API applications. 129 This mechanism is a GSS-API mechanism that encapsulates an EAP 130 conversation. From the perspective of RFC 3748, this specification 131 defines a new lower-layer protocol for EAP. 133 Section 1.3 of [RFC5247] outlines the typical conversation between 134 EAP peers where an EAP key is derived: 136 o Phase 0: Discovery 138 o Phase 1: Authentication 140 o 1a: EAP authentication 142 o 1b: AAA Key Transport (optional) 144 o Phase 2: Secure Association Protocol 146 o 2a: Unicast Secure Association 148 o 2b: Multicast Secure Association (optional) 150 1.1. Discovery 152 GSS-API peers discover each other and discover support for GSS-API in 153 an application-dependent mechanism. SASL [RFC4422] describes how 154 discovery of a particular SASL mechanism such as a GSS-API mechanism 155 is conducted. The Simple and Protected Negotiation mechanism 156 (SPNEGO) [RFC4178] provides another approach for discovering what 157 GSS-API mechanisms are available. The specific approach used for 158 discovery is out of scope for this mechanism. 160 1.2. Authentication 162 GSS-API authenticates a party called the GSS-API initiator to the 163 GSS-API acceptor, optionally providing authentication of the acceptor 164 to the initiator. Authentication starts with a mechanism-specific 165 message called a context token sent from the initiator to the 166 acceptor. The acceptor may respond, followed by the initiator, and 167 so on until authentication succeeds or fails. GSS-API context tokens 168 are reliably delivered by the application using GSS-API. The 169 application is responsible for in-order delivery and retransmission. 171 EAP authentication can be started by either the peer or the 172 authenticator. The EAP peer maps onto the GSS-API initiator and the 173 EAP authenticator and EAP server maps onto the GSS-API acceptor. EAP 174 messages from the peer to the authenticator are called responses; 175 messages from the authenticator to the peer are called requests. 177 This specification permits a GSS-API peer to hand-off the processing 178 of the EAP packets to a remote EAP server by using AAA protocols such 179 as RADIUS, RadSec or Diameter. In this case, the GSS-API peer acts 180 as an EAP pass-through authenticator. If EAP authentication is 181 successful, and where the chosen EAP method supports key derivation, 182 EAP keying material may also be derived. If an AAA protocol is used, 183 this can also be used to replicate the EAP Key from the EAP server to 184 the EAP authenticator. 186 See Section 5 for details of the authentication exchange. 188 1.3. Secure Association Protocol 190 After authentication succeeds, GSS-API provides a number of per- 191 message security services that can be used: 193 GSS_Wrap() provides integrity and optional confidentiality for a 194 message. 196 GSS_GetMIC() provides integrity protection for data sent 197 independently of the GSS-API 199 GSS_Pseudo_random [RFC4401] provides key derivation functionality. 201 These services perform a function similar to security association 202 protocols in network access. Like security association protocols, 203 these services need to be performed near the authenticator/acceptor 204 even when a AAA protocol is used to separate the authenticator from 205 the EAP server. The key used for these per-message services is 206 derived from the EAP key; the EAP peer and authenticator derive this 207 key as a result of a successful EAP authentication. In the case that 208 the EAP authenticator is acting as a pass-through it obtains it via 209 the AAA protocol. See Section 6 for details. 211 2. Requirements notation 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 3. EAP Channel Binding and Naming 219 EAP authenticates a realm. The peer knows that it has exchanged 220 authentication with an EAP server in a given realm. Today, the peer 221 does not typically know which NAS it is talking to securely. That is 222 often fine for network access. However privileges to delegate to a 223 chat server seem very different than privileges for a file server or 224 trading site. Also, an EAP peer knows the identity of the home 225 realm, but perhaps not even the visited realm. 227 In contrast, GSS-API takes a name for both the initiator and acceptor 228 as inputs to the authentication process. When mutual authentication 229 is used, both parties are authenticated. The granularity of these 230 names is somewhat mechanism dependent. In the case of the Kerberos 231 mechanism, the acceptor name typically identifies both the protocol 232 in use (such as IMAP) and the specific instance of the service being 233 connected to. The acceptor name almost always identifies the 234 administrative domain providing service. 236 An EAP GSS-API mechanism needs to provide GSS-API naming semantics in 237 order to work with existing GSS-API applications. EAP channel 238 binding [I-D.ietf-emu-chbind] is used to provide GSS-API naming 239 semantics. Channel binding sends a set of attributes from the peer 240 to the EAP server either as part of the EAP conversation or as part 241 of a secure association protocol. In addition, attributes are sent 242 in the backend authentication protocol from the authenticator to the 243 EAP server. The EAP server confirms the consistency of these 244 attributes. Confirming attribute consistency also involves checking 245 consistency against a local policy database as discussed below. In 246 particular, the peer sends the name of the acceptor it is 247 authenticating to as part of channel binding. The acceptor sends its 248 full name as part of the backend authentication protocol. The EAP 249 server confirms consistency of the names. 251 EAP channel binding is easily confused with a facility in GSS-API 252 also called channel binding. GSS-API channel binding provides 253 protection against man-in-the-middle attacks when GSS-API is used as 254 authentication inside some tunnel; it is similar to a facility called 255 cryptographic binding in EAP. See [RFC5056] for a discussion of the 256 differences between these two facilities and Section 6.1 for how GSS- 257 API channel binding is handled in this mechanism. 259 3.1. Mechanism Name Format 261 Before discussing how the initiator and acceptor names are validated 262 in the AAA infrastructure, it is necessary to discuss what composes a 263 name for an EAP GSS-API mechanism. GSS-API permits several types of 264 generic names to be imported using GSS_Import_name(). Once a 265 mechanism is chosen, these names are converted into a mechanism name 266 form. This section first discusses name types that need to be 267 imported and then discusses the structure of the mechanism name. 269 The GSS_C_NT_USER_NAME form represents the name of an individual 270 user. From the standpoint of this mechanism it may take the form 271 either of an undecorated user name or a network access identifier 272 (NAI) [RFC4282]. 274 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 275 on a host; it is textually represented as "HOST@SERVICE". This name 276 form is required by most SASL profiles and is used by many existing 277 applications that use the Kerberos GSS-API mechanism. While support 278 for this name form is critical, it presents an interesting challenge 279 in terms of channel binding. Consider a case where the server 280 communicates with a "server proxy," or a AAA server near the server. 281 That server proxy communicates with the EAP server. The EAP server 282 and server proxy are in different administrative realms. The server 283 proxy is in a position to verify that the request comes from the 284 indicated host. However the EAP server cannot make this 285 determination directly. So, the EAP server needs to determine 286 whether to trust the server proxy to verify the host portion of the 287 acceptor name. This trust decision depends both on the host name and 288 the realm of the server proxy. In effect, the EAP server decides 289 whether to trust that the realm of the server proxy is the right 290 realm for the given hostname and then makes a trust decision about 291 the server proxy itself. The same problem appears in Kerberos: 292 there, clients decide what Kerberos realm to trust for a given 293 hostname. 295 Sometimes, the client may know what AAA realm a particular host 296 should belong to. In this case it would be desirable to use a name 297 form that included a service, host and realm. Syntactically, this 298 appears the same as the domain-based name discussed in [RFC5178], but 299 the semantics do not appear sufficiently similar to use the same name 300 form. 302 A name form is needed to identify a SAML endpoint and a specific 303 instance of SAML metadata associated with that endpoint. The 304 metadata describes properties of the endpoint including public keys. 305 One of the motivating use cases is to be able to use GSS-API to build 306 trust in this metadata. In this case it is desirable to authenticate 307 to an acceptor based on the endpoint and a cryptographic hash of the 308 metadata. 310 The mechanism name form must be able to represent all of these names. 311 In addition, the mechanism name form MUST make it easy for 312 intermediate AAA proxies to extract the hostname portion when 313 present. One possible starting point is the Kerberos name form 314 discussed in [RFC1964]. The major down side of that approach is that 315 there is no guaranteed way to be able to extract a hostname from a 316 Kerberos name. Also, Kerberos naming may provide more flexibility 317 than is needed. 319 3.2. Exported Mechanism Names 321 GSS-API provides the GSS_Export_name call. This call can be used to 322 export the binary representation of a name. This name form can be 323 stored on access control lists for binary comparison. 325 This section defines the format of the exported name token for this 326 mechanism. 328 3.3. Acceptor Name RADIUS AVP 330 This section defines an attribute-value pair for transporting the 331 name of the acceptor in a RADIUS or Diameter message. This AVP is 332 included by the server to indicate the acceptor name it claims. This 333 AVP is included in channel bindings by the client to indicate what 334 acceptor is authenticated against. 336 3.4. Proxy Verification of Acceptor Name 337 4. Selection of EAP Method 339 The specification currently describes a single GSS-API mechanism. 340 The peer and authenticator exchange EAP messages. The GSS-API 341 mechanism specifies no constraints about what EAP method types are 342 used; text in the specification says that negotiation of which EAP 343 method to use happens at the EAP layer. 345 EAP does not provide a facility for an EAP server to advertise what 346 methods are available to a peer. Instead, a server starts with its 347 preferred method selection. If the peer does not accept that method, 348 the peer sends a NAK response containing the list of methods 349 supported by the client. 351 Providing multiple facilities to negotiate which security mechanism 352 to use is undesirable. Section 7.3 of [RFC4462]describes the problem 353 referencing the SSH key exchange negotiation and the SPNEGO GSS-API 354 mechanism. If a client preferred an EAP method A, a non-EAP 355 authentication mechanism B, and then an EAP method C, then the client 356 would have to commit to using EAP before learning whether A is 357 actually supported. Such a client might end up using C when B is 358 available. 360 The standard solution to this problem is to perform all the 361 negotiation at one layer. In this case, rather than defining a 362 single GSS-API mechanism, a family of mechanisms should be defined. 363 Each mechanism corresponds to an EAP method. The EAP method type 364 should be part of the GSS-API OID. Then, a GSS-API rather than EAP 365 facility can be used for negotiation. 367 Unfortunately, using a family of mechanisms has a number of problems. 368 First, GSS-API assumes that both the initiator and acceptor know the 369 entire set of mechanisms that are available. Some negotiation 370 mechanisms are driven by the client; others are driven by the server. 371 With EAP GSS-API, the acceptor does not know what methods the EAP 372 server implements. The EAP server that is used depends on the 373 identity of the client. The best solution so far is to accept the 374 disadvantages of multi-layer negotiation and commit to using EAP GSS- 375 API before a specific EAP method. This has two main disadvantages. 376 First, authentication may fail when other methods might allow 377 authentication to succeed. Second, a non-optimal security mechanism 378 may be chosen. 380 5. Context Tokens 382 All context establishment tokens emitted by the EAP mechanism SHALL 383 have the framing described in section 3.1 of [RFC2743], as 384 illustrated by the following pseudo-ASN.1 structures: 386 GSS-API DEFINITIONS ::= 387 BEGIN 389 MechType ::= OBJECT IDENTIFIER 390 -- representing EAP mechanism 391 GSSAPI-Token ::= 392 -- option indication (delegation, etc.) indicated within 393 -- mechanism-specific token 394 [APPLICATION 0] IMPLICIT SEQUENCE { 395 thisMech MechType, 396 innerToken ANY DEFINED BY thisMech 397 -- contents mechanism-specific 398 -- ASN.1 structure not required 399 } 400 END 402 The innerToken field contains an EAP packet or special token. The 403 first EAP packet SHALL be a EAP response/identity packet from the 404 initiator to acceptor. The acceptor SHALL respond either with an EAP 405 request or an EAP failure packet. 407 The initiator and acceptor will continue exchanging response/request 408 packets until authentication succeeds or fails. 410 After the EAP authentication succeeds, channel binding tokens are 411 exchanged; see Section 6.1 for details. Currently, the channel 412 binding tokens are the only types of special tokens in use. 414 5.1. Mechanisms and Encryption Types 416 This mechanism family uses the security services of the Kerberos 417 cryptographic framework [RFC3961]. As such, a particular encryption 418 type needs to be chosen. A new GSS-API OID should be defined for EAP 419 GSS-API with a given Kerberos crypto system. This document defines 420 the eap-aes128-cts-hmac-sha1-96 GSS-API mechanism. XXX define an OID 421 for that and use the right language to get that into the appropriate 422 SASL registry. 424 5.2. Context Options 426 GSS-API provides a number of optional per-context services requested 427 by flags on the call to GSS_Init_sec_context and indicated as outputs 428 from both GSS_Init_sec_context and GSS_Accept_sec_context. This 429 section describes how these services are handled. 431 Integrity, confidentiality, sequencing and replay detection are 432 always available. Regardless of what flags are requested in 433 GSS_Init_sec_context, implementations MUST set the flag corresponding 434 to these services in the output of GSS_Init_sec_context and 435 GSS_Accept_sec_context. 437 The PROT_READY service is never available with this mechanism. 438 Implementations MUST NOT offer this flag or permit per-message 439 security services to be used before context establishment. 441 Open issue: how is the mutual authentication request and return 442 handled? The big question here is figuring out how this interacts 443 with EAP and transporting state back to a pass-through authenticator. 445 Open issue: handling of lifetime parameters. 447 6. Acceptor Services 449 The context establishment process may be passed through to a EAP 450 server via a backend authentication protocol. However after the EAP 451 authentication succeeds, security services are provided directly by 452 the acceptor. 454 This mechanism uses an RFC 3961 cryptographic key called the context 455 root key (CRK). The CRK is the result of the random-to-key operation 456 consuming the appropriate number of bits from the EAP master session 457 key. For example for aes128-cts-hmac-sha1-96, the random-to-key 458 operation consumes 16 octets of key material; thus the first 16 bytes 459 of the master session key are input to random-to-key to form the CRK. 461 6.1. GSS-API Channel Binding 463 GSS-API channel binding [RFC5554] is a protected facility for 464 exchanging a cryptographic name for an enclosing channel between the 465 initiator and acceptor. The initiator sends channel binding data and 466 the acceptor confirms that channel binding data has been checked. 468 The acceptor SHOULD accept any channel binding providing by the 469 initiator if null channel bindings are passed into 470 gss_accept_sec_context. Protocols such as HTTP Negotiate depend on 471 this behavior of some Kerberos implementations. It is reasonable for 472 the protocol to distinguish an acceptor ignoring channel bindings 473 from an acceptor successfully validating them. No facility is 474 currently provided for an initiator implementation to expose this 475 distinction to the initiator code. 477 Define a token format, token ID and key usage for this token. 479 6.2. Per-message security 481 The per-message tokens of section 4 of RFC 4121 are used. The CRK 482 SHALL be treated as the initiator sub-session key, the acceptor sub- 483 session key and the ticket session key. 485 6.3. Pseudo Random Function 487 The pseudo random function defined in [RFC4402] is used. 489 7. Authorization and Naming Extensions 491 One goal of this mechanism is to support retrieving a SAML assertion 492 as a result of the EAP authentication. The GSS-API naming extensions 493 will be used to access this message. This section will be expanded 494 to discuss details. 496 8. Applicability Considerations 498 Section 1.3 of RFC 3748 provides the applicability statement for EAP. 499 Among other constraints, EAP is scoped for use in network access. 500 This specification anticipates using EAP beyond its current scope. 501 The assumption is that some other document will discuss the issues 502 surrounding the use of EAP for application authentication and expand 503 EAP's applicability. That document will likely enumerate 504 considerations that a specific use of EAP for application 505 authentication needs to handle. Examples of such considerations 506 might include the multi-layer negotiation issue, deciding when EAP or 507 some other mechanism should be used, and so forth. This section 508 serves as a placeholder to discuss any such issues with regard to the 509 use of EAP and GSS-API. 511 9. Security Considerations 513 RFC 3748 discusses security issues surrounding EAP. RFC 5247 514 discusses the security and requirements surrounding key management 515 that leverages the AAA infrastructure. These documents are critical 516 to the security analysis of this mechanism. 518 RFC 2743 discusses generic security considerations for the GSS-API. 519 RFC 4121 discusses security issues surrounding the specific per- 520 message services used in this mechanism. 522 As discussed in Section 4, this mechanism may introduce multiple 523 layers of security negotiation into application protocols. Multiple 524 layer negotiations are vulnerable to a bid-down attack when a 525 mechanism negotiated at the outer layer is preferred to some but not 526 all mechanisms negotiated at the inner layer; see section 7.3 of 527 [RFC4462] for an example. One possible approach to mitigate this 528 attack is to construct security policy such that the preference for 529 all mechanisms negotiated in the inner layer falls between 530 preferences for two outer layer mechanisms or falls at one end of the 531 overall ranked preferences including both the inner and outer layer. 532 Another approach is to only use this mechanism when it has 533 specifically been selected for a given service. The second approach 534 is likely to be common in practice because one common deployment will 535 involved an EAP supplicant interacting with a user to select a given 536 identity. Only when an identity is successfully chosen by the user 537 will this mechanism be attempted. 539 The security of this mechanism depends on the use and verification of 540 EAP channel binding. Today EAP channel binding is in very limited 541 deployment. If EAP channel binding is not used, then the system may 542 be vulnerable to phishing attacks where a user is diverted from one 543 service to another. These attacks are possible with EAP today 544 although not typically with common GSS-API mechanisms. 546 Every proxy in the AAA chain from the authenticator to the EAP server 547 needs to be trusted to help verify channel bindings and to protect 548 the integrity of key material. GSS-API applications may be built to 549 assume a trust model where the acceptor is directly responsible for 550 authentication. However, GSS-API is definitely used with trusted- 551 third-party mechanisms such as Kerberos. 553 10. References 555 10.1. Normative References 557 [I-D.ietf-emu-chbind] 558 Clancy, C. and K. Hoeper, "Channel Binding Support for EAP 559 Methods", draft-ietf-emu-chbind-04 (work in progress), 560 October 2009. 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC2743] Linn, J., "Generic Security Service Application Program 566 Interface Version 2, Update 1", RFC 2743, January 2000. 568 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 569 Levkowetz, "Extensible Authentication Protocol (EAP)", 570 RFC 3748, June 2004. 572 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 573 Kerberos 5", RFC 3961, February 2005. 575 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 576 Version 5 Generic Security Service Application Program 577 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 578 July 2005. 580 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 581 Network Access Identifier", RFC 4282, December 2005. 583 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 584 Extension for the Generic Security Service Application 585 Program Interface (GSS-API)", RFC 4401, February 2006. 587 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 588 Kerberos V Generic Security Service Application Program 589 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 591 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 592 Channels", RFC 5056, November 2007. 594 [RFC5554] Williams, N., "Clarifications and Extensions to the 595 Generic Security Service Application Program Interface 596 (GSS-API) for the Use of Channel Bindings", RFC 5554, 597 May 2009. 599 10.2. Informative References 601 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 602 RFC 1964, June 1996. 604 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 605 Dial In User Service) Support For Extensible 606 Authentication Protocol (EAP)", RFC 3579, September 2003. 608 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 609 Authentication Protocol (EAP) Application", RFC 4072, 610 August 2005. 612 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 613 Simple and Protected Generic Security Service Application 614 Program Interface (GSS-API) Negotiation Mechanism", 615 RFC 4178, October 2005. 617 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 618 Security Layer (SASL)", RFC 4422, June 2006. 620 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 621 "Generic Security Service Application Program Interface 622 (GSS-API) Authentication and Key Exchange for the Secure 623 Shell (SSH) Protocol", RFC 4462, May 2006. 625 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 626 Application Program Interface (GSS-API) 627 Internationalization and Domain-Based Service Names and 628 Name Type", RFC 5178, May 2008. 630 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 631 Authentication Protocol (EAP) Key Management Framework", 632 RFC 5247, August 2008. 634 Authors' Addresses 636 Sam Hartman (editor) 637 Painless Security 639 Email: hartmans-ietf@mit.edu 641 Josh Howlett 642 JANET(UK) 644 Email: josh.howlett@ja.net