idnits 2.17.1 draft-ietf-acme-service-provider-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 18, 2017) is 2473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 345, but no explicit reference was found in the text == 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: 0 errors (**), 0 flaws (~~), 6 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 MLB@Realtime Communications 4 Intended status: Informational C. Wendt 5 Expires: January 19, 2018 Comcast 6 July 18, 2017 8 ACME Identifiers and Challenges for VoIP Service Providers 9 draft-ietf-acme-service-provider-01 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 http://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 January 19, 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 (http://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 governance entity has authorized the 114 entity to provide VoIP services in the network and thus to request 115 credentials on behalf of the VoIP users in the network. 117 3. Identifier for Service Provider Codes 119 In order to issue certificates for service providers based on service 120 provider code values, a new ACME identifier type is required for use 121 in ACME authorization objects. The baseline ACME specification 122 defines one type of identifier, for a fully-qualified domain name 123 ("dns"). The document [I-D.ietf-acme-telephone] defines an ACME 124 identifier type for telephone numbers ("tn"). This document defines 125 a new ACME identifier type for service provider codes ("TNAuthList"). 126 The "TNAuthList" identifier is the same type that is specified in the 127 TN Authorization List certificate extension 128 [I-D.ietf-stir-certificates] for service provider codes. 130 4. Challenges for Service Providers 132 The new "TNAuthList" identifier introduces a slightly different 133 authorization process. A mechanism is required to allow the service 134 provider to prove it has the authority to request certificates on 135 behalf of the entities for whom it is providing VoIP services. This 136 document defines a new ACME challenge type of "spc-token-01" to 137 support the authorization of service provider code tokens. 139 The following is the response that the ACME client receives when it 140 sends a GET for the challenges in the case of a "TNAuthList" 141 identifer: 143 HTTP/1.1 200 OK 144 Content-Type: application/json 145 Link: ;rel="directory" 147 { 148 "status": "pending", 150 "identifier": { 151 "type": "TNAuthList", 152 "value": ["1234-0111"] 153 }, 155 "challenges": [ 156 { 157 "type": "spc-token-01", 158 "url": "https://sti-ca.com/authz/asdf/0" 159 "token": "DGyRejmCefe7v4NfDGDKfA" } 160 ], 161 } 163 A client responds to this challenge by providing a service provider 164 code token. In the SHAKEN Certificate Management framework, the 165 Service Provider has a secure exchange with the STI-PA to obtain a 166 service provider code token that can be used for authorization by the 167 CA when requesting a certificate. The service provider code token is 168 a standard JWT token [RFC7519] using a JWS defined signature string 169 [RFC7515]. 171 The service provider code token JWT Protected Header MUST include the 172 following: 174 alg: Defines the algorithm used in the signature of the token. 175 For Service Provider Code tokens, the algorithm MUST be 176 "ES256". 178 typ: Set to standard "JWT" value. 180 x5u: Defines the URL of the certificate of the STI-PA validating 181 the Service Provider Code. 183 The service provide code token JWT Payload MUST include the 184 following: 186 sub: Service Provider Code value being validated in the form of a 187 JSON array of ASCII strings. 189 iat: DateTime value of the time and date the token was issued. 191 nbf: DateTime value of the starting time and date that the token 192 is valid. 194 exp: DateTime value of the ending time and date that the token 195 expires. 197 fingerprint: : Fingerprint of the ACME credentials the Service 198 Provider used to create an account with the CA. The 199 fingerprint is of the form: 200 base64url(JWK_Thumbprint(accountKey)). 202 The "JWK_Thumbprint" step indicates the computation specified 203 in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted 204 in JWA [RFC7518] any prepended zero octets in the JWK object 205 MUST be stripped before doing the computation. 207 To respond to a service provider code token challenge, the ACME 208 client constructs a service provider code authorization ("spc-authz") 209 using the "token" value provided in the challenge and the service 210 provider code token ("spcAuthzToken") that has been previously 211 obtained from the STI-PA. These two values are concatenated and 212 separated by a "." character as follows: 214 spcAuthorization = token || '.' || spcAuthzToken 216 The token for a challenge is a string comprised entirely of 217 characters in the URL- safe base64 alphabet. The "||" operator 218 indicates concatenation of strings. 220 An example of the use of the "spc-token-01" in a challenge response 221 sent by the ACME client is provided below: 223 POST /acme/authz/asdf/0 HTTP/1.1 224 Host: sti-ca.com 225 Content-Type: application/jose+json 227 { 228 "protected": base64url({ 229 "alg": "ES256", 230 "kid": "https://sti-ca.com/acme/reg/asdf", 231 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 232 "url": "https://sti-ca.com/acme/authz/asdf/0" 233 }), 234 "payload": base64url({ 235 "spcAuthorization": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 236 }), 237 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 238 } 240 Upon receiving a response to the challenge, the ACME server 241 determines the validity of the response. The ACME server MUST verify 242 that the "token" in the response matches the "token" in the original 243 challenge. To determine if the "spcAuthzToken" is valid, the server 244 MUST use the URL in the JWT header in the "spcAuthzToken" to obtain 245 the certificate associated with the JWT payload. The server MUST 246 validate the signature and verify the claims. The "sub" field MUST 247 be a value that is included in the values for the "TN-Auth-List" in 248 the original challenge. The server MUST verify that the 249 "fingerprint" field matches the ACME credentials for the ACME client 250 that created the account with the CA. If the validation is 251 successful, the "status" in the challenge object is set to "valid". 252 If any step of the validation process fails, the "status" in the 253 challenge object MUST be set to "invalid". [Editor's Note: Likely we 254 should describe specific error responses for the above.] 256 5. IANA Considerations 258 This document defines a new ACME Identifier type and ACME Challenge 259 type to be registered. 261 [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned 262 to this document ]] 264 5.1. ACME TNAuthList Identifier 266 This document defines the "TNAuthList" ACME Challenge type in the 267 ACME Identifier Type registry as follows: 269 +-----------------------+-----------+ 270 | Identifier Type | Reference | 271 +-----------------------+-----------+ 272 | TNAuthList | RFC XXXX | 273 +-----------------------+-----------+ 275 5.2. ACME Service Provider Challenge 277 This document defines the "spc-token-01" ACME Challenge type in the 278 ACME Challenge Types registry as follows: 280 +--------------+--------------------+-----------+ 281 | Label | Identifier Type | Reference | 282 +--------------+--------------------+-----------+ 283 | spc-token-01 | TNAuthList | RFC XXXX | 284 +--------------+--------------------+-----------+ 286 6. Security Considerations 288 This document relies on the security considerations established for 289 the ACME protocol per [I-D.ietf-acme-acme]. The new "TNAuthList" 290 identifier and "spc-token-01" validation challenges introduce a 291 slightly different authorization process. Although, the challenges 292 still have a binding between the account private key and the 293 validation query made by the server since the fingerprint of the 294 account key is contained in the service provider code token used for 295 authorization. 297 The service provider code token is initially obtained through a 298 secure exchange between the service provider and the entity in the 299 network that is responsible for determining what entities can operate 300 as VoIP service providers (the STI Policy Administrator). Further 301 details on this are provided in [ATIS-1000080]. 303 7. Informative References 305 [ATIS-1000074] 306 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 307 of Asserted information using toKENs (SHAKEN)", January 308 2017. 310 [ATIS-1000080] 311 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 312 of Asserted information using toKENs (SHAKEN): Governance 313 Model and Certificate Management", May 2017. 315 [FIPS180-4] 316 Department of Commerce, National, "NIST FIPS 180-4, Secure 317 Hash Standard", March 2012. 319 [I-D.ietf-acme-acme] 320 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 321 Certificate Management Environment (ACME)", draft-ietf- 322 acme-acme-07 (work in progress), June 2017. 324 [I-D.ietf-acme-telephone] 325 Peterson, J. and R. Barnes, "ACME Identifiers and 326 Challenges for Telephone Numbers", draft-ietf-acme- 327 telephone-00 (work in progress), July 2017. 329 [I-D.ietf-stir-certificates] 330 Peterson, J. and S. Turner, "Secure Telephone Identity 331 Credentials: Certificates", draft-ietf-stir- 332 certificates-14 (work in progress), May 2017. 334 [I-D.ietf-stir-passport] 335 Wendt, C. and J. Peterson, "Personal Assertion Token 336 (PASSporT)", draft-ietf-stir-passport-11 (work in 337 progress), February 2017. 339 [I-D.ietf-stir-rfc4474bis] 340 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 341 "Authenticated Identity Management in the Session 342 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 343 (work in progress), February 2017. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 351 Telephone Identity Problem Statement and Requirements", 352 RFC 7340, DOI 10.17487/RFC7340, September 2014, 353 . 355 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 356 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 357 2015, . 359 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 360 DOI 10.17487/RFC7518, May 2015, 361 . 363 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 364 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 365 . 367 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 368 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 369 2015, . 371 Authors' Addresses 373 Mary Barnes 374 MLB@Realtime Communications 376 Email: mary.ietf.barnes@gmail.com 378 Chris Wendt 379 Comcast 380 One Comcast Center 381 Philadelphia, PA 19103 382 US 384 Email: chris-ietf@chriswendt.net