ATIS 1000080-2017 Signature-based Handling of Asserted information using toKENs (SHAKEN) Governance Model and Certificate Management.pdf

《ATIS 1000080-2017 Signature-based Handling of Asserted information using toKENs (SHAKEN) Governance Model and Certificate Management.pdf》由会员分享，可在线阅读，更多相关《ATIS 1000080-2017 Signature-based Handling of Asserted information using toKENs (SHAKEN) Governance Model and Certificate Management.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、 JOINT STANDARD ATIS-1000080 JOINT ATIS/SIP FORUM STANDARD SIGNATURE-BASED HANDLING OF ASSERTED INFORMATION USING TOKENS (SHAKEN): GOVERNANCE MODEL AND CERTIFICATE MANAGEMENT ATIS-1000080 ii Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved unde

2、rstanding between providers, customers, and manufacturers. The Packet Technologies and Systems Committee (PTSC) develops and recommends standards and technical reports related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and i

3、nternational standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission to U.S. International Telecommunication Union Telecommunication Sector (ITU-T) and U.S.

4、ITU Radiocommunication Sector (ITU-R) Study Groups or other standards organizations, and reviews for acceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. The SIP Forum is an IP communications industry association t

5、hat engages in numerous activities that promote and advance SIP-based technology, such as the development 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 S

6、IP Forum is also the producer of the annual SIP Network Operators Conference (SIPNOC), 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

7、recommendation for direct IP peering and interoperability between IP Private Branch Exchanges (PBXs) and SIP-based service provider networks. Other important Forum initiatives include work in Video Relay Service (VRS) interoperability, security, Network-to-Network Interoperability (NNI), and SIP and

8、 IPv6. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, PTSC, 1200 G Street NW, Suite 500, Washington, DC 20005, and/or to the SIP Forum, 733 Turnpike Street, Suite 192, North Andover, MA, 01845. The mandatory re

9、quirements are designated by 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. Th

10、e word may denotes an optional capability that could augment the standard. The standard is fully functional without the incorporation of this optional capability. The ATIS/SIP Forum IP-NNI Task Force under the ATIS Packet Technologies and Systems Committee (PTSC) and the SIP Forum Technical Working

11、Group (TWG) was responsible for the development of this document. ATIS-1000080 iii Table of Contents 1 Scope especially a CA that is used as a trust anchor CA RFC 4949. Trust Model: Describes how trust is distributed from Trust Anchors. ATIS-1000080 4 3.2 Acronyms rel=“index“ “status“: “valid“, “con

12、tact“: “mailto:cert-admin-sp-“, “tel:+12155551212“ In the case where the Service Provider wants to change the accounts public/private key pair used for the particular STI-CA, it can use the following request with both the old key and signature, and updated key and signature as follows: POST /acme/ke

13、y-change HTTP/1.1 Host: sti- Content-Type: application/jose+json “protected“: base64url( “alg“: “ES256“, “jwk“: /* old key */, ATIS-1000080 14 “nonce“: “K60BWPrMQG9SDxBDS_xtSw“, “url“: “https:/sti- ), “payload“: base64url( “protected“: base64url( “alg“: “ES256“, “jwk“: /* new key */, “url“: “https:/

14、sti- ), “payload“: base64url( “account“: “https:/sti- “newKey“: /* new key */ ) “signature“: “Xe8B94RD30Azj2ea.8BmZIRtcSKPSd8gU“ ), “signature“: “5TWiqIYQfIDfALQv.x9C2mg8JGPxl5bI4“ 6.3.4 Service Provider Code Token Acquisition Before a Service Provider can create a Certificate Signing Request (CSR)

15、as part of the ACME request to the STI-CA, it shall get a valid and up-to-date Service Provider Code token. The Service Provider Code and Service Provider Code token are used for two things. First, the Service Provider Code token is used as a way to authenticate the Service Provider to the STI-CA as

16、 part of the authorization process defined in ACME and below as part of the application for an STI Certificate in clause 6.3.6. Second, the Service Provider Code is used as part of the CSR so that the Service Provider Code is included in the STI certificate and can be validated by the STI-VS receivi

17、ng a call with a signed Identity header field as defined in the SHAKEN Framework ATIS-1000074. 6.3.4.1 STI-PA Service Provider Code Token Definition The following is a standard JSON Web Token (JWT) RFC 7519. JWT Protected Header “alg“: “ES256“, “typ“: “JWT“, “x5u“: “https:/sti- The “alg” value defin

