draft-ietf-stir-passport-divert-07.txt   draft-ietf-stir-passport-divert-08.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: RFC8224 (if approved) November 4, 2019 Updates: RFC8224 (if approved) March 9, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: May 7, 2020 Expires: September 10, 2020
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-07 draft-ietf-stir-passport-divert-08
Abstract Abstract
PASSporT is specified in RFC 8225 to convey cryptographically-signed PASSporT is specified in RFC 8225 to convey cryptographically-signed
information about the people involved in personal communications. information about the people involved in personal communications.
This document extends PASSporT to include an indication that a call This document extends PASSporT to include an indication that a call
has been diverted from its original destination to a new one. This has been diverted from its original destination to a new one. This
information can greatly improve the decisions made by verification information can greatly improve the decisions made by verification
services in call forwarding scenarios. Also specified here is an services in call forwarding scenarios. Also specified here is an
encapsulation mechanism for nesting a PASSporT within another encapsulation mechanism for nesting a PASSporT within another
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 4, line 22 skipping to change at page 4, line 22
3. The 'div' PASSporT Type and Claim 3. The 'div' PASSporT Type and Claim
This specification defines a PASSporT [RFC8225] type called "div" This specification defines a PASSporT [RFC8225] type called "div"
that may be employed by authentication services located at that may be employed by authentication services located at
retargeting entities. All "div" PASSporTs MUST contain a new JSON retargeting entities. All "div" PASSporTs MUST contain a new JSON
Web Token "div" claim, also specified in this document, which Web Token "div" claim, also specified in this document, which
indicates a previous destination for a call during its routing indicates a previous destination for a call during its routing
process. When a retargeting entity receives a call signed with a process. When a retargeting entity receives a call signed with a
PASSporT, it may act as an authentication service and create a new PASSporT, it may act as an authentication service and create a new
PASSporT containing the "div" claim to attach to the call. Note that PASSporT containing the "div" claim to attach to the call.
a new PASSporT is only necessary when the canonical form of the
"dest" identifier (per the canonicalization procedures in [RFC8224] Note that a new PASSporT is only necessary when the canonical form of
Section 8) changes due to this retargeting. If the canonical form of the "dest" identifier (per the canonicalization procedures in
the "dest" identifiier is not changed during retargeting, then a new [RFC8224] Section 8) changes due to this retargeting. If the
PASSporT with a "div" claim MUST NOT be produced. The headers of the canonical form of the "dest" identifiier is not changed during
new PASSporTs generated by retargeting entities MUST include the retargeting, then a new PASSporT with a "div" claim MUST NOT be
"div" PASSporT type, and an "x5u" field pointing to a credential that produced.
the retargeting entity controls. "div" PASSporTs MUST use full form
instead of compact form. The new PASSporT header will look as The headers of the new PASSporTs generated by retargeting entities
follows: MUST include the "div" PASSporT type, and an "x5u" field pointing to
a credential that the retargeting entity controls. "div" PASSporTs
MUST use full form instead of compact form. 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.cer" } "x5u":"https://www.example.com/cert.cer" }
A "div" PASSporT claims set is populated with elements drawn from the A "div" PASSporT claims set is populated with elements drawn from the
PASSporT(s) received for a call by the retargeting entity: at a high PASSporT(s) received for a call by the retargeting entity: at a high
level, the original identifier for the called party in the "dest" level, the original identifier for the called party in the "dest"
object will become the "div" claim in the new PASSporT. If the object will become the "div" claim in the new PASSporT. If the
skipping to change at page 5, line 43 skipping to change at page 5, line 45
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \
jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \
J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \
SqIlk3yCNkg SqIlk3yCNkg
The same "div" PASSporT would result if the "dest" object of the The same "div" PASSporT would result if the "dest" object of the
original PASSporT contained an array value, such as original PASSporT contained an array value, such as
{"tn":["12155551213"],["19995551234"]}, and the retargeting entity {"tn":["12155551213","19995551234"]}, and the retargeting entity
chose to retarget from the first telephone number in the array. chose to retarget from the first telephone number in the array.
Every "div" PASSporT is diverting from only one identifier. Every "div" PASSporT is diverting from only one identifier.
Note that the "div" element may contain other name/value pairs than Note that the "div" element may contain other name/value pairs than
just a destination, including a History-Info indicator (see just a destination, including a History-Info indicator (see
Section 8). After the PASSporT header and claims have been Section 8). After the PASSporT header and claims have been
constructed, their signature is generated per the guidance in constructed, their signature is generated per the guidance in
[RFC8225] - except for the credential required to sign it. While in [RFC8225] - except for the credential required to sign it. While in
the ordinary construction of a PASSporT, the credential used to sign the ordinary construction of a PASSporT, the credential used to sign
will have authority over the identity in the "orig" claim (for will have authority over the identity in the "orig" claim (for
skipping to change at page 6, line 26 skipping to change at page 6, line 29
in a request, some sorting may be required to match "div" PASSporTs in a request, some sorting may be required to match "div" PASSporTs
to their originals. to their originals.
PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6) PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6)
element in their payload. element in their payload.
4. Using 'div' in SIP 4. Using 'div' in SIP
This section specifies SIP-specific usage for the "div" PASSporT type This section specifies SIP-specific usage for the "div" PASSporT type
and its handling in the SIP Identity header field "ppt" parameter and its handling in the SIP Identity header field "ppt" parameter
value. Other using protocols of PASSporT may define behavior value. Other protocols using PASSporT may define behavior specific
specific to their use of the "div" claim. to their use of the "div" claim.
4.1. Authentication Service Behavior 4.1. Authentication Service Behavior
An authentication service only adds an Identity header field value An authentication service only adds an Identity header field value
containing the "div" PASSporT type to a SIP request that already containing the "div" PASSporT type to a SIP request that already
contains at least one Identity header field value; it MUST NOT add a contains at least one Identity header field value; it MUST NOT add a
"div" PASSporT to an INVITE that contains no Identity header field. "div" PASSporT to an INVITE that contains no Identity header field.
The retargeting entity SHOULD act as a verification service and The retargeting entity SHOULD act as a verification service and
validate the existing Identity header field value(s) in the request validate the existing Identity header field value(s) in the request
before proceeding; in some high-volume environments, it may instead before proceeding; in some high-volume environments, it may instead
skipping to change at page 8, line 31 skipping to change at page 8, line 33
verification service. At a high level, the immediate responsibility verification service. At a high level, the immediate responsibility
of the verification service is to extract all PASSporTs from the two of the verification service is to extract all PASSporTs from the two
or more Identity header fields in a request, identify which are "div" or more Identity header fields in a request, identify which are "div"
PASSporTs and which are not, and then order and link the "div" PASSporTs and which are not, and then order and link the "div"
PASSporTs to the original PASSporT(s) in order to build one or more PASSporTs to the original PASSporT(s) in order to build one or more
chains of retargeting. chains of retargeting.
In order to validate a SIP request using the "div" PASSporT type, a In order to validate a SIP request using the "div" PASSporT type, a
verification service needs to inspect all of the valid Identity verification service needs to inspect all of the valid Identity
header field values associated with a request, as an Identity header header field values associated with a request, as an Identity header
field value containing "div" necessary refers to an earlier PASSporT field value containing "div" necessarily refers to an earlier
already in the message. For each "div" PASSporT, the verification PASSporT already in the message. For each "div" PASSporT, the
service MUST find an earlier PASSporT that contains a "dest" claim verification service MUST find an earlier PASSporT that contains a
with a value equivalent to the "div" claim in each "div" PASSporT. "dest" claim with a value equivalent to the "div" claim in each "div"
It is possible that this earlier PASSporT will also contain a "div", PASSporT. It is possible that this earlier PASSporT will also
and that it will in turn chain to a still earlier PASSporT stored in contain a "div", and that it will in turn chain to a still earlier
a different Identity header field value. If a complete chain cannot PASSporT stored in a different Identity header field value. If a
be constructed, the verification service cannot complete "div" complete chain cannot be constructed, the verification service cannot
validation; it MAY still validate any non-"div" PASSporTs in the complete "div" validation; it MAY still validate any non-"div"
request per normal [RFC8224] procedures. If a chain has been PASSporTs in the request per normal [RFC8224] procedures. If a chain
successfully constructed, the verification service extracts from the has been successfully constructed, the verification service extracts
outermost (that is, the most recent) PASSporT in the chain a "dest" from the outermost (that is, the most recent) PASSporT in the chain a
field; this will be a "div" PASSporT that no other "div" PASSporT in "dest" field; this will be a "div" PASSporT that no other "div"
the SIP request refers to. Its "dest" element value will be referred PASSporT in the SIP request refers to. Its "dest" element value will
to in the procedures that follow as the value of the "outermost be referred to in the procedures that follow as the value of the
"dest" field." "outermost "dest" field."
Ultimately, by looking at this chain of transformations and Ultimately, by looking at this chain of transformations and
validating the associated signatures, the verification service will validating the associated signatures, the verification service will
be able to ascertain that the appropriate parties were responsible be able to ascertain that the appropriate parties were responsible
for the retargeting of the call to its current destination. This can for the retargeting of the call to its current destination. This can
help the verification service to determine that the original PASSporT help the verification service to determine that the original PASSporT
in the call was not simply used in a cut-and-paste attack and inform in the call was not simply used in a cut-and-paste attack and inform
any associated authorization decisions in terms of how the call will any associated authorization decisions in terms of how the call will
be treated - though, per [RFC8224] Section 6.2.1, that decision is a be treated - though, per [RFC8224] Section 6.2.1, that decision is a
matter of local policy and is thus outside the scope of this matter of local policy and is thus outside the scope of this
skipping to change at page 16, line 36 skipping to change at page 16, line 36
Any extension that makes PASSporTs larger creates a potential Any extension that makes PASSporTs larger creates a potential
amplification mechanism for SIP-based DDoS attacks. Since diversion amplification mechanism for SIP-based DDoS attacks. Since diversion
PASSporTs are created as a part of normal forwarding activity, this PASSporTs are created as a part of normal forwarding activity, this
risk arises at the discretion of the retargeting domain: simply using risk arises at the discretion of the retargeting domain: simply using
3xx response redirections rather than retargeting (with supply a 3xx response redirections rather than retargeting (with supply a
"div" per Section 7) mitigates the potential impact. Under unusual "div" per Section 7) mitigates the potential impact. Under unusual
traffic loads, even domains that might ordinarily retarget requests traffic loads, even domains that might ordinarily retarget requests
can switch to redirection. can switch to redirection.
SIP has an inherent capability to redirect requests, including
forking them to multiple parties -- potentially a very large numbers
of parties. The use of the "div" PASSporT type does not grant any
additional powers to attackers who hope to place bulk calls; if
present, the "div" PASSporT instead identifies the party responsible
for the forwarding. As such, senders of bulk unsolicited traffic are
unlikely to find the use of "div" attractive.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 17, line 38 skipping to change at page 17, line 44
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-05 (work Architecture and Use Cases", draft-ietf-stir-oob-06 (work
in progress), July 2019. in progress), November 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. 11 change blocks. 
37 lines changed or deleted 48 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/