Extending shaken framework to validate and verify device identity

Abstract

In accordance with example embodiments of the invention there is at least a method and apparatus to at least perform identifying a session initiation protocol INVITE comprising an indication of a caller identity; based on the identifying, initiating an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and determining whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

Description

[0001] EXTENDING SHAKEN FRAMEWORK TO VALIDATE AND VERIFY DEVICE

[0002] IDENTITY

[0003] TECHNICAL FIELD:

[0004] The teachings in accordance with the exemplary embodiments of this invention relate generally to proposes to extend the STIR / SHAKEN framework at the time of this application and, more specifically, relate to extending the STIR / SHAKEN framework to not only validate and verify the caller identity but also the device identity.

[0005] BACKGROUND:

[0006] This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.

[0007] Certain abbreviations that may be found in the description and / or in the Figures are herewith defined as follows:

[0008] 3GPP 3rd Generation Partnership Project

[0009] ATIS Alliance for Telecommunication Industry

[0010] CSCF Call Session Control Function

[0011] P - Proxy

[0012] E- Emergency

[0013] S- Session

[0014] IETF Internet Engineering T ask F orce

[0015] IMEI International Mobile Equipment Identifier

[0016] PSAP Public Safety Answering Point

[0017] RFC Request For Comments

[0018] SHAKEN Signature based handling of Asserted Information using tokens

[0019] SIP Session Initiation Protocol

[0020] SP Service Provider

[0021] STIR Secure Telephone Identity Revisited

[0022] URI Uniform Resource Identifier

[0023] Signature-based Handling of Asserted information using toKENs (SHAKEN) is an industry framework for managing the deployment of Secure Telephone Identity (STI) technologies for providing end-to-end cryptographic authentication and verification of the telephone identity and other information in an Internet Protocol (IP)-based service provider voice network.

[0024] With illegitimate caller identity spoofing being a growing concern for north American telephone service providers and their subscribers, the SHAKEN framework helps in validation of legitimate calls and the mitigation of illegitimate spoofing of telephone identities

[0025] However, in certain types of important or emergency calls or caller attacks on emergency systems increasing a caller identity may be anonymous such that a SHAKEN framework cannot validate the caller identity.

[0026] Example embodiments of this invention proposes method(s) to address at least these issues and improved operations for such Signature-based Handling.

[0027] SUMMARY:

[0028] This section contains examples of possible implementations and is not meant to be limiting.

[0029] In another example aspect of the invention, there is an apparatus, such as a user equipment side apparatus, comprising: at least one processor; and at least one memory storing instructions, that when executed by the at least one processor, cause the apparatus at least to: identify a session initiation protocol INVITE comprising an indication of a caller identity; based on the identifying, initiate an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and determine whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

[0030] In still another example aspect of the invention, there is a method, comprising: identifying a session initiation protocol INVITE comprising an indication of a caller identity; based on the identifying, initiating an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and determining whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

[0031] A further example embodiment is an apparatus and a method comprising the apparatus and the method of the previous paragraphs, wherein the identifying comprises extracting the caller identity and extracting the device identity from a contact international mobile station equipment identity parameter of the session initiation protocol and performing validation of both identities, wherein the identity authentication service comprises a secure telephone identity authentication service and a secure telephone identity verification service, wherein at least one of the secure telephone identity authentication service or the secure telephone identity verification service is used for the caller identity and the device identity, wherein there is creating an emergency session initiation protocol INVITE with a telephone identity; and based on the creating, adding a device identity to a session initiation protocol contact header, wherein there is identifying an identity header field identifying the caller identity of an originating session initiation protocol UA, wherein there is validating an international mobile station equipment identity parameter of the device identity; and communicating an origination trigger to the identity authentication service for the session initiation protocol INVITE, wherein the identity authentication service is invoked for both the caller identity and the device identity if present in a session initiation protocol contact header, wherein there is using service provider specific means and device validation procedures for determining whether there is legitimacy of a secured telephone identity based on a determined legitimacy of the caller identity and the device identity based on a presence in the session initiation protocol INVITE, wherein there is adding at least one identity header field using the caller identity in an identity header field; and add a new session initiation protocol header for device identity, wherein the identity header field comprises a JSON web token and at least one parameter, wherein the at least one parameter comprises at least one of: info, alg, and Ppt, wherein the JSON web token comprises at least one of a header, payload, or signature, wherein alg indicates the encryption algorithm, wherein Ppt - indicates the token type, wherein alg indicates the encryption algorithm and must be ES256, and wherein Ppt indicates the token type and must be passport, wherein there is communicating with a terminating network side, an updated session initiation protocol INVITE message with a caller identity and a device identity validated, wherein there is routing a call to an egress interconnection border control function (IBCF), wherein the session initiation protocol INVITE is routed over network to network interface (NNI) through a standard inter-domain routing configuration, wherein there is terminating a service provider (SP) ingress, where the interconnection border control function receives the session initiation protocol INVITE over NNI, wherein there is initiating a terminating trigger to the secure telephone identity verification service for the session initiation protocol INVITE to verify the caller identity and the device identity validation results, wherein the terminating uses an“x5u” field in PASSporT Protected header to determine the secure telephone identity certificate repository (STI-CR) uniform resource identifier (URI) and connects to it, wherein the PASSporT Protected header is identifying a service provider that is vouching for the device identity and indicating what information the service provider is attesting to, wherein the attesting is using a “devAttest” indication comprising one of a “D” or “E” values, wherein the values correspond to “Full Device Attestation” and “No Device Attestation” respectively, wherein the Full Device Attestation “D” means the service provider has validated the device ID and has control over the device, and wherein the No Device Attestation “E” means the service provider could not validate the device identity and the identity seems invalid, wherein the secure telephone identity verification service (STI-VS) uses a new field “x6u” or other value to determine the secure telephone identity certificate repository uniform resource identifier (URI) for device identity validation, wherein there is validating using the secure telephone identity verification service (STI-VS) certificates for the caller identity and the device identity, and extract respective public keys, wherein there is dropping an emergency call for which caller identity is not present and device identity validation fails, wherein there is, based on a secure telephony identity verification result, determining that the call is to be completed with the appropriate “verstat” and “devstat” values, wherein a value for devstat would be one of “D” - device- identity-validation-passed, or “E” - device-identity-validation-failed, wherein there is, based on determined caller identity verification error conditions, defining a device identity verification as a value of 403, New 4xx, or 437, wherein the value of 403 is retained, the value New 4xx indicates one of a “Use devidentity” header or a “Bad device identity info” header or “Invalid devidentity” header, and the value 437 indicates “Unsupported credential”.

