idnits 2.17.1 draft-ietf-abfab-gss-eap-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2012) is 4246 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 597, but not defined == Missing Reference: 'Application 0' is mentioned on line 962, but not defined == Unused Reference: 'I-D.ietf-krb-wg-gss-cb-hash-agility' is defined on line 1510, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GSS-IANA' == Outdated reference: A later version (-06) exists of draft-ietf-abfab-eapapplicability-00 ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4402 (Obsoleted by RFC 7802) == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-03 == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-03 == Outdated reference: A later version (-13) exists of draft-ietf-radext-radius-extensions-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). 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: February 14, 2013 JANET 6 August 13, 2012 8 A GSS-API Mechanism for the Extensible Authentication Protocol 9 draft-ietf-abfab-gss-eap-09.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 Extensible 16 Authentication Protocol mechanism. Through the GS2 family of 17 mechanisms defined in RFC 5801, these protocols also define how 18 Simple Authentication and Security Layer (SASL, RFC 4422) 19 applications use the Extensible Authentication Protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 14, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Secure Association Protocol . . . . . . . . . . . . . . . 6 59 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 60 3. EAP Channel Binding and Naming . . . . . . . . . . . . . . . . 9 61 3.1. Mechanism Name Format . . . . . . . . . . . . . . . . . . 9 62 3.2. Internationalization of Names . . . . . . . . . . . . . . 12 63 3.3. Exported Mechanism Names . . . . . . . . . . . . . . . . . 12 64 3.4. Acceptor Name RADIUS AVP . . . . . . . . . . . . . . . . . 13 65 3.5. Proxy Verification of Acceptor Name . . . . . . . . . . . 13 66 4. Selection of EAP Method . . . . . . . . . . . . . . . . . . . 15 67 5. Context Tokens . . . . . . . . . . . . . . . . . . . . . . . . 16 68 5.1. Mechanisms and Encryption Types . . . . . . . . . . . . . 17 69 5.2. Processing received tokens . . . . . . . . . . . . . . . . 17 70 5.3. Error Subtokens . . . . . . . . . . . . . . . . . . . . . 18 71 5.4. Initial State . . . . . . . . . . . . . . . . . . . . . . 18 72 5.4.1. Vendor Subtoken . . . . . . . . . . . . . . . . . . . 19 73 5.4.2. Acceptor Name Request . . . . . . . . . . . . . . . . 19 74 5.4.3. Acceptor Name Response . . . . . . . . . . . . . . . . 19 75 5.5. Authenticate State . . . . . . . . . . . . . . . . . . . . 20 76 5.5.1. EAP Request Subtoken . . . . . . . . . . . . . . . . . 21 77 5.5.2. EAP Response Subtoken . . . . . . . . . . . . . . . . 21 78 5.6. Extension State . . . . . . . . . . . . . . . . . . . . . 21 79 5.6.1. Flags Subtoken . . . . . . . . . . . . . . . . . . . . 22 80 5.6.2. GSS Channel Bindings Subtoken . . . . . . . . . . . . 22 81 5.6.3. MIC Subtoken . . . . . . . . . . . . . . . . . . . . . 23 82 5.7. Example Token . . . . . . . . . . . . . . . . . . . . . . 24 83 5.8. Context Options . . . . . . . . . . . . . . . . . . . . . 24 84 6. Acceptor Services . . . . . . . . . . . . . . . . . . . . . . 26 85 6.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 26 86 6.2. Per-message security . . . . . . . . . . . . . . . . . . . 27 87 6.3. Pseudo Random Function . . . . . . . . . . . . . . . . . . 27 88 7. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 28 89 7.1. OID Registry . . . . . . . . . . . . . . . . . . . . . . . 28 90 7.2. RFC 4121 Token Identifiers . . . . . . . . . . . . . . . . 29 91 7.3. GSS EAP Subtoken Types . . . . . . . . . . . . . . . . . . 29 92 7.4. RADIUS Attribute Assignments . . . . . . . . . . . . . . . 30 93 7.5. Registration of the EAP-AES128 SASL Mechanisms . . . . . . 31 94 7.6. GSS EAP Errors . . . . . . . . . . . . . . . . . . . . . . 31 95 7.7. GSS EAP Context Flags . . . . . . . . . . . . . . . . . . 32 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 38 102 Appendix A. Pre-Publication RADIUS VSA . . . . . . . . . . . . . 40 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 105 1. Introduction 107 ABFAB [I-D.ietf-abfab-arch] describes an architecture for providing 108 federated access management to applications using the Generic 109 Security Services Application Programming Interface (GSS-API) 110 [RFC2743] and Simple Authentication and Security Layers (SASL) 111 [RFC4422]. This specification provides the core mechanism for 112 bringing federated authentication to these applications. 114 The Extensible Authentication Protocol (EAP) [RFC3748] defines a 115 framework for authenticating a network access client and server in 116 order to gain access to a network. A variety of different EAP 117 methods are in wide use; one of EAP's strengths is that for most 118 types of credentials in common use, there is an EAP method that 119 permits the credential to be used. 121 EAP is often used in conjunction with a backend Authentication , 122 Authorization and Accounting (AAA) server via RADIUS [RFC3579] or 123 Diameter [RFC4072]. In this mode, the Network Access Server (NAS) 124 simply tunnels EAP packets over the backend authentication protocol 125 to a home EAP/AAA server for the client. After EAP succeeds, the 126 backend authentication protocol is used to communicate key material 127 to the NAS. In this mode, the NAS need not be aware of or have any 128 specific support for the EAP method used between the client and the 129 home EAP server. The client and EAP server share a credential that 130 depends on the EAP method; the NAS and AAA server share a credential 131 based on the backend authentication protocol in use. The backend 132 authentication server acts as a trusted third party enabling network 133 access even though the client and NAS may not actually share any 134 common authentication methods. As described in the architecture 135 document, using AAA proxies, this mode can be extended beyond one 136 organization to provide federated authentication for network access. 138 The GSS-API provides a generic framework for applications to use 139 security services including authentication and per-message data 140 security. Between protocols that support GSS-API directly or 141 protocols that support SASL [RFC4422], many application protocols can 142 use GSS-API for security services. However, with the exception of 143 Kerberos [RFC4121], few GSS-API mechanisms are in wide use on the 144 Internet. While GSS-API permits an application to be written 145 independent of the specific GSS-API mechanism in use, there is no 146 facility to separate the server from the implementation of the 147 mechanism as there is with EAP and backend authentication servers. 149 The goal of this specification is to combine GSS-API's support for 150 application protocols with EAP/AAA's support for common credential 151 types and for authenticating to a server without requiring that 152 server to specifically support the authentication method in use. In 153 addition, this specification supports the architectural goal of 154 transporting attributes about subjects to relying parties. Together 155 this combination will provide federated authentication and 156 authorization for GSS-API applications. This specification meets the 157 applicability requirements for EAP to application authentication 158 [I-D.ietf-abfab-eapapplicability]. 160 This mechanism is a GSS-API mechanism that encapsulates an EAP 161 conversation. From the perspective of RFC 3748, this specification 162 defines a new lower-layer protocol for EAP. From the perspective of 163 the application, this specification defines a new GSS-API mechanism. 165 Section 1.3 of [RFC5247] outlines the typical conversation between 166 EAP peers where an EAP key is derived: 168 o Phase 0: Discovery 170 o Phase 1: Authentication 172 o 1a: EAP authentication 174 o 1b: AAA Key Transport (optional) 176 o Phase 2: Secure Association Protocol 178 o 2a: Unicast Secure Association 180 o 2b: Multicast Secure Association (optional) 182 1.1. Discovery 184 GSS-API peers discover each other and discover support for GSS-API in 185 an application-dependent mechanism. SASL [RFC4422] describes how 186 discovery of a particular SASL mechanism such as a GSS-API mechanism 187 is conducted. The Simple and Protected Negotiation mechanism 188 (SPNEGO) [RFC4178] provides another approach for discovering what 189 GSS-API mechanisms are available. The specific approach used for 190 discovery is out of scope for this mechanism. 192 1.2. Authentication 194 GSS-API authenticates a party called the GSS-API initiator to the 195 GSS-API acceptor, optionally providing authentication of the acceptor 196 to the initiator. Authentication starts with a mechanism-specific 197 message called a context token sent from the initiator to the 198 acceptor. The acceptor responds, followed by the initiator, and so 199 on until authentication succeeds or fails. GSS-API context tokens 200 are reliably delivered by the application using GSS-API. The 201 application is responsible for in-order delivery and retransmission. 203 EAP authenticates a party called a peer to a party called the EAP 204 server. A third party called an EAP passthrough authenticator may 205 decapsulate EAP messages from a lower layer and reencapsulate them 206 into an AAA protocol. The term EAP authenticator refers to whichever 207 of the passthrough authenticator or EAP server receives the lower- 208 layer EAP packets. The first EAP message travels from the 209 authenticator to the peer; a GSS-API message is sent from the 210 initiator to acceptor to prompt the authenticator to send the first 211 EAP message. The EAP peer maps onto the GSS-API initiator. The role 212 of the GSS-API acceptor is split between the EAP authenticator and 213 the EAP server. When these two entities are combined, the division 214 resembles GSS-API acceptors in other mechanisms. When a more typical 215 deployment is used and there is a passthrough authenticator, most 216 context establishment takes place on the EAP server and per-message 217 operations take place on the authenticator. EAP messages from the 218 peer to the authenticator are called responses; messages from the 219 authenticator to the peer are called requests. 221 Because GSS-API applications provide guaranteed delivery of context 222 tokens, the EAP retransmission timeout MUST be infinite and the EAP 223 layer MUST NOT retransmit a message. 225 This specification permits a GSS-API acceptor to hand-off the 226 processing of the EAP packets to a remote EAP server by using AAA 227 protocols such as RADIUS, RadSec or Diameter. In this case, the GSS- 228 API acceptor acts as an EAP pass-through authenticator. The pass- 229 through authenticator is responsible for retransmitting AAA messages 230 if a response is not received from the AAA server. If a response 231 cannot be recieved, then the authenticator generates an error at the 232 GSS-API level. If EAP authentication is successful, and where the 233 chosen EAP method supports key derivation, EAP keying material may 234 also be derived. If an AAA protocol is used, this can also be used 235 to replicate the EAP Key from the EAP server to the EAP 236 authenticator. 238 See Section 5 for details of the authentication exchange. 240 1.3. Secure Association Protocol 242 After authentication succeeds, GSS-API provides a number of per- 243 message security services that can be used: 245 GSS_Wrap() provides integrity and optional confidentiality for a 246 message. 248 GSS_GetMIC() provides integrity protection for data sent 249 independently of the GSS-API 251 GSS_Pseudo_random [RFC4401] provides key derivation functionality. 253 These services perform a function similar to secure association 254 protocols in network access. Like secure association protocols, 255 these services need to be performed near the authenticator/acceptor 256 even when a AAA protocol is used to separate the authenticator from 257 the EAP server. The key used for these per-message services is 258 derived from the EAP key; the EAP peer and authenticator derive this 259 key as a result of a successful EAP authentication. In the case that 260 the EAP authenticator is acting as a pass-through it obtains it via 261 the AAA protocol. See Section 6 for details. 263 2. Requirements notation 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in [RFC2119]. 269 3. EAP Channel Binding and Naming 271 EAP authenticates a user to a realm. The peer knows that it has 272 exchanged authentication with an EAP server in a given realm. Today, 273 the peer does not typically know which NAS it is talking to securely. 274 That is often fine for network access. However privileges to 275 delegate to a chat server seem very different than privileges for a 276 file server or trading site. Also, an EAP peer knows the identity of 277 the home realm, but perhaps not even the visited realm. 279 In contrast, GSS-API takes a name for both the initiator and acceptor 280 as inputs to the authentication process. When mutual authentication 281 is used, both parties are authenticated. The granularity of these 282 names is somewhat mechanism dependent. In the case of the Kerberos 283 mechanism, the acceptor name typically identifies both the protocol 284 in use (such as IMAP) and the specific instance of the service being 285 connected to. The acceptor name almost always identifies the 286 administrative domain providing service. 288 An EAP GSS-API mechanism needs to provide GSS-API naming semantics in 289 order to work with existing GSS-API applications. EAP channel 290 binding [I-D.ietf-emu-chbind] is used to provide GSS-API naming 291 semantics. Channel binding sends a set of attributes from the peer 292 to the EAP server either as part of the EAP conversation or as part 293 of a secure association protocol. In addition, attributes are sent 294 in the backend authentication protocol from the authenticator to the 295 EAP server. The EAP server confirms the consistency of these 296 attributes. Confirming attribute consistency also involves checking 297 consistency against a local policy database as discussed in 298 Section 3.5. In particular, the peer sends the name of the acceptor 299 it is authenticating to as part of channel binding. The acceptor 300 sends its full name as part of the backend authentication protocol. 301 The EAP server confirms consistency of the names. 303 EAP channel binding is easily confused with a facility in GSS-API 304 also called channel binding. GSS-API channel binding provides 305 protection against man-in-the-middle attacks when GSS-API is used as 306 authentication inside some tunnel; it is similar to a facility called 307 cryptographic binding in EAP. See [RFC5056] for a discussion of the 308 differences between these two facilities and Section 6.1 for how GSS- 309 API channel binding is handled in this mechanism. 311 3.1. Mechanism Name Format 313 Before discussing how the initiator and acceptor names are validated 314 in the AAA infrastructure, it is necessary to discuss what composes a 315 name for an EAP GSS-API mechanism. GSS-API permits several types of 316 generic names to be imported using GSS_Import_name(). Once a 317 mechanism is chosen, these names are converted into a mechanism- 318 specific name called a "Mechanism Name". Note that a Mechanism Name 319 is the name of an initiator or acceptor, not of a GSS-API mechanism. 320 This section first discusses the mechanism name form and then 321 discusses what name forms are supported. 323 The string representation of the GSS-EAP mechanism name has the 324 following ABNF [RFC5234] representation: 326 char-normal = %x00-2E/%x30-3F/%x41-5B/%x5D-FF 327 char-escaped = "\" %x2F / "\" %x40 / "\" %x5C 328 name-char = char-normal / char-escaped 329 name-string = 1*name-char 330 user-or-service = name-string 331 host = [name-string] 332 realm = name-string 333 service-specific = name-string 334 service-specifics = service-specific 0*("/" service-specifics) 335 name = user-or-service ["/" host [ "/" service-specifics]] [ "@" 336 realm ] 338 Special characters appearing in a name can be backslash escaped to 339 avoid their special meanings. For example "\\" represents a literal 340 backslash. This escaping mechanism is a property of the string 341 representation; if the components of a name are transported in some 342 mechanism that will keep them separate without backslash escaping, 343 then backslash SHOULD have no special meaning. 345 The user-or-service component is similar to the portion of a network 346 access identifier (NAI) before the '@' symbol for initiator names and 347 the service name from the registry of GSS-API host-based services in 348 the case of acceptor names [GSS-IANA]. The NAI specification 349 provides rules for encoding and string preparation in order to 350 support internationalization of NAIs; implementations of this 351 mechanism MUST NOT prepare the user-or-service according to these 352 rules; see Section 3.2 for internationalization of this mechanism. 353 The host portion is empty for initiators and typically contains the 354 domain name of the system on which an acceptor service is running. 355 Some services MAY require additional parameters to distinguish the 356 entity being authenticated against. Such parameters are encoded in 357 the service-specifics portion of the name. The EAP server MUST 358 reject authentication of any acceptor name that has a non-empty 359 service-specifics component unless the EAP server understands the 360 service-specifics and authenticates them. The interpretation of the 361 service-specifics is scoped by the user-or-service portion. The 362 realm is similar to the the realm portion of a NAI for initiator 363 names; again the NAI specification's internationalization rules MUST 364 NOT be applied to the realm. The realm is the administrative realm 365 of a service for an acceptor name. 367 The string representation of this name form is designed to be 368 generally compatible with the string representation of Kerberos names 369 defined in [RFC1964]. 371 The GSS_C_NT_USER_NAME form represents the name of an individual 372 user. From the standpoint of this mechanism it may take the form 373 either of an undecorated user name or a name semantically similar to 374 a network access identifier (NAI) [RFC4282]. The name is split at 375 the first at-sign ('@') into the part preceeding the realm which is 376 the user-or-service portion of the mechanism name and the realm 377 portion which is the realm portion of the mechanism name. 379 The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running 380 on a host; it is textually represented as "service@host". This name 381 form is required by most SASL profiles and is used by many existing 382 applications that use the Kerberos GSS-API mechanism. While support 383 for this name form is critical, it presents an interesting challenge 384 in terms of EAP channel binding. Consider a case where the server 385 communicates with a "server proxy," or a AAA server near the server. 386 That server proxy communicates with the EAP server. The EAP server 387 and server proxy are in different administrative realms. The server 388 proxy is in a position to verify that the request comes from the 389 indicated host. However the EAP server cannot make this 390 determination directly. So, the EAP server needs to determine 391 whether to trust the server proxy to verify the host portion of the 392 acceptor name. This trust decision depends both on the host name and 393 the realm of the server proxy. In effect, the EAP server decides 394 whether to trust that the realm of the server proxy is the right 395 realm for the given hostname and then makes a trust decision about 396 the server proxy itself. The same problem appears in Kerberos: 397 there, clients decide what Kerberos realm to trust for a given 398 hostname. The service portion of this name is imported into the 399 user-or-service portion of the mechanism name; the host portion is 400 imported into the host portion of the mechanism name. The realm 401 portion is empty. However, authentication will typically fail unless 402 some AAA component indicates the realm to the EAP server. If the 403 application server knows its realm, then it should be indicated in 404 the outgoing AAA request. Otherwise, a proxy SHOULD add the realm. 405 An alternate form of this name type MAY be used on acceptors; in this 406 case the name form is "service" with no host component. This is 407 imported with the service as user-or-service and an empty host and 408 realm portion. This form is useful when a service is unsure which 409 name an initiator knows it by. 411 If the null name type or the GSS_EAP_NT_EAP_NAME (OID 412 1.3.6.1.5.5.15.2.1) (see Section 7.1 ) is imported, then the string 413 representation above should be directly imported. Mechanisms MAY 414 support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form with the OID 415 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 416 gssapi(2) krb5(2) krb5_name(1)}. In many circumstances, Kerberos 417 GSS-API mechanism names will behave as expected when used with the 418 GSS-API EAP mechanism, but there are some differences that may cause 419 some confusion. If an implementation does support importing Kerberos 420 names it SHOULD fail the import if the Kerberos name is not 421 syntactically a valid GSS-API EAP mechanism name as defined in this 422 section. 424 3.2. Internationalization of Names 426 For the most part, GSS-EAP names are transported in other protocols; 427 those protocols define the internationalization semantics. For 428 example, if an AAA server wishes to communicate the user-or-service 429 portion of the initiator name to an acceptor, it does so using 430 existing mechanisms in the AAA protocol. Existing 431 internationalization rules are applied. Similarly, within an 432 application, existing specifications such as [RFC5178] define the 433 encoding of names that are imported and displayed with the GSS-API. 435 This mechanism does introduce a few cases where name components are 436 sent. In these cases the encoding of the string is UTF-8. Senders 437 SHOULD NOT normalize or map strings before sending. These strings 438 include RADIUS attributes introduced in Section 3.4. 440 When comparing the host portion of a GSS-EAP acceptor name supplied 441 in EAP channel binding by a peer to that supplied by an acceptor, EAP 442 servers SHOULD prepare the host portion according to [RFC5891] prior 443 to comparison. Applications MAY prepare domain names prior to 444 importing them into this mechanism. 446 3.3. Exported Mechanism Names 448 GSS-API provides the GSS_Export_name call. This call can be used to 449 export the binary representation of a name. This name form can be 450 stored on access control lists for binary comparison. 452 The exported name token MUST use the format described in section 3.2 453 of RFC 2743. The mechanism specific portion of this name token is 454 the string format of the mechanism name described in Section 3.1. 456 RFC 2744 [RFC2744] places the requirement that the result of 457 importing a name, canonicalizing it to a Mechanism Name and then 458 exporting it needs to be the same as importing that name, obtaining 459 credentials for that principal, initiating a context with those 460 credentials and exporting the name on the acceptor. In practice, GSS 461 mechanisms often, but not always meet this requirement. For names 462 expected to be used as initiator names, this requirement is met. 463 However, permitting empty host and realm components when importing 464 hostbased services may make it possible for an imported name to 465 differ from the exported name actually used. Other mechanisms such 466 as Kerberos have similar situations where imported and exported names 467 may differ. 469 3.4. Acceptor Name RADIUS AVP 471 See Section 7.4 for registrations of RADIUS attribute types to carry 472 the acceptor service name. All the attribute types registered in 473 that section are strings. See Section 3.1 for details of the values 474 in a name. 476 If RADIUS is used as an AAA transport, the acceptor MUST send the 477 acceptor name in these attribute types. That is, the acceptor 478 decomposes its name and sends any non-empty portion as a RADIUS 479 attribute. With the exception of the service-specifics portion of 480 the name, the backslash escaping mechanism is not used in RADIUS 481 attributes; backslash has no special meaning. In the service- 482 specifics portion, a literal "/" separates components. In this one 483 attribute, "\/" indicates a slash character that does not separate 484 components and "\\" indicates a literal backslash character. 486 The initiator MUST require that the EAP method in use support channel 487 binding and MUST send the acceptor name as part of the channel 488 binding data. The client MUST NOT indicate mutual authentication in 489 the result of GSS_Init_Sec_Context unless all name elements that the 490 client supplied are in a successful channel binding response. For 491 example, if the client supplied a hostname in channel binding data, 492 the hostname MUST be in a successful channel binding response. 494 If an empty target name is supplied to GSS_Init_Sec_Context, the 495 initiator MUST fail context establishment unless the acceptor 496 supplies the acceptor name response (Section 5.4.3). If a null 497 target name is supplied, the initiator MUST use this response to 498 populate EAP channel bindings. 500 3.5. Proxy Verification of Acceptor Name 502 Proxies may play a role in verification of the acceptor identity. 503 For example, an AAA proxy near the acceptor may be in a position to 504 verify the acceptor hostname, while the EAP server is likely to be 505 too distant to reliably verify this on its own. 507 The EAP server or some proxy trusted by the EAP server is likely to 508 be in a position to verify the acceptor realm. In effect, this proxy 509 is confirming that the right AAA credential is used for the claimed 510 realm and thus that the acceptor is in the organization it claims to 511 be part of. This proxy is also typically trusted by the EAP server 512 to make sure that the hostname claimed by the acceptor is a 513 reasonable hostname for the realm of the acceptor. 515 A proxy close to the EAP server is unlikely to be in a position to 516 confirm that the acceptor is claiming the correct hostname. Instead 517 this is typically delegated to a proxy near the acceptor. That proxy 518 is typically expected to verify the acceptor hostname and to verify 519 the appropriate AAA credential for that host is used. Such a proxy 520 may insert the acceptor realm if it is absent, permitting realm 521 configuration to be at the proxy boundary rather than on acceptors. 523 Ultimately specific proxy behavior is a matter for deployment. The 524 EAP server MUST assure that the appropriate validation has been done 525 before including acceptor name attributes in a successful channel 526 binding response. If the acceptor service is included the EAP server 527 asserts that the service is plausible for the acceptor. If the 528 acceptor hostname is included the EAP server asserts that the 529 acceptor hostname is verified. If the realm is included the EAP 530 server asserts that the realm has been verified, and if the hostname 531 was also included, that the realm and hostname are consistent. Part 532 of this verification MAY be delegated to proxies, but the EAP server 533 configuration MUST guarantee that the combination of proxies meets 534 these requirements. Typically such delegation will involve business 535 or operational measures such as cross-organizational agreements as 536 well as technical measures. 538 It is likely that future technical work will be needed to communicate 539 what verification has been done by proxies along the path. Such 540 technical measures will not release the EAP server from its 541 responsibility to decide whether proxies on the path should be 542 trusted to perform checks delegated to them. However technical 543 measures could prevent misconfigurations and help to support diverse 544 environments. 546 4. Selection of EAP Method 548 EAP does not provide a facility for an EAP server to advertise what 549 methods are available to a peer. Instead, a server starts with its 550 preferred method selection. If the peer does not accept that method, 551 the peer sends a NAK response containing the list of methods 552 supported by the client. 554 Providing multiple facilities to negotiate which security mechanism 555 to use is undesirable. Section 7.3 of [RFC4462]describes the problem 556 referencing the SSH key exchange negotiation and the SPNEGO GSS-API 557 mechanism. If a client preferred an EAP method A, a non-EAP 558 authentication mechanism B, and then an EAP method C, then the client 559 would have to commit to using EAP before learning whether A is 560 actually supported. Such a client might end up using C when B is 561 available. 563 The standard solution to this problem is to perform all the 564 negotiation at one layer. In this case, rather than defining a 565 single GSS-API mechanism, a family of mechanisms should be defined. 566 Each mechanism corresponds to an EAP method. The EAP method type 567 should be part of the GSS-API OID. Then, a GSS-API rather than EAP 568 facility can be used for negotiation. 570 Unfortunately, using a family of mechanisms has a number of problems. 571 First, GSS-API assumes that both the initiator and acceptor know the 572 entire set of mechanisms that are available. Some negotiation 573 mechanisms are driven by the client; others are driven by the server. 574 With EAP GSS-API, the acceptor does not know what methods the EAP 575 server implements. The EAP server that is used depends on the 576 identity of the client. The best solution so far is to accept the 577 disadvantages of multi-layer negotiation and commit to using EAP GSS- 578 API before a specific EAP method. This has two main disadvantages. 579 First, authentication may fail when other methods might allow 580 authentication to succeed. Second, a non-optimal security mechanism 581 may be chosen. 583 5. Context Tokens 585 All context establishment tokens emitted by the EAP mechanism SHALL 586 have the framing described in section 3.1 of [RFC2743], as 587 illustrated by the following pseudo-ASN.1 structures: 589 GSS-API DEFINITIONS ::= 590 BEGIN 592 MechType ::= OBJECT IDENTIFIER 593 -- representing EAP mechanism 594 GSSAPI-Token ::= 595 -- option indication (delegation, etc.) indicated within 596 -- mechanism-specific token 597 [APPLICATION 0] IMPLICIT SEQUENCE { 598 thisMech MechType, 599 innerToken ANY DEFINED BY thisMech 600 -- contents mechanism-specific 601 -- ASN.1 structure not required 602 } 603 END 605 The innerToken field starts with a 16-bit network byte order token 606 type identifier. The remainder of the innerToken field is a set of 607 type-length-value subtokens. The following figure describes the 608 structure of the inner token: 610 +----------------+--------------------------+ 611 | Octet Position | Description | 612 +----------------+--------------------------+ 613 | 0..1 | token ID | 614 | | | 615 | 2..5 | first subtoken type | 616 | | | 617 | 6..9 | length of first subtoken | 618 | | | 619 | 10..10+n-1 | first subtoken body | 620 | | | 621 | 10+n..10+n+3 | second subtoken type | 622 +----------------+--------------------------+ 624 The inner token continues with length, second subtoken body, and so 625 forth. If a subtoken type is present, its length and body MUST be 626 present. 628 Structure of Inner Token 630 The length is a four-octet length of the subtoken body in network 631 byte order. The length does not include the length of the type field 632 or the length field; the length only covers the body. 634 Tokens from the initiator to acceptor use an inner token type with ID 635 06 01; tokens from acceptor to initiator use an inner token type with 636 ID 06 02. These token types are registered in the registry of RFC 637 4121 token types; see Section 7.2. 639 See Section 5.7 for the encoding of a complete token. The following 640 sections discuss how mechanism OIDs are chosen and the state machine 641 that defines what subtokens are permitted at each point in the 642 context establishment process. 644 5.1. Mechanisms and Encryption Types 646 This mechanism family uses the security services of the Kerberos 647 cryptographic framework [RFC3961]. The root of the OID ARC for 648 mechanisms described in this document is 1.3.6.1.5.5.15.1.1; a 649 Kerberos encryption type number [RFC3961] is appended to that root 650 OID to form a mechanism OID. As such, a particular encryption type 651 needs to be chosen. By convention, there is a single object 652 identifier arc for the EAP family of GSS-API mechanisms. A specific 653 mechanism is chosen by adding the numeric Kerberos encryption type 654 number to the root of this arc. However, in order to register the 655 SASL name, the specific usage with a given encryption type needs to 656 be registered. This document defines the EAP-AES128 GSS-API 657 mechanism. 659 5.2. Processing received tokens 661 Whenever a context token is received, the receiver performs the 662 following checks. First the receiver confirms the object identifier 663 is that of the mechanism being used. The receiver confirms that the 664 token type corresponds to the role of the peer: acceptors will only 665 process initiator tokens and initiators will only process acceptor 666 tokens. 668 Implementations of this mechanism maintain a state machine for the 669 context establishment process. Both the initiator and acceptor start 670 out in the initial state; see Section 5.4 for a description of this 671 state. Associated with each state are a set of subtoken types that 672 are processed in that state and rules for processing these subtoken 673 types. The reciever examines the subtokens in order, processing any 674 that are appropriate for the current state. Unknown subtokens or 675 subtokens that are not expected in the current state are ignored if 676 their critical bit (see below) is clear. 678 A state may have a set of required subtoken types. If a subtoken 679 type is required by the current state but no subtoken of that type is 680 present, then the context establishment MUST fail. 682 The most-significant bit (0x80000000) in a subtoken type is the 683 critical bit. If a subtoken with this bit set in the type is 684 received, the receiver MUST fail context establishment unless the 685 subtoken is understood and processed for the current state. 687 The subtoken type MUST be unique within a given token. 689 5.3. Error Subtokens 691 The acceptor may always end the exchange by generating an error 692 subtoken. The error subtoken has the following format: 694 +--------+----------------------------------------------------------+ 695 | Pos | Description | 696 +--------+----------------------------------------------------------+ 697 | 0..3 | 0x80 00 00 01 | 698 | | | 699 | 4..7 | length of error token | 700 | | | 701 | 8..11 | major status from RFC 2744 as 32-bit network byte order | 702 | | | 703 | 12..15 | GSS EAP error code as 32-bit network byte order; see | 704 | | Section 7.6 | 705 +--------+----------------------------------------------------------+ 707 Initiators MUST ignore octets beyond the GSS EAP error code for 708 future extensibility. As indicated, the error token is always marked 709 critical. 711 5.4. Initial State 713 Both the acceptor and initiator start the context establishment 714 process in the initial state. 716 The initiator sends a token to the acceptor. It MAY be empty; no 717 subtokens are required in this state. Alternatively the initiator 718 MAY include a vendor ID subtoken or an acceptor name request 719 subtoken. 721 The acceptor responds to this message. It MAY include an acceptor 722 name response subtoken. It MUST include a first eap request; this is 723 an EAP request/identity message (see Section 5.5.1 for the format of 724 this subtoken). 726 The initiator and acceptor then transition to authenticate state. 728 5.4.1. Vendor Subtoken 730 The vendor ID token has type 0x0000000B and the following structure: 732 +-------------+------------------------+ 733 | Pos | Description | 734 +-------------+------------------------+ 735 | 0..3 | 0x0000000B | 736 | | | 737 | 4..7 | length of vendor token | 738 | | | 739 | 8..8+length | Vendor ID string | 740 +-------------+------------------------+ 742 The vendor ID string is an UTF-8 string describing the vendor of this 743 implementation. This string is unstructured and for debugging 744 purposes only. 746 5.4.2. Acceptor Name Request 748 The acceptor name request token is sent from the initiator to the 749 acceptor indicating that the initiator wishes a particular acceptor 750 name. This is similar to TLS Server Name Indication [RFC6066] which 751 permits a client to indicate which one of a number of virtual 752 services to contact. The structure is as follows: 754 +------+------------------------------+ 755 | Pos | Description | 756 +------+------------------------------+ 757 | 0..3 | 0x00000002 | 758 | | | 759 | 4..7 | Length of subtoken | 760 | | | 761 | 8..n | string form of acceptor name | 762 +------+------------------------------+ 764 It is likely that channel binding and thus authentication will fail 765 if the acceptor does not choose a name that is a superset of this 766 name. That is, if a hostname is sent, the acceptor needs to be 767 willing to accept this hosntame. 769 5.4.3. Acceptor Name Response 771 The acceptor name response subtoken indicates what acceptor name is 772 used. This is useful for example if the initiator supplied no target 773 name to context initialization. This allows the initiator to learn 774 the acceptor name. EAP channel bindings will provide confirmation 775 that the acceptor is accurately naming itself. 777 this token is sent from the acceptor to initiator. In the Initial 778 state, this token would typically be sent if the acceptor name 779 request is absent, because if the initiator already sent an acceptor 780 name then the initiator knows what acceptor it wishes to contact. 781 This subtoken is also sent in extensions state Section 5.6 so the 782 initiator can protect against a man-in-the-middle modifying the 783 acceptor name request subtoken. 785 +------+------------------------------+ 786 | Pos | Description | 787 +------+------------------------------+ 788 | 0..3 | 0x00000003 | 789 | | | 790 | 4..7 | Length of subtoken | 791 | | | 792 | 8..n | string form of acceptor name | 793 +------+------------------------------+ 795 5.5. Authenticate State 797 In this state, the acceptor sends EAP requests to the initiator and 798 the initiator generates EAP responses. The goal of the state is to 799 perform a successful EAP authentication. Since the acceptor sends an 800 identity request at the end of the initial state, the first half- 801 round-trip in this state is a response to that request from the 802 initiator. 804 The EAP conversation can end in a number of ways: 806 o If the EAP state machine generates an EAP success message, then 807 the EAP authenticator believes the authentication is successful. 808 The Acceptor MUST confirm that a key has been derived (Section 809 7.10 of [RFC3748]). The acceptor MUST confirm that this success 810 indication is consistent with any protected result indication for 811 combined authenticators and with AAA indication of success for 812 pass-through authenticators. If any of these checks fail, the 813 acceptor MUST send an error subtoken and fail the context 814 establishment. If these checks succeed the acceptor sends the 815 success message using the EAP Request subtoken type and 816 transitions to Extensions state. If the initiator receives an EAP 817 Success message, it confirms that a key has been derived and that 818 the EAP success is consistent with any protected result 819 indication. If so, it transitions to Extensions state. 820 Otherwise, it returns an error to the caller of 821 GSS_Init_Sec_context without producing an output token. 823 o If the acceptor receives an EAP failure, then the acceptor sends 824 this in the Eap Request subtoken type. If the initiator receives 825 an EAP Failure, it returns GSS failure. 827 o If there is some other error, the acceptor MAY return an error 828 subtoken. 830 5.5.1. EAP Request Subtoken 832 The EAP Request subtoken is sent from the acceptor to the initiator. 833 This subtoken is always critical and is REQUIRED in the 834 authentication state. 836 +-------------+-----------------------+ 837 | Pos | Description | 838 +-------------+-----------------------+ 839 | 0..3 | 0x80000005 | 840 | | | 841 | 4..7 | Length of EAP message | 842 | | | 843 | 8..8+length | EAP message | 844 +-------------+-----------------------+ 846 5.5.2. EAP Response Subtoken 848 This subtoken is REQUIRED in authentication state messages from the 849 initiator to the acceptor. It is always critical. 851 +-------------+-----------------------+ 852 | Pos | Description | 853 +-------------+-----------------------+ 854 | 0..3 | 0x80000004 | 855 | | | 856 | 4..7 | Length of EAP message | 857 | | | 858 | 8..8+length | EAP message | 859 +-------------+-----------------------+ 861 5.6. Extension State 863 After EAP success, the initiator sends a token to the acceptor 864 including additional subtokens that negotiate optional features or 865 provide GSS-API channel binding (see Section 6.1). The acceptor then 866 responds with a token to the initiator. When the acceptor produces 867 its final token it returns GSS_S_COMPLETE; when the initiator 868 consumes this token it returns GSS_S_COMPLETE if no errors are 869 detected. 871 The acceptor SHOULD send an acceptor name response (Section 5.4.3) so 872 that the initiator can get a copy of the acceptor name protected by 873 the MIC subtoken. 875 Both the initiator and acceptor MUST include and verify a MIC 876 subtoken to protect the extensions exchange. 878 5.6.1. Flags Subtoken 880 This token is sent to convey initiator flags to the acceptor. The 881 flags are sent as a 32-bit integer in network byte order. The only 882 flag defined so far is GSS_C_MUTUAL_FLAG, indicating that the 883 initiator successfully performed mutual authentication of the 884 acceptor. This flag is communicated to the acceptor because some 885 protocols [RFC4462] require the acceptor to know whether the 886 initiator has confirmed its identity. This flag has the value 0x2 to 887 be consistent with RFC 2744. 889 +-------+-----------------------+ 890 | Pos | Description | 891 +-------+-----------------------+ 892 | 0..3 | 0x0000000C | 893 | | | 894 | 4..7 | length of flags token | 895 | | | 896 | 8..11 | flags | 897 +-------+-----------------------+ 899 Initiators MUST send 4 octets of flags. Acceptors MUST ignore flag 900 octets beyond the first 4 and MUST ignore flag bits other than 901 GSS_C_MUTUAL_FLAG. Initiators MUST send undefined flag bits as zero. 903 5.6.2. GSS Channel Bindings Subtoken 905 This token is always critical when sent. It is sent from the 906 initiator to the acceptor. The contents of this token are an RFC 907 3961 get_mic token of the application data from the GSS channel 908 bindings structure passed into the context establishment call. 910 +-------------+---------------------------------------------+ 911 | Pos | Description | 912 +-------------+---------------------------------------------+ 913 | 0..3 | 0x80000006 | 914 | | | 915 | 4..7 | length of token | 916 | | | 917 | 8..8+length | get_mic of channel binding application data | 918 +-------------+---------------------------------------------+ 920 Again, only the application data is sent in the channel binding. Any 921 initiator and acceptor addresses passed by an application into 922 context establishment calls are ignored and not sent over the wire. 923 The checksum type of the get_mic token SHOULD be the mandatory to 924 implement checksum type of the Context Root Key (CRK.) The key to 925 use is the CRK and the key usage is 60 (KEY_USAGE_GSSEAP_CHBIND_MIC). 926 An acceptor MAY accept any MIC in the channel bindings subtoken if 927 the channel bindings input to GSS_Accept_Sec_context is not provided. 928 If the channel binding input to GSS_Accept_Sec_context is provided, 929 the acceptor MUST return failure if the channel binding MIC in a 930 received channel binding subtoken fails to verify. 932 The initiator MUST send this token if channel bindings including 933 application data are passed into GSS_Init_Sec_context and MUST NOT 934 send this token otherwise. 936 5.6.3. MIC Subtoken 938 This token MUST be the last subtoken in the tokens sent in Extensions 939 state. This token is sent both by the initiator and acceptor. 941 +-------------+--------------------------------------------------+ 942 | Pos | Description | 943 +-------------+--------------------------------------------------+ 944 | 0..3 | 0x8000000D for initiator 0x8000000E for acceptor | 945 | | | 946 | 4..7 | Length of RFC 3961 MIC token | 947 | | | 948 | 8..8+length | RFC 3961 result of get_mic | 949 +-------------+--------------------------------------------------+ 951 As with any call to get_mic, a token is produced as described in RFC 952 3961 using the CRK Section 6 as the key and the mandatory checksum 953 type for the encryption type of the CRK as the checksum type. The 954 key usage is 61 (KEY_USAGE_GSSEAP_ACCTOKEN_MIC) for the subtoken from 955 the acceptor to the initiator and 62 (KEY_USAGE_GSSEAP_INITTOKEN_MIC) 956 for the subtoken from the initiator to the acceptor. The input is as 957 follows: 959 1. The DER-encoded object identifier of the mechanism in use; this 960 value starts with 0x06 (the tag for object identifier). When 961 encoded in an RFC 2743 context token, the object identifier is 962 preceeded by the tag and length for [Application 0] SEQUENCE. 963 This tag and the length of the overall token is not included; 964 only the tag, length and value of the object identifier itself. 966 2. A 16-bit token type in network byte order of the RFC 4121 token 967 identifier (0x0601 for initiator, 0x0602 for acceptor). 969 3. For each subtoken other than the MIC subtoken itself in the order 970 the subtokens appear in the token: 972 1. A four octet subtoken type in network byte order 974 2. A four byte length in network byte order 976 3. Length octets of value from that subtoken 978 5.7. Example Token 980 +----+------+----+------+-----+-------------------------+ 981 | 60 | 23 | 06 | 09 | 2b | 06 01 05 05 0f 01 01 11 | 982 +----+------+----+------+-----+-------------------------+ 983 |App0|Token |OID |OID | 1 3 | 6 1 5 5 15 1 1 17 | 984 |Tag |length|Tag |length| Mechanism object id | 985 +----+------+----+------+-------------------------------+ 987 +----------+-------------+-------------+ 988 | 06 01 | 00 00 00 02 | 00 00 00 0e | 989 +----------+-------------|-------------| 990 |Initiator | Acceptor | Length | 991 |context | name | (14 octets) | 992 |token id | request | | 993 +----------+-------------+-------------+ 995 +-------------------------------------------+ 996 | 68 6f 73 74 2f 6c 6f 63 61 6c 68 6f 73 74 | 997 +-------------------------------------------+ 998 | String form of acceptor name | 999 | "host/localhost" | 1000 +-------------------------------------------+ 1002 Example Initiator Token 1004 5.8. Context Options 1006 GSS-API provides a number of optional per-context services requested 1007 by flags on the call to GSS_Init_sec_context and indicated as outputs 1008 from both GSS_Init_sec_context and GSS_Accept_sec_context. This 1009 section describes how these services are handled. Which services the 1010 client selects in the call to GSS_Init_sec_context controls what EAP 1011 methods MAY be used by the client. Section 7.2 of RFC 3748 describes 1012 a set of security claims for EAP. As described below, the selected 1013 GSS options place requirements on security claims that MUST be met. 1015 This GSS mechanism MUST only be used with EAP methods that provide 1016 dictionary attack resistance. Typically dictionary attack resistance 1017 is obtained by using an EAP tunnel method to tunnel an inner method 1018 in TLS. 1020 The EAP method MUST support key derivation. Integrity, 1021 confidentiality, sequencing and replay detection MUST be indicated in 1022 the output of GSS_Init_Sec_Context and GSS_Accept_Sec_context 1023 regardless of which services are requested. 1025 The PROT_READY service defined in Section 1.2.7 of [RFC2743] is never 1026 available with this mechanism. Implementations MUST NOT offer this 1027 flag or permit per-message security services to be used before 1028 context establishment. 1030 The EAP method MUST support mutual authentication and channel 1031 binding. See Section 3.4 for details on what is required for 1032 successful mutual authentication. Regardless of whether mutual 1033 authentication is requested, the implementation MUST include channel 1034 bindings in the EAP authentication. If mutual authentication is 1035 requested and successful mutual authentication takes place as defined 1036 in Section 3.4, the initiator MUST send a flags subtoken 1037 Section 5.6.1 in Extensions state. 1039 6. Acceptor Services 1041 The context establishment process may be passed through to a EAP 1042 server via a backend authentication protocol. However after the EAP 1043 authentication succeeds, security services are provided directly by 1044 the acceptor. 1046 This mechanism uses an RFC 3961 cryptographic key called the context 1047 root key (CRK). The CRK is derived from the GMSK (GSS-API MSK). The 1048 GMSK is the result of the random-to-key [RFC3961] operation of the 1049 encryption type of this mechanism consuming the appropriate number of 1050 bits from the EAP master session key. For example for aes128-cts- 1051 hmac-sha1-96, the random-to-key operation consumes 16 octets of key 1052 material; thus the first 16 bytes of the master session key are input 1053 to random-to-key to form the GMSK. If the MSK is too short, 1054 authentication MUST fail. 1056 In the following, pseudo-random is the RFC 3961 pseudo-random 1057 operation for the encryption type of the GMSK and random-to-key is 1058 the RFC 3961 random-to-key operation for the enctype of the 1059 mechanism. The truncate function takes the initial l bits of its 1060 input. The goal in constructing a CRK is to call the pseudo-random 1061 function enough times to produce the right number of bits of output 1062 and discard any excess bits of output. 1064 The CRK is derived from the GMSK using the following procedure 1066 Tn = pseudo-random(GMSK, n || "rfc4121-gss-eap") 1067 CRK = random-to-key(truncate(L, T0 || T1 || .. || Tn)) 1068 L = random-to-key input size 1070 Where n is a 32-bit integer in network byte order starting at 0 and 1071 incremented to each call to the pseudo_random operation. 1073 6.1. GSS-API Channel Binding 1075 GSS-API channel binding [RFC5554] is a protected facility for 1076 exchanging a cryptographic name for an enclosing channel between the 1077 initiator and acceptor. The initiator sends channel binding data and 1078 the acceptor confirms that channel binding data has been checked. 1080 The acceptor SHOULD accept any channel binding provided by the 1081 initiator if null channel bindings are passed into 1082 gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] 1083 depend on this behavior of some Kerberos implementations. 1085 As discussed, the GSS channel bindings subtoken is sent in the 1086 extensions state. 1088 6.2. Per-message security 1090 The per-message tokens of section 4 of RFC 4121 are used. The CRK 1091 SHALL be treated as the initiator sub-session key, the acceptor sub- 1092 session key and the ticket session key. 1094 6.3. Pseudo Random Function 1096 The pseudo random function defined in [RFC4402] is used to provide 1097 GSS_Pseudo_Random functionality to applications. 1099 7. Iana Considerations 1101 This specification creates a number of IANA registries. 1103 7.1. OID Registry 1105 IANA is requested to create a registry of ABFAB object identifiers 1106 titled "Object Identifiers for Application Bridging for federated 1107 Access". The initial contents of the registry are specified below. 1108 The registration policy is IETF review or IESG approval. Early 1109 allocation is permitted. IANA is requested to update the reference 1110 for the root of this OID delegation to point to the newly created 1111 registry. 1113 Prefix: iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15) 1115 Decimal Name Description References 1116 ------- ---- ------------------------------------ ---------- 1117 0 Reserved Reserved 1118 1 mechanisms A sub-arc containing ABFAB mechanisms 1119 2 nametypes A sub-arc containing ABFAB GSS-API Name Types 1121 NOTE: the following mechanisms registry are the root of the OID for 1122 the mechanism in question. As discussed in Section 5.1 1123 [draft-ietf-abbfab-gss-eap], a Kerberos encryption type number 1124 [RFC3961] is appended to the mechanism version OID below to form the 1125 OID of a specific mechanism. 1127 Prefix: iso.org.dod.internet.security.mechanisms.abfab.mechanisms 1128 (1.3.6.1.5.5.15.1) 1130 Decimal Name Description References 1131 ------- ---- ------------------------------------ ---------- 1132 0 Reserved Reserved 1133 1 gss-eap-v1 The GSS-EAP mechanism [this spec 1135 Prefix: iso.org.dod.internet.security.mechanisms.abfab.nametypes 1136 (1.3.6.1.5.5.15.2) 1138 Decimal Name Description References 1139 ------- ---- ------------------------------------ ---------- 1140 0 Reserved Reserved 1141 1 GSS_EAP_NT_EAP_NAME sect 3.1 1143 7.2. RFC 4121 Token Identifiers 1145 In the top level registry titled "Kerberos V GSS-API Mechanism 1146 Parameters," a sub-registry called "Kerberos GSS-API Token Type 1147 Identifiers" is created; the overall reference for this subregistry 1148 is section 4.1 of RFC 4121. The allocation procedure is expert 1149 review [RFC5226]. The expert's primary job is to make sure that 1150 token type identifiers are requested by an appropriate requester for 1151 the RFC 4121 mechanism in which they will be used and that multiple 1152 values are not allocated for the same purpose. For RFC 4121 and this 1153 mechanism, the expert is currently expected to make allocations for 1154 token identifiers from documents in the IETF stream; effectively for 1155 these mechanisms the expert currently confirms the allocation meets 1156 the requirements of the IETF review process. 1158 The ID field is a hexadecimal token identifier specified in network 1159 byte order. 1161 The initial registrations are as follows: 1163 +-------+---------------------------------+-----------------------+ 1164 | ID | Description | Reference | 1165 +-------+---------------------------------+-----------------------+ 1166 | 01 00 | KRB_AP_REQ | RFC 4121 sect 4.1 | 1167 | | | | 1168 | 02 00 | KRB_AP_REP | RFC 4121 sect 4.1 | 1169 | | | | 1170 | 03 00 | KRB_ERROR | RFC 4121 sect 4.1 | 1171 | | | | 1172 | 04 04 | MIC tokens | RFC 4121 sect 4.2.6.1 | 1173 | | | | 1174 | 05 04 | wrap tokens | RFC 4121 sect 4.2.6.2 | 1175 | | | | 1176 | 06 01 | GSS-EAP initiator context token | Section 5 | 1177 | | | | 1178 | 06 02 | GSS EAP acceptor context token | Section 5 | 1179 +-------+---------------------------------+-----------------------+ 1181 7.3. GSS EAP Subtoken Types 1183 This document creates a top level registry called "The Extensible 1184 Authentication Protocol Mechanism for the Generic Security Services 1185 Application Programming Interface (GSS-EAP) Parameters". In any 1186 short form of that name, including any URI for this registry, it is 1187 important that the string GSS come before the string EAP; this will 1188 help to distinguish registries if EAP methods for performing GSS-API 1189 authentication are ever defined. 1191 In this registry is a subregistry of subtoken types; identifiers are 1192 32-bit integers; the upper bit (0x80000000) is reserved as a critical 1193 flag and should not be indicated in the registration. Assignments of 1194 GSS EAP subtoken types are made by expert review. The expert is 1195 expected to require a public specification of the subtoken similar in 1196 detail to registrations given in this document. The security of GSS- 1197 EAP depends on making sure that subtoken information has adequate 1198 protection and that the overall mechanism continues to be secure. 1199 Examining the security and architectural consistency of the proposed 1200 registration is the primary responsibility of the expert. 1202 +------------+--------------------------+---------------+ 1203 | Type | Description | Reference | 1204 +------------+--------------------------+---------------+ 1205 | 0x00000001 | Error | Section 5.3 | 1206 | | | | 1207 | 0x0000000B | Vendor | Section 5.4.1 | 1208 | | | | 1209 | 0x00000002 | Acceptor name request | Section 5.4.2 | 1210 | | | | 1211 | 0x00000003 | Acceptor name response | Section 5.4.3 | 1212 | | | | 1213 | 0x00000005 | EAP request | Section 5.5.1 | 1214 | | | | 1215 | 0x00000004 | EAP response | Section 5.5.2 | 1216 | | | | 1217 | 0x0000000C | Flags | Section 5.6.1 | 1218 | | | | 1219 | 0x00000006 | GSS-API channel bindings | Section 5.6.2 | 1220 | | | | 1221 | 0x0000000D | Initiator MIC | Section 5.6.3 | 1222 | | | | 1223 | 0x0000000E | Acceptor MIC | Section 5.6.3 | 1224 +------------+--------------------------+---------------+ 1226 7.4. RADIUS Attribute Assignments 1228 The following RADIUS attribute type values [RFC3575] are assigned. 1229 The assignment rules in section 10.3 of 1230 [I-D.ietf-radext-radius-extensions] may be used if that specification 1231 is approved when IANA actions for this specification are processed. 1233 +--------------------------------+-----------+----------------------+ 1234 | Name | Attribute | Description | 1235 +--------------------------------+-----------+----------------------+ 1236 | GSS-Acceptor-Service-Name | TBD1 | user-or-service | 1237 | | | portion of name | 1238 | | | | 1239 | GSS-Acceptor-Host-Name | TBD2 | host portion of name | 1240 | | | | 1241 | GSS-Acceptor-Service-specifics | TBD3 | service-specifics | 1242 | | | portion of name | 1243 | | | | 1244 | GSS-Acceptor-Realm-Name | TBD4 | Realm portion of | 1245 | | | name | 1246 +--------------------------------+-----------+----------------------+ 1248 7.5. Registration of the EAP-AES128 SASL Mechanisms 1250 Subject: Registration of SASL mechanisms 1251 EAP-AES128 and EAP-AES128-PLUS 1253 SASL mechanism names: EAP-AES128 and EAP-AES128-PLUS 1255 Security considerations: See RFC 5801 and draft-ietf-abfab-gss-eap 1257 Published specification (recommended): draft-ietf-abfab-gss-eap 1259 Person & email address to contact for further information: 1260 Abfab Working Group abfab@ietf.org 1262 Intended usage: common 1264 Owner/Change controller: iesg@ietf.org 1266 Note: This mechanism describes the GSS-EAP mechanism used with 1267 the aes128-cts-hmac-sha1-96 enctype. The GSS-API OID for this 1268 mechanism is 1.3.6.1.5.5.15.1.1.17 1269 As described in RFC 5801 a PLUS varient of this mechanism is 1270 also required. 1272 7.6. GSS EAP Errors 1274 A new subregistry is created in the GSS EAP parameters registry 1275 titled "Error Codes". The error codes in this registry are unsigned 1276 32-bit numbers. Values less than or equal to 127 are assigned by 1277 standards action. Values 128 through 255 are assigned with the 1278 specification required assignment policy. Values greater than 255 1279 are reserved; updates to registration policy may make these values 1280 available for assignment and implementations MUST be prepared to 1281 receive them. 1283 This table provides the initial contents of the registry. 1285 +-------+----------------------------------------------------+ 1286 | Value | Description | 1287 +-------+----------------------------------------------------+ 1288 | 0 | Reserved | 1289 | | | 1290 | 1 | Buffer is incorrect size | 1291 | | | 1292 | 2 | Incorrect mechanism OID | 1293 | | | 1294 | 3 | Token is corrupted | 1295 | | | 1296 | 4 | Token is truncated | 1297 | | | 1298 | 5 | Packet received by direction that sent it | 1299 | | | 1300 | 6 | Incorrect token type identifier | 1301 | | | 1302 | 7 | Unhandled critical subtoken received | 1303 | | | 1304 | 8 | Missing required subtoken | 1305 | | | 1306 | 9 | Duplicate subtoken type | 1307 | | | 1308 | 10 | Received unexpected subtoken for current state xxx | 1309 | | | 1310 | 11 | EAP did not produce a key | 1311 | | | 1312 | 12 | EAP key too short | 1313 | | | 1314 | 13 | Authentication rejected | 1315 | | | 1316 | 14 | AAA returned an unexpected message type | 1317 | | | 1318 | 15 | AAA response did not include EAP request | 1319 | | | 1320 | 16 | Generic AAA failure | 1321 +-------+----------------------------------------------------+ 1323 7.7. GSS EAP Context Flags 1325 A new sub-registry is created in the GSS EAP parameters registry. 1326 This registry holds registrations of flag bits sent in the flags 1327 subtoken Section 5.6.1. There are 32 flag bits available for 1328 registration represented as hexadecimal numbers from the most- 1329 significant bit 0x80000000 to the least significant bit 0x1. The 1330 registration policy for this registry is IETF review or in 1331 exceptional cases IESG approval. The following table indicates 1332 initial registrations; all other values are available for assignment. 1334 +------+-------------------+---------------+ 1335 | Flag | Name | Reference | 1336 +------+-------------------+---------------+ 1337 | 0x2 | GSS_C_MUTUAL_FLAG | Section 5.6.1 | 1338 +------+-------------------+---------------+ 1340 8. Security Considerations 1342 RFC 3748 discusses security issues surrounding EAP. RFC 5247 1343 discusses the security and requirements surrounding key management 1344 that leverages the AAA infrastructure. These documents are critical 1345 to the security analysis of this mechanism. 1347 RFC 2743 discusses generic security considerations for the GSS-API. 1348 RFC 4121 discusses security issues surrounding the specific per- 1349 message services used in this mechanism. 1351 As discussed in Section 4, this mechanism may introduce multiple 1352 layers of security negotiation into application protocols. Multiple 1353 layer negotiations are vulnerable to a bid-down attack when a 1354 mechanism negotiated at the outer layer is preferred to some but not 1355 all mechanisms negotiated at the inner layer; see section 7.3 of 1356 [RFC4462] for an example. One possible approach to mitigate this 1357 attack is to construct security policy such that the preference for 1358 all mechanisms negotiated in the inner layer falls between 1359 preferences for two outer layer mechanisms or falls at one end of the 1360 overall ranked preferences including both the inner and outer layer. 1361 Another approach is to only use this mechanism when it has 1362 specifically been selected for a given service. The second approach 1363 is likely to be common in practice because one common deployment will 1364 involve an EAP supplicant interacting with a user to select a given 1365 identity. Only when an identity is successfully chosen by the user 1366 will this mechanism be attempted. 1368 EAP channel binding is used to give the GSS-API initiator confidence 1369 in the identity of the GSS-API acceptor. Thus, the security of this 1370 mechanism depends on the use and verification of EAP channel binding. 1371 Today EAP channel binding is in very limited deployment. If EAP 1372 channel binding is not used, then the system may be vulnerable to 1373 phishing attacks where a user is diverted from one service to 1374 another. If the EAP method in question supports mutual 1375 authentication then users can only be diverted between servers that 1376 are part of the same AAA infrastructure. For deployments where 1377 membership in the AAA infrastructure is limited, this may serve as a 1378 significant limitation on the value of phishing as an attack. For 1379 other deployments, use of EAP channel binding is critical to avoid 1380 phishing. These attacks are possible with EAP today although not 1381 typically with common GSS-API mechanisms. For this reason, 1382 implementations are required to implement and use EAP channel 1383 binding; see Section 3 for details. 1385 The security considerations of EAP channel binding 1386 [I-D.ietf-emu-chbind] describe the security properties of channel 1387 binding. Two attacks are worth calling out here. First, when a 1388 tunneled EAP method is used, it is critical that the channel binding 1389 be performed with an EAP server trusted by the peer. With existing 1390 EAP methods this typically requires validating the certificate of the 1391 server tunnel endpoint back to a trust anchor and confirming the name 1392 of the entity who is a subject of that certificate. EAP methods may 1393 suffer from bid-down attacks where an attacker can cause a peer to 1394 think that a particular EAP server does not support channel binding. 1395 This does not directly cause a problem because mutual authentication 1396 is only offered at the GSS-API level when channel binding to the 1397 server's identity is successful. However when an EAP method is not 1398 vulnerable to these bid-down attacks, additional protection is 1399 available. This mechanism will benefit significantly from new strong 1400 EAP methods such as [I-D.ietf-emu-eap-tunnel-method]. 1402 Every proxy in the AAA chain from the authenticator to the EAP server 1403 needs to be trusted to help verify channel bindings and to protect 1404 the integrity of key material. GSS-API applications may be built to 1405 assume a trust model where the acceptor is directly responsible for 1406 authentication. However, GSS-API is definitely used with trusted- 1407 third-party mechanisms such as Kerberos. 1409 RADIUS does provide a weak form of hop-by-hop confidentiality of key 1410 material based on using MD5 as a stream cipher. Diameter can use TLS 1411 or IPsec but has no mandatory-to-implement confidentiality mechanism. 1412 Operationally, protecting key material as it is transported between 1413 the IDP and RP is critical to per-message security and verification 1414 of GSS-API channel binding [RFC5056]. Mechanisms such as RADIUS over 1415 TLS [I-D.ietf-radext-radsec] provide significantly better protection 1416 of key material than the base RADIUS specification. 1418 9. Acknowledgements 1420 Luke Howard, Jim Schaad, Alejandro Perez Mendez, Alexey Melnikov and 1421 Sujing Zhou provided valuable reviews of this document. 1423 Rhys Smith provided the text for the OID registry section. Sam 1424 Hartman's work on this draft has been funded by JANET. 1426 10. References 1428 10.1. Normative References 1430 [GSS-IANA] 1431 IANA, "GSS-API Service Name Registry", . 1435 [I-D.ietf-abfab-eapapplicability] 1436 Winter, S. and J. Salowey, "Update to the EAP 1437 Applicability Statement for ABFAB", 1438 draft-ietf-abfab-eapapplicability-00 (work in progress), 1439 July 2012. 1441 [I-D.ietf-emu-chbind] 1442 Hartman, S., Clancy, T., and K. Hoeper, "Channel Binding 1443 Support for EAP Methods", draft-ietf-emu-chbind-16 (work 1444 in progress), May 2012. 1446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1447 Requirement Levels", BCP 14, RFC 2119, March 1997. 1449 [RFC2743] Linn, J., "Generic Security Service Application Program 1450 Interface Version 2, Update 1", RFC 2743, January 2000. 1452 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 1453 C-bindings", RFC 2744, January 2000. 1455 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1456 Authentication Dial In User Service)", RFC 3575, 1457 July 2003. 1459 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1460 Levkowetz, "Extensible Authentication Protocol (EAP)", 1461 RFC 3748, June 2004. 1463 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1464 Kerberos 5", RFC 3961, February 2005. 1466 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1467 Version 5 Generic Security Service Application Program 1468 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1469 July 2005. 1471 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1472 Network Access Identifier", RFC 4282, December 2005. 1474 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1475 Extension for the Generic Security Service Application 1476 Program Interface (GSS-API)", RFC 4401, February 2006. 1478 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1479 Kerberos V Generic Security Service Application Program 1480 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1482 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1483 Channels", RFC 5056, November 2007. 1485 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1486 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1488 [RFC5554] Williams, N., "Clarifications and Extensions to the 1489 Generic Security Service Application Program Interface 1490 (GSS-API) for the Use of Channel Bindings", RFC 5554, 1491 May 2009. 1493 [RFC5891] Klensin, J., "Internationalized Domain Names in 1494 Applications (IDNA): Protocol", RFC 5891, August 2010. 1496 10.2. Informative References 1498 [I-D.ietf-abfab-arch] 1499 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1500 Schaad, "Application Bridging for Federated Access Beyond 1501 Web (ABFAB) Architecture", draft-ietf-abfab-arch-03 (work 1502 in progress), July 2012. 1504 [I-D.ietf-emu-eap-tunnel-method] 1505 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1506 "Tunnel EAP Method (TEAP) Version 1", 1507 draft-ietf-emu-eap-tunnel-method-03 (work in progress), 1508 June 2012. 1510 [I-D.ietf-krb-wg-gss-cb-hash-agility] 1511 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 1512 Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility-10 1513 (work in progress), January 2012. 1515 [I-D.ietf-radext-radius-extensions] 1516 DeKok, A. and A. Lior, "Remote Authentication Dial In User 1517 Service (RADIUS) Protocol Extensions", 1518 draft-ietf-radext-radius-extensions-06 (work in progress), 1519 June 2012. 1521 [I-D.ietf-radext-radsec] 1522 Wierenga, K., McCauley, M., Winter, S., and S. Venaas, 1523 "Transport Layer Security (TLS) encryption for RADIUS", 1524 draft-ietf-radext-radsec-12 (work in progress), 1525 February 2012. 1527 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1528 RFC 1964, June 1996. 1530 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1531 Dial In User Service) Support For Extensible 1532 Authentication Protocol (EAP)", RFC 3579, September 2003. 1534 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1535 Authentication Protocol (EAP) Application", RFC 4072, 1536 August 2005. 1538 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 1539 Simple and Protected Generic Security Service Application 1540 Program Interface (GSS-API) Negotiation Mechanism", 1541 RFC 4178, October 2005. 1543 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1544 Security Layer (SASL)", RFC 4422, June 2006. 1546 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1547 "Generic Security Service Application Program Interface 1548 (GSS-API) Authentication and Key Exchange for the Secure 1549 Shell (SSH) Protocol", RFC 4462, May 2006. 1551 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1552 Kerberos and NTLM HTTP Authentication in Microsoft 1553 Windows", RFC 4559, June 2006. 1555 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 1556 Application Program Interface (GSS-API) 1557 Internationalization and Domain-Based Service Names and 1558 Name Type", RFC 5178, May 2008. 1560 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1561 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1562 May 2008. 1564 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1565 Authentication Protocol (EAP) Key Management Framework", 1566 RFC 5247, August 2008. 1568 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1569 Extension Definitions", RFC 6066, January 2011. 1571 Appendix A. Pre-Publication RADIUS VSA 1573 As described in Section 3.4, RADIUS attributes are used to carry the 1574 acceptor name when this family of mechanisms is used with RADIUS. 1575 Prior to publication of this specification, a vendor-specific RADIUS 1576 attribute was used. This non-normative appendix documents that 1577 attribute as it may be seen from older implementations. 1579 Prior to IANA assignment, GSS-EAP used a RADIUS vendor-specific 1580 attribute for carrying the acceptor name. The VSA with enterprise ID 1581 25622 is formatted as a VSA according to the recommendation in the 1582 RADIUS specification. The following sub-attributes are defined: 1584 +--------------------------------+-----------+----------------------+ 1585 | Name | Attribute | Description | 1586 +--------------------------------+-----------+----------------------+ 1587 | GSS-Acceptor-Service-Name | 128 | user-or-service | 1588 | | | portion of name | 1589 | | | | 1590 | GSS-Acceptor-Host-Name | 129 | host portion of name | 1591 | | | | 1592 | GSS-Acceptor-Service-specifics | 130 | service-specifics | 1593 | | | portion of name | 1594 | | | | 1595 | GSS-Acceptor-Realm-Name | 131 | Realm portion of | 1596 | | | name | 1597 +--------------------------------+-----------+----------------------+ 1599 Authors' Addresses 1601 Sam Hartman (editor) 1602 Painless Security 1604 Email: hartmans-ietf@mit.edu 1606 Josh Howlett 1607 JANET 1609 Email: josh.howlett@ja.net