idnits 2.17.1 draft-ietf-stir-rph-00.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCThis' is mentioned on line 286, but not defined == Unused Reference: 'RFC3261' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC6919' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 366, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR R. Singh 3 Internet-Draft Vencore Labs 4 Intended status: Standards Track M. Dolly 5 Expires: January 1, 2018 AT&T 6 S. Das 7 Vencore Labs 8 A. Nguyen 9 Office of Emergency Communication/DHS 10 June 30, 2017 12 PASSporT Extension for Resource-Priority Authorization 13 draft-ietf-stir-rph-00 15 Abstract 17 This document extends the PASSporT object to convey 18 cryptographically-signed assertions of authorization for 19 communications 'Resource-Priority'. It extends PASSporT to allow 20 cryptographic-signing of the SIP 'Resource-Priority" header field 21 which is used for communications resource prioritization. It also 22 describes how the PASSPorT extension is used in SIP signaling to 23 convey assertions of authorization of the information in the SIP 24 'Resource-Priority' header field. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. PASSporT 'rph' Claim . . . . . . . . . . . . . . . . . . . . 3 63 4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Authentication Service Behavior . . . . . . . . . . . . . 4 65 4.2. Verification Service Behavior . . . . . . . . . . . . . . 5 66 5. Further Information Associated with Resource-Priority . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 6 69 6.2. PASSporT RPH Types . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7.1. Avoidance of replay and cut and past attacks . . . . . . 7 72 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 7 73 7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 PASSporT [I-D.ietf-stir-passport] is a token format based on JWT 82 [RFC7519] for conveying cryptographically-signed information about 83 the identities involved in personal communications; it is used with 84 STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the 85 identity of the participants in real-time communications established 86 via a protocol like SIP. This specification extends PASSporT to 87 allow cryptographic-signing of the SIP 'Resource-Priority' header 88 field defined in [RFC4412]. 90 [RFC4412] defines the SIP 'Resource-Priority' header field for 91 communications Resource Priority. As specified in [RFC4412], the 92 'Resource-Priority' header field may be used by SIP user agents, 93 including, Public Switched Telephone Network (PSTN) gateways and 94 terminals, and SIP proxy servers to influence prioritization afforded 95 to communication sessions,including PSTN calls. However, the SIP 96 'Resource-Priority' header field could be spoofed and abused by 97 unauthorized entities. 99 The STIR architecture assumes that an authority on the originating 100 side of a call provides a cryptographic assurance of the validity of 101 the calling party number in order to prevent impersonation attacks. 102 The STIR architecture allows extension that can be utilized by 103 authorities supporting real-time communication services using the 104 'Resource-Priority' header field to cryptographically sign the SIP 105 'Resource-Priority' header field and convey assertion of the 106 authorization for 'Resource-Priority'. For example, the authority on 107 the originating side verifying the authorization of a particular 108 communication for Resource-Priority can use a PASSPorT claim to 109 cryptographically-sign the SIP 'Resource-Priority' header field and 110 convey an assertion of the authorization for 'Resource-Priority'. 111 This will allow a receiving entity (including entities located in 112 different network domains/boundaries) to verify the validity of 113 assertions authorizating Resource-Priority. Cryptographically-signed 114 SIP 'Resource-Priority' headers will allow a receiving entity to 115 verify and act on the information with confidence that the 116 information have not been spoofed or compromised. 118 This specification documents an optional extension to PASSporT and 119 the associated STIR mechanisms to provide a function to sign the SIP 120 'Resource-Priority' header field. How the optional extension to 121 PASSporT is used for real-time communications supported using SIP 122 'Resource-Priority' header field is defined in other documents and is 123 outside the scope of this document. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. PASSporT 'rph' Claim 133 This specification defines a new JSON Web Token claim for "rph", 134 which provides an assertion for information in SIP 'Resource- 135 Priority'header. 137 The creator of a PASSporT object adds a "ppt" value of "rph" to the 138 header of a PASSporT object, in which case the PASSporT claims MUST 139 contain a "rph" claim, and any entities verifying the PASSporT object 140 will be required to understand the "ppt" extension in order to 141 process the PASSporT in question. A PASSPort header with the "ppt" 142 included will look as follows: 144 { "typ":"passport", 145 "ppt":"rph", 146 "alg":"ES256", 147 "x5u":"https://www.example.org/cert.cer"} 149 The "rph" claim will provide an assertion of authorization,"auth", 150 for information in the SIP "Resource-Priority" header field (i.e., 151 Resource-Priority: namespace "." r-priority) based on [RFC4412]. 152 Specifically, the "rph" claim includes assertion of the priority- 153 level of the user to be used for a given communication session. The 154 value of the "rph" claim is an array containing one or more of JSON 155 objects for the content of the SIP 'Resource-Priority' header that is 156 being asserted of which one of the "rph" object, is mandatory. 158 The following is an example "rph" claim for a SIP "Resource-Priority" 159 header field with a "namespace "." r-priority" value of "ets.0". 161 { "orig":{"tn":"12155551212"} 162 "dest":{"tn":"12125551213"}, 163 "iat":1443208345, 164 "rph":{"auth":"ets.0"}} 166 After the header and claims PASSporT objects have been constructed, 167 their signature is generated normally per the guidance in 168 [I-D.ietf-stir-passport] using the full form of PASSPorT. The 169 credentials (e.g., authority responsible for authorizating Resource- 170 Priority) used to create the signature must have authority over the 171 "rph" claim and there is only one authority per claim. The authority 172 MUST use its credentials (i.e., CERT) associated with the specific 173 service supported by the SIP namespace in the claim. 175 4. 'rph' in SIP 177 This section specifies SIP-specific usage for the "rph" claim in 178 PASSporT. 180 4.1. Authentication Service Behavior 182 The Authentication Service will create the "rph" claim using the 183 values discussed in section 3 based on [RFC4412]. The construction 184 of "rph" claim follows the steps described in Section 4 of 185 [I-D.ietf-stir-rfc4474bis]. 187 The resulting Identity header for "rph" might look as follows: 189 "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSndZWE56Y0c5eW 190 RDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFOaUlzRFFvaWVEVjFJanBvZE 191 hSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaWEowTG1ObGNuME5DZz09IHx84oCZLuKAmX 192 x8IGV5SnZjbWxuSWpwN0luUnVJam9pTVRJeE5UVTFOVEV5TVRJaWZTd2dEUW9pYVdGMElqb2lNVF 193 EwTXpJd09ETTBOU0lzSUEwS0ltUmxjM1FpT25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TXlKOURRb2 194 ljbkJvSWpwN0ltRjFkR2dpT2lKbGRITXVNQ0o5RFFvTkNnMEsgICAgIiwibmJmIjoxNDk4NDg5MT 195 U5LCJleHAiOjE0OTg0OTI3NTksImlhdCI6MTQ5ODQ4OTE1OX0.oia2-qJTlDJICsJ_Af2A5slhO2 196 iJU-kAHG-HRVVhRiUea6acIoD0w2Bc3Ap4iZ6izx7haRj55MtKKCwY5_bItA"; 197 info= "https://www.example.org/cert.cer";alg=ES256;ppt="rph" 199 A SIP authentication service typically will derive the value of "rph" 200 from the 'Resource-Priority' header field based on policy associated 201 with service specific use of the "namespace "." r-priority" values 202 based on [RFC4412]. The authentication service derives the value of 203 the PASSPorT claim by verifying the authorization for Resource- 204 Priority (i.e., verifying a calling user privilege for Resource- 205 Priority based on its identity) which might be derived from customer 206 profile data or from access to external services. 208 [RFC4412] allows multiple "namespace "." r-priority" pairs, either in 209 a single SIP Resource-Priority header or across multiple SIP 210 Resource-Priority headers. However, it is not necessary to sign all 211 content of a SIP Resource-Priority header or all SIP Resource- 212 Priority headers in a given SIP message. An authority is only 213 responsible for signing the content of a SIP Resource-Priority header 214 for which it has authority (e.g., a specific "namespace "." 215 r-priority"). 217 4.2. Verification Service Behavior 219 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 220 specifications defining "ppt" values describe any additional verifier 221 behavior. The behavior specified for the "ppt" values of "rph" is as 222 follows: 224 The verification service MUST extract the value associated with the 225 "auth" key in a full form PASSPorT with a "ppt" value of "rph". If 226 the signature validates, then the verification service can use the 227 value of the "rph" claim as validation that the calling party is 228 authorized for Resource-Priority, which would in turn be used for 229 priority treatment in accordance with local policy for the associated 230 communication service. 232 The verification service MUST extract the value associated with the 233 "auth" key in a full form PASSPorT with a "ppt" value of "rph". If 234 the signature validates, then the verification service can use the 235 value of the "rph" claim as validation that the calling party is 236 authorized for Resource-Priority, which would in turn be used for 237 priority treatment in accordance with local policy for the associated 238 communication service. 240 In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires 241 "iat" value in "rph" claim to be verified. 243 The behavior of a SIP UAs upon receiving an INVITE containing a 244 PASSporT object with a "rph" claim will largely remain a matter of 245 implementation policy for the specific communication service. In 246 most cases,implementations would act based on confidence in the 247 veracity of this information. The use of the compact form of 248 PASSporT is not specified in this document. 250 5. Further Information Associated with Resource-Priority 252 There may be additional information about the calling party or the 253 call that could be relevant to authorization for Resource-Priority. 254 This may include information related to the device subscription of 255 the caller, or to any institutions that the caller or device is 256 associated with, or even categories of institutions. All of these 257 data elements would benefit from the secure attestations provided by 258 the STIR and PASSporT frameworks. The specification of the "rph" 259 claim could entail the optional presence of one or more such 260 additional information fields. 262 A new IANA registry has been defined to hold potential values of the 263 "rph" array; see Section 8.3. Details of extensions to the "rph" 264 claim to encompass other data elements are left for future version of 265 this specification. 267 6. IANA Considerations 269 6.1. JSON Web Token Claims Registration 271 o Claim Name: "rph" 273 o Claim Description: Resource Priority Header 275 o Change Controller: IESG 277 o Specification Document(s): Section 3 of [RFCThis] 279 6.2. PASSporT RPH Types 281 This document requests that the IANA create a new registry for 282 PASSporT RPH types. Registration of new PASSporT RPH types shall be 283 under the specification required policy. 285 This registry is to be initially populated with a single value for 286 "namespace" which is specified in [RFCThis]. 288 7. Security Considerations 290 The security considerations discussed in [I-D.ietf-stir-rfc4474bis] 291 in Section 10 are applicable here. 293 7.1. Avoidance of replay and cut and past attacks 295 The PASSporT extension with a "ppt" value of "rph" MUST only be sent 296 with SIP INVITE when 'Resource-Priority' header is used to convey the 297 priority of the communication as defined in [RFC4412]. To avoid the 298 replay, and cut and paste attacks, the procedures described in 299 Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 301 7.2. Solution Considerations 303 The use of extension to PASSporT tokens with ppt value rph based on 304 the validation of the digital signature and the associated 305 certificate requires consideration of the authentication and 306 authority or reputation of the signer to attest to the identity being 307 asserted. The following considerations should be recognized when 308 using PASSporT extension with "ppt" value of "rph": 310 o An authority (signer) is only allowed to sign the content of a SIP 311 'Resource-Priority' header for which it has the right authority. 312 The authority that signs the token MUST have a secure method for 313 authentication of the end user or the device. 315 o The verification of the signature MUST include means of verifying 316 that the signer is authoritative for the signed content of the SIP 317 'Resource-Priority' header. 319 7.3. Acknowledgements 321 We would like to thank STIR members, ATIS/SIP Forum Task Force on 322 IPNNI members, and the NS/EP Priority Services community for 323 contributions to this problem statement and specification. We would 324 also like to thank David Hancock for his valuable inputs. 326 8. References 328 8.1. Normative References 330 [I-D.ietf-stir-passport] 331 Wendt, C. and J. Peterson, "Personal Assertion Token 332 (PASSporT)", February 2017. 334 [I-D.ietf-stir-rfc4474bis] 335 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 336 "Authenticated Identity Management in the Session 337 Initiation Protocol (SIP)", February 2017. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 345 Priority for the Session Initiation Protocol (SIP)", 346 RFC 4412, DOI 10.17487/RFC4412, February 2006, 347 . 349 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 350 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 351 . 353 8.2. Informative References 355 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 356 A., Peterson, J., Sparks, R., Handley, M., and E. 357 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 358 DOI 10.17487/RFC3261, June 2002, 359 . 361 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 362 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 363 DOI 10.17487/RFC6919, April 2013, 364 . 366 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 367 Telephone Identity Problem Statement and Requirements", 368 RFC 7340, DOI 10.17487/RFC7340, September 2014, 369 . 371 Authors' Addresses 373 Ray P. Singh 374 Vencore Labs 375 150 Mount Airy Road 376 New Jersey, NJ 07920 377 USA 379 Email: rsingh@vencorelabs.com 380 Martin Dolly 381 AT&T 382 200 Laurel Avenue 383 Middletown, NJ 07748 384 USA 386 Email: md3135@att.com 388 Subir Das 389 Vencore Labs 390 150 Mount Airy Road 391 New Jersey, NJ 07920 392 USA 394 Email: sdas@vencorelabs.com 396 An Nguyen 397 Office of Emergency Communication/DHS 398 245 Murray Lane, Building 410 399 Washington, DC 20528 400 USA 402 Email: an.p.nguyen@HQ.DHS.GOV