[0032] A non-transitory computer-readable medium storing program code, the program code executed by at least one processor to perform at least the method as described in the paragraphs above.

[0033] In yet another example aspect of the invention, there is an apparatus comprising: means for identifying a session initiation protocol INVITE comprising an indication of a caller identity; means, based on the identifying, for initiating an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and means for determining whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

[0034] In accordance with the example embodiments as described in the paragraph above, at least the means for identifying, initiating, and determining comprises a network interface, and computer program code stored on a computer-readable medium and executed by at least one processor.

[0035] A communication system comprising the network side apparatus and the user equipment side apparatus performing operations as described above. BRIEF DESCRIPTION OF THE DRAWINGS:

[0036] The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent from the following detailed description with reference to the accompanying drawings, in which like reference signs are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and are not necessarily drawn to scale, in which: FIG. 1 shows a Shaken reference architecture;

[0037] FIG. 2 shows a SHAKEN Call Flow;

[0038] FIG. 3 shows a Shaken Call flow modified in accordance with example embodiments of the invention;

[0039] FIG. 4 shows a high level block diagram of various devices used in carrying out various aspects of the invention; and

[0040] FIG. 5 shows a method in accordance with example embodiments of the invention which may be performed by an apparatus.

[0041] DETAILED DESCRIPTION:

[0042] In example embodiments of this invention there is proposed at least a method and apparatus for extending a STIR / SHAKEN framework to not only validate and verify the caller identity but also the device identity.

[0043] SHAKEN is a framework that utilizes protocols defined in IETF STIR Working Group that work together in an end-to-end architecture for the authentication and assertion of a Caller ID by an originating service provider and the verification of this identity by a terminating service provider.

[0044] Today the assertion of caller identity typically uses the P-Asserted-Identity SIP header defined in IETF RFC 3325 as a network self-asserted identity.

[0045] FIG. 1 shows a SHAKEN reference architecture:

[0046] The SHAKEN reference architecture as shown in FIG. 1 includes the following elements:

[0047] 1. SIP UA: SIP UA is authenticated by the originating service provider network (OSP). The OSP can assert the calling party identity in originating SIP INVITE requests initiated by the SIP UA; 2. IMS / CSCF: This component represents the SIP registrar and routing function. Also SIP AS;

[0048] 3. IBCF / TrGW: This function is at the edge of the service provider network and represents the NNI or peering interconnection point between service providers. It’s the egress and ingress point for SIP calls between providers;

[0049] 4. Authentication Service (STI-AS): the SIP AS that performs the function of the authentication service defined in [8], It should either itself be highly secure and contain the Secure Key Store (SKS) or secret private keys or have an authenticated TLS -encrypted interface to the SKS that stores the secret private key(s) used to create PASSporT signatures;

[0050] 5. Verification Service (STI-VS): the SIP AS that performs the function the verification service defined in in [8], It has HTTPs interface to the secure telephone identity certificate repository that is referenced in the Identity header field to retrieve the provider public key certificate;

[0051] 6. Call Validation Treatment (CVT): This is a logical that could be an application server function or a 3rd party application for applying call analytics and treatment techniques once the signature is positively or negatively verified;

[0052] 7. SKS: The Secure Key Store is a logical highly secure element that stores secret private key(s) for the authentication service (STI-AS) to access;

[0053] 8. Certificate provisioning service: A logical service used to provision certificate(s) used for STI;

[0054] 9. Secure Telephone Identity Certificate Repository (STI-CR): This represents the publicly accessible store for public key certificates. This is an HTTPS web service that can be validated back to the owner of the public key certificate.

[0055] FIG. 2 shows a SHAKEN Call Flow

[0056] The SHAKEN call flow as shown in FIG. 2 includes the following steps:

[0057] 1. The originating SIP UA which first registers and is authenticated to the CSCF creates a SIP INVITE with a Caller identity (SIP From header); The CSCF of the originating provider adds a p-asserted-identity header field asserting the caller identity of the originating SIP UA. The CSCF then initiates an origination trigger to the STI-AS for the INVITE. The STI-AS should be invoked after processing of call features that may impact either the origination or destination telephone number; The STI-AS in the origination SP network first determines through service provider specific means the legitimacy of the telephone identity being used in the SIP INVITE. The STI-AS then securely requests its private key from the SKS; The SKS provides the private key in the response and the STI-AS signs the INVITE and adds Identity header field(s) as per IETF RFC 8224 using the Caller ID in the P-Asserted- Identity header field; The STI-AS passes the INVITE back to SP A’s CSCF; The originating CSCF through standard resolution routes the call to the egress IBCF; The INVITE is routed over the NNI through the standard inter-domain routing configuration; The terminating SP’s (e.g., SP B) ingress IBCF receives the INVITE over the NNI; The terminating CSCF initiates a terminating trigger to the STI-VS for the INVITE. The STI-VS should be invoked before processing of call features that may impact either the origination or destination number; The terminating SP STI-VS uses the “x5u” field in the PASSporT Protected header as per IETF RFC 8225 to determine the STI-CR URI and makes an HTTPs request to the referenced STI-CR; The STI-VS validates the certificate and then extracts the public key. It constructs the 8 format and uses the public key to verify the signature in the Identity header field, which validates the Caller ID used when signing the INVITE on the originating service provider’s STI-AS; The CVT is an optional function that can be invoked to perform call analytics or other spam mitigation techniques. The CVT may be integrated within the service provider network or outside the service provider network by a third party; 13. Depending on the result of the STI verification, the STI-VS determines that the call is to be completed with the appropriate “verstaf ’ value (defined in standards at the time of this application) and the INVITE is passed back to the terminating CSCF which continues to set up the call to the terminating SIP UA;

