diff options
Diffstat (limited to 'doc/rfc/rfc8946.txt')
| -rw-r--r-- | doc/rfc/rfc8946.txt | 881 |
1 files changed, 881 insertions, 0 deletions
diff --git a/doc/rfc/rfc8946.txt b/doc/rfc/rfc8946.txt new file mode 100644 index 0000000..a5de86e --- /dev/null +++ b/doc/rfc/rfc8946.txt @@ -0,0 +1,881 @@ + + + + +Internet Engineering Task Force (IETF) J. Peterson +Request for Comments: 8946 Neustar +Updates: 8224 February 2021 +Category: Standards Track +ISSN: 2070-1721 + + + Personal Assertion Token (PASSporT) Extension for Diverted Calls + +Abstract + + The Personal Assertion Token (PASSporT) is specified in RFC 8225 to + convey cryptographically signed information about the people involved + in personal communications. This document extends PASSporT to + include an indication that a call has been diverted from its original + destination to a new one. This information can greatly improve the + decisions made by verification services in call forwarding scenarios. + Also specified here is an encapsulation mechanism for nesting a + PASSporT within another PASSporT that assists relying parties in some + diversion scenarios. + + This document updates RFC 8224. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8946. + +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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. The "div" PASSporT Type and Claim + 4. Using "div" in SIP + 4.1. Authentication Service Behavior + 4.2. Verification Service Behavior + 5. The "div-o" PASSporT Type + 5.1. Processing "div-o" PASSporTs + 6. Definition of "opt" + 7. "div" and Redirection + 8. Extending "div" to Work with Service Logic Tracking + 9. IANA Considerations + 9.1. JSON Web Token Claims Registrations + 9.1.1. "div" registration + 9.1.2. "opt" registration + 9.2. PASSporT Type Registrations + 10. Privacy Considerations + 11. Security Considerations + 12. References + 12.1. Normative References + 12.2. Informative References + Appendix A. Keys for Examples + Acknowledgments + Author's Address + +1. Introduction + + A Personal Assertion Token (PASSporT) [RFC8225] is a token format + based on the JSON Web Token (JWT) [RFC7519] for conveying + cryptographically signed information about the people involved in + personal communications; it is used by the Secure Telephone Identity + Revisited (STIR) protocol [RFC8224] to convey a signed assertion of + the identity of the participants in real-time communications + established via a protocol like SIP. This specification extends + PASSporT to include an indication that a call has been diverted from + its original destination to a new one. + + Although the STIR problem statement [RFC7340] is focused on + preventing the impersonation of the caller's identity, which is a + common enabler for threats such as robocalling and voicemail hacking + on the telephone network today, it also provides a signature over the + called number at the time that the authentication service sees it. + As [RFC8224], Section 12.1 describes, this protection over the + contents of the To header field is intended to prevent a class of + cut-and-paste attacks. If Alice calls Bob, for example, Bob might + attempt to cut and paste the Identity header field in Alice's INVITE + into a new INVITE that Bob sends to Carol, and thus be able to fool + Carol into thinking the call came from Alice and not Bob. With the + signature over the To header field value, the INVITE Carol sees will + clearly have been destined originally for Bob, and thus Carol can + view the INVITE as suspect. + + However, as [RFC8224], Section 12.1.1 points out, it is difficult for + Carol to confirm or reject these suspicions based on the information + she receives from the baseline PASSporT object. The common "call + forwarding" service serves as a good example of the reality that the + original called party number is not always the number to which a call + is delivered. There are a number of potential ways for + intermediaries to indicate that such a forwarding operating has taken + place. The address in the To header field value of SIP requests is + not supposed to change, according to baseline SIP behavior [RFC3261]; + instead, it is the Request-URI that is supposed to be updated when a + call is retargeted. Practically speaking, however, many operational + environments do alter the To header field. The History-Info header + field [RFC7044] was created to store the Request-URIs that are + discarded by a call in transit. The SIP Diversion header field + [RFC5806], though historic, is still used for this purpose by some + operators today. Neither of these header fields provide any + cryptographic assurance of secure redirection, and they both record + entries for minor syntactical changes in URIs that do not reflect a + change to the actual target of a call. + + Therefore, this specification extends PASSporT with an explicit + indication that the original called number in PASSporT no longer + reflects the destination to which a call is intended to be delivered. + For this purpose, it specifies a Divert PASSporT type ("div") for use + in common SIP retargeting cases; it is expected that in this case, + SIP INVITE requests will carry multiple Identity header fields, each + containing its own PASSporT. Throughout this document, PASSporTs + that contain a "div" element will be referred to as "div" PASSporTs. + Verification services and the relying parties who make authorization + decisions about communications may use this diversion indication to + confirm that a legitimate retargeting of the call has taken place, + rather than a cut-and-paste attack. For out-of-band use cases + [RFC8816] and other non-SIP applications of PASSporT, a separate + "div-o" PASSporT type is also specified, which defines an "opt" + PASSporT element for carrying nested PASSporTs within a PASSporT. + These shall in turn be referred to in this document as "div-o" + PASSporTs. + +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 to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. The "div" PASSporT Type and Claim + + This specification defines a PASSporT [RFC8225] type called "div", + which may be employed by authentication services located at + retargeting entities. All "div" PASSporTs MUST contain a new JSON + Web Token "div" claim, also specified in this document, which + indicates a previous destination for a call during its routing + process. When a retargeting entity receives a call signed with a + PASSporT, it may act as an authentication service and create a new + PASSporT containing the "div" claim to attach to the call. + + Note that a new PASSporT is only necessary when the canonical form of + the "dest" identifier (per the canonicalization procedures in + [RFC8224], Section 8.3) changes due to this retargeting. If the + canonical form of the "dest" identifier is not changed during + retargeting, then a new PASSporT with a "div" claim MUST NOT be + produced. + + The headers of the new PASSporTs generated by retargeting entities + MUST include the "div" PASSporT type and an "x5u" field pointing to a + credential that the retargeting entity controls. "div" PASSporTs MUST + use full form instead of compact form. The new PASSporT header will + look as follows: + + { "typ":"passport", + "ppt":"div", + "alg":"ES256", + "x5u":"https://www.example.com/cert.cer" } + + A "div" PASSporT claims set is populated with elements drawn from the + PASSporT(s) received for a call by the retargeting entity; at a high + level, the original identifier for the called party in the "dest" + object will become the "div" claim in the new PASSporT. If the + "dest" object of the original PASSporT contains multiple identifiers, + because it contains one or more name/value pairs with an array as its + value, the retargeting entity MUST select only one identifier from + the value(s) of the "dest" object to occupy the value of the "div" + field in the new PASSporT. Moreover, it MUST select an identifier + that is within the scope of the credential that the retargeting + entity will specify in the "x5u" of the PASSporT header (as described + below). + + The new target for the call selected by the retargeting entity + becomes the value of the "dest" object of the new PASSporT. The + "orig" object MUST be copied into the new PASSporT from the original + PASSporT received by the retargeting entity. The retargeting entity + SHOULD retain the "iat" object from the original PASSporT, though if + in the underlying signaling protocol (e.g., SIP) the retargeting + entity changes the date and time information in the retargeted + request, the new PASSporT should instead reflect that date and time. + No other claims or extensions are to be copied from the original + PASSporT to the "div" PASSporT. + + So, for an original PASSporT claims set of the form: + + { "dest":{"tn":["12155551213"]}, + "iat":1443208345, + "orig":{"tn":"12155551212"} } + + If the retargeting entity is changing the target from 12155551213 to + 12155551214, the claims set of a "div" PASSporT generated by the + retargeting entity would look as follows: + + { "dest":{"tn":["12155551214"]}, + "div":{"tn":"121555551213"}, + "iat":1443208345, + "orig":{"tn":"12155551212"} } + + The combined full form PASSporT (with a signature covered by the + ES256 keys given in Appendix A) would look as follows: + + eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ + oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ + jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ + 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ + J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ + SqIlk3yCNkg + + The same "div" PASSporT would result if the "dest" object of the + original PASSporT contained an array value, such as + {"tn":["12155551213","19995551234"]}, and the retargeting entity + chose to retarget from the first telephone number in the array. + Every "div" PASSporT is diverting from only one identifier. + + Note that the "div" element may contain other name/value pairs than + just a destination, including a History-Info indicator (see + Section 8). After the PASSporT header and claims have been + constructed, their signature is generated per the guidance in + [RFC8225] -- except for the credential required to sign it. While in + the ordinary construction of a PASSporT, the credential used to sign + will have authority over the identity in the "orig" claim (for + example, a certificate with authority over the telephone number in + "orig" per [RFC8226]), for all PASSporTs using the "div" type the + signature MUST be created with a credential with authority over the + identity present in the "div" claim. So for the example above, where + the original "dest" is "12155551213", the signer of the new PASSporT + object MUST have authority over that telephone number and need not + have any authority over the telephone number present in the "orig" + claim. + + Note that Identity header fields are not ordered in a SIP request, + and in a case where there is a multiplicity of Identity header fields + in a request, some sorting may be required to match "div" PASSporTs + to their originals. + + PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6) + element in their payload. + +4. Using "div" in SIP + + This section specifies SIP-specific usage for the "div" PASSporT type + and its handling in the SIP Identity header field "ppt" parameter + value. Other protocols using PASSporT may define behavior specific + to their use of the "div" claim. + +4.1. Authentication Service Behavior + + An authentication service only adds an Identity header field value + containing the "div" PASSporT type to a SIP request that already + contains at least one Identity header field value; it MUST NOT add a + "div" PASSporT to an INVITE that contains no Identity header field. + The retargeting entity SHOULD act as a verification service and + validate the existing Identity header field value(s) in the request + before proceeding; in some high-volume environments, it may instead + put that burden of validating the chain entirely on the terminating + verification service. As the authentication service will be adding a + new PASSporT that refers to an original, it MUST NOT remove the + original request's Identity header field value before forwarding. + + As was stated in Section 3, the authentication service MUST sign any + "div" PASSporT with a credential that has a scope of authority + covering the identity it populates in the "div" element value. Note + that this is a significant departure from baseline STIR + authentication service behavior, in which the PASSporT is signed by a + credential with authority over the "orig" field. The "div" value + reflects the URI that caused the call to be routed to the retargeting + entity, so in ordinary operations, it would already be the STIR + entity holding the appropriate private keying material for calls + originating from that identity. + + A SIP authentication service typically will derive the "dest" element + value of a "div" PASSporT from a new Request-URI that is set for the + SIP request before it is forwarded. Older values of the Request-URI + may appear in header fields like Diversion or History-Info; this + document specifies an optional interaction with History-Info below in + Section 8. Note as well that because PASSporT operates on + canonicalized telephone numbers and normalized URIs, many smaller + changes to the syntax of identifiers that might be captured by other + mechanisms that record retargeting (like History-Info) will likely + not require a "div" PASSporT. + + When adding an Identity header field with a PASSporT claims set + containing a "div" claim, SIP authentication services MUST also add a + "ppt" parameter to that Identity header with a value of "div". For + the example PASSporT given in Section 3, the new Identity header + added after retargeting might look as follows: + + Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \ + iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \ + Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \ + MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \ + xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \ + ChHhVIiMTSqIlk3yCNkg; \ + info=<https://www.example.com/cert.cer>;ppt="div" + + Note that in some deployments, an authentication service will need to + generate "div" PASSporTs for a request that contains multiple + non-"div" Identity header field values. For example, a request + arriving at a retargeting entity might contain, in different Identity + header fields, a baseline [RFC8224] PASSporT and a PASSporT of type + "rph" [RFC8443] signed by a separate authority. Provided that these + PASSporTs share the same "orig" and "dest" values, the retargeting + entity's authentication service SHOULD generate only one "div" + PASSporT. If the "orig" or "dest" of these PASSporTs differ, + however, one "div" PASSporT SHOULD be generated for each non-"div" + PASSporT. Note that this effectively creates multiple chains of + "div" PASSporTs in a single request, which complicates the procedures + that need to be performed at verification services. + + Furthermore, a request may also be retargeted a second time, at which + point the subsequent retargeting entity SHOULD generate one "div" + PASSporT for each previous "div" PASSporT in the request that + contains a "dest" object with the value of the current target -- but + not for "div" PASSporTs with earlier targets. Ordinarily, the + current target will be readily identifiable, as it will be in the + last "div" PASSporT in each chain, and in SIP cases, it will + correspond to the Request-URI received by the retargeting entity. + Moreover, the current target will be an identifier that the + retargeting entity possesses a credential to sign for, which may not + be true for earlier targets. Ultimately, on each retargeting, the + number of PASSporTs added to a request will be equal to the number of + non-"div" PASSporTs that do not share the same "orig" and "dest" + object values. + +4.2. Verification Service Behavior + + [RFC8224], Section 6.2, Step 5 requires that specifications defining + "ppt" values describe any additional or alternative verifier + behavior. The job of a SIP verification service handling one or more + "div" PASSporTs is very different from that of a traditional + verification service. At a high level, the immediate responsibility + of the verification service is to extract all PASSporTs from the two + or more Identity header fields in a request, identify which are "div" + PASSporTs and which are not, and then order and link the "div" + PASSporTs to the original PASSporT(s) in order to build one or more + chains of retargeting. + + In order to validate a SIP request using the "div" PASSporT type, a + verification service needs to inspect all of the valid Identity + header field values associated with a request, as an Identity header + field value containing "div" necessarily refers to an earlier + PASSporT already in the message. For each "div" PASSporT, the + verification service MUST find an earlier PASSporT that contains a + "dest" claim with a value equivalent to the "div" claim in each "div" + PASSporT. It is possible that this earlier PASSporT will also + contain a "div" and that it will in turn chain to a still earlier + PASSporT stored in a different Identity header field value. If a + complete chain cannot be constructed, the verification service cannot + complete "div" validation; it MAY still validate any non-"div" + PASSporTs in the request per the normal procedures in [RFC8224]. If + a chain has been successfully constructed, the verification service + extracts from the outermost (that is, the most recent) PASSporT in + the chain a "dest" field; this will be a "div" PASSporT that no other + "div" PASSporT in the SIP request refers to. Its "dest" element + value will be referred to in the procedures that follow as the value + of the "outermost "dest" field". + + Ultimately, by looking at this chain of transformations and + validating the associated signatures, the verification service will + be able to ascertain that the appropriate parties were responsible + for the retargeting of the call to its current destination. This can + help the verification service to determine that the original PASSporT + in the call was not simply used in a cut-and-paste attack and inform + any associated authorization decisions in terms of how the call will + be treated -- though, per [RFC8224], Section 6.2.1, that decision is + a matter of local policy and is thus outside the scope of this + specification. + + A verification service parses a chain of PASSporTs as follows: + + 1. The verification service MUST compare the value in the outermost + "dest" field to the target of the call. As it is anticipated + that SIP authentication services that create "div" PASSporTs will + populate the "dest" header from the retargeted Request-URI (see + Section 4.1), in ordinary SIP operations, the Request-URI is + where verification services will find the latest call target. + Note, however, that after a "div" PASSporT has been added to a + SIP request, the Request-URI may have been updated during normal + call processing to an identifier that no longer contains the + logical destination of a call; in this case, the verification + service MAY compare the "dest" field to a provisioned telephone + number for the recipient. + + 2. The verification service MUST validate the signature over the + outermost "div" PASSporT and establish that the credential that + signed the "div" PASSporT has the authority to attest for the + identifier in the "div" element of the PASSporT (per [RFC8224], + Section 6.2, Step 3). + + 3. The verification service MUST validate that the "orig" field of + the innermost PASSporT of the chain (the only PASSporT in the + chain that will not be of PASSporT type "div") is equivalent to + the "orig" field of the outermost "div" PASSporT; in other words, + that the original calling identifier has not been altered by + retargeting authentication services. If the "orig" value has + changed, the verification service MUST treat the entire PASSporT + chain as invalid. The verification service MUST also verify that + all other "div" PASSporTs in the chain share the same "orig" + value. Then, the verification service validates the relationship + of the "orig" field to the SIP-level call signaling per the + guidance in [RFC8224], Section 6.2, Step 2. + + 4. The verification service MUST check the date freshness in the + outermost "div" PASSporT, per [RFC8224], Section 6.2, Step 4. + Furthermore, it is RECOMMENDED that the verification service + check that the "iat" field of the innermost PASSporT is also + within the date freshness interval; otherwise, the verification + service could allow attackers to replay an old, stale PASSporT + embedded in a fresh "div". However, note that in some use cases, + including certain ways that call transfers are implemented, it is + possible that an established call will be retargeted long after + it has originally been placed, and verification services may want + to allow a longer window for the freshness of the innermost + PASSporT if the call is transferred from a trusted party (as an + upper bound, a freshness window on the order of three hours might + suffice). + + 5. The verification service MUST inspect and validate the signatures + on each and every PASSporT object in the chain between the + outermost "div" PASSporT and the innermost PASSporT. Note that + (per Section 4.1) a chain may terminate at more than one + innermost PASSporT, in cases where a single "div" is used to + retarget from multiple innermost PASSporTs. Also note that + [RFC8224], Section 6.2, Step 1 applies to the chain validation + process; if the innermost PASSporT contains an unsupported "ppt", + its chain MUST be ignored. + + Note that the To header field is not used in the first step above. + Optionally, the verification service MAY verify that the To header + field value of the received SIP signaling is equal to the "dest" + value in the innermost PASSporT; however, as has been observed in + some deployments, the original To header field value may be altered + by intermediaries to reflect changes of target. Deployments that + change the original To header field value to conceal the original + destination of the call from the ultimate recipient should note that + the original destination of a call may be preserved in the innermost + PASSporT. Future work on "div" might explore methods to implement + that sort of policy while retaining a secure chain of redirection. + +5. The "div-o" PASSporT Type + + This specification defines a "div-o" PASSporT type that uses the + "div" claim element in conjunction with the "opt" (Section 6) claim + element. As is the case with "div" PASSporT type, a "div-o" PASSporT + is created by an authentication service acting for a retargeting + entity, but instead of generating a separate "div" PASSporT to be + conveyed alongside an original PASSporT, the authentication service + in this case embeds the original PASSporT inside the "opt" element of + the "div-o" PASSporT. The "div-o" extension is designed for use in + non-SIP or gatewayed SIP environments where the conveyance of + PASSporTs in separate Identity header fields in impossible, such as + out-of-band STIR scenarios [RFC8816]. + + The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" + PASSporT header object might look as follows: + + { "typ":"passport", + "ppt":"div-o", + "alg":"ES256", + "x5u":"https://www.example.com/cert.cer" } + + Whereas a "div" PASSporT claims set contains only the "orig", "dest", + "iat", and "div" elements, the "div-o" additionally MUST contain an + "opt" element (see Section 6), which encapsulates the full form of + the previous PASSporT from which the call was retargeted, triggering + the generation of this "div-o". The format of the "opt" element is + identical to the encoded PASSporT format given in Appendix A of + [RFC8225]. + + So, for an original PASSporT claims set of the form: + + { "orig":{"tn":"12155551212"}, + "dest":{"tn":["12155551213"]}, + "iat":1443208345 } + + If the retargeting entity is changing the target from 12155551213 to + 12155551214, the new PASSporT claims set for "div-o" would look as + follows: + + { "orig":{"tn":"12155551212"}, + "dest":{"tn":["12155551214"]}, + "iat":1443208345, + "div":{"tn":"121555551213"}, + "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \ + HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \ + EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \ + E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \ + RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" } + + While in ordinary operations, it is not expected that SIP would carry + a "div-o" PASSporT, it might be possible in some gatewaying + scenarios. The resulting full form Identity header field with a + "div-o" PASSporT would look as follows: + + Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \ + nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \ + N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ + In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ + I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ + YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ + V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ + T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \ + BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \ + VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \ + HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \ + LaDV2y2VtHTLIEgmHig; \ + info=<https://www.example.com/cert.cer>;ppt="div-o" + +5.1. Processing "div-o" PASSporTs + + The authentication and verification service procedures required for + "div-o" closely follow the guidance given in Sections 4.1 and 4.2, + with the major caveats being, first, that they do store or retrieve + PASSporTs via the Identity header field values of SIP requests and, + second, that they process nested PASSporTs in the "opt" claim + element. But transposing the rest of the behaviors described above + to creating and validating "div-o" PASSporTs is straightforward. + + For the "div-o" PASSporT type, retargeting authentication services + that handle calls with one or more existing PASSporTs will create a + corresponding "div-o" PASSporT for each received PASSporT. Each + "div-o" PASSporT MUST contain an "opt" claim set element with the + value of the original PASSporT from which the "div-o" was created; as + specified in Section 4.1, the authentication service MUST populate + the "div" claim set element of the "div-o" PASSporT with the "dest" + field of the original PASSporT. Each received PASSporT may in turn + contain its own "opt" claim set element if the retargeting + authentication service is not the first in its chain. Note that if + the retargeting authentication service is handling a call with + multiple PASSporTs, which in ordinary SIP operation would result in + the construction of multiple "div" chains, it will in effect be + generating one "div-o" PASSporT per chain. + + The job of a verification service is in many ways easier for "div-o" + than for "div", as the verification service has no need to correlate + the PASSporTs it receives and assemble them into chains, as any + chains in "div-o" will be nested through the "opt" element. + Nonetheless, the verification services MUST perform the same chain + validation described in Section 4.2 to validate that each nested + PASSporT shares the same "orig" field as its enclosing PASSporT and + that the "dest" field of each nested PASSporT corresponds to the + "div" field of its enclosing PASSporT. The same checks MUST also be + performed for freshness, signature validation, and so on. It is + similarly OPTIONAL for the verification service to determine that the + "dest" claims element of the outermost PASSporT corresponds to the + called party indication of receive telephone signaling, where such + indication would vary depending on the using protocol. + + How authentication services or verification services receive or + transport PASSporTs for "div-o" is outside the scope of this document + and dependent on the using protocol. + +6. Definition of "opt" + + The presence of an "Original PASSporT" ("opt") claims set element + signifies that a PASSporT encapsulates another entire PASSporT within + it, typically a PASSporT that was transformed in some way to create + the current PASSporT. Relying parties may need to consult the + encapsulated PASSporT in order to validate the identity of a caller. + "opt", as defined in this specification, may be used by future + PASSporT extensions as well as in conjunction with "div-o". + + "opt" MUST contain a quoted full-form PASSporT, as specified by + [RFC8225], Appendix A; it MUST NOT contain a compact form PASSporT. + For an example of a "div-o" PASSporT containing "opt", see Section 5. + +7. "div" and Redirection + + The "div" mechanism exists primarily to prevent false negatives at + verification services when an arriving SIP request, due to + intermediary retargeting, does not appear to be intended for its + eventual recipient, because the original PASSporT "dest" value + designates a different destination. + + Any intermediary that assigns a new target to a request can, instead + of retargeting and forwarding the request, redirect with a 3xx + response code. In ordinary operations, a redirection poses no + difficulties for the operations of baseline STIR: when the user agent + client (UAC) receives the 3xx response, it will initiate a new + request to the new target (typically the target carried in the + Contact header field value of the 3xx), and the "dest" of the + PASSporT created for the new request will match that new target. As + no impersonation attack can arise from this case, it creates no new + requirements for STIR. + + However, some UACs record the original target of a call with + mechanisms like History-Info [RFC7044] or Diversion [RFC5806] and may + want to leverage STIR to demonstrate to the ultimate recipient that + the call has been redirected securely, that is, that the original + destination was the one that sent the redirection message that led to + the recipient receiving the request. The semantics of the PASSporT + necessary for that assertion are the same as those for the "div" + retargeting cases above. The only wrinkle is that the PASSporT needs + to be generated by the redirecting entity and sent back to the + originating user agent client within the 3xx response. + + This introduces more complexity than might immediately be apparent. + In the first place, a 3xx response can convey multiple targets + through the Contact header field value; to accommodate this, the + "div" PASSporT MAY include one "dest" object array value per Contact, + but if the retargeting entity wants to keep the Contact list private + from targets, it may need to generate one PASSporT per Contact. Bear + in mind as well that the original SIP request could have carried + multiple Identity header field values that had been added by + different authentication services in the request path, so a + redirecting entity might need to generate one "div" PASSporT for each + PASSporT in the original request. Often, this will mean just one + "div" PASSporT, but for some deployment scenarios, it could require + an impractical number of combinations. But in very complex call + routing scenarios, attestation of source identity would only add + limited value anyway. + + Therefore, STIR-aware SIP intermediaries that redirect requests MAY + convey one or more PASSporTs in the backwards direction within + Identity header fields. These redirecting entities will act as + authentication services for "div" as described in Section 4.1. This + document consequently updates [RFC8224] to permit carrying Identity + header fields in SIP 300-class responses. It is left to the + originating user agent to determine which Identity header fields + should be copied from the 3xx into any new requests resulting from + the redirection, if any; use of these Identity header fields by + entities receiving a 3xx response is OPTIONAL. + + Finally, note that if an intermediary in the response path consumes + the 3xx and explores new targets itself while performing sequential + forking, it will effectively retarget the call on behalf of the + redirecting server, and this will create the same need for "div" + PASSporTs as any other retargeted call. These intermediaries MAY + also copy PASSporTs from the 3xx response and insert them into + sequential forking requests, if appropriate. + +8. Extending "div" to Work with Service Logic Tracking + + It is anticipated that "div" may be used in concert with History-Info + [RFC7044] in some deployments. It may not be clear from the "orig" + and "dest" values which History-Info header a given PASSporT + correlates to, especially because some of the target changes tracked + by History-Info will not be reflected in a "div" PASSporT (see + Section 1). Therefore, an "hi" element as defined here may appear in + "div" corresponding to the History-Info header field index parameter + value. So for a History-Info header field with an index value of + "1.2.1", the claims set of the corresponding PASSporT with "div" + might look like: + + { "orig":{"tn":"12155551212"}, + "dest":{"tn":["12155551214"]}, + "iat":1443208345, + "div":{"tn":"121555551213", + "hi":"1.2.1"} } + + Past experience has shown that there may be additional information + about the motivation for retargeting, which relying parties might + consider when making authorization decisions about a call; see, for + example, the "reason" associated with the SIP Diversion header field + [RFC5806]. Future extensions to this specification might incorporate + reasons into "div". + +9. IANA Considerations + +9.1. JSON Web Token Claims Registrations + + Per this specification, IANA has added two new claims to the "JSON + Web Token Claims" registry as defined in [RFC7519]. + +9.1.1. "div" registration + + Claim Name: div + + Claim Description: Diverted Target of a Call + + Change Controller: IESG + + Reference: RFC 8946 + +9.1.2. "opt" registration + + Claim Name: opt + + Claim Description: Original PASSporT (in Full Form) + + Change Controller: IESG + + Reference: RFC 8946 + +9.2. PASSporT Type Registrations + + This specification defines two new PASSporT types for the "Personal + Assertion Token (PASSporT) Extensions" registry defined in [RFC8225], + which resides at <https://www.iana.org/assignments/passport>. They + are: + + * "div", as defined in Section 3. + + * "div-o", as defined in Section 5. + + +10. Privacy Considerations + + There is an inherent trade-off in any mechanism that tracks, in SIP + signaling, how calls are routed through a network, as routing + decisions may expose policies set by users for how calls are + forwarded, potentially revealing relationships between different + identifiers representing the same user. Note, however, that in + ordinary operations, this information is revealed to the user agent + service of the called party, not the calling party. It is usually + the called party who establishes these forwarding relationships, and + if indeed some other party is responsible for calls being forwarded + to the called party, many times the called party should likely be + entitled to information about why they are receiving these calls. + Similarly, a redirecting entity who sends a 3xx in the backwards + direction knowingly shares information about service logic with the + caller's network. However, as there may be unforeseen circumstances + where the revelation of service logic to the called party poses a + privacy risk, implementers and users of this or similar diversion- + tracking techniques should understand the trade-off. + + Furthermore, it is a general privacy risk of identity mechanisms + overall that they do not interface well with anonymization services; + the interaction of STIR with anonymization services is detailed in + [RFC8224], Section 11. Any forwarding service that acts as an + anonymizing proxy may not be able to provide a secure chain of + retargeting due to the obfuscation of the originating identity. + + Also see [RFC8224], Section 11 for further considerations on the + privacy of using PASSporTs in SIP. + +11. Security Considerations + + This specification describes a security feature and is primarily + concerned with increasing security when calls are forwarded. + Including information about how calls were retargeted during the + routing process can allow downstream entities to infer particulars of + the policies used to route calls through the network. However, + including this information about forwarding is at the discretion of + the retargeting entity, so if there is a requirement to keep an + intermediate called number confidential, no PASSporT should be + created for that retargeting -- the only consequence will be that + downstream entities will be unable to correlate an incoming call with + the original PASSporT without access to some prior knowledge of the + policies that could have caused the retargeting. + + Any extension that makes PASSporTs larger creates a potential + amplification mechanism for SIP-based DDoS attacks. Since diversion + PASSporTs are created as a part of normal forwarding activity, this + risk arises at the discretion of the retargeting domain; simply using + 3xx response redirections rather than retargeting (by supplying a + "div" per Section 7) mitigates the potential impact. Under unusual + traffic loads, even domains that might ordinarily retarget requests + can switch to redirection. + + SIP has an inherent capability to redirect requests, including + forking them to multiple parties -- potentially, a very large number + of parties. The use of the "div" PASSporT type does not grant any + additional powers to attackers who hope to place bulk calls; if + present, the "div" PASSporT instead identifies the party responsible + for the forwarding. As such, senders of bulk unsolicited traffic are + unlikely to find the use of "div" attractive. + +12. References + +12.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>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and + C. Holmberg, "An Extension to the Session Initiation + Protocol (SIP) for Request History Information", RFC 7044, + DOI 10.17487/RFC7044, February 2014, + <https://www.rfc-editor.org/info/rfc7044>. + + [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>. + + [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity + Credentials: Certificates", RFC 8226, + DOI 10.17487/RFC8226, February 2018, + <https://www.rfc-editor.org/info/rfc8226>. + +12.2. Informative References + + [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in + SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, + <https://www.rfc-editor.org/info/rfc5806>. + + [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure + Telephone Identity Problem Statement and Requirements", + RFC 7340, DOI 10.17487/RFC7340, September 2014, + <https://www.rfc-editor.org/info/rfc7340>. + + [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>. + + [RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity + Revisited (STIR) Out-of-Band Architecture and Use Cases", + RFC 8816, DOI 10.17487/RFC8816, February 2021, + <https://www.rfc-editor.org/info/rfc8816>. + +Appendix A. Keys for Examples + + The following EC256 keys are used in the signing examples given in + this document. WARNING: Do not use this key pair in production + systems. + + -----BEGIN PUBLIC KEY----- + MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4 + hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== + -----END PUBLIC KEY----- + + -----BEGIN EC PRIVATE KEY----- + MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49 + AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4 + +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== + -----END EC PRIVATE KEY----- + +Acknowledgments + + We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean + Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks + for contributions to this document. + +Author's Address + + Jon Peterson + Neustar, Inc. + 1800 Sutter St., Suite 570 + Concord, CA 94520 + United States of America + + Email: jon.peterson@team.neustar |