idnits 2.17.00 (12 Aug 2021) /tmp/idnits13172/draft-arkko-eap-service-identity-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 966. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 987), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 155: '...are found, these SHOULD be logged; add...' RFC 2119 keyword, line 156: '... actions MAY also be taken, such ...' RFC 2119 keyword, line 196: '...owed, and the authentication SHOULD be...' RFC 2119 keyword, line 224: '... authenticator, authentication MUST be...' RFC 2119 keyword, line 337: '...ved for future use. The value MUST be...' (12 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 (April 2, 2004) is 6623 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) == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: draft-haverinen-pppext-eap-sim has been published as RFC 4186 ** Downref: Normative reference to an Informational draft: draft-haverinen-pppext-eap-sim (ref. '5') == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 ** Downref: Normative reference to an Informational draft: draft-arkko-pppext-eap-aka (ref. '6') == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: draft-cam-winget-eap-fast has been published as RFC 4851 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Extensible Authentication Protocol J. Arkko 2 Working Group Ericsson 3 Internet-Draft P. Eronen 4 Expires: October 1, 2004 Nokia Research Center 5 April 2, 2004 7 Authenticated Service Identities for the Extensible Authentication 8 Protocol (EAP) 9 draft-arkko-eap-service-identity-auth-00 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3667. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 1, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 A common arrangement in network access is the separation of the 42 actual network access device (such as a wireless LAN access point) 43 from the authentication servers. In the Extensible Authentication 44 Protocol (EAP) framework, different authentication methods can 45 provide varying security properties. If the EAP methods support 46 authentication of service identities, it becomes possible for the 47 clients to verify not only that the access device is trusted, but 48 also that the parameters advertised by the access device are correct. 50 This document specifies a backward compatible extension to popular 51 EAP methods for supporting such service identity authentication. A 52 common parameter name space is created in order to ensure that the 53 same parameters can be communicated independent of the choice of the 54 authentication method. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 60 3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2 General Parameters . . . . . . . . . . . . . . . . . . 8 63 3.2.1 Service Type Parameter . . . . . . . . . . . . . 8 64 3.2.2 Service Provider Parameter . . . . . . . . . . . 9 65 3.2.3 Country Code Parameter . . . . . . . . . . . . . 9 66 3.3 Parameters for IEEE 802.11 wireless LANs . . . . . . . 9 67 3.3.1 SSID Parameter . . . . . . . . . . . . . . . . . 9 68 3.3.2 BSSID Parameter . . . . . . . . . . . . . . . . 9 69 3.3.3 STA_MAC Parameter . . . . . . . . . . . . . . . 9 70 3.3.4 Protection Mechanism Parameter . . . . . . . . . 9 71 3.4 Parameters for PPP . . . . . . . . . . . . . . . . . . 10 72 3.4.1 Encapsulation Parameter . . . . . . . . . . . . 10 73 3.4.2 Called-Station-Id Parameter . . . . . . . . . . 10 74 3.4.3 Protection Mechanism Parameter . . . . . . . . . 10 75 3.5 Parameters for PANA . . . . . . . . . . . . . . . . . 10 76 3.5.1 PaC Device-Id Parameter . . . . . . . . . . . . 10 77 3.5.2 PAA Device-Id Parameter . . . . . . . . . . . . 11 78 3.5.3 Protection Mechanism Parameter . . . . . . . . . 11 79 3.6 Parameters for IKEv2 . . . . . . . . . . . . . . . . . 11 80 3.6.1 Initiator Address Parameter . . . . . . . . . . 11 81 3.6.2 Responder Address Parameter . . . . . . . . . . 11 82 3.6.3 IDi Parameter . . . . . . . . . . . . . . . . . 11 83 3.6.4 IDr Parameter . . . . . . . . . . . . . . . . . 11 84 4. EAP Method Extensions . . . . . . . . . . . . . . . . . . . 12 85 4.1 EAP-TLS . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.2 PEAPv2 . . . . . . . . . . . . . . . . . . . . . . . . 13 87 4.3 EAP-AKA . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4 EAP-SIM . . . . . . . . . . . . . . . . . . . . . . . 16 89 5. Security Considerations . . . . . . . . . . . . . . . . . . 17 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 91 6.1 Allocations Requested in This Document . . . . . . . . 18 92 6.2 Future Allocation Policy . . . . . . . . . . . . . . . 18 93 Normative References . . . . . . . . . . . . . . . . . . . . 19 94 Informative References . . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 96 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 97 Intellectual Property and Copyright Statements . . . . . . . 22 99 1. Introduction 101 In the Extensible Authentication Protocol (EAP) framework, different 102 authentication methods can provide varying security properties. If 103 the EAP methods support authentication of service identities, it 104 becomes possible for the clients to verify not only that the access 105 device is trusted, but also that the parameters advertised by the 106 access device are correct. [4] uses the term channel bindings for 107 this property, and defines it as follows: 109 The communication within an EAP method of integrity-protected 110 channel properties such as endpoint identifiers which can be 111 compared to values communicated via out of band mechanisms (such 112 as via a AAA or lower layer protocol). 114 The document continues by describing the security implications of not 115 being able to verify service identities: 117 It is possible for a compromised or poorly implemented EAP 118 authenticator to communicate incorrect information to the EAP peer 119 and/or server. This may enable an authenticator to impersonate 120 another authenticator or communicate incorrect information via 121 out-of-band mechanisms (such as via a AAA or lower layer 122 protocol). 124 Where EAP is used in pass-through mode, the EAP peer typically 125 does not verify the identity of the pass-through authenticator, it 126 only verifies that the pass-through authenticator is trusted by 127 the EAP server. This creates a potential security vulnerability. 129 Section 4.3.7 of [11] describes how an EAP pass-through 130 authenticator acting as a AAA client can be detected if it 131 attempts to impersonate another authenticator (such by sending 132 incorrect NAS-Identifier [9], NAS-IP-Address [9] or 133 NAS-IPv6-Address [10] attributes via the AAA protocol). However, 134 it is possible for a pass-through authenticator acting as a AAA 135 client to provide correct information to the AAA server while 136 communicating misleading information to the EAP peer via a lower 137 layer protocol. 139 For example, it is possible for a compromised authenticator to 140 utilize another authenticator's Called-Station-Id or 141 NAS-Identifier in communicating with the EAP peer via a lower 142 layer protocol, or for a pass-through authenticator acting as a 143 AAA client to provide an incorrect peer Calling-Station-Id [9, 12] 144 to the AAA server via the AAA protocol. 146 In order to address this vulnerability, EAP methods may support a 147 protected exchange of channel properties such as endpoint 148 identifiers, including (but not limited to): Called-Station-Id 149 [9, 12], Calling-Station-Id [9, 12], NAS-Identifier [9], 150 NAS-IP-Address [9], and NAS-IPv6-Address [10]. 152 Using such a protected exchange, it is possible to match the 153 channel properties provided by the authenticator via out-of-band 154 mechanisms against those exchanged within the EAP method. Where 155 discrepancies are found, these SHOULD be logged; additional 156 actions MAY also be taken, such as denying access. 158 Unfortunately, such verification is currently not possible in popular 159 network scenarios. For instance, in IEEE 802.11 networks a rogue 160 operator can actually advertise the same identity (SSID) as the local 161 operator; the parameters advertised by the access point information 162 are not authenticated end-to-end to the home network. There is no 163 support is in the commonly used EAP methods for authentication of 164 service identities, and there are no alternative verification means 165 in the lower layer. Hence, rogue access points can present a 166 different set of parameters to the client and to the home network. 168 This document specifies a backwards compatible extension to popular 169 EAP methods for supporting authentication service identities. A 170 common parameter name space is created in order to ensure that the 171 same parameters can be communicated independent of the choice of the 172 authentication method. 174 This document is organized as follows. Section 2 gives an overview of 175 the protocol operation. Section 3 describes the parameters that can 176 be verified. We have provided only an initial list of parameters for 177 the most popular lower layers, but additional parameters can be 178 defined through IANA. Section 4 describes the extensions necessary 179 for certain popular EAP methods. Support for other EAP methods can be 180 added in other specifications. 182 2. Protocol Overview 184 In order to provide authentication of service identities, an EAP 185 method needs to be able to pass data between the EAP peer and server, 186 and be able to protect this exchange using keys known only them and 187 not the access device. The Transient EAP Keys (TEKs) can be used for 188 this purpose, as these keys are only known to the EAP endpoints and 189 not communicated to the access device. 191 The data exchange needs to be bidirectional. After exchanging the 192 information, the EAP peer can compare the information provided from 193 the EAP server to the information it has received directly from the 194 access device. If the information does not match, the access device 195 has provided different information to the peer and to the AAA 196 protocol. This is disallowed, and the authentication SHOULD be 197 terminated in this case. Similarly, the EAP server can compare the 198 information the peer has provided to the information given from the 199 access device via AAA. 201 Simply comparing the information from the two sources ensures only 202 that the service (NAS) has provided the same information for the 203 involved parties. However, this does not guarantee that the 204 information is correct in any sense. For many parameters it is 205 necessary for the EAP server to check that the NAS is providing it is 206 authorized to do. There are two authorization checks the EAP server 207 must do. The first is that the authenticating user is allowed to 208 access this service. The second is that the NAS node making the AAA 209 request is allowed to provide this service. Both of these checks use 210 the authentication information (who is the user being authenticated 211 and who is the AAA node providing the service) and policy configured 212 either on the EAP server or provided to it by other means such as 213 certificates containing authorization information. 215 In order to provide a generic solution where any EAP method can be 216 used on a given lower layer, the same format is used for the 217 exchanged information. This format consists of Tag-Length-Value 218 triplets with IANA managed tag space. 220 The parameter information is sent along the other messages in an EAP 221 method. Both the server and the peer send their information to the 222 other. Both parties make their own, independent decision about the 223 correctness of the information. When mismatching information is 224 received from EAP and authenticator, authentication MUST be 225 terminated. The exact message sequences depend on the used EAP 226 method, but Figure 1 shows a typical sequence. 228 Peer Authenticator Server 229 | | | 230 | 802.11 attachment+params | | 231 |<------------------------>| | 232 | | | 233 +-----------------------+ | | 234 | Peer now knows what | | | 235 | the authenticator has | | | 236 | claimed as parameters | | | 237 +-----------------------+ | | 238 | | | 239 | EAP Identity Request | | 240 |<-------------------------| | 241 | | | 242 | EAP Identity Response | | 243 |------------------------->| | 244 | | RADIUS Access-Req+params | 245 | |------------------------->| 246 | | | 247 | | +------------------------+ 248 | | | Server gets claimed | 249 | | | parameters from the | 250 | | | Access-Request message | 251 | | +------------------------+ 252 | | | 253 | | RADIUS Access-Challenge | 254 | EAP TLS Start |<-------------------------| 255 |<-------------------------| | 256 | | | 257 +-----------------------+ | | 258 | Peer sends a list of | | | 259 | parameters it thinks | | | 260 | are correct | | | 261 +-----------------------+ | | 262 | | | 263 | EAP TLS C-Hello + params | | 264 |------------------------->| | 265 | | RADIUS Access-Request | 266 | |------------------------->| 267 | | | 268 | | +------------------------+ 269 | | | Server can now compare | 270 | | | authenticator's and | 271 | | | peer's parameters | 272 | | +------------------------+ 273 | | | 274 | | RADIUS Access-Challenge | 275 | EAP TLS S-Hello + params |<-------------------------| 276 |<-------------------------| | 277 | | | 278 +-----------------------+ | | 279 | Peer can now compare | | | 280 | authenticator's and | | | 281 | server's parameters | | | 282 +-----------------------+ | | 283 | | | 284 | | | 285 | EAP TLS Finished | | 286 |------------------------->| RADIUS Access-Request | 287 | |------------------------->| 288 | | | 289 | | RADIUS Access-Challenge | 290 | EAP TLS Finished |<-------------------------| 291 |<-------------------------| | 292 | | | 293 | | | 294 | EAP TLS | | 295 |------------------------->| RADIUS Access-Request | 296 | |------------------------->| 297 | | | 298 | | RADIUS Access-Accept | 299 | EAP Success |<-------------------------| 300 |<-------------------------| | 301 | | | 303 Zero or more parameters are exchanged in each direction. Each 304 parameter is of the format explained in the next section. 306 3. Parameters 308 3.1 Format 310 Nodes supporting this extension pass parameters in the following 311 format: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |A| Res | Parameter Identifier | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 . . 320 . Value . 321 . . 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 The meaning of the fields is described as follows: 327 A 329 The authenticated information flag. Value of zero means that the 330 information is claimed by the service, but the EAP server is 331 unable to tell whether the service is authorized to claim this or 332 not. Value of one means that the EAP server knows that the service 333 is authorized to claim this. 335 Res 337 A 3-bit field reserved for future use. The value MUST be 338 initialized to zero by the sender, and MUST be ignored by the 339 receiver. 341 Parameter Identifier 343 A 16-bit field that specifies what parameter is being 344 communicated. 346 Length 348 A 12-bit field that indicates the length of the Value field, in 349 bytes. 351 Value 353 The actual parameter value. The interpretation of this value 354 depends on the Parameter Identifier field. 356 The encapsulation of this sequence of parameters is EAP method 357 dependent. 359 3.2 General Parameters 361 These parameters are for any type of nodes and lower layers. The 362 Service Type parameter MUST be supported by all nodes conforming to 363 this specification, and MUST be the first parameter in all messages 364 containing a sequence of parameters defined here. 366 3.2.1 Service Type Parameter 368 The Parameter Identifier for this parameter is 0, and the Value is a 369 32-bit integer, represented in network byte order. The following 370 values have been currently defined: 372 0 PPP 374 1 IEEE 802.11 376 2 PANA 378 3 IKEv2 380 The 'A' flag MUST always be set with the Service Type parameter. The 381 receiver SHOULD fail the authentication if the Value field is either 382 not recognized by it or is not the same one for which it thinks 383 access is being provided. 385 3.2.2 Service Provider Parameter 387 The Parameter Identifier for this parameter is 1, and the Value is an 388 UTF-8 encoded string describing the human readable name of the 389 service provider. As EAP is used primarily for network access, this 390 is typically the name of the access network provider. 392 3.2.3 Country Code Parameter 394 The Parameter Identifier for this parameter is 2, and the Value is an 395 ASCII string of at most 3 characters, conforming to the ISO 3166 [8] 396 country code. 398 3.3 Parameters for IEEE 802.11 wireless LANs 400 All the following parameters MUST be supported when IEEE 802.11 is 401 accepted as a Service Type. 403 3.3.1 SSID Parameter 405 The Parameter Identifier for this parameter is 3, and the Value is an 406 octet string containing the Service Set Identifier (SSID). 408 3.3.2 BSSID Parameter 410 The Parameter Identifier for this parameter is 4, and the Value is a 411 6-octet string containing the BSSID. 413 3.3.3 STA_MAC Parameter 415 The Parameter Identifier for this parameter is 5, and the Value is a 416 6-octet string containing the STA MAC address. 418 3.3.4 Protection Mechanism Parameter 420 The Parameter Identifier for this parameter is 6, and the Value is a 421 32-bit integer, represented in network byte order. The following 422 values have been currently defined: 424 0 WPA/802.11i 426 1 WEP/802.1X 428 2 802.1X only 430 3.4 Parameters for PPP 432 All the following parameters MUST be supported when PPP is accepted 433 as the Service Type. 435 3.4.1 Encapsulation Parameter 437 The Parameter Identifier for this parameter is 7, and the Value is a 438 32-bit integer, represented in network byte order. The following 439 values have been currently defined: 441 0 Framed 443 1 PPPoE 445 2 PPTP 447 3 L2TP 449 3.4.2 Called-Station-Id Parameter 451 The Parameter Identifier for this parameter is 8, and the Value is an 452 ASCII string containing the called station identity. 454 3.4.3 Protection Mechanism Parameter 456 The Parameter Identifier for this parameter is 9, and the Value is a 457 32-bit integer, represented in network byte order. The following 458 values have been currently defined: 460 0 None 462 1 MPPE 464 3.5 Parameters for PANA 466 All the following parameters MUST be supported when PANA is accepted 467 as the Service Type. 469 3.5.1 PaC Device-Id Parameter 471 The Parameter Identifier for this parameter is 10, and the Value is 472 an octet string containing the PaC Device-Id. 474 3.5.2 PAA Device-Id Parameter 476 The Parameter Identifier for this parameter is 11, and the Value is 477 an octet string containing the PAA Device-Id. 479 3.5.3 Protection Mechanism Parameter 481 The Parameter Identifier for this parameter is 12, and the Value is a 482 32-bit integer, represented in network byte order. The following 483 values have been currently defined: 485 0 None 487 1 Layer 2 489 3 IPsec 491 3.6 Parameters for IKEv2 493 All the following parameters MUST be supported when IKEv2 is accepted 494 as the Service Type. 496 3.6.1 Initiator Address Parameter 498 The Parameter Identifier for this parameter is 13, and the Value is 499 the IP address of the node who initiated this IKEv2 EAP exchange. The 500 Value is either 4 or 16 bytes depending on whether IPv4 or IPv6 is 501 used. 503 3.6.2 Responder Address Parameter 505 The Parameter Identifier for this parameter is 14, and the Value is 506 the IP address of the node who acted as the responder for this IKEv2 507 EAP exchange. The Value is either 4 or 16 bytes depending on whether 508 IPv4 or IPv6 is used. 510 3.6.3 IDi Parameter 512 The Parameter Identifier for this parameter is 15, and the Value is 513 an octet string containing the IKEv2 initiator identity payload 514 (IDi). 516 3.6.4 IDr Parameter 518 The Parameter Identifier for this parameter is 16, and the Value is 519 an octet string containing the IKEv2 initiator identity payload 520 (IDr). 522 4. EAP Method Extensions 524 This section describes an initial set of extensions to some current 525 EAP methods so that they can be transport the parameter information. 527 The extensions are optional and backwards compatible, so that, where 528 allowed by policy, EAP peers without these extensions can still 529 contact EAP servers with these extensions and vice versa. The default 530 policy SHOULD be that such usage is allowed. 532 4.1 EAP-TLS 534 A TLS extension [3] is added to the EAP TLS [2] client_hello/ 535 server_hello messages. The extension type of the extension is EAP 536 Service Identity and it has the number < To Be Assigned By IANA >. 537 The extension contains a sequence of parameters, followed by each 538 other. 540 As discussed in RFC 3546, when these extensions appear in a client 541 hello message, they are ignored by old server implementations. The 542 lack of this extension in the authenticator's server hello response 543 SHOULD be taken as an indication that the authenticator does not 544 support the mechanisms defined in this document. The authenticator 545 MUST NOT use this extension unless the client provided the same 546 extension in its own hello message, as per RFC 3546 the client is 547 required to terminate the TLS session otherwise. 549 The client_hello/server_hello messages are included in MACs in the 550 TLS Finished messages, which ensures that modifications will be 551 detected. 553 The following sequence illustrates the operation of the EAP TLS 554 protocol with this extension: 556 Peer Authenticator 557 | | 558 | PPP EAP-Request/ | 559 | EAP-Type=EAP-TLS | 560 | (TLS Start) | 561 |<---------------------------------------------------------| 562 | | 563 | PPP EAP-Response/ | 564 | EAP-Type=EAP-TLS | 565 | (TLS client_hello + parameters) | 566 |--------------------------------------------------------->| 567 | | 568 | PPP EAP-Request/ | 569 | EAP-Type=EAP-TLS | 570 | (TLS server_hello + parameters, | 571 | TLS certificate, | 572 | [TLS server_key_exchange,] | 573 | [TLS certificate_request,] | 574 | TLS server_hello_done) | 575 |<---------------------------------------------------------| 576 | | 577 | PPP EAP-Response/ | 578 | EAP-Type=EAP-TLS | 579 | (TLS certificate, | 580 | TLS client_key_exchange, | 581 | [TLS certificate_verify,] | 582 | TLS change_cipher_spec, | 583 | TLS finished) | 584 |--------------------------------------------------------->| 585 | | 586 | PPP EAP-Request/ | 587 | EAP-Type=EAP-TLS | 588 | (TLS change_cipher_spec, | 589 | TLS finished) | 590 |<---------------------------------------------------------| 591 | | 592 | PPP EAP-Response/ | 593 | EAP-Type=EAP-TLS | 594 |--------------------------------------------------------->| 595 | | 596 | PPP EAP-Success | 597 |<---------------------------------------------------------| 598 | | 600 This works the same way when resuming session. Note that the 601 parameters can change from the initial authentication. 603 4.2 PEAPv2 605 In PEAPv2 [7], the Connection-Binding TLV is used to carry parameter 606 objects. One Connection-Binding TLV for this purpose is exchanged in 607 each direction, containing all the parameters that need to be 608 exchanged. The Connection-Binding TLV carries a set of PEAPv2 TLVs. 609 The transport of parameters for the purposes of this document takes 610 place through the PEAPv2 Service Identity Parameter TLV defined in 611 the following: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |M|R| TLV Type | Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Parameter... | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 The fields of this TLV are as follows: 623 M 625 0 - Optional TLV. 627 R 629 Reserved, set to zero (0). 631 TLV Type 633 < To Be Assigned By IANA > 635 Length 637 Length of the TLV. 639 Parameter... 641 The parameter in the format described in Section 3.1. 643 4.3 EAP-AKA 645 For EAP-AKA, a new attribute AT_SERVICEID is added to the 646 EAP-Request/AKA/Challenge and EAP-Response/AKA/Challenge messages. 648 The format of the AT_SERVICEID attribute is shown below: 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | AT_SERVICEID | Length | Actual data length | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | | 656 . Parameters... . 657 . . 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 The fields of this attribute are as follows: 663 AT_SERVICEID 665 < To Be Assigned By IANA > 667 Length 669 Length of the attribute. 671 Actual data length 673 This field specifies the length of the following field in 674 bytes, because the length of the parameter must be a multiple 675 of 4 bytes, the sender pads the data with zero bytes when 676 necessary. 678 Parameters... 680 The parameters in the format described in Section 3.1. 682 The following sequence illustrates the operation of the EAP-AKA 683 protocol with this extension: 685 Peer Authenticator 686 | EAP-Request/Identity | 687 |<------------------------------------------------------| 688 | | 689 | EAP-Response/Identity | 690 | (Includes user's NAI) | 691 |------------------------------------------------------>| 692 | | 693 | +------------------------------+ 694 | | Server runs UMTS algorithms, | 695 | | generates RAND and AUTN. | 696 | +------------------------------+ 697 | | 698 | EAP-Request/AKA-Challenge | 699 | (AT_RAND, AT_AUTN, AT_MAC, AT_SERVICEID) | 700 |<------------------------------------------------------| 701 | | 702 +-------------------------------------+ | 703 | Peer runs UMTS algorithms on USIM, | | 704 | verifies AUTN and MAC, derives RES | | 705 | and session key | | 706 +-------------------------------------+ | 707 | | 708 | EAP-Response/AKA-Challenge | 709 | (AT_RES, AT_MAC, AT_SERVICEID) | 710 |------------------------------------------------------>| 711 | | 712 | +--------------------------------+ 713 | | Server checks the given RES, | 714 | | and MAC and finds them correct.| 715 | +--------------------------------+ 716 | | 717 | EAP-Success | 718 |<------------------------------------------------------| 720 Note that the AT_SERVICEID attribute is used also in the EAP-Request/ 721 AKA/AKA-Reauthentication and EAP-Response/AKA/AKA-Reauthentication 722 messages, and that the set of parameters exchanged in this case may 723 differ from those agreed upon earlier in the initial authentication. 725 The use of the AT_SERVICEID attribute is backwards compatible, 726 because existing implementations ignore unknown parameters. 728 4.4 EAP-SIM 730 For EAP-SIM, a new attribute AT_SERVICEID is added to the 731 EAP-Request/SIM/Challenge and EAP-Response/SIM/Challenge messages. 732 The format of the AT_SERVICEID attribute is as shown for EAP-AKA. 734 The following sequence illustrates the operation of the EAP-SIM 735 protocol with this extension: 737 Peer Authenticator 738 | | 739 | EAP-Request/Identity | 740 |<---------------------------------------------------------| 741 | | 742 | EAP-Response/Identity | 743 |--------------------------------------------------------->| 744 | | 745 | EAP-Request/SIM/Start | 746 | (AT_VERSION_LIST) | 747 |<---------------------------------------------------------| 748 | | 749 | EAP-Response/SIM/Start | 750 | (AT_NONCE_MT, AT_SELECTED_VERSION) | 751 |--------------------------------------------------------->| 752 | | 753 | EAP-Request/SIM/Challenge | 754 | (AT_RAND, AT_MAC, AT_SERVICEID) | 755 |<---------------------------------------------------------| 756 | | 757 +-------------------------------------+ | 758 | Peer runs GSM algorithms, | | 759 | verifies AT_MAC and derives | | 760 | session keys | | 761 +-------------------------------------+ | 762 | | 763 | EAP-Response/SIM/Challenge | 764 | (AT_MAC, AT_SERVICEID) | 765 |--------------------------------------------------------->| 766 | | 767 | | 768 | EAP-Success | 769 |<---------------------------------------------------------| 770 | | 772 As with EAP-AKA, the AT_SERVICEID attribute must be passed also in 773 the EAP-Request/SIM/SIM-Reauthentication and EAP-Response/SIM/ 774 SIM-Reauthentication messages. 776 5. Security Considerations 778 The implications of being unable to verify service identities have 779 been described in Section 7.15 of [4]. These include vulnerabilities 780 related to compromised access points or fraudulent service providers. 781 The mechanism provided in this document removes these 782 vulnerabilities. The mechanism is generic and not tied to any 783 specific EAP method or use of EAP over a specific link layer, and as 784 such can be expected to be more easily deployed as alternative 785 suggestions such as those described in PEAPv2 [7] or EAP FAST [13]. 787 In order to operate, however, the mechanism requires that the used 788 AAA protocol is able to transport the same information (such as the 789 SSID that an access point claims the user requested) to the home AAA 790 server, so that the server can compare this claim to the 791 authenticated information received from the client. Where such 792 information is not available, vulnerabilities still remain. 794 In the deployment phase, it is possible that clients and servers do 795 not get support for the mechanism described in this document at the 796 same time. It is a policy decision to accept an EAP exchange from a 797 party that does not support this mechanism. This decision is 798 protected from a bidding down attack by a man-in-the-middle, because 799 EAP methods have integrity protection for the exchanged messages. 800 Therefore, the removal or modification of the parameter block would 801 be detected. 803 6. IANA Considerations 805 6.1 Allocations Requested in This Document 807 This document requests an IANA allocation of TLS Extension type [3] 808 for EAP Service Identity (see Section 4.1). 810 This document requests an IANA allocation of a PEAPv2 [7] TLV type 811 number for the Service Identity Parameter TLV (see Section 4.2). 813 This document requests an IANA allocation for the attribute type 814 number AT_SERVICEID in the [6] and [5] protocols (see Section 4.3 and 815 Section 4.4). The same value should be allocated for both protocols. 817 6.2 Future Allocation Policy 819 New Parameter Identifier values can be defined through Specification 820 Required [1]. The following values have been currently allocated: 822 0 Service Type 824 1 Service Provider 826 2 Country Code 827 3 802.11/SSID 829 4 802.11/BSSID 831 5 802.11/STA_MAC 833 6 802.11/Protection Mechanism 835 7 PPP/Encapsulation 837 8 PPP/Called-Station-Id 839 9 PPP/Protection Mechanism 841 10 PANA/PaC Device-Id 843 11 PANA/PAA Device-Id 845 12 PANA/Protection Mechanism 847 13 IKEv2/Initiator Address 849 14 IKEv2/Responder Address 851 15 IKEv2/IDi 853 16 IKEv2/IDr 855 New Service Type values can be defined through IETF Consensus [1]. 856 The following values have been currently allocated: 858 0 PPP 860 1 IEEE 802.11 862 2 PANA 864 3 IKEv2 866 Values in other enumerated parameters can be defined through First 867 Come, First Served [1]. 869 Normative References 871 [1] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 872 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 874 [2] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 875 RFC 2716, October 1999. 877 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. 878 Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, 879 June 2003. 881 [4] Blunk, L., "Extensible Authentication Protocol (EAP)", 882 draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. 884 [5] Haverinen, H. and J. Salowey, "EAP SIM Authentication", 885 draft-haverinen-pppext-eap-sim-12 (work in progress), October 886 2003. 888 [6] Arkko, J. and H. Haverinen, "EAP AKA Authentication", 889 draft-arkko-pppext-eap-aka-11 (work in progress), October 2003. 891 [7] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected 892 EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 893 (work in progress), October 2003. 895 [8] International Organization for Standardization, "Codes for the 896 representation of names of countries, 3rd edition", ISO Standard 897 3166, August 1988. 899 Informative References 901 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 902 Authentication Dial In User Service (RADIUS)", RFC 2865, June 903 2000. 905 [10] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 906 August 2001. 908 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 909 In User Service) Support For Extensible Authentication Protocol 910 (EAP)", RFC 3579, September 2003. 912 [12] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 913 802.1X Remote Authentication Dial In User Service (RADIUS) 914 Usage Guidelines", RFC 3580, September 2003. 916 [13] Salowey, J., "EAP Flexible Authentication via Secure Tunneling 917 (EAP-FAST)", draft-cam-winget-eap-fast-00 (work in progress), 918 February 2004. 920 Authors' Addresses 922 Jari Arkko 923 Ericsson 925 FI-02420 Jorvas 926 Finland 928 EMail: jari.arkko@ericsson.com 930 Pasi Eronen 931 Nokia Research Center 932 P.O. Box 407 933 FI-00045 Nokia Group 934 Finland 936 EMail: pasi.eronen@nokia.com 938 Appendix A. Acknowledgments 940 The authors would like to thank Bernard Aboba, Mohan Parthasarathy, 941 and David Mariblanca for interesting discussions in this problem 942 space. 944 Intellectual Property Statement 946 The IETF takes no position regarding the validity or scope of any 947 Intellectual Property Rights or other rights that might be claimed to 948 pertain to the implementation or use of the technology described in 949 this document or the extent to which any license under such rights 950 might or might not be available; nor does it represent that it has 951 made any independent effort to identify any such rights. Information 952 on the IETF's procedures with respect to rights in IETF Documents can 953 be found in BCP 78 and BCP 79. 955 Copies of IPR disclosures made to the IETF Secretariat and any 956 assurances of licenses to be made available, or the result of an 957 attempt made to obtain a general license or permission for the use of 958 such proprietary rights by implementers or users of this 959 specification can be obtained from the IETF on-line IPR repository at 960 http://www.ietf.org/ipr. 962 The IETF invites any interested party to bring to its attention any 963 copyrights, patents or patent applications, or other proprietary 964 rights that may cover technology that may be required to implement 965 this standard. Please address the information to the IETF at 966 ietf-ipr@ietf.org. 968 The IETF has been notified of intellectual property rights claimed in 969 regard to some or all of the specification contained in this 970 document. For more information consult the online list of claimed 971 rights. 973 Disclaimer of Validity 975 This document and the information contained herein are provided on an 976 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 977 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 978 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 979 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 980 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 981 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 983 Copyright Statement 985 Copyright (C) The Internet Society (2004). This document is subject 986 to the rights, licenses and restrictions contained in BCP 78, and 987 except as set forth therein, the authors retain all their rights. 989 Acknowledgment 991 Funding for the RFC Editor function is currently provided by the 992 Internet Society.