RFC 9027

Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks ✨

okay bestie, first things first 🎀 this is RFC 9027, from the Internet Engineering Task Force, dated June 2021. It's a Standards Track document, so it's the real deal 👑 It was written by M. Dolly (AT&T) and C. Wendt (Comcast), and its ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so nothing here replaces or changes an earlier RFC 🦋

Abstract 💜

okay so this doc adds new assertion values for a Resource Priority Header (rph) claim, and it adds a brand new SIP Priority Header (sph) claim. Both are there to protect the psap-callback value, as part of the rph PASSporT extension. The whole point is keeping emergency services networks secure for emergency call origination and callback 🚨🫶

Status of This Memo 🌸

this is an Internet Standards Track document 💅

it's a product of the IETF, which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚

for the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9027 🍓

Copyright Notice 🌈

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ✨

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the date this was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈

also, any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License ⭐

Table of Contents 🦋

1.  Introduction
2.  Terminology
3.  New Assertion Values for "rph" Claim
4.  The SIP Priority Header ("sph") Claim
5.  Order of Claim Keys
6.  Compact Form of PASSporT
7.  IANA Considerations
  7.1.  JSON Web Token Claims
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🎀

so "Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization" is [RFC8443], and it extended the PASSporT spec from [RFC8225] 💖 It lets you include cryptographically signed assertions of authorization for the values in the Session Initiation Protocol (SIP) 'Resource-Priority' header field [RFC4412]. [EMERGENCY-CALLS] explains why we need to protect both the SIP 'Resource-Priority' and 'Priority' header fields, which are used to sort the priority of a call in the telephone network, especially for emergency calls 🚨

the danger is that if someone compromises those headers, they could misuse network resources during congestion. That hits the application services that use the SIP 'Resource-Priority' header field, and it messes with Public Safety Answering Point (PSAP) callbacks 😭

[RFC8225] lets an authority on the originating side check that a particular communication is authorized for the SIP 'Resource-Priority' or SIP 'Priority' header field. Then it can use PASSporT claims to cryptographically sign that info and say, "yep, the signer authorized this." A signed header means a receiving entity (even one in a different network domain or boundary) can verify the assertions and act on them confidently, knowing nobody spoofed or compromised them 👑

this document adds new "auth" array key values for a Resource Priority Header ("rph") claim defined in [RFC8443], for emergency services networks handling call origination and callback 📞 It also defines a new PASSporT claim, "sph", which protects the SIP 'Priority' header field for an emergency service callback marked with the value "psap-callback", as defined in [RFC7090] 🫶 Using these new claim and key values with the SIP 'Resource-Priority' and 'Priority' header fields for emergency services is introduced in [EMERGENCY-CALLS], but it's otherwise out of scope here. And the PASSporT claims and values in this document are meant for environments where you can verify that the signer of those headers is actually authoritative 🔐

2. Terminology 💜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🌸

3. New Assertion Values for "rph" Claim 🦋

this spec lets you sign the SIP 'Resource-Priority' header field namespace for local emergency communications, as defined in [RFC7135]. That namespace is represented by the string esnet.x, where x is the priority level allowed in the esnet namespace. As of writing, the priority level is between 0 and 4, inclusive, but future specs can extend it 🧚

similar to the values [RFC8443] defines for the "auth" JSON object key inside the "rph" claim, the string esnet.x with the appropriate value should be used when resource priority is required for local emergency communications. It has to correspond to and exactly match the SIP 'Resource-Priority' header field representing the namespace invoked in the call 💅

when you use esnet.x as the "auth" assertion value in calls headed to emergency services, the "orig" claim of the PASSporT MUST represent the calling party number that starts the call to emergency services 📞 The "dest" claim MUST be either a country- or region-specific dial string (like "911" for North America, or the "112" GSM-defined string used in Europe and other countries), or "urn:service:sos", as defined in [RFC5031], to represent the emergency services destination of the call 🚨

here's an example of an "rph" claim for the SIP 'Resource-Priority' header field with an "esnet.1" assertion 🎀

