RFC 7458

Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core

📅 published February 2015, from ietf

RFC 7458 at a glance 💖

Okay so bestie, this is RFC 7458, titled "Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core" 🎀 It came out in February 2015 and it's Informational, so it's not a Standards Track spec 🦋

The authors are R. Valmikam (Unaffiliated) and R. Koodli (Intel) 👑 The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there ✨

Abstract ✨

Okay so Wi-Fi is literally becoming a huge access network for mobile service providers 🌈 That means it's now important to bring the stuff 3G and 4G networks already do over to Wi-Fi too 🔥 We're talking Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks 💅

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to reach the mobile Evolved Packet Core (EPC) through Wi-Fi networks 🦋 This doc defines a few new EAP attributes that make all of the above possible in these networks ✨ The attributes get passed between a client (like a Mobile Node (MN)) and its network buddy (like an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure 🫶

Status of This Memo

Here's the tea: this document is not an Internet Standards Track specification 🎀 It's just published for informational purposes 💜

This doc is a product of the Internet Engineering Task Force (IETF) 👑 It represents the consensus of the IETF community and got public review, then was approved for publication by the Internet Engineering Steering Group (IESG) 🔥 Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for that 🙈

If you want the latest status, errata, or a way to give feedback, head to http://www.rfc-editor.org/info/rfc7458 🌸

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication 🧚 Please read these carefully, because they spell out your rights and restrictions 💅 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⭐

Table of Contents

1. Introduction ....................................................3
   1.1. APN Selection ..............................................4
   1.2. Multiple APN Connectivity ..................................4
   1.3. Wi-Fi to E-UTRAN Mobility ..................................4
2. Terminology .....................................................4
3. Protocol Overview ...............................................5
   3.1. Brief Introduction to EAP ..................................5
   3.2. IEEE 802.11 Authentication Using EAP over 802.1X ...........5
4. New EAP Attributes ..............................................7
   4.1. APN Selection ..............................................7
   4.2. Connectivity Type ..........................................7
   4.3. Wi-Fi to UTRAN/E-UTRAN Mobility ............................8
   4.4. MN Serial ID ...............................................8
5. Attribute Extensions ............................................8
   5.1. AT_VIRTUAL_NETWORK_ID ......................................8
   5.2. AT_VIRTUAL_NETWORK_REQ .....................................9
   5.3. AT_CONNECTIVITY_TYPE ......................................10
   5.4. AT_HANDOVER_INDICATION ....................................11
   5.5. AT_HANDOVER_SESSION_ID ....................................11
   5.6. AT_MN_SERIAL_ID ...........................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................14
8. References .....................................................15
   8.1. Normative References ......................................15
   8.2. Informative References ....................................16
Acknowledgments ...................................................18
Authors' Addresses ................................................18

1. Introduction 🌸

Wi-Fi has become a "trusted" access technology for mobile service providers 🦋 See [EPC2] for the 3rd Generation Partnership Project (3GPP) description of "trusted" access 💜 Advances in IEEE 802.11u [IEEE802.11u] and "HotSpot 2.0" [hs20] have enabled seamless roaming, so a Mobile Node can pick and connect to a Wi-Fi access network just like it would roam into a cellular network 🔥 That makes it important to bring certain functions to Wi-Fi that are commonly supported in licensed-spectrum networks like 3G and 4G 💅 This document specifies a few new EAP attributes so an MN can interact with the network to support some of these functions (more on that below) ✨

These new attributes act as a trigger for Proxy Mobile IPv6 network nodes to do the relevant mobility operations 🧚 For example, when the MN requests a new IP session (a new APN in 3GPP) and the network agrees, the matching attribute triggers the Mobile Anchor Gateway (MAG) to start a new mobility session with the Local Mobility Anchor (LMA) 🎀 This document refers to [RFC6459] for the basic definitions of mobile network terminology (like APN) 💖

The 3GPP networks support lots of functions that aren't commonly implemented in Wi-Fi networks 🙈 This document defines EAP attributes that enable the following functions in Wi-Fi access networks using EAP-AKA [RFC4187] and EAP-AKA' [RFC5448]:

  • APN Selection
  • Multiple APN Connectivity
  • Wi-Fi to 3G/4G (Universal Terrestrial Radio Access Network (UTRAN) / Evolved UTRAN (E-UTRAN)) mobility

The attributes are exchanged between the MN and the EAP server, which is usually part of the AAA server infrastructure in a service provider's network 🫶 The Wi-Fi access network basically just passes the attributes along to the service provider's core network, where the EAP processing happens [EPC] 🌈 Since these attributes share the same IANA registry, the methods work for EAP-AKA, EAP-AKA', and EAP Subscriber Identity Modules (EAP-SIM) [RFC4186], and with appropriate extensions they might also work for other EAP methods 👑 Beyond trusted Wi-Fi access networks, the attributes also apply to any trusted "non-3GPP" access network that uses the EAP methods and connects to the mobile EPC, which serves 3G, 4G, and other non-3GPP access networks [EPC2] ✨

1.1. APN Selection 🎀

The 3GPP networks support the concept of an APN, defined in [GPRS] 💜 Each APN is its own independent IP network with its own set of IP services 🦋 When the MN attaches, it may select a specific APN to get the services it wants 💅 For example, a user device might select the APN "Internet" for generic Internet services, or the APN "IMSvoice" for IP Multimedia Subsystems (IMS) voice services 🔥

In a Wi-Fi access scenario, the MN needs a way to send the desired APN name to the network 🧚 This document specifies a new attribute that carries the APN information over EAP 💖 The agreed APN is necessary for the Proxy Mobile IPv6 MAG to start a new session with the LMA ⭐

1.2. Multiple APN Connectivity 🌸

Multiple APN connectivity is like an extension of APN Selection, because an MN may choose to connect to multiple IP networks at the same time 🙈 3GPP offers this via additional Packet Data Protocol (PDP) contexts or additional Packet Data Network (PDN) connections, and it defines the matching set of signaling procedures 💅 In a trusted Wi-Fi network, an MN connects to the first APN through DHCPv4 or IPv6 Router Solicitation 🫶 This document specifies an attribute that indicates the MN's capability to support multiple APN connectivity 🌈 The specific connectivity types are also necessary for the Proxy Mobile IPv6 signaling 👑

1.3. Wi-Fi to E-UTRAN Mobility 🦋

When operating in a multiaccess network, an MN may want to gracefully hand over its IP attachment from one access network to another 🔥 For instance, an MN connected to a 3GPP E-UTRAN network may choose to move its connectivity to a trusted Wi-Fi network 🧚 Or, the MN may choose to use both access technologies at once and keep two independent IP attachments 💜 To make these scenarios work, the MN needs a way to correlate the UTRAN/E-UTRAN session with the new Wi-Fi session ✨ This document specifies an attribute that carries the E-UTRAN session identification to the network via EAP 🎀 That helps the network correlate the sessions between the two Radio Access Network (RAN) technologies, which makes the overall handover process smoother 💖

2. Terminology 💅

Here are the capital-letter key words we need to know 🌈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶

3. Protocol Overview 🧚

3.1. Brief Introduction to EAP ✨

EAP is defined as a generic protocol in [RFC3748] 🎀 EAP, combined with one of the payload protocols such as EAP-AKA' [RFC5448], can do several things in a network 💜

  • Establish the identity of the user (MN) to the network.
  • Authenticate the user during the first attach with the help of an authentication center that securely keeps the user credentials. This process is called "EAP Authentication".
  • Re-authenticate the user periodically, but without the overhead of a round-trip to the authentication center. This process is called "EAP Fast Re-Authentication".

This document makes use of the EAP Authentication procedure 🦋 The EAP Fast Re-Authentication procedure is for further study 🔥 Both the EAP Authentication and EAP Fast Re-Authentication procedures are specified for trusted access network use in 3GPP[TS-33.402] 💖

3.2. IEEE 802.11 Authentication Using EAP over 802.1X ✨

okay so in a Wi-Fi network, EAP rides on top of IEEE 802.1X Authentication 🫶. 802.1X is basically a transparent, payload-unaware courier. It carries the auth messages between the MN and the Wi-Fi network elements and doesn't care what's inside 📦.

EAP, though? It's giving multitasker 💅. Its core jobs are sharing an MN's credentials with the network and proving who the MN is, but it also lets the MN send arbitrary information elements to help set up its IP session 🦋. Figure 1 shows an end-to-end EAP flow in an IEEE 802.11 Wi-Fi network. First, the terminology 📝:

  • MN: Mobile Node
  • WAN: Wi-Fi Access Node, typically made of a Wi-Fi Access Point and a Wi-Fi Controller. CAPWAP [RFC5415] lets these functions live on separate physical nodes or on one single node 🧚. In a Proxy Mobile IPv6 (PMIPv6) [RFC5213] network, the MAG functionality sits in the WAN, either in the Wi-Fi Access Point or the Wi-Fi Controller.
  • AAA: The infrastructure node that hosts the AAA server with the EAP methods (AKA, AKA', EAP-SIM). The endpoints of the EAP method are the MN and the AAA server 👑.
  • IPCN: IP Core Network. This includes the PMIPv6 LMA function 🌈.
  MN                        WAN                        AAA         IPCN
                           (MAG)                                   (LMA)
  1)|<----------Beacon--------|                         |             |
  2)|<----------Probe-------->|                         |             |
    |                         |                         |             |
    |              802.11 Auth|                         |             |
  3)|<----------------------->|                         |             |
    |                         |                         |             |
    |       802.11 Association|                         |             |
  4)|<----------------------->|                         |             |
    |                         |                         |             |
  5)|<----EAP Req/Identity----|                         |             |
    |                         |                         |             |
  6)|----EAP Resp/Identity----|->--EAP Resp/Identity--->|             |
    |                         |                         |             |
  7)|<-EAP Req/AKA-Challenge<-|--EAP Req/AKA-Challenge--|             |
    |                         |                         |             |
  8)|-EAP Resp/AKA-Challenge--|>EAP Resp/AKA-Challenge->|             |
    |                         |                         |             |
  9)|<-----EAP Success------<-|------EAP Success--------|             |
    |                         |                         |             |
 10)|<====== 802.11 Data ====>|<========== 802.11 Data ====Tunnel to=>|
    |                         |                         | core network|
    |                         |                         |             |

