idnits 2.17.1 draft-ietf-netext-wifi-epc-eap-attributes-15.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2014) is 3416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 185, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext Ravi. Valmikam 3 Internet-Draft Unaffiliated 4 Intended status: Informational Rajeev. Koodli 5 Expires: June 20, 2015 Intel 6 December 17, 2014 8 EAP Attributes for Wi-Fi - EPC Integration 9 draft-ietf-netext-wifi-epc-eap-attributes-15 11 Abstract 13 With Wi-Fi emerging as a crucial access network for mobile service 14 providers, it has become important to provide functions commonly 15 available in 3G and 4G networks in Wi-Fi access networks as well. 16 Such functions include Access Point Name (APN) Selection, multiple 17 Packet Data Network (PDN) connections, and seamless mobility between 18 Wi-Fi and 3G/4G networks. 20 The EAP-AKA (and EAP-AKA') protocol is required for mobile devices to 21 access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This 22 document defines a few new EAP attributes to enable the above- 23 mentioned functions in such networks. The attributes are exchanged 24 between a client (such as a Mobile Node) and its network counterpart 25 (such as a AAA server) in the service provider's infrastructure. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 20, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. APN Selection . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Multiple APN Connectivity . . . . . . . . . . . . . . . . 4 64 1.3. Wi-Fi to E-UTRAN mobility . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Brief Introduction to EAP . . . . . . . . . . . . . . . . 4 68 3.2. IEEE 802.11 Authentication using EAP over 802.1X . . . . 5 69 4. New EAP Attributes . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. APN Selection . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Connectivity Type . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Wi-Fi to UTRAN/E-UTRAN Mobility . . . . . . . . . . . . . 7 73 4.4. MN Serial ID . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Attribute Extensions . . . . . . . . . . . . . . . . . . . . 8 75 5.1. AT_VIRTUAL_NETWORK_ID . . . . . . . . . . . . . . . . . . 8 76 5.2. AT_VIRTUAL_NETWORK_REQ . . . . . . . . . . . . . . . . . 9 77 5.3. AT_CONNECTIVITY_TYPE . . . . . . . . . . . . . . . . . . 10 78 5.4. AT_HANDOVER_INDICATION . . . . . . . . . . . . . . . . . 11 79 5.5. AT_HANDOVER_SESSION_ID . . . . . . . . . . . . . . . . . 11 80 5.6. AT_MN_SERIAL_ID . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 Wi-Fi has emerged as a "trusted" access technology for mobile service 93 providers; see [EPC2] for reference to the 3GPP description of 94 "trusted" access. Advances in IEEE 802.11u [IEEE802.11u] and 95 "HotSpot 2.0" [hs20] have enabled seamless roaming, in which a Mobile 96 Node can select and connect to a Wi-Fi access network just as it 97 would roam into a cellular network. It has thus become important to 98 provide certain functions in Wi-Fi which are commonly supported in 99 licensed-spectrum networks such as 3G and 4G networks. This draft 100 specifies a few new EAP attributes for a Mobile Node (MN) to interact 101 with the network to support some of these functions (see below). 102 These new attributes serve as a trigger for Proxy Mobile IPv6 network 103 nodes to undertake the relevant mobility operations. For instance, 104 when the Mobile Node requests and the network agrees for a new IP 105 session (i.e., a new Access Point Name or APN in 3GPP), the 106 corresponding attribute (defined below) acts as a trigger for the 107 Mobile Anchor Gateway (MAG) to initiate a new mobility session with 108 the Local Mobility Anchor (LMA). This document refers to [RFC6459] 109 for the basic definitions of mobile network terminology (such as APN) 110 used here. 112 The 3rd Generation Partnership Project (3GPP) networks support many 113 functions that are not commonly implemented in a Wi-Fi network. This 114 document defines EAP attributes that enable the following functions 115 in Wi-Fi access networks using EAP-AKA' [RFC5448] and EAP-AKA 116 [RFC4187]: 118 o APN Selection 120 o Multiple APN Connectivity 122 o Wi-Fi to 3G/4G (UTRAN/EUTRAN) mobility 124 The attributes defined here are exchanged between the Mobile Node and 125 the EAP server, typically realized as part of the AAA server 126 infrastructure in a service provider's infrastructure. In 127 particular, the Wi-Fi access network simply conveys the attributes to 128 the service provider's core network where the EAP processing takes 129 place [EPC]. Since these attributes share the same IANA registry, 130 the methods are applicable to EAP-AKA', EAP-AKA, EAP-SIM [RFC4186] 131 and, with appropriate extensions, are possibly applicable for other 132 EAP methods as well. In addition to the trusted Wi-Fi access 133 networks, the attributes are applicable to any trusted "non-3GPP" 134 access network that uses the EAP methods and provides connectivity to 135 the mobile EPC, which provides connectivity for 3G, 4G, and other 136 non-3GPP access networks [EPC2]. 138 1.1. APN Selection 140 The 3GPP networks support the concept of an APN (Access Point Name). 141 This is defined in [GPRS]. Each APN is an independent IP network 142 with its own set of IP services. When the MN attaches to the 143 network, it may select a specific APN to receive desired services. 144 For example, to receive generic Internet services, a user device may 145 select APN "Internet" and to receive IMS voice services, it may 146 select APN "IMSvoice". 148 In a Wi-Fi access scenario, an MN needs a way of sending the desired 149 APN name to the network. This draft specifies a new attribute to 150 propagate the APN information via EAP. The agreed APN is necessary 151 for the Proxy Mobile IPv6 MAG to initiate a new session with the LMA. 153 1.2. Multiple APN Connectivity 155 As an extension of APN Selection, an MN may choose to connect to 156 multiple IP networks simultaneously. 3GPP provides this feature via 157 additional Packet Data Protocol (PDP) contexts or additional Packet 158 Data Network (PDN) connections, and defines the corresponding set of 159 signaling procedures. In a trusted Wi-Fi network, an MN connects to 160 the first APN via DHCPv4 or IPv6 Router Solicitation. This document 161 specifies an attribute that indicates the MN's capability to support 162 multiple APN connectivity. The specific connectivity types are also 163 necessary for the Proxy Mobile IPv6 signaling. 165 1.3. Wi-Fi to E-UTRAN mobility 167 When operating in a multi-access network, an MN may want to 168 gracefully handover its IP attachment from one access network to 169 another. For instance, an MN connected to a 3GPP E-UTRAN network may 170 choose to move its connectivity to a trusted Wi-Fi network. 171 Alternatively, the MN may choose to connect using both access 172 technologies simultaneously, and maintain two independent IP 173 attachments. To implement these scenarios, the MN needs a way to 174 correlate the UTRAN/E-UTRAN session with the new Wi-Fi session. This 175 draft specifies an attribute to propagate E-UTRAN session 176 identification to the network via EAP. This helps the network to 177 correlate the sessions between the two Radio Access Network 178 technologies and thus helps the overall handover process. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Protocol Overview 188 3.1. Brief Introduction to EAP 190 EAP is defined as a generic protocol in [RFC3748]. EAP, combined 191 with one of the payload protocols such as EAP-AKA' [RFC5448] can 192 accomplish several things in a network: 194 o Establish identity of the user (MN) to the network. 196 o Authenticate the user during the first attach with the help of an 197 authentication center that securely maintains the user 198 credentials. This process is called EAP Authentication. 200 o Re-authenticate the user periodically, but without the overhead of 201 a round-trip to the authentication center. This process is called 202 EAP Fast Re-Authentication. 204 This draft makes use of the EAP Authentication procedure. The use of 205 EAP Fast Re-Authentication procedure is for further study. Both the 206 EAP Authentication and EAP Fast Re-Authentication procedures are 207 specified for trusted access network use in 3GPP. [TS-33.402] 209 3.2. IEEE 802.11 Authentication using EAP over 802.1X 211 In a Wi-Fi network, EAP is carried over the IEEE 802.1X 212 Authentication protocol. The IEEE 802.1X Authentication is a 213 transparent, payload-unaware mechanism to carry the authentication 214 messages between the MN and the Wi-Fi network elements. 216 EAP, on the other hand, has multiple purposes. Apart from its core 217 functions of communicating an MN's credentials to the network and 218 proving the MN's identity, it also allows the MN to send arbitrary 219 information elements to help establish the MN's IP session in the 220 network. The following figure shows an example end-to-end EAP flow 221 in the context of an IEEE 802.11 Wi-Fi network. We first define the 222 terminology: 224 o MN: Mobile Node 226 o WAN: Wi-Fi Access Node, typically consisting of Wi-Fi Access Point 227 and Wi-Fi Controller. In a PMIPv6 [RFC5213] network, the MAG 228 functionality is located in the WAN, either in the Wi-Fi Access 229 Point or in the Wi-Fi Controller. 231 o AAA: The infrastructure node supporting the AAA server with the 232 EAP methods (AKA, AKA', EAP-SIM). The end-points of the EAP 233 method are the MN and the AAA server. 235 o IPCN: IP Core Network. This includes the PMIPv6 LMA function. 237 MN WAN AAA IPCN 238 (MAG) (LMA) 239 1)|<----------Beacon--------| | | 240 2)|<----------Probe-------->| | | 241 | | | | 242 | 802.11 Auth| | | 243 3)|<----------------------->| | | 244 | | | | 245 | 802.11 Association| | | 246 4)|<----------------------->| | | 247 | | | | 248 5)|<----EAP Req/Identity----| | | 249 | | | | 250 6)|----EAP Resp/Identity----|->--EAP Resp/Identity--->| | 251 | | | | 252 7)|<-EAP Req/AKA-Challenge<-|--EAP Req/AKA-Challenge--| | 253 | | | | 254 8)|-EAP Resp/AKA-Challenge--|>EAP Resp/AKA-Challenge->| | 255 | | | | 256 9)|<-----EAP Success------<-|------EAP Success--------| | 257 | | | | 258 10)|<====== 802.11 Data ====>|<=========== 802.11Data ====Tunnel to=>| 259 | | | core network| 260 | | | | 262 Figure 1: Example EAP Deployment 264 The figure shows separate Wi-Fi Access Point and Wi-Fi Access 265 Controller, following the split-MAC model of CAPWAP [RFC5415]. A 266 particular deployment may have the two functions within a single 267 node. 269 1. An MN detects a beacon from a WAP in the vicinity. 271 2. The MN probes the WAP to determine suitability to attach (Verify 272 SSID list, authentication type and so on). 274 3. The MN initiates the IEEE 802.11 Authentication with the Wi-Fi 275 network. In WPA/WPA2 mode, this is an open authentication 276 without any security credential verification. 278 4. The MN initiates 802.11 Association with the Wi-Fi network. 280 5. The Wi-Fi network initiates 802.1X/EAP Authentication procedures 281 by sending EAP Request/Identity. 283 6. The MN responds with its permanent or temporary identity. 285 7. The Wi-Fi network challenges the MN to prove its identity by 286 sending EAP Request/AKA-Challenge. 288 8. The MN calculates the security digest and responds with EAP 289 Response/AKA-Challenge. 291 9. If the authentication is successful, the Wi-Fi network responds 292 to the MN with EAP Success. 294 10. An end-to-End data path is available for the MN to start IP 295 layer communication (DHCPv4, IPv6 Router Solicitation and so 296 on). 298 4. New EAP Attributes 300 The following sections define the new EAP attributes and their usage. 302 4.1. APN Selection 304 In a Wi-Fi network, an MN includes the AT_VIRTUAL_NETWORK_ID 305 attribute in the EAP-Response/AKA-Challenge to indicate the desired 306 APN identity for the first PDN connection. 308 If the MN does not include the AT_VIRTUAL_NETWORK_ID attribute in the 309 EAP-Response/AKA-Challenge, the network may select an APN by other 310 means. This selection mechanism is outside the scope of this 311 document. 313 An MN includes the AT_VIRTUAL_NETWORK_REQ attribute to indicate 314 single or multiple PDN capability. In addition, a sub-type in the 315 attribute indicates IPv4, IPv6, or dual IPv4v6 PDN connectivity. 317 4.2. Connectivity Type 319 An MN indicates its preference for connectivity using the 320 AT_CONNECTIVITY_TYPE attribute in the EAP-Response/AKA-Challenge 321 message. The preference indicates whether the MN wishes connectivity 322 to the Evolved Packet Core (the so-called "EPC PDN connectivity") or 323 Internet Offload (termed as "Non-Seamless Wireless Offload"). 325 The network makes its decision and replies with the same attribute in 326 the EAP Success message. 328 4.3. Wi-Fi to UTRAN/E-UTRAN Mobility 330 When a multi-access MN enters a Wi-Fi network, the following 331 parameters are applicable in the EAP-Response/AKA-Challenge for IP 332 session continuity from UTRAN/E-UTRAN. 334 o AT_HANDOVER_INDICATION: This attribute indicates to the network 335 that the MN intends to continue the IP session from UTRAN/E-UTRAN. 336 If a previous session can be located, network will honor this 337 request by connecting the Wi-Fi access to the existing IP session. 339 o AT_HANDOVER_SESSION_ID: An MN MAY use this attribute to identify 340 the session on UTRAN/E-UTRAN. If used, this attribute contains 341 P-TMSI (Packet Temporary Mobile Subscriber Identity) if the 342 previous session was on UTRAN or M-TMSI (Mobile Temporary Mobile 343 Subscriber Identity) if the previous session was on E-UTRAN. This 344 attribute helps the network correlate the Wi-Fi session to an 345 existing UTRAN/E-UTRAN session. 347 4.4. MN Serial ID 349 The MN_SERIAL_ID attribute defines an MN's serial number, including 350 International Mobile Equipment Identity (IMEI) and International 351 Mobile Equipment Identity Software Version (IMEISV). The IMEI (or 352 IMEISV) is used for ensuring a legitimate (and not a stolen) device 353 is in use. As with the others, this attribute is exchanged with the 354 service provider's AAA server. The MN_SERIAL_ID MUST NOT be 355 propagated further by the AAA server to any other node. 357 5. Attribute Extensions 359 The format for the new attributes follows that in [RFC4187]. Note 360 that the Length field value is inclusive of the first two bytes. 362 5.1. AT_VIRTUAL_NETWORK_ID 364 The AT_VIRTUAL_NETWORK_ID attribute identifies the virtual IP network 365 that the MN intends to attach to. The implementation of the virtual 366 network on the core network side is technology specific. For 367 instance, in a 3GPP network, the virtual network is implemented based 368 on the 3GPP APN primitive. 370 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 371 message. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |AT_VIRTUAL | Length | Virtual Network Id | 377 | _NETWORK_ID | | | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Virtual Network Id | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 2: AT_VIRTUAL_NETWORK_ID EAP Attribute 385 Virtual Network Id: 387 An arbitrary octet string that identifies a virtual network in the 388 access technology the MN is attaching to. For instance, in 3GPP 389 E-UTRAN, this could be an APN. See [TS-23.003] for encoding of the 390 field. 392 5.2. AT_VIRTUAL_NETWORK_REQ 394 When an MN intends to connect an APN, it SHOULD use this attribute to 395 indicate different capabilities to the network. In turn, the network 396 provides what is supported. 398 From the MN, this attribute can be included only in EAP-Response/ 399 Identity. From the network, it SHOULD be included in the EAP 400 Request/AKA-Challenge message. In the MN-to-network direction, the 401 Type field (below) indicates the MN's request. In the network-to-MN 402 direction, the Type field indicates network's willingness to support 403 the request; a present Type field value indicates the network support 404 for that Type. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |AT_VIRTUAL_ | Length | Virt-Net-Req | Virt-Net-Req | 410 |NETWORK_REQ | | Type | Sub-type | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 3: AT_VIRTUAL_NETWORK_REQ EAP Attribute 415 Virt-Net-Req Type: 417 Type can have one of the following values: 419 o TBA IANA: Reserved 420 o TBA IANA: Single PDN connection 422 o TBA IANA : Multiple PDN connection. Can request Non-Seamless Wi- 423 Fi Offload or EPC connectivity (see the Connectivity Type 424 attribute below) 426 Virt-Net-Req Sub-type: 428 Sub-type can have one of the following values: 430 o TBA IANA : Reserved 432 o TBA IANA : PDN Type: IPv4 434 o TBA IANA : PDN Type: IPv6 436 o TBA IANA : PDN Type: IPv4v6 438 5.3. AT_CONNECTIVITY_TYPE 440 An MN uses this attribute to indicate whether it wishes the 441 connectivity type to be Non-Seamless WLAN Offload or EPC. This 442 attribute is applicable for multiple PDN connections only. 444 From the MN, this attribute can be included only in EAP-Response/ 445 Identity. From the network, it SHOULD be included in the EAP 446 Request/AKA-Challenge message. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |AT_CONNECTIVITY| Length | Connectivity | Reserved | 452 |_TYPE | | Type | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 4: AT_CONNECTIVITY_TYPE EAP Attribute 457 Connectivity Type: 459 Connectivity Type can have one of the following values: 461 o TBA IANA : Reserved 463 o TBA IANA : Non-Seamless WLAN Offload (NSWO) 465 o TBA IANA : EPC PDN connectivity 467 5.4. AT_HANDOVER_INDICATION 469 This attribute indicates an MN's handover intention of an existing IP 470 attachment. 472 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 473 message. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 |AT_HANDOVER_IND| Length | Handover | Pad | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 5: AT_HANDOVER_INDICATION EAP Attribute 483 Handover Type: 485 o 0 - the MN has no intention of handing over an existing IP 486 session, i.e., the MN is requesting an independent IP session with 487 the Wi-Fi network without disrupting the IP session with the 488 UTRAN/E-UTRAN. In this case, no Session Id (Section 5.5) is 489 included. 491 o 1 - the MN intends to handover an existing IP session. In this 492 case, MN MAY include a Session Id (Section 5.5) to correlate this 493 Wi-Fi session with a UTRAN/E-UTRAN session. 495 5.5. AT_HANDOVER_SESSION_ID 497 When an MN intends to handover an earlier IP session to the current 498 access network, it may propagate a session identity that can help 499 identify the previous session from UTRAN/E-UTRAN that the MN intends 500 to handover. This attribute is defined as a generic octet string. 501 The MN MAY include an E-UTRAN GUTI if the previous session was an 502 E-UTRAN session. If the previous session was a UTRAN session, the MN 503 MAY include UTRAN Global RNC ID (MCC, MNC, RNC Id) and P-TMSI 504 concatenated as an octet string. 506 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 507 message. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |AT_HANDOVER_ | Length | Access | Reserved | 513 | SESSION_ID | | Technology | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Session Id | 516 | ... | 517 | ... | 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 6: AT_HANDOVER_SESSION_ID EAP Attribute 523 Access Technology: 525 This field represents the RAN technology from which the MN is 526 undergoing a handover. 528 o TBA IANA: Reserved 530 o TBA IANA: UTRAN 532 o TBA IANA: E-UTRAN 534 Session Id: 536 An octet string of variable length that identifies the session in the 537 source access technology. As defined at the beginning of this 538 section, the actual value is RAN technology dependent. For E-UTRAN, 539 the value is GUTI. For UTRAN, the value is Global RNC Id (6 bytes) 540 followed by P-TMSI (4 bytes). See [TS-23.003] for encoding of the 541 field. 543 5.6. AT_MN_SERIAL_ID 545 This attribute defines the MN's machine serial number. Examples are 546 International Mobile Equipment Identity (IMEI) and International 547 Mobile Equipment Identity Software Version (IMEISV). 549 A network that requires the machine serial number for authorization 550 purposes MUST send a request for the attribute in an EAP-Request/AKA- 551 Challenge message. If the attribute is present, the MN SHOULD 552 include the attribute in the EAP-Response/AKA-Challenge message. If 553 the MN sends the attribute, it MUST be contained within an 554 AT_ENCR_DATA attribute. An MN MUST NOT provide the attribute unless 555 it receives the request from a network authenticated via EAP/AKA. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |AT_MN_ | Length | Serial ID | Reserved | 561 | SERIAL_ID | | Type | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | MN Serial Id | 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 7: AT_MN_SERIAL_ID EAP Attribute 569 Serial ID Type: 571 This field identifies the type of the MN Identifier. 573 o TBA IANA: Reserved 575 o TBA IANA: IMEI 577 o TBA IANA: IMEISV 579 MN Serial Id: 581 An arbitrary octet string that identifies the MN's machine serial 582 number. The actual value is device-specific. See [TS-23.003] for 583 encoding of the field. When sent by the network in the EAP-Request/ 584 AKA-Challenge message, this field is not present, which serves as an 585 indication for the MN to provide the attribute in the EAP-Response/ 586 AKA-Challenge message. 588 AT_MN_SERIAL_ID attribute MUST only be used with methods which can 589 provide mutual (network and device) authentication, such as AKA, AKA' 590 and EAP-SIM 592 6. Security Considerations 594 This document defines new EAP attributes to extend the capability of 595 the EAP-AKA protocol as specified in Section 8.2 of [RFC4187]. The 596 attributes are passed between an MN and a AAA server in provider- 597 controlled trusted Wi-Fi networks, where the Wi-Fi Access Network is 598 a relay between the MN and the AAA server. The document does not 599 specify any new messages or options to the EAP-AKA protocol. 601 The attributes defined here are fields which are used in existing 3G 602 and 4G networks, where they are exchanged (in protocols specific to 603 3G and 4G networks) subsequent to the mobile network authentication 604 (e.g., using the UMTS-AKA mechanism). For the operator-controled Wi- 605 Fi access which is connected to the same core infrastructure as the 606 3G and 4G access, similar model is followed here with the EAP-AKA (or 607 EAP-AKA', EAP-SIM) authentication. In doing so, these attribute 608 processing, security-wise, is no worse than that in existing 3G and 609 4G mobile networks. 611 The attributes inherit the security protection (integrity, replay, 612 and confidentiality) provided by the paratmeters in the AKA(') or SIM 613 methods ; see Section 12.6 in [RFC4187]. Furthermore, RFC 4187 614 requires attributes exchanged in EAP-Request/AKA-Identity or EAP- 615 Response/AKA-Identity to be integrity-protected with AT_CHECKCODE; 616 see Section 8.2 in [RFC4187]. This requirement applies to the 617 AT_CONNECTIVITY_TYPE and AT_VIRTUAL_NETWORK_REQ attributes defined in 618 this document. 620 The AT_MN_SERIAL_ID attribute MUST have confidentiality protection 621 provided by the AKA(') or EAP-SIM methods beyond the secure transport 622 (such as private leased lines, VPN etc.) deployed by the provider of 623 the trusted Wi-Fi service. 625 7. IANA Considerations 627 This document defines the following new skippable EAP-AKA attributes. 628 These attributes need assignments from the "EAP-AKA and EAP-SIM 629 Parameters" registry at https://www.iana.org/assignments/eapsimaka- 630 numbers 632 o AT_VIRTUAL_NETWORK_ID (Section 5.1) - TBA by IANA 634 o AT_VIRTUAL_NETWORK_REQ (Section 5.2) - TBA by IANA 636 o AT_CONNECTIVITY_TYPE (Section 5.3) - TBA IANA 638 o AT_HANDOVER_INDICATION (Section 5.4) - TBA by IANA 640 o AT_HANDOVER_SESSION_ID (Section 5.5) - TBA by IANA 642 o AT_MN_SERIAL_ID (Section 5.6) - TBA by IANA 644 This document requests a new IANA registry "Trusted non-3GPP Access 645 EAP Parameters". The range for both Types and Sub types in the 646 registry is 0 - 127, with 0 (zero) being a reserved value. The 647 document requests IANA to make assignments in a monotonically 648 increasing order in increments of 1, starting from 1. New 649 assignments in this registry are made with the Specification Required 650 policy [RFC5226]. 652 The IANA Designated Expert should review the requirements for new 653 assignments based on factors including, but not limited to, the 654 source of request (e.g., standards bodies), deployment needs (e.g., 655 industry consortium, operator community) and experimental needs 656 (e.g., academia, industrial labs). A document outlining the purpose 657 of new assignments should accompany the request. Such a document 658 could be a standards document, or a research project description. 659 The Designated Expert should consider that there is sufficient 660 evidence of potential usage both on the end-points (e.g., Mobile 661 Devices etc.) and the infrastructure (e.g., AAA servers, gateways 662 etc.) 664 The document requests assignments from the new registry for the 665 following fields defined in this document: 667 o Virt-Net-Req Type (Section 5.2) - TBA by IANA 669 o Virt-Net-Req Sub type (Section 5.2) - TBA by IANA 671 o Connectivity Type (Section 5.3) - TBA IANA 673 o Access Technology (Section 5.5) - TBA by IANA 675 o Serial ID Type (Section 5.6) - TBA by IANA 677 8. Acknowledgment 679 Thanks to Sebastian Speicher for the review and suggesting 680 improvements. Thanks to Mark Grayson for proposing the MN Serial ID 681 attribute. And, thanks to Brian Haberman for suggesting a new 682 registry. 684 9. References 686 9.1. Normative References 688 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 689 Protocol Method for 3rd Generation Authentication and Key 690 Agreement (EAP-AKA)", RFC4187, January 2006, 691 . 693 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 694 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 695 May 2008. 697 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 698 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 699 Partnership Project (3GPP) Evolved Packet System (EPS)", 700 RFC 6459, January 2012. 702 9.2. Informative References 704 [EPC] "General Packet Radio Service (GPRS); enhancements for 705 Evolved Universal Terrestrial Radio Access Network 706 (E-UTRAN) access, 3GPP TS 23.401 8.8.0, December 2009.", 707 . 709 [EPC2] "Architecture enhancements for non-3GPP accesses, 3GPP TS 710 23.402 8.8.0, December 2009.", 711 . 713 [GPRS] "General Packet Radio Service (GPRS); Service description, 714 Stage 2, 3GPP TS 23.060, December 2006", 715 . 717 [IEEE802.11u] 718 "802.11u-2011 - IEEE Standard for Information Technology- 719 Telecommunications and information exchange between 720 systems- Local and Metropolitan networks-specific 721 requirements- Part II: Wireless LAN Medium Access Control 722 (MAC) and Physical Layer (PHY) specifications: Amendment 723 9: Interworking with External Networks", , Feb 2011, 724 . 727 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 728 Levkowetz, Ed., "Extensible Authentication Protocol 729 (EAP)", RFC3748, June 2004, 730 . 732 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 733 Protocol Method for Global System for Mobile 734 Communications (GSM) Subscriber Identity Modules (EAP- 735 SIM)", RFC 4186, January 2006. 737 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 738 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 740 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 741 Provisioning of Wireless Access Points (CAPWAP) Protocol 742 Specification", RFC5415, January 2009, 743 . 745 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 746 Extensible Authentication Protocol Method for 3rd 747 Generation Authentication and Key Agreement (EAP-AKA')", 748 RFC 5448, May 2009. 750 [TS-23.003] 751 "3rd Generation Partnership Project: Numbering, Addressing 752 and Identification, 3GPP TS 23.003 12.2.0, March 2014.", , 753 . 755 [TS-33.402] 756 "3GPP System Architecture Evolution (SAE); Security 757 aspects of non-3GPP accesses, 3GPP TS 33.402 8.6.0, 758 December 2009.", , 759 . 761 [hs20] "Hotspot 2.0 (Release 2) Technical Specification Package 762 v1.0.0", , . 765 Appendix A. Change Log 767 o: Initial Draft 769 o: v01: status to Informational, Updated References, Revised the 770 Figure 772 o: No changes from 01 to 02 774 o: Per recent 3GPP updates, added the Connectivity Type attribute 775 to allow indicating Non-Seamless WLAN Offload or EPC connectivity 777 o: version-04: Revised AT_VIRTUAL_NETWORK_REQ to include 1) single 778 PDN vs Multiple PDN connections, 2) PDN Types, and referred to 779 NSWO Connectivity Type attribute 781 o: version 05: Added AT_MN_SERIAL_ID. Revised the IANA 782 Considerations section 784 o: version 06, 07: various edits 786 o: AD review revs 788 o: version 09: IETF LC, Directorate review revs 790 o: IANA Section revision, based on IANA interaction 791 o: version 12 - clarified/revised: 1) IMEI purpose, 2) attributes 792 requirement in PMIP6 signaling, 3) references to 802.11u, HotSpot 793 2.0 (seamless roaming) 4) References (normative/informative), 5) 794 editorial corrections 796 o: version 13 - revised AT_MN_SERIAL_ID processing per IESG 797 DISCUSS 799 o: version 14 -clarified usage of AT_MN_SERIAL_ID. Provided 800 additional reference to "trusted" Wi-Fi access. 802 Authors' Addresses 804 Ravi Valmikam 805 Unaffiliated 806 USA 808 Email: valmikam@gmail.com 810 Rajeev Koodli 811 Intel 812 USA 814 Email: rajeev.koodli@intel.com