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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/