< draft-ietf-stir-passport-divert-05.txt   draft-ietf-stir-passport-divert-06.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: RFC8224 (if approved) February 19, 2019 Updates: RFC8224 (if approved) July 8, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: August 23, 2019 Expires: January 9, 2020
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-05.txt draft-ietf-stir-passport-divert-06
Abstract Abstract
This document extends PASSporT, which conveys cryptographically- This document extends PASSporT, which is specified in RFC 8225 to
signed information about the people involved in personal convey cryptographically-signed information about the people involved
communications, to include an indication that a call has been in personal communications, to include an indication that a call has
diverted from its original destination to a new one. This 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
PASSporT that assists relying parties in some diversion scenarios. 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 August 23, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4 3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 7 4.2. Verification Service Behavior . . . . . . . . . . . . . . 7
5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 9 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10
6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 11 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 11
7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 11 7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 12
8. Extending 'div' to work with Service Logic Tracking . . . . . 13 8. Extending 'div' to work with Service Logic Tracking . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. 'div' registration . . . . . . . . . . . . . . . . . . . 13 10.1. JSON Web Token Claims Registrations . . . . . . . . . . 14
10.2. 'opt' registration . . . . . . . . . . . . . . . . . . . 14 10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 14
10.3. PASSporT Type Registrations . . . . . . . . . . . . . . 14 10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for A Personal Assertion Token (PASSporT [RFC8225]) is a token format
conveying cryptographically-signed information about the people based on the JSON Web Token (JWT [RFC7519]) for conveying
involved in personal communications; it is used by STIR [RFC8224] to cryptographically-signed information about the people involved in
convey a signed assertion of the identity of the participants in personal communications; it is used by the Secure Telephone Identity
real-time communications established via a protocol like SIP. This Revisited (STIR [RFC8224]) protocol to convey a signed assertion of
specification extends PASSporT to include an indication that a call the identity of the participants in real-time communications
has been diverted from its original destination to a new one. established via a protocol like SIP. This specification extends
PASSporT to include an indication that a call has been diverted from
its original destination to a new one.
Although the STIR problem statement [RFC7340] is focused on Although the STIR problem statement [RFC7340] is focused on
preventing the impersonation of the caller's identity, which is a preventing the impersonation of the caller's identity, which is a
common enabler for threats such as robocalling and voicemail hacking common enabler for threats such as robocalling and voicemail hacking
on the telephone network today, it also provides a signature over the on the telephone network today, it also provides a signature over the
called number as the authentication service sees it. As [RFC8224] called number at the time that the authentication service sees it.
Section 12.1 describes, this protection over the contents of the To
header field is intended to prevent a class of cut-and-paste attacks. As [RFC8224] Section 12.1 describes, this protection over the
If Alice calls Bob, for example, Bob might attempt to cut-and-paste contents of the To header field is intended to prevent a class of
the Identity header field in Alice's INVITE into a new INVITE that cut-and-paste attacks. If Alice calls Bob, for example, Bob might
Bob sends to Carol, and thus be able to fool Carol into thinking the attempt to cut-and-paste the Identity header field in Alice's INVITE
call came from Alice and not Bob. With the signature over the To into a new INVITE that Bob sends to Carol, and thus be able to fool
header field value, the INVITE Carol sees will clearly have been Carol into thinking the call came from Alice and not Bob. With the
destined originally for Bob, and thus Carol can view the INVITE as signature over the To header field value, the INVITE Carol sees will
suspect. clearly have been destined originally for Bob, and thus Carol can
view the INVITE as suspect.
However, as [RFC8224] Section 12.1.1 points out, it is difficult for However, as [RFC8224] Section 12.1.1 points out, it is difficult for
Carol to confirm or reject these suspicions based on the information Carol to confirm or reject these suspicions based on the information
she receives from the baseline PASSporT object. The common "call she receives from the baseline PASSporT object. The common "call
forwarding" service serves as a good example of the reality that the forwarding" service serves as a good example of the reality that the
original called party number is not always the number to which a call original called party number is not always the number to which a call
is delivered. There are a number of potential ways for is delivered. There are a number of potential ways for
intermediaries to indicate that such a forwarding operating has taken intermediaries to indicate that such a forwarding operating has taken
place. The address in the To header field value of SIP requests is place. The address in the To header field value of SIP requests is
not supposed to change, according to baseline [RFC3261], as it is the not supposed to change, according to baseline [RFC3261], as it is the
Request-URI that is supposed to be updated when a call is retargeted, Request-URI that is supposed to be updated when a call is retargeted,
but practically speaking some operational environments do alter the but practically speaking many operational environments do alter the
To header field. The History-Info header field [RFC7044] was created To header field. The History-Info header field [RFC7044] was created
to store the Request-URIs that are discarded by a call in transit. to store the Request-URIs that are discarded by a call in transit.
The SIP Diversion header field [RFC5806], though historic, is still The SIP Diversion header field [RFC5806], though historic, is still
used for this purpose by some operators today. Neither of these used for this purpose by some operators today. Neither of these
header fields provide any cryptographic assurance of secure header fields provide any cryptographic assurance of secure
redirection, and they both can capture minor syntactical changes in redirection, and they both record entries for minor syntactical
URIs that do not reflect a change to the actual target of a call. changes in 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 the original called number in PASSporT no longer indication that the original called number in PASSporT no longer
reflects the destination to which a call is intended to be delivered. reflects the destination to which a call is intended to be delivered.
For this purpose, it specifies a "div" PASSporT type for use in For this purpose, it specifies a "div" PASSporT type for use in
common SIP retargeting cases; it is expected that in this case, SIP common SIP retargeting cases; it is expected that in this case, SIP
INVITE requests will carry multiple Identity header fields, each INVITE requests will carry multiple Identity header fields, each
containing its own PASSporT. Verification services and the relying containing its own PASSporT. Throughout this document, PASSporTs
parties who make authorization decisions about communications may use that contain a "div" element will be referred to as "div" PASSporTs.
this diversion indication to confirm that a legitimate retargeting of Verification services and the relying parties who make authorization
the call has taken place, rather than a cut-and-paste attack. For decisions about communications may use this diversion indication to
out-of-band [I-D.ietf-stir-oob] use cases, and other non-SIP confirm that a legitimate retargeting of the call has taken place,
applications of PASSporT, a separate "div-o" PASSporT type is also rather than a cut-and-paste attack. For out-of-band
specified, which defines an "opt" PASSporT element for carrying [I-D.ietf-stir-oob] use cases, and other non-SIP applications of
nested PASSporTs within a PASSporT. PASSporT, a separate "div-o" PASSporT type is also specified, which
defines an "opt" PASSporT element for carrying nested PASSporTs
within a PASSporT. These shall in turn be referred to in this
document as "div-o" PASSporTs.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in BCP
described in [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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. Note that
a new PASSporT is only necessary when the canonical form of the a new PASSporT is only necessary when the canonical form of the
"dest" identifier (per the canonicalization procedures in [RFC8224] "dest" identifier (per the canonicalization procedures in [RFC8224]
Section 8) changes due to this retargeting. The headers of the new Section 8) changes due to this retargeting. If the canonical form of
PASSporTs generated by retargeting entities MUST include the "div" the "dest" identifiier is not changed during retargeting, then a new
PASSporT type, and an "x5u" field pointing to a credential that the PASSporT with a "div" claim MUST NOT be produced. The headers of the
retargeting entity controls. "div" PASSporTs MUST use full form new PASSporTs generated by retargeting entities 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 instead of compact form. The new PASSporT header will look as
follows: 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.cer" }
A "div" PASSporT claims object is populated with elements drawn from A "div" PASSporT claims set is populated with elements drawn from the
the PASSporT(s) received for a call by the retargeting entity: at a PASSporT(s) received for a call by the retargeting entity: at a high
high level, the original identifier for the called party in the level, the original identifier for the called party in the "dest"
"dest" array will become the "div" claim in the new PASSporT. If the array will become the "div" claim in the new PASSporT. If the "dest"
"dest" array of the original PASSporT contains multiple identifiers, array of the original PASSporT contains multiple identifiers, the
the retargeting entity MUST select only one them to occupy the "div" 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 claims or extensions are to be copied from the original No other claims or extensions are to be copied from the original
PASSporT to the "div" PASSporT. PASSporT to the "div" PASSporT.
So, for an original PASSporT claims object of the form: So, for an original PASSporT claims set 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 claims object of a "div" PASSpoRT generated by the 12155551214, the claims set of a "div" PASSpoRT generated by the
retargeting entity would look as follows: retargeting entity 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"]} }
The combined full form PASSporT (with a signature covered by the The combined full form PASSporT (with a signature covered by the
ES256 keys given in Appendix A) would look as follows: ES256 keys given in Appendix A) would look as follows:
skipping to change at page 5, line 49 skipping to change at page 6, line 11
"12155551213", the signer of the new PASSporT object MUST have "12155551213", the signer of the new PASSporT object MUST have
authority over that telephone number, and need not have any authority authority over that telephone number, and need not have any authority
over the telephone number present in the "orig" claim. over the telephone number present in the "orig" claim.
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 "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 claims; PASSporTs of type "div-o" (see Section 5) element in their payload.
MUST contain an "opt".
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
skipping to change at page 6, line 48 skipping to change at page 7, line 7
value of a "div" PASSporT from a new Request-URI that is set for the value of a "div" PASSporT from a new Request-URI that is set for the
SIP request before it is forwarded. Older values of the Request-URI SIP request before it is forwarded. Older values of the Request-URI
may appear in header fields like Diversion or History-Info; this may appear in header fields like Diversion or History-Info; this
document specifies an optional interaction with History-Info below in document specifies an optional interaction with History-Info below in
Section 8. Note as well that because PASSporT operates on Section 8. 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 that record retargeting (like History-Info) will likely mechanisms that record retargeting (like History-Info) will likely
not require a "div" PASSporT. not require a "div" PASSporT.
When adding an Identity header field with a PASSporT claims object When adding an Identity header field with a PASSporT claims set
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". For "ppt" parameter to that Identity header with a value of "div". For
the example PASSporT given in Section 3, the new Identity header the example PASSporT given in Section 3, the new Identity header
added after retargeting might look as follows: added after retargeting might look as follows:
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J \ Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J \
0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJk \ 0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJk \
ZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1 \ ZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1 \
NTEyMTMifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEy \ NTEyMTMifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEy \
MTIifX0.YZX3UGjaXsAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cH \ MTIifX0.YZX3UGjaXsAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cH \
maq0Mof2N-bfvRXPXuchtDJm8VbrbQ; \ maq0Mof2N-bfvRXPXuchtDJm8VbrbQ; \
info=<https://biloxi.example.org/biloxi.cer>;ppt="div" info=<https://biloxi.example.org/biloxi.cer>;ppt="div"
Note that in some deployments, an authentication service will need to Note that in some deployments, an authentication service will need to
generate "div" PASSporTs for a request that contains multiple generate "div" PASSporTs for a request that contains multiple
non-"div" Identity header field values. For example, a request non-"div" Identity header field values. For example, a request
arriving at a retargeting entity might contain in different Identity arriving at a retargeting entity might contain in different Identity
header fields a baseline [RFC8224] PASSporT and a PASSporT of type header fields a baseline [RFC8224] PASSporT and a PASSporT of type
"rph" [I-D.ietf-stir-rph] signed by a separate authority. Provided "rph" [RFC8443] signed by a separate authority. Provided that these
that these PASSporTs share the same "orig" and "dest" values, the PASSporTs share the same "orig" and "dest" values, the retargeting
retargeting entity's authentication service SHOULD generate only one entity's authentication service SHOULD generate only one "div"
"div" PASSporT. If the "orig" or "dest" of these PASSporTs differ, PASSporT. If the "orig" or "dest" of these PASSporTs differ,
however, one "div" PASSporT SHOULD be generated for each non-"div" however, one "div" PASSporT SHOULD be generated for each non-"div"
PASSporT. Furthermore note that a request may also be retargeted a PASSporT. Furthermore note that a request may also be retargeted a
second time, at which point the subsequent retargeting entity SHOULD second time, at which point the subsequent retargeting entity SHOULD
generate one "div" PASSporT for each previous "div" PASSporT in the generate one "div" PASSporT for each previous "div" PASSporT in the
request. This can create multiple chains of "div" PASSporTs in a request. This can create multiple chains of "div" PASSporTs in a
single request, which complicates the procedures that need to be single request, which complicates the procedures that need to be
performed at verification services. performed at verification services.
4.2. Verification Service Behavior 4.2. Verification Service Behavior
skipping to change at page 8, line 13 skipping to change at page 8, line 23
and that it will in turn chain to a still earlier PASSporT stored in and that it will in turn chain to a still earlier PASSporT stored in
a different Identity header field value. If a complete chain cannot a different Identity header field value. If a complete chain cannot
be constructed, the verification service cannot complete "div" be constructed, the verification service cannot complete "div"
validation; it MAY still validate any non-"div" PASSporTs in the validation; it MAY still validate any non-"div" PASSporTs in the
request per normal [RFC8224] procedures. If a chain has been request per normal [RFC8224] procedures. If a chain has been
successfully constructed, the verification service extracts from the successfully constructed, the verification service extracts from the
outermost (that is, the most recent) PASSporT in the chain a "dest" outermost (that is, the most recent) PASSporT in the chain a "dest"
field; this will be a "div" PASSporT that no other "div" PASSporT in field; this will be a "div" PASSporT that no other "div" PASSporT in
the SIP request refers to. Its "dest" element value will be referred the SIP request refers to. Its "dest" element value will be referred
to in the procedures that follow as the value of the "outermost to in the procedures that follow as the value of the "outermost
'dest' field." "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 9, line 5 skipping to change at page 9, line 14
identifier in the "div" element of the PASSporT (per [RFC8224] identifier in the "div" element of the PASSporT (per [RFC8224]
Section 6.2 Step 3). Section 6.2 Step 3).
Third, the verification service MUST validate that the "orig" Third, the verification service MUST validate that the "orig"
field of the innermost PASSporT of the chain (the only PASSporT in field of the innermost PASSporT of the chain (the only PASSporT in
the chain which will not be of PASSporT type "div") is equivalent the chain which will not be of PASSporT type "div") is equivalent
to the "orig" field of the outermost "div" PASSporT; in other to the "orig" field of the outermost "div" PASSporT; in other
words, that the original calling identifier has not been altered words, that the original calling identifier has not been altered
by retargeting authentication services. If the "orig" value has by retargeting authentication services. If the "orig" value has
changed, the verification service MUST treat the entire PASSporT changed, the verification service MUST treat the entire PASSporT
chain as invalid. The verification service SHOULD also verify chain as invalid. The verification service MUST also verify that
that all other "div" PASSporTs in the chain share the same "orig" all other "div" PASSporTs in the chain share the same "orig"
value. Then the verification service validates the relationship value. Then the verification service validates the relationship
of the "orig" field to the SIP-level call signaling per the of the "orig" field to the SIP-level call signaling per the
guidance in [RFC8224] Section 6.2 Step 2. guidance in [RFC8224] Section 6.2 Step 2.
Fourth, the verification service MUST check the date freshness in Fourth, the verification service MUST check the date freshness in
the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It
is furthermore RECOMMENDED that the verification service check is furthermore RECOMMENDED that the verification service check
that the "iat" field of the innermost PASSporT is also within the that the "iat" field of the innermost PASSporT is also within the
date freshness interval; otherwise the verification service could date freshness interval; otherwise the verification service could
allow attackers to replay an old, stale PASSporT embedded in a allow attackers to replay an old, stale PASSporT embedded in a
fresh "div". fresh "div".
Fifth, the verification service MUST inspect and validate the Fifth, the verification service MUST inspect and validate the
signatures on each and every PASSporT object in the chain between signatures on each and every PASSporT object in the chain between
the outermost "div" PASSporT and the innermost PASSporT. Note the outermost "div" PASSporT and the innermost PASSporT. Note
that (per Section 4.1) a chain may terminate at more than one that (per Section 4.1) a chain may terminate at more than one
innermost PASSporT, in cases where a single "div" is used to innermost PASSporT, in cases where a single "div" is used to
retarget from multiple based PASSporTs. retarget from multiple innermost PASSporTs. Also note that
[RFC8224] Section 6.2 Step 1 applies to the chain validation
process: if the innermost PASSporT contains an unsupported "ppt",
its chain MUST be ignored.
Note that the To header field is not used in the first step above. Note that the To header field is not used in the first step above.
Optionally, the verification service MAY verify that the To header Optionally, the verification service MAY verify that the To header
field value of the received SIP signaling is equal to the "dest" field value of the received SIP signaling is equal to the "dest"
value in the innermost PASSporT; however, as has been observed in value in the innermost PASSporT; however, as has been observed in
some deployments, the original To header field value may be altered some deployments, the original To header field value may be altered
by intermediaries to reflect changes of target. Deployments that by intermediaries to reflect changes of target. Deployments that
change the original To header field value to conceal the original change the original To header field value to conceal the original
destination of the call from the ultimate recipient should note that destination of the call from the ultimate recipient should note that
the original destination of a call may be preserved in the innermost the original destination of a call may be preserved in the innermost
skipping to change at page 10, line 11 skipping to change at page 10, line 26
environments where the conveyance of PASSporTs in separate Identity environments where the conveyance of PASSporTs in separate Identity
header fields in impossible, such as out-of-band [I-D.ietf-stir-oob] header fields in impossible, such as out-of-band [I-D.ietf-stir-oob]
STIR scenarios. STIR scenarios.
The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" The syntax of "div-o" PASSporTs is very similar to "div". A "div-o"
PASSporT header object might look as follows: PASSporT header object might look as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"div-o", "ppt":"div-o",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "x5u":"https://www.example.com/cert.cer" }
Whereas a "div" PASSporT claims object contains only the "orig", Whereas a "div" PASSporT claims set contains only the "orig", "dest",
"dest", "iat", and "div" elements, the "div-o" additionally MUST "iat", and "div" elements, the "div-o" additionally MUST contain an
contain an "opt" element (see Section 6), which encapsulates the full "opt" element (see Section 6), which encapsulates the full form of
form of the previous PASSporT from which the call was retargeted, the previous PASSporT from which the call was retargeted, triggering
triggering the generation of this "div-o". The value of the "opt" the generation of this "div-o". The value of the "opt" element is
element is identical to the base64 encoded PASSporT format given in identical to the base64 encoded PASSporT format given in Appendix A
Appendix A of [RFC8225]. of [RFC8225].
So, for an original PASSporT claims object of the form: So, for an original PASSporT claims set 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 claims object for "div-o" would look as 12155551214, the new PASSporT claims set for "div-o" would look as
follows: follows:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213"}, "div":{"tn":"121555551213"},
"opt":"4F7jsZv0mJ5bjg4Xik6Mfah3IO8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7 \ "opt":"4F7jsZv0mJ5bjg4Xik6Mfah3IO8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7 \
c0_0eQi4e9FVX-WmvX3uETtlVjAtgeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3N \ c0_0eQi4e9FVX-WmvX3uETtlVjAtgeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3N \
wb3J0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ. \ wb3J0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ. \
eyJkZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUs \ eyJkZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUs \
skipping to change at page 11, line 25 skipping to change at page 11, line 41
CYorw_3FaH78VuERURlJp1hD6qh2eIct4RIebVtYp3es9HTsvCz1qXRWq3j0E9Pb2h \ CYorw_3FaH78VuERURlJp1hD6qh2eIct4RIebVtYp3es9HTsvCz1qXRWq3j0E9Pb2h \
YrMUXSQbBYQSviW5cCA; \ YrMUXSQbBYQSviW5cCA; \
info=<https://biloxi.example.org/biloxi.cer>;ppt="div-o" info=<https://biloxi.example.org/biloxi.cer>;ppt="div-o"
The authentication and verification service procedures required for The authentication and verification service procedures required for
"div-o" will necessarily be specific to the protocol or environment "div-o" will necessarily be specific to the protocol or environment
where it is used, and thus are left to future work. where it is used, and thus are left to future work.
6. Definition of 'opt' 6. Definition of 'opt'
The presence of an original PASSporT claims object element, The presence of an original PASSporT claims set element, designated
designated as "opt", signifies that a PASSporT encapsulates another as "opt", signifies that a PASSporT encapsulates another entire
entire PASSporT within it, typically a PASSporT that was transformed PASSporT within it, typically a PASSporT that was transformed in some
in some way to create the current PASSporT. Relying parties may need way to create the current PASSporT. Relying parties may need to
to consult the encapsulated PASSporT in order to validate the consult the encapsulated PASSporT in order to validate the identity
identity of a caller. "opt" as defined in this specification may be of a caller. "opt" as defined in this specification may be used by
used by future PASSporT extensions as well as in conjunction with future PASSporT extensions as well as in conjunction with "div-o".
"div-o".
"opt" MUST contain a quoted base64 encoded full-form PASSporT as "opt" MUST contain a quoted base64 encoded full-form PASSporT as
specified by [RFC8225] Appendix A; it MUST NOT contain a compact form specified by [RFC8225] Appendix A; it MUST NOT contain a compact form
PASSporT. For an example of a "div-o" PASSporT containing "opt," see PASSporT. For an example of a "div-o" PASSporT containing "opt," see
Section 5. Section 5.
7. 'div' and Redirection 7. '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 the original PASSporT "dest" value eventual recipient, because the original PASSporT "dest" value
designates a different destination. designates a different 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
difficulties for the operations of baseline STIR: when the UAC difficulties for the operations of baseline STIR: when the user agent
receives the 3xx response, it will initiate a new request to the new client (UAC) receives the 3xx response, it will initiate a new
target (typically the target carried in the Contact header field request to the new target (typically the target carried in the
value of the 3xx), and the "dest" of the PASSporT created for the new Contact header field value of the 3xx), and the "dest" of the
request will match that new target. As no impersonation attack can PASSporT created for the new request will match that new target. As
arise from this case, it creates no new requirements for STIR. no impersonation attack can 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 for that assertion are the same as those for the PASSporT necessary for that assertion are the same as those for
the "div" retargeting cases above. The only wrinkle is that the the "div" retargeting cases above. The only wrinkle is that the
PASSporT needs to be generated by the redirecting entity and sent PASSporT needs to be generated by the redirecting entity and sent
skipping to change at page 13, line 14 skipping to change at page 13, line 28
also copy PASSporTs from the 3xx response and insert them into also copy PASSporTs from the 3xx response and insert them into
sequential forking requests, if appropriate. sequential forking requests, if appropriate.
8. Extending 'div' to work with Service Logic Tracking 8. 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 as defined here may appear in
corresponding to the History-Info header field index parameter value. "div" corresponding to the History-Info header field index parameter
So for a History-Info header field with an index value of "1.2.1", value. So for a History-Info header field with an index value of
the claims object of the corresponding PASSporT with "div" might look "1.2.1", the claims set of the corresponding PASSporT with "div"
like: might look like:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213", "div":{"tn":"121555551213",
"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".
9. Acknowledgments 9. Acknowledgments
We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Eric We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean
Burger, and Robert Sparks for contributions to this document. Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks
for contributions to this document.
10. IANA Considerations 10. IANA Considerations
This document contains actions for the IANA.
10.1. JSON Web Token Claims Registrations
This specification requests that the IANA add two new claims to the This specification requests that the IANA add two new claims to the
JSON Web Token Claims registry as defined in [RFC7519]. JSON Web Token Claims registry as defined in [RFC7519].
10.1. 'div' registration 10.1.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]
10.2. 'opt' registration 10.1.2. 'opt' registration
Claim Name: "opt" Claim Name: "opt"
Claim Description: Encapsulated JSON token Claim Description: Encapsulated JSON token
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
10.3. PASSporT Type Registrations 10.2. PASSporT Type Registrations
This specification defines two new PASSporT types for the PASSport This specification defines two new PASSporT types for the PASSport
Type Registry defined in [RFC8225]. They are: Extensions Registry defined in [RFC8225], which resides at
https://www.iana.org/assignments/passport/passport.xhtml#passport-
extensions. They are:
"div" as defined in Section 3. "div" as defined in [RFCThis] Section 3.
"div-o" as defined in Section 5. "div-o" as defined in [RFCThis] Section 5.
11. Security Considerations 11. Privacy Considerations
There is an inherent trade-off in any mechanism that tracks in SIP
signaling how calls are routed through a network, as routing
decisions may expose policies set by users for how calls are
forwarded, potentially revealing relationships between different
identifiers representing the same user. Note however that in
ordinary operations, this information is revealed to the user agent
service of the called party, not the calling party. It is usually
the called party who establishes these forwarding relationships, and
if indeed some other party is responsible for calls being forwarded
to the called party, many times the called party should likely be
entitled to information about why they receiving these calls.
However, as there may be unforeseen circumstances where the
revelation of service logic to the called party poses a privacy risk,
implementers and users of this or similar diversion-tracking
techniques should understand the trade-off.
Furthermore, it is a general privacy risk of identity mechanisms
overall that they do not interface well with anonymization services;
the interaction of STIR with anonymization services is detailed in
[RFC8224] Section 11. Any forwarding services that acts as an
anonymizing proxy may not be able to provide a secure chain of
retargeting due to the obfuscation of the originating identity.
12. 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
skipping to change at page 14, line 48 skipping to change at page 15, line 45
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.
12. References 13. References
12.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,
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 15, line 27 skipping to change at page 16, line 26
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
12.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-03 (work Architecture and Use Cases", draft-ietf-stir-oob-04 (work
in progress), July 2018. in progress), March 2019.
[I-D.ietf-stir-rph]
Singh, R., Dolly, M., Das, S., and A. Nguyen, "PASSporT
Extension for Resource Priority Authorization", draft-
ietf-stir-rph-06 (work in progress), May 2018.
[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>.
[RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal
Assertion Token (PASSporT) Extension for Resource Priority
Authorization", RFC 8443, DOI 10.17487/RFC8443, August
2018, <https://www.rfc-editor.org/info/rfc8443>.
Appendix A. Appendix A: Keys for Examples Appendix A. Appendix A: Keys for Examples
The following EC256 keys are used in the signing examples given in The following EC256 keys are used in the signing examples given in
this document. this document. WARNING: Do not use this key pair in production
systems.
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49 MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4 AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
 End of changes. 48 change blocks. 
126 lines changed or deleted 178 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/