idnits 2.17.1 draft-salowey-guam-mech-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 879. ** 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 25, 2006) is 6507 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: 'TBD' is mentioned on line 758, but not defined == Unused Reference: 'I-D.ietf-sasl-rfc2222bis' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'I-D.adrangi-eap-network-discovery' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'I-D.salowey-guam' is defined on line 829, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 == Outdated reference: A later version (-08) exists of draft-ietf-sasl-gssapi-06 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 27, 2006 June 25, 2006 6 Guidelines for Creating Generally Useful Authentication Mechanisms 7 (GUAM) 8 draft-salowey-guam-mech-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Generic Security Services API (GSS-API), the Simple Authentication 42 and Security Layer (SASL), and the Extensible Authentication Protocol 43 (EAP) are three authentication and frameworks used within the IETF 44 that have similar goals. This document describes guidelines for 45 creating authentication mechanisms that are generally usable in any 46 of these frameworks. 48 Table of Contents 50 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1 GSS-API Model . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2 SASL Model . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3 EAP Model . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Mechanism Guidelines . . . . . . . . . . . . . . . . . . . . 6 56 3.1 Mechanism Naming . . . . . . . . . . . . . . . . . . . . . 6 57 3.2 Framing and Protocol . . . . . . . . . . . . . . . . . . . 6 58 3.3 Mechanism Security Properties . . . . . . . . . . . . . . 8 59 3.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 9 60 3.5 Security Layer . . . . . . . . . . . . . . . . . . . . . . 10 61 3.6 Target Identification . . . . . . . . . . . . . . . . . . 10 62 3.7 Session Identification . . . . . . . . . . . . . . . . . . 12 63 3.8 Channel Binding . . . . . . . . . . . . . . . . . . . . . 12 64 3.9 Principal Naming and Attributes . . . . . . . . . . . . . 14 65 3.10 Mechanism Negotiation . . . . . . . . . . . . . . . . . 15 66 3.11 Indentity Protection . . . . . . . . . . . . . . . . . . 16 67 3.12 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 16 68 4. Tools for creating GUAM mechanisms . . . . . . . . . . . . . 17 69 4.1 Mechanism Bridges . . . . . . . . . . . . . . . . . . . . 17 70 4.2 Protocol Initiation . . . . . . . . . . . . . . . . . . . 17 71 4.3 Generic PRF . . . . . . . . . . . . . . . . . . . . . . . 17 72 4.4 Generic Per-Message Security Layer . . . . . . . . . . . . 17 73 4.5 Fragmentation Support . . . . . . . . . . . . . . . . . . 18 74 4.6 Channel Binding and Authenticated Data . . . . . . . . . . 18 75 4.7 Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 18 76 4.8 Mechanism Naming . . . . . . . . . . . . . . . . . . . . . 18 77 4.9 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 5. Interface Specification . . . . . . . . . . . . . . . . . . 20 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 80 7. Security Considerations . . . . . . . . . . . . . . . . . . 22 81 7.1 Same mechanism accessed through different frameworks . . . 22 82 7.2 Algorithm identification and negotiation . . . . . . . . . 22 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 9.1 Normative References . . . . . . . . . . . . . . . . . . . 24 86 9.2 Informative References . . . . . . . . . . . . . . . . . . 24 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 88 Intellectual Property and Copyright Statements . . . . . . . 26 90 1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 2.1 GSS-API Model 100 The Generic Security Service Application Program Interface (GSS-API) 101 [RFC2743] defines interface into security modules for the purpose of 102 establish a security context between two peers. The peers are 103 usually identified as the GSS-API context initiator and the GSS-API 104 context acceptor. GSS-API is generally applicable in a wide variety 105 of situations, however it is most often used in application layer 106 protocols. 108 +-----------+ +-----------+ 109 | | Authentication | | 110 | GSS-API |<---------------------------->| GSS-API | 111 | Context | | Context | 112 | Initiator | Message Protection | Acceptor | 113 | |<---------------------------->| | 114 +-----------+ +-----------+ 116 GSS-API can provide optional message protection services between the 117 GSS-API initiator and Acceptor. 119 2.2 SASL Model 121 The Simple Authentication and Security Layer (SASL) provides a 122 framework for providing authentication and security services between 123 a SASL Client and a SASL Server. SASL provides an abstraction layer 124 between application protocols and authentication mechanisms. SASL is 125 generally applicable within application layer protocols. 127 +-----------+ +-----------+ 128 | | Authentication | | 129 | SASL |<---------------------------->| SASL | 130 | Client | | Server | 131 | | Octet Stream Protection | | 132 | |<---------------------------->| | 133 +-----------+ +-----------+ 135 2.3 EAP Model 137 The Extensible Authentication Protocol (EAP) [RFC3748] defines a 138 protocol for performing authentication between two entities. EAP is 139 generally applicable for network access authentication. The protocol 140 allows different authentication mechanisms through different EAP 141 methods. The EAP conversation is carried in a lower layer protocol 142 between the EAP Peer and EAP Authenticator, however the EAP 143 authentication conversation is actually terminated in a logical 144 entity known as the EAP server. The EAP server may be co-located 145 with the EAP authenticator or it may be located on a physically 146 separate device such as a AAA server. When the EAP server is 147 separated from the EAP authenticator the authenticator device 148 operates in pass-through mode. Message protection is not provided by 149 EAP, however it is common for key material from the authentication 150 exchange to be exported from the EAP server to the EAP authenticator 151 so it can be used in lower layer message protection schemes. The 152 export of the key material outside the EAP Server and the message 153 protection between the EAP Peer and the EAP Authenticator is done 154 outside the EAP protocol. 156 +--------+ +-----------+ +---------+ 157 | | Authentication | | 158 | |<---------------------------------------------->| | 159 | EAP | | EAP | | EAP | 160 | Peer | | Authenti- | Key Material | Server | 161 | | Message Prot. | cator |<----------------| | 162 | |<---------------->| | | | 163 +--------+ +-----------+ +---------+ 165 3. Mechanism Guidelines 167 3.1 Mechanism Naming 169 Each of the frameworks described in Section 2 provides a means to 170 identify mechanisms. A SASL mechanism name as 1 to 20 character 171 string selected from a subset of the ASCII character set. An GSS-API 172 mechanism is identified by an ASN.1 OID. An EAP mechanism is defined 173 either by a single by number if it is a normal type mechanism and a 3 174 byte SMI vendor indicator followed by a 4 byte type indicator if it 175 is an expanded type mechanism. 177 The recommendation for general mechanism naming is as follows: 179 1. A GUAM mechanism must provide a mechanism name for use in each of 180 these frameworks. 182 3.2 Framing and Protocol 184 All the frameworks rely upon the authentication mechanism to define 185 the authentication protocol messages exchanged between the 186 authenticating peers. All the frameworks treat the tokens that are 187 exchanged as opaque and can support an arbitrary number of exchanges 188 to establish a security context. The different frameworks have 189 different approaches to providing protocol support and framing for 190 carrying out authentication exchanges. From an authentication 191 protocol standpoint all the frameworks deal with two entities. The 192 GSS-API initiator, SASL client and EAP peer are equivalent and the 193 GSS-API acceptor, SASL server and EAP server are equivalent. 195 SASL mechanisms are designed to be embedded in an application 196 protocol and require no special framing of messages as this is 197 handled in the application layer protocol. Since SASL runs within a 198 connection oriented application protocol there is no consideration 199 for the fragmentation or retransmission. SASL allows either the SASL 200 client or the SASL server to initiate the conversation depending on 201 the capabilities of the SASL mechanism. In some cases application 202 protocols do not allow to send a server message with a result 203 indication. In these cases the SASL client mechanism may need to 204 respond with an empty message to the final server message. The SASL 205 security layer assumes it is running under a reliable connection 206 oriented application protocol. 208 GSS-API is also designed to be run within the context of another 209 protocol which will handle framing, fragmentation, retransmission and 210 message exchange. GSS-API does require that the initial token sent 211 between GSS-API initiator and acceptor start with the OID that 212 identifies the mechanism, but this is the only required framing. 213 GSS-API mechanism exchanges are always initiated by the GSS-API 214 context initiator. GSS-API provides per-message security services 215 that may provide replay detection and sequence detection so they may 216 be used in protocols that are not connection oriented. 218 EAP was designed to be embedded within lower layer protocols that do 219 not provide support fragmentation or retransmission. Therefore EAP 220 provides a protocol outside of the authentication protocol provided 221 by EAP methods. This protocol provides basic message framing which 222 is required on every EAP message. The protocol also defines 223 retransmission behavior that can be used when the underlying protocol 224 does not provide retransmission of lost packets. EAP does not 225 provide fragmentation so it is up to the implementation of individual 226 EAP mechanisms to provide this support. EAP authentication exchanges 227 are always initiated from the EAP server side of the conversation. 228 The last EAP message in the method conversation is sent from peer to 229 server, excluding the EAP Success or failure message. The EAP 230 protocol also includes a negotiation phase which is described in 231 Section 3.10 and an unprotected way to indicate success or failure. 232 EAP does not provide a security layer or per-message security 233 services. EAP also does not define a way to distribute key material 234 from the EAP server to an EAP authenticator. In the case where the 235 EAP server and the EAP authenticator are collocated this is a local 236 interface and in the case where they are separated from one another 237 the key distribution typically makes use of a AAA protocol such as 238 RADIUS or Diameter. 240 Another consideration with EAP is often used to perform 241 authentication to get authorization to a network. This means that 242 all or some network services may not be available at authentication 243 time. Therefore if the underlying authentication technology requires 244 access to network services such as a Kerberos KDC the authentication 245 may be impossible. Mechanism developers should take this into 246 consideration and possibly provide additional mechanisms to support 247 cases in which network services are not available and authentication 248 exchanges need to be carried out through the authenticator. 250 The recommendation for handling this in a general mechanism is as 251 follows. 253 1. The core authentication protocol messages SHOULD be the same 254 regardless of which framework is used. 256 2. A GUAM mechanism MUST define message flows that can be initiated 257 from the server/acceptor side or the initiator/client side. 259 3. When operating in GSS-API mode the first message sent from the 260 client MUST begin with the GSS-API OID for the mechanism. When 261 operating in first message sent by client mode in other 262 frameworks the first message MAY begin with the GSS-API OID for 263 the mechanism. If the mechanism excludes the OID in certain 264 frameworks then the absence of the OID MUST NOT create any 265 difference in the subsequent message or operation of the 266 mechanism. 268 4. GUAM mechanisms MUST define how to do fragmentation. In order to 269 accommodate this a generic fragmentation wrapper should be used. 270 The Internet community may develop a fragmentation framework as 271 part of a generic framing facility. 273 5. A GUAM mechanism MUST define itself as client initiated, server 274 initiated or variable when operating in SASL mode. 276 6. If the last message in the core authentication exchange is sent 277 by the server then the client/peer MUST be prepared to send an 278 empty message to satisfy the SASL application and EAP 279 requirements. The server/acceptor side of the conversation MUST 280 be prepared to accept this empty message when operating in these 281 modes. This along with 2 SHOULD be the only protocol difference 282 between the messages used in different frameworks. 284 7. A GUAM mechanism SHOULD take into consideration scenarios where 285 network services are not available to an entity wishing to join 286 the network and provide mechanisms or modes of operation which do 287 not require direct access to network services. Typically it will 288 be the client side of the conversation that does not have access 289 to network services. 291 3.3 Mechanism Security Properties 293 This section makes recommendations on the types of security 294 properties that a mechanism should have. This list is taken from 295 [RFC3748] and refers to the capabilities of the authentication 296 exchange itself and not to subsequent per-message protection or 297 security layers. 299 1. A mechanism MUST identify the algorithms in use and provide for 300 algorithm agility. A mechanism SHOULD support ciphersuite 301 negotiation for the algorithms used in the authentication 302 exchange. 304 2. If a mechanism supports ciphersuite negotiation then it SHOULD be 305 protected 307 3. A mechanism MUST support mutual authentication. For EAP 308 mechanisms this means mutual authentication between EAP peer and 309 EAP server. 311 4. A mechanism MUST support integrity protection for messages 312 exchanged within the authenticated key exchange. 314 5. A mechanism MUST support replay protection for the message 315 exchanged within the core authenticated key exchange. 317 6. A mechanism MAY support confidentiality for the message exchanged 318 within the core authenticated key exchange. 320 7. A mechanism SHOULD provide passive and active dictionary attack 321 resistance. 323 8. A mechanism SHOULD support Session independence so the compromise 324 of one session does not compromise previous or subsequent 325 sessions 327 9. If a mechanism incorporates or uses another mechanism it SHOULD 328 provide a means to cryptographically bind the mechanism exchanges 329 together if possible. 331 3.4 Key Derivation 333 All of the frameworks support an authenticated key exchange. SASL 334 does not provide access to generated key material, however key 335 material from a SASL exchange may be used in a SASL security layer. 336 EAP methods derive two keys, the master session key (MSK) and the 337 extended master session key (EMSK). GSS-API mechanisms can provide 338 access to a pseudo-random function that derives keys from the 339 underlying authenticated key exchange. 341 The recommendations for key derivation in a general mechanism is as 342 follows: 344 1. A mechanism MUST support the derivation of key material. 346 2. Mechanisms MUST support a PRF that can interface with the GSS-API 347 PRF function. A default generic PRF may be defined for this 348 purpose. 350 3. A mechanism SHOULD provide a way to provide cryptographic agility 351 for a PRF. 353 4. A mechanism MUST define key material that may be defined as the 354 EAP MSK and EMSK. It is possible that these keys may be derived 355 from the GSS-API PRF using well defined strings as input. This 356 may need more investigation since it is possible that a mechanism 357 may not export the EMSK but would instead export only keys 358 derived from the EMSK. 360 5. Key material exported from mechanisms MUST be cryptographically 361 separate from keys used for other purposes by the mechanism such 362 as those used in a security layer. 364 3.5 Security Layer 366 SASL and GSS-API provide a security layer that can be used to protect 367 further information between the two authenticated parties. The SASL 368 security layer expects to be run over a connection oriented 369 transport. The GSS-API security services may be used for message 370 protection and do not necessarily expect to run over a connection 371 oriented transport. EAP does not provide a security layer, instead 372 it exports key material that is used to seed an external security 373 layer that protects data between the EAP peer and EAP authenticator. 375 All GUAMs MUST meet the recommendations for general mechanism 376 security layer as follows: 378 1. A mechanism MUST support a security layer which provides message 379 integrity protection at a minimum. A generic security layer may 380 be defined that can use key material generated from the 381 authentication exchange. 383 2. A mechanism SHOULD support confidentiality in the security layer. 385 3. A mechanism MUST provide for replay detection and MAY provide 386 out-of-sequence detection. 388 4. A mechanism MUST provide cryptographic agility with respect to 389 integrity and confidentiality algorithms. 391 3.6 Target Identification 393 Specifying the target name of the service is useful when 394 communicating with an entity which supports multiple virtual 395 services. 397 When establishing a security context the GSS-API context initiator 398 specifies the name of the target service it wants to communicate 399 with. SASL also allows the specification of the name of a target 400 service when establishing a security context. What is expected of 401 the target name is not completely described. A Kerberos mechanism 402 requires a target service name so it can obtain an select the 403 appropriate service tickets for the service. The type of names 404 typically used as target names are host based service names to 405 represent a service on a host. 407 EAP does not have a notion of a target service name. Originally EAP 408 was more concerned with the authentication of the client accessing a 409 network rather than of a host to a client. In addition EAP has 410 largely been concerned with clients trying to access a network which 411 provides a uniform service with all authenticators providing the same 412 access service. As networks evolve this is changing somewhat so the 413 need to specify a target type of network service or, in some cases, a 414 particular instance of an authenticator providing a service. Some 415 EAP methods such as EAP-SIM and EAP-AKA do not explicitly name the 416 target but rather rely upon the assumption that an authorized party 417 has access to a shared secret. In some cases the EAP peer trying to 418 access the network does not know the identity of the network ahead of 419 time. Therefore it is desirable for the network to provide a hint of 420 its identity in its initial message. This can also be done in the 421 EAP identity request message as in [I-D.adrangi-eap-network- 422 discovery], however this message is not specific to a mechanism so it 423 may not be possible to provide accurate information. 425 The recommendations for general mechanism target identification are 426 as follows: 428 1. A mechanism SHOULD provide a means to bind a target service name 429 to the authentication exchange so at least the initiator and 430 acceptor can select the correct credentials and verify that the 431 target is consistent with the type of request being made. Note 432 that credential selection is a technique that can help in some 433 types of channel bindings described in Section 3.8. 435 2. A mechanism SHOULD provide support for host based service names 436 as defined in [RFC2743]. Note that it may be beneficial to 437 define name types that identify network based services to support 438 environments where EAP is currently used. 440 3. A mechanism SHOULD provide a means for the acceptor to provide a 441 hint of its identity to the initiator when the acceptor issues 442 the first message. It SHOULD be possible to suppress this hint 443 for cases where this information should not be revealed. 445 3.7 Session Identification 447 Session identification information provides a way to identify a 448 particular instance of an authentication transaction. This 449 information could be used to bind this authentication transaction to 450 another exchange or it could be used to identify keys generated by 451 the exchange. GSS-API and SASL frameworks do not provide an external 452 way to identify a particular authentication transaction. It is 453 possible that the GSS-API PRF interface could be used for this 454 purpose, but it may be preferred to generate a value that is a 455 property of the mechanism execution instead of application specific 456 information. EAP also does not provide a external way to identify a 457 particular exchange, however [I-D.ietf-eap-keying] does make 458 recommendations in this area. 460 The recommendations for general mechanism session identification are 461 as follows: 463 A mechanism SHOULD provide a means to export a value to identify a 464 particular instance of an authentication transaction. This value 465 is a public value and must not reveal any secret information. 467 3.8 Channel Binding 469 The term channel binding has been used with various different 470 meanings in the different frameworks. 472 GSS-API included the concept of channel binding to bind the context 473 establishment to an existing underlying cryptographic channel. The 474 helps to ensure that the end points of the secure channel are the 475 same as the endpoints of the context establishment. In the GSS-API 476 initiator and acceptor applications provide "channel bindings" data, 477 a strong identifier for a secure channel, to the mechanism which 478 determines the channel bindings data are the same for both peers, 479 such as by exchanging and comparing integrity hashes thereof. The 480 data from channel bindings could be transformations of key material 481 negotiated by the underlying channel or unique public data that has 482 been exchanged within and bound to the channel negotiation (such as 483 the TLS finished messages). In some cases network addresses have 484 also been used as channel bindings which can be problematic since 485 address may be translated and are often not bound to an underlying 486 cryptographic channel. GSS-API type of channel binding has also been 487 referred to cryptographic binding in the context of EAP method 488 discussions. 490 In EAP the term channel binding has been used with a different 491 emphasis. It is common for EAP deployments to locate the EAP server 492 on a AAA server which is physically separated from the authenticator. 493 The AAA server typically supports multiple authenticators. This 494 results in the EAP peer authenticating the identity of the AAA server 495 and not the identity of the authenticator, it just knows that the 496 authenticator it is talking to has been authorized by the AAA server. 497 In many cases this does not cause a problem since all authenticators 498 provide the same service. However in the case where authenticators 499 providing different services use the same AAA server or in cases 500 where the identity of the individual authenticator is important this 501 does raise an issue. A peer requesting a particular service may be 502 fooled into accepting service from an authenticator that is not 503 authorized to provide the service. In attempt to solve this problem 504 it is recommended that the EAP authentication method provide a way to 505 bind parameters in the lower layer request to the authentication 506 protocol so they AAA server can verify the binding between the 507 service requested by the client and a service that the authenticator 508 is authorized to provide. This type of channel binding might be 509 better called service binding. There are several ways that this type 510 of channel binding may be achieved. 512 o Credential Selection - by including a target service identifier in 513 the authentication protocol the initiator and/or acceptor can 514 select an appropriate credentials to perform authentication as a 515 particular service. For example this could result in the 516 acquisition of a Kerberos service ticket for a specific service, 517 selection of an appropriate certificate to identify a specific 518 service, or localization of a shared secret for use with a 519 specific service. This requires each target service to have its 520 own name and credential. Credential selection may not provide 521 enough granularity for all the parameters specified by a service. 523 o GSS-API style channel bindings - in this case each side hashes the 524 binding information and the two hashes are compared. The contents 525 of the binding information must be rigidly defined because any 526 variation will cause the binding to fail. The AAA server will 527 need to know what binding parameters are associated with the 528 authenticator in order to correctly compute the binding. 530 o Authenticated data style bindings - in this case the binding 531 information is communicated from initiator or vice versa. The 532 data can then be exported from the mechanism and compared with 533 additional parameters communicated out of band. This approach 534 allows for a more complex comparison where some variation of 535 binding parameters is allowed. 537 o Binding through external key derivation - in this case the keys 538 that are exported from a mechanism are bound to a particular 539 channel parameters through the key derivation algorithm. This 540 approach does not require support from a mechanism and can only be 541 used when the key material is made use of externally. 543 SASL does not currently have a concept similar to channel bindings 544 although it does support specifying a target service identifier. 545 However there is ongoing work on defining channel bindings for SASL 546 mechanisms. 548 The recommendations for general mechanism channel bindings are as 549 follows: 551 1. A mechanism MUST support channel bindings compatible with 552 [RFC2743]. 554 2. A mechanism MUST support authenticated data style channel 555 bindings. 557 3.9 Principal Naming and Attributes 559 GSS-API has a formal system of mechanism independent naming described 560 in [RFC2743]. The most commonly used name types are host based 561 service names (GSS_C_NT_HOSTBASED_SERVICE) and user names 562 GSS_C_NT_USER_NAME. GSS-API also has the concept of a canonical name 563 representation that can be used for binary comparisons of equality. 564 There are ongoing investigations into providing a more structured 565 naming scheme which could provide additional attributes such as group 566 affiliation. 568 EAP typically beings with an identity assertion phase where the peer 569 responds to an EAP-Identity request with an EAP-Identity response 570 containing an network access identifier (NAI). The NAI is not 571 authenticated at this point, but provides a hint to the back end 572 authentication services as how to authenticated the peer, i.e. which 573 authentication server to contact. In some ways this identifies the 574 target of the authentication, but it is just specify a realm instead 575 of a specific service that is being provided. The actual 576 authentication may or may not authenticate the NAI depending on the 577 authentication method. In some cases the NAI is anonymous and 578 completely unrelated to the final authenticated identity. EAP does 579 not provide a formal way of dealing with authenticated names. EAP 580 methods may provide a means for exchanging application specified data 581 which could be possibly be structured as naming attributes. 583 SASL defines an authorization identity in addition to the 584 authenticated identity. The authorization identity is the identity 585 that the client is expected to act as. The SASL implementation must 586 verify that the authenticated identity is authorized to act as the 587 authenticated identity. SASL does not specify the structure or 588 format of names. 590 The recommendations for general mechanism principal naming and 591 attributes are as follows: 593 1. A mechanism MUST define how to export names in the GSS-API 594 mechanism independent and canonical formats. 596 2. A mechanism MUST support the authenticated communication of an 597 application specific authorization identity. The mechanism 598 should provide hooks where appropriate to allow for the 599 authorization of the authorization identity to authenticated 600 identity mapping. 602 3. A mechanism MAY define support for other identity attribute types 603 as appropriate. 605 3.10 Mechanism Negotiation 607 GSS-API does not provide native support for mechanism negotiation, 608 however there is a pseudo-mechanism designed to perform negotiation 609 called Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) 610 [RFC4178]. SPNEGO can negotiate a mechanism in common between the 611 initiator and acceptor, and, provided the mechanisms negotiated 612 provide integrity support, then it can also protect the negotiation. 613 Some GSS-API applications eschew SPNEGO and perform mechanism 614 negotiation at the application protocol layer. . 616 EAP provides a negotiation mechanism in which the server suggests a 617 mechanism by sending the initial message in the authentication 618 exchange and the peer replies with either a response or a NAK message 619 containing a list of mechanisms it supports. The negotiation is not 620 protected. Once a particular negotiation method is selected it is 621 not possible to abort and switch to a new mechanism without 622 restarting the conversation. 624 In SASL mechanism negotiation is left to the application. Typically 625 the server presents a list that the client chooses from. The 626 negotiation may be protected if a security layer is provided and the 627 application defines a way to obtain a list of mechanisms after the 628 security layer is established. 630 Multiple layers of mechanism negotiation can cause problems. The 631 main problem with multi-layer mechanism negotiation is that security 632 requirements may not be maintained at all negotiation layers, thus 633 one layer may select a security mechanism that is too weak or 634 otherwise inappropriate at a higher layer. It is also possible for 635 the negotiation to fail because a mechanism selected tries to do 636 negotiation which fails and there is no way to go backwards in the 637 mechanism tree without restarting the negotiation from the beginning. 639 The recommendations for general mechanism negotiation are as follows: 641 1. Mechanism specifications should analyze the security implications 642 of sub mechanism negotiation and include security considerations 643 to address security issues that may arise from sub-mechanism 644 negotiation. 646 3.11 Indentity Protection 648 Some mechanisms provide support for concealing the identity of one of 649 the parties executing the authentication protocol from an 650 eavesdropper. The recommendation for general mechanisms support for 651 identity protection is as follows, 653 1. A mechanism MAY support identity protection for one of the 654 participants in the authentication conversation. In general 655 mechanisms are more interested in protecting the identity of 656 clients rather than services. 658 3.12 Fast Reconnect 660 Fast reconnect is defined in [RFC3748]as "The ability, in the case 661 where a security association has been previously established, to 662 create a new or refreshed security association more efficiently or in 663 a smaller number of round-trips." The recommendation for general 664 mechanisms support for fast reconnect is as follows. 666 1. A mechanism MAY support fast reconnect for one of the 667 participants in the authentication conversation. 669 4. Tools for creating GUAM mechanisms 671 This section describes tools and techniques that mechanism developers 672 can use to help them create generally usable mechanism. 674 4.1 Mechanism Bridges 676 A mechanism bridge creates an automated way to incorporate mechanisms 677 from one framework into another framework. An example of such a 678 bridge is the SASL GSS-API based mechanism [I-D.ietf-sasl-gssapi]. 679 This specification describes how a GSS-API mechanism may be invoked 680 as a SASL mechanism. This allows any mechanism specified in GSS-API 681 to be invoked through the SASL framework. When the SASL GSS-API 682 mechanism was first defined all GSS-API mechanism appeared as one 683 SASL mechanism within the SASL framework. 685 It may be possible to create bridges for other combinations of 686 mechanisms, but there often exists gaps in functionality between 687 mechanisms of different frameworks. The following sections describe 688 techniques that make it easier to overcome these gaps and make it 689 possible to adapt a candidate mechanism to different frameworks. As 690 a mechanism is incorporated from one framework into another it should 691 retain a unique identity so existing negotiation mechanisms of 692 frameworks and applications are not broken. 694 4.2 Protocol Initiation 696 The different frameworks require different entities to start the 697 authentication conversation. In EAP it is the server/acceptor side 698 that starts the conversation, in GSS-API it is the opposite and SASL 699 can operate in either mode. It is often possible to include an 700 additional message or remove a message without affecting the 701 protocol. For example to convert a client initiated protocol for use 702 with EAP an initial message that contains a hint of the identity of 703 the server could be added. The hint can be useful in EAP where the 704 peer may not have another means of knowing who it is talking to until 705 the authentication protocol is underway. 707 4.3 Generic PRF 709 For mechanisms that do not define a PRF that can be used in GSS-API 710 calls a default PRF can be defined. 712 4.4 Generic Per-Message Security Layer 714 Mechanisms that are defined as EAP methods do not provide a security 715 layer. However they do provide cryptographic key material generated 716 from the EAP exchange in the form of the MSK and EMSK. Key material 717 derived from these quantities could be used to key a generic security 718 layer. An generic security layer could be based on Kerberos 719 encryption and checksum profile [RFC4121][RFC3961] or on IPSec ESP. 720 EAP methods also do not provide for the negotiation of a ciphersuite 721 for the security layer. One approach would be to add negotiation 722 into the generic security layer. Another approach may be to exchange 723 quality of protection parameters as authenticated data. 725 4.5 Fragmentation Support 727 Mechanisms that are defined as GSS-API or SASL mechanisms leave any 728 fragmentation up to the application itself. In order to support EAP 729 these mechanisms would have to include fragmentation support. A 730 generic fragmentation layer could be modelled after EAP-TLS 731 [RFC2716]. 733 4.6 Channel Binding and Authenticated Data 735 The ability to carry data that is integrity protected between the 736 authenticating parties is a useful feature for a mechanism. Channel 737 binding would certainly be helped by this capability. The data 738 should be tagged for different purposes. One use could be to carry a 739 hash of channel binding parameters used for GSS-API style channel 740 bindings. Another use could be for communicating a SASL 741 authorization ID or for carry EAP style channel bindings. Having a 742 common name space for different types of attributes could be useful 743 in developing mechanisms in a consistent way. 745 4.7 Fast Reconnect 747 Some mechanisms provide support for a fast reconnect feature that 748 optimizes subsequent authentications after an initial authentication. 749 In some cases this may be best provided by the mechanism, however it 750 could be possible for a generic fast reauthentication mechanism be 751 developed to address this need for general mechanisms. 753 4.8 Mechanism Naming 755 It is possible to automatically generate types from a single value. 756 The recommended approach is to assign an EAP type to a mechanism. A 757 GSS-API OID can be created from the EAP type by appending the EAP 758 type as an integer appended to the GUAM mechanism base OID [TBD]. 759 The SASL specification for using GSS-API mechanisms in SASL is 760 defined in [I-D.ietf-sasl-gssapi] and specifies a way to create a 761 SASL name from a GSS-API OID. 763 4.9 Naming 765 TBD - Some guidance in naming is needed. 767 We need at least support for naming services, both domain-wide (AAA 768 services) and host-based, and we need support for naming users. 769 Everything else should pretty much be optional, including anonymity 770 and pseudonymity. 772 5. Interface Specification 774 This section outlines how the GSS-API can provide a interface that 775 could potentially be used by any of the mechanism frameworks. Some 776 required enhancements to GSS-API to make this happen are discussed. 778 6. IANA Considerations 780 To be determined. 782 7. Security Considerations 784 7.1 Same mechanism accessed through different frameworks 786 7.2 Algorithm identification and negotiation 787 8. Acknowledgements 789 Nicolas Williams, Sam Hartman, and Glen Zorn provided valuable 790 discussions and feedback that went into the preparation of this 791 document. 793 9. References 795 9.1 Normative References 797 [I-D.ietf-sasl-rfc2222bis] 798 Melnikov, A. and K. Zeilenga, "Simple Authentication and 799 Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-15 800 (work in progress), January 2006. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, March 1997. 805 [RFC2743] Linn, J., "Generic Security Service Application Program 806 Interface Version 2, Update 1", RFC 2743, January 2000. 808 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 809 Levkowetz, "Extensible Authentication Protocol (EAP)", 810 RFC 3748, June 2004. 812 9.2 Informative References 814 [I-D.adrangi-eap-network-discovery] 815 Adrangi, F., "Identity selection hints for Extensible 816 Authentication Protocol (EAP)", 817 draft-adrangi-eap-network-discovery-14 (work in progress), 818 August 2005. 820 [I-D.ietf-eap-keying] 821 Aboba, B., "Extensible Authentication Protocol (EAP) Key 822 Management Framework", draft-ietf-eap-keying-13 (work in 823 progress), May 2006. 825 [I-D.ietf-sasl-gssapi] 826 Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", 827 draft-ietf-sasl-gssapi-06 (work in progress), June 2006. 829 [I-D.salowey-guam] 830 Salowey, J., "Generally Useful Authentication Mechanisms 831 (GUAM)", draft-salowey-guam-00 (work in progress), 832 June 2005. 834 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 835 Protocol", RFC 2716, October 1999. 837 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 838 Kerberos 5", RFC 3961, February 2005. 840 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 841 Version 5 Generic Security Service Application Program 842 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 843 July 2005. 845 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 846 Simple and Protected Generic Security Service Application 847 Program Interface (GSS-API) Negotiation Mechanism", 848 RFC 4178, October 2005. 850 Author's Address 852 Joseph Salowey 853 Cisco Systems 855 Email: jsalowey@cisco.com 857 Intellectual Property Statement 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. Information 865 on the procedures with respect to rights in RFC documents can be 866 found in BCP 78 and BCP 79. 868 Copies of IPR disclosures made to the IETF Secretariat and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementers or users of this 872 specification can be obtained from the IETF on-line IPR repository at 873 http://www.ietf.org/ipr. 875 The IETF invites any interested party to bring to its attention any 876 copyrights, patents or patent applications, or other proprietary 877 rights that may cover technology that may be required to implement 878 this standard. Please address the information to the IETF at 879 ietf-ipr@ietf.org. 881 Disclaimer of Validity 883 This document and the information contained herein are provided on an 884 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 885 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 886 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 887 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 888 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 889 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 891 Copyright Statement 893 Copyright (C) The Internet Society (2006). This document is subject 894 to the rights, licenses and restrictions contained in BCP 78, and 895 except as set forth therein, the authors retain all their rights. 897 Acknowledgment 899 Funding for the RFC Editor function is currently provided by the 900 Internet Society.