idnits 2.17.1 draft-ietf-stir-rph-emergency-services-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 (July 13, 2020) is 1376 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 260, but not defined == Unused Reference: 'RFC3261' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'RFC8226' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC7375' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 331, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.rosen-stir-emergency-calls' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR M. Dolly 3 Internet-Draft AT&T 4 Intended status: Standards Track C. Wendt 5 Expires: January 14, 2021 Comcast 6 July 13, 2020 8 Assertion Values for a Resource Priority Header Claim and a SIP Priority 9 Header Claim in Support of Emergency Services Networks 10 draft-ietf-stir-rph-emergency-services-02 12 Abstract 14 This document adds new assertion values for a Resource Priority 15 Header ("rph") claim and a new SIP Priority Header claim ("sph") for 16 protection of the "psap-callback" value as part of the "rph" PASSporT 17 extension, in support of the security of Emergency Services Networks 18 for emergency call origination and callback. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 14, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New Assertion Values for "rph" claim . . . . . . . . . . . . 3 57 3.1. ESorig . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. EScallback . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. The SIP Priority header "sph" claim . . . . . . . . . . . . . 4 60 5. Order of Claim Keys . . . . . . . . . . . . . . . . . . . . . 5 61 6. Compact Form of PASSporT . . . . . . . . . . . . . . . . . . 5 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7.1. PASSporT Resource Priority Header (rph) Types . . . . . . 5 64 7.2. JSON Web Token claims . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 9.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Personal Assertion Token (PASSporT) Extension for Resource Priority 74 Authorization [RFC8443] extended the Personal Assertion Token 75 (PASSporT) specification defined in [RFC8225] to allow the inclusion 76 of cryptographically signed assertions of authorization for the 77 values populated in the Session Initiation Protocol (SIP) "Resource- 78 Priority" header field [RFC4412], which is used for communications 79 resource prioritization and the SIP "Priority" header field, used for 80 categorizing the priority use of the call. 82 Compromise of the SIP "Resource-Priority" header field could lead to 83 misuse of network resources (i.e., during congestion scenarios), 84 impacting the application services supported using the SIP "Resource- 85 Priority" header field. 87 [RFC8225] allows extensions by which an authority on the originating 88 side verifying the authorization of a particular communication for 89 the SIP "Resource-Priority" header field or the SIP "Priority" header 90 field can use PASSPorT claims to cryptographically sign the 91 information associated with either the SIP "Resource-Priority" or 92 "Priority" header fields and convey assertion of those values by the 93 signing party authorization. A signed SIP "Resource-Priority" or 94 "Priority" header fields will allow a receiving entity (including 95 entities located in different network domains/boundaries) to verify 96 the validity of assertions to act on the information with confidence 97 that the information has not been spoofed or compromised. 99 This document adds new assertion values for a Resource Priority 100 Header ("rph") claim defined in [RFC8443], in support of Emergency 101 Services Networks for emergency call origination and callback. This 102 document also defines a new claim, "sph", including protection of the 103 SIP Priority header for the indication of an emergency service call- 104 back assigned the value "psap-callback" as defined in [RFC7090]. The 105 use of these new assertion values for real-time communications 106 supported using the SIP 'Resource-Priority' and 'Priority' header 107 fields for emergency services is introduced in 108 [I-D.rosen-stir-emergency-calls] but otherwise out-of-scope of this 109 document. In addition, the PASSPorT claims and values defined in 110 this document are intended for use in environments where there are 111 means to verify that the signer of the SIP 'Resource-Priority' and 112 'Priority' header fields is authoritative. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. New Assertion Values for "rph" claim 124 This specification defines new assertions values for: 126 * "ESorig": Emergency Services call origination 127 * "EScallback": Emergency Services callback. 129 3.1. ESorig 131 When using "ESorig" as the "rph" assertion value, the "orig" claim of 132 the PASSporT MUST represent the calling party number that initiates 133 the call to emergency services. The "dest" claim MUST either be a 134 country or region specific dial string (e.g., "911" for North America 135 or "112" GSM defined string used in Europe and other countries) or 136 "urn:service:sos" as defined in TBD, representing the emergency 137 services destination of the call. 139 The following is an example of an "rph" claim for SIP 'Resource- 140 Priority' header field with a "ESorig" assertion: 142 { 143 "orig":{"tn":"12155551212"}, 144 "dest":{["uri":"urn:service:sos"]}, 145 "iat":1443208345, 146 "rph":{"ESorig":["esnet,x"]} 147 } 149 3.2. EScallback 151 When using "EScallback" as the "rph" assertion value, the "orig" 152 claim of the PASSporT MUST represent the emergency network telephone 153 number. The "dest" claim MUST be the telephone number representing 154 the original calling party of the emergency service call that is 155 being called back. 157 The following is an example of an "rph" claim for SIP 'Resource- 158 Priority' header field with a "EScallback" assertion: 160 { 161 "orig":{"tn":"12155551213"}, 162 "dest":{["tn":"12155551212"]}, 163 "iat":1443208345, 164 "rph":{"EScallback":["esnet,x"]} 165 } 167 After the header and claims PASSporT objects have been constructed, 168 their signature is generated normally per the guidance in [RFC8225] 169 using the full form of PASSPorT. The credentials (i.e., Certificate) 170 used to create the signature must have authority over the namespace 171 of the "rph" claim, and there is only one authority per claim. The 172 authority MUST use its credentials associated with the specific 173 service supported by the resource priority namespace in the claim. 174 If r-values are added or dropped by the intermediaries along the 175 path, the intermediaries must generate a new "rph" header and sign 176 the claim with their own authority. 178 4. The SIP Priority header "sph" claim 180 As discussed in [I-D.rosen-stir-emergency-calls], and as defined in 181 [RFC7090] the SIP Priority header may be set to the value "psap- 182 callback" for emergency services callback calls. Because some SIP 183 networks may act on this value and provide priority or other special 184 routing based on this value, it is important to protect and validate 185 the authoritative use associated with it. 187 Therefore, we define a new claim key as part of the "rph" PASSporT, 188 "sph", which MUST be used only for authorized emergency callbacks and 189 correspond to a SIP Priority header with the value "psap-callback". 191 The value of the "sph" claim key should only be "psap-callback" to 192 match the SIP Priority header field value for authorized emergency 193 services callbacks. 195 The following is an example of an "sph" claim for SIP 'Priority' 196 header field with the value "psap-callback": 198 { 199 "orig":{"tn":"12155551213"}, 200 "dest":{["tn":"12155551212"]}, 201 "iat":1443208345, 202 "rph":{"EScallback":["esnet,x"]}, 203 "sph":"psap-callback" 204 } 206 5. Order of Claim Keys 208 The order of the claim keys MUST follow the rules of [RFC8225] 209 Section 9; the claim keys MUST appear in lexicographic order. 210 Therefore, the claim keys discussed in this document appear in the 211 PASSporT Payload in the following order, 213 o dest 215 o iat 217 o orig 219 o rph 221 o sph 223 6. Compact Form of PASSporT 225 The use of the compact form of PASSporT is not specified in this 226 document or recommended for 'rph' PASSporTs. 228 7. IANA Considerations 230 7.1. PASSporT Resource Priority Header (rph) Types 232 This specification requests that the IANA add two new assertion 233 values to the "PASSporT Resource Priority Header (rph) Types" 234 Registry as defined in [RFC8443]. 236 The following assertion values will be added to the registry: 238 * "ESorig": Emergency Services call origination 239 * "EScallback": Emergency Services callback 241 +--------------+------------+ 242 | rph Type | Reference | 243 +--------------+------------+ 244 | ESorig | [this RFC] | 245 +--------------+------------+ 246 | EScallback | [this RFC] | 247 +--------------+------------+ 249 7.2. JSON Web Token claims 251 This specification requests that the IANA add two new claims to the 252 JSON Web Token Claims registry as defined in [RFC7519]. 254 Claim Name: "sph" 256 Claim Description: SIP Priority header field 258 Change Controller: IESG 260 Specification Document(s): [RFCThis] 262 8. Security Considerations 264 The security considerations discussed in [RFC8224], Section 12, are 265 applicable here. 267 9. References 269 9.1. Normative References 271 [I-D.rosen-stir-emergency-calls] 272 Rosen, B., "Non-Interactive Emergency Calls", draft-rosen- 273 stir-emergency-calls-00 (work in progress), March 2020. 275 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 276 A., Peterson, J., Sparks, R., Handley, M., and E. 277 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 278 DOI 10.17487/RFC3261, June 2002, 279 . 281 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 282 Priority for the Session Initiation Protocol (SIP)", 283 RFC 4412, DOI 10.17487/RFC4412, February 2006, 284 . 286 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 287 Patel, "Public Safety Answering Point (PSAP) Callback", 288 RFC 7090, DOI 10.17487/RFC7090, April 2014, 289 . 291 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 292 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 293 . 295 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 296 "Authenticated Identity Management in the Session 297 Initiation Protocol (SIP)", RFC 8224, 298 DOI 10.17487/RFC8224, February 2018, 299 . 301 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 302 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 303 . 305 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 306 Credentials: Certificates", RFC 8226, 307 DOI 10.17487/RFC8226, February 2018, 308 . 310 [RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal 311 Assertion Token (PASSporT) Extension for Resource Priority 312 Authorization", RFC 8443, DOI 10.17487/RFC8443, August 313 2018, . 315 9.2. Informative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 323 Telephone Identity Problem Statement and Requirements", 324 RFC 7340, DOI 10.17487/RFC7340, September 2014, 325 . 327 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 328 RFC 7375, DOI 10.17487/RFC7375, October 2014, 329 . 331 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 332 Writing an IANA Considerations Section in RFCs", BCP 26, 333 RFC 8126, DOI 10.17487/RFC8126, June 2017, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 Authors' Addresses 342 Martin Dolly 343 AT&T 345 Email: md3135@att.com 347 Chris Wendt 348 Comcast 349 Comcast Technology Center 350 Philadelphia, PA 19103 351 USA 353 Email: chris-ietf@chriswendt.net