idnits 2.17.1 draft-ietf-netext-wifi-epc-eap-attributes-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 21, 2014) is 3538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 171, but not defined Summary: 0 errors (**), 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: January 22, 2015 Intel 6 July 21, 2014 8 EAP Attributes for Wi-Fi - EPC Integration 9 draft-ietf-netext-wifi-epc-eap-attributes-09 11 Abstract 13 With Wi-Fi emerging as a trusted access network for 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 trusted Wi-Fi 22 networks. This document defines a few new EAP attributes to enable 23 the above-mentioned functions in trusted Wi-Fi access networks. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 22, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. APN Selection . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Multiple APN Connectivity . . . . . . . . . . . . . . . . 3 62 1.3. Wi-Fi to E-UTRAN mobility . . . . . . . . . . . . . . . . 4 63 2. Reference Architecture and Terminology . . . . . . . . . . . 4 64 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Brief Introduction to EAP . . . . . . . . . . . . . . . . 4 66 3.2. IEEE 802.11 Authentication using EAP over 802.1X . . . . 5 67 4. New EAP Attributes . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. APN Selection . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. Connectivity Type . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Wi-Fi to UTRAN/E-UTRAN Mobility . . . . . . . . . . . . . 7 71 4.4. MN Serial ID . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Attribute Extensions . . . . . . . . . . . . . . . . . . . . 8 73 5.1. AT_VIRTUAL_NETWORK_ID . . . . . . . . . . . . . . . . . . 8 74 5.2. AT_VIRTUAL_NETWORK_REQ . . . . . . . . . . . . . . . . . 9 75 5.3. AT_CONNECTIVITY_TYPE . . . . . . . . . . . . . . . . . . 10 76 5.4. AT_HANDOVER_INDICATION . . . . . . . . . . . . . . . . . 10 77 5.5. AT_HANDOVER_SESSION_ID . . . . . . . . . . . . . . . . . 11 78 5.6. AT_MN_SERIAL_ID . . . . . . . . . . . . . . . . . . . . . 12 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Wi-Fi has emerged as a trusted access technology for mobile service 91 providers. It has become important to provide certain functions in 92 Wi-Fi which are commonly supported in licensed-spectrum networks such 93 as 3G and 4G networks. This draft specifies a few new EAP attributes 94 for a Mobile Node (MN) to interact with the network to support some 95 of these functions (see below). These new attributes serve as a 96 trigger for network nodes to undertake the relevant mobility 97 operations. For instance, when the Mobile Node requests and the 98 network agrees for a new IP session (i.e., a new Access Point Name or 99 APN in 3GPP), the corresponding attribute (defined below) can act as 100 a trigger for the Mobile Anchor Gateway (MAG) to initiate a new 101 mobility session with the Local Mobility Anchor (LMA). This document 102 refers to [RFC6459] for the basic definitions of mobile network 103 terminology (such as APN) used here. 105 The 3rd Generation Partnership Project (3GPP) networks support many 106 functions that are not commonly implemented in a Wi-Fi network. This 107 document defines EAP attributes that enable the following functions 108 in trusted Wi-Fi access networks using EAP-AKA' [RFC5448] and EAP-AKA 109 [RFC4187]: 111 o APN Selection 113 o Multiple APN Connectivity 115 o Wi-Fi to 3G/4G (UTRAN/EUTRAN) mobility 117 Since the attributes defined here share the same IANA registry, the 118 methods are applicable to EAP-AKA', EAP-AKA, EAP-SIM [RFC4186] and, 119 with appropriate extensions, are possibly applicable for other EAP 120 methods as well. In addition to the trusted Wi-Fi access networks, 121 the attributes are applicable to any trusted "non-3GPP" access 122 network that uses the EAP methods and provides connectivity to the 123 mobile EPC, which provides connectivity for 3G, 4G, and other non- 124 3GPP access networks [EPC]. 126 1.1. APN Selection 128 The 3GPP networks support the concept of an APN (Access Point Name). 129 This is defined in [GPRS]. Each APN is an independent IP network 130 with its own set of IP services. When the MN attaches to the 131 network, it may select a specific APN to receive desired services. 132 For example, to receive generic Internet services, a user device may 133 select APN "Internet" and to receive IMS voice services, it may 134 select APN "IMSvoice". 136 In a Wi-Fi access scenario, an MN needs a way of sending the desired 137 APN name to the network. This draft specifies a new attribute to 138 propagate the APN information via EAP. 140 1.2. Multiple APN Connectivity 142 As an extension of APN Selection, an MN may choose to connect to 143 multiple IP networks simultaneously. 3GPP provides this feature via 144 additional Packet Data Protocol (PDP) contexts or additional Packet 145 Data Network (PDN) connections, and defines the corresponding set of 146 signaling procedures. In a trusted Wi-Fi network, an MN connects to 147 the first APN via DHCPv4 or IPv6 Router Solicitation. This document 148 specifies an attribute that indicates the MN's capability to support 149 multiple APN connectivity. 151 1.3. Wi-Fi to E-UTRAN mobility 153 When operating in a multi-access network, an MN may want to 154 gracefully handover its IP attachment from one access network to 155 another. For instance, an MN connected to a 3GPP E-UTRAN network may 156 choose to move its connectivity to a trusted Wi-Fi network. 157 Alternatively, the MN may choose to connect using both access 158 technologies simultaneously, and maintain two independent IP 159 attachments. To implement these scenarios, the MN needs a way to 160 correlate the UTRAN/E-UTRAN session with the new Wi-Fi session. This 161 draft specifies an attribute to propagate E-UTRAN session 162 identification to the network via EAP. This helps the network to 163 correlate the sessions between the two Radio Access Network 164 technologies and thus helps the overall handover process. 166 2. Reference Architecture and Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 3. Protocol Overview 174 3.1. Brief Introduction to EAP 176 EAP is defined as a generic protocol in [RFC3748]. EAP, combined 177 with one of the payload protocols such as EAP-AKA' [RFC5448] can 178 accomplish several things in a network: 180 o Establish identity of the user (MN) to the network. 182 o Authenticate the user during the first attach with the help of an 183 authentication center that securely maintains the user 184 credentials. This process is called EAP Authentication. 186 o Re-authenticate the user periodically, but without the overhead of 187 a round-trip to the authentication center. This process is called 188 EAP Fast Re-Authentication. 190 This draft makes use of the EAP Authentication procedure. The use of 191 EAP Fast Re-Authentication procedure is for further study. Both the 192 EAP Authentication and EAP Fast Re-Authentication procedures are 193 specified for trusted access network use in 3GPP. [TS-33.402] 195 3.2. IEEE 802.11 Authentication using EAP over 802.1X 197 In a Wi-Fi network, EAP is carried over the IEEE 802.1X 198 Authentication protocol. The IEEE 802.1X Authentication is a 199 transparent, payload-unaware mechanism to carry the authentication 200 messages between the MN and the Wi-Fi network elements. 202 EAP, on the other hand, has multiple purposes. Apart from its core 203 functions of communicating MN's credentials to the network and 204 proving the MN's identity, it also allows the MN to send arbitrary 205 information elements to help establish the MN's IP session in the 206 network. The following figure shows an example end-to-end EAP flow 207 in the context of an IEEE 802.11 Wi-Fi network. We first define the 208 terminology: 210 o MN: Mobile Node 212 o WAP: Wi-Fi Access Point 214 o WAC: Wi-Fi Access Controller. In a PMIPv6 [RFC5213] network, 215 hosts the MAG functionality or is assumed to have a suitable 216 interface to the MAG. In the following, we simply use "WAC" 217 notation. The MAG functionality within the WAC (or within the Wi- 218 Fi access network), or a suitable interface to the MAG is assumed 219 for PMIPv6 deployments. 221 o IPCN: IP Core Network. This includes the LMA function. It 222 generically also includes the AAA server function. 224 MN WAP WAC IPCN 225 (MAG) (LMA) 226 1)|<----------Beacon--------| | | 227 2)|<----------Probe-------->| | | 228 | | | | 229 | 802.11 Auth| (Open System) | | 230 3)|<----------------------->|<----------------------->| | 231 | | | | 232 | 802.11 | Association | | 233 4)|<----------------------->|<----------------------->| | 234 | | | | 235 | (802.1X) | (CAPWAP/802.1X) | | 236 5)|<----EAP Req/Identity----|<----EAP Req/Identity----| | 237 | | | | 238 6)|----EAP Resp/Identity--->|----EAP Resp/Identity--->| | 239 | | | | 240 7)|<-EAP Req/AKA-Challenge--|<-EAP Req/AKA-Challenge--| | 241 | | | | 242 8)|-EAP Resp/AKA-Challenge->|-EAP Resp/AKA-Challenge->| | 243 | | | | 244 9)|<-----EAP Success--------|<-----EAP Success--------| | 245 | | | | 246 10)|<====== 802.11 Data ====>|<=== CAPWAP(802.3 Data)=>|<=Tunnel to=>| 247 | | | core network| 248 | | | | 250 Figure 1: Example EAP Deployment 252 The figure shows separate Wi-Fi Access Point and Wi-Fi Access 253 Controller, following the split-MAC model of CAPWAP [RFC5415]. A 254 particular deployment may have the two functions within a single 255 node. 257 1. An MN detects a beacon from a WAP in the vicinity. 259 2. The MN probes the WAP to determine suitability to attach (Verify 260 SSID list, authentication type and so on). 262 3. The MN initiates the IEEE 802.11 Authentication with the Wi-Fi 263 network. In WPA/WPA2 mode, this is an open authentication 264 without any security credential verification. 266 4. The MN initiates 802.11 Association with the Wi-Fi network. 268 5. The Wi-Fi network initiates 802.1X/EAP Authentication procedures 269 by sending EAP Request/Identity. 271 6. The MN responds with its permanent or temporary identity. 273 7. The Wi-Fi network challenges the MN to prove its identity by 274 sending EAP Request/AKA-Challenge. 276 8. The MN calculates the security digest and responds with EAP 277 Response/AKA-Challenge. 279 9. If the authentication is successful, the Wi-Fi network responds 280 to the MN with EAP Success. 282 10. An end-to-End data path is available for the MN to start IP 283 layer communication (DHCPv4, IPv6 Router Solicitation and so 284 on). 286 4. New EAP Attributes 288 The following sections define the new EAP attributes and their usage. 290 4.1. APN Selection 292 In a Wi-Fi network, an MN includes the AT_VIRTUAL_NETWORK_ID 293 attribute in the EAP-Response/AKA-Challenge to indicate the desired 294 APN identity for the first PDN connection. 296 If the MN does not include the AT_VIRTUAL_NETWORK_ID attribute in the 297 EAP-Response/AKA-Challenge, the network may select an APN by other 298 means. This selection mechanism is outside the scope of this 299 document. 301 An MN includes the AT_VIRTUAL_NETWORK_REQ attribute to indicate 302 single or multiple PDN capability. In addition, a sub-type in the 303 attribute indicates IPv4, IPv6, or dual IPv4v6 PDN connectivity. 305 4.2. Connectivity Type 307 An MN indicates its preference for connectivity using the 308 AT_CONNECTIVITY_TYPE attribute in the EAP-Response/AKA-Challenge 309 message. The preference indicates whether the MN wishes connectivity 310 to the Evolved Packet Core (the so-called "EPC PDN connectivity") or 311 Internet Offload (termed as "Non-Seamless Wireless Offload"). 313 The network makes its decision and replies with the same attribute in 314 the EAP Success message. 316 4.3. Wi-Fi to UTRAN/E-UTRAN Mobility 318 When a multi-access MN enters a Wi-Fi network, the following 319 parameters are applicable in the EAP-Response/AKA-Challenge for IP 320 session continuity from UTRAN/E-UTRAN. 322 o AT_HANDOVER_INDICATION: This attribute indicates to the network 323 that the MN intends to continue the IP session from UTRAN/E-UTRAN. 324 If a previous session can be located, network will honor this 325 request by connecting the Wi-Fi access to the existing IP session. 327 o AT_HANDOVER_SESSION_ID: An MN MAY use this attribute to identify 328 the session on UTRAN/E-UTRAN. If used, this attribute contains 329 P-TMSI (Packet Temporary Mobile Subscriber Identity) if the 330 previous session was on UTRAN or M-TMSI (Mobile Temporary Mobile 331 Subscriber Identity) if the previous session was on E-UTRAN. This 332 attribute helps the network correlate the Wi-Fi session to an 333 existing UTRAN/E-UTRAN session. 335 4.4. MN Serial ID 337 The MN_SERIAL_ID attribute defines an MN's serial number, including 338 International Mobile Equipment Identity (IMEI) and International 339 Mobile Equipment Identity Software Version (IMEISV). Other formats 340 may be defined in the future. 342 5. Attribute Extensions 344 The format for the new attributes follows that in [RFC4187]. Note 345 that the Length field value is inclusive of the first two bytes. 347 5.1. AT_VIRTUAL_NETWORK_ID 349 The AT_VIRTUAL_NETWORK_ID attribute identifies the virtual IP network 350 that the MN intends to attach to. The implementation of the virtual 351 network on the core network side is technology specific. For 352 instance, in a 3GPP network, the virtual network is implemented based 353 on the 3GPP APN primitive. 355 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 356 message. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |AT_VIRTUAL | Length | Virtual Network Id | 362 | _NETWORK_ID | | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Virtual Network Id | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Figure 2: AT_VIRTUAL_NETWORK_ID EAP Attribute 370 Virtual Network Id: 372 An arbitrary octet string that identifies a virtual network in the 373 access technology MN is attaching to. For instance, in 3GPP E-UTRAN, 374 this could be an APN. See [TS-23.003] for encoding of the field. 376 5.2. AT_VIRTUAL_NETWORK_REQ 378 When an MN intends to connect an APN, it SHOULD use this attribute to 379 indicate different capabilities to the network. In turn, the network 380 provides what is supported. 382 From the MN, this attribute can be included only in EAP-Response/ 383 Identity. From the network, it SHOULD be included in the EAP 384 Request/AKA-Challenge message. In the MN-to-network direction, the 385 Type field (below) indicates the MN's request. In the network-to-MN 386 direction, the Type field indicates network's willingness to support 387 the request; a present Type value field indicates the network support 388 for that Type. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |AT_VIRTUAL_ | Length | Virt-Net-Req | Virt-Net-Req | 394 |NETWORK_REQ | | Type | Sub-type | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 3: AT_VIRTUAL_NETWORK_REQ EAP Attribute 399 Virt-Net-Req Type: 401 Type can have one of the following values: 403 o TBA IANA: Reserved 405 o TBA IANA: Single PDN connection 407 o TBA IANA : Multiple PDN connection. Can request Non-Seamless Wi- 408 Fi Offload or EPC connectivity (see the Connectivity Type 409 attribute below) 411 Virt-Net-Req Sub-type: 413 Sub-type can have one of the following values: 415 o TBA IANA : Reserved 417 o TBA IANA : PDN Type: IPv4 418 o TBA IANA : PDN Type: IPv6 420 o TBA IANA : PDN Type: IPv4v6 422 5.3. AT_CONNECTIVITY_TYPE 424 An MN uses this attribute to indicate whether it wishes the 425 connectivity type to be Non-Seamless WLAN Offload or EPC. This 426 attribute is applicable for multiple PDN connections only. 428 From the MN, this attribute can be included only in EAP-Response/ 429 Identity. From the network, it SHOULD be included in the EAP 430 Request/AKA-Challenge message. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |AT_CONNECTIVITY| Length | Connectivity | Reserved | 436 |_TYPE | | Type | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 Figure 4: AT_CONNECTIVITY_TYPE EAP Attribute 441 Connectivity Type: 443 Connectivity Type can have one of the following values: 445 o TBA IANA : Reserved 447 o TBA IANA : Non-Seamless WLAN Offload (NSWO) 449 o TBA IANA : EPC PDN connectivity 451 5.4. AT_HANDOVER_INDICATION 453 This attribute indicates an MN's handover intention of an existing IP 454 attachment. 456 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 457 message. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |AT_HANDOVER_IND| Length | Handover | Pad | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 5: AT_HANDOVER_INDICATION EAP Attribute 467 Handover Type: 469 o 0 - the MN has no intention of handing over an existing IP 470 session, i.e., the MN is requesting an independent IP session with 471 the Wi-Fi network without disrupting the IP session with the 472 UTRAN/E-UTRAN. In this case, no Session Id (Section 5.5) is 473 included. 475 o 1 - the MN intends to handover an existing IP session. In this 476 case, MN MAY include a Session Id (Section 5.5) to correlate this 477 Wi-Fi session with a UTRAN/E-UTRAN session. 479 5.5. AT_HANDOVER_SESSION_ID 481 When an MN intends to handover an earlier IP session to the current 482 access network, it may propagate a session identity that can help 483 identify the previous session from UTRAN/E-UTRAN that the MN intends 484 to handover. This attribute is defined as a generic octet string. 485 The MN MAY include an E-UTRAN GUTI if the previous session was an 486 E-UTRAN session. If the previous session was a UTRAN session, the MN 487 MAY include UTRAN Global RNC ID (MCC, MNC, RNC Id) and P-TMSI 488 concatenated as an octet string. 490 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 491 message. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |AT_HANDOVER_ | Length | Access | Reserved | 497 | SESSION_ID | | Technology | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Session Id | 500 | ... | 501 | ... | 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 6: AT_HANDOVER_SESSION_ID EAP Attribute 507 Access Technology: 509 This field represents the RAN technology from which the MN is 510 undergoing a handover. 512 o TBA IANA: Reserved 514 o TBA IANA: UTRAN 515 o TBA IANA: E-UTRAN 517 Session Id: 519 An octet string of variable length that identifies the session in the 520 source access technology. As defined at the beginning of this 521 section, the actual value is RAN technology dependent. For E-UTRAN, 522 the value is GUTI. For UTRAN, the value is Global RNC Id (6 bytes) 523 followed by P-TMSI (4 bytes). See [TS-23.003] for encoding of the 524 field. 526 5.6. AT_MN_SERIAL_ID 528 This attribute defines the MN's machine serial number. Examples are 529 International Mobile Equipment Identity (IMEI) and International 530 Mobile Equipment Identity Software Version (IMEISV). Other formats 531 may be defined in the future. 533 This attribute SHOULD be included in the EAP-Response/AKA-Challenge 534 message. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |AT_MN_ | Length | Serial ID | Reserved | 540 | SERIAL_ID | | Type | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | MN Serial Id | 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 7: AT_MN_SERIAL_ID EAP Attribute 548 Serial ID Type: 550 This field identifies the type of the MN Identifier. New values may 551 be defined in the future. 553 o TBA IANA: Reserved 555 o TBA IANA: IMEI 557 o TBA IANA: IMEISV 559 MN Serial Id 560 An arbitrary octet string that identifies the MN's machine serial 561 number. The actual value is device-specific. See [TS-23.003] for 562 encoding of the field. 564 6. Security Considerations 566 This document defines new EAP attributes to extend the capability of 567 the EAP-AKA protocol as specified in Section 8.2 of [RFC4187]. The 568 attributes are passed between an MN and a AAA server. The document 569 does not specify any new messages or options to the EAP-AKA protocol. 571 The attributes defined here are fields which are used in existing 572 trusted 3G and 4G networks, where they are exchanged (in protocols 573 specific to 3G and 4G networks) subsequent to the mobile network 574 authentication (e.g., using the UMTS-AKA mechanism). The same model 575 is followed here with the EAP-AKA (or EAP-AKA', EAP-SIM) 576 authentication; the AT_VIRTUAL_NETWORK_ID, AT_HANDOVER_INDICATION, 577 AT_HANDOVER_SESSION_ID, AT_MN_SERIAL-ID attributes MUST be processed 578 only after a successful EAP authentication. In doing so, these 579 attribute processing, security-wise, is no worse than that in 580 existing 3G and 4G mobile networks. 582 Furthermore, RFC 4187 requires attributes exchanged in EAP-Request/ 583 AKA-Identity or EAP-Response/AKA-Identity to be integrity-protected 584 with AT_CHECKCODE; see Section 8.2 in [RFC4187]. This requirement 585 applies for the AT_CONNECTIVITY_TYPE and AT_VIRTUAL_NETWORK_REQ 586 attributes defined in this document. 588 7. IANA Considerations 590 This document defines the following new skippable EAP-AKA attributes. 591 These attributes need assignments from the "EAP-AKA and EAP-SIM 592 Parameters" registry at https://www.iana.org/assignments/eapsimaka- 593 numbers/eapsimaka-numbers.xhtml 595 o AT_VIRTUAL_NETWORK_ID (Section 5.1) - TBA by IANA 597 o AT_VIRTUAL_NETWORK_REQ (Section 5.2) - TBA by IANA 599 o AT_CONNECTIVITY_TYPE (Section 5.3) - TBA IANA 601 o AT_HANDOVER_INDICATION (Section 5.4) - TBA by IANA 603 o AT_HANDOVER_SESSION_ID (Section 5.5) - TBA by IANA 605 o AT_MN_SERIAL_ID (Section 5.6) - TBA by IANA 606 This document requests a new IANA registry "Trusted non-3GPP Access 607 EAP Parameters", and requests assignments for the following fields: 609 o Virt-Net-Req Type (Section 5.2) - TBA by IANA 611 o Virt-Net-Req Sub type (Section 5.2) - TBA by IANA 613 o Connectivity Type (Section 5.3) - TBA IANA 615 o Access Technology (Section 5.5) - TBA by IANA 617 o Serial ID Type (Section 5.6) - TBA by IANA 619 8. Acknowledgment 621 Thanks to Sebastian Speicher for the review and suggesting 622 improvements. Thanks to Mark Grayson for proposing the MN Serial ID 623 attribute. And, thanks to Brian Haberman for suggesting a new 624 registry. 626 9. References 628 9.1. Normative References 630 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 631 Protocol Method for 3rd Generation Authentication and Key 632 Agreement (EAP-AKA)", RFC4187, January 2006, 633 . 635 9.2. Informative References 637 [EPC] "General Packet Radio Service (GPRS); enhancements for 638 Evolved Universal Terrestrial Radio Access Network 639 (E-UTRAN) access, 3GPP TS 23.401 8.8.0, December 2009.", , 640 . 642 [GPRS] "General Packet Radio Service (GPRS); Service description, 643 3GPP TS 23.060, December 2006", , 644 . 646 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 647 Levkowetz, Ed., "Extensible Authentication Protocol 648 (EAP)", RFC3748, June 2004, 649 . 651 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 652 Protocol Method for Global System for Mobile 653 Communications (GSM) Subscriber Identity Modules (EAP- 654 SIM)", RFC 4186, January 2006. 656 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 657 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 659 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 660 Provisioning of Wireless Access Points (CAPWAP) Protocol 661 Specification", RFC5415, January 2009, 662 . 664 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 665 Extensible Authentication Protocol Method for 3rd 666 Generation Authentication and Key Agreement (EAP-AKA')", 667 RFC 5448, May 2009. 669 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 670 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 671 Partnership Project (3GPP) Evolved Packet System (EPS)", 672 RFC 6459, January 2012. 674 [TS-23.003] 675 "3rd Generation Partnership Project: Numbering, Addressing 676 and Identification, 3GPP TS 23.003 12.2.0, March 2014.", , 677 . 679 [TS-33.402] 680 "3GPP System Architecture Evolution (SAE); Security 681 aspects of non-3GPP accesses, 3GPP TS 33.402 8.6.0, 682 December 2009.", , 683 . 685 Appendix A. Change Log 687 o: Initial Draft 689 o: v01: status to Informational, Updated References, Revised the 690 Figure 692 o: No changes from 01 to 02 694 o: Per recent 3GPP updates, added the Connectivity Type attribute 695 to allow indicating Non-Seamless WLAN Offload or EPC connectivity 696 o: version-04: Revised AT_VIRTUAL_NETWORK_REQ to include 1) single 697 PDN vs Multiple PDN connections, 2) PDN Types, and referred to 698 NSWO Connectivity Type attribute 700 o: version 05: Added AT_MN_SERIAL_ID. Revised the IANA 701 Considerations section 703 o: version 06, 07: various edits 705 o: AD review revs 707 o: version 09: IETF LC, Directorate review revs 709 Authors' Addresses 711 Ravi Valmikam 712 Unaffiliated 713 USA 715 Email: valmikam@gmail.com 717 Rajeev Koodli 718 Intel 719 USA 721 Email: rajeev.koodli@intel.com