DMM WG S. Gundavelli Internet-Draft M. Grayson Intended status: Standards Track Cisco Expires: January 12, 2023 July 11, 2022 Cryptographically Generated Device identifiers draft-gundavelli-dmm-device-identifier-00.txt Abstract Network Access Identifier (NAI) is an identifier used by access networks for identifying users requesting access to the network. A user may access the network using more than one device, but all using the same NAI and the associated credentials. There are various use- cases where an access network needs to unambiguously identify a device used for accessing the network, and NAI is not sufficient for such determination. This document describes a device identifier structure and also identifies the potential stable identifiers that are present on a dual-radio device which can be used as a device identifiers. This document also describes mechanisms where the device can generate device identifiers using cryptographic methods. These generated identifiers are transient in nature and are unique to a given access network. Device identifier is intended to be shared only with a trusted access network which holds the user's network access credentials and for which the identifier was generated. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2023. Copyright Notice Gundavelli & Grayson Expires January 12, 2023 [Page 1] Internet-Draft Device Identifiers July 2022 Copyright (c) 2022 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. CGDI Generation . . . . . . . . . . . . . . . . . . . . . . . . 6 5. CGDI Validation . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Gundavelli & Grayson Expires January 12, 2023 [Page 2] Internet-Draft Device Identifiers July 2022 1. Introduction Link-layer identifiers such as IEEE 48-bit MAC addresses, or the access specific identifiers such as 3GPP 5G IMEI/PEI are used as primary identifiers for the device. These identifiers serve as stable device identifiers. Access policies configured to these stable identifiers in the network are used for enforcing access and security policies on the associated sessions. Access networks also rely on these identifiers for correlating all the sessions initiated from a given device irrespective of the identity that is used for access authentication, or the type of radio access technology used for network connectivity. These fixed identifiers serve as stable device identifiers. With the adoption of GDRP regulations and with increased focus on privacy, these identifiers can no longer be considered as stable device identifiers. For complying to GDPR and other privacy laws, client devices now have the support for the use the randomized MAC addresses. There is no presence of a stable MAC address during Wi-Fi scans and in future even across associations. There is the general industry push to avoid the exposure of any stable identifiers (PII elements) to every access network that the device connects to as that allows traceability of the user. Furthermore, the current access architectures do not have the provisions either for the device to assert its ownership on a device identity, or for the network to validate the same. The basic notion of ownership establishment for the client on a given device identifier by mere inclusion of that identifier in the signaling messages is fundamentally a flawed approach. There must be a way for the device to assert its ownership of the claimed device identity and the network must be able to validate the same. For meeting the above stated goals, we describe a method for generating device identifiers based on cryptographic methods. The generated identifiers have certain properties: a.) Binds the device identifier to a given access network, b.) Unique to the device with the ability to assert ownership, c.) Immutable with in that network d.) The generated identifier is access-agnostic and can be signaled over any radio access technologies supported in the given access network. We refer to these identifiers based on cryprographic techniques as Cryptographically Generated Device Identifiers (CGDI). The techniques defined in this document can also be used for generating identifiers of popular formats such IMEI/PEI. Gundavelli & Grayson Expires January 12, 2023 [Page 3] Internet-Draft Device Identifiers July 2022 2. Conventions and Terminology 2.1. Conventions 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 RFC 2119 [RFC2119]. 2.2. Terminology All the mobility terms used in this document are to be interpreted as defined in the IETF and 3GPP specifications. For convenience, the definitions for some of the terms are provided below. Subscription Permanent Identifier (SUPI)) A globally unique 5G Subscription Permanent Identifier (SUPI) is allocated to each subscriber in the 5G System. The SUPI value is provisioned in USIM and UDM/UDR function in 5G Core. The structure of SUPI and its privacy is specified [TS23501] Subscription Concealed Identifier (SUCI) The Subscription Concealed Identifier (SUCI) is a privacy preserving identifier containing the concealed SUPI. The UE generates a SUCI using the public key of the Home Network provisioned to the USIM. The structure of SUCI is specified in 3GPP specification [TS33501]. Permanent Equipment Identifier (PEI) In 5G System, the Permanent Equipment Identifier (PEI) is a unique identifier of a UE accessing the private 5G System. The structure of the PEI is specified in 3GPP specification [TS23003]. International Mobile Station Equipment Identifier (IMEI) IMEI is a number that uniquely identifies a mobile device in Global System for Mobile Communications (GSM) The structure of the IMEI is specified in 3GPP specification [TS23003]. 3. Overview There are various use-cases where an access network needs to unambiguously identify a device used for accessing the network, and there are no elements that the network can rely on for such determination. 1.) A dual-radio device attached to the enterprise Gundavelli & Grayson Expires January 12, 2023 [Page 4] Internet-Draft Device Identifiers July 2022 private 5G and Wi-Fi networks will potentially use access specific identities on each of its interfaces and the network will have no ability to correlate the sessions. 2.) A user may access the network using more than one device, but all using the same NAI [RFC7542] or CUI [RFC4372] and the associated credentials and again the network will have no ability to disambiguate sessions from different devices of the same user. 3.) Use of stable identifiers such as Mac Addresses, IMEI/PEI, Serial numbers are not an option for privacy reasons. With the proposed approach a device identifier is generated by computing a hash of the public key, access network identifier, and few auxiliary parameters. The generated identifier is referred to Cryptographically Generated Device Identifiers (CGDI). The public key of the device owner is bound cryptographically to the identifier. The device can use the corresponding private key for asserting the ownership of the generated device identifier and can be signaled over any of the access networks. The access network can verify the sender is the true owner of the claimed device identifier and that the identifier has a relation to the access network. Gundavelli & Grayson Expires January 12, 2023 [Page 5] Internet-Draft Device Identifiers July 2022 _----_ _( )_ -( Internet )- (_ _) '----' | +---+ |-----------|AAA| | +---+ | Device Id (CGDI): DE01BABA4081CODE _-----_ Device Policy: Policy-1 _( )_ Wi-Fi Identity: NAI-1 -( Access )- P5G Identity: SUPI-1 -(_Net #1)- '-----' | +---------------+ | | +-----+ +-----+ |Wi-Fi| | P5G | +-----+ +-----+ . . . . . . . . . . +----+ . . Access Network: Access-Net#1 . +----| UE |-----+ . Device Id (CGDI): AB01BABA4081CODE . +----+ . Wi-Fi Identity: NAI-1 . User's: Laptop . P5G Identity: SUPI-1 (or Non-SIM Id: NAI-1) . . . +----+ . Access Network: Access-Net#1 +------| UE |-------+ Device Id (CGDI): AB02BABA4081CODE +----+ Wi-Fi Identity: NAI-1 P5G Identity: SUPI-2 (or Non-SIM Id: NAI-1) User's: Mobile Device Figure 1: Device Identifiers 4. CGDI Generation Following are the key steps involved in the CGDI generation: o The client device generates an RSA Public/Private Key pair for CGDI operation. The device computes a one-way hash on the following input parameters a.) access network identifier, b.) Public key, & c.) Additional auxiliary parameters. The hash is encrypted using the private key. Gundavelli & Grayson Expires January 12, 2023 [Page 6] Internet-Draft Device Identifiers July 2022 o The access network identifier can be Private Enterprise Number, or PLMN Id + NID, NAI Realm (xxx.mnc[MNC].mcc[MCC].3gppnetwork.org), SSID, RCOI. The auxiliary parameters can also include elements resulting from authentication procedure. o The generated identifier from the above step will result in a 64- bit identifier which will the device identifier that can be used within that access network when connected over any of the radio access technologies. The generated identifier is bound to the access network whose identity is used in the CGDI generation. o The client using the private key can always assert its ownership of this device identity when presenting the identifier to the network. o An enterprise user with multiple devices will generate a unique CGDI for each device and on an access network basis. In a variation art, the network, policy function or the IDP can also generate the device identifier and provision the corresponding private/public key parameters on the device. 5. CGDI Validation Following are the key steps involved in the CGDI validation: o The device when attached to an access network matching the network identifier associated with the CGDI, will signal the CGDI as part of the access authentication procedure, or using link-layer protocol options. The device will also include the auxiliary parameters used for the hash computation and the public key. o The network will decrypt the identifier using the public key. The resulting hash is matched against the hash the network compute using the provided auxiliary parameters and the public key. o If the match is successful and is for that network, the CGDI is bound to the session associated with that device and is tied to the session state in AAA. This will remain as a stable device identifier in the network for that device. o Any time the device initiates a second connection over a different radio access, the CGDI will be validated again, and the associated sessions are correlated. Gundavelli & Grayson Expires January 12, 2023 [Page 7] Internet-Draft Device Identifiers July 2022 6. IANA Considerations This document does not requires any IANA actions. 7. Security Considerations Device identifier is considered to be a personally identifiable information (PII) element. An attacker having access to the device identifier in most cases will be able to identify the user of the device, and the home affiliation of the user. Presence of the device in a given location served by a network can also imply the presence of the user of that device in the same location and at the same time. Just as how network access identifier [RFC7542] can be used by an attacker for probing the user name space, device identifier can also assist the attacker with the same attack. In general, all of the attack vectors that are possible with the exposure of NAI are also possible with the exposure of device identifier. In order to avoid this identity leakage, care must be taken to ensure the exchange of the device identitifier must be limited to trusted network elements that the client has an established trust relation. A client may share the device identifier with a trusted access network that holds the client's access credentials and must avoid sharing the same with any hotspot providing internet services. The device identifier must not be passed in clear text in network protocols. When the device identifier is carried in network protocols, it must be protected using the confidentiality services provided by those respective protocols, or by the transport protocols. A rogue or a compromised device may present the device identifiers of some other device to the access network. The access network must challenge the device to assert the ownership on the device identity. An access network must always associate the device identity to the validated access network credentials. This minimizes the threat surface. 8. Acknowledgements TBD 9. References Gundavelli & Grayson Expires January 12, 2023 [Page 8] Internet-Draft Device Identifiers July 2022 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, DOI 10.17487/ RFC4372, January 2006, . [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, . 9.2. Informative References [TS23003] 3GPP, "Numbering, addressing and identification", 2021. [TS23501] 3GPP, "Numbering, addressing and identification", 2021. [TS33501] 3GPP, "Architecture enhancements for non-3GPP accesses", 2021. Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Mark Grayson Cisco 11 New Square Park Bedfont Lakes, Feltham TW14 8HA England Email: mgrayson@cisco.com Gundavelli & Grayson Expires January 12, 2023 [Page 9]