draft-ietf-stir-passport-divert-03.txt   draft-ietf-stir-passport-divert-04.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational July 2, 2018 Updates: RFC8224 (if approved) October 22, 2018
Expires: January 3, 2019 Intended status: Standards Track
Expires: April 25, 2019
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-03.txt draft-ietf-stir-passport-divert-04.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. 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 37 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 January 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 13 skipping to change at page 2, line 14
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
3.1. Nesting the original PASSporT in 'div' . . . . . . . . . 5
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6
5. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 7 5. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 7
6. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7 6. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7
7. Extending 'div' to work with Service Logic Tracking . . . . . 9 7. Extending 'div' to work with Service Logic Tracking . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. 'div' registration . . . . . . . . . . . . . . . . . . . 9
9.2. 'opt' registration . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the people conveying cryptographically-signed information about the people
involved in personal communications; it is used with STIR [RFC8224] involved in personal communications; it is used with STIR [RFC8224]
to convey a signed assertion of the identity of the participants in to convey a signed assertion of the identity of the participants in
real-time communications established via a protocol like SIP. This real-time communications established via a protocol like SIP. This
specification extends PASSporT to include an indication that a call specification extends PASSporT to include an indication that a call
skipping to change at page 3, line 25 skipping to change at page 3, line 27
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
URIs that do not reflect a change to the actual target of a call. URIs that do not reflect a 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 original called number in PASSporT no longer reflects indication that the original called number in PASSporT no longer
the destination to which a call is likely to be delivered. reflects the destination to which a call is likely to be delivered.
Verification services and the relying parties who make authorization Verification services and the relying parties who make authorization
decisions about communications may use this indication to confirm decisions about communications may use this indication to confirm
that a legitimate retargeting of the call has taken place, rather that a legitimate retargeting of the call has taken place, rather
than a cut-and-paste attack. In support of this goal, this than a cut-and-paste attack. In support of this goal, this
specification also defines a nesting mechanism for PASSporTs that specification also defines a nesting mechanism for PASSporTs that
allows the original unmodified PASSporT to be conveyed to relying allows the original unmodified PASSporT to be conveyed to relying
parties. parties.
2. Terminology 2. Terminology
skipping to change at page 3, line 48 skipping to change at page 3, line 50
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
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. Note that
removing the original PASSporT). Note that a new PASSporT is only a new PASSporT is only necessary when the canonical form of the
necessary when the canonical form of the "dest" identifier (per the "dest" identifier (per the canonicalization procedures in [RFC8224]
canonicalization procedures in [RFC8224] Section 8) changes due to Section 8) changes due to this retargeting. "div" is 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 as well as a copy of the original PASSporT.
retargeting entity, though it may include other elements as well, These new PASSporTs generated by retargeting entities MUST include
including a copy of the original PASSporT. These new PASSporT the "div" PASSporT type, and an "x5u" field pointing to a credential
generated by retargeting entities MUST include the "div" PASSporT that the retargeting entity controls. The new PASSporT header will
type, and an "x5u" field pointing to a credential that the look as follows:
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 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" 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 "opt" (see Section 5) contains the full form of the original PASSporT
to the "div" PASSporT. from which the "div" was generated. No other extension claims should
be copied from the original 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"},
"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 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"},
"opt":"eyJ0eXAiOiJwYXNzcG9ydCIsInBwdCI6ImRpdiIsImFsZyI6IkVT \
MjU2IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3g \
ifQ==.eyJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifSwiZGVzdCI6eyJ0b \
iI6IjEyMTU1NTUxMjEzIn0sImlhdCI6MTQ0MzIwODM0NX0=.rq3pjT1hoRw \
akEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3Q \
fPOlckGaS6hEck7w"} }
Note that the "div" claim may contain other elements than just a Note that the "div" claim may contain other elements than just a
destination, including a copy of the original PASSporT (see destination, including a History-Info indicator (see Section 7).
Section 3.1). After the PASSporT header and claims have been After the PASSporT header and claims have been constructed, their
constructed, their signature is generated per the guidance in signature is generated per the guidance in [RFC8225] - except for the
[RFC8225] - except for the credential required to sign it. While in credential required to sign it. While in the ordinary construction
the ordinary construction of a PASSporT, the credential used to sign of a PASSporT, the credential used to sign will have authority over
will have authority over the identity in the "orig" claim (for the identity in the "orig" claim (for example, a certificate with
example, a certificate with authority over the telephone number in authority over the telephone number in "orig" per [RFC8226]), for all
"orig" per [RFC8226]), for all PASSporTs using the "div" type the PASSporTs using the "div" type the signature MUST be created with a
signature MUST be created with a credential with authority over the credential with authority over the identity present in the "div"
identity present in the "div" claim. So for the example above, where claim. So for the example above, where the original "dest" is
the original "dest" is "12155551213", the signer of the new PASSporT "12155551213", the signer of the new PASSporT object MUST have
object MUST have authority over that telephone number, and need not authority over that telephone number, and need not have any authority
have any authority over the telephone number present in the "orig" over the telephone number present in the "orig" claim.
claim.
3.1. Nesting the original PASSporT in 'div'
In some use cases, instead of 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" (see
Section 5) 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).
The "opt" extension is RECOMMENDED for use within in-band SIP use Instead of having multiple unlinked PASSporTs associated with a
cases as well. The alternative, having multiple Identity headers in single call, it is helpful to relying parties to nest diversion
a SIP request, could be confusing for some verification services. PASSporTs, explicitly relating the original PASSporT to the diverted
However, nested PASSporTs could result in lengthy Identity headers, one. Note that the approach of having multiple Identity headers in a
and some operational experience is needed to ascertain how viable SIP request was considered in prior versions of this specification,
multiple layers of nesting will be. but it could be confusing for some verification services. The "opt"
extension is REQUIRED for use within in-band SIP use cases as well as
out-of-band [I-D.ietf-stir-oob] scenarios. Nested PASSporTs could
result in lengthy Identity headers, and some operational experience
is needed to ascertain how resilient legacy implementations will be
to large headers.
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 behavior 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 value
containing the "div" PASSporT type to an SIP request that already containing the "div" PASSporT type to a SIP request that already
contains at least one Identity header field; it MUST NOT add a "div" contains at least one Identity header field value; it MUST NOT add a
request to an INVITE that contains no other Identity headers fields. "div" PASSporT to an INVITE that contains no Identity headers field.
Note that the authentication service doing so does not remove or As the authentication service will be adding a new PASSporT that
replace any existing Identity header fields, it simply adds a new contains an encapsulation of the original, it SHOULD remove the
one. When adding an Identity header field with a PASSporT object original request's Identity header field value before forwarding.
containing a "div" claim, SIP authentication services MUST also add a Note that a request may contain multiple Identity header field values
"ppt" parameter to that Identity header with a value of "div". The generated by different authorities; as a consequence, the retargeting
resulting compact form Identity header field to add to the message authentication service may need to perform this operation on multiple
might look as follows: existing PASSporTs, adding a "div" PASSporT per PASSporT in the
original. When adding an Identity header field with a PASSporT
object containing a "div" claim, SIP authentication services MUST
also add a "ppt" parameter to that Identity header with a value of
"div". The resulting full form Identity header field to add to the
message might look as follows:
Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 \
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJvcmlnIjp7InRuIjoiMTIxNTU1NTE \
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ yMTIifSwiZGVzdCI6eyJ0biI6IjEyMTU1NTUxMjE0In0sImlhdCI6MTQ0MzIwODM0NSwiZGl2 \
Ijp7InRuIjoiMTIxNTU1NTUxMjEzIn0sIm9wdCI6ImV5SjBlWEFpT2lKd1lYTnpjRzl5ZENJc \
0luQndkQ0k2SW1ScGRpSXNJbUZzWnlJNklrVlRNalUySWl3aWVEVjFJam9pYUhSMGNITTZMeT \
kzZDNjdVpYaGhiWEJzWlM1amIyMHZZMlZ5ZEM1d2EzZ2lmUT09LmV5SnZjbWxuSWpwN0luUnV \
Jam9pTVRJeE5UVTFOVEV5TVRJaWZTd2laR1Z6ZENJNmV5SjBiaUk2SWpFeU1UVTFOVFV4TWpF \
ekluMHNJbWxoZENJNk1UUTBNekl3T0RNME5YMD0ucnEzcGpUMWhvUndha0VHakhDbldTd1Vuc \
2hkMC16SjZGMVZPZ0ZXU2pIQnI4UWpwamxrLWNwRllwRllzb2pOQ3BUek8zUWZQT2xja0dhUz \
ZoRWNrN3cifX0=.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpF \
YsojNCpTzO3QfPOlckGaS6hEck7w;
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 retargeting will likely mechanisms that record retargeting (like History-Info) will likely
not require a "div" PASSporT. not require a "div" PASSporT.
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 verifier behavior. The behavior "ppt" values describe any additional verifier behavior. The behavior
specified for the "div" value of "ppt" is as follows. specified for the "div" value of "ppt" is as follows.
In order to use the "div" extension, a verification 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 any nested PASSporT objects within PASSporTs it validates, as
a request, as an Identity header field value containing "div" an Identity header field value containing "div" necessarily refers to
necessary refers to an earlier PASSporT already in the message. In an earlier PASSporT nested. If a nested PASSporT within a "div"
particular, the verification service must find a PASSporT associated PASSporT contains a "dest" claim with a value not equivalent to the
with the call, one created earlier, that contains a "dest" claim with "div" claim in the "div" PASSporT, that "div" PASSporT SHOULD NOT be
a value equivalent to the "div" claim in the current PASSporT. It is considered valid. It is possible that this nested PASSporT will also
possible that this earlier PASSporT will also contain a "div", and contain a "div", and that it will in turn chain to a still earlier
that it will in turn chain to a still earlier PASSporT stored in a PASSporT nested within it. Ultimately, by looking at this chain of
different Identity header field value. Ultimately, by looking at transformations and validating the associated signatures, the
this chain of transformations and validating the associated verification service will be able to ascertain that the appropriate
signatures, the verification service will be able to ascertain that parties were responsible for the retargeting of the call to its
the appropriate parties were responsible for the retargeting of the ultimate destination; this can help the verification service to
call to its ultimate destination; this can help the verification determine that the original PASSporT in the call was not simply used
service to determine that original PASSporT in the call was not in a cut-and-paste attack. This will help relying parties to make
simply used in a cut-and-paste attack. This will help relying any associated authorization decisions in terms of how the call will
parties to make any associated authorization decisions in terms of be treated - though, per [RFC8224] Section 6.2.1, that decision is a
how the call will be treated - though, per [RFC8224] Section 6.2.1, matter of local policy.
that decision is a matter of local policy.
Note that Identity header fields are not ordered in a SIP request,
and in a case where there is a multiplicity of Identity header fields
in a request, some sorting may be required to match divert PASSporTs
to their originals.
5. Definition of 'opt' 5. Definition of 'opt'
The presence of an "opt" signifies that a PASSporT encapsulates The presence of an original PASSporT claims object element,
another entire PASSporT within it, typically a PASSporT that was designated as "opt", signifies that a PASSporT encapsulates another
transformed in some way to create the current PASSporT. Relying entire PASSporT within it, typically a PASSporT that was transformed
parties may need to consult the encapsulated PASSporT in order to in some way to create the current PASSporT. Relying parties may need
validate the identity of a caller. "opt" as defined in this to consult the encapsulated PASSporT in order to validate the
specification may be used by future PASSporT extensions as well as by identity of a caller. "opt" as defined in this specification may be
used by future PASSporT extensions as well as in conjunction with
"div". "div".
"opt" MUST contain a quoted base64 encoded full-form PASSporT; it "opt" MUST contain a quoted base64 encoded full-form PASSporT; it
MUST NOT contain a compact form PASSporT. A "div" PASSporT MUST NOT contain a compact form PASSporT. For an example of a "div"
containing the "opt" would look as follows: PASSporT containing "opt," see Section 3.
{ "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551214"},
"iat":1443208345,
"div":{"tn":"121555551213",
"opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w"} }
6. 'div' and Redirection 6. '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 its "dest" value designates a different eventual recipient, because its "dest" value designates a different
original destination. original destination.
Any intermediary that assigns a new target to a request can, instead Any intermediary that assigns a new target to a request can, instead
of retargeting and forwarding the request, instead redirect with a of retargeting and forwarding the request, instead redirect with a
3xx response code. In ordinary operations, a redirection poses no 3xx response code. In ordinary operations, a redirection poses no
difficult for the operations of baseline STIR: when the UAC receives difficulties for the operations of baseline STIR: when the UAC
the 3xx response, it will initiate a new request to the new target receives the 3xx response, it will initiate a new request to the new
(typically the target carried in the Contact header field value of target (typically the target carried in the Contact header field
the 3xx), and the "dest" of the PASSporT created for the new request value of the 3xx), and the "dest" of the PASSporT created for the new
will match that new target. As no impersonation attack can arise request will match that new target. As no impersonation attack can
from this case, it creates no new requirement for STIR. arise from this case, it creates no new requirements for STIR.
However, some UACs record the original target of a call with However, some UACs record the original target of a call with
mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and
may want to leverage STIR to demonstrate to the ultimate recipient may want to leverage STIR to demonstrate to the ultimate recipient
that the call has been redirected securely: that is, that the that the call has been redirected securely: that is, that the
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 to attest that are the same as those for the the PASSporT necessary for that assertion are the same as those for
"div" retargeting cases above. The only wrinkle is that the PASSporT the "div" retargeting cases above. The only wrinkle is that the
needs to be generated by the redirecting entity and sent back to the PASSporT needs to be generated by the redirecting entity and sent
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" array value per Contact, but if
the retargeting entity wants to keep the Contact list private from the retargeting entity wants to keep the Contact list private from
targets, it may need to generate one PASSporT per Contact. Bear in targets, it may need to generate one PASSporT per Contact. Bear in
mind as well that the original SIP request could have carried 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
skipping to change at page 9, line 24 skipping to change at page 9, line 22
Section 1). Therefore an "hi" element may appear in "div" Section 1). Therefore an "hi" element may appear in "div"
corresponding to the History-Info header field index parameter value. 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 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 claims object of the corresponding PASSporT with "div" might look
like: like:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551214"}, "dest":{"tn":"12155551214"},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213", "div":{"tn":"121555551213",
"hi":"1.2.1"} } "hi":"1.2.1"}
"opt":[...]" }
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".
8. Acknowledgments 8. Acknowledgments
We would like to thank Robert Sparks for contributions to this We would like to thank Eric Burger, Dave Hancock, Chris Wendt and
document. Robert Sparks for contributions to this document.
9. IANA Considerations 9. IANA Considerations
This specification requests that the IANA add a new claim to the JSON This specification requests that the IANA add two new claims to the
Web Token Claims registry as defined in [RFC7519]. JSON Web Token Claims registry as defined in [RFC7519].
9.1. 'div' registration
Claim Name: "div" Claim Name: "div"
Claim Description: New Target of a Call Claim Description: New Target of a Call
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
9.2. 'opt' registration
Claim Name: "opt"
Claim Description: Encapsulated JSON token
Change Controller: IESG
Specification Document(s): [RFCThis]
10. Security Considerations 10. 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 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.
11. Informative References Any extension that makes PASSporTs larger creates a potential
amplification mechanism for SIP-based DDoS attacks. Since diversion
PASSporTs are created as a part of normal forwarding activity, this
risk arises at the discretion of the retargeting domain: simply using
3xx response redirections rather than retargeting (with supply a
"div" per Section 6) mitigates the potential impact. Under unusual
traffic loads, even domains that might ordinarily retarget requests
can switch to redirection.
[I-D.ietf-stir-oob] 11. References
Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-02 (work 11.1. Normative References
in progress), March 2018.
[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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in
SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010,
<https://www.rfc-editor.org/info/rfc5806>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
C. Holmberg, "An Extension to the Session Initiation C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 7044, Protocol (SIP) for Request History Information", RFC 7044,
DOI 10.17487/RFC7044, February 2014, DOI 10.17487/RFC7044, February 2014,
<https://www.rfc-editor.org/info/rfc7044>. <https://www.rfc-editor.org/info/rfc7044>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[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, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
Author's Address 11.2. Informative References
[I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-03 (work
in progress), July 2018.
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in
SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010,
<https://www.rfc-editor.org/info/rfc5806>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
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@team.neustar Email: jon.peterson@team.neustar
 End of changes. 31 change blocks. 
149 lines changed or deleted 169 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/