[0058] 14. The terminating SIP UA receives the INVITE and normal SIP processing of the call continues.

[0059] As similarly stated above, with illegitimate caller identity spoofing being a growing concern for north American telephone service providers and their subscribers, the SHAKEN framework helps in validation of legitimate calls and the mitigation of illegitimate spoofing of telephone identities. Using the mechanisms defined in SHAKEN standards, calls traversing through interconnected carrier networks have the legitimacy of their caller identity evaluated and if asserted, signed as legitimate by the originating carrier, and later verified by the terminating carrier.

[0060] But in emergency calls, the caller identity could be “anonymous” and in such scenarios, the current SHAKEN framework cannot validate the caller identity and due to this the terminating carrier cannot verify the legitimacy of unvalidated caller identity. In such cases, it would be beneficial to validate and verify the device identity too to make sure the call is made from a legitimate device and the identity is not a spoofed one.

[0061] Also, with attacks on emergency systems increasing, where attackers use spoofed subscriber and device identities, it would be highly beneficial to validate and verify the subscriber and device identities used to make emergency calls, in order to ensure they are made from legitimate devices and not from spoofed anonymizers. If the identities could not be validated and verified or determined to be invalid, then those calls can be dropped.

[0062] In order to validate and verify device identity, the invention proposes to extend the current STIR / SHAKEN framework to not only validate and verify the caller identity but also the device identity.

[0063] For SHAKEN framework to validate device identity, the following new extensions are proposed:

[0064] New PASSporT attest claim - dev Attest;

[0065] New attestation levels - “D” and “E”;

[0066] New device validation status header - devvalstat with values: “device-validation-passed”, “device-validation -failed”. Example embodiments of the invention propose at least to extend the impact of STIR / SHAKEN framework on 911 calls to not only validate and verify the caller identity but also validate the device identity i.e., IMEI thereby preventing attack on PSAPs due to spoofed device identities.

[0067] Example embodiments of the invention propose at least several extensions to SHAKEN framework defined in various ATIS and IETF standards in order to add new parameters for device identities and procedures for validating device identity.

[0068] Example embodiments of the invention extends the SHAKEN framework to validate and verify device identity.

[0069] Before describing the example embodiments as disclosed herein in detail, reference is made to FIG. 4 for illustrating a simplified block diagram of various electronic devices that are suitable for use in practicing the example embodiments of this invention.

[0070] FIG. 4 shows a block diagram of one possible and non-limiting exemplary system in which the example embodiments may be practiced. In FIG. 4, a user equipment (UE) 10 is in wireless communication with a wireless network 1 or network, 1 as in FIG. 4. The wireless network 1 or network 1 as in FIG. 4 can comprise a communication network such as a mobile network e.g., the mobile network 1 or first mobile network as disclosed herein. Any reference herein to a wireless network 1 as in FIG. 4 can be seen as a reference to any wireless network as disclosed herein. Further, the wireless network 1 as in FIG. 4 can also comprises hardwired features as may be required by a communication network. A UE is a wireless, typically mobile device that can access a wireless network. The UE, for example, may be a mobile phone (or called a "cellular" phone) and / or a computer with a mobile terminal function. For example, the UE or mobile terminal may also be a portable, pocket, handheld, computer-embedded or vehicle-mounted mobile device and performs a language signaling and / or data exchange with the RAN.

[0071] The UE 10 includes one or more processors DP 10 A, one or more memories MEM 10B, and one or more transceivers TRANS 10D interconnected through one or more buses. Each of the one or more transceivers TRANS 10D includes a receiver and a transmitter. The one or more buses may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers TRANS 10D which can be optionally connected to one or more antennas for communication to NN 12 and NN 13, respectively. The one or more memories MEM 10B include computer program code PROG 10C. The UE 10 communicates with NN 12 and / or NN 13 via a wireless link 11 or 16.

[0072] The NN 12 (NR / 5G / 6G Node B, an evolved NB, or LTE device) is a network node such as a master or secondary node base station (e.g., for NR or LTE long term evolution) that communicates with devices such as NN 13 and UE 10 of FIG. 4. The NN 12 provides access to wireless devices such as the UE 10 to the wireless network 1. The NN 12 includes one or more processors DP 12 A, one or more memories MEM 12B, and one or more transceivers TRANS 12D interconnected through one or more buses. In accordance with the example embodiments these TRANS 12D can include X2 and / or Xn interfaces for use to perform the example embodiments. Each of the one or more transceivers TRANS 12D includes a receiver and a transmitter. The one or more transceivers TRANS 12D can be optionally connected to one or more antennas for communication over at least link 11 with the UE 10. The one or more memories MEM 12B and the computer program code PROG 12C are configured to cause, with the one or more processors DP 12 A, the NN 12 to perform one or more of the operations as described herein. The NN 12 may communicate with another gNB or eNB, or a device such as the NN 13 such as via link 16 or link 18. Further, the link 11, link 16 and / or any other link may be wired or wireless or both and may implement, e.g., an X2 or Xn interface. Further the link 11 and / or link 16 and / or link 18 may be through other network devices such as, but not limited to an NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 device as in FIG. 4. The NN 12 may perform functionalities of an MME (Mobility Management Entity) or SGW (Serving Gateway), such as a User Plane Functionality, and / or an Access Management functionality for LTE and similar functionality for 5G or 6G.

