ATIS 1000074-2017 Joint ATIS SIP Forum STandard - Signature-based Handling of Asserted information using toKENs (SHAKEN).pdf

《ATIS 1000074-2017 Joint ATIS SIP Forum STandard - Signature-based Handling of Asserted information using toKENs (SHAKEN).pdf》由会员分享，可在线阅读，更多相关《ATIS 1000074-2017 Joint ATIS SIP Forum STandard - Signature-based Handling of Asserted information using toKENs (SHAKEN).pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、 JOINT STANDARD ATIS-1000074 JOINT ATIS/SIP FORUM STANDARD SIGNATURE-BASED HANDLING OF ASSERTED INFORMATION USING TOKENS (SHAKEN) As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies

2、 to advance the industrys most pressing business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution

3、, quality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is

4、 accredited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of and major U.S. contributor to the International Telecommun

5、ication Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. The SIP Forum is an IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as the dev

6、elopment of industry recommendations, the SIPit, SIPconnect-IT and RTCWeb-it interoperability testing events, special workshops, educational seminars, and general promotion of SIP in the industry. The SIP Forum is also the producer of the annual SIPNOC conferences (for SIP Network Operators Conferen

7、ce), focused on the technical requirements of the service provider community. One of the Forums notable technical activities is the development of the SIPconnect Technical Recommendation a standards-based SIP trunking recommendation for direct IP peering and interoperability between IP PBXs and SIP-

8、based service provider networks. Other important Forum initiatives include work in VRS interoperability, security, NNI, and SIP and IPv6. Notice of Disclaimer an originating IMS network hosted by Service Provider A, and a terminating IMS network hosted by Service Provider B. Figure 4.1 SHAKEN Refere

9、nce Architecture This SHAKEN reference architecture includes the following elements: SIP UA The SIP User Agent authenticated by the service provider network. When the SIP UA is under direct management control of the telephone service provider, the service provider network can assert the calling part

10、y identity in originating SIP INVITE requests initiated by the SIP UA. ATIS-1000074 5 IMS/Call Session Control Function (CSCF) This component represents the SIP registrar and routing function. It also has a SIP application server interface. Interconnection Border Control Function (IBCF)/Transition G

11、ateway (TrGW) This function is at the edge of the service provider network and represents the Network-to-Network Interface (NNI) or peering interconnection point between telephone service providers. It is the ingress and egress point for SIP calls between providers. Authentication Service (STI-AS) T

12、he SIP application server that performs the function of the authentication service defined in draft-ietf-stir-rfc4474bis. It should either itself be highly secured and contain the Secure Key Store (SKS) of secret private key(s) or have an authenticated, Transport Layer Security (TLS)-encrypted inter

13、face to the SKS that stores the secret private key(s) used to create PASSporT signatures. Verification Service (STI-VS) The SIP application server that performs the function of the verification service defined in draft-ietf-stir-rfc4474bis. It has an Hypertext Transfer Protocol Secure (HTTPS) interf

14、ace to the Secure Telephone Identity Certificate Repository that is referenced in the Identity header field to retrieve the provider public key certificate. Call Validation Treatment (CVT) This is a logical function that could be an application server function or a third party application for applyi

15、ng anti-spoofing mitigation techniques once the signature is positively or negatively verified. The CVT can also provide information in its response that indicates how the results of the verification should be displayed to the called user. SKS The Secure Key Store is a logical highly secure element

16、that stores secret private key(s) for the authentication service (STI-AS) to access. Certificate Provisioning Service A logical service used to provision certificate(s) used for STI. Secure Telephone Identity Certificate Repository (STI-CR) This represents the publically accessible store for public

17、key certificates. This should be an HTTPS web service that can be validated back to the owner of the public key certificate. The focus of this document is on the STI-AS and STI-VS functionality and the relevant SIP signaling and interfaces. Detailed functionality for the Certificate Provisioning Ser

18、vice, the STI-CR, the SKS and the CVT will be provided in separate document(s). 4.3 SHAKEN Call Flow Figure 4.2 SHAKEN Reference Call Flow 1. 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 orig

19、inating provider adds a P-Asserted-Identity header field asserting the Caller ID of the originating SIP UA. The CSCF then initiates an originating trigger to the STI-AS for the INVITE. ATIS-1000074 6 NOTE: The STI-AS must be invoked after originating call processing. 3. The STI-AS in the originating

20、 SP (i.e., Service Provider A) first determines through service provider-specific means the legitimacy 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

21、the INVITE and adds an Identity header field per draft-ietf-stir-rfc4474bis using the Caller 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

22、routed over the NNI through the standard inter-domain routing configuration. 8. The terminating 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 termin

23、ating call processing. 10. The terminating SP STI-VS uses the “info” parameter information in 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 Sec

24、tion 5.3.1 for details) and then extracts the public key. It constructs the draft-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 C

25、VT is an optional function that can be invoked to perform call spam analytics or other mitigation techniques and return a response related to what should be signaled to the user for a legitimate or illegitimate call. The CVT may be integrated in the service provider network or outside the service pr

26、ovider network by a third party. 13. Depending 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

27、 call to the terminating SIP UA. NOTE: Error cases where verification fails are discussed in Section 6. 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. 5 STI SIP Procedures Both draft-ietf-s

28、tir-4474bis and draft-ietf-stir-passport define a base set of procedures for how STI fits into the SIP call flow. Draft-ietf-stir-rfc4474bis defines an authentication service, corresponding to STI-AS in the SHAKEN reference architecture, as well as a verification service or STI-VS. This section will

29、 detail the procedures required for the STI-AS to create the required identity header. 5.1 PASSporT Token Overview STI as defined in draft-ietf-stir-passport specifies the process of the PASSporT token. PASSporT tokens have the following form: A protected header with the value BASE64URL(UTF(JWS Prot

30、ected Header). A payload with the value BASE64URL(JWS Payload). A signature with the value BASE64URL(JWS Signature). An example of each is as follows: Protected Header “typ“:“passport“, ATIS-1000074 7 “alg“:“ES256“, “x5u“:“https:/cert.example.org/passport.crt“ Payload “iat“:“1443208345“, “orig“:“tn”

31、:“12155551212“, “dest“:“tn”:“12155551213“ draft-ietf-stir-passport has specific examples of a PASSporT token. 5.2 4474bis Authentication procedures 5.2.1 PASSporT cause=436 ;text=“Bad Identity Info“ 2Report and Order (Rbranch=z9hG4bK-524287-1-77ba17085d60f141;rport Max-Forwards: 69 Contact: To: From

32、: “Alice“;tag=614bdb40 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI P-Asserted-Identity: “Alice“, CSeq: 2 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp Date: Tue, 16 Aug 2016 19:23:38 GMT Identity: eyJhbGciOiJFUzI1

33、NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydCJ9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiIxNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6nY4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA;info=;alg=ES256 Content-Length: 153 v=0 o=- 13103070023943130 1 IN IP4 10.36.78.177 c=IN IP4 10.36.78.177 t=0 0 m=audio 54242 RTP/AVP 0 a=sendrecv