Figure 1: Example EAP Deployment 🎀

  1. An MN spots a beacon from a WAP nearby 📡.
  2. The MN probes the WAP to check if it's a good match to attach to (verify the Service Set Identifier (SSID) list, authentication type, and so on) 🔍.
  3. The MN kicks off IEEE 802.11 Authentication with the Wi-Fi network. In Wi-Fi Protected Access (WPA) / WPA2 mode, this is open authentication, so there's no security credential verification happening here 🙈.
  4. The MN starts 802.11 Association with the Wi-Fi network.
  5. The Wi-Fi network starts the 802.1X/EAP Authentication by sending EAP Request/Identity.
  6. The MN replies with its permanent or temporary identity.
  7. The Wi-Fi network challenges the MN to prove its identity by sending EAP Request/AKA-Challenge 💅.
  8. The MN works out the security digest and responds with EAP Response/AKA-Challenge.
  9. If authentication succeeds, the Wi-Fi network sends EAP Success to the MN ✨.
  10. An end-to-end data path is ready, so the MN can start IP layer communication (DHCPv4, IPv6 Router Solicitation, and so on) 🚀.

4. New EAP Attributes 🌸

the following subsections define the new EAP attributes and how to use them 💖.

4.1. APN Selection

in a Wi-Fi network, an MN puts the AT_VIRTUAL_NETWORK_ID attribute in the EAP-Response/AKA-Challenge to say which APN it wants for the first PDN connection 🎯.

