draft-ietf-stir-passport-divert-06.txt   draft-ietf-stir-passport-divert-07.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: RFC8224 (if approved) July 8, 2019 Updates: RFC8224 (if approved) November 4, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: January 9, 2020 Expires: May 7, 2020
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-06 draft-ietf-stir-passport-divert-07
Abstract Abstract
This document extends PASSporT, which is specified in RFC 8225 to PASSporT is specified in RFC 8225 to convey cryptographically-signed
convey cryptographically-signed information about the people involved information about the people involved in personal communications.
in personal communications, to include an indication that a call has This document extends PASSporT to include an indication that a call
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
PASSporT that assists relying parties in some diversion scenarios. PASSporT that assists relying parties in some diversion scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 16 skipping to change at page 2, line 16
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
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 . . . . . . . . . . . . . . 7 4.2. Verification Service Behavior . . . . . . . . . . . . . . 8
5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10
6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 11 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 12
7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 12 7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 12
8. Extending 'div' to work with Service Logic Tracking . . . . . 13 8. Extending 'div' to work with Service Logic Tracking . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. JSON Web Token Claims Registrations . . . . . . . . . . 14 10.1. JSON Web Token Claims Registrations . . . . . . . . . . 14
10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 14 10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 15
10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 14 10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 15
10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 14 10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 15
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 17 Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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 23 skipping to change at page 3, line 23
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 [RFC3261], as it is the not supposed to change, according to baseline SIP behavior [RFC3261];
Request-URI that is supposed to be updated when a call is retargeted, instead, it is the Request-URI that is supposed to be updated when a
but practically speaking many operational environments do alter the call is retargeted. Practically speaking, however, many operational
To header field. The History-Info header field [RFC7044] was created environments do alter the To header field. The History-Info header
to store the Request-URIs that are discarded by a call in transit. field [RFC7044] was created to store the Request-URIs that are
The SIP Diversion header field [RFC5806], though historic, is still discarded by a call in transit. The SIP Diversion header field
used for this purpose by some operators today. Neither of these [RFC5806], though historic, is still used for this purpose by some
header fields provide any cryptographic assurance of secure operators today. Neither of these header fields provide any
redirection, and they both record entries for minor syntactical cryptographic assurance of secure redirection, and they both record
changes in URIs that do not reflect a change to the actual target of entries for minor syntactical changes in URIs that do not reflect a
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 "div" PASSporT type for use in
common SIP retargeting cases; it is expected that in this case, SIP common SIP retargeting cases; it is expected that in this case, SIP
INVITE requests will carry multiple Identity header fields, each 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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
follows: 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"
array will become the "div" claim in the new PASSporT. If the "dest" object will become the "div" claim in the new PASSporT. If the
array of the original PASSporT contains multiple identifiers, the "dest" object of the original PASSporT contains multiple identifiers,
retargeting entity MUST select only one them to occupy the "div" because it contains one or more name/value pairs with an array as its
field in the new PASSporT, and in particular, it MUST select an value, the retargeting entity MUST select only one identifier from
identifier that is within the scope of the credential that the the value(s) of the "dest" object to occupy the value of the "div"
retargeting entity will specify in the "x5u" of the PASSporT header field in the new PASSporT. Moreover, it MUST select an identifier
(as described below). that is within the scope of the credential that the retargeting
entity will specify in the "x5u" of the PASSporT header (as described
below).
The new target for the call selected by the retargeting entity The new target for the call selected by the retargeting entity
becomes the value of the "dest" array of the new PASSporT. The becomes the value of the "dest" object of the new PASSporT. The
"orig" value 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" value 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"}, { "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 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"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551214"}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":["121555551213"]} } "div":{"tn":"121555551213"} }
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 \
oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJkZXN0Ijp7InRuI \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \
jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.YZX3UGjaX \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \
sAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cHmaq0Mof2N-bfvRXPXuc \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \
htDJm8VbrbQ SqIlk3yCNkg
Note that the "div" element may contain other elements than just a The same "div" PASSporT would result if the "dest" object of the
destination, including a History-Info indicator (see Section 8). original PASSporT contained an array value, such as
After the PASSporT header and claims have been constructed, their {"tn":["12155551213"],["19995551234"]}, and the retargeting entity
signature is generated per the guidance in [RFC8225] - except for the chose to retarget from the first telephone number in the array.
credential required to sign it. While in the ordinary construction Every "div" PASSporT is diverting from only one identifier.
of a PASSporT, the credential used to sign will have authority over
the identity in the "orig" claim (for example, a certificate with Note that the "div" element may contain other name/value pairs than
authority over the telephone number in "orig" per [RFC8226]), for all just a destination, including a History-Info indicator (see
PASSporTs using the "div" type the signature MUST be created with a Section 8). After the PASSporT header and claims have been
credential with authority over the identity present in the "div" constructed, their signature is generated per the guidance in
claim. So for the example above, where the original "dest" is [RFC8225] - except for the credential required to sign it. While in
"12155551213", the signer of the new PASSporT object MUST have the ordinary construction of a PASSporT, the credential used to sign
authority over that telephone number, and need not have any authority will have authority over the identity in the "orig" claim (for
over the telephone number present in the "orig" claim. example, a certificate with authority over the telephone number in
"orig" per [RFC8226]), for all PASSporTs using the "div" type the
signature MUST be created with a credential with authority over the
identity present in the "div" claim. So for the example above, where
the original "dest" is "12155551213", the signer of the new PASSporT
object MUST have authority over that telephone number, and need not
have any authority over the telephone number present in the "orig"
claim.
Note that Identity header fields are not ordered in a SIP request, 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
skipping to change at page 7, line 13 skipping to change at page 7, line 24
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:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J \ Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \
0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJk \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \
ZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1 \ Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \
NTEyMTMifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEy \ MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \
MTIifX0.YZX3UGjaXsAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cH \ xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \
maq0Mof2N-bfvRXPXuchtDJm8VbrbQ; \ ChHhVIiMTSqIlk3yCNkg; \
info=<https://biloxi.example.org/biloxi.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. Furthermore note that a request may also be retargeted a PASSporT. Note that this effectively creates multiple chains of
second time, at which point the subsequent retargeting entity SHOULD "div" PASSporTs in a single request, which complicates the procedures
generate one "div" PASSporT for each previous "div" PASSporT in the that need to be performed at verification services.
request. This can create multiple chains of "div" PASSporTs in a
single request, which complicates the procedures that need to be Furthermore, a request may also be retargeted a second time, at which
performed at verification services. point the subsequent retargeting entity SHOULD generate one "div"
PASSporT for each previous "div" PASSporT in the request which
contains a "dest" object with the value of the current target - but
not for "div" PASSporTs with earlier targets. Ordinarily, the
current target will be readily identifiable, as it will be in the
last "div" PASSporT in each chain, and in SIP cases it will
correspond to the Request-URI received by the retargeting entity.
Moreover, the current target will be an identifier that the
retargeting entity possess a credential to sign for, which may not be
true for earlier targets. Ultimately, on each retargeting, the
number of PASSporTs added to a request will be equal to the number of
non-"div" PASSporTs that do not share the same "orig" and "dest"
object values.
4.2. Verification Service Behavior 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 headers 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" necessary refers to an earlier PASSporT field value containing "div" necessary refers to an earlier PASSporT
already in the message. For each "div" PASSporT, the verification already in the message. For each "div" PASSporT, the verification
service MUST find an earlier PASSporT that contains a "dest" claim service MUST find an earlier PASSporT that contains a "dest" claim
skipping to change at page 9, line 26 skipping to change at page 9, line 50
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 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". fresh "div". However, note that in some use cases, including
certain ways that blind transfer is implemented, it is possible
that an established call will be retargeted long after it has
originally been placed, and verification services may want to
allow a longer window for the freshness of the innermost PASSporT
if the call is transferred from a trusted party.
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 11, line 9 skipping to change at page 11, line 32
"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":"4F7jsZv0mJ5bjg4Xik6Mfah3IO8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7 \ "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \
c0_0eQi4e9FVX-WmvX3uETtlVjAtgeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3N \ HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \
wb3J0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ. \ EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \
eyJkZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUs \ E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \
Im9yaWciOnsidG4iOiIxMjE1NTU1MTIxMiJ9fQ.4F7jsZv0mJ5bjg4Xik6Mfah3I \ RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw"} }
O8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7c0_0eQi4e9FVX-WmvX3uETtlVjAtg"} }
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 \
nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LnBreCJ9.eyJkZX \ nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \
N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \
In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \
I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \
YlhCc1pTNWpiMjB2WTJWeWRDNXdhM2dpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \
V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \
T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjRGN2pzWnYwbUo1YmpnNFhpaz \ T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \
ZNZmFoM0lPOEs2RklzVUlndnQwZEU3UW0zS1pyNVVGX1VwQ3J6N2MwXzBlUWk0ZTlG \ BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \
VlgtV212WDN1RVR0bFZqQXRnIiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.M \ VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \
CYorw_3FaH78VuERURlJp1hD6qh2eIct4RIebVtYp3es9HTsvCz1qXRWq3j0E9Pb2h \ HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \
YrMUXSQbBYQSviW5cCA; \ LaDV2y2VtHTLIEgmHig; \
info=<https://biloxi.example.org/biloxi.cer>;ppt="div-o" info=<https://www.example.com/cert.cer>;ppt="div-o"
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" will necessarily be specific to the protocol or environment
where it is used, and thus are left to future work. where it is used, and thus are left to future work.
6. Definition of 'opt' 6. Definition of 'opt'
The presence of an original PASSporT claims set element, designated The presence of an original PASSporT claims set element, designated
as "opt", signifies that a PASSporT encapsulates another entire as "opt", signifies that a PASSporT encapsulates another entire
PASSporT within it, typically a PASSporT that was transformed in some PASSporT within it, typically a PASSporT that was transformed in some
skipping to change at page 12, line 38 skipping to change at page 13, line 22
original destination was the one that sent the redirection message original destination was the one that sent the redirection message
that led to the recipient receiving the request. The semantics of that led to the recipient receiving the request. The semantics of
the PASSporT necessary for that assertion are the same as those for the PASSporT necessary for that assertion are the same as those for
the "div" retargeting cases above. The only wrinkle is that the the "div" retargeting cases above. The only wrinkle is that the
PASSporT needs to be generated by the redirecting entity and sent PASSporT needs to be generated by the redirecting entity and sent
back to the originating user agent client within the 3xx response. back to the 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" array value per Contact, but if "div" PASSporT MAY include one "dest" object array value per Contact,
the retargeting entity wants to keep the Contact list private from but if the retargeting entity wants to keep the Contact list private
targets, it may need to generate one PASSporT per Contact. Bear in from targets, it may need to generate one PASSporT per Contact. Bear
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 nested "div" PASSporT redirecting entity might need to generate one "div" PASSporT for each
per each PASSporT in the original request. Often this will mean just PASSporT in the original request. Often, this will mean just one
one "div" PASSporT, but for some deployment scenarios, it could "div" PASSporT, but for some deployment scenarios, it could require
require an impractical number of combinations. But in very complex an impractical number of combinations. But in very complex call
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 STIR-aware SIP intermediaries that redirect requests MAY therefore
convey one or more PASSporTs in the backwards direction within convey one or more PASSporTs in the backwards direction within
Identity headers. 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
headers in SIP 300-class responses. It is left to the originating header fields in SIP 300-class responses. It is left to the
user agent to determine which Identity headers should be copied from originating user agent to determine which Identity header fields
the 3xx into any new requests resulting from the redirection, if any: should be copied from the 3xx into any new requests resulting from
use of these Identity headers by entities receiving a 3xx response is the redirection, if any: use of these Identity header fields by
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
skipping to change at page 15, line 8 skipping to change at page 15, line 48
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 receiving these calls. entitled to information about why they are receiving these calls.
However, as there may be unforeseen circumstances where the However, as there may be unforeseen circumstances where the
revelation of service logic to the called party poses a privacy risk, revelation of service logic to the called party poses a privacy risk,
implementers and users of this or similar diversion-tracking implementers and users of this or similar diversion-tracking
techniques should understand the trade-off. 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 services 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
skipping to change at page 16, line 49 skipping to change at page 17, line 38
[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-04 (work Architecture and Use Cases", draft-ietf-stir-oob-05 (work
in progress), March 2019. in progress), July 2019.
[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. 30 change blocks. 
115 lines changed or deleted 140 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/