ATIS 1000084-2018 Technical Report on Operational and Management Considerations for SHAKEN STI Certification Authorities and Policy Administrators.pdf

1、 JOINT STANDARD ATIS-1000084 Technical Report on Operational and Management Considerations for SHAKEN STI Certification Authorities and Policy Administrators As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together

2、the top global ICT companies 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

3、 security, network evolution, 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 inter

4、operability testing. ATIS is 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 the International Telecommunic

5、ation 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 a leading IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as th

6、e development of industry recommendations; interoperability testing events and special workshops, educational activities, and general promotion of IP communications standards, services, and technology for service provider, enterprise, and governmental applications. The SIP Forum is also the producer

7、 of the annual SIPNOC conferences (for SIP Network Operators Conference), focused on the technical requirements of the service provider community. One of the Forums technical activities is the development of the SIPconnect Technical Recommendation a standards-based SIP trunking recommendation that p

8、rovides detailed guidelines for direct IP peering and interoperability between IP PBXs and SIP-based service provider networks, and the SIPconnect Certification Testing Program, a unique certification testing program that includes a certification test suite and test platform, and an associated “SIPc

9、onnect Certified” logo program that provides an official “seal of certification” for companies products and services that have officially achieved conformance with the SIPconnect specification. Other important Forum initiatives include work in security, SIP and IPv6, and IP-based Network-to-Network

10、Interconnection (IP-NNI). For more information about all SIP Forum initiatives, please visit: Notice of Disclaimer (b) ensuring the administration of those policies; and (c) approving any cross-certification or interoperability agreements with CAs external to the PKI and any related policy mappings.

11、 The PMA may also be the accreditor for the PKI as a whole or for some of its components or applications. Private Key: In asymmetric cryptography, the private key is kept secret by the end-entity. The private key can be used for both encryption and decryption. RFC 4949 Public Key: The publicly discl

12、osable component of a pair of cryptographic keys used for asymmetric cryptography. RFC 4949 Public Key Infrastructure (PKI): The set of hardware, software, personnel, policy, and procedures used by a CA to issue and manage certificates. RFC 4949 Relying party: A system entity that depends on the val

13、idity of information (such as another entitys public key value) provided by a certificate. RFC 5217 Root CA: A CA that is directly trusted by an end-entity. See also Trust Anchor CA and Trusted CA. RFC 4949 ATIS-1000084 4 Service Provider Code: In the context of this document, this term refers to an

14、y unique identifier that is allocated by a Regulatory and/or administrative entity to a service provider. In the US and Canada this would be a Company Code as defined in ATIS-0300251.2007. Signature: Created by signing the message using the private key. It ensures the identity of the sender and the

15、integrity of the data. RFC 4949 Subscriber: A user that is registered in a PKI and, therefore, can be named in the “subject“ field of a certificate issued by a CA in that PKI. RFC 4949 Telephone Identity: An identifier associated with an originator of a telephone call. In the context of the SHAKEN f

16、ramework, this is a SIP identity (e.g., a SIP URI or a TEL URI) from which a telephone number can be derived. Trust Anchor: An established point of trust (usually based on the authority of some person, office, or organization) from which a certificate user begins the validation of a certification pa

17、th. The combination of a trusted public key and the name of the entity to which the corresponding private key belongs. RFC 4949 Trust Anchor CA: A CA that is the subject of a trust anchor certificate or otherwise establishes a trust anchor key. See also Root CA and Trusted CA. RFC 4949 Trust Authori

18、ty: An entity that manages a Trust List for use by one or more relying parties. RFC 5217 Trusted CA: A CA upon which a certificate user relies on for issuing valid certificates; especially a CA that is used as a trust anchor CA. RFC 4949 Trust List: A set of one or more trust anchors used by a relyi

19、ng party to explicitly trust one or more PKIs. RFC 5217 Trust Model: Describes how trust is distributed from Trust Anchors. 3.2 Acronyms & Abbreviations ACME Automated Certificate Management Environment (Protocol) ATIS Alliance for Telecommunications Industry Solutions CA Certification Authority CRL