18、es the algorithm used in the signature of the token. For Service Provider Code tokens, the algorithm shall be “ES256”. The “typ” is set to standard “JWT” value. The “x5u” value defines the URL of the STI certificate of the STI-PA administrator validating the Service Provider Code. ATIS-1000080 15 JW

19、T Payload “sub“: “1234“ “iat“: 14589234802, “nbf“: 14782347239, “exp“: 15832948298 “fingerprint“:“SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3“ The required values for the token are as follows: The “sub” value is the Service Provider Code val

20、ue being validated in the form of an American Standard Code for Information Interchange (ASCII) string. This should be in the form of a JSON array for future extension, however, only a single SPC value is required or will be used for SHAKEN. The “iat” value is the DateTime value of the time and date

21、 the token was issued. The “nbf” value is the DateTime value of the starting time and date that the token is valid. The “exp” value is the DateTime value of the ending time and date that the token expires. The “fingerprint” value is the certificate fingerprint of the ACME credentials the SP used to

22、create an account with the STI-CA, as defined in clause 6.3.3. This shall be in the form as shown in the above example with the algorithm first followed by a space followed by the fingerprint value. A certificate fingerprint is a secure one-way hash of the Distinguished Encoding Rules (DER) form of

23、the certificate. The fingerprint value consists of the name of the hash function, which shall be SHA256 for this specification, followed by the hash value itself. The hash value is represented as a sequence of uppercase hexadecimal bytes, separated by colons. The number of bytes is defined by the ha

24、sh function. JSON Web Token Signature The JSON Web token signature follows the standard JSON Web Signature (JWS)-defined signature string. 6.3.4.2 Service Provider Code Token API Request Definition The following is the HTTP-based POST request that the STI-PA shall provide to a service provider to ma

25、ke the request. POST /sti-pa/account/:id/token Description A request to get a current Service Provider Code token for a Service Provider to use in a CSR to the STI-CA. Request Pass the following information in the request parameter. Filter Description id A unique account id provided to Service Provi

26、der Pass the following information in JSON body. ATIS-1000080 16 Property Type Description fingerprint string The fingerprint of the public key certificate used for STI-CA ACME account creation Example JSON body with fingerprint: “fingerprint“:“SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:

27、19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3“ Response 200 OK Filter Type Description token string A signed Service Provider Code token using the STI-PA certificate with a TTL of the token set by policy 403 - Forbidden Authorization header credentials are invalid. 404 - Invalid account ID Account

28、 ID provided does not exist or does not match credentials in Authorization header. 6.3.5 Application for a Certificate Assuming the Service Provider has a current and up-to-date signed Service Provider Code token, as detailed in the previous clause of this document, it can immediately initiate an ap

29、plication for a new STI certificate to the STI-CA. This process includes two main steps, creation of the CSR and the ACME-based certificate application process as defined in draft-ietf-acme-acme. 6.3.5.1 CSR Construction The general creation of a CSR is defined in RFC 5280 with a format defined as P

30、KCS #10 and defined in RFC 2986. For the SHAKEN certificate framework and ACME-based protocols the overall process and definitions do not change, however there are a few specific uses of and guidelines for CSR attributes defined as part of the SHAKEN Certificate Framework. Following draft-ietf-stir-

31、certificates, a Telephone Number (TN) Authorization List certificate extension shall be included in the CSR. In the case of SHAKEN, the TN Authorization List shall include only one Service Provider Code. A service provider can obtain multiple certificates for a given service provider code or for dif

32、ferent service provider codes. The essential aspect is that the service provider code uniquely identifies a given service provider. As defined in draft-ietf-stir-certificates the OID defined for the TN Authorization list extension will be defined in Structure of Management Information (SMI) Security

33、 for Public Key Infrastructure for X.509 Certificates (PKIX) Certificate Extension registry here: http:/www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 and assigned the value 26. ATIS-1000080 17 6.3.5.2 ACME Based Steps for Application for an STI Certificate Once a

34、 CSR has been generated, the steps in the ACME protocol flow are as follows. It should be noted that it is possible for the ACME client to do a pre-authorization prior to applying for a certificate, in which case processing equivalent to steps 2-5 is done prior to an application for a certificate an

35、d thus the polling period for step 7 is abbreviated. However, that is not the recommended approach for the SHAKEN certificate framework at this time. 1) The application is initiated by the ACME client with an HTTP POST as shown in the following example: POST /acme/new-order HTTP/1.1 Host: sti- Conte

