A Uniform Resource Name
Namespace
for the Global System for Mobile Communications Association (GSMA)
and the International Mobile station Equipment Identity (IMEI)Blackberry4701 Tahoe Dr.MississaugaL4W 0B4OntarioCanada mmontemurro@blackberry.com Blackberry1200 Sawgrass Corporate ParkwaySunrise33323FloridaUSAaallen@blackberry.comEircomDavid.McDonald@meteor.ieGSM Association1st Floor, Mid City Place, 71 High Holborn London Englandpgosden@gsma.com
Internet Area
Network Working Group GSM, UMTS, LTE, 3GPP, Mobile, identifier, instance IDThis specification defines a Uniform Resource Name (URN)
namespace for the Global System for Mobile Communications
Association (GSMA) and a Namespace Specific String (NSS) for the
International Mobile station Equipment Identity (IMEI), as well as an
associated parameter for the International Mobile station Equipment
Identity and Software Version number (IMEISV). The IMEI and IMEISV
were introduced as part of the specification for the GSM and are
also now incorporated by the 3rd Generation Partnership Project
(3GPP) as part of the 3GPP specification for GSM, Universal Mobile
Telecommunications System (UMTS), and 3GPP Long Term Evolution
(LTE) networks. The IMEI and IMEISV are used to uniquely identify
Mobile Equipment within these systems and are managed by the GSMA.
URNs from this namespace almost always contain personally
identifiable information and need to be treated accordingly.This specification defines a Uniform Resource Name (URN)
namespace for the Global System for Mobile Communications Association (GSMA)
and a Namespace Specific String (NSS) for the International Mobile station
Equipment Identity (IMEI), as well as an associated parameter for the
International Mobile station Equipment Identity and Software Version number
(IMEISV) as per the namespace registration requirement found in
RFC 3406 . The Namespace Identifier (NID) 'gsma'
is for identities used in GSM, Universal Mobile Telecommunications System
(UMTS), and Long Term Evolution (LTE) networks. The IMEI and the IMEISV are
managed by the GSMA, so this NID is managed by the GSMA. While this
specification currently defines only the 'imei' NSS under the 'gsma' NID,
additional NSS under the 'gsma' NID may be specified in the future by the
GSMA, using the procedure for URN NSS changes and additions (currently
through the publication of future Informational RFCs approved by IETF
consensus).The IMEI is 15 decimal digits long and includes a Type Allocation Code
(TAC) of 8 decimal digits and a Serial Number (SNR) of 6 decimal digits
plus a Spare decimal digit. The TAC identifies the type of the Mobile
Equipment and is chosen from a range of values allocated to the Mobile
Equipment manufacturer in order to uniquely identify the model of the Mobile
Equipment. The SNR is an individual serial number that uniquely identifies
each Mobile Equipment device within the TAC. The Spare digit is used as a
Check digit to validate the IMEI and is always set to the value 0 when
transmitted by the Mobile Equipment.The IMEISV is 16 decimal digits long and includes the TAC and SNR, same as for
the IMEI, but also includes a 2 decimal digit Software Version Number (SVN),
which is allocated by the Mobile Equipment manufacturer to identify the software
version of the Mobile Equipment.The information here is meant to be a concise guide for
those wishing to use the IMEI and IMEISV as URNs. Nothing in this document
should be construed to override 3GPP Technical Specification (TS)
23.003 , which specifies the IMEI
and IMEISV.The GSMA is a global trade association representing
nearly 800 mobile phone operators across 220 territories and
countries of the world. The primary goals of the GSMA are to ensure that
mobile phones and wireless services work globally and are easily accessible.
Further details about the GSMA's role in allocating the IMEI and the IMEISV,
as well as the IMEI and IMEISV allocation guidelines, can be found in
GSMA Permanent Reference Document (PRD) TS.06 . 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 . 'gsma' 1 2014-01-12 GSM Association 1st Floor, Mid City Place, 71 High Holborn, London, England Paul Gosden pgosden@gsma.comThe identifier is expressed in American Standard Code
for Information Interchange (ASCII) characters and has a
hierarchical structure expressed using the Augmented
Backus-Naur Form (ABNF) defined in
RFC 5234 , as follows:
An NSS for the IMEI is defined under the 'gsma' NID. An IMEI is an identifier under the 'gsma' NID that
uniquely identifies the mobile devices
used in the GSM, UMTS, and LTE networks.The representation of the IMEI is defined in 3GPP TS 23.003 . To accurately
represent an IMEI received in a cellular signaling message (see 3GPP TS 24.008
) as a URN, it is necessary to convert the
received binary (Binary Coded Decimal (BCD)) encoded bit sequence to a decimal
digit string representation. Each field has its representation for humans as
a decimal digit string with the most significant digit first.
The following ABNF includes the set of core rules in
RFC 5234 ; the core rules are not repeated here. A URN with the 'imei' NSS contains one 'imeival',
and its formal definition is provided by the following ABNF
(RFC 5234) :
tac "-" snr "-" spare<future-gsma-specifier> and <gsma-defined-nonempty>
can comprise any ASCII characters compliant with the above ABNF.
The GSMA will take responsibility for the 'gsma' namespace,
including the 'imei' NSS.Additional NSS may be added for future identifiers needed by
the GSMA, at their discretion. Only URNs with the 'imei' NSS are
considered to be "GSMA IMEI URNs", and use in IETF protocols of
other NSS that might be defined in the future will require
IETF consensus. See IMEI Allocation and Approval Guidelines
(GSMA PRD TS.06) and
3GPP TS 23.003 .Identifiers under the 'gsma' NID are defined and assigned
by the GSMA after ensuring that the URNs
to be assigned are unique. Uniqueness is achieved by checking
against the IANA registry of previously assigned names. Procedures are in place to ensure that each IMEI is
uniquely assigned by the Mobile Equipment manufacturer so that it is
guaranteed to uniquely identify that particular Mobile Equipment device. Procedures are in place to ensure that each IMEISV is
uniquely assigned by the Mobile Equipment manufacturer so that it is
guaranteed to uniquely identify that particular Mobile Equipment device
and the specific software version installed.The GSMA is committed to maintaining uniqueness and persistence of all resources identified by assigned URNs.As the NID sought is 'gsma' and "GSMA" is the
long-standing acronym for the trade association that represents
the mobile phone operators, the URN should also persist indefinitely
(at least as long as there is a need for its use). The assignment process
guarantees that names are not reassigned. The binding between the name and
its resource is permanent. The TAC and SNR portions of the IMEI and IMEISV are
permanently stored in the Mobile Equipment, so they remain persistent
as long as the Mobile Equipment exists. The process for TAC and SNR
assignment is documented in GSMA PRD TS.06 ,
and once assigned, the TAC and SNR values are not reassigned to other
Mobile Equipment devices. The SVN portion of the IMEISV may be modified
by software when new versions are installed but should be
persistent for the duration of the installation of that specific
version of software. The GSMA will manage the <NSS> (including 'imei')
and <future-gsma-specifier> identifier
resources to maintain uniqueness. The process for IMEI and IMEISV assignment is
documented in GSMA PRD TS.06 .
Since the 'gsma' NSS is not currently globally resolvable,
this is not applicable. Two GSMA IMEI URNs are equivalent if they have the same
'imeival' value, and the same parameter values in the same
sequential order, with the exception that the 'vers=0' parameter
is to be ignored for the purposes of comparison. All of these
comparisons are to be case insensitive. Any identifier in the 'gsma' NSS can be compared
using the normal mechanisms for percent-encoded UTF-8 strings
(see RFC 3629 ). The string representation of the 'gsma' NID and of the 'imei' NSS is fully
compatible with the URN syntax (see RFC 2141 ).The IMEI can be validated using the mechanism defined in Annex B of 3GPP TS 23.003 .
There is no mechanism defined to
validate the SVN field of the IMEISV.The GSMA URN is global in scope. The optional 'vers' parameter and the 'ext-imei' field
in the ABNF are included for extensibility of the 'imei' NSS -- for example,
if the IMEI format is extended in the future (such as with
additional digits or using hex digits). In this case, the 'vers' parameter
would contain a non-zero value and the 'ext-imei' would be further
defined to represent the syntax of the extended IMEI format. A value of
the 'vers' parameter equal to 0 or the absence of the 'vers' parameter
means the URN format is compliant with the format specified here.Any change to the format of the 'imei' NSS requires the use of the
procedure for URN NSS changes and additions (currently through the
publication of future Informational RFCs approved by IETF consensus). The
use of the 'vers' parameter was chosen for extensibility instead of defining
a new NSS (e.g., 'imei2') because it is likely that many applications
will only need to perform string compares of the 'imeival'. So, even if
the format or length of the 'imeival' changes in the future, such
applications should continue to work without having to be updated to
understand a new NSS.RFC 7255 specifies how
the GSMA IMEI URN can be used as an instance ID as specified in RFC 5626 . Any future value of the 'vers' parameter other than 0, or
the definition of additional parameters that are intended to be used as part
of an instance ID, will require an update to RFC 7255 . For example: urn:gsma:imei:90420156-025763-0;vers=0 The IMEISV is an identifier that uniquely identifies
mobile devices and their associated software versions used in the GSM,
UMTS, and LTE networks. The representation of the IMEISV
is defined in 3GPP TS 23.003 .To represent the IMEISV, the URN parameter 'svn' is
appended to the GSMA IMEI URN and set equal to the decimal string
representation of the two software version number (svn) digits in the
IMEISV, and the Spare digit in the IMEI 'imeival' is set to zero. For example:
urn:gsma:imei:90420156-025763-0;svn=42 The TAC is an 8 decimal digit value. The TAC identifies the type
of the Mobile Equipment and is chosen from a range of values
allocated to the Mobile Equipment manufacturer in order to uniquely
identify the model of the Mobile Equipment.The SNR is a 6 decimal digit value. The SNR is an
individual serial number that uniquely identifies each Mobile Equipment device
within the TAC.The Spare is a single decimal digit. When the IMEI
is stored on the Mobile Equipment and network equipment, it contains a
value that is used as a Check digit and is intended to avoid manual
reporting errors (e.g., when customers register stolen mobiles at the
operator's customer care desk) and also to help guard against the
possibility of incorrect entries being provisioned in the network equipment.
The Spare is always set to zero when transmitted by the Mobile Equipment
(including when in the IMEI URN format).
Annex B of 3GPP TS 23.003 specifies a
mechanism for computing the actual Check digit in order to validate the
TAC and SNR.When included in a cellular signaling message,
the IMEI format is 15 decimal digits encoded in 8 octets, using BCD
as defined in 3GPP TS 24.008 .
is an abstract representation of a BCD-encoded
IMEI stored in memory (the actual storage format in memory is
implementation specific). In , the most significant
digit of the TAC is coded in the least significant bits of octet 1. The
most significant digit of the SNR is coded in the least significant bits
of octet 5. The Spare digit is coded in the least significant bits
of octet 8. When included in an identity element in a cellular signaling
message, the most significant digit of the TAC is included in digit 1 of
the identity element in Figure 10.5.4 of 3GPP TS 24.008 .The TAC is the same as the TAC in the IMEI
(see ).The SNR is the same as the SNR in the IMEI
(see ).The Software Version Number is allocated by the mobile device
manufacturer to identify the software version of the mobile
device.When included in a cellular signaling message, the IMEISV
format is 16 decimal digits encoded in 8 octets using BCD as defined in
3GPP TS 24.008 . is
an abstract representation of a BCD-encoded IMEISV stored in memory
(the actual storage format in memory is implementation specific).
In , the most significant digit of the TAC
is coded in the most significant bits of octet 1. The most significant
digit of the SNR is coded in the most significant bits of octet 5. The
most significant digit of the SVN is coded in the most significant bits
of octet 8. When included in an identity element in a cellular signaling
message, the most significant digit of the TAC is included in digit 1 of
the identity element in Figure 10.5.4 of 3GPP TS 24.008 .GSM, UMTS, and LTE mobile devices will be interoperating with Internet
devices for a variety of voice and data services. To do this, they
need to make use of Internet protocols that will operate end to end
between devices in GSM/UMTS/LTE networks and those in the general
Internet. Some of these protocols require the use of URNs as
identifiers. Within the GSM/UMTS/LTE networks, mobile devices are
identified by their IMEI or IMEISV. Internet users will need to be
able to receive and include the GSMA URN in various Internet protocol
elements to facilitate communication between pure Internet-based
devices and GSM/UMTS/LTE mobile devices. Thus, the existence and syntax
of these namespaces need to be available to the general Internet
community, and the namespace needs to be reserved with IANA in order to
guarantee uniqueness and prevent potential namespace conflicts both
within the Internet and within GSM/UMTS/LTE networks. Conversely,
Internet implementations will not generally possess IMEI identifiers.
The identifiers generated by such implementations will typically be URNs
within namespaces other than 'gsma' and may, depending on context, even
be non-URN URIs. Implementations are advised to be ready to process URIs
other than 'gsma' namespaced URNs, so as to aid in interoperability.A URN was considered the most appropriate URI to represent the IMEI and
IMEISV, as these identifiers may be used and transported similarly to the
Universally Unique Identifier (UUID), which is defined as a URN in
RFC 4122 . Since specifications for protocols
that are used to transport device identifiers often require the device
identifier to be globally unique and in the URN format, it is necessary
that the URN formats are defined to represent the IMEI and IMEISV. In accordance with BCP 66 (RFC 3406) , IANA
has registered the Formal URN Namespace 'gsma' in the
"Uniform Resource Names (URN) Namespaces" registry, using the
registration template presented in of
this document.IMEIs (but with the Spare value set to the value of the
Check digit) are displayable on most mobile devices and in many cases
are printed on the case within the battery compartment. Anyone with
brief physical access to the mobile device can therefore easily obtain
the IMEI. Therefore, IMEIs MUST NOT be used as security capabilities
(identifiers whose mere possession grants access). Unfortunately,
there are currently examples of some applications that are using the
IMEI for authorization. Also, some service provider's customer
service departments have been known to use knowledge of the IMEI as
"proof" that the caller is the legitimate owner of the mobile device.
Both of these are inappropriate uses of the IMEI.While the specific software version of the mobile device only
identifies the lower-layer software that has undergone and passed
certification testing, and not the operating system or application
software, the software version could identify software that is
vulnerable to attacks or is known to contain security holes.
Therefore, the IMEISV MUST only be delivered to trusted entities
within carrier networks and not provided to the Internet at large,
as it could help a malicious device identify that the mobile device
is running software that is known to be vulnerable to certain attacks.
This concern is similar to concerns regarding the use of the
User-Agent header in the Session Initiation Protocol (SIP) as
specified in RFC 3261 . Therefore, the
IMEISV (that is, the IMEI URN with a 'svn'
parameter) MUST NOT be delivered to devices that are not trusted.
IMEIs are almost always personally identifiable
information, and so these URNs MUST be treated
as personally identifiable information in all cases.
In order to prevent violating a user's privacy, the IMEI URN
MUST NOT be included in messages intended to convey any level of
anonymity.Since the IMEI is permanently assigned to the mobile device and is not
modified when the ownership of the mobile device changes (even
upon a complete software reload of the device), the IMEI URN MUST NOT
be used as a user identifier or user address by an application. Using the
IMEI to identify a user or as a user address could result in
communications destined for a previous owner of a device being
received by the new device owner or could allow the new device owner
to access information or services owned by the previous device owner.Additionally, since the IMEI identifies the mobile device, it
potentially could be used to identify and track users for the
purposes of surveillance and call data mining if sent in the clear.Since the IMEI is personally identifiable information, uses of
the IMEI URN with IETF protocols require a specification and IETF
Expert Review in order to ensure that
privacy concerns are appropriately addressed. Protocols carrying
the IMEI URN SHOULD at a minimum use channels that are strongly
hop-by-hop encrypted, and it is RECOMMENDED that end-to-end
encryption be used.Additional security considerations are specified in 3GPP TS 22.016
. Specifically, the IMEI is to be
incorporated in a module that is contained within the terminal.
The IMEI SHALL NOT be changed after the terminal's production process.
It SHALL resist tampering, i.e., manipulation and change, by any
means (e.g., physical, electrical, and software).This document draws heavily on the 3GPP work on Numbering, Addressing,
and Identification in 3GPP TS 23.003 and
also on the style and structure used in RFC 4122 .
The authors would like to thank Cullen Jennings, Lisa Dusseault,
Dale Worley, Ivo Sedlacek, Atle Monrad, James Yu, Mary Barnes, Tim Bray,
S. Moonesamy, Alexey Melnikov, Martin Duerst, John Klensin, Paul Kyzivat,
Christer Holmberg, Barry Leiba, and Stephen Farrell for their help
and comments.Numbering, addressing and identification3GPPIMEI Allocation and Approval GuidelinesGSM AssociationMobile radio interface Layer 3 specification; Core network protocols; Stage 33GPPInternational Mobile station Equipment Identities (IMEI)3GPPUsing the International Mobile station Equipment
Identity (IMEI) Uniform Resource Name (URN) as an Instance ID