Internet DRAFT - draft-gundavelli-dmm-device-identifier
draft-gundavelli-dmm-device-identifier
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, DOI 10.17487/
RFC4372, January 2006,
<https://www.rfc-editor.org/info/rfc4372>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
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]