[0073] The NN 13 can be for WiFi or Bluetooth or other wireless device associated with a mobility function device such as an AMF or SMF, further the NN 13 may comprise a NR / 5G / 6G Node B or possibly an evolved NB a base station such as a master or secondary node base station (e.g., for NR or LTE long term evolution) that communicates with devices such as the NN 12 and / or UE 10 and / or the wireless network 1. The NN 13 includes one or more processors DP 13 A, one or more memories MEM 13B, one or more network interfaces, and one or more transceivers TRANS 13D interconnected through one or more buses. In accordance with the example embodiments these network interfaces of NN 13 can include X2 and / or Xn interfaces for use to perform the example embodiments. Each of the one or more transceivers TRANS 13D includes a receiver and a transmitter that can optionally be connected to one or more antennas. The one or more memories MEM 13B include computer program code PROG 13C. For instance, the one or more memories MEM 13B and the computer program code PROG 13C are configured to cause, with the one or more processors DP 13 A, the NN 13 to perform one or more of the operations as described herein. The NN 13 may communicate with another mobility function device and / or eNB such as the NN 12 and the UE 10 or any other device using, e.g., link 11 or link 16 or link 18 or another link. The link 16 or link 18 as shown in FIG. 4 can be used for communication with the NN12. These links maybe wired or wireless or both and may implement, e.g., an X2 or Xn interface. Further, as stated above the link 11 and / or link 16 and / or link 18 may be through other network devices such as, but not limited to an NCE / MME / SGW device such as the NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 of FIG. 4.

[0074] The one or more buses of the device of FIG. 4 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers TRANS 12D, TRANS 13D and / or TRANS 10D may be implemented as a remote radio head (RRH), with the other elements of the NN 12 being physically in a different location from the RRH, and these devices can include one or more buses that could be implemented in part as fiber optic cable to connect the other elements of the NN 12 to a RRH.

[0075] It is noted that although FIG. 4 shows a network nodes such as NN 12 and NN 13, any of these nodes may can incorporate or be incorporated into an eNodeB or eNB or gNB such as for LTE and NR, and would still be configurable to perform example embodiments.

[0076] Also it is noted that description herein indicates that “cells” perform functions, but it should be clear that the gNB that forms the cell and / or a user equipment and / or mobility management function device that will perform the functions. In addition, the cell makes up part of a gNB, and there can be multiple cells per gNB.

[0077] The wireless network 1 or any network it can represent may or may not include a NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 that may include (NCE) network control element functionality, MME (Mobility Management Entity) / SGW (Serving Gateway) functionality, and / or serving gateway (SGW), and / or MME (Mobility Management Entity) and / or SGW (Serving Gateway) functionality, and / or user data management functionality (UDM), and / or PCF (Policy Control) functionality, and / or Access and Mobility Management Function (AMF) functionality, and / or Session Management (SMF) functionality, and / or Location Management Function (LMF), and / or Authentication Server (AUSF) functionality and which provides connectivity with a further network, such as a telephone network and / or a data communications network (e.g., the Internet), and which is configured to perform any 5G, 6G, and / or NR operations in addition to or instead of other standard operations at the time of this application. The NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 is configurable to perform operations in accordance with example embodiments in any of an LTE, NR, 5G, 6G, and / or any standards based communication technologies being performed or discussed at the time of this application. In addition, it is noted that the operations in accordance with example embodiments, as performed by the NN 12 and / or NN 13, may also be performed at the NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14.

[0078] The NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 includes one or more processors DP 14 A, one or more memories MEM 14B, and one or more network interfaces (N / W I / F(s)), interconnected through one or more buses coupled with the link 13 and / or link 16 and / or link 18. In accordance with the example embodiments these network interfaces can include X2 and / or Xn interfaces for use to perform the example embodiments. The one or more memories MEM 14B include computer program code PROG 14C. The one or more memories MEM14B and the computer program code PROG 14C are configured to, with the one or more processors DP 14 A, cause the NCE / MME / SGW / UDM / PCF / AMF / SMF / LMF 14 to perform one or more operations which may be needed to support the operations in accordance with the example embodiments.

[0079] It is noted that that the NN 12 and / or NN 13 and / or UE 10 can be configured (e.g. based on standards implementations etc.) to perform functionality of a Location Management Function (LMF). The LMF functionality may be embodied in any of these network devices or other devices associated with these devices. In addition, an LMF such as the LMF of the MME / SGW / UDM / PCF / AMF / SMF / LMF 14 of FIG. 4, as at least described below, can be co-located with UE 10 such as to be separate from the NN 12 and / or NN 13 of FIG. 4 for performing operations in accordance with example embodiments as disclosed herein.

[0080] The wireless Network 1 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors DP10, DP12A, DP13A, and / or DP14A and memories MEM 10B, MEM 12B, MEM 13B, and / or MEM 14B, and also such virtualized entities create technical effects.

[0081] The computer readable memories MEM 10B, MEM 12B, MEM 13B, and MEM 14B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories MEM 12B, MEM 13B, and MEM 14B may be means for performing storage functions. The processors DP 10, DP12A, DP13A, and DP14A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors DP10, DP12A, DP13A, and DP14A may be means for performing functions, such as controlling the UE 10, NN 12, NN 13, and other functions as described herein.

[0082] In general, various embodiments of any of these devices can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.

