idnits 2.17.1 draft-barnes-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 date (June 2, 2017) is 2512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-06 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 Summary: 0 errors (**), 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 MLB@Realtime Communications 4 Intended status: Informational C. Wendt 5 Expires: December 4, 2017 Comcast 6 June 2, 2017 8 ACME Identifiers and Challenges for VoIP Service Providers 9 draft-barnes-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 December 4, 2017. 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. TNAuthList Identifier Code and Challenges Example . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. ACME TNAuthList Identifier . . . . . . . . . . . . . . . 5 59 6.2. ACME Service Provider Challenge . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. Informative References . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 [I-D.ietf-acme-acme] is a mechanism for automating certificate 67 management on the Internet. It enables administrative entities to 68 prove effective control over resources like domain names, and 69 automates the process of generating and issuing certificates. 71 The STIR problem statement [RFC7340] identifies the need for Internet 72 credentials that can attest authority for the originator of VoIP 73 calls in order to detect impersonation, which is currently an enabler 74 for common attacks associated with illegal robocalling, voicemail 75 hacking, and swatting. These credentials are used to sign PASSporTs 76 [I-D.ietf-stir-passport], which can be carried in using protocols 77 such as SIP [I-D.ietf-stir-rfc4474bis]. Currently, the only defined 78 credentials for this purpose are the certificates specified in 79 [I-D.ietf-stir-certificates]. 81 [I-D.ietf-stir-certificates] describes certificate extensions 82 suitable for associating telephone numbers and service provider codes 83 with certificates. [I-D.peterson-acme-telephone] specifies the ACME 84 extensions to enable certification authorities to issue certificates 85 based on telephone numbers. This specification defines extensions to 86 ACME to enable certification authorities to issue certificates based 87 on service provider codes. 89 2. Overview 91 The document [SHAKEN_Certificate_Mgmt] provides a framework and model 92 for using certificates based on service provider codes. In this 93 model, each service provider requires only a few certificates, which 94 are used in conjunction with a PASSporT that contains additional 95 information attesting to a service provider's knowledge of the 96 originator of the call. Further details on the PASSporT extensions 97 for this model are provided in the SHAKEN Framework [ATIS-1000074]. 99 In the SHAKEN Certificate Management framework, there is an 100 administrative entity that is responsible for allocating service 101 provider codes. This is referred to as the STI Policy Administrator 102 (STI-PA). This allows a certification authority to validate that the 103 entity requesting issuance of a certificate is authorized to request 104 certificates on behalf of the entity that has been assigned a 105 specific service provider code. A single VoIP service provider can 106 be allocated multiple service provider codes. A service provider can 107 choose to use the same certificate for multiple service providers as 108 reflected by the structure of the TN Authorization List certificate 109 extension defined in [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.peterson-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. An example 129 is provided in Section 5. 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. 138 The STI-PA in the SHAKEN Certificate Management framework has a 139 secure exchange with the Service Provider in order to provide a 140 service provider code token that the Service Provider can use for 141 authorization by the CA when requesting a certificate. The service 142 provider code token ("spc-token") is a standard JWT token [RFC7519] 143 using a JWS defined signature string [RFC7515]. Note that further 144 details on the CA interface to the STI-PA for the authorization are 145 provided in [SHAKEN_Certificate_Mgmt]. 147 This document defines a new ACME challenges type of "spc-token" to 148 support the SHAKEN Certificate Management framework. An example of 149 the use of the "spc-token" for ACME is provided in Section 5. 151 5. TNAuthList Identifier Code and Challenges Example 153 The section provides examples of the use of the TNAuthList identifier 154 as a challenge mechanism. 156 The following is the response that the ACME client receives when it 157 sends a GET for the challenges: 159 HTTP/1.1 200 OK 160 Content-Type: application/json 161 Link: ;rel="directory" 163 { 164 "status": "pending", 166 "identifier": { 167 "type": "TNAuthList", 168 "value": ["1234-0111"] 169 }, 171 "challenges": [ 172 { 173 "type": "spc-token", 174 "url": "https://sti-ca.com/authz/asdf/0" 175 "token": "DGyRejmCefe7v4NfDGDKfA" } 176 ], 177 } 178 The following is the response to the challenge sent by the ACME 179 client: 181 POST /acme/authz/asdf/0 HTTP/1.1 182 Host: sti-ca.com 183 Content-Type: application/jose+json 185 { 186 "protected": base64url({ 187 "alg": "ES256", 188 "kid": "https://sti-ca.com/acme/reg/asdf", 189 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 190 "url": "https://sti-ca.com/acme/authz/asdf/0" 191 }), 192 "payload": base64url({ 193 "type": "spc-token", 194 "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE" 195 }), 196 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 197 } 199 6. IANA Considerations 201 This document defines a new ACME Identifier type and ACME Challenge 202 type to be registered. 204 [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned 205 to this document ]] 207 6.1. ACME TNAuthList Identifier 209 This document defines the "TNAuthList" ACME Challenge type in the 210 ACME Identifier Type registry as follows: 212 +-----------------------+-----------+ 213 | Identifier Type | Reference | 214 +-----------------------+-----------+ 215 | TNAuthList | RFC XXXX | 216 +-----------------------+-----------+ 218 6.2. ACME Service Provider Challenge 220 This document defines the "spc-token" ACME Challenge type in the ACME 221 Challenge Types registry as follows: 223 +-----------+--------------------+-----------+ 224 | Label | Identifier Type | Reference | 225 +-----------+--------------------+-----------+ 226 | spc-token | TNAuthList | RFC XXXX | 227 +-----------+--------------------+-----------+ 229 7. Security Considerations 231 This document relies on the security considerations established for 232 the ACME protocol per [I-D.ietf-acme-acme]. The new "TNAuthList" 233 identifier and "spc-token" validation challenges introduce a slightly 234 different authorization process. Although, the challenges still have 235 a binding between the account private key and the validation query 236 made by the server, via the key authorization. 238 The "spc-token" is initially obtained through a secure exchange 239 between the service provider and the entity in the network that is 240 responsible for determining what entities can operate as VoIP service 241 providers (the STI Policy Administrator). Further details on this 242 are provided in [SHAKEN_Certificate_Mgmt]. 244 8. Informative References 246 [ATIS-1000074] 247 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 248 of Asserted information using toKENs (SHAKEN)", January 249 2017. 251 [I-D.ietf-acme-acme] 252 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 253 Certificate Management Environment (ACME)", draft-ietf- 254 acme-acme-06 (work in progress), March 2017. 256 [I-D.ietf-stir-certificates] 257 Peterson, J. and S. Turner, "Secure Telephone Identity 258 Credentials: Certificates", draft-ietf-stir- 259 certificates-14 (work in progress), May 2017. 261 [I-D.ietf-stir-passport] 262 Wendt, C. and J. Peterson, "Personal Assertion Token 263 (PASSporT)", draft-ietf-stir-passport-11 (work in 264 progress), February 2017. 266 [I-D.ietf-stir-rfc4474bis] 267 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 268 "Authenticated Identity Management in the Session 269 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 270 (work in progress), February 2017. 272 [I-D.peterson-acme-telephone] 273 Peterson, J. and R. Barnes, "ACME Identifiers and 274 Challenges for Telephone Numbers", draft-peterson-acme- 275 telephone-00 (work in progress), October 2016. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 283 Telephone Identity Problem Statement and Requirements", 284 RFC 7340, DOI 10.17487/RFC7340, September 2014, 285 . 287 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 288 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 289 2015, . 291 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 292 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 293 . 295 [SHAKEN_Certificate_Mgmt] 296 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 297 of Asserted information using toKENs (SHAKEN): Governance 298 Model and Certificate Management", May 2017. 300 Authors' Addresses 302 Mary Barnes 303 MLB@Realtime Communications 305 Email: mary.ietf.barnes@gmail.com 306 Chris Wendt 307 Comcast 308 One Comcast Center 309 Philadelphia, PA 19103 310 US 312 Email: chris-ietf@chriswendt.net