Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
Extracted elements (17)
A separate 'rph' PASSporT extension is needed in addition to the telephone-number attestation PASSporT because priority authorization must be separately cryptographically signed to prevent spoofing of the SIP 'Resource-Priority' header field, which could lead to misuse of scarce network resources during congestion.
The compact form of PASSporT is not specified for use with the 'rph' extension; only the full form is used. This ensures all claim fields are available for verification of priority authorization.
The PASSporT 'rph' extension is intended for use in environments where there are means to verify that the signer of the SIP 'Resource-Priority' header field is authoritative; use in other environments is out of scope. How the extension is used for real-time communications is also out of scope.
A PASSporT object with 'ppt' of 'rph' MUST contain an 'rph' claim, and any entities verifying the PASSporT object are required to understand the 'ppt' extension in order to process the PASSporT in question.
If signature validation fails, the SIP 'Resource-Priority' header field SHOULD be stripped from the SIP request and the call treated as an ordinary call.
The authority signing an 'rph' PASSporT MUST use credentials associated with the specific service supported by the resource priority namespace in the claim. There is only one authority per claim.
The 'iat' value in the 'rph' claim must be verified as required by RFC 8224 Section 6.2 Step 4, ensuring freshness of the signed assertion.
The verification service MUST extract the value associated with the 'auth' key in a full-form PASSporT with a 'ppt' value of 'rph' and use it to validate that the calling party is authorized for the SIP 'Resource-Priority' header fields indicated in the claim.
If r-values are added or dropped by intermediaries along the path, those intermediaries must generate a new 'rph' PASSporT header and sign the claim with their own authority credentials.
The Authentication Service constructs the 'rph' claim by verifying the calling-user authorization for the SIP 'Resource-Priority' header field based on identity, deriving values from customer-profile data or external services, following the steps in RFC 8224 Section 4.1.
The 'rph' PASSporT claim provides an assertion of authorization for information in the SIP 'Resource-Priority' header field. The PASSporT header includes a 'ppt' value of 'rph', and the claim contains an 'auth' key whose value is a JSON array of r-values (namespace.priority strings) from the SIP 'Resource-Priority' header field.
IANA has added a new 'rph' claim to the 'JSON Web Token Claims' registry (RFC 7519), with claim description 'Resource Priority Header Authorization' and change controller IESG, as specified in Section 3 of RFC 8443.
IANA has created a new entry 'rph' in the 'Personal Assertion Token (PASSporT) Extensions' registry.
IANA has created a new 'PASSporT Resource Priority Header (rph) Types' registry, initially populated with the value 'auth'. New entries require the name of the 'rph' type and a specification document; registration policy is Specification Required per RFC 8126.
A signer is only allowed to sign SIP 'Resource-Priority' header field content for which it has proper authorization. Before signing tokens, the signer MUST have a secure method for authentication of the end user or device being granted a token.
The PASSporT extension with 'ppt' value of 'rph' MUST only be sent with SIP INVITE when the SIP 'Resource-Priority' header field is used to convey priority. To avoid replay and cut-and-paste attacks, the recommendations in RFC 8224 Section 12.1 MUST be followed.
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, including validating the digital signature and certificate chain to a trust anchor.