[0083] Further, the various embodiments of any of these devices can be used with a UE vehicle, a High Altitude Platform Station, or any other such type node associated with a terrestrial network or any drone type radio or a radio in aircraft or other airborne vehicle or a vessel that travels on water such as a boat.

[0084] FIG. 3 shows a Shaken Call flow modified in accordance with example embodiments of the invention. FIG. 3 shows modified entries in accordance with example embodiments of the invention using an ‘X’.

[0085] Below is shown the proposed architecture in accordance with example embodiments of the invention with modified elements as in FIG. 3 :

[0086] Note: The actual device validation procedure is defined in ART-1.

[0087] In the extended SHAKEN reference architecture, the functionality of following elements is extended:

[0088] 1. IMS CSCF : This component in addition to caller identity also extracts the device identity from SIP Contact header’s IMEI parameter and performs validation of both the identities, (updated entity as shown with X); 2. Authentication Service (STI-AS): The SIP AS along with performing the authentication service defined in IETF RFC 8224 for Caller Identity, also performs the function of the authentication service for device identity;

[0089] 3. Verification Service (STI-VS): The SIP AS along with performing the verification service defined in IETF RFC 8224 for caller identity, also performs the function of the verification service for device identity;

[0090] 4. SKS: stores secret private keys for both current STI-AS.

[0091] Referring to FIG. 3, the extended SHAKEN call flow would be: . The originating SIP UA creates SIP INVITE with telephone identity and if the session is an emergency one, adds device identity to SIP Contact header; . The CSCF of the originating provider adds a P-Asserted-Identity header field asserting the caller ID of the originating SIP UA. It also proceeds with validating the device identity i.e., IMEI. The CSCF then initiates an origination trigger to the STI-AS for the INVITE. The STI-AS is invoked for both caller ID and device ID if present in SIP Contact header; . The STI-AS in the originating SP network first determines through service provider specific means and through the device validation procedures the legitimacy of the telephone and device identity if present in INVITE; . The SKS provides the private key in the response and the STI-AS signs the INVITE and adds Identity header field(s) per IETF RFC 8224 using Caller ID in P-Asserted-Identity header field and for device identity, the STI-AS adds a new SIP devidentity header. The details of devidentity header (similar to SIP Identity header) are:

[0092] SIP devidentity header contains a JSON web token (JWT) and 3 parameters - info, alg, and PPT;

[0093] JSON web token - Header, payload, and signature; alg - indicates the encryption algorithm - must be “ES256 ”;

[0094] Ppt - indicates the token type. Must be “passport ”; x5u - indicates the location of the certificate used to sign the token.

[0095] Example of decoded payload for devidentity header { atest": "D", “iat”: 1548859982,

[0096] “devidentity” :”urn:gsma:imei :99000493-686661 -0”

[0097] }

[0098] Further, referring to FIG. 2:

[0099] 5. The STI-AS passes the updated INVITE message (with caller id and device id validated) back to originating SP’s CSCF;

[0100] 6. The originating CSCF routes the call to the egress IBCF;

[0101] 7. The INVITE is routed over the NNI through the standard inter-domain routing configuration;

[0102] 8. The terminating SP’s ingress IBCF receives the INVITE over NNI;

[0103] 9. The terminating CSCF initiates a terminating trigger to the STI-VS for the INVITE to verify the caller id and device identity validation results;

[0104] 10. The terminating SP STI-VS uses the “x5u” field in PASSporT Protected header defined in RFC 8225 to determine the STI-CR URI and connects to it. Similarly, STI-VS uses a new field “x6u” or other appropriate value to determine the STI-CR URI for device identity validation;

[0105] 11. The STI-VS validates the certificates for caller and device identities and then extracts the respective public keys;

[0106] 12. The enhanced CVT can be invoked to perform call and device analytics or other spam mitigation techniques - e.g., dropping emergency calls for which caller identity is not present and device identity validation fails;

[0107] 13. Depending on the result of STI verification, the STI-VS determines that the call is to be completed with the appropriate “verstaf ’ and “devstaf ’ values. Possible values for devstat would be:

[0108] - “D” - device-identity -validation-passed, or

[0109] - “E” - device-identity-validation-failed.

[0110] In addition to the caller id verification error conditions, the device identity verification are defined as follows: • 403 - retained;

[0111] • New 4xx - “Use devidentity header” is not recommended for SHAKEN until a point where calls with caller and device identity are mandated to be signed;

[0112] • New 4xx - “Bad device identity info” - the URI in the “x6u” or the defined field cannot be dereferenced;

[0113] • 437 - “Unsupported credential” - this error code needs to be extended to also check for the credential supplied by “x6u” and the verifier does not support it or if there is any other issue with it;

[0114] • New 4xx - “Invalid devidentity header” - Occurs if signature verification for device identity verification fails;

[0115] 14. The terminating SIP UA receives INVITE.

[0116] New PASSporT “devicelD” claim

[0117] This indicator allows for both identifying the service provider that is vouching for the device identity as well as clearly indicating what information the service provider is attesting to. The “devAttest” claim can be one of the following two values: “D” or “E”. These values correspond to “Full Device Attestation” and “No Device Attestation” respectively.

[0118] • Full Device Attestation “D” means the service provider has validated the device ID and has control over the device;

[0119] • No Device Attestation “E” means the service provider could not validate the device identity and the identity seems invalid.

[0120] The device identity can be IMEI or MAC or UUID

[0121] Adding PASSporT “devicelD” claim to PASSporT Extension “Shaken” (ATIS 1000074)

[0122] The updated “shaken” PASSporT would be as below:

[0123] Protected Header

[0124] {

[0125] "alg":"ES256",

[0126] "typ": "passport",

[0127] "ppt":" shaken device",

[0128] "x6u" : "https: / / cert.example.org / passport.cer"

[0129] } Full Device Attestation

