idnits 2.17.1 draft-arkko-eap-service-identity-auth-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1132. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '...are found, these SHOULD be logged; add...' RFC 2119 keyword, line 198: '... actions MAY also be taken, such ...' RFC 2119 keyword, line 446: '... authentication SHOULD be terminated ...' RFC 2119 keyword, line 564: '...ved for future use. The value MUST be...' RFC 2119 keyword, line 565: '... the sender, and MUST be ignored by th...' (13 more instances...) 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 (October 24, 2005) is 6757 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) ** Obsolete normative reference: RFC 2434 (ref. '1') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2716 (ref. '2') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 3546 (ref. '3') (Obsoleted by RFC 4366) ** Downref: Normative reference to an Informational draft: draft-haverinen-pppext-eap-sim (ref. '5') == Outdated reference: A later version (-16) exists of draft-arkko-pppext-eap-aka-15 ** Downref: Normative reference to an Informational draft: draft-arkko-pppext-eap-aka (ref. '6') -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-06) exists of draft-cam-winget-eap-fast-01 == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-03 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extensible Authentication Protocol J. Arkko 3 Working Group Ericsson 4 Internet-Draft P. Eronen 5 Expires: April 27, 2006 Nokia 6 October 24, 2005 8 Authenticated Service Information for the Extensible Authentication 9 Protocol (EAP) 10 draft-arkko-eap-service-identity-auth-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 EAP is typically used in an arrangement where the actual service 44 (such as a wireless LAN access point) is separated from the 45 authentication server. However, EAP itself does not have a concept 46 of a service identity or its parameters, and thus the client usually 47 does not authenticate any information about the service itself, even 48 when a mutually authenticating EAP method is used. This document 49 specifies a backward compatible extension to popular EAP methods for 50 authenticating service related information, such as the identity and 51 type of the offered service. A common parameter name space is 52 created in order to ensure that the same kinds of identifiers can be 53 authenticated independent of the choice of the EAP authentication 54 method, retaining the EAP media independence principle. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Authenticated Service Information . . . . . . . . . 3 60 2. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Media Independence . . . . . . . . . . . . . . . . . 6 62 2.2. Verifying Party . . . . . . . . . . . . . . . . . . 8 63 2.3. Communication within EAP vs. within AAA . . . . . . 9 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 65 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 12 67 4.2. General Parameters . . . . . . . . . . . . . . . . . 13 68 4.2.1. Service Type Parameter . . . . . . . . . . 13 69 4.2.2. Service Provider Parameter . . . . . . . . 14 70 4.2.3. Country Code Parameter . . . . . . . . . . 14 71 4.3. Parameters for IEEE 802.11 wireless LANs . . . . . . 14 72 4.3.1. SSID Parameter . . . . . . . . . . . . . . 14 73 4.3.2. BSSID Parameter . . . . . . . . . . . . . 14 74 4.4. Parameters for IEEE 802.16 Networks . . . . . . . . 14 75 4.5. Parameters for IKEv2 . . . . . . . . . . . . . . . . 14 76 4.5.1. Responder Address Parameter . . . . . . . 15 77 4.5.2. IDr Parameter . . . . . . . . . . . . . . 15 78 5. EAP Method Extensions . . . . . . . . . . . . . . . . . . . . 15 79 5.1. EAP-TLS . . . . . . . . . . . . . . . . . . . . . . 15 80 5.2. PEAPv2 . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.3. EAP-AKA . . . . . . . . . . . . . . . . . . . . . . 17 82 5.4. EAP-SIM . . . . . . . . . . . . . . . . . . . . . . 20 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 7.1. Allocations Requested in This Document . . . . . . . 21 86 7.2. Future Allocation Policy . . . . . . . . . . . . . . 22 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 8.1. Normative References . . . . . . . . . . . . . . . . 23 89 8.2. Informative References . . . . . . . . . . . . . . . 23 90 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 92 Intellectual Property and Copyright Statements . . . . . . . . . . 26 94 1. Introduction 96 EAP is typically used in an arrangement where the actual service 97 (such as a wireless LAN access point) is separated from the 98 authentication server. However, EAP itself does not have a concept 99 of a service identity or its parameters, and thus the client usually 100 does not authenticate any information about the service itself, even 101 when a mutually authenticating EAP method is used. 103 However, if a method supports channel bindings as specified in RFC 104 3748 [4] it becomes possible to ensure that the client, the node 105 providing the service, and the authentication server all have the 106 same information about this information. This does not, by itself, 107 ensure that the information is correct, just that everyone has the 108 same information; a service node might be providing a service that 109 this particular node should not be providing. A method that supports 110 authenticated service information ensures in addition that the 111 authentication server knows this information to be correct. 113 This document specifies a backwards compatible extension to popular 114 EAP methods for supporting both channel bindings and authenticated 115 service information. It does so in a media-independent manner, 116 making it possible to run the same EAP mechanisms across different 117 media, and introducing new information elements without affecting 118 interoperability. 120 This extension is intended for the verification of service 121 information. It is not intended as a means for communicating 122 information about parameters that EAP clients would not otherwise be 123 aware of based on their communication with the node providing the 124 service. 126 This rest of the document is organized as follows. In Section 1.1 we 127 discuss the need for authenticated service information in more 128 detail. Section 2 discusses the design considerations and 129 alternatives for solutions in this space. Section 3 gives an 130 overview of how our protocol operates and Section 4 describes the 131 kind of information that can be verified. We have provided only an 132 initial list of parameters for IEEE 802.11 and IKEv2, but additional 133 parameters can be defined through IANA. Section 5 describes the 134 extensions necessary for certain popular EAP methods. Support for 135 other EAP methods can be added in other specifications. 137 1.1. Authenticated Service Information 139 EAP is run for the purposes of providing granting access to a 140 service, such as network access. The nodes providing such services 141 (called authenticators in EAP) typically have an identifier or 142 identifiers, and offer a specific type of a service with an 143 associated set of parameters. Collectively, this identifier, type 144 and parameter information is called service information. 146 In the Extensible Authentication Protocol (EAP) framework, different 147 authentication methods can provide varying security properties. One 148 such property is called "channel bindings", which is described in RFC 149 3748 [4] as follows: 151 "The communication within an EAP method of integrity-protected 152 channel properties such as endpoint identifiers which can be 153 compared to values communicated via out of band mechanisms (such 154 as via a AAA or lower layer protocol)." 156 The document continues by describing the security implications of not 157 being able to verify service information: 159 "It is possible for a compromised or poorly implemented EAP 160 authenticator to communicate incorrect information to the EAP peer 161 and/or server. This may enable an authenticator to impersonate 162 another authenticator or communicate incorrect information via 163 out-of-band mechanisms (such as via a AAA or lower layer 164 protocol). 166 Where EAP is used in pass-through mode, the EAP peer typically 167 does not verify the identity of the pass-through authenticator, it 168 only verifies that the pass-through authenticator is trusted by 169 the EAP server. This creates a potential security vulnerability. 171 Section 4.3.7 of [11] describes how an EAP pass-through 172 authenticator acting as a AAA client can be detected if it 173 attempts to impersonate another authenticator (such by sending 174 incorrect NAS-Identifier [9], NAS-IP-Address [9] or NAS-IPv6- 175 Address [10] attributes via the AAA protocol). However, it is 176 possible for a pass-through authenticator acting as a AAA client 177 to provide correct information to the AAA server while 178 communicating misleading information to the EAP peer via a lower 179 layer protocol. 181 For example, it is possible for a compromised authenticator to 182 utilize another authenticator's Called-Station-Id or NAS- 183 Identifier in communicating with the EAP peer via a lower layer 184 protocol, or for a pass-through authenticator acting as a AAA 185 client to provide an incorrect peer Calling-Station-Id [9] [12] to 186 the AAA server via the AAA protocol. 188 In order to address this vulnerability, EAP methods may support a 189 protected exchange of channel properties such as endpoint 190 identifiers, including (but not limited to): Called-Station-Id [9] 191 [12], Calling-Station-Id [9] [12], NAS-Identifier [9], NAS-IP- 192 Address [9], and NAS-IPv6-Address [10]. 194 Using such a protected exchange, it is possible to match the 195 channel properties provided by the authenticator via out-of-band 196 mechanisms against those exchanged within the EAP method. Where 197 discrepancies are found, these SHOULD be logged; additional 198 actions MAY also be taken, such as denying access." 200 Unfortunately, such verification is currently not possible in popular 201 network scenarios. For instance, in IEEE 802.11 networks a rogue 202 operator can actually advertise the same identity (BSSID or SSID) as 203 the local operator; the parameters advertised by the access point 204 information are not authenticated end-to-end to the home network. 205 There is no support is in the commonly used EAP methods for 206 authentication of service information, and there are no alternative 207 verification means in the IEEE 802 lower layer. For instance, rogue 208 access points can present a different identity to the client and to 209 the home network. Or a rogue IKEv2 gateway can claim to be a 802.11 210 access point to its clients, but still appear as an IKEv2 gateway 211 towards the authentication server. 213 There are cases where the lower layer does provide its own means of 214 authenticating the service information. For instance, in IKE2, EAP 215 is used together with certificate-based authentication of the 216 responder. However, this document may be useful with proposed IKEv2 217 extensions like [15] that remove the need to deploy a PKI. Also, 218 even a lower layer that performs some kind of authentication for its 219 service information may be unable to do so in all cases, such as 220 distinguishing between different services offered by the nodes 221 belonging to a group of nodes certified in the same manner. 223 This situation is further complicated by the fact that services do 224 not necessarily have just a single identifier, but several different 225 identifiers of different types. For instance, an IEEE 802.11 access 226 point could be identified by a BSSID, an IPv4 address (e.g., NAS-IP- 227 Address), or a domain name (e.g., NAS-Identifier). Other 228 identifiers, such as SSID, do not necessarily identify a single 229 access point, but may be more interesting to the client (if you 230 consider the "service" to be wireless LAN network access in some 231 hotspot, rather than a single physical box). 233 Ongoing development in the network access technology is opening up 234 vulnerabilities that go beyond simple identifiers. For instance, 235 protocol mechanisms are being developed to indicate the "cost" of 236 access, such as whether the access is free or for a charge. Without 237 a secure way to agree about the cost among the parties, fraudulent 238 local networks can get customers via an attractive offer and 239 subsequently charge them for usage with less attractive conditions. 240 Prevention of such attacks is of high interest, as without technical 241 measures they are expected to occur due to the economic incentives. 243 It is important to make a distinction between channel bindings and 244 authenticating information related to the the pass-through 245 authenticator. Channel bindings only ensure that the same 246 information is available to the EAP peer and the AAA server. This 247 alone does not prevent an authenticator from impersonating another 248 authenticator if the AAA server blindly accepts any information 249 received from the authenticator. To provide authentication, the AAA 250 server has to verify that the information actually corresponds to the 251 entity the AAA-Key is sent to. 253 2. Design Considerations 255 The following considerations deserve some discussion: 257 o Retaining media independence in EAP 259 o Choosing the party (or parties) to perform the verification 261 o Communication within EAP vs. within AAA protocols 263 These are discussed in following subsections. 265 2.1. Media Independence 267 An EAP-based channel binding solution can fail to retain EAP's 268 independence from media in three ways. First, an EAP method might 269 support channel bindings only for some media, or make the addition of 270 parameters for new media types hard. This would make it harder for 271 users to switch to new media. 273 Second, if channel bindings are provided only by some EAP methods, 274 the choice of authentication methods and credentials would be limited 275 in an environment that requires channel binding support [13]. 277 Third, the EAP layer or EAP methods might have to interpret or 278 understand the channel binding parameter information in some manner. 279 This would result in a need to update EAP peer and server 280 implementations when new media or new parameters on an existing media 281 are developed. 283 This draft avoids these problems by (1) defining the channel binding 284 support simultaneously to the most popular EAP methods, (2) providing 285 a common parameter name space across these methods in order to ensure 286 that the same kind of information can be authenticated independent of 287 the choice of the EAP method, and (3) treating the channel binding 288 information as opaque data at the EAP layer and within EAP methods. 290 Note that while the parameters are represented as opaque data at the 291 EAP layer, it is still necessary to specify the parameters in a 292 publicly avaible, stable specification for interoperability. This is 293 why this document defines both the EAP transport and the actual 294 parameters. 296 Figures 1 and 2 illustrate how information is expected to be conveyed 297 to upper layers where authorization decisions can be made. 299 Peer Pass-through Authenticator Authentication 300 (optional) Server 302 +-----------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 303 | | | | | | 304 | Control | | Control | | Control | 305 |application| | application | |application| 306 | | | | | | 307 +-------+ + +----------+ +----------+ + +-------+ 308 | | | | | | | | | | 309 | EAP | | | EAP | | EAP | | | EAP | 310 | layer | | | layer | | layer | | | layer | 311 | | | | | | | | | | 312 +-------+---+ +----------+--+--+----------+ +---+-------+ 313 | | | | | | | 314 |Lower layer| | Lower layer| AAA/IP | | AAA/IP | 315 | | | | | | | 316 +-----+-----+ +-------+-----+-----+-------+ +-----+-----+ 317 ! ! ! ! 318 ! ! ! ! 319 +-------->--------+ +--------->-------+ 321 Figure 1: Architecture 323 +----------------------------------------------------+ 324 | | 325 | Control application | 326 | | 327 | | 328 | | 329 | Lower /|\ /|\ Opaque channel | 330 | layer | | binding data | 331 | information| | to/from EAP | 332 | | | layer | 333 | \|/ \|/ | 334 +-------------------------+--------------------------+ 335 | | | 336 | | | 337 | | | 338 | Lower layer <----+----> EAP layer | 339 | | | 340 | | | 341 | | | 342 | | | 343 | | | 344 | | | 345 +-------------------------+--------------------------+ 347 Figure 2: Flow of information to and from EAP 349 2.2. Verifying Party 351 The main idea of channel bindings is to be able to verify information 352 from two sources, such as comparing what the EAP authenticator has 353 told the peer and the server. Different designs could implement this 354 check at different nodes: at the peer, the server, or both. 356 Assuming a secure exchange of opaque data through EAP, both the peer 357 and the server can have the same information available to them, 358 including what the authenticator has communicated over AAA to the 359 server and what it has told the peer over the lower layer. (Note 360 that there are vulnerabilities in both AAA and lower layer protocols; 361 what matters, however, is that both ends see the same information. 362 Assuming the EAP method is secure, this can be arranged.) 364 However, the server may be in a better position to have an 365 understanding of what roaming contracts exist, what authenticators 366 are expected to exist and what services they should be offering. 367 Similarly, fraud detection and policy rules are easier to arrange at 368 a central site than in clients. Finally, server-side verification is 369 the model already adopted in PEAPv2 [7], it makes the introduction of 370 a general channel binding model easier for this method. 372 As a result, it seems reasonable to assume a model where the server 373 is in charge of the verification process. 375 2.3. Communication within EAP vs. within AAA 377 As discussed in [16], the communication of the verified parameters 378 can occur in two ways: 380 Within EAP 382 Here the set of verified parameters is communicated end-to-end 383 within EAP as an opaque string. 385 Within AAA and Lower Layer 387 Here the set of verified parameters is communicated from the 388 authenticator (a) to the peer via the lower layer protocol and (b) 389 to the server via the AAA protocol. In order to prevent 390 fraudulent claims about the parameters, the AAA protocol 391 calculates AAA-Key based on the parameters, and communicates only 392 this key (not the current MSK) to the authenticator. As a result, 393 the peer and the authenticator can not complete their network 394 attachment process if there's a mismatch in the set of parameters. 396 The overall result of both approaches is the same, but there are 397 subtle security differences: One difference is that in the EAP 398 approach we need to trust the endpoints to actually perform the 399 check, whereas the key-based check is implicit and "non-skippable" in 400 the latter approach; if the parameters mismatch the keys simply do 401 not work. 403 Another difference is in the timing of the check; in conventional AAA 404 protocols the user is considered authenticated when the RADIUS 405 Access-Accept or equivalent message is sent. This ensures that the 406 AAA server is aware of the result of the access request. But in the 407 AAA-based approach a mismatch in the parameters is learned after 408 this, and may be hard to report in a secure way. For instance, the 409 authenticator could claim that a session was started, even if in 410 reality the secure association protocol failed due to a mismatch. 412 There is also a difference in terms of deployment implications. The 413 EAP-based approach means that EAP implementations and methods have be 414 updated. Existing credentials can continue to be used, however, and 415 it is expected that the opaque data approach makes it possible to add 416 new media and new parameters without additional code changes in EAP. 418 There are no EAP updates in the AAA-based approach, but it is still 419 necessary to add support for the new parameter communication means 420 and AAA-Key calculation to peers, authenticators, and servers. The 421 main difference to the EAP-based approach is that authenticators need 422 to be changed. 424 Because of the above considerations, this draft employs the EAP-based 425 approach. 427 3. Protocol Overview 429 The basic idea in this extension is that the EAP peer sends the EAP 430 server a statement that it going to accept service from an access 431 device associated with particular set of identifiers and other 432 information. 434 In order to protect this statement, an EAP method needs to be able to 435 pass data from the EAP peer to the EAP server, and be able to protect 436 this exchange using keys known only them and not the access device. 437 The Transient EAP Keys (TEKs) can be used for this purpose, as these 438 keys are only known to the EAP endpoints and not communicated to the 439 access device. 441 After receiving this information, the EAP server can compare the 442 information provided from the EAP peer to the information it has 443 received directly from the access device. If the information does 444 not match, the access device has provided different information to 445 the peer and to the AAA protocol. This is disallowed, and the 446 authentication SHOULD be terminated and the discrepancy MUST be 447 logged. 449 In order to provide a generic solution where any EAP method can be 450 used on a given lower layer, the same format is used for the 451 exchanged information. This format consists of Tag-Length-Value 452 triplets with IANA managed tag space. 454 The parameter information is sent along the other messages in an EAP 455 method. The exact message sequences depend on the used EAP method, 456 but Figure 1 shows a typical sequence. 458 Peer Authenticator Server 459 | | | 460 | 802.11 attachment | | 461 |<------------------------>| | 462 | | | 463 +----------------------+ | | 464 | Information received | | | 465 | at this point is | | | 466 | not authenticated | | | 467 +----------------------+ | | 468 | | | 469 | EAP Identity Request | | 470 |<-------------------------| | 471 | | | 472 | EAP Identity Response | | 473 |------------------------->| | 474 | | RADIUS Access-Request | 475 | |------------------------->| 476 | | | 477 | | +----------------------+ 478 | | | Server authenticates | 479 | | | the RADIUS request | 480 | | +----------------------+ 481 | | | 482 | | RADIUS Access-Challenge | 483 | EAP TLS Start |<-------------------------| 484 |<-------------------------| | 485 | | | 486 +-----------------------+ | | 487 | Peer sends the | | | 488 | authenticator's info | | | 489 | to the server in EAP | | | 490 +-----------------------+ | | 491 | | | 492 | EAP TLS C-Hello + id. | | 493 |------------------------->| | 494 | | RADIUS Access-Request | 495 | |------------------------->| 496 | | | 497 | | +-------------------------+ 498 | | | Server can now verify | 499 | | | that the information | 500 | | | is what was expected | 501 | | +-------------------------+ 502 | | | 503 | | RADIUS Access-Challenge | 504 | EAP TLS S-Hello . |<-------------------------| 505 |<-------------------------| | 506 | | | 507 +-------------------------+ | | 508 | Peer learns here that | | | 509 | the information was | | | 510 | verified (EAP continues)| | | 511 +-------------------------+ | | 512 | | | 513 | | | 514 | EAP TLS Finished | | 515 |------------------------->| RADIUS Access-Request | 516 | |------------------------->| 517 | | | 518 | | RADIUS Access-Challenge | 519 | EAP TLS Finished |<-------------------------| 520 |<-------------------------| | 521 | | | 522 | | | 523 | EAP TLS | | 524 |------------------------->| RADIUS Access-Request | 525 | |------------------------->| 526 | | | 527 | | RADIUS Access-Accept + | 528 | | AAA-Key | 529 | EAP Success |<-------------------------| 530 |<-------------------------| | 531 | | | 532 +-----------------------------+ 533 | Authentication is completed | 534 | when the authenticator | 535 | proves it knows the AAA-Key | 536 +-----------------------------+ 538 Zero or more parameters are sent from the peer to the server. Each 539 parameter is of the format explained in the next section. 541 4. Parameters 543 4.1. Format 545 Nodes supporting this extension pass parameters in the following 546 format: 548 0 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Res | Parameter Identifier | Length | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 . . 555 . Value . 556 . . 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 The meaning of the fields is described as follows: 562 Res 564 A 4-bit field reserved for future use. The value MUST be 565 initialized to zero by the sender, and MUST be ignored by the 566 receiver. 568 Parameter Identifier 570 A 16-bit field that specifies what parameter is being 571 communicated. 573 Length 575 A 12-bit field that indicates the length of the Value field, in 576 bytes. 578 Value 580 The actual parameter value. The interpretation of this value 581 depends on the Parameter Identifier field. Integers are 582 represented as four bytes in all cases, whereas addresses and 583 strings are represented in as many octets as they are long. 585 The EAP or the EAP method layer SHOULD NOT attempt to interpret the 586 information beyond this format. In other words, the Parameter 587 Identifier and Value fields are interpreted as opaque data in order 588 to ensure EAP media independence. EAP implementations SHOULD pass 589 the information to higher layers that are in charge of authorization 590 decisions, such as AAA server authorization logic. 592 The encapsulation of this sequence of parameters is EAP method 593 dependent. 595 4.2. General Parameters 597 These parameters are for any type of nodes and lower layers. The 598 Service Type parameter MUST be supported by all nodes conforming to 599 this specification, and MUST be the first parameter in all messages 600 containing a sequence of parameters defined here. 602 4.2.1. Service Type Parameter 604 The Parameter Identifier for this parameter is 0, and the Value is a 605 32-bit integer, represented in network byte order. The following 606 values have been currently defined: 608 0 IEEE 802.11 610 1 IEEE 802.16 612 2 IKEv2 614 The receiver SHOULD fail the authentication if the Value field is 615 either not recognized by it or is not the same one for which it 616 thinks access is being provided. 618 4.2.2. Service Provider Parameter 620 The Parameter Identifier for this parameter is 1, and the Value is an 621 UTF-8 encoded string describing the human readable name of the 622 service provider. As EAP is used primarily for network access, this 623 is typically the name of the access network provider. 625 4.2.3. Country Code Parameter 627 The Parameter Identifier for this parameter is 2, and the Value is an 628 ASCII string of at most 3 characters, conforming to the ISO 3166 [8] 629 country code. 631 4.3. Parameters for IEEE 802.11 wireless LANs 633 All the following parameters MUST be supported when IEEE 802.11 is 634 accepted as a Service Type. 636 4.3.1. SSID Parameter 638 The Parameter Identifier for this parameter is 3, and the Value is an 639 octet string containing the Service Set Identifier (SSID). 641 4.3.2. BSSID Parameter 643 The Parameter Identifier for this parameter is 4, and the Value is a 644 6-octet string containing the BSSID. 646 4.4. Parameters for IEEE 802.16 Networks 648 No parameters have yet been defined for the IEEE 802.16 networks. 650 4.5. Parameters for IKEv2 652 All the following parameters MUST be supported when IKEv2 is accepted 653 as the Service Type. 655 4.5.1. Responder Address Parameter 657 The Parameter Identifier for this parameter is 14, and the Value is 658 the IP address of the node who acted as the responder for this IKEv2 659 EAP exchange. The Value is either 4 or 16 bytes depending on whether 660 IPv4 or IPv6 is used. 662 4.5.2. IDr Parameter 664 The Parameter Identifier for this parameter is 16, and the Value is 665 an octet string containing the IKEv2 responder identity payload 666 (IDr). 668 5. EAP Method Extensions 670 This section describes an initial set of extensions to some current 671 EAP methods so that they can be transport the parameter information. 673 The extensions are optional and backwards compatible, so that, where 674 allowed by policy, EAP peers without these extensions can still 675 contact EAP servers with these extensions and vice versa. The 676 default policy SHOULD be that such usage is allowed. 678 5.1. EAP-TLS 680 A TLS extension [3] is added to the EAP TLS [2] client_hello/ 681 server_hello messages. The extension type of the extension is EAP 682 Service Information and it has the number < To Be Assigned By IANA >. 683 The extension contains a sequence of parameters, followed by each 684 other. 686 The extension sent in the server_hello message SHOULD contain zero 687 parameters, and is only used to confirm that the server supports this 688 specification. As discussed in RFC 3546, when these extensions 689 appear in a client hello message, they are ignored by old server 690 implementations. The lack of this extension in the authenticator's 691 server hello response SHOULD be taken as an indication that the 692 authenticator does not support the mechanisms defined in this 693 document. The authenticator MUST NOT use this extension unless the 694 client provided the same extension in its own hello message, as per 695 RFC 3546 the client is required to terminate the TLS session 696 otherwise. 698 The client_hello/server_hello messages are included in MACs in the 699 TLS Finished messages, which ensures that modifications will be 700 detected. 702 The following sequence illustrates the operation of the EAP TLS 703 protocol with this extension: 705 Peer Authenticator 706 | | 707 | PPP EAP-Request/ | 708 | EAP-Type=EAP-TLS | 709 | (TLS Start) | 710 |<---------------------------------------------------------| 711 | | 712 | PPP EAP-Response/ | 713 | EAP-Type=EAP-TLS | 714 | (TLS client_hello + extension) | 715 |--------------------------------------------------------->| 716 | | 717 | PPP EAP-Request/ | 718 | EAP-Type=EAP-TLS | 719 | (TLS server_hello + extension, | 720 | TLS certificate, | 721 | [TLS server_key_exchange,] | 722 | [TLS certificate_request,] | 723 | TLS server_hello_done) | 724 |<---------------------------------------------------------| 725 | | 726 | PPP EAP-Response/ | 727 | EAP-Type=EAP-TLS | 728 | (TLS certificate, | 729 | TLS client_key_exchange, | 730 | [TLS certificate_verify,] | 731 | TLS change_cipher_spec, | 732 | TLS finished) | 733 |--------------------------------------------------------->| 734 | | 735 | PPP EAP-Request/ | 736 | EAP-Type=EAP-TLS | 737 | (TLS change_cipher_spec, | 738 | TLS finished) | 739 |<---------------------------------------------------------| 740 | | 741 | PPP EAP-Response/ | 742 | EAP-Type=EAP-TLS | 743 |--------------------------------------------------------->| 744 | | 745 | PPP EAP-Success | 746 |<---------------------------------------------------------| 747 | | 749 This works the same way when resuming session. Note that the 750 parameters can change from the initial authentication. 752 5.2. PEAPv2 754 In PEAPv2 [7], the Connection-Binding TLV is used to carry parameter 755 objects. One Connection-Binding TLV for this purpose is exchanged in 756 each direction, containing all the parameters that need to be 757 exchanged. The Connection-Binding TLV carries a set of PEAPv2 TLVs. 758 The transport of parameters for the purposes of this document takes 759 place through the PEAPv2 Service Information Parameter TLV defined in 760 the following: 762 0 1 2 3 763 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |M|R| TLV Type | Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Parameter... | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 The fields of this TLV are as follows: 772 M 774 0 - Optional TLV. 776 R 778 Reserved, set to zero (0). 780 TLV Type 782 < To Be Assigned By IANA > 784 Length 786 Length of the TLV. 788 Parameter... 790 The parameter in the format described in Section 4.1. 792 5.3. EAP-AKA 794 For EAP-AKA, a new attribute AT_SERVICEID is added to the EAP- 795 Request/AKA/Challenge message. 797 The format of the AT_SERVICEID attribute is shown below: 799 0 1 2 3 800 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | AT_SERVICEID | Length | Actual data length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 . Parameters... . 806 . . 807 | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 The fields of this attribute are as follows: 812 AT_SERVICEID 814 < To Be Assigned By IANA > 816 Length 818 Length of the attribute. 820 Actual data length 822 This field specifies the length of the following field in 823 bytes, because the length of the parameter must be a multiple 824 of 4 bytes, the sender pads the data with zero bytes when 825 necessary. 827 Parameters... 829 The parameters in the format described in Section 4.1. 831 The following sequence illustrates the operation of the EAP-AKA 832 protocol with this extension: 834 Peer Authenticator 835 | EAP-Request/Identity | 836 |<------------------------------------------------------| 837 | | 838 | EAP-Response/Identity | 839 | (Includes user's NAI) | 840 |------------------------------------------------------>| 841 | | 842 | +------------------------------+ 843 | | Server runs UMTS algorithms, | 844 | | generates RAND and AUTN. | 845 | +------------------------------+ 846 | | 847 | EAP-Request/AKA-Challenge | 848 | (AT_RAND, AT_AUTN, AT_MAC, AT_SERVICEID) | 849 |<------------------------------------------------------| 850 | | 851 +-------------------------------------+ | 852 | Peer runs UMTS algorithms on USIM, | | 853 | verifies AUTN and MAC, derives RES | | 854 | and session key | | 855 +-------------------------------------+ | 856 | | 857 | EAP-Response/AKA-Challenge | 858 | (AT_RES, AT_MAC, AT_SERVICEID) | 859 |------------------------------------------------------>| 860 | | 861 | +--------------------------------+ 862 | | Server checks the given RES, | 863 | | and MAC and finds them correct.| 864 | +--------------------------------+ 865 | | 866 | EAP-Success | 867 |<------------------------------------------------------| 869 The AT_SERVICEID attribute from the server to the peer is empty, and 870 is only used for capability detection. A peer MUST NOT send a 871 AT_SERVICEID attribute if no such attribute was seen from the server 872 previously. In this case, the peer MAY disconnect if its policy 873 requires the channel binding support. 875 Note that the AT_SERVICEID attribute is used also in the EAP-Request/ 876 AKA/AKA-Reauthentication message, and that the set of parameters 877 exchanged in this case may differ from those agreed upon earlier in 878 the initial authentication. 880 The use of the AT_SERVICEID attribute is backward compatible, because 881 existing implementations ignore unknown parameters. 883 5.4. EAP-SIM 885 For EAP-SIM, a new attribute AT_SERVICEID is added to the EAP- 886 Request/SIM/Challenge message. The format of the AT_SERVICEID 887 attribute is as shown for EAP-AKA. 889 The following sequence illustrates the operation of the EAP-SIM 890 protocol with this extension: 892 Peer Authenticator 893 | | 894 | EAP-Request/Identity | 895 |<---------------------------------------------------------| 896 | | 897 | EAP-Response/Identity | 898 |--------------------------------------------------------->| 899 | | 900 | EAP-Request/SIM/Start | 901 | (AT_VERSION_LIST) | 902 |<---------------------------------------------------------| 903 | | 904 | EAP-Response/SIM/Start | 905 | (AT_NONCE_MT, AT_SELECTED_VERSION) | 906 |--------------------------------------------------------->| 907 | | 908 | EAP-Request/SIM/Challenge | 909 | (AT_RAND, AT_MAC, AT_SERVICEID) | 910 |<---------------------------------------------------------| 911 | | 912 +-------------------------------------+ | 913 | Peer runs GSM algorithms, | | 914 | verifies AT_MAC and derives | | 915 | session keys | | 916 +-------------------------------------+ | 917 | | 918 | EAP-Response/SIM/Challenge | 919 | (AT_MAC, AT_SERVICEID) | 920 |--------------------------------------------------------->| 921 | | 922 | | 923 | EAP-Success | 924 |<---------------------------------------------------------| 925 | | 927 As with EAP-AKA, the AT_SERVICEID attribute must be passed also in 928 the EAP-Request/SIM/SIM-Reauthentication message. Similarly, the 929 AT_SERVICEID attribute from the server to the client is empty and 930 only used for capability detection. 932 6. Security Considerations 934 The implications of being unable to verify service information have 935 been described in Section 7.15 of RFC 3748 [4]. These include 936 vulnerabilities related to compromised access points or fraudulent 937 service providers. When properly used, the mechanism provided in 938 this document removes these vulnerabilities. The mechanism is 939 generic and not tied to any specific EAP method or use of EAP over a 940 specific link layer, and as such can be expected to be more easily 941 deployed as alternative suggestions such as those described in PEAPv2 942 [7] or EAP FAST [14]. 944 Authenticating the service information may complicate operation in 945 some deployment scenarios, since it requires that the AAA server is 946 able to authenticate the expected kinds of information. For 947 instance, RADIUS is often deployed in situations where the only 948 authenticated information related to the RADIUS client is the IP 949 address; other information may be present in the Access-Request 950 message (such as BSSID/SSID in the Called-Station-Id attribute), but 951 this is simply claimed information not authenticated information. 952 Where such information is not available, some vulnerabilities still 953 remain. 955 In the deployment phase, it is possible that clients and servers do 956 not get support for the mechanism described in this document at the 957 same time. It is a policy decision to accept an EAP exchange from a 958 party that does not support this mechanism. This decision is 959 protected from a bidding down attack by a man-in-the-middle, because 960 EAP methods have integrity protection for the exchanged messages. 961 Therefore, the removal or modification of the parameter block would 962 be detected. 964 7. IANA Considerations 966 7.1. Allocations Requested in This Document 968 This document requests an IANA allocation of TLS Extension type [3] 969 for EAP Service Identity (see Section 5.1). 971 This document requests an IANA allocation of a PEAPv2 [7] TLV type 972 number for the Service Identity Parameter TLV (see Section 5.2). 974 This document requests an IANA allocation for the attribute type 975 number AT_SERVICEID in the [6] and [5] protocols (see Section 5.3 and 976 Section 5.4). The same value should be allocated for both protocols. 978 7.2. Future Allocation Policy 980 New Parameter Identifier values can be defined through Specification 981 Required [1]. The following values have been currently allocated: 983 0 Service Type 985 1 Service Provider 987 2 Country Code 989 3 802.11/SSID 991 4 802.11/BSSID 993 6 IKEv2/Responder Address 995 7 IKEv2/IDr 997 Values 65000 through 65530 and for Experimental Use and can be used 998 without allocation. Values 65531 through 65535 are Reserved. 1000 New Service Type values can be defined through IETF Consensus [1]. 1001 The following values have been currently allocated: 1003 0 IEEE 802.11 1005 1 IEEE 802.16 1007 2 IKEv2 1009 Values 429496700 through 4294967289 are for Experimental Use and can 1010 be used without allocation. Values 4294967290 through 4294967295 are 1011 Reserved. 1013 Values in other enumerated parameters can be defined through First 1014 Come, First Served[1]. However, this extension is intended only for 1015 the verification of service information. Its use for communicating 1016 other information not already known by the EAP client (such as for 1017 service discovery) is discouraged. In all enumarated parameters, 1018 values 429496700 through 4294967289 are for Experimental Use and can 1019 be used without allocation. Values 4294967290 through 4294967295 are 1020 Reserved. 1022 8. References 1023 8.1. Normative References 1025 [1] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1026 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1028 [2] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 1029 RFC 2716, October 1999. 1031 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1032 T. Wright, "Transport Layer Security (TLS) Extensions", 1033 RFC 3546, June 2003. 1035 [4] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1036 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 1037 June 2004. 1039 [5] Haverinen, H. and J. Salowey, "EAP SIM Authentication", 1040 draft-haverinen-pppext-eap-sim-16 (work in progress), 1041 December 2004. 1043 [6] Arkko, J. and H. Haverinen, "EAP AKA Authentication", 1044 draft-arkko-pppext-eap-aka-15 (work in progress), December 2004. 1046 [7] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected 1047 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-10 1048 (work in progress), October 2004. 1050 [8] International Organization for Standardization, "Codes for the 1051 representation of names of countries, 3rd edition", ISO Standard 1052 3166, August 1988. 1054 8.2. Informative References 1056 [9] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1057 Authentication Dial In User Service (RADIUS)", RFC 2865, 1058 June 2000. 1060 [10] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 1061 RFC 3162, August 2001. 1063 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1064 In User Service) Support For Extensible Authentication Protocol 1065 (EAP)", RFC 3579, September 2003. 1067 [12] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 1068 "IEEE 802.1X Remote Authentication Dial In User Service 1069 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1071 [13] Stanley, D., Walker, J., and B. Aboba, "Extensible 1072 Authentication Protocol (EAP) Method Requirements for Wireless 1073 LANs", RFC 4017, March 2005. 1075 [14] Cam-Winget, N., McGrew, D., and J. Salowey, "EAP Flexible 1076 Authentication via Secure Tunneling (EAP-FAST)", 1077 draft-cam-winget-eap-fast-01 (work in progress), October 2004. 1079 [15] Eronen, P. and H. Tschofenig, "Extension for EAP Authentication 1080 in IKEv2", draft-eronen-ipsec-ikev2-eap-auth-03 (work in 1081 progress), April 2005. 1083 [16] Yanagiya, M. and Y. Ohba, "AAA-Key Derivation with Lower-Layer 1084 Parameter Binding", draft-ohba-eap-aaakey-binding-01 (work in 1085 progress), July 2005. 1087 Appendix A. Acknowledgments 1089 The authors would like to thank Bernard Aboba, Yoshihiro Ohba, Mohan 1090 Parthasarathy, Hannes Tschofenig, Joe Salowey, Glen Zorn, and David 1091 Mariblanca for interesting discussions in this problem space. 1093 Authors' Addresses 1095 Jari Arkko 1096 Ericsson 1097 FI-02420 Jorvas 1098 Finland 1100 Email: jari.arkko@ericsson.com 1102 Pasi Eronen 1103 Nokia Research Center 1104 P.O. Box 407 1105 FI-00045 Nokia Group 1106 Finland 1108 Email: pasi.eronen@nokia.com 1110 Intellectual Property Statement 1112 The IETF takes no position regarding the validity or scope of any 1113 Intellectual Property Rights or other rights that might be claimed to 1114 pertain to the implementation or use of the technology described in 1115 this document or the extent to which any license under such rights 1116 might or might not be available; nor does it represent that it has 1117 made any independent effort to identify any such rights. Information 1118 on the procedures with respect to rights in RFC documents can be 1119 found in BCP 78 and BCP 79. 1121 Copies of IPR disclosures made to the IETF Secretariat and any 1122 assurances of licenses to be made available, or the result of an 1123 attempt made to obtain a general license or permission for the use of 1124 such proprietary rights by implementers or users of this 1125 specification can be obtained from the IETF on-line IPR repository at 1126 http://www.ietf.org/ipr. 1128 The IETF invites any interested party to bring to its attention any 1129 copyrights, patents or patent applications, or other proprietary 1130 rights that may cover technology that may be required to implement 1131 this standard. Please address the information to the IETF at 1132 ietf-ipr@ietf.org. 1134 Disclaimer of Validity 1136 This document and the information contained herein are provided on an 1137 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1138 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1139 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1140 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1141 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1142 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1144 Copyright Statement 1146 Copyright (C) The Internet Society (2005). This document is subject 1147 to the rights, licenses and restrictions contained in BCP 78, and 1148 except as set forth therein, the authors retain all their rights. 1150 Acknowledgment 1152 Funding for the RFC Editor function is currently provided by the 1153 Internet Society.