draft-ietf-stir-passport-divert-02.txt   draft-ietf-stir-passport-divert-03.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational March 5, 2018 Intended status: Informational July 2, 2018
Expires: September 6, 2018 Expires: January 3, 2019
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-02.txt draft-ietf-stir-passport-divert-03.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. Also specified here is an
encapsulation mechanism for nesting a PASSporT within another
PASSporT that assists relying parties in some diversion scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on January 3, 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
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 3.1. Nesting the original PASSporT in 'div' . . . . . . . . . 5
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 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. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7 5. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 7
6. Extending 'div' to work with Service Logic Tracking . . . . . 8 6. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Extending 'div' to work with Service Logic Tracking . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . 10
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 26 skipping to change at page 3, line 30
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 original called number in PASSporT no longer reflects
the destination to which a call is likely to be delivered. 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. than a cut-and-paste attack. In support of this goal, this
specification also defines a nesting mechanism for PASSporTs that
allows the original unmodified PASSporT to be conveyed to relying
parties.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"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
skipping to change at page 5, line 19 skipping to change at page 5, line 23
"orig" per [RFC8226]), for all PASSporTs using the "div" type the "orig" per [RFC8226]), for all PASSporTs using the "div" type the
signature MUST be created with a credential with authority over the signature MUST be created with a credential with authority over the
identity present in the "div" claim. So for the example above, where identity present in the "div" claim. So for the example above, where
the original "dest" is "12155551213", the signer of the new PASSporT the original "dest" is "12155551213", the signer of the new PASSporT
object MUST have authority over that telephone number, and need not object MUST have authority over that telephone number, and need not
have any authority over the telephone number present in the "orig" have any authority over the telephone number present in the "orig"
claim. claim.
3.1. Nesting the original PASSporT in 'div' 3.1. Nesting the original PASSporT in 'div'
For some use cases, rather than having multiple unconnected PASSporTS In some use cases, instead of having multiple unconnected PASSporTS
associated with a single call, it makes more sense to nest the associated with a single call, it makes more sense to nest the
PASSporTs, explicitly relating two PASSporTs to one another. For PASSporTs, explicitly relating two PASSporTs to one another. For
example, when storing a PASSporT with "div" at a Call Placement example, when storing a PASSporT with "div" at a Call Placement
Service (CPS) for STIR out-of-band [I-D.ietf-stir-oob] scenarios, Service (CPS) for STIR out-of-band [I-D.ietf-stir-oob] scenarios,
clients MUST include an "opt" element within "div". "opt" contains clients MUST include an "opt" element within "div". "opt" (see
the full form of the original PASSporT from which the "div" was Section 5) contains the full form of the original PASSporT from which
generated. If the diverting entity originally received that PASSporT the "div" was generated. If the diverting entity originally received
encrypted, it MUST decrypt it before storing it in "opt." The entire that PASSporT encrypted, it MUST decrypt it before storing it in
"div" PASSporT would than be signed and re-encrypted normally for "opt." The entire "div" PASSporT would than be signed and re-
storage at an out-of-band Call Placement Service (CPS). 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 The "opt" extension is RECOMMENDED for use within in-band SIP use
cases as well. The alternative, having multiple Identity headers in cases as well. The alternative, having multiple Identity headers in
a SIP request, could be confusing for some verification services. a SIP request, could be confusing for some verification services.
However, nested PASSporTs could result in lengthy Identity headers, However, nested PASSporTs could result in lengthy Identity headers,
and some operational experience is needed to ascertain how viable and some operational experience is needed to ascertain how viable
multiple layers of nesting will be. multiple layers of nesting will be.
4. Using 'div' in SIP 4. Using 'div' in SIP
skipping to change at page 7, line 24 skipping to change at page 7, line 17
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 [RFC8224] Section 6.2.1, how the call will be treated - though, per [RFC8224] 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. 'div' and Redirection 5. Definition of 'opt'
The presence of an "opt" signifies that a PASSporT encapsulates
another entire PASSporT within it, typically a PASSporT that was
transformed in some way to create the current PASSporT. Relying
parties may need to consult the encapsulated PASSporT in order to
validate the identity of a caller. "opt" as defined in this
specification may be used by future PASSporT extensions as well as by
"div".
"opt" MUST contain a quoted base64 encoded full-form PASSporT; it
MUST NOT contain a compact form PASSporT. 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"} }
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. Any intermediary that assigns a new target to original destination.
a request could choose to redirect with a 3xx response code instead
of retargeting. In ordinary operations, a redirection poses no Any intermediary that assigns a new target to a request can, instead
of retargeting and forwarding the request, instead redirect with a
3xx response code. In ordinary operations, a redirection poses no
difficult for the operations of baseline STIR: when the UAC receives difficult for the operations of baseline STIR: when the UAC receives
the 3xx response, it will initiate a new request to the new target 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 (typically the target carried in the Contact header field value of
the "dest" of the PASSporT created for the new request will match the 3xx), and the "dest" of the PASSporT created for the new request
that new target. As no impersonation attack can arise from this will match that new target. As no impersonation attack can arise
case, it creates no new requirement for STIR. from this case, it creates no new requirement 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 to attest that are the same as those for the
"div" retargeting cases above. The only wrinkle is that the PASSporT "div" retargeting cases above. The only wrinkle is that the PASSporT
needs to be generated by the redirecting entity and sent back to the needs to be generated by the redirecting entity and sent back to the
originating user agent client within the 3xx response. 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; and thus the redirecting UAS through the Contact header field value; to accommodate this, the
needs to include one nested PASSporT per new target. Bear in mind as "div" PASSporT MAY include one "dest" array value per Contact, but if
well that the original SIP request could have carried multiple the retargeting entity wants to keep the Contact list private from
Identity header field values that had been added by different targets, it may need to generate one PASSporT per Contact. Bear in
authentication services in the request path. So a redirecting entity mind as well that the original SIP request could have carried
might need to generate one nested "div" PASSporT per each PASSporT in multiple Identity header field values that had been added by
the original request per each Contact URI in the 3xx. Often that may different authentication services in the request path, so a
mean just one "div" PASSporT, but for some deployment scenarios, it redirecting entity might need to generate one nested "div" PASSporT
could require an impractical number of combinations. per each PASSporT in the original request. Often this will mean just
one "div" PASSporT, but for some deployment scenarios, it could
require an impractical number of combinations. But in very complex
call routing scenarios, attestation of source identity would only add
limited value anyway.
STIR-aware intermediaries that redirect requests MAY therefore convey STIR-aware intermediaries that redirect requests MAY therefore convey
one or more PASSporTs in the backwards direction within Identity one or more PASSporTs in the backwards direction within Identity
headers. This document consequently updates [RFC8224] to permit headers. This document consequently updates [RFC8224] to permit
carrying Identity headers in SIP 300-class responses. It is left to carrying Identity headers in SIP 300-class responses. It is left to
authentication services to determine which Identity headers should be authentication services to determine which Identity headers should be
copied into any new requests resulting from the redirection, if any: copied into any new requests resulting from the redirection, if any:
use of these Identity headers by entities receiving a 3xx response is use of these Identity headers by entities receiving a 3xx response is
OPTIONAL. OPTIONAL.
Finally, note that if an intermediary in the response path consumes Finally, note that if an intermediary in the response path consumes
the 3xx and explores new targets itself while performing sequential the 3xx and explores new targets itself while performing sequential
forking, it will effectively retarget the call on behalf of the forking, it will effectively retarget the call on behalf of the
redirecting server, and this will create the same need for "div" redirecting server, and this will create the same need for "div"
PASSporTs as any other retargeted call. PASSporTs as any other retargeted call.
6. Extending 'div' to work with Service Logic Tracking 7. Extending 'div' to work with Service Logic Tracking
It is anticipated that "div" may be used in concert with History-Info 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" [RFC7044] in some deployments. It may not be clear from the "orig"
and "dest" values which History-Info header a given PASSporT and "dest" values which History-Info header a given PASSporT
correlates to, especially because some of the target changes tracked correlates to, especially because some of the target changes tracked
by History-Info will not be reflected in a "div" PASSporT (see by History-Info will not be reflected in a "div" PASSporT (see
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
skipping to change at page 9, line 9 skipping to change at page 9, line 33
"div":{"tn":"121555551213", "div":{"tn":"121555551213",
"hi":"1.2.1"} } "hi":"1.2.1"} }
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 8. Acknowledgments
We would like to thank Robert Sparks for contributions to this We would like to thank Robert Sparks for contributions to this
document. document.
8. 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 a new claim to the JSON
Web Token Claims registry as defined in [RFC7519]. Web Token Claims registry as defined in [RFC7519].
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. 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.
10. Informative References 11. 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-01 (work Architecture and Use Cases", draft-ietf-stir-oob-02 (work
in progress), October 2017. 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,
skipping to change at page 11, line 13 skipping to change at page 11, line 32
<https://www.rfc-editor.org/info/rfc8226>. <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@team.neustar
 End of changes. 20 change blocks. 
57 lines changed or deleted 82 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/