[0130] Payload

[0131] {

[0132] "dev Attest"

[0133] “dest" : { [“uri" :“um: services: sos"] } or "desf ' : { "tn" : ["911 "]}

[0134] "iat":" 1443208345",

[0135] “deviceidentity” urn:gsma:imei :99000493-686661 -0”

[0136] }

[0137] No Device Attestation

[0138] Payload

[0139] {

[0140] "devicelD”: “E"

[0141] "dest": {[“uri”: “urn:services:sos"]} or "dest":{"tn":["911"]}

[0142] "iat":" 1443208345",

[0143] “deviceidentity”:” urn:gsma:imei:99000493-686661-0”

[0144] }

[0145] Changes to Network Elements . P-CSCF: Additional functionality of device identity validation and attestation levels for device identity validation results. Support for new PASSporT claim “devicelD” along with attestation levels for “devicelD” claim - D and E:

[0146] - P-CSCF checks for caller identity in SIP From header and destination number in Request URI and To header. If it finds “anonymous” in SIP From header and 911 or urn: services: SOS in Request URI / To, then initiates device identity registration,

[0147] - The device identity can be of the form URN as specified in of FIG. 2,

[0148] - As an added service, the P-CSCF could also trigger device identity validation along with caller identity validation depending on originating or terminating network policies (not just for 911 calls but also for regular 4G / 5G calls) . STI: Added functionality of device identity signing and verification; . IBCF: Added functionality to verify device identity signing. New IETF Drafts

[0149] 1. New IETF Internet Draft (I-D) to propose new PASSporT claim for device identity - claim name: “dev Attest”. Updates IETF RFC 8443; . New IETF Internet Draft (I-D) to propose new PASSporT claim - “dev Attest” and add values - D and E. Updates to IETF RFC 8588;

[0150] 3. New IETF Internet Draft (I-D) to propose updates to Section 5. PASSporT payload of RFC 8225. 5.2.1.3: “urn “ (URN) format - the device identity should of the form of a URN as defined in step 11 of FIG. 2 and other updates.

[0151] New 3 GPP CRs

[0152] 1. CR to 24.229 to add device identity attest claims - D and E

[0153] Updates to ATIS Standards

[0154] 1. Updates to ATIS-0700048: Section 8.1 to add proposed additions to P-CSCF, IBCF, STI- AS and STI-VS; . Updates to ATIS-1000082: add new datatype deviceidentity of the format URN for device identity;

[0155] 3. Updates to ATIS- 1000074: update text to add device identity spoofing threats, method for CSCF to invoke device identity validation and procedures on CSCF to add attestation for device identity validation.

[0156] IANA assignment update

[0157] Add “dev Attest” claim to ppt value.

[0158] FIG. 5 shows a method in accordance with example embodiments of the invention which may be performed by an apparatus.

[0159] FIG. 5 illustrates operations which may be performed by a device such as, but not limited to, a device such as a network device (e.g., the UE 10 as in FIG. 4). As shown in block 510 of FIG. 5 there is, identifying a session initiation protocol INVITE comprising an indication of a caller identity. As shown in block 520 of FIG. 5 there is, based on the identifying, initiating an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE. As shown in block 530 of FIG. 5 wherein the identity authentication service functions as an authentication service for device identity. Then as shown in block 540 of FIG. 5 there is determining whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

[0160] In accordance with the example embodiments as described in the paragraph above, wherein the identifying comprises extracting the caller identity and extracting the device identity from a contact international mobile station equipment identity parameter of the session initiation protocol and performing validation of both identities.

[0161] In accordance with the example embodiments as described in the paragraphs above, wherein the identity authentication service comprises a secure telephone identity authentication service and a secure telephone identity verification service.

[0162] In accordance with the example embodiments as described in the paragraphs above, wherein at least one of the secure telephone identity authentication service or the secure telephone identity verification service is used for the caller identity and the device identity.

[0163] In accordance with the example embodiments as described in the paragraphs above, wherein there is creating an emergency session initiation protocol INVITE with a telephone identity; and based on the creating, add a device identity to a session initiation protocol contact header.

[0164] In accordance with the example embodiments as described in the paragraphs above, wherein there is identifying an identity header field identifying the caller identity of an originating session initiation protocol UA.

[0165] In accordance with the example embodiments as described in the paragraphs above 1, wherein there is validating an international mobile station equipment identity parameter of the device identity; and communicating an origination trigger to the identity authentication service for the session initiation protocol INVITE.

[0166] In accordance with the example embodiments as described in the paragraphs above, wherein the identity authentication service is invoked for both the caller identity and the device identity if present in a session initiation protocol contact header.

[0167] In accordance with the example embodiments as described in the paragraphs above, wherein there is using service provider specific means and device validation procedures for determining whether there is legitimacy of a secured telephone identity based on a determined legitimacy of the caller identity and the device identity based on a presence in the session initiation protocol INVITE.

[0168] In accordance with the example embodiments as described in the paragraphs above, wherein there is adding at least one identity header field using the caller identity in an identity header field; and add a new session initiation protocol header for device identity.

[0169] In accordance with the example embodiments as described in the paragraphs above, wherein the identity header field comprises a JSON web token and at least one parameter, wherein the at least one parameter comprises at least one of: info, alg, and Ppt, wherein the JSON web token comprises at least one of a header, payload, or signature, wherein alg indicates the encryption algorithm, wherein Ppt - indicates the token type.

[0170] In accordance with the example embodiments as described in the paragraphs above, wherein alg indicates the encryption algorithm and must be ES256, and wherein Ppt indicates the token type and must be passport.

[0171] In accordance with the example embodiments as described in the paragraphs above, wherein there is communicating with a terminating network side, an updated session initiation protocol INVITE message with a caller identity and a device identity validated.

[0172] In accordance with the example embodiments as described in the paragraphs above, wherein there is routing a call to an egress interconnection border control function (IBCF), wherein the session initiation protocol INVITE is routed over network to network interface (NNI) through a standard inter-domain routing configuration.

[0173] In accordance with the example embodiments as described in the paragraphs above, wherein there is terminating a service provider (SP) ingress, where the interconnection border control function receives the session initiation protocol INVITE over NNI.

[0174] In accordance with the example embodiments as described in the paragraphs above, wherein there is initiating a terminating trigger to the secure telephone identity verification service for the session initiation protocol INVITE to verify the caller identity and the device identity validation results.

[0175] In accordance with the example embodiments as described in the paragraphs above, wherein the terminating uses an“x5u” field in PASSporT Protected header to determine the secure telephone identity certificate repository (STI-CR) uniform resource identifier (URI) and connects to it.

[0176] In accordance with the example embodiments as described in the paragraphs above, wherein the PASSporT Protected header is identifying a service provider that is vouching for the device identity and indicating what information the service provider is attesting to.

[0177] In accordance with the example embodiments as described in the paragraphs above, wherein the attesting is using a “dev Attest” indication comprising one of a “D” or “E” values, wherein the values correspond to “Full Device Attestation” and “No Device Attestation” respectively.

[0178] In accordance with the example embodiments as described in the paragraphs above, wherein the Full Device Attestation “D” means the service provider has validated the device ID and has control over the device, and wherein the No Device Attestation “E” means the service provider could not validate the device identity and the identity seems invalid.

[0179] In accordance with the example embodiments as described in the paragraphs above, wherein the secure telephone identity verification service (STI-VS) uses a new field “x6u” or other value to determine the secure telephone identity certificate repository uniform resource identifier (URI) for device identity validation.

[0180] In accordance with the example embodiments as described in the paragraphs above, wherein there is validating using the secure telephone identity verification service (STI-VS) certificates for the caller identity and the device identity, and extract respective public keys.

[0181] In accordance with the example embodiments as described in the paragraphs above, wherein there is dropping an emergency call for which caller identity is not present and device identity validation fails.

[0182] In accordance with the example embodiments as described in the paragraphs above, wherein there is, based on a secure telephony identity verification result, determining that the call is to be completed with the appropriate “verstat” and “devstaf ’ values.

[0183] In accordance with the example embodiments as described in the paragraphs above, wherein a value for devstat would be one of “D” - device-identity-validation-passed, or “E” - deviceidentity -validation-failed. In accordance with the example embodiments as described in the paragraphs above, wherein there is, based on determined caller identity verification error conditions, defining a device identity verification as a value of 403, New 4xx, or 437.

[0184] In accordance with the example embodiments as described in the paragraphs above, wherein the value of 403 is retained, the value New 4xx indicates one of a “Use devidentity” header or a “Bad device identity info” header or “Invalid devidentity” header, and the value 437 indicates “Unsupported credential”.

[0185] A non-transitory computer-readable medium (MEM 10B as in FIG. 4) storing program code (PROG 10C as in FIG. 4), the program code executed by at least one processor (DP 10A as in FIG. 4) to perform the operations as at least described in the paragraphs above.

[0186] In accordance with an example embodiment of the invention as described above there is an apparatus comprising: means for identifying (one or more transceivers 10D; MEM 10B; PROG 10C; and DP 10A as in FIG. 4) a session initiation protocol INVITE comprising an indication of a caller identity. Means, based on the identifying, for initiating (one or more transceivers 10D; MEM 10B; PROG 10C; and DP 10A as in FIG. 4) an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions (one or more transceivers 10D; MEM 10B; PROG 10C; and DP 10A as in FIG. 4) as an authentication service for device identity; and means for determining (one or more transceivers 10D; MEM 10B; PROG 10C; and DP 10A as in FIG. 4) whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

[0187] In the example aspect of the invention according to the paragraph above, wherein at least the means for identifying, initiating, and determining comprises a non-transitory computer readable medium [MEM 10B as in FIG. 4] encoded with a computer program [PROG 10C as in FIG. 4] executable by at least one processor [DP 10A as in FIG. 4],

[0188] Further, in accordance with example embodiments of the invention there is circuitry for performing operations in accordance with example embodiments of the invention as disclosed herein. This circuitry can include any type of circuitry including content coding circuitry, content decoding circuitry, processing circuitry, image generation circuitry, data analysis circuitry, etc.). Further, this circuitry can include discrete circuitry, application-specific integrated circuitry (ASIC), and / or field-programmable gate array circuitry (FPGA), etc. as well as a processor specifically configured by software to perform the respective function, or dual-core processors with software and corresponding digital signal processors, etc.). Additionally, there are provided necessary inputs to and outputs from the circuitry, the function performed by the circuitry and the interconnection (perhaps via the inputs and outputs) of the circuitry with other components that may include other circuitry in order to perform example embodiments of the invention as described herein.

