ATIS 0300116-2016 Interoperability Standards between Next Generation Networks (NGN) for Signature-Based Handling of Asserted information Using Tokens (SHAKEN).pdf

《ATIS 0300116-2016 Interoperability Standards between Next Generation Networks (NGN) for Signature-Based Handling of Asserted information Using Tokens (SHAKEN).pdf》由会员分享，可在线阅读，更多相关《ATIS 0300116-2016 Interoperability Standards between Next Generation Networks (NGN) for Signature-Based Handling of Asserted information Using Tokens (SHAKEN).pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、ATIS-0300116 ATIS Standard on Interoperability Standards between Next Generation Networks (NGN) for Signature-Based Handling of Asserted information Using Tokens (SHAKEN) Alliance for Telecommunications Industry Solutions Approved December 5, 2016 Abstract This document is intended to provide Next G

2、eneration Network (NGN) telephone service providers (SPs) with a framework and guidance for interoperability as calls process through their networks implementing Signature-Based Handling of Asserted Information Using Tokens (SHAKEN) technologies to ensure the validation as well as the completion of

3、legitimate calls and the mitigation of illegitimate spoofing of telephone identities. ATIS-0300116 ii Foreword The Alliance for Telecommunications Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Next Generation Interconne

4、ction Interoperability Forum (NGIIF) addresses next generation network interconnection and interoperability topics associated with emerging technologies. Specifically, it develops operational procedures that involve the network aspects of architecture, disaster preparedness, installation, maintenanc

5、e, management, reliability, routing, security, and testing between network operators. In addition, the NGIIF addresses issues that impact the interconnection of existing and next generation networks and facilitate the transition to emerging technologies. The mandatory requirements are designated by

6、the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal currently identifiable as having distinct compatibility or performance advantages. The word may denotes an optiona

7、l capability that could augment the standard. The standard is fully functional without the incorporation of this optional capability. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, NGIIF, 1200 G Street NW, Suit

8、e 500, Washington, DC 20005. At the time of consensus on this document, NGIIF, which was responsible for its development, had the following leadership: Amy Hindman, Co-Chair (Verizon Wireless) Mary Retka, Co-Chair (CenturyLink) ATIS-0300116 iii Table of Contents 1 Scope and Purpose . 1 1.1 Scope . 1

9、 1.2 Purpose . 1 2 Normative References . 1 3 Definitions, Acronyms, and Abbreviations . 2 3.1 Definitions 2 3.2 Acronyms 3GPP TS 29.165 V11.5.0 (2012-12). 83GPP TS 33.234 V023.0 (2002-11); 3GPP TS 29.165 V11.5.0 (2012-12). ATIS-0300116 3 JSON JavaScript Object Notation NGIIF Next Generation Interco

10、nnection Interoperability Forum NGN Next Generation Network NNI Network-to-Network Interface NS/EP National Security and Emergency Preparedness OCSP Online Certificate Status Protocol PASSporT Persona Assertion Token PBX Private Branch Exchange PSTN Public Switched Telephone Network PKI Public Key I

11、nfrastructure R an originating IMS network hosted by Service Provider A, and a terminating IMS network hosted by Service Provider B.18Figure 4.1 SHAKEN Reference Architecture19This SHAKEN reference architecture includes the following elements: SIP UA The SIP User Agent authenticated by the service p

12、rovider network. When the SIP UA is under direct management control of the telephone service provider, the service provider network can assert the calling party identity in originating SIP INVITE requests initiated by the SIP UA. IMS/Call Session Control Function (CSCF) This component represents the

13、 SIP registrar and routing function. It also has a SIP application server interface. Interconnection Border Control Function (IBCF)/Transition Gateway (TrGW) This function is at the edge of the service provider network and represents the Network-to-Network Interface (NNI) or peering interconnection

14、point between telephone service providers. It is the ingress and egress point for SIP calls between providers. Authentication Service (STI-AS) The SIP application server that performs the function of the authentication service defined in draft-ietf-stir-rfc4474bis. It should either itself be highly

15、secured and contain the Secure Key Store (SKS) of secret private key(s) or have an authenticated, Transport Layer Security (TLS)-encrypted interface to the SKS that stores the secret private key(s) used to create PASSporT signatures. Verification Service (STI-VS) The SIP application server that perf