if the MN doesn't include AT_VIRTUAL_NETWORK_ID in the EAP-Response/AKA-Challenge, the network might pick an APN some other way. that selection mechanism is outside the scope of this document 🤷‍♀️.

an MN includes the AT_VIRTUAL_NETWORK_REQ attribute to show whether it can do single or multiple PDN capability. plus, a Sub type in that attribute says whether it wants IPv4, IPv6, or dual IPv4v6 PDN connectivity 🌈.

4.2. Connectivity Type

an MN shares its connectivity preference using the AT_CONNECTIVITY_TYPE attribute in the EAP-Response/AKA-Challenge message 💜. the preference tells the network whether the MN wants the Evolved Packet Core ("EPC PDN connectivity") or Internet Offload (called "Non-Seamless Wireless Offload") 🍓.

the network makes the call and replies with the same attribute in the EAP Success message 👑.

4.3. Wi-Fi to UTRAN/E-UTRAN Mobility

when a multiaccess MN walks into a Wi-Fi network, these parameters apply in the EAP-Response/AKA-Challenge so the IP session can continue from UTRAN/E-UTRAN 🦋.

  • AT_HANDOVER_INDICATION: this attribute tells the network that the MN plans to continue the IP session from UTRAN/E-UTRAN. if a previous session can be found, the network will honor the request by hooking the Wi-Fi access up to the existing IP session 🔥.
  • AT_HANDOVER_SESSION_ID: an MN MAY use this attribute to identify the session on UTRAN/E-UTRAN. if it's used, the attribute carries the Packet Temporary Mobile Subscriber Identity (P-TMSI) when the previous session was on UTRAN. if the previous session was on E-UTRAN, it carries the Mobile Temporary Mobile Subscriber Identity (M-TMSI). this helps the network match the Wi-Fi session to an existing UTRAN/E-UTRAN session 🧚.