[0189] In accordance with example embodiments of the invention as disclosed in this application this application, the “circuitry” provided can include at least one or more or all of the following:

[0190] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry);

[0191] (b) combinations of hardware circuits and software, such as (as applicable):

[0192] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware; and

[0193] (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions, such as functions or operations in accordance with example embodiments of the invention as disclosed herein); and

[0194] (c) hardware circuit(s) and or processor(s), such as a microprocessor s) or a portion of a microprocessor s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.”

[0195] In accordance with example embodiments of the invention, there is adequate circuitry for performing at least novel operations in accordance with example embodiments of the invention as disclosed in this application, this 'circuitry' as may be used herein refers to at least the following:

[0196] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry); and

[0197] (b) to combinations of circuits and software (and / or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s) / software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

[0198] (c) to circuits, such as a microprocessor s) or a portion of a microprocessor s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of ' circuitry' applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and / or firmware. The term "circuitry" would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or other network device.

[0199] In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0200] Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0201] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.

[0202] The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the best method and apparatus presently contemplated by the inventors for carrying out the invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of example embodiments of this invention will still fall within the scope of this invention. It should be noted that the terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and / or printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as several non-limiting and non- exhaustive examples.

[0203] Furthermore, some of the features of the preferred embodiments of this invention could be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles of the invention, and not in limitation thereof.

