draft-ietf-stir-passport-divert-01.txt   draft-ietf-stir-passport-divert-02.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational October 30, 2017 Intended status: Informational March 5, 2018
Expires: May 3, 2018 Expires: September 6, 2018
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-01.txt draft-ietf-stir-passport-divert-02.txt
Abstract Abstract
This document extends PASSporT, which conveys cryptographically- This document extends PASSporT, which conveys cryptographically-
signed information about the people involved in personal signed information about the people involved in personal
communications, to include an indication that a call has been communications, to include an indication that a call has been
diverted from its original destination to a new one. This 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. services in call forwarding scenarios.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3 3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5 3.1. Nesting the original PASSporT in 'div' . . . . . . . . . 5
4.1. Authentication Service Behavior . . . . . . . . . . . . . 5 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6
5. Using 'div' in STIR out-of-band . . . . . . . . . . . . . . . 6 5. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7
6. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extending 'div' to work with Service Logic Tracking . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
PASSporT [I-D.ietf-stir-passport] is a token format based on JWT PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
[RFC7519] for conveying cryptographically-signed information about conveying cryptographically-signed information about the people
the people involved in personal communications; it is used with STIR involved in personal communications; it is used with STIR [RFC8224]
[I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the to convey a signed assertion of the identity of the participants in
identity of the participants in real-time communications established real-time communications established via a protocol like SIP. This
via a protocol like SIP. This specification extends PASSporT to specification extends PASSporT to include an indication that a call
include an indication that a call has been diverted from its has been diverted from its originally destination to a new one.
originally 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 as the authentication service sees it. As called number as the authentication service sees it. As [RFC8224]
[I-D.ietf-stir-rfc4474bis] Section 12.1 describes, this protection Section 12.1 describes, this protection over the contents of the To
over the contents of the To header field is intended to prevent a header field is intended to prevent a class of cut-and-paste attacks.
class of cut-and-paste attacks. If Alice calls Bob, for example, Bob If Alice calls Bob, for example, Bob might attempt to cut-and-paste
might attempt to cut-and-paste the Identity header field in Alice's the Identity header field in Alice's INVITE into a new INVITE that
INVITE into a new INVITE that Bob sends to Carol, and thus be able to Bob sends to Carol, and thus be able to fool Carol into thinking the
fool Carol into thinking the call came from Alice and not Bob. With call came from Alice and not Bob. With the signature over the To
the signature over the To header field value, the INVITE Carol sees header field value, the INVITE Carol sees will clearly have been
will clearly have been destined originally for Bob, and thus Carol destined originally for Bob, and thus Carol can view the INVITE as
can view the INVITE as suspect. suspect.
However, as [I-D.ietf-stir-rfc4474bis] Section 12.1.1 points out, it However, as [RFC8224] Section 12.1.1 points out, it is difficult for
is difficult for Carol to confirm or reject these suspicions based on Carol to confirm or reject these suspicions based on the information
the information she receives from the baseline PASSporT object. The she receives from the baseline PASSporT object. The common "call
common "call forwarding" service serves as a good example of the fact forwarding" service serves as a good example of the fact that the
that the original called party number is not always the number to original called party number is not always the number to which a call
which a call is delivered. The address in the To header field value is delivered. The address in the To header field value of SIP
of SIP requests is not supposed to change, accordingly to baseline requests is not supposed to change, accordingly to baseline
[RFC3261], as it is the Request-URI that is supposed to be updated [RFC3261], as it is the Request-URI that is supposed to be updated
when a call is retargeted, but practically speaking some operational when a call is retargeted, but practically speaking some operational
environments do alter the To header field. There are a number of environments do alter the To header field. There are a number of
potential ways for intermediaries to indicate that such a forwarding potential ways for intermediaries to indicate that such a forwarding
operating has taken place. The History-Info header field [RFC7044] operating has taken place. The History-Info header field [RFC7044]
was created to store the Request-URIs that are discarded by a call in was created to store the Request-URIs that are discarded by a call in
transit. The SIP Diversion header field [RFC5806], though historic, transit. The SIP Diversion header field [RFC5806], though historic,
is still used for this purpose by some operators today. Neither of is still used for this purpose by some operators today. Neither of
these header fields provide any cryptographic assurance of secure these header fields provide any cryptographic assurance of secure
redirection, and they can both capture minor syntactical changes in redirection, and they can both capture minor syntactical changes in
skipping to change at page 3, line 43 skipping to change at page 3, line 43
described in [RFC2119]. described in [RFC2119].
3. PASSporT 'div' Claim 3. PASSporT 'div' Claim
This specification defines a new JSON Web Token claim for "div" which This specification defines a new JSON Web Token claim for "div" 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 (without PASSporT containing the "div" claim to attach to the call (without
removing the original PASSporT). Note that a new PASSporT is only removing the original PASSporT). Note that a new PASSporT is only
necessary when the cannical form of the "dest" identifier (per the necessary when the canonical form of the "dest" identifier (per the
canonicalization procedures in [I-D.ietf-stir-rfc4474bis] Section 8) canonicalization procedures in [RFC8224] Section 8) changes due to
changes due to this retargeting. "div" is typically populated with a this retargeting. "div" is typically populated with a destination
destination address found in the "dest" field of PASSporT received by address found in the "dest" field of PASSporT received by the
the retargeting entity. These new PASSporT generated by retargeting retargeting entity, though it may include other elements as well,
entities MUST include the "div" PASSporT type, and an "x5u" field including a copy of the original PASSporT. These new PASSporT
pointing to a credential that the retargeting entity controls. The generated by retargeting entities MUST include the "div" PASSporT
new PASSporT will look as follows: type, and an "x5u" field pointing to a credential that the
retargeting entity controls. The new PASSporT header will look as
follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"div", "ppt":"div",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "x5u":"https://www.example.com/cert.pkx" }
A PASSporT claims object containing "div" is populated with a A PASSporT claims object containing "div" is populated with a
modification of the original token before the call was retargeted: at modification of the original token before the call was retargeted: at
a high level, the original identifier for the called party in the a high level, the original identifier for the called party in the
"dest" array will become the "div" claim in the new PASSporT. If the "dest" array will become the "div" claim in the new PASSporT. If the
"dest" array of the original PASSporT contains multiple identifiers, "dest" array of the original PASSporT contains multiple identifiers,
the retargeting entity MUST select only one them to occupy the "div" the retargeting entity MUST select only one them to occupy the "div"
field in the new PASSporT. and in particular, it MUST select an field in the new PASSporT. and in particular, it MUST select an
identifier that is within the scope of the credential that the identifier that is within the scope of the credential that the
retargeting entity will specify in the "x5u" of the PASSporT header retargeting entity will specify in the "x5u" of the PASSporT header
(as described below). (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" array of the new PASSporT. The
"orig" value MUST be copied into the new PASSporT from the original "orig" value MUST be copied into the new PASSporT from the original
PASSporT received by the retargeting entity. The regargeting 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" value 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 extension claims should be copied from the original PASSporT No other extension claims should be copied from the original PASSporT
to the "div" PASSporT. to the "div" PASSporT.
So, for an original PASSporT of the form: So, for an original PASSporT of the form:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
skipping to change at page 4, line 46 skipping to change at page 4, line 48
"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 with "div" would look as follows: 12155551214, the new PASSporT with "div" 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"} }
After the PASSporT header and claims have been constructed, their Note that the "div" claim may contain other elements than just a
signature is generated per the guidance in [I-D.ietf-stir-passport] - destination, including a copy of the original PASSporT (see
except for the credential required to sign it. While in the ordinary Section 3.1). After the PASSporT header and claims have been
construction of a PASSporT, the credential used to sign will have constructed, their signature is generated per the guidance in
authority over the identity in the "orig" claim (for example, a
certificate with authority over the telephone number in "orig" per [RFC8225] - except for the credential required to sign it. While in
[I-D.ietf-stir-certificates]), for all PASSporTs using the "div" type the ordinary construction of a PASSporT, the credential used to sign
the signature MUST be created with a credential with authority over will have authority over the identity in the "orig" claim (for
the identity present in the "div" claim. So for the example above, example, a certificate with authority over the telephone number in
where the original "dest" is "12155551213", the signer of the new "orig" per [RFC8226]), for all PASSporTs using the "div" type the
PASSporT object MUST have authority over that telephone number, and signature MUST be created with a credential with authority over the
need not have any authority over the telephone number present in the identity present in the "div" claim. So for the example above, where
"orig" claim. 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.
3.1. Nesting the original PASSporT in 'div'
For some use cases, rather than having multiple unconnected PASSporTS
associated with a single call, it makes more sense to nest the
PASSporTs, explicitly relating two PASSporTs to one another. For
example, when storing a PASSporT with "div" at a Call Placement
Service (CPS) for STIR out-of-band [I-D.ietf-stir-oob] scenarios,
clients MUST include an "opt" element within "div". "opt" contains
the full form of the original PASSporT from which the "div" was
generated. If the diverting entity originally received that PASSporT
encrypted, it MUST decrypt it before storing it in "opt." The entire
"div" PASSporT would than be signed and re-encrypted normally for
storage at an out-of-band Call Placement Service (CPS).
A "div" PASSporT containing the "opt" would look as follows:
{ "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551214"},
"iat":1443208345,
"div":{"tn":"121555551213",
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w"} }
The "opt" extension is RECOMMENDED for use within in-band SIP use
cases as well. The alternative, having multiple Identity headers in
a SIP request, could be confusing for some verification services.
However, nested PASSporTs could result in lengthy Identity headers,
and some operational experience is needed to ascertain how viable
multiple layers of nesting will be.
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 using protocols of PASSporT may define behvaior value. Other using protocols of PASSporT may define behavior
specific to their use of the "div" claim. specific 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 An authentication service only adds an Identity header field
containing the "div" PASSporT type to an SIP request that already containing the "div" PASSporT type to an SIP request that already
contains at least one Identity header field; it MUST NOT add a "div" contains at least one Identity header field; it MUST NOT add a "div"
request to an INVITE that contains no other Identity headers fields. request to an INVITE that contains no other Identity headers fields.
Note that the authentication service doing so does not remove or Note that the authentication service doing so does not remove or
replace any existing Identity header fields, it simply adds a new replace any existing Identity header fields, it simply adds a new
skipping to change at page 5, line 45 skipping to change at page 6, line 39
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="div" info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="div"
A SIP authentication service typically will derive the new value of A SIP authentication service typically will derive the new value of
"dest" from a new Request-URI that is set for the SIP request before "dest" from a new Request-URI that is set for the SIP request before
it is forwarded. Older values of the Request-URI may appear in it is forwarded. Older values of the Request-URI may appear in
header fields like Diversion or History-Info; this document specifies header fields like Diversion or History-Info; this document specifies
no specific interaction between the "div" mechanism and those SIP no specific interaction between the "div" mechanism and those SIP
header fields. Note as well that because PASSporT operates on header fields. Note as well that because PASSporT operates on
canonicalized telephone numbers and normalized URIs, many smaller canonicalized telephone numbers and normalized URIs, many smaller
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 (like History-Info) that record regargeting will likely mechanisms (like History-Info) that record retargeting will likely
not require a "div" PASSporT. not require a "div" PASSporT.
4.2. Verification Service Behavior 4.2. Verification Service Behavior
[I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that [RFC8224] Section 6.2 Step 5 requires that specifications defining
specifications defining "ppt" values describe any additional verifier "ppt" values describe any additional verifier behavior. The behavior
behavior. The behavior specified for the "div" value of "ppt" is as specified for the "div" value of "ppt" is as follows.
follows.
In order to use the "div" extension, a verificiation service needs to In order to use the "div" extension, a verification service needs to
inspect all of the valid Identity header field values associated with inspect all of the valid Identity header field values associated with
a request, as an Identity header field value containing "div" a request, as an Identity header field value containing "div"
necessary refers to an earlier PASSporT already in the message. In necessary refers to an earlier PASSporT already in the message. In
particular, the verification service must find a PASSporT associated particular, the verification service must find a PASSporT associated
with the call, one created earlier, that contains a "dest" claim with with the call, one created earlier, that contains a "dest" claim with
a value equivalent to the "div" claim in the current PASSporT. It is a value equivalent to the "div" claim in the current PASSporT. It is
possible that this earlier PASSporT will also contain a "div", and possible that this earlier PASSporT will also contain a "div", and
that it will in turn chain to a still earlier PASSporT stored in a that it will in turn chain to a still earlier PASSporT stored in a
different Identity header field value. Ultimately, by looking at different Identity header field value. Ultimately, by looking at
this chain of transformations and validating the associated this chain of transformations and validating the associated
signatures, the verification service will be able to ascertain that signatures, the verification service will be able to ascertain that
the appropriate parties were responsible for the retargeting of the the appropriate parties were responsible for the retargeting of the
call to its ultimate destination; this can help the verification call to its ultimate destination; this can help the verification
service to determine that original PASSporT in the call was not service to determine that original PASSporT in the call was not
simply used in a cut-and-paste attack. This will help relying simply used in a cut-and-paste attack. This will help relying
parties to make any associated authorization decisions in terms of parties to make any associated authorization decisions in terms of
how the call will be treated - though, per [I-D.ietf-stir-rfc4474bis] how the call will be treated - though, per [RFC8224] Section 6.2.1,
Section 6.2.1, that decision is a matter of local policy. that decision is a matter of local policy.
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 divert PASSporTs in a request, some sorting may be required to match divert PASSporTs
to their originals. to their originals.
5. Using 'div' in STIR out-of-band 5. 'div' and Redirection
When storing a PASSporT with "div" at a Call Placement Service (CPS) The "div" mechanism exists primarily to prevent false negatives at
for STIR out-of-band [I-D.ietf-stir-rfc4474bis] scenarios, clients verification services when an arriving SIP request, due to
should include an "opt" element within "div". "opt" contains the full intermediary retargeting, does not appear to be intended for its
form of the original PASSporT from which the "div" was generated. If eventual recipient, because its "dest" value designates a different
the diverting entity originally received that PASSporT encrypted, it original destination. Any intermediary that assigns a new target to
MUST decrypt it before storing it in "opt." The entire "div" a request could choose to redirect with a 3xx response code instead
PASSporT would than be signed and re-encrypted normally for storage of retargeting. In ordinary operations, a redirection poses no
at an out-of-band Call Placement Service (CPS). difficult for the operations of baseline STIR: when the UAC receives
the 3xx response, it will initiate a new request to the new target
(typically carried in the Contact header field value of the 3xx), and
the "dest" of the PASSporT created for the new request will match
that new target. As no impersonation attack can arise from this
case, it creates no new requirement for STIR.
A "div" PASSporT containing the "opt" would look as follows: However, some UACs record the original target of a call with
mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and
may want to leverage STIR to demonstrate to the ultimate recipient
that the call has been redirected securely: that is, that the
original destination was the one that sent the redirection message
that led to the recipient receiving the request. The semantics of
the PASSporT necessary to attest that are the same as those for the
"div" retargeting cases above. The only wrinkle is that the PASSporT
needs to be generated by the redirecting entity and sent back to the
originating user agent client within the 3xx response.
This introduces more complexity than might immediately be apparent.
In the first place, a 3xx response can convey multiple targets
through the Contact header field value; and thus the redirecting UAS
needs to include one nested PASSporT per new target. Bear in mind as
well that the original SIP request could have carried multiple
Identity header field values that had been added by different
authentication services in the request path. So a redirecting entity
might need to generate one nested "div" PASSporT per each PASSporT in
the original request per each Contact URI in the 3xx. Often that may
mean just one "div" PASSporT, but for some deployment scenarios, it
could require an impractical number of combinations.
STIR-aware intermediaries that redirect requests MAY therefore convey
one or more PASSporTs in the backwards direction within Identity
headers. This document consequently updates [RFC8224] to permit
carrying Identity headers in SIP 300-class responses. It is left to
authentication services to determine which Identity headers should be
copied into any new requests resulting from the redirection, if any:
use of these Identity headers by entities receiving a 3xx response is
OPTIONAL.
Finally, note that if an intermediary in the response path consumes
the 3xx and explores new targets itself while performing sequential
forking, it will effectively retarget the call on behalf of the
redirecting server, and this will create the same need for "div"
PASSporTs as any other retargeted call.
6. Extending 'div' to work with Service Logic Tracking
It is anticipated that "div" may be used in concert with History-Info
[RFC7044] in some deployments. It may not be clear from the "orig"
and "dest" values which History-Info header a given PASSporT
correlates to, especially because some of the target changes tracked
by History-Info will not be reflected in a "div" PASSporT (see
Section 1). Therefore an "hi" element may appear in "div"
corresponding to the History-Info header field index parameter value.
So for a History-Info header with an index value of "1.2.1", the
claims object of the corresponding PASSporT with "div" 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",
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ "hi":"1.2.1"} }
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w"} }
The "opt" extension is not required for any unencrypted in-band
PASSporT conveyance. For forward compatibility reasons, its use is
not forbidden in those environments.
6. Extending 'div'
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 that 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".
7. Acknowledgments 7. Acknowledgments
skipping to change at page 8, line 15 skipping to change at page 9, line 44
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 the
original called number confidential, no PASSporT should be created original called number confidential, no PASSporT should be created
for that retargeting - the only consequence will be that downstream for that retargeting - the only consequence will be that downstream
entities will be unable to correlate an incoming call with the entities will be unable to correlate an incoming call with the
original PASSporT without access to some prior knowledge of 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.
10. Informative References 10. Informative References
[I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017.
[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-00 (work Architecture and Use Cases", draft-ietf-stir-oob-01 (work
in progress), July 2017. in progress), October 2017.
[I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017.
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017.
[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 9, line 20 skipping to change at page 10, line 35
[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>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
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 US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 24 change blocks. 
111 lines changed or deleted 191 lines changed or added

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