16、orms the function of the verification service defined in draft-ietf-stir-rfc4474bis. It has an Hypertext Transfer Protocol Secure (HTTPS) interface to the Secure Telephone Identity Certificate Repository that is referenced in the Identity header field to retrieve the provider public key certificate.

17、 Call Validation Treatment (CVT) This is a logical function that could be an application server function or a third party application for applying anti-spoofing mitigation techniques once the signature is positively or negatively verified. The CVT can also provide information in its response that in

18、dicates how the results of the verification should be displayed to the called user. 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. Certificate Provisioning Service A logical service used to provision ce

19、rtificate(s) used for STI. 18ibid. 19ibid. ATIS-0300116 7 Secure Telephone Identity Certificate Repository (STI-CR) This represents the publically accessible store for public key certificates. This should be an HTTPS web service that can be validated back to the owner of the public key certificate.2

20、04.4 SHAKEN Call Flow Figure 4.2 SHAKEN Reference Call Flow211. The originating SIP UA, which first REGISTERs and is authenticated to the CSCF, creates a SIP INVITE with a telephone number identity. 2. The CSCF of the originating provider adds a P-Asserted-Identity header field asserting the Caller

21、ID of the originating SIP UA. The CSCF then initiates an originating trigger to the STI-AS for the INVITE. NOTE: The STI-AS must be invoked after originating call processing. 3. The STI-AS in the originating SP (i.e., Service Provider A) first determines through service provider-specific means the l

22、egitimacy of the telephone number identity being used in the INVITE. The STI-AS then securely requests its private key from the SKS. 4. The SKS provides the private key in the response, and the STI-AS signs the INVITE and adds an Identity header field per draft-ietf-stir-rfc4474bis using the Caller

23、ID in the P-Asserted-Identity header field. 5. The STI-AS passes the INVITE back to the SP As CSCF. 6. The originating CSCF, through standard resolution, routes the call to the egress IBCF. 7. The INVITE is routed over the NNI through the standard inter-domain routing configuration. 8. The terminati

24、ng SPs (Service Provider B) ingress IBCF receives the INVITE over the NNI. 9. The terminating CSCF initiates a terminating trigger to the STI-VS for the INVITE. NOTE: The STI-VS must be invoked before terminating call processing. 10. The terminating SP STI-VS uses the “info” parameter information in

25、 the Identity header field per draft-ietf-stir-rfc4474bis to determine the STI-CR Uniform Resource Identifier (URI) and makes an HTTPS request to the STI-CR. 11. The STI-VS validates the certificate (see Section 5.3.1 of ATIS-1000074 for details) and then extracts the public key. It constructs the d

26、raft-ietf-stir-rfc4474bis 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 STI-AS. 12. The CVT is an optional function that can be invoked to perform call spam analytics

27、 or other mitigation techniques and return a response related to what should be signaled to the user for a legitimate or 20ibid. 21ibid. ATIS-0300116 8 illegitimate call. The CVT may be integrated in the service provider network or outside the service provider network by a third party. 13. Depending

28、 on the result of the STI validation, the STI-VS determines that the call is to be completed with any appropriate indicator (that may be defined outside of this document) and the INVITE is passed back to the terminating CSCF which continues to set up the call to the terminating SIP UA. NOTE: Error c

29、ases where verification fails are discussed in Section 6 of ATIS-1000074 and Section 6.2 of this document. 14. The terminating SIP UA receives the INVITE and normal SIP processing of the call continues, returning “200 OK” or optionally setting up media end-to-end.224.5 4474bis Verification Procedure

30、s Draft-ietf-stir-rfc4474bis defines the procedures for verification services including the methods used to verify the signature contained in the Identity header field.234.5.1 PASSporT and Identity Header Verification The certificate referenced in the “info” parameter of the Identity header field sh

31、all be validated by performing the following: Check the certificates validity using the Basic Path Validation algorithm defined in the X.509 certificate standard (RFC 5280). Check that the certificate is not revoked using CRLs and/or OCSP. The verifier validates that the PASSporT token provided in t

32、he Identity header of the INVITE includes all of the baseline claims, as well as the SHAKEN extension claims. The verifier shall also follow the draft-ietf-stir-rfc4474bis-defined verification procedures to check the corresponding date, originating identity (i.e., the originating telephone number) a