Claims

CLAIMS1. An apparatus, comprising: at least one processor; and at least one memory storing instructions, that when executed by the at least one processor, cause the apparatus at least to: identify a session initiation protocol INVITE comprising an indication of a caller identity; based on the identifying, initiate an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and determine whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

2. The apparatus of claim 1, wherein the identifying comprises extracting the caller identity and extracting the device identity from a contact international mobile station equipment identity parameter of the session initiation protocol and performing validation of both identities.

3. The apparatus of claim 1, wherein the identity authentication service comprises a secure telephone identity authentication service and a secure telephone identity verification service.

4. The apparatus of claim 3, wherein at least one of the secure telephone identity authentication service or the secure telephone identity verification service is used for the caller identity and the device identity.

5. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: create an emergency session initiation protocol INVITE with a telephone identity; and based on the creating, add a device identity to a session initiation protocol contact header.

6. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to:identify an identity header field identifying the caller identity of an originating session initiation protocol UA.

7. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: validate an international mobile station equipment identity parameter of the device identity; and communicate an origination trigger to the identity authentication service for the session initiation protocol INVITE.

8. The apparatus of claim 7, wherein the identity authentication service is invoked for both the caller identity and the device identity if present in a session initiation protocol contact header.

9. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: use service provider specific means and device validation procedures for determining whether there is legitimacy of a secured telephone identity based on a determined legitimacy of the caller identity and the device identity based on a presence in the session initiation protocol INVITE.

10. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: add at least one identity header field using the caller identity in an identity header field; and add a new session initiation protocol header for device identity.

11. The apparatus of claim 10, wherein the identity header field comprises a JSON web token and at least one parameter, wherein the at least one parameter comprises at least one of: info, alg, and Ppt, wherein the JSON web token comprises at least one of a header, payload, or signature, wherein alg indicates the encryption algorithm, wherein Ppt - indicates the token type.

12. The apparatus of claim 11, wherein alg indicates the encryption algorithm and must be ES256, and wherein Ppt indicates the token type and must be passport.

13. The apparatus of claim 1, wherein the at least one memory stores furtherinstructions, that when executed by the at least one processor, further cause the apparatus at least to: communicate with a terminating network side, an updated session initiation protocol INVITE message with a caller identity and a device identity validated.

14. The apparatus of claim 1, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: route a call to an egress interconnection border control function (IBCF), wherein the session initiation protocol INVITE is routed over network to network interface (NNI) through a standard inter-domain routing configuration.

15. The apparatus of claim 14, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: terminate a service provider (SP) ingress, where the interconnection border control function receives the session initiation protocol INVITE over NNI.

16. The apparatus of claim 15, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: initiate a terminating trigger to the secure telephone identity verification service for the session initiation protocol INVITE to verify the caller identity and the device identity validation results.

17. The apparatus of claim 16, wherein the terminating uses an“x5u” field in PASSporT Protected header to determine the secure telephone identity certificate repository (STI-CR) uniform resource identifier (URI) and connects to it.

18. The apparatus of claim 17, wherein the PASSporT Protected header is identifying a service provider that is vouching for the device identity and indicating what information the service provider is attesting to.

19. The apparatus of claim 18, wherein the attesting is using a “dev Attest” indication comprising one of a “D” or “E” values, wherein the values correspond to “Full Device Attestation” and “No Device Attestation” respectively.

20. The apparatus of claim 18, wherein the Full Device Attestation “D” means theservice provider has validated the device ID and has control over the device, and wherein the No Device Attestation “E” means the service provider could not validate the device identity and the identity seems invalid.

21. The apparatus of claim 17, wherein the secure telephone identity verification service (STI-VS) uses a new field “x6u” or other value to determine the secure telephone identity certificate repository uniform resource identifier (URI) for device identity validation.

22. The apparatus of claim 16, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: validate using the secure telephone identity verification service (STI-VS) certificates for the caller identity and the device identity, and extract respective public keys.

23. The apparatus of claim 16, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: drop an emergency call for which caller identity is not present and device identity validation fails.

24. The apparatus of claim 16, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: based on a secure telephony identity verification result, determine that the call is to be completed with the appropriate “verstaf ’ and “devstaf ’ values.

25. The apparatus of claim 24, wherein a value for devstat would be one of: “D” - device-identity -validation-passed, or“E” - device-identity-validation-failed.

26. The apparatus of claim 24, wherein the at least one memory stores further instructions, that when executed by the at least one processor, further cause the apparatus at least to: based on determined caller identity verification error conditions, define a device identity verification as a value of: 403, New 4xx, or 437.

27. The apparatus of claim 26, wherein the value of 403 is retained, the value New4xx indicates one of a “Use devidentity” header or a “Bad device identity info” header or “Invalid devidentity” header, and the value 437 indicates “Unsupported credential”.

28. A method, comprising: identifying a session initiation protocol INVITE comprising an indication of a caller identity; based on the identifying, initiating an origination trigger to an identity authentication service (STI-AS) for the session initiation protocol INVITE, wherein the identity authentication service functions as an authentication service for device identity; and determining whether to accept the session initiation protocol INVITE based on a legitimacy of the caller identity being used in the session initiation protocol INVITE.

Images