4.4. MN Serial ID

the MN_SERIAL_ID attribute carries an MN's serial number, which covers the International Mobile Equipment Identity (IMEI) and the International Mobile Equipment Identity Software Version (IMEISV) 📱. the IMEI (or IMEISV) is used to make sure a legit device is in use and not a stolen one 🚨. like the others, this attribute gets exchanged with the service provider's AAA server. the AAA server MUST NOT pass MN_SERIAL_ID on to any other node 🔒.

The MN_SERIAL_ID attribute is sensitive, so the AAA server MUST NOT propagate it beyond itself. Please don't forward it, bestie 💀.

5. Attribute Extensions 🎀

the new attributes follow the format in [RFC4187]. heads up that the Length field value includes the first two bytes 📏.

5.1. AT_VIRTUAL_NETWORK_ID

the AT_VIRTUAL_NETWORK_ID attribute identifies the virtual IP network the MN wants to attach to 🌐. how the virtual network is implemented on the core network side depends on the technology. for example, in a 3GPP network, the virtual network is built on the 3GPP APN primitive 💅.

this attribute SHOULD be included in the EAP-Response/AKA-Challenge message 💖.

      0                   1                   2                   3
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AT_VIRTUAL     | Length        | Virtual Network Id            |
      |  _NETWORK_ID  |               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Virtual Network Id                           |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: AT_VIRTUAL_NETWORK_ID EAP Attribute ✨

Virtual Network Id:

an arbitrary octet string that identifies a virtual network in the access technology the MN is attaching to 🧚. for example, in 3GPP E-UTRAN, this could be an APN. see [TS-23.003] for how to encode the field 📖.

5.2. AT_VIRTUAL_NETWORK_REQ

when an MN wants to connect to an APN, it SHOULD use this attribute to ask for different capabilities from the network 🙋‍♀️. in return, the network provides whatever it supports 🫶.

from the MN, this attribute can only be included in EAP-Response/Identity. from the network, it SHOULD be included in the EAP Request/AKA-Challenge message 🔥. in the MN-to-network direction, the Type field (below) shows what the MN is requesting. in the network-to-MN direction, the Type field shows the network's willingness to support the request. a Type field value that shows up means the network supports that Type 💜.

      0                   1                   2                   3
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AT_VIRTUAL_    |     Length    |  Virt-Net-Req | Virt-Net-Req  |
      |NETWORK_REQ    |               |     Type      |   Sub type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: AT_VIRTUAL_NETWORK_REQ EAP Attribute 🌸

Virt-Net-Req Type:

Type can be one of these values 📋:

  • 0: Reserved
  • 1: Single PDN connection
  • 2: Multiple PDN connection. Can request Non-Seamless Wi-Fi Offload or EPC connectivity (see the Connectivity Type attribute below)

