As used herein, the following abbreviations shall have the following meanings:
CS: Circuit Switched
CSCF: Call Session Control Function
ESN: Electronic Serial Number
GRUU: Globally Routable User Agent (UA) URIs
I-CSCF: Interrogating CSCF
ICS: IMS Centralized Services
ID: Identifier
IMEI: International Mobile Equipment Identity
IMS: IP Multimedia Subsystem
IP: Internet Protocol
MEID: Mobile Equipment Identifier
MSC: Mobile Switching Center
NAI: Network Access Identifier
NSS: Name Space Specific string
P-CSCF: Proxy CSCF
PS: Packet Switched
S-CSCF: Serving CSCF
SCC AS: Service Centralization and Continuity Application Server
SIP: Session Initiation Protocol
SNR: Serial Number
TAC: Type Allocation Code
UA: User Agent
UE: User Equipment
URI: Uniform Resource Identifiers
UUID: Universally Unique Identifier
In SIP-based systems, such as IMS, it would be desirable to target a request to a specific device, such as, but not limited to, a mobile telephone, terminal, UE, fixed line terminal, or software based client (sometimes referred to herein as a “device”). For example, when transferring a call, it might be desirable to target a specific device such as a mobile telephone.
In order to achieve this, a Globally Routable User Agent (UA) URI (GRUU) is assigned to the device by the registrar (which is the S-CSCF in an IMS system). In order to properly assign the GRUU, the registrar uses an Instance ID that is provided by the device during registration.
The Instance ID is used by the registrar to generate the actual GRUU. The most common approach is to use the Instance ID as the “gr” parameter of the GRUU.
The current IMS specification assumes that the device being targeted with the GRUU is performing the registration. However, with the introduction of IMS Centralized Services (ICS) it is possible for the network to register in IMS on behalf of the device when the device is using CS access. In the case of ICS, the MSC Server is the network entity that registers on behalf of the CS subscriber.
Because an ICS device may also be able to register directly in IMS when it is using PS access, it is desirable that the Instance ID that is used by the network be identical to the Instance ID that is used by the device when performing registration. This ensures that the same GRUU is assigned to the device.
The current IMS specification does not provide any specific guidance on how the device or the network shall create the Instance ID. The only guidance that is provided is that the Instance ID must match the format described in the IETF Outbound draft. Therefore, the current IMS specification does not ensure that the Instance ID used by the network will match the Instance ID used by the device.
Additionally, the current IMS specification does not provide any guidance on how the registrar shall generate the GRUU from the Instance ID. This can lead to the generation of different GRUUs depending on which S-CSCF is assigned during registration if different S-CSCF vendors choose to generate the GRUU in different ways.
It has been proposed to directly use, as the Instance ID, an already existing equipment identity from the terminal, such as the IMEI. However, if the S-CSCF were to use the Instance ID unchanged as the GRUU, then this would expose the DevID to other users during session establishment. This could be considered a privacy violation and could be used to clone the equipment. Therefore there are disadvantageous to directly using an existing device identity such as the IMEI as the Instance ID.
The following presents a summary of the present invention in order to provide a basic understanding of some aspects thereof. This summary is not an exhaustive overview of the present invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later.
The present invention describes a process for creating Instance IDs that are consistent, whether they are created by the device or by the network, while at the same time providing privacy and security.
To ensure consistency, the creation of the Instance ID is based on the use of a unique identifier that belongs to the device but is also known to the network (referred to herein as the “DevID”).
To ensure privacy, the creation of the Instance ID or GRUU is based on using a hash to protect the DevID and a shared namespace that is used by both the network and the device when encoding the DevID into an Instance ID or GRUU.
Optimally, the Instance ID would not contain information about the DevID passed as unencrypted plaintext. However, because it may not be possible to mandate that the UE protect the Instance ID as described herein, it is necessary to also describe procedures for the registrar to provide some level of protection. Therefore, the present invention describes an alternative approach that can be used to provide a level of privacy even when the DevID is initially sent unprotected during registration.
Therefore, the present invention claims two approaches for addressing privacy concerns: (1) defining a mechanism for creating an Instance ID which does not reveal any information about the actual DevID. This allows the Instance ID to be directly used as the “gr” parameter of the GRUU, and (2). defining a mechanism where, if the Instance ID contains the DevID plaintext in the clear, that the registrar manipulates the Instance ID in order to generate the “gr” parameter of the GRUU. This provides privacy for DevID in non-registration signaling from the UE.
In the following section, the present invention will be described with reference to exemplary embodiments illustrated in the Figures, in which:
The present invention facilitates the creation of an Instance ID that will ensure uniqueness of the ID, while ensuring the privacy of existing equipment identities. The present invention also provides a mechanism to ensure that the network (MSC Server) and the device will create identical Instance IDs that are used in the creation of a GRUU. It makes use of the UUID format defined in RFC 4122.
Additionally, the present invention provides a mechanism for the network to provide privacy for the DevID even when the ID is not protected in the Instance ID that is sent to the network during registration. This aspect of the present invention uses the same techniques that are employed when the UE or MSC Server protects the DevID, but instead are performed by the registrar (S-CSCF).
As described herein, the device is assumed to be a 3GPP Mobile that supports GRUU and the creation of an Instance ID, however the present invention is applicable to any device where the network and the device share knowledge of a device specific identifier. In the case of a 3GPP device, the DevID is derived from the IMEI. In the case of a 3GPP2 device, the DevID is derived from the MEID or ESN.
For software based clients, and clients not fully conforming to the mobile standards, the IMEI (or equivalent) might not be available. Hence, in another embodiment of the present invention, the DevID is created based on the private user identity of the terminal. In such a scenario, a device may be represented by several private user identities, towards the registrar (one from the UE as such over the PS access, and one from the MSC server registering on behalf of the user). To ensure a consistent behavior, both the UE and the network performing the registration, need to select the DevID based on the private ID used by the network. Another benefit of using the private ID from the network as DevID would be that it becomes agnostic to the type of CS access used.
In the present invention, the name-based version of the UUID is used as described in RFC 4122. Either version 3 or version 5 can be used, the only difference being the type of hashing that is used (MD5 and SHA-1, respectively). As seen in table 100 of
In order to create the final Instance ID, a name space ID is required. Table 200 of
The IMEI (14 digits) is complemented by a check digit. The check digit is not part of the digits transmitted.
Example DevID Derivation:
The IMEISV 400 as seen in
Example DevID Derivation:
In the MEID 500 of
The Check Digit (CD) 505 is not part of the MEID and is not transmitted when the MEID is transmitted.
Example DevID Derivation:
The following are Identifier alternatives for devices without unique device IDs.
In some cases, there may not be a device specific ID, such as an IMEI, available to the client. For example, this would be the case when using a soft client. In this case the private identity can be used instead. The private identity takes the form of a Network Access Identifier (NAI) as defined in RFC 4282.
An example private identity for IMS is: user1_private@home1.net.
Example DevID Derivation:
Private ID:
Private ID: user1_private@home1.net
DevID=Private ID=user1_private@home1.net
Instance ID Creation when Providing DevID Protection in the UE or Network (MSC Server)
As previously described, the preferred embodiment of the present invention is to protect the DevID at the UE or MSC Server, even during registration. Therefore, the DevID shall be encoded using the following steps.
Steps for creation of Instance ID at the UE or network (MSC Server) using a device specific ID, in this example using the IMEI as defined in 3GPP:
In
In the interest of clarity, some details unrelated to the present invention have been omitted, including some of the SIP Headers in the examples below.
The basic registration flow for a device implementing the present invention are as seen in
Optimally, the DevID would be protected even during registration, however there may be circumstances where the DevID is sent plain text unencrypted as the Instance ID during registration. In order to provide some level of privacy protection for the user it is necessary to define procedures in the network for constructing the GRUU based on the Instance ID in a way that does not reveal the DevID.
An additional embodiment of the present invention uses the same techniques that were described above for the creation of an Instance ID which protected the DevID. However, in this scenario the registrar (S-CSCF) will apply those techniques to the creation of the “gr” parameter of the GRUU instead of the Instance ID.
DevID Format when Transported Plain Text Unencrypted in an Instance ID
As specified in the draft-ietf-sip-outbound, any Instance ID must use a URN scheme. An embodiment of the present invention has been described herein of using an RFC 4122 based URN when sending a protected DevID as the Instance ID. However, when sending a DevID format as unencrypted plain text, there is currently no finalized RFC for which to refer. Therefore, it is only possible to give examples of what a URN for the DevID might look like. The final format of such a URN may not be identical to the examples presented here, however the principles described should still apply to other formats that carry the same information.
One proposed format for an IMEI based DevID is described in draft-montemurro-gsma-imei-urn. An example Instance ID based on that draft is as follows:
It should be noted that the zero (0) at the end represents the spare digit which is always transmitted as zero (0).
The registrar uses the received URN format in the Instance ID (+sip.instance) to determine what handling to apply. In this example, receipt of the urn:gsma:imei would be a trigger to apply the procedures of the present invention.
Steps for GRUU Creation by the Registrar (S-CSCF) when the DevID is not Protected During Registration
The steps of creating the GRUU by the registrar (S-CSCF) based on an unprotected DevID in the Instance ID are:
In the case of a non-3GPP device where an identification other than an IMEI is used, the only criteria is that the contents of the Instance ID is unique to the device and does not change over time.
An alternative embodiment of the present invention can be implemented by the registrar where the URN format is not recognized or in the case of a non-3GPP device which may not have an IMEI equivalent. In these cases the registrar could use the following steps:
Referring now to
The call flow of
Some details not related to the present invention illustrated in
As seen hereinabove, the present invention comprises a method and apparatus for signaling between a device and network. The method comprises the step of generating, by a device, an Instance Identification (ID) that matches an Instance ID used by a network. The apparatus of the present invention includes a means of generating an ID that matches the Instance ID used by the network. The means, as more fully described below, can be implemented in computer hardware and software. In either the method or apparatus, the Instance ID is based on a unique identifier that belongs to the device but is also known to the network (DevID). The creation of the Instance ID can be based on a hash to protect the DevID and a shared namespace that is used by both the network and the device when encoding the DevID into an Instance ID. In some instances, the Instance ID would not contain information about the DevID passed as unencrypted plaintext. Further, in the present invention, (i) a registrar in the network can be adapted to protect the Instance ID; (ii) the creation of the Instance ID can be based on using the DevID directly as a URN into an Instance ID; (iii) the Instance ID can contain information about the DevID passed as unencrypted plaintext, wherein, in an embodiment, the creation of the “gr” parameter of the GRUU is based on a hash to protect the DevID and in a further embodiment, the creation of the hashed parameter can be based on the concatenation of the DevID and a namespace and applying the hashing algorithm. In the present invention, the Instance ID can be based on an IMEI, an MEID, on a private user identity in the form of a NAI or on a URN format that is not recognized by the registrar. Where the Instance ID is based on a URN format, the creation of the “gr” parameter of the GRUU is based on a hash to protect the unknown URN format.
The present invention provides several advantages over the proposed solutions. Most notably, it ensures that any Instance ID created by a network will be identical to an Instance ID created by the device. This, in turn, results in the same GRUU being defined regardless of how the device is registered (directly or by the network). Further, it provides specific steps to outline the creation of the Instance ID, particularly in the case of an IMS system. This fills a gap currently open in the existing 3GPP specifications. The present invention ensures consistent behavior for IMS-based services such as ICS. The present invention uses a hash to derive the Instance ID thus protecting the device specific identifier (such as IMEI, MEID, etc). The present invention protects the integrity of the device specific identifier, thus enhancing security.
The apparatus and means of the present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
The present invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.
This application claims the benefit of U.S. Provisional Application No. 61/086,908, filed Aug. 7, 2008, now pending, the disclosure of which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61086908 | Aug 2008 | US |