idnits 2.17.1 draft-ietf-stir-rph-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 : ---------------------------------------------------------------------------- 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 (January 04, 2018) is 2301 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: 'RFC7340' is defined on line 356, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: July 8, 2018 AT&T 6 S. Das 7 Vencore Labs 8 A. Nguyen 9 Office of Emergency Communication/DHS 10 January 04, 2018 12 PASSporT Extension for Resource-Priority Authorization 13 draft-ietf-stir-rph-02 15 Abstract 17 This document extends the STIR PASSporT specification to allow the 18 inclusion of cryptographically-signed assertions of authorization for 19 the values populated in the SIP 'Resource-Priority' header field, 20 which is used for communications resource prioritization. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 8, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PASSporT 'rph' Claim . . . . . . . . . . . . . . . . . . . . 3 59 4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Authentication Service Behavior . . . . . . . . . . . . . 4 61 4.2. Verification Service Behavior . . . . . . . . . . . . . . 5 62 5. Further Information Associated with Resource-Priority . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 6 65 6.2. PASSporT 'rph' Types . . . . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7.1. Avoidance of replay and cut and paste attacks . . . . . . 7 68 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 7 69 7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 PASSporT [I-D.ietf-stir-passport] is a token format based on JWT 78 [RFC7519] for conveying cryptographically-signed information about 79 the identities involved in personal communications; it is used with 80 STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the 81 identity of the participants in real-time communications established 82 via a protocol like SIP. This specification extends PASSporT to 83 allow cryptographic-signing of the SIP 'Resource-Priority' header 84 field defined in [RFC4412]. 86 [RFC4412] defines the SIP 'Resource-Priority' header field for 87 communications Resource Priority. As specified in [RFC4412], the 88 'Resource-Priority' header field may be used by SIP user agents 89 [RFC3261], including, Public Switched Telephone Network (PSTN) 90 gateways and terminals, and SIP proxy servers to influence 91 prioritization afforded to communication sessions,including PSTN 92 calls. However, the SIP 'Resource-Priority' header field could be 93 spoofed and abused by unauthorized entities. 95 The STIR architecture [RFC7340]assumes that an authority on the 96 originating side of a call provides a cryptographic assurance of the 97 validity of the calling party number in order to prevent 98 impersonation attacks. The STIR architecture allows extension that 99 can be utilized by authorities supporting real-time communication 100 services using the 'Resource-Priority' header field to 101 cryptographically sign the SIP 'Resource-Priority' header field and 102 convey assertion of the authorization for 'Resource-Priority'. For 103 example, the authority on the originating side verifying the 104 authorization of a particular communication for Resource-Priority can 105 use a PASSPorT claim to cryptographically-sign the SIP 'Resource- 106 Priority' header field and convey an assertion of the authorization 107 for 'Resource-Priority'. This will allow a receiving entity 108 (including entities located in different network domains/boundaries) 109 to verify the validity of assertions authorizing Resource-Priority. 110 Cryptographically-signed SIP 'Resource-Priority' headers will allow a 111 receiving entity to verify and act on the information with confidence 112 that the information have not been spoofed or compromised. 114 This specification documents an optional extension to PASSporT and 115 the associated STIR mechanisms to provide a function to sign the SIP 116 'Resource-Priority' header field. This PASSporT object is used to 117 provide attestation of a calling user authorization for priority 118 communications. This is necessary in addition to the PASSporT object 119 that is used for calling user telephone number attestation. How the 120 optional extension to PASSporT is used for real-time communications 121 supported using SIP 'Resource-Priority' header field is defined in 122 other documents and is outside the scope of this document. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. PASSporT 'rph' Claim 132 This specification defines a new JSON Web Token claim for "rph", 133 which provides an assertion for information in SIP 'Resource- 134 Priority'header. 136 The creator of a PASSporT object adds a "ppt" value of "rph" to the 137 header of a PASSporT object, in which case the PASSporT claims MUST 138 contain a "rph" claim, and any entities verifying the PASSporT object 139 will be required to understand the "ppt" extension in order to 140 process the PASSporT in question. A PASSPorT header with the "ppt" 141 included will look as follows: 143 { "typ":"passport", 144 "ppt":"rph", 145 "alg":"ES256", 146 "x5u":"https://www.example.org/cert.cer"} 148 The "rph" claim will provide an assertion of authorization,"auth", 149 for information in the SIP "Resource-Priority" header field (i.e., 150 Resource-Priority: namespace "." r-priority) based on [RFC4412]. 151 Specifically, the "rph" claim includes assertion of the priority- 152 level of the user to be used for a given communication session. The 153 value of the "rph" claim is an array containing one or more of JSON 154 objects for the content of the SIP 'Resource-Priority' header that is 155 being asserted of which one of the "rph" object, is mandatory. 157 The following is an example "rph" claim for a SIP "Resource-Priority" 158 header field with a "namespace "." r-priority" value of "ets.0" and 159 with a "namespace "." r-priority" value of "wps.0". 161 { "orig":{"tn":"12155551212"} 162 "dest":{["tn":"12125551213"]}, 163 "iat":1443208345, 164 "rph":{"auth":["ets.0","wps.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 authorizing 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.eyJpc3MiOiJleUowZVhBaU9pSnd 190 ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO 191 aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW 192 EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW 193 pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR 194 VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z 195 aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D 196 l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ 197 oos2P2Dyw"; info= "https://www.example.org/cert.cer";alg=ES256; 198 ppt="rph" 200 A SIP authentication service typically will derive the value of "rph" 201 from the 'Resource-Priority' header field based on policy associated 202 with service specific use of the "namespace "." r-priority" values 203 based on [RFC4412]. The authentication service derives the value of 204 the PASSPorT claim by verifying the authorization for Resource- 205 Priority (i.e., verifying a calling user privilege for Resource- 206 Priority based on its identity) which might be derived from customer 207 profile data or from access to external services. 209 [RFC4412] allows multiple "namespace "." r-priority" pairs, either in 210 a single SIP Resource-Priority header or across multiple SIP 211 Resource-Priority headers. However, it is not necessary to sign all 212 content of a SIP Resource-Priority header or all SIP Resource- 213 Priority headers in a given SIP message. An authority is only 214 responsible for signing the content of a SIP Resource-Priority header 215 for which it has authority (e.g., a specific "namespace "." 216 r-priority"). 218 4.2. Verification Service Behavior 220 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 221 specifications defining "ppt" values describe any additional verifier 222 behavior. The behavior specified for the "ppt" values of "rph" is as 223 follows: 225 The verification service MUST extract the value associated with the 226 "auth" key in a full form PASSPorT with a "ppt" value of "rph". If 227 the signature validates, then the verification service can use the 228 value of the "rph" claim as validation that the calling party is 229 authorized for Resource-Priority, which would in turn be used for 230 priority treatment in accordance with local policy for the associated 231 communication service. 233 In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires 234 "iat" value in "rph" claim to be verified. 236 The behavior of a SIP UAs upon receiving an INVITE containing a 237 PASSporT object with a "rph" claim will largely remain a matter of 238 implementation policy for the specific communication service. In 239 most cases,implementations would act based on confidence in the 240 veracity of this information. The use of the compact form of 241 PASSporT is not specified in this document. 243 5. Further Information Associated with Resource-Priority 245 There may be additional information about the calling party or the 246 call that could be relevant to authorization for Resource-Priority. 247 This may include information related to the device subscription of 248 the caller, or to any institutions that the caller or device is 249 associated with, or even categories of institutions. All of these 250 data elements would benefit from the secure attestations provided by 251 the STIR and PASSporT frameworks. The specification of the "rph" 252 claim could entail the optional presence of one or more such 253 additional information fields. 255 A new IANA registry has been defined to hold potential values of the 256 "rph" array; see Section 6.2. The definition of the "rph" claim may 257 have one or more such additional information field(s). Details of 258 such "rph" claim to encompass other data elements are left for future 259 version of this specification. 261 6. IANA Considerations 263 6.1. JSON Web Token Claims Registration 265 o Claim Name: "rph" 267 o Claim Description: Resource Priority Header Authorization 269 o Change Controller: IESG 271 o Specification Document(s): Section 3 of [RFCThis] 273 6.2. PASSporT 'rph' Types 275 This document requests that the IANA add a new entry to the PASSporT 276 Types registry for the type "rph" which is specified in [RFCThis]. 277 This specification also requests that the IANA create a new registry 278 for PASSporT "rph" types. Registration of new PASSporT "rph" types 279 shall be under the specification required policy. This registry is 280 to be initially populated with a single value for "auth" which is 281 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 paste attacks 290 The PASSporT extension with a "ppt" value of "rph" MUST only be sent 291 with SIP INVITE when 'Resource-Priority' header is used to convey the 292 priority of the communication as defined in [RFC4412]. To avoid the 293 replay, and cut and paste attacks, the procedures described in 294 Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 296 7.2. Solution Considerations 298 The use of extension to PASSporT tokens with "ppt" value "rph" based 299 on the validation of the digital signature and the associated 300 certificate requires consideration of the authentication and 301 authority or reputation of the signer to attest to the identity being 302 asserted. The following considerations should be recognized when 303 using PASSporT extension with "ppt" value of "rph": 305 o An authority (signer) is only allowed to sign the content of a SIP 306 'Resource-Priority' header for which it has the right authority. 307 The authority that signs the token MUST have a secure method for 308 authentication of the end user or the device. 310 o The verification of the signature MUST include means of verifying 311 that the signer is authoritative for the signed content of the SIP 312 'Resource-Priority' header. 314 7.3. Acknowledgements 316 We would like to thank STIR members, ATIS/SIP Forum Task Force on 317 IPNNI members, and the NS/EP Priority Services community for 318 contributions to this problem statement and specification. We would 319 also like to thank David Hancock for his valuable inputs. 321 8. References 323 8.1. Normative References 325 [I-D.ietf-stir-passport] 326 Wendt, C. and J. Peterson, "Personal Assertion Token 327 (PASSporT)", February 2017. 329 [I-D.ietf-stir-rfc4474bis] 330 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 331 "Authenticated Identity Management in the Session 332 Initiation Protocol (SIP)", February 2017. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 340 Priority for the Session Initiation Protocol (SIP)", 341 RFC 4412, DOI 10.17487/RFC4412, February 2006, 342 . 344 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 345 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 346 . 348 8.2. Informative References 350 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 351 A., Peterson, J., Sparks, R., Handley, M., and E. 352 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 353 DOI 10.17487/RFC3261, June 2002, 354 . 356 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 357 Telephone Identity Problem Statement and Requirements", 358 RFC 7340, DOI 10.17487/RFC7340, September 2014, 359 . 361 Authors' Addresses 363 Ray P. Singh 364 Vencore Labs 365 150 Mount Airy Road 366 New Jersey, NJ 07920 367 USA 369 Email: rsingh@vencorelabs.com 370 Martin Dolly 371 AT&T 372 200 Laurel Avenue 373 Middletown, NJ 07748 374 USA 376 Email: md3135@att.com 378 Subir Das 379 Vencore Labs 380 150 Mount Airy Road 381 New Jersey, NJ 07920 382 USA 384 Email: sdas@vencorelabs.com 386 An Nguyen 387 Office of Emergency Communication/DHS 388 245 Murray Lane, Building 410 389 Washington, DC 20528 390 USA 392 Email: an.p.nguyen@HQ.DHS.GOV