20、 Certificate Revocation List CP Certificate Policy CPS Certification Practice Statement CSR Certificate Signing Request HTTPS Hypertext Transfer Protocol Secure IETF Internet Engineering Task Force JSON JavaScript Object Notation JWT JSON Web Token NNI Network-to-Network Interface NRRA National/Regi

21、onal Regulatory Authority NRRO National/Regional Regulatory Oversight OCSP Online Certificate Status Protocol PKI Public Key Infrastructure PKIX Public Key Infrastructure for X.509 Certificates PMA Policy Management Authority PTSC ATIS Packet Technologies and Systems Committee SHAKEN Signature-based

22、 Handling of Asserted information using toKENs SIP Session Initiation Protocol ATIS-1000084 5 SKS Secure Key Store SP Service Provider SP-KMS SP Key Management Server STI Secure Telephone Identity STI-AS Secure Telephone Identity Authentication Service STI-CA Secure Telephone Identity Certification

23、Authority STI-CR Secure Telephone Identity Certificate Repository STI-GA Secure Telephone Identity Governance Authority STI-PA Secure Telephone Identity Policy Administrator STI-VS Secure Telephone Identity Verification Service STIR Secure Telephone Identity Revisited TN Telephone Number URI Uniform

24、 Resource Identifier VoIP Voice over Internet Protocol 4 Overview The governance model in ATIS-1000080 introduces an STI-Policy Administrator that bridges the governance aspects of STI with the protocol requirements to support digital certificates RFC 5280 which are used by the SHAKEN framework ATIS

25、-1000074 to authenticate and verify telephone identities. Per the governance model and certificate management framework, the STI-PA maintains a list of trusted STI-CAs to be provided to the Authentication and Verification services. The STI-PA also provides for management of the Service Providers aut

26、horized to obtain certificates and provide STI functionality within the VoIP network. This document effectively extends the roles and functions of the STI-PA beyond those defined in ATIS-1000080 per the following diagram: ATIS-1000084 6 Figure 4.1 Governance Model for Certificate Management Clause 5

27、 of this document describes a Trust Authority Policy that establishes the relationship between the STI Governance Authority (STI-GA) and the STI-PAs operational responsibilities. In the context of SHAKEN, the approval of STI-CAs follows standard PKI practices, as outlined in RFC 3647, including the

28、definition of Certificate Policies as described in clause 6. The STI-PA defines a CP and the STI-CAs provide a CPS describing their adherence to the CP during the approval process. Details on the management of the list of STI-CAs are provided in clause 7 and the management of the authorized Service

29、Providers in clause 8. 5 STI-PA as Trust Authority As described in ATIS-1000080, the STI-GA is responsible for: Establishing policies governing which entities can manage the PKI and issue STI certificates. Defining the policies and procedures governing which entities can acquire STI certificates. AT

30、IS-1000084 7 The STI-PA applies and enforces any policies established by the STI-GA in its role as the Trust Authority. In this role, the STI-PA serves as the Trust Authority to the relying parties in the PKI. The STI-PA maintains the Trust List of authorized STI-CAs which each establish their own P

31、KI for issuing certificates, per the following diagram: Figure 5.1 Trust Model Each of the STI-CAs operates its own Root CA and PKI infrastructure similar to following diagram: Figure 5.2 PKI Model In a multi-stakeholder PKI model, typically a Policy Management Authority (PMA) is established, compri

32、sing a set of people responsible for ensuring that the established policies are being adhered to. The set is typically comprised of the stakeholders (e.g., service providers in the case of SHAKEN). The PMA defines a CP to be supported by the approved STI-CAs. The STI-CAs provide a CPS describing the

33、ir adherence to the CP during the approval process. An outline of the CP to be supported by the STI-CAs is provided in clause 6.1. ATIS-1000084 8 The STI-PA defines a Trust Authority Policy, including the following: STI-CAs shall not inherit trust from other STI-CAs in the deployment of the SHAKEN f

34、ramework (i.e., the STI-PA is the only trust authority). To preclude this, policy mapping shall be inhibited. An STI-PA may remove an STI-CA from the list of trusted STI-CAs based on specific criteria such as a failure to comply with the CP established by the STI-PA or other criteria as defined by t