36、nt-Type: application/jose+json “protected“: base64url( “alg“: “ES256“, “kid“: “ https:/sti- “nonce“: “5XJ1L3lEkMG7tR6pA00clA“, “url“: “ https:/sti- ) “payload“: base64url( “csr“: “5jNudRx6Ye4HzKEqT5.FS6aKdZeGsysoCo4H9P“, “notBefore“: “2016-01-01T00:00:00Z“, “notAfter“: “2016-01-08T00:00:00Z“ ), “sig

37、nature“: “H6ZXtGjTZyUnPeKn.wEA4TklBdh3e454g“ The CSR is inserted into the JWS payload along with the requested time frame of the certificate application. The request is signed using the private key used in the ACME registration with the STI-CA. 2) The STI-CA ACME server shall look into the CSR reque

38、st as standard process. However, for the SHAKEN certificate management specifically, different from a typical domain validation, it shall use the specific “type” identifier of “TNAuthList” and include a key of “value” which is a Service Provider Code. An example of this identifier is: “identifier“:

39、“type“: “TNAuthList“, “value“:“1234“ This identifier will be used in the authorization challenge that will be shown incorporated into the authorization object below. This service provider code shall correspond to the service provider code provided in the STI-PA token. 3) Upon successful processing o

40、f the application request, a challenge authorization response from the ACME server is sent back, as shown in the following example: HTTP/1.1 201 Created Replay-Nonce: MYAuvOpaoIiywTezizk5vw Location: https:/sti- “status“: “pending“, ATIS-1000080 18 “expires“: “2015-03-01T14:09:00Z“, “csr“: “jcRf4uXr

41、a7FGYW5ZMewvV.rhlnznwy8YbpMGqwidEXfE“, “notBefore“: “2016-01-01T00:00:00Z“, “notAfter“: “2016-01-08T00:00:00Z“, “authorizations“: “https:/sti- 4) The SP-KMS ACME client shall respond to the challenge before it expires, but for the SHAKEN framework, the ACME client shall be prepared to respond to the

42、 challenge using the current Service Provider Code token retrieved in preparation for the certificate application process. The ACME client shall first retrieve the authorization challenge details with a HTTP GET, an example of which follows: GET /acme/authz/1234 HTTP/1.1 Host: sti- HTTP/1.1 200 OK C

43、ontent-Type: application/json Link: ;rel=“index“ “status“: “pending“, “identifier“: “type“: “TNAuthList“, “value“: “1234“ , “challenges“: “type“: “spc-token“, “url“: “https:/sti- “token“: “DGyRejmCefe7v4NfDGDKfA“ , NOTE: This includes the identifier specific to the SHAKEN certificate framework const

44、ructed as part of the certificate application request and CSR processing. The response shall also include the SHAKEN specific challenge type of “token”. 5) Using the URL of the challenge, the ACME client shall respond to this challenge with the Service Provider Code token to validate the Service Pro

45、viders authority to request an STI certificate. An HTTP POST shall be sent back in the form as follows: POST /acme/authz/1234/0 HTTP/1.1 Host: sti- Content-Type: application/jose+json “protected“: base64url( “alg“: “ES256“, ATIS-1000080 19 “kid“: “https:/sti- “nonce“: “Q_s3MWoqT05TrdkM2MTDcw“, “url“

46、: “https:/sti- ), “payload“: base64url( “type“: “spc-token“, “keyAuthorization“: “IlirfxKKXA.vb29HhjjLPSggwiE“ ), “signature“: “9cbg5JO1Gf5YLjjz.SpkUfcdPai9uVYYQ“ This challenge response JWS payload shall include the SHAKEN certificate framework specific challenge type of “spc-token” and the “keyAut

47、horization” field containing the “token” for the challenge concatenated with the value of the Service Provider Code token. 6) Once the challenge response is sent to the STI-CA ACME server, the server shall validate the “token” challenge by verifying the Service Provider Code token. As a part of that

48、 token validation, the STI-CA needs to retrieve the public key of the STI-PA, as identified in the x5u protected header value in the token. Once successful, the state of the challenge shall be changed from “pending” to “valid”. 7) Finally, the SHAKEN ACME client shall poll the status of the authorization until it verifies that the challenge is set to the “valid” status. This is performed with the following HTTP GET request: GET /acme/authz/1234_HTTP/1.1 Host: sti- HTTP/1.1 200 O