{
  "dest":{"uri":["urn:service:sos"]},
  "iat":1615471428,
  "orig":{"tn":"12155551212"},
  "rph":{"auth":["esnet.1"]}
}

for emergency services callbacks, the "orig" claim of the "rph" PASSporT MUST represent the Public Safety Answering Point (PSAP) telephone number 📞 The "dest" claim MUST be the telephone number of the original calling party from the emergency service call that's now being called back 🔁

and here's an example of an "rph" claim for the SIP 'Resource-Priority' header field with an "esnet.0" assertion 💖

{
  "dest":{"tn":["12155551212"]},
  "iat":1615471428,
  "orig":{"tn":"12155551213"},
  "rph":{"auth":["esnet.0"]}
}

once the header and claims PASSporT objects are built, the signature is generated normally, following the guidance in [RFC8225], using the full form of PASSporT ✨ The credentials (i.e., Certificate) used to create the signature must have authority over the namespace of the "rph" claim, and there's only one authority per claim. The authority MUST use its credentials tied to the specific service the resource priority namespace supports in the claim 🔐 If intermediaries along the path add or drop r-values, the intermediaries must generate a new "rph" identity header and sign the claim with their own authority 🫶

4. The SIP Priority Header ("sph") Claim 👑

as defined in [RFC7090], the SIP 'Priority' header field may be set to the value "psap-callback" for emergency services callback calls 📞 Some SIP networks act on this value and give priority or other special routing based on it, so it's super important to protect and validate the authoritative use tied to it 😤

so we define a new claim key, "sph", as part of the "rph" PASSporT 🎀 It's an optional claim that MUST only be used with an "auth" claim whose value is "esnet.x", which indicates an authorized emergency callback call. It has to correspond to a SIP 'Priority' header field with the value "psap-callback" 💅

the value of the "sph" claim key should only be "psap-callback", and it MUST match the SIP 'Priority' header field value for authorized emergency services callbacks. If the value is anything other than "psap-callback", the PASSporT validation MUST be considered a failure case 🚫

quick note: this spec is only for emergency services, so it's also assumed that the signer of the "rph" PASSporT can authoritatively represent both the 'Resource-Priority' header field content and the 'Priority' header field info for an emergency services callback, where both could exist 🧚 This doc is not meant to be a general mechanism for protecting the SIP 'Priority' header fields. That could happen later, with a new PASSporT extension, or a new claim added to an existing PASSporT or PASSporT extension usage 🦋

here's an example of an "sph" claim for the SIP 'Priority' header field with the value "psap-callback" 🌈

{
  "dest":{"tn":["12155551212"]},
  "iat":1615471428,
  "orig":{"tn":"12155551213"},
  "rph":{"auth":["esnet.0"]},
  "sph":"psap-callback"
}

---

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, DOI 10.17487/RFC4412, February 2006, <https://www.rfc-editor.org/info/rfc4412>.

[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, DOI 10.17487/RFC5031, January 2008, <https://www.rfc-editor.org/info/rfc5031>.

[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, DOI 10.17487/RFC7090, April 2014, <https://www.rfc-editor.org/info/rfc7090>.

[RFC7135] Polk, J., "Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications", RFC 7135, DOI 10.17487/RFC7135, May 2014, <https://www.rfc-editor.org/info/rfc7135>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.

[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.

[RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization", RFC 8443, DOI 10.17487/RFC8443, August 2018, <https://www.rfc-editor.org/info/rfc8443>.

9.2. Informative References

[EMERGENCY-CALLS] Rosen, B., "Non-Interactive Emergency Calls", Work in Progress, Internet-Draft, draft-rosen-stir-emergency-calls-00, 9 March 2020, <https://tools.ietf.org/html/draft-rosen-stir-emergency-calls-00>.

Acknowledgements 🫶

Huge thanks to Brian Rosen, Terry Reese, and Jon Peterson, who gave the authors helpful suggestions, comments, and corrections. 💖

Authors' Addresses 🎀

Martin Dolly
AT&T

Email: md3135@att.com


Chris Wendt
Comcast
Comcast Technology Center
Philadelphia, PA 19103
United States of America

Email: chris-ietf@chriswendt.net