35、he STI-GA. Typically, compliance is audited by the PMA and thus guidelines must be established for the timeframe in which an identified problem must be resolved. Other policies established by the STI-GA for operation of the STI-PA. Beyond the role of managing the list of trusted STI-CAs, the STI-PA

36、also serves as a Trust Anchor to the relying parties in the PKI by providing service providers with the Service Provider Code Token that is used by the STI-CA in determining whether the Service Provider requesting issuance of certificates is authorized. In the context of SHAKEN, whether an entity is

37、 authorized to acquire STI certificates is based on the Service Provider being assigned a service provider code by a Regulatory and/or administrative entity. Per ATIS-1000080, the STI-GA can define other policies and procedures governing which entities can acquire STI Certificates. The following dia

38、gram summarizes the roles and responsibilities associated with the STI-PA, including the interfaces to other functional elements: Figure 5.3 STI-PA Roles and Functional Interfaces 6 Certificate Policy & Certification Practice Statements The STI-PA defines a CP that prescribes the policies to be foll

39、owed by an STI-CA within the SHAKEN framework. Within the SHAKEN framework, the STI-PA imposes some of these policies based on its role as the Trust Authority. The STI-CAs shall produce Certification Practice Statements defining the manner in which they abide by the Certificate Policy, aligning with

40、 their role as a CA issuing STI certificates. ATIS-1000084 9 6.1 Certificate Policy A CP provides a set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements RFC 3647. It contains the business, legal, and te

41、chnical requirements for certificate approval, management, use, revocation, and renewal. The following reference documents provide additional information about writing the CP and CPS: NIST SP 800-57, Recommendation for Key Management3 o Part 1 Revision 4: General o Part 2: Best Practices for Key Man

42、agement Organization o Part 3 Revision 1: Application-Specific Key Management Guidance, section 2 on PKI. FIPS PUB 140-2, Security Requirements for Cryptographic Modules3. The CP contains policies for the STI-PA, STI-CA, STI-CR, subscribers, and relying parties. RFC 3647 contains the following outli

43、ne for the contents of the Certificate Policy. The STI-PA shall address the following 9 topics: 1. Introduction 2. Publication and Repository 3. Identification and Authentication 4. Certificate Life-Cycle Operational Requirements 5. Facilities, Management, and Operational Controls 6. Technical Secur

44、ity Controls 7. Certificate, CRL, and OCSP Profile 8. Compliance audit 9. Other Business and Legal Matters. 6.1.1 Introduction This component of the CP provides the set of provisions, and the entities and application (SHAKEN) for which the CP is targeted. 6.1.1.1 Overview The CP shall provide an ove

45、rview of the relationship between the CP and CPS, and the target audience. This section shall include the following statement: “This CP conforms to Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Internet Engineering Task Force (IETF) RFC 3647.” 6.1.

46、1.2 Document Name and Identification The CP shall provide an official title. The CP shall identify certificate policies, levels of assurance, and object identifier (OID) values that will be included in certificates issued by the STI-CAs. The CP shall contain the TNAuthList OID as defined in RFC 8226

47、. 6.1.1.3 PKI Participants The CP provides information on the PKI participants. This shall include Certification Authorities, Registration Authorities, Subscribers, and Relying Parties. The Root CA is recommended to be an offline CA that only issues 3 This document is available from the National Ins

48、titute of Standards and Technology (NIST). . ATIS-1000084 10 certificates to intermediate CAs. In the context of SHAKEN, service providers are the subscribers and relying parties. 6.1.1.4 Certificate Usage The CP shall include the appropriate certificate uses and prohibited certificate uses. The CP

49、shall specify that the certificates are used for SHAKEN. 6.1.1.5 Policy Administration The STI-PA administers the CP. The CP shall provide contact information for STI-CAs writing their CPSs. The CP shall include additional information for reviewing the CPS compliance with the CP. The CP shall document the CP approval procedures. 6.1.1.6 Definitions and Acronyms The CP shall include the definitions and acronyms used in the CP. This section can also reference an appendix with the information. 6.1.2 Publication