draft-ietf-stir-passport-divert-08.txt   draft-ietf-stir-passport-divert-09.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: RFC8224 (if approved) March 9, 2020 Updates: RFC8224 (if approved) July 13, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2020 Expires: January 14, 2021
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-08 draft-ietf-stir-passport-divert-09
Abstract Abstract
PASSporT is specified in RFC 8225 to convey cryptographically-signed PASSporT is specified in RFC 8225 to convey cryptographically-signed
information about the people involved in personal communications. information about the people involved in personal communications.
This document extends PASSporT to include an indication that a call This document extends PASSporT to include an indication that a call
has been diverted from its original destination to a new one. This has been diverted from its original destination to a new one. This
information can greatly improve the decisions made by verification information can greatly improve the decisions made by verification
services in call forwarding scenarios. Also specified here is an services in call forwarding scenarios. Also specified here is an
encapsulation mechanism for nesting a PASSporT within another encapsulation mechanism for nesting a PASSporT within another
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4 3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 8 4.2. Verification Service Behavior . . . . . . . . . . . . . . 8
5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10
6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 12 5.1. Processing 'div-o' PASSporTs . . . . . . . . . . . . . . 12
7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 12 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 13
7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 13
8. Extending 'div' to work with Service Logic Tracking . . . . . 14 8. Extending 'div' to work with Service Logic Tracking . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.1. JSON Web Token Claims Registrations . . . . . . . . . . 14 10.1. JSON Web Token Claims Registrations . . . . . . . . . . 15
10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 15 10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 15
10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 15 10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 16
10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 15 10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 16
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 18 Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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 [RFC8224]) protocol 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 This specification therefore 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 "div" PASSporT type for use in For this purpose, it specifies a Divert PASSporT type ("div") for use
common SIP retargeting cases; it is expected that in this case, SIP in common SIP retargeting cases; it is expected that in this case,
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
[I-D.ietf-stir-oob] use cases, and other non-SIP applications of [I-D.ietf-stir-oob] use cases, and other non-SIP applications of
PASSporT, a separate "div-o" PASSporT type is also specified, which PASSporT, a separate "div-o" PASSporT type is also specified, which
defines an "opt" PASSporT element for carrying nested PASSporTs defines an "opt" PASSporT element for carrying nested PASSporTs
within a PASSporT. These shall in turn be referred to in this within a PASSporT. These shall in turn be referred to in this
skipping to change at page 4, line 26 skipping to change at page 4, line 26
that may be employed by authentication services located at that 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) changes due to this retargeting. If the [RFC8224] Section 8.3) changes due to this retargeting. If the
canonical form of the "dest" identifiier 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 credential that the retargeting entity controls. "div" PASSporTs a credential that the retargeting entity controls. "div" PASSporTs
MUST use full form instead of compact form. The new PASSporT header MUST use full form instead of compact form. The new PASSporT header
will look as follows: will look as follows:
{ "typ":"passport", { "typ":"passport",
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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:
{ "orig":{"tn":"12155551212"}, { "dest":{"tn":["12155551213"]},
"dest":{"tn":["12155551213"]}, "iat":1443208345,
"iat":1443208345 } "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:
{ "orig":{"tn":"12155551212"}, { "dest":{"tn":["12155551214"]},
"dest":{"tn":["12155551214"]}, "div":{"tn":"121555551213"},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213"} } "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
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 which
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 possess a credential to sign for, which may not be retargeting entity possesses a credential to sign for, which may not
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
skipping to change at page 9, line 11 skipping to change at page 9, line 11
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 a
matter of local policy and is thus outside the scope of this matter of local policy and is thus outside the scope of this
specification. A verification service parses a chain of PASSporTs as specification.
follows:
A verification service parses a chain of PASSporTs as follows:
First, the verification service MUST compare the value in the First, the verification service MUST compare the value in the
outermost "dest" field to the target of the call. As it is outermost "dest" field to the target of the call. As it is
anticipated that SIP authentication services that create "div" anticipated that SIP authentication services that create "div"
PASSporTs will populate the "dest" header from the retargeted PASSporTs will populate the "dest" header from the retargeted
Request-URI (see Section 4.1), in ordinary SIP operations, the Request-URI (see Section 4.1), in ordinary SIP operations, the
Request-URI is where verification services will find the latest Request-URI is where verification services will find the latest
call target. Note however that after a "div" PASSporT has been call target. Note however that after a "div" PASSporT has been
added to a SIP request, the Request-URI may have been updated added to a SIP request, the Request-URI may have been updated
during normal call processing to an identifier that no longer during normal call processing to an identifier that no longer
skipping to change at page 10, line 5 skipping to change at page 10, line 6
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 Fourth, the verification service MUST check the date freshness in
the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It
is furthermore RECOMMENDED that the verification service check is furthermore RECOMMENDED that the verification service check
that the "iat" field of the innermost PASSporT is also within the that the "iat" field of the innermost PASSporT is also within the
date freshness interval; otherwise the verification service could date freshness interval; otherwise the verification service could
allow attackers to replay an old, stale PASSporT embedded in a allow attackers to replay an old, stale PASSporT embedded in a
fresh "div". However, note that in some use cases, including fresh "div". However, note that in some use cases, including
certain ways that blind transfer is implemented, it is possible certain ways that call transfers are implemented, it is possible
that an established call will be retargeted long after it has that an established call will be retargeted long after it has
originally been placed, and verification services may want to originally been placed, and verification services may want to
allow a longer window for the freshness of the innermost PASSporT allow a longer window for the freshness of the innermost PASSporT
if the call is transferred from a trusted party. if the call is transferred from a trusted party (as an upper
bound, a freshness window on the order of three hours might
suffice).
Fifth, the verification service MUST inspect and validate the Fifth, the verification service MUST inspect and validate the
signatures on each and every PASSporT object in the chain between signatures on each and every PASSporT object in the chain between
the outermost "div" PASSporT and the innermost PASSporT. Note the outermost "div" PASSporT and the innermost PASSporT. Note
that (per Section 4.1) a chain may terminate at more than one that (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.
skipping to change at page 10, line 36 skipping to change at page 10, line 39
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) PASSporT "div" claim element in conjunction with the "opt" (Section 6) claim
claim element. As is the case with "div" PASSporT type, a "div-o" element. As is the case with "div" PASSporT type, a "div-o" PASSporT
PASSporT is created by an authentication service acting for a is created by an authentication service acting for a retargeting
retargeting entity, but instead of generating a separate "div" entity, but instead of generating a separate "div" PASSporT to be
PASSporT to be conveyed alongside an original PASSporT, the conveyed alongside an original PASSporT, the authentication service
authentication service in this case embeds the original PASSporT in this case embeds the original PASSporT inside the "opt" element of
inside the "opt" element of the "div-o" PASSporT. The "div-o" the "div-o" PASSporT. The "div-o" extension is designed for use in
extension is designed for use in non-SIP or gatewayed SIP non-SIP or gatewayed SIP environments where the conveyance of
environments where the conveyance of PASSporTs in separate Identity PASSporTs in separate Identity header fields in impossible, such as
header fields in impossible, such as out-of-band [I-D.ietf-stir-oob] out-of-band [I-D.ietf-stir-oob] STIR scenarios.
STIR scenarios.
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",
"iat", and "div" elements, the "div-o" additionally MUST contain an "iat", and "div" elements, the "div-o" additionally MUST contain an
"opt" element (see Section 6), which encapsulates the full form of "opt" element (see Section 6), which encapsulates the full form of
the previous PASSporT from which the call was retargeted, triggering the previous PASSporT from which the call was retargeted, triggering
the generation of this "div-o". The value of the "opt" element is the generation of this "div-o". The format of the "opt" element is
identical to the base64 encoded PASSporT format given in Appendix A identical to the encoded PASSporT format given in Appendix A of
of [RFC8225]. [RFC8225].
So, for an original PASSporT claims set of the form: So, for an original PASSporT claims set of the form:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]}, "dest":{"tn":["12155551213"]},
"iat":1443208345 } "iat":1443208345 }
If the retargeting entity is changing the target from 12155551213 to If the retargeting entity is changing the target from 12155551213 to
12155551214, the new PASSporT claims set for "div-o" would look as 12155551214, the new PASSporT claims set for "div-o" would look as
follows: follows:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213"}, "div":{"tn":"121555551213"},
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \ "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \
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
The authentication and verification service procedures required for The authentication and verification service procedures required for
"div-o" will necessarily be specific to the protocol or environment "div-o" closely follow the guidance given in Section 4.1 and
where it is used, and thus are left to future work. Section 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;
and 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 fo 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' 6. Definition of 'opt'
The presence of an original PASSporT claims set element, designated The presence of an "Original PASSporT" ("opt") claims set element
as "opt", signifies that a PASSporT encapsulates another entire signifies that a PASSporT encapsulates another entire PASSporT within
PASSporT within it, typically a PASSporT that was transformed in some it, typically a PASSporT that was transformed in some way to create
way to create the current PASSporT. Relying parties may need to the current PASSporT. Relying parties may need to consult the
consult the encapsulated PASSporT in order to validate the identity encapsulated PASSporT in order to validate the identity of a caller.
of a caller. "opt" as defined in this specification may be used by "opt" as defined in this specification may be used by future PASSporT
future PASSporT extensions as well as in conjunction with "div-o". extensions as well as in conjunction with "div-o".
"opt" MUST contain a quoted base64 encoded full-form PASSporT as "opt" MUST contain a quoted full-form PASSporT as specified by
specified by [RFC8225] Appendix A; it MUST NOT contain a compact form [RFC8225] Appendix A; it MUST NOT contain a compact form PASSporT.
PASSporT. For an example of a "div-o" PASSporT containing "opt," see For an example of a "div-o" PASSporT containing "opt," see Section 5.
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
skipping to change at page 15, line 9 skipping to change at page 15, line 43
10.1. JSON Web Token Claims Registrations 10.1. JSON Web Token Claims Registrations
This specification requests that the IANA add two new claims to the This specification requests that the IANA add two new claims to the
JSON Web Token Claims registry as defined in [RFC7519]. JSON Web Token Claims registry as defined in [RFC7519].
10.1.1. 'div' registration 10.1.1. 'div' registration
Claim Name: "div" Claim Name: "div"
Claim Description: New Target of a Call Claim Description: Diverted Target of a Call
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
10.1.2. 'opt' registration 10.1.2. 'opt' registration
Claim Name: "opt" Claim Name: "opt"
Claim Description: Encapsulated JSON token Claim Description: Original PASSporT (in Full Form)
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
10.2. PASSporT Type Registrations 10.2. PASSporT Type Registrations
This specification defines two new PASSporT types for the PASSport This specification defines two new PASSporT types for the PASSport
Extensions Registry defined in [RFC8225], which resides at Extensions Registry defined in [RFC8225], which resides at
https://www.iana.org/assignments/passport/passport.xhtml#passport- https://www.iana.org/assignments/passport/passport.xhtml#passport-
skipping to change at page 15, line 49 skipping to change at page 16, line 39
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.
However, as there may be unforeseen circumstances where the Similarly, a redirecting entity who sends a 3xx in the backwards
revelation of service logic to the called party poses a privacy risk, direction knowingly shares information about service logic with the
implementers and users of this or similar diversion-tracking caller's network. However, as there may be unforeseen circumstances
techniques should understand the trade-off. 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 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 services 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
privacy of using PASSporTs in SIP.
12. Security Considerations 12. 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 the the retargeting entity, so if there is a requirement to keep an
original called number confidential, no PASSporT should be created intermediate called number confidential, no PASSporT should be
for that retargeting - the only consequence will be that downstream created for that retargeting - the only consequence will be that
entities will be unable to correlate an incoming call with the downstream entities will be unable to correlate an incoming call with
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 (with supply 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 numbers
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
skipping to change at page 17, line 44 skipping to change at page 18, line 44
[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 13.2. Informative References
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-06 (work Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), November 2019. 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>.
 End of changes. 31 change blocks. 
78 lines changed or deleted 126 lines changed or added

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