idnits 2.17.1 draft-singh-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 8 instances of too long lines in the document, the longest one being 6 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 06, 2017) is 2509 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 281, but not defined == Unused Reference: 'RFC3261' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC6919' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 378, 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 Ray. Singh 3 Internet-Draft Vencore Labs 4 Intended status: Standards Track Martin. Dolly 5 Expires: December 8, 2017 AT&T 6 Subir. Das 7 Vencore Labs 8 An. Nguyen 9 Office of Emergency Communication/DHS 10 June 06, 2017 12 PASSporT Extension for Resource-Priority Authorization 13 draft-singh-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 December 8, 2017. 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 . . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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. Cryphographically-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]. The 152 value of the "rph" claim is an array containing one or more of JSON 153 objects for the content of the SIP 'Resource-Priority' header that is 154 being asserted of which one of the "rph" object, is mandatory. 156 The following is an example "rph" claim for a SIP "Resource-Priority" 157 header field with a "namespace "." r-priority" value of "ets.0". 159 { "orig":{"tn":"12155551212"} 160 "dest":{"tn":"12125551213"}, 161 "iat":1443208345, 162 "rph":{"auth":":"Resource-Priority: ets.0"}} 164 After the header and claims PASSporT objects have been constructed, 165 their signature is generated normally per the guidance in 166 [I-D.ietf-stir-passport] using the full form of PASSPorT. The 167 credentials (e.g., authority responsible for authorizating Resource- 168 Priority) used to create the signature must have authority over the 169 "rph" claim. 171 4. 'rph' in SIP 173 This section specifies SIP-specific usage for the "rph" claim in 174 PASSporT. 176 4.1. Authentication Service Behavior 178 The Authentication Service will create the "rph" claim using the 179 values discussed in section 3 based on [RFC4412]. The constrcution 180 of "rph" claim follows the steps described in Section 4 of 181 [I-D.ietf-stir-rfc4474bis]. 183 The resulting Identity header for "rph" might look as follows: 185 "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSndZWE56Y0c5eW 186 RDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFOaUlzRFFvaWVEVjFJanBvZE 187 hSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaWEowTG1ObGNuME5DZz09LmV5SnZjbWxuSW 188 pwN0luUnVJam9pTVRJeE5UVTFOVEV5TVRJaWZTd2dEUW9pYVdGMElqb2lNVFEwTXpJd09ETTBOU0 189 lzSUEwS0ltUmxjM1FpT25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TXlKOURRb2ljbkJvSWpwN0ltRj 190 FkR2dpT2lKU1pYTnZkWEpqWlMxUWNtbHZjbWwwZVRvZ1pYUnpMakFpWFgxOURRb05DZzBLIiwibm 191 JmIjoxNDk2NzU4Mzk0LCJleHAiOjE0OTY3NjE5OTQsImlhdCI6MTQ5Njc1ODM5NH0.0-oNMVgchp 192 biDzSxCktUIQVbkJWL48DfxOTllSHBmj3sZtV2S3SKZkmnU2V9akv2LnJ50JK9W_1ynz7JrChJ3g"; 193 info= "https://www.example.org/cert.cer";alg=ES256;ppt="rph" 195 A SIP authentication service typically will derive the value of "rph" 196 from the 'Resource-Priority' header field based on policy associated 197 with service specific use of the "namespace "." r-priority" values 198 based on [RFC4412]. The authentication service derives the value of 199 the PASSPorT claim by verifying the authorization for Resource- 200 Priority (i.e., verifying a calling user privilege for Resoure- 201 Priority based on its identity) which mighth be derived from customer 202 profile data or from access to external services. 204 [RFC4412] allows multiple "namespace "." r-priority" pairs, either in 205 a single SIP Resource-Priority header or across multiple SIP 206 Resource-Priority headers. However, it is not necessary to sign all 207 content of a SIP Resource-Priority header or all SIP Resource- 208 Priority headers in a given SIP message. An authority is only 209 responsible for signing the content of a SIP Resource-Priority header 210 for which it has authority (e.g., a specific "namespace "." 211 r-priority"). 213 4.2. Verification Service Behavior 215 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 216 specifications defining "ppt" values describe any additional verifier 217 behavior. The behavior specified for the "ppt" values of "rph" is as 218 follows: 220 The verification service MUST extract the value associated with the 221 "auth" key in a full form PASSPorT with a "ppt" value of "rph". If 222 the signature validates, then the verification service can use the 223 value of the "rph" claim as validation that the calling party is 224 authorized for Resource-Priority, which would in turn be used for 225 priority treatment in accordance with local policy for the associated 226 communication service. 228 The verification service MUST extract the value associated with the 229 "auth" key in a full form PASSPorT with a "ppt" value of "rph". If 230 the signature validates, then the verification service can use the 231 value of the "rph" claim as validation that the calling party is 232 authorized for Resource-Priority, which would in turn be used for 233 priority treatment in accordance with local policy for the associated 234 communication service. 236 In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires 237 "iat" value in "rph" claim to be verified. 239 The behavior of a SIP UAs upon receiving an INVITE containing a 240 PASSporT object with a "rph" claim will largely remain a matter of 241 implementation policy for the specific communication service. In 242 most cases,implementations would act based on confidence in the 243 veracity of this information. 245 5. Further Information Associated with Resource-Priority 247 There may be additional information about the calling party or the 248 call that could be relevant to authorization for Resource-Priority. 249 This may include information related to the device subscription of 250 the caller, or to any institutions that the caller or device is 251 associated with, or even categories of institutions. All of these 252 data elements would benefit from the secure attestations provided by 253 the STIR and PASSporT frameworks. The specification of the "rph" 254 claim could entail the optional presence of one or more such 255 additional information fields. 257 A new IANA registry has been defined to hold potential values of the 258 "rph" array; see Section 8.3. Details of extensions to the "rph" 259 claim to encompass other data elements are left for future version of 260 this specification. 262 6. IANA Considerations 264 6.1. JSON Web Token Claims Registration 266 o Claim Name: "rph" 268 o Claim Description: Resource Priority Header 270 o Change Controller: IESG 272 o Specification Document(s): Section 3 of [RFCThis] 274 6.2. PASSporT RPH Types 276 This document requests that the IANA create a new registry for 277 PASSporT RPH types. Registration of new PASSporT RPH types shall be 278 under the specification required policy. 280 This registry is to be initially populated with a single value for 281 "namespace" which is specified in [RFCThis]. 283 7. Security Considerations 285 The security considerations discussed in [I-D.ietf-stir-rfc4474bis] 286 in Section 10 are applicable here. 288 7.1. Avoidance of replay and cut and past attacks 290 The PASSporT extension with a "ppt" value of "rph" MUST only be sent 291 with SIP when 'Resource-Priority' header is used to convey the 292 priority of the communication as defined in [RFC4412]. A uniqueness 293 of the set of token with extension claims and token signature is 294 constructed using the originating identity being asserted with the 295 "orig" claim along with the following two claims: 297 o "iat" claim should correspond to a date/time the message was 298 originated. It should also be within a relative time that is 299 reasonable for clock drift and transmission time characteristics 300 associated with the application using the PASSporT token. 301 Therefore, validation of the token should consider date and time 302 correlation, which could be influenced by signaling protocol 303 specific use and network time differences. 305 o "dest" claim is included to prevent the valid re-use of a 306 previously originated message to send to another destination 307 party. 309 7.2. Solution Considerations 311 The use of extension to PASSporT tokens with ppt value rph based on 312 the validation of the digital signature and the associated 313 certificate requires consideration of the authentication and 314 authority or reputation of the signer to attest to the identity being 315 asserted. The following considerations should be recognized when 316 using PASSporT extension with "ppt" value of "rph": 318 o The use of this token should not, in it's own right, be considered 319 a full solution for absolute non-repudiation of the identity being 320 asserted. 322 o An authority (signer) is only allowed to sign the content of a SIP 323 'Resource-Priority' header for which it has the right authority. 324 The authority that signs the token MUST have a secure method for 325 authentication of the end user or the device. 327 o The verification of the signature MUST include means of verifying 328 that the signer is authoritative for the signed content of the SIP 329 'Resource-Priority' header. 331 7.3. Acknowledgements 333 We would like to thank STIR members, ATIS/SIP Forum Task Force on 334 IPNNI members, and the NS/EP Priority Services community for 335 contributions to this problem statement and specification. We would 336 also like to thank David Hancock for his valuable inputs. 338 8. References 340 8.1. Normative References 342 [I-D.ietf-stir-passport] 343 Wendt, C. and J. Peterson, "Personal Assertion Token 344 (PASSporT)", February 2017. 346 [I-D.ietf-stir-rfc4474bis] 347 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 348 "Authenticated Identity Management in the Session 349 Initiation Protocol (SIP)", February 2017. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 357 Priority for the Session Initiation Protocol (SIP)", 358 RFC 4412, DOI 10.17487/RFC4412, February 2006, 359 . 361 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 362 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 363 . 365 8.2. Informative References 367 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 368 A., Peterson, J., Sparks, R., Handley, M., and E. 369 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 370 DOI 10.17487/RFC3261, June 2002, 371 . 373 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 374 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 375 DOI 10.17487/RFC6919, April 2013, 376 . 378 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 379 Telephone Identity Problem Statement and Requirements", 380 RFC 7340, DOI 10.17487/RFC7340, September 2014, 381 . 383 Authors' Addresses 385 Ray P. Singh 386 Vencore Labs 387 150 Mount Airy Road 388 New Jersey, NJ 07920 389 USA 391 Email: rsingh@vencorelabs.com 393 Martin Dolly 394 AT&T 395 200 Laurel Avenue 396 Middletown, NJ 07748 397 USA 399 Email: md3135@att.com 401 Subir Das 402 Vencore Labs 403 150 Mount Airy Road 404 New Jersey, NJ 07920 405 USA 407 Email: sdas@vencorelabs.com 409 An Nguyen 410 Office of Emergency Communication/DHS 411 245 Murray Lane, Building 410 412 Washington, DC 20528 413 USA 415 Email: an.p.nguyen@HQ.DHS.GOV