Virt-Net-Req Sub type:

Sub type can be one of these values 🌈:

  • 0: Reserved
  • 1: PDN Type: IPv4
  • 2: PDN Type: IPv6
  • 3: PDN Type: IPv4v6

5.3. AT_CONNECTIVITY_TYPE

an MN uses this attribute to say whether it wants the connectivity type to be Non-Seamless WLAN Offload or EPC 🍓. this attribute only applies to multiple PDN connections 🫶.

from the MN, this attribute can only be included in EAP-Response/Identity. from the network, it SHOULD be included in the EAP Request/AKA-Challenge message 💅.

      0                   1                   2                   3
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AT_CONNECTIVITY|     Length    | Connectivity  | Reserved      |
      |_TYPE          |               | Type          |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: AT_CONNECTIVITY_TYPE EAP Attribute 💖

Connectivity Type:

Connectivity Type can be one of these values 🧚:

  • 0: Reserved
  • 1: Non-Seamless WLAN Offload (NSWO)
  • 2: EPC PDN connectivity

5.4. AT_HANDOVER_INDICATION 🦋

Okay so this attribute is how an MN says "hey, I'm thinking about handing over an IP attachment I already have" 🫶 It's the handover intention, bestie. So this attribute SHOULD be included in the EAP-Response/AKA-Challenge message 💅

      0                   1                   2                   3
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AT_HANDOVER_IND|     Length    | Handover      |   Pad         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: AT_HANDOVER_INDICATION EAP Attribute

Handover Type:

  • 0: The MN has zero plans to hand over an existing IP session 🙅 It wants an independent IP session with the Wi-Fi network, and the IP session on UTRAN/E-UTRAN just keeps going without being disrupted ✨ In this case, no Session Id (Section 5.5) is included.
  • 1: The MN intends to hand over an existing IP session 🦋 In this case, MN MAY include a Session Id (Section 5.5) to correlate this Wi-Fi session with a UTRAN/E-UTRAN session.

5.5. AT_HANDOVER_SESSION_ID 🎀

So when an MN wants to hand over an earlier IP session to the current access network, it may propagate a session identity 🧚 that helps identify the previous session from UTRAN/E-UTRAN. This attribute is defined as a generic octet string 💜 The MN MAY include an E-UTRAN Globally Unique Temporary User Equipment Identity (GUTI) if the previous session was an E-UTRAN session. If the previous session was a UTRAN session, the MN MAY include a UTRAN Global Radio Network Controller (RNC) ID (Mobile Country Code (MCC), Mobile Network Code (MNC), RNC ID) and P-TMSI concatenated as an octet string.

This attribute SHOULD be included in the EAP-Response/AKA-Challenge message.

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_HANDOVER_   |   Length      |  Access       |  Reserved     |
   |  SESSION_ID   |               |  Technology   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Session Id                          |
   |                              ...                              |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: AT_HANDOVER_SESSION_ID EAP Attribute

Access Technology:

This field represents the RAN technology from which the MN is undergoing a handover.

  • 0: Reserved
  • 1: UTRAN
  • 2: E-UTRAN

Session Id:

This is an octet string of variable length that identifies the session in the source access technology. As defined at the beginning of this section, the actual value is RAN technology dependent. For E-UTRAN, the value is GUTI. For UTRAN, the value is Global RNC ID (6 bytes) followed by P-TMSI (4 bytes). See [TS-23.003] for encoding of the field.

5.6. AT_MN_SERIAL_ID 🔥

This attribute defines the MN's machine serial number. Examples are IMEI and IMEISV.

A network that requires the machine serial number for authorization purposes MUST send a request for the attribute in an EAP-Request/AKA-Challenge message. If the attribute is present, the MN SHOULD include the attribute in the EAP-Response/AKA-Challenge message. If the MN sends the attribute, it MUST be contained within an AT_ENCR_DATA attribute. An MN MUST NOT provide the attribute unless it receives the request from a network authenticated via EAP/AKA. 🔐

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |AT_MN_         |   Length      |  Serial ID    |  Reserved     |
   |  SERIAL_ID    |               |    Type       |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MN Serial Id                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: AT_MN_SERIAL_ID EAP Attribute