33、nd destination identities (i.e., the terminating telephone numbers). The “orig” claim and “dest” claim shall be of type “tn”. The “orig” claim “tn” value validation shall be performed as follows: The P-Asserted-Identity header field value shall be checked as the telephone identity to be validated if

34、 present, otherwise the From header field value shall also be checked. If there are two P-Asserted-Identity values, the verification service shall check each of them until it finds one that is valid. NOTE: As discussed in draft-ietf-stir-rfc4474bis, call features such as call forwarding can cause ca

35、lls to reach a destination different from the number in the To header field. The problem of determining whether or not these call features or other B2BUA functions have been used legitimately is out of scope of STIR. It is expected that future SHAKEN documents will address these use cases.244.5.2 Ve

36、rification Error Conditions If the authentication service functions correctly, and the certificate is valid and available to the verification service, the SIP message can be delivered successfully. However, if these conditions are not satisfied, errors can be generated as defined draft-ietf-stir-rfc

37、4474bis. This section identifies important error conditions and specifies procedurally what should happen if they occur. Error handling procedures should consider how best to always deliver the call per current regulatory requirements25while providing diagnostic information back to the signer. 22ibi

38、d. 23ibid. 24ibid. 25Report and Order (Rcause=436 ;text=“Bad Identity Info“ In addition, if any of the base claims or SHAKEN extension claims are missing from the PASSporT token claims, the verification service shall treat this as a 438 Invalid Identity Header error and proceed as defined above.265

39、Certificates 5.1 Certificate Assertion in Calls Processed Across Multiple Networks With the implementation of SHAKEN, it is expected that there will be the addition of the identity header with the signature. ATIS-1000074 expects that for the majority of calls, the originator network will sign and au

40、thenticate the calling party TN where the originating SP holds the telephone number and has explicitly authenticated the origination of the telephone call from the device. There are however other scenarios to consider: The originating network provider signs and indirectly authenticates the calling p

41、arty TN (where they have a third party e.g., reseller to whom they have provided their numbering resources.) The originating network provider signs the call but does not have any authority for calling party TN (e.g., roaming). Calls that originate on un-trusted networks (e.g., legacy TDM networks or

42、 networks where the provider is not certified). 26ATIS-1000074, Signature-based Handling of Asserted information using Tokens (SHAKEN). ATIS-0300116 10 5.2 Attestation Indicator (“attest”) This indicator allows for both identifying the service provider that is vouching for the call as well as clearl

43、y indicating what information the service provider is attesting to. In the SHAKEN framework we define the following three levels of attestation: A. Full Attestation: The signing provider shall satisfy all of the following conditions: Is responsible for the origination of the call onto the IP based s

44、ervice provider voice network. Has a direct authenticated relationship with the customer and can identify the customer. Has established a verified association with the telephone number used for the call. NOTE 1: The signing provider is asserting that their customer can “legitimately” use the number

45、that appears as the calling party (i.e., the Caller ID). The legitimacy of the telephone number(s) the originator of the call can use is subject to signer-specific policy, but could use mechanisms such as the following: The number was assigned to this customer by the signing service provider. This n

46、umber is one of a range of numbers assigned to an enterprise or wholesale customer. The signing service provider has ascertained that the customer is authorized to use a number (e.g., by business agreement or evidence the customer has access to use the number). This includes numbers assigned by anot

47、her service provider. The number is not permanently assigned to an individual customer but the signing provider can track the use of the number by a customer for certain calls or during a certain timeframe. NOTE 2: Ultimately it is up to service provider policy to decide what constitutes “legitimate

48、 right to assert a telephone number” but the service providers reputation may be directly dependent on how rigorous they have been in making this assertion. B. Partial Attestation: The signing provider shall satisfy all of the following conditions: Is responsible for the origination of the call onto

49、 its IP-based voice network. Has a direct authenticated relationship with the customer and can identify the customer. Has NOT established a verified association with the telephone number being used for the call. NOTE: When partial attestation is used, each customer will have a unique origination identifier created and managed by the service provider, but the intention is that it will not be possible to reverse engineer the identity of the customer purely from the identifier or signature. As described in se