idnits 2.17.1 draft-ietf-acme-service-provider-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '... [RFC7515]. It is RECOMMENDED that the lifetime of the service...' RFC 2119 keyword, line 175: '... JWT Protected Header MUST include the...' RFC 2119 keyword, line 179: '...der Code tokens, the algorithm MUST be...' RFC 2119 keyword, line 187: '...ode token JWT Payload MUST include the...' RFC 2119 keyword, line 209: '... MUST be stripped before doing...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 == Outdated reference: A later version (-01) exists of draft-ietf-acme-telephone-00 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Barnes 3 Internet-Draft iconectiv 4 Intended status: Informational C. Wendt 5 Expires: May 3, 2018 Comcast 6 October 30, 2017 8 ACME Identifiers and Challenges for VoIP Service Providers 9 draft-ietf-acme-service-provider-02 11 Abstract 13 This document specifies identifiers and challenges required to enable 14 the Automated Certificate Management Environment (ACME) to issue 15 certificates for VoIP service providers to support Secure Telephony 16 Identity (STI). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 3, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Identifier for Service Provider Codes . . . . . . . . . . . . 3 55 4. Challenges for Service Providers . . . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. ACME TNAuthList Identifier . . . . . . . . . . . . . . . 6 58 5.2. ACME Service Provider Challenge . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. Informative References . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 [I-D.ietf-acme-acme] is a mechanism for automating certificate 66 management on the Internet. It enables administrative entities to 67 prove effective control over resources like domain names, and 68 automates the process of generating and issuing certificates. 70 The STIR problem statement [RFC7340] identifies the need for Internet 71 credentials that can attest authority for the originator of VoIP 72 calls in order to detect impersonation, which is currently an enabler 73 for common attacks associated with illegal robocalling, voicemail 74 hacking, and swatting. These credentials are used to sign PASSporTs 75 [I-D.ietf-stir-passport], which can be carried in using protocols 76 such as SIP [I-D.ietf-stir-rfc4474bis]. Currently, the only defined 77 credentials for this purpose are the certificates specified in 78 [I-D.ietf-stir-certificates]. 80 [I-D.ietf-stir-certificates] describes certificate extensions 81 suitable for associating telephone numbers and service provider codes 82 with certificates. [I-D.ietf-acme-telephone] specifies the ACME 83 extensions to enable certification authorities to issue certificates 84 based on telephone numbers. This specification defines extensions to 85 ACME to enable certification authorities to issue certificates based 86 on service provider codes. 88 2. Overview 90 The document [ATIS-1000080] provides a framework and model for using 91 certificates based on service provider codes. In this model, each 92 service provider requires only a few certificates, which are used in 93 conjunction with a PASSporT that contains additional information 94 attesting to a service provider's knowledge of the originator of the 95 call. Further details on the PASSporT extensions for this model are 96 provided in the SHAKEN Framework [ATIS-1000074]. 98 In the SHAKEN Certificate Management framework [ATIS-1000080], there 99 is an administrative entity that is responsible for allocating 100 service provider codes. This is referred to as the STI Policy 101 Administrator (STI-PA). This allows a certification authority to 102 validate that the entity requesting issuance of a certificate is 103 authorized to request certificates on behalf of the entity that has 104 been assigned a specific service provider code. A single VoIP 105 service provider can be allocated multiple service provider codes. A 106 service provider can choose to use the same certificate for multiple 107 service providers as reflected by the structure of the TN 108 Authorization List certificate extension defined in 109 [I-D.ietf-stir-certificates]. 111 The intent of the challenges in this document is not to establish 112 that an entity is a valid service provider but rather to provide 113 evidence that an established administrative authority entity has 114 authorized the entity to provide VoIP services in the network and 115 thus to request credentials on behalf of the VoIP users in the 116 network. 118 3. Identifier for Service Provider Codes 120 In order to issue certificates for service providers based on service 121 provider code values, a new ACME identifier type is required for use 122 in ACME authorization objects. The baseline ACME specification 123 defines one type of identifier, for a fully-qualified domain name 124 ("dns"). The document [I-D.ietf-acme-telephone] defines an ACME 125 identifier type for telephone numbers ("tn"). This document defines 126 a new ACME identifier type for service provider codes ("TNAuthList"). 127 The "TNAuthList" identifier is the same type that is specified in the 128 TN Authorization List certificate extension 129 [I-D.ietf-stir-certificates] for service provider codes. 131 4. Challenges for Service Providers 133 The new "TNAuthList" identifier introduces a slightly different 134 authorization process. A mechanism is required to allow the service 135 provider to prove it has the authority to request certificates on 136 behalf of the entities for whom it is providing VoIP services. This 137 document defines a new ACME challenge type of "spc-token-01" to 138 support the authorization of service provider code tokens. 140 The following is the response that the ACME client receives when it 141 sends a GET for the challenges in the case of a "TNAuthList" 142 identifer: 144 HTTP/1.1 200 OK 145 Content-Type: application/json 146 Link: ;rel="directory" 148 { 149 "status": "pending", 151 "identifier": { 152 "type": "TNAuthList", 153 "value": ["1234-0111"] 154 }, 156 "challenges": [ 157 { 158 "type": "spc-token-01", 159 "url": "https://sti-ca.com/authz/asdf/0" 160 "token": "DGyRejmCefe7v4NfDGDKfA" } 161 ], 162 } 164 A client responds to this challenge by providing a service provider 165 code token. In the SHAKEN Certificate Management framework, the 166 Service Provider has a secure exchange with the STI-PA to obtain a 167 service provider code token that can be used for authorization by the 168 CA when requesting a certificate. The service provider code token is 169 a standard JWT token [RFC7519] using a JWS defined signature string 170 [RFC7515]. It is RECOMMENDED that the lifetime of the service 171 provider code token be greater than the certificate lifetime, in 172 particular in cases where multiple certificates are being issued 173 using the same service provider code token. 175 The service provider code token JWT Protected Header MUST include the 176 following: 178 alg: Defines the algorithm used in the signature of the token. 179 For Service Provider Code tokens, the algorithm MUST be 180 "ES256". 182 typ: Set to standard "JWT" value. 184 x5u: Defines the URL of the certificate of the STI-PA validating 185 the Service Provider Code. 187 The service provide code token JWT Payload MUST include the 188 following: 190 sub: Service Provider Code value being validated in the form of 191 an ASCII string. 193 iat: DateTime value of the time and date the token was issued. 195 nbf: DateTime value of the starting time and date that the token 196 is valid. 198 exp: DateTime value of the ending time and date that the token 199 expires. 201 fingerprint: : Fingerprint of the ACME credentials the Service 202 Provider used to create an account with the CA. The 203 fingerprint is of the form: 204 base64url(JWK_Thumbprint(accountKey)). 206 The "JWK_Thumbprint" step indicates the computation specified 207 in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted 208 in JWA [RFC7518] any prepended zero octets in the JWK object 209 MUST be stripped before doing the computation. 211 To respond to a service provider code token challenge, the ACME 212 client constructs a service provider code authorization ("spc-authz") 213 using the "token" value provided in the challenge and the service 214 provider code token ("spcAuthzToken") that has been previously 215 obtained from the STI-PA. These two values are concatenated and 216 separated by a "." character as follows: 218 spcAuthorization = token || '.' || spcAuthzToken 220 The token for a challenge is a string comprised entirely of 221 characters in the URL- safe base64 alphabet. The "||" operator 222 indicates concatenation of strings. 224 An example of the use of the "spc-token-01" in a challenge response 225 sent by the ACME client is provided below: 227 POST /acme/authz/asdf/0 HTTP/1.1 228 Host: sti-ca.com 229 Content-Type: application/jose+json 231 { 232 "protected": base64url({ 233 "alg": "ES256", 234 "kid": "https://sti-ca.com/acme/reg/asdf", 235 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 236 "url": "https://sti-ca.com/acme/authz/asdf/0" 237 }), 238 "payload": base64url({ 239 "spcAuthorization": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 240 }), 241 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 242 } 244 Upon receiving a response to the challenge, the ACME server 245 determines the validity of the response. The ACME server MUST verify 246 that the "token" in the response matches the "token" in the original 247 challenge. To determine if the "spcAuthzToken" is valid, the server 248 MUST use the URL in the JWT header in the "spcAuthzToken" to obtain 249 the certificate associated with the JWT payload. The server MUST 250 validate the signature and verify the claims. The "sub" field MUST 251 be a value that is included in the values for the "TN-Auth-List" in 252 the original challenge. The server MUST verify that the 253 "fingerprint" field matches the ACME credentials for the ACME client 254 that created the account with the CA. If the validation is 255 successful, the "status" in the challenge object is set to "valid". 256 If any step of the validation process fails, the "status" in the 257 challenge object MUST be set to "invalid". [Editor's Note: Likely we 258 should describe specific error responses for the above.] 260 5. IANA Considerations 262 This document defines a new ACME Identifier type and ACME Challenge 263 type to be registered. 265 [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned 266 to this document ]] 268 5.1. ACME TNAuthList Identifier 270 This document defines the "TNAuthList" ACME Challenge type in the 271 ACME Identifier Type registry as follows: 273 +-----------------------+-----------+ 274 | Identifier Type | Reference | 275 +-----------------------+-----------+ 276 | TNAuthList | RFC XXXX | 277 +-----------------------+-----------+ 279 5.2. ACME Service Provider Challenge 281 This document defines the "spc-token-01" ACME Challenge type in the 282 ACME Challenge Types registry as follows: 284 +--------------+--------------------+-----------+ 285 | Label | Identifier Type | Reference | 286 +--------------+--------------------+-----------+ 287 | spc-token-01 | TNAuthList | RFC XXXX | 288 +--------------+--------------------+-----------+ 290 6. Security Considerations 292 This document relies on the security considerations established for 293 the ACME protocol per [I-D.ietf-acme-acme]. The new "TNAuthList" 294 identifier and "spc-token-01" validation challenges introduce a 295 slightly different authorization process. Although, the challenges 296 still have a binding between the account private key and the 297 validation query made by the server since the fingerprint of the 298 account key is contained in the service provider code token used for 299 authorization. 301 The service provider code token is initially obtained through a 302 secure exchange between the service provider and the entity in the 303 network that is responsible for determining what entities can operate 304 as VoIP service providers (the STI Policy Administrator). Further 305 details on this are provided in [ATIS-1000080]. 307 7. Informative References 309 [ATIS-1000074] 310 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 311 of Asserted information using toKENs (SHAKEN)", January 312 2017. 314 [ATIS-1000080] 315 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 316 of Asserted information using toKENs (SHAKEN): Governance 317 Model and Certificate Management", May 2017. 319 [FIPS180-4] 320 Department of Commerce, National, "NIST FIPS 180-4, Secure 321 Hash Standard", March 2012. 323 [I-D.ietf-acme-acme] 324 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 325 Certificate Management Environment (ACME)", draft-ietf- 326 acme-acme-07 (work in progress), June 2017. 328 [I-D.ietf-acme-telephone] 329 Peterson, J. and R. Barnes, "ACME Identifiers and 330 Challenges for Telephone Numbers", draft-ietf-acme- 331 telephone-00 (work in progress), July 2017. 333 [I-D.ietf-stir-certificates] 334 Peterson, J. and S. Turner, "Secure Telephone Identity 335 Credentials: Certificates", draft-ietf-stir- 336 certificates-14 (work in progress), May 2017. 338 [I-D.ietf-stir-passport] 339 Wendt, C. and J. Peterson, "Personal Assertion Token 340 (PASSporT)", draft-ietf-stir-passport-11 (work in 341 progress), February 2017. 343 [I-D.ietf-stir-rfc4474bis] 344 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 345 "Authenticated Identity Management in the Session 346 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 347 (work in progress), February 2017. 349 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 350 Telephone Identity Problem Statement and Requirements", 351 RFC 7340, DOI 10.17487/RFC7340, September 2014, 352 . 354 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 355 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 356 2015, . 358 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 359 DOI 10.17487/RFC7518, May 2015, 360 . 362 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 363 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 364 . 366 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 367 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 368 2015, . 370 Authors' Addresses 372 Mary Barnes 373 iconectiv 375 Email: mary.ietf.barnes@gmail.com 377 Chris Wendt 378 Comcast 379 One Comcast Center 380 Philadelphia, PA 19103 381 US 383 Email: chris-ietf@chriswendt.net