Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
Vencore Labs150 Mount Airy RoadNew Jersey, NJ 07920United States of Americarsingh@vencorelabs.comAT&T200 Laurel AvenueMiddletown, NJ 07748 United States of Americamd3135@att.comVencore Labs150 Mount Airy RoadNew Jersey, NJ 07920United States of Americasdas@vencorelabs.comOffice of Emergency Communication/DHS245 Murray Lane, Building 410Washington, DC 20528United States of Americaan.p.nguyen@HQ.DHS.GOV
ART
STIR
This document extends the Personal Assertion Token (PASSporT) specification
defined in RFC 8225 to allow the inclusion of cryptographically
signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for
communications resource prioritization.
PASSporT is a token format based on JSON
Web Token (JWT) for conveying
cryptographically signed information about the identities involved in
personal communications. PASSporT with Secure Telephone Identity
Revisited (STIR) provides a mechanism by
which an authority on the originating side of a call, using a protocol
like SIP , can provide a cryptographic
assurance of the validity of the calling party telephone number in
order to prevent impersonation attacks. defines a mechanism to prioritize access to SIP-signaled resources during periods of communications resource scarcity using the SIP 'Resource-Priority' header. As specified in
, the SIP 'Resource-Priority' header field may
be used by SIP user agents (UAs)
(including Public Switched Telephone Network (PSTN) gateways and SIP
proxy servers) to influence prioritization afforded to communication
sessions, including PSTN calls (e.g., to manage scarce network
resources during network congestion scenarios). However, the SIP
'Resource-Priority' header field could be spoofed and abused by
unauthorized entities, the threat models and use cases of which are
described in and ,
respectively. Compromise of the SIP 'Resource-Priority' header field
could lead to misuse of network resources
(i.e., during congestion scenarios), impacting the application
services supported using the SIP 'Resource-Priority' header field. allows extensions by which an authority
on the originating side verifying the authorization of a
particular communication for the SIP 'Resource-Priority' header field can use a PASSPorT
claim to cryptographically sign the SIP 'Resource-Priority' header field
and convey assertion of the authorization for the SIP 'Resource-Priority' header field. A
signed SIP 'Resource-Priority' header field will allow a receiving
entity (including entities located in different network
domains/boundaries) to verify the validity of assertions authorizing
the SIP 'Resource-Priority' header field and to act on the information with confidence that
the information has not been spoofed or compromised. This specification documents an extension to PASSporT and the
associated STIR mechanisms to provide a function to cryptographically
sign the SIP 'Resource-Priority' header field. This PASSporT object is
used to provide attestation of a calling-user authorization for
priority communications. This is necessary in addition to the
PASSporT object that is used for calling-user telephone-number
attestation. How this extension to PASSporT is used for real-time
communications supported using the SIP 'Resource-Priority' header field
is outside the scope of this document. In addition, the PASSPorT
extension defined in this document is intended for use in environments
where there are means to verify that the signer of the SIP
'Resource-Priority' header field is authoritative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
This specification defines a new JSON Web Token claim for "rph" that
provides an assertion for information in the SIP 'Resource-Priority' header field. The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a
PASSporT object. The PASSporT claims MUST contain an "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: The "rph" claim will provide an assertion of authorization, "auth", for information in the SIP 'Resource-Priority' header field
based on . The syntax is: Specifically, the "rph" claim includes an assertion of the priority level of the user to be used for a given communication session. The value of the "rph" claim is an object
with one or more keys. Each key is associated with a JSON array. These arrays contain strings that correspond to the r-values indicated in the SIP 'Resource-Priority'
header field.
The following is an example "rph" claim for a SIP 'Resource-Priority' header field with one r-value of "ets.0" and with another r-value of "wps.0": After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in
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 is only
one authority per claim. The authority MUST use its credentials associated with the specific service supported by the resource priority namespace
in the claim. If r-values are added or dropped by the intermediaries along
the path, the intermediaries must generate a new "rph" header
and sign the claim with their own authority. The use of the compact form of PASSporT is not specified in this document. This section specifies SIP-specific usage for the "rph" claim in PASSporT. The Authentication Service will create the "rph" claim using the values
discussed in of this document that are based on . The construction
of the "rph" claim follows the steps described in Section 4.1 of . The resulting Identity header for "rph" might look as follows (backslashes shown for line folding only): A SIP authentication service will derive the value of "rph" from the
SIP 'Resource-Priority' header field based on policy associated with
service-specific use of r-values, defined as follows in :
r-value = namespace "." r-priority
The authentication service derives the value of the PASSPorT claim by verifying the
authorization for the SIP 'Resource-Priority' header field (i.e.,
verifying a calling-user privilege for the SIP 'Resource-Priority'
header field based on its identity). The authorization might be
derived from customer-profile data or access to external
services. allows multiple "namespace "." priority value" pairs, either in a single SIP 'Resource-Priority' header field or across multiple SIP
'Resource-Priority' header fields. An authority is responsible for signing all the content of a SIP 'Resource-Priority' header field for which it has the authority. , Section 6.2, Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The
behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the
"auth" key in a full-form PASSPorT with a "ppt" value of "rph". If the
signature validates, then the verification service can use the value
of the "rph" claim as validation that the calling party is authorized
for SIP 'Resource-Priority' header fields as indicated in the claim. This value
would, in turn, be used for priority treatment in accordance with
local policy for the associated communication service. If the
signature validation fails, the verification service should infer that
the calling party is not authorized for SIP 'Resource-Priority' header fields as
indicated in the claim. In such cases, the priority treatment for the
associated communication service is handled as per the local policy of
the verifier. In such scenarios, the SIP 'Resource-Priority' header field
SHOULD be stripped from the SIP request, and the network entities
should treat the call as an ordinary call. In addition, , Section 6.2, Step 4
requires the "iat" value in "rph" claim to be verified. The behavior of a SIP UA upon receiving an INVITE containing a
PASSporT object with an "rph" claim will largely remain a matter of
implementation policy for the specific communication service. In most
cases, implementations would act based on confidence in the veracity
of this information. There may be additional information about the calling party or the
call that could be relevant to authorization for the SIP
'Resource-Priority' header field. This may include information related
to the device subscription of the caller, to any institutions that
the caller or device is associated with, or even to categories of
institutions. All of these data elements would benefit from the
secure attestations provided by the STIR and PASSporT frameworks. The
specification of the "rph" claim could entail the optional presence of
one or more such additional information fields applicable to the SIP
'Resource-Priority' header field. A new IANA registry has been defined to hold potential values of the "rph"
array; see . The definition of the "rph" claim may have one or more such additional
information field(s). Details of how an "rph" claim encompasses other data
elements are left for future specifications. IANA has added a new claim to the "JSON Web
Token Claims" registry as defined in .Claim Name: "rph"Claim Description: Resource Priority Header AuthorizationChange Controller: IESGSpecification Document(s): of RFC 8443IANA has created a new entry in the
"Personal Assertion Token (PASSporT) Extensions" registry for the type "rph", which is specified in this document. In addition, the "PASSporT Resource Priority Header (rph) Types" registry has been created in which each entry must contain two fields: the name of the "rph" type and the specification
in which the type is described. This registry has been initially populated
with the single value for "auth", which is specified in this document.
Registration of new "rph" types shall be under the Specification Required policy. The security considerations discussed in , Section 12, are applicable here. The PASSporT extension with a "ppt" value of "rph"
MUST only be sent with SIP INVITE when the SIP 'Resource-Priority' header field is used to convey the priority of the communication, as defined in .
To avoid replay and cut-and-paste attacks, the recommendations provided in Section 12.1 of MUST be followed.
Using extensions to PASSporT tokens with a "ppt" value of "rph" requires knowledge of the authentication, authorization, and reputation of the signer to attest to the
identity being asserted, including validating the digital signature and the associated certificate chain to a trust anchor. The following considerations should be
recognized when using PASSporT extensions with a "ppt" value of "rph":
A signer is only allowed to sign the content of a SIP 'Resource-Priority' header field for which it has the proper authorization. Before signing tokens, the signer
MUST have a secure method for authentication of the end user or the device being granted a token. The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the resource priority namespace in the
PASSporT. We would like to thank STIR Working Group members, the ATIS/SIP Forum Task Force on IPNNI members, and the NS/EP Priority Services community for contributions to this problem
statement and specification. We would also like to thank David Hancock and Ning Zhang for their valuable inputs.