draft-ietf-stir-passport-divert-00.txt   draft-ietf-stir-passport-divert-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational July 3, 2017 Intended status: Informational October 30, 2017
Expires: January 4, 2018 Expires: May 3, 2018
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-00.txt draft-ietf-stir-passport-divert-01.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.
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 http://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 4, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5
4.1. Authentication Service Behavior . . . . . . . . . . . . . 5 4.1. Authentication Service Behavior . . . . . . . . . . . . . 5
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6
5. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 6 5. Using 'div' in STIR out-of-band . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
PASSporT [I-D.ietf-stir-passport] is a token format based on JWT PASSporT [I-D.ietf-stir-passport] is a token format based on JWT
[RFC7519] for conveying cryptographically-signed information about [RFC7519] for conveying cryptographically-signed information about
the people involved in personal communications; it is used with STIR the people involved in personal communications; it is used with STIR
[I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the
identity of the participants in real-time communications established identity of the participants in real-time communications established
via a protocol like SIP. This specification extends PASSporT to via a protocol like SIP. This specification extends PASSporT to
include an indication that a call has been diverted from its include an indication that a call has been diverted from its
skipping to change at page 5, line 35 skipping to change at page 5, line 35
replace any existing Identity header fields, it simply adds a new replace any existing Identity header fields, it simply adds a new
one. When adding an Identity header field with a PASSporT object one. When adding an Identity header field with a PASSporT object
containing a "div" claim, SIP authentication services MUST also add a containing a "div" claim, SIP authentication services MUST also add a
"ppt" parameter to that Identity header with a value of "div". The "ppt" parameter to that Identity header with a value of "div". The
resulting compact form Identity header field to add to the message resulting compact form Identity header field to add to the message
might look as follows: might look as follows:
Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \
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 regargeting will likely
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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 [I-D.ietf-stir-rfc4474bis]
Section 6.2.1, that decision is a matter of local policy. Section 6.2.1, 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. Extending 'div' 5. Using 'div' in STIR out-of-band
When storing a PASSporT with "div" at a Call Placement Service (CPS)
for STIR out-of-band [I-D.ietf-stir-rfc4474bis] scenarios, clients
should 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 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".
6. Acknowledgments 7. 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.
7. IANA Considerations 8. 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]
8. Security Considerations 9. 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.
9. Informative References 10. Informative References
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017. certificates-14 (work in progress), May 2017.
[I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out of Band
Architecture and Use Cases", draft-ietf-stir-oob-00 (work
in progress), July 2017.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017. progress), February 2017.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017. (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,
<http://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,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[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,
<http://www.rfc-editor.org/info/rfc5806>. <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,
<http://www.rfc-editor.org/info/rfc7044>. <https://www.rfc-editor.org/info/rfc7044>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
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. 19 change blocks. 
24 lines changed or deleted 58 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/