Serial ID Type:

This field identifies the type of the MN Identifier.

  • 0: Reserved
  • 1: IMEI
  • 2: IMEISV

MN Serial Id:

This is an arbitrary octet string that identifies the MN's machine serial number. The actual value is device specific. See [TS-23.003] for encoding of the field. When sent by the network in the EAP-Request/AKA-Challenge message, this field is not present, which serves as an indication for the MN to provide the attribute in the EAP-Response/AKA-Challenge message.

An AT_MN_SERIAL_ID attribute MUST only be used with methods that can provide mutual (network and device) authentication, such as AKA, AKA', and EAP-SIM.

6. Security Considerations 👑

This document defines new EAP attributes to extend the capability of the EAP-AKA protocol as specified in Section 8.2 of [RFC4187]. The attributes are passed between an MN and a AAA server in provider-controlled, trusted Wi-Fi networks, where the Wi-Fi access network is a relay between the MN and the AAA server. The document does not specify any new messages or options to the EAP-AKA protocol.

The attributes defined here are fields that are used in existing 3G and 4G networks, where they are exchanged (in protocols specific to 3G and 4G networks) subsequent to the mobile network authentication (e.g., using the UMTS-AKA mechanism). For the operator-controlled Wi-Fi access that is connected to the same core infrastructure as the 3G and 4G access, a similar model is followed here with the EAP-AKA (or EAP-AKA', EAP-SIM) authentication. In doing so, processing these attributes, security-wise, is no worse than that in existing 3G and 4G mobile networks. 🌸

The attributes inherit the security protection (integrity, replay, and confidentiality) provided by the parameters in the AKA(') or SIM methods; see Section 12.6 in [RFC4187]. Furthermore, RFC 4187 requires attributes exchanged in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity to be integrity-protected with AT_CHECKCODE; see Section 8.2 in [RFC4187]. This requirement applies to the AT_CONNECTIVITY_TYPE and AT_VIRTUAL_NETWORK_REQ attributes defined in this document.

The AT_MN_SERIAL_ID attribute MUST have confidentiality protection provided by the AKA(') or EAP-SIM methods beyond the secure transport (such as private leased lines, VPN, etc.) deployed by the provider of the trusted Wi-Fi service. 🚨

Use of identifiers such as IMEI could have privacy implications, wherein devices can be profiled and tracked. With additional information, this could also lead to profiling of user's network access patterns. Implementers should consult [hotos-2011], and the references therein, for a broader discussion and possible mitigation methods on the subject. 💀

7. IANA Considerations 🌈

This document defines the following new skippable EAP-AKA attributes. These attributes have been assigned from the "EAP-AKA and EAP-SIM Parameters" registry at https://www.iana.org/assignments/eapsimaka-numbers.

  • AT_VIRTUAL_NETWORK_ID (Section 5.1): 145
  • AT_VIRTUAL_NETWORK_REQ (Section 5.2): 146
  • AT_CONNECTIVITY_TYPE (Section 5.3): 147
  • AT_HANDOVER_INDICATION (Section 5.4): 148
  • AT_HANDOVER_SESSION_ID (Section 5.5): 149
  • AT_MN_SERIAL_ID (Section 5.6): 150

A new IANA registry titled "Trusted Non-3GPP Access EAP Parameters" has been created. The range for both Types and Sub types in the registry is 0 - 127, with 0 (zero) being a reserved value. IANA has made assignments in a monotonically increasing order in increments of 1, starting from 1. New assignments in this registry are made with the Specification Required policy [RFC5226].

The IANA Designated Expert should review the requirements for new assignments based on factors including, but not limited to, the source of request (e.g., standards bodies), deployment needs (e.g., industry consortium, operator community), and experimental needs (e.g., academia, industrial labs). A document outlining the purpose of new assignments should accompany the request. Such a document could be a standards document or a research project description. The Designated Expert should consider that there is sufficient evidence of potential usage both on the endpoints (e.g., Mobile Devices, etc.) and the infrastructure (e.g., AAA servers, gateways, etc.)

The following fields have been assigned:

  • Virt-Net-Req Type (Section 5.2): 1
  • Virt-Net-Req Sub type (Section 5.2): 2
  • Connectivity Type (Section 5.3): 3
  • Access Technology (Section 5.5): 4
  • Serial ID Type (Section 5.6): 5

8. References 📚

8.1. Normative References 💖

8.2. Informative References 📚

okay bestie, here's the extra reading list 🫶 these are the docs the spec points to for background, and they're all in one block so you can copy the exact details 💅

[EPC]      3GPP, "General Packet Radio Service (GPRS); enhancements
           for Evolved Universal Terrestrial Radio Access Network
           (E-UTRAN) access", TS 23.401 8.8.0, December 2009,
           <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.

[EPC2]     3GPP, "Architecture enhancements for non-3GPP accesses",
           TS 23.402 8.8.0, December 2009,
           <http://www.3gpp.org/ftp/Specs/html-info/23402.htm>.

[GPRS]     3GPP, "General Packet Radio Service (GPRS); Service
           description, Stage 2", TS 23.060, December 2006,
           <http://www.3gpp.org/ftp/Specs/html-info/23060.htm>.

[IEEE802.11u]
           IEEE, "IEEE Standard for Information Technology-
           Telecommunications and information exchange between
           systems-Local and Metropolitan networks-specific
           requirements-Part II: Wireless LAN Medium Access Control
           (MAC) and Physical Layer (PHY) specifications: Amendment
           9: Interworking with External Networks", IEEE Std 802.11u-
           2011, February 2011, <http://standards.ieee.org/findstds/
           standard/802.11u-2011.html>.

[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, Ed., "Extensible Authentication Protocol
           (EAP)", RFC3748, June 2004,
           <http://www.rfc-editor.org/info/rfc3748.txt>.

[RFC4186]  Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
           Authentication Protocol Method for Global System for
           Mobile Communications (GSM) Subscriber Identity Modules
           (EAP-SIM)", RFC 4186, January 2006,
           <http://www.rfc-editor.org/info/rfc4186>.

[RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
           Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC
           5213, August 2008,
           <http://www.rfc-editor.org/info/rfc5213>.

[RFC5415]  Calhoun, P., Montemurro, M., and D. Stanley, "Control And
           Provisioning of Wireless Access Points (CAPWAP) Protocol
           Specification", RFC5415, January 2009,
           <http://www.rfc-editor.org/info/rfc5415.txt>.

[RFC5448]  Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
           Extensible Authentication Protocol Method for 3rd
           Generation Authentication and Key Agreement (EAP-AKA')",
           RFC 5448, May 2009,
           <http://www.rfc-editor.org/info/rfc5448>.

[TS-23.003]
           3GPP, "Numbering, addressing and identification", TS
           23.003 12.2.0, March 2014,
           <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.

[TS-33.402]
           3GPP, "3GPP System Architecture Evolution (SAE); Security
           aspects of non-3GPP accesses", TS 33.402 8.6.0, December
           2009, <http://www.3gpp.org/ftp/Specs/html-info/33402.htm>.

[hotos-2011]
           Wetherall, et al., D., "Privacy Revelations for Web and
           Mobile Apps", Proceedings of the Hot Topics in Operating
           Systems (HotOS), May 2011,
           <https://www.usenix.org/legacy/events/hotos11/tech/>.

[hs20]     "Hotspot 2.0 (Release 2) Technical Specification Package
           v1.0.0", <https://www.wi-fi.org/hotspot-20-release-2-
           technical-specification-package-v100>.

Acknowledgments ✨

big thank-you energy 💖 to Sebastian Speicher for the review and for suggesting improvements 🙌 and to Mark Grayson for proposing the MN Serial ID attribute 🧚 plus Brian Haberman for suggesting a new registry 🌸 the whole crew is iconic fr fr

Authors' Addresses 🎀

Here are the people who wrote this one, with their contact details, all in one block so nothing gets mixed up 🦋

Ravi Valmikam
Unaffiliated
United States

EMail: valmikam@gmail.com


Rajeev Koodli
Intel
United States

EMail: rajeev.koodli@intel.com
📦 where this page comes from