draft-ietf-stir-passport-divert-04.txt   draft-ietf-stir-passport-divert-05.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Updates: RFC8224 (if approved) October 22, 2018 Updates: RFC8224 (if approved) February 19, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: April 25, 2019 Expires: August 23, 2019
PASSporT Extension for Diverted Calls PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-04.txt draft-ietf-stir-passport-divert-05.txt
Abstract Abstract
This document extends PASSporT, which conveys cryptographically- This document extends PASSporT, which conveys cryptographically-
signed information about the people involved in personal signed information about the people involved in personal
communications, to include an indication that a call has been communications, to include an indication that a call has been
diverted from its original destination to a new one. This diverted from its original destination to a new one. This
information can greatly improve the decisions made by verification information can greatly improve the decisions made by verification
services in call forwarding scenarios. Also specified here is an services in call forwarding scenarios. Also specified here is an
encapsulation mechanism for nesting a PASSporT within another encapsulation mechanism for nesting a PASSporT within another
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on August 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3 3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4
4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 7
5. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 7 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 9
6. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 11
7. Extending 'div' to work with Service Logic Tracking . . . . . 9 7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Extending 'div' to work with Service Logic Tracking . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. 'div' registration . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.2. 'opt' registration . . . . . . . . . . . . . . . . . . . 10 10.1. 'div' registration . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10.2. 'opt' registration . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.3. PASSporT Type Registrations . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 by STIR [RFC8224] to
to convey a signed assertion of the identity of the participants in 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
has been diverted from its originally destination to a new one. 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 as the authentication service sees it. As [RFC8224]
Section 12.1 describes, this protection over the contents of the To 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. header field is intended to prevent a class of cut-and-paste attacks.
If Alice calls Bob, for example, Bob might attempt to cut-and-paste If Alice calls Bob, for example, Bob might attempt to cut-and-paste
the Identity header field in Alice's INVITE into a new INVITE that the Identity header field in Alice's INVITE into a new INVITE that
Bob sends to Carol, and thus be able to fool Carol into thinking the Bob sends to Carol, and thus be able to fool Carol into thinking the
call came from Alice and not Bob. With the signature over the To call came from Alice and not Bob. With the signature over the To
header field value, the INVITE Carol sees will clearly have been header field value, the INVITE Carol sees will clearly have been
destined originally for Bob, and thus Carol can view the INVITE as destined originally for Bob, and thus Carol can view the INVITE as
suspect. 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 fact 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. The address in the To header field value of SIP is delivered. There are a number of potential ways for
requests is not supposed to change, accordingly to baseline intermediaries to indicate that such a forwarding operating has taken
[RFC3261], as it is the Request-URI that is supposed to be updated place. The address in the To header field value of SIP requests is
when a call is retargeted, but practically speaking some operational not supposed to change, according to baseline [RFC3261], as it is the
environments do alter the To header field. There are a number of Request-URI that is supposed to be updated when a call is retargeted,
potential ways for intermediaries to indicate that such a forwarding but practically speaking some operational environments do alter the
operating has taken place. The History-Info header field [RFC7044] To header field. The History-Info header field [RFC7044] was created
was created to store the Request-URIs that are discarded by a call in to store the Request-URIs that are discarded by a call in transit.
transit. The SIP Diversion header field [RFC5806], though historic, The SIP Diversion header field [RFC5806], though historic, is still
is still used for this purpose by some operators today. Neither of used for this purpose by some operators today. Neither of these
these header fields provide any cryptographic assurance of secure header fields provide any cryptographic assurance of secure
redirection, and they can both capture minor syntactical changes in redirection, and they both can 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 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 likely to be delivered. reflects the destination to which a call is intended to be delivered.
Verification services and the relying parties who make authorization For this purpose, it specifies a "div" PASSporT type for use in
decisions about communications may use this indication to confirm common SIP retargeting cases; it is expected that in this case, SIP
that a legitimate retargeting of the call has taken place, rather INVITE requests will carry multiple Identity header fields, each
than a cut-and-paste attack. In support of this goal, this containing its own PASSporT. Verification services and the relying
specification also defines a nesting mechanism for PASSporTs that parties who make authorization decisions about communications may use
allows the original unmodified PASSporT to be conveyed to relying this diversion indication to confirm that a legitimate retargeting of
parties. the call has taken place, rather than a cut-and-paste attack. For
out-of-band [I-D.ietf-stir-oob] use cases, and other non-SIP
applications of PASSporT, a separate "div-o" PASSporT type is also
specified, which defines an "opt" PASSporT element for carrying
nested PASSporTs within a PASSporT.
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. The 'div' PASSporT Type and Claim
This specification defines a new JSON Web Token claim for "div" which This specification defines a PASSporT [RFC8225] type called "div"
that may be employed by authentication services located at
retargeting entities. All "div" PASSporTs MUST contain a new JSON
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. "div" is populated with a Section 8) changes due to this retargeting. The headers of the new
destination address found in the "dest" field of PASSporT received by PASSporTs generated by retargeting entities MUST include the "div"
the retargeting entity as well as a copy of the original PASSporT. PASSporT type, and an "x5u" field pointing to a credential that the
These new PASSporTs generated by retargeting entities MUST include retargeting entity controls. "div" PASSporTs MUST use full form
the "div" PASSporT type, and an "x5u" field pointing to a credential instead of compact form. The new PASSporT header will look as
that the retargeting entity controls. The new PASSporT header will follows:
look as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"div", "ppt":"div",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "x5u":"https://www.example.com/cert.pkx" }
A PASSporT claims object containing "div" is populated with a A "div" PASSporT claims object is populated with elements drawn from
modification of the original token before the call was retargeted: at the PASSporT(s) received for a call by the retargeting entity: at a
a high level, the original identifier for the called party in the high level, the original identifier for the called party in the
"dest" array will become the "div" claim in the new PASSporT. If the "dest" array will become the "div" claim in the new PASSporT. If the
"dest" array of the original PASSporT contains multiple identifiers, "dest" array of the original PASSporT contains multiple identifiers,
the retargeting entity MUST select only one them to occupy the "div" the retargeting entity MUST select only one them to occupy the "div"
field in the new PASSporT, and in particular, it MUST select an field in the new PASSporT, and in particular, it MUST select an
identifier that is within the scope of the credential that the identifier that is within the scope of the credential that the
retargeting entity will specify in the "x5u" of the PASSporT header retargeting entity will specify in the "x5u" of the PASSporT header
(as described below). (as described below).
The new target for the call selected by the retargeting entity The new target for the call selected by the retargeting entity
becomes the value of the "dest" array of the new PASSporT. The becomes the value of the "dest" array of the new PASSporT. The
"orig" value MUST be copied into the new PASSporT from the original "orig" value MUST be copied into the new PASSporT from the original
PASSporT received by the retargeting entity. The retargeting entity PASSporT received by the retargeting entity. The retargeting entity
SHOULD retain the "iat" value from the original PASSporT, though if SHOULD retain the "iat" value from the original PASSporT, though if
in the underlying signaling protocol (e.g. SIP) the retargeting in the underlying signaling protocol (e.g. SIP) the retargeting
entity changes the date and time information in the retargeted entity changes the date and time information in the retargeted
request, the new PASSporT should instead reflect that date and time. request, the new PASSporT should instead reflect that date and time.
"opt" (see Section 5) contains the full form of the original PASSporT No other claims or extensions are to be copied from the original
from which the "div" was generated. No other extension claims should PASSporT to the "div" PASSporT.
be copied from the original PASSporT to the "div" PASSporT.
So, for an original PASSporT of the form: So, for an original PASSporT claims object of the form:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551213"}, "dest":{"tn":["12155551213"]},
"iat":1443208345 } "iat":1443208345 }
If the retargeting entity is changing the target from 12155551213 to If the retargeting entity is changing the target from 12155551213 to
12155551214, the new PASSporT with "div" would look as follows: 12155551214, the claims object of a "div" PASSpoRT generated by the
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"]} }
"opt":"eyJ0eXAiOiJwYXNzcG9ydCIsInBwdCI6ImRpdiIsImFsZyI6IkVT \
MjU2IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3g \
ifQ==.eyJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifSwiZGVzdCI6eyJ0b \
iI6IjEyMTU1NTUxMjEzIn0sImlhdCI6MTQ0MzIwODM0NX0=.rq3pjT1hoRw \
akEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3Q \
fPOlckGaS6hEck7w"} }
Note that the "div" claim may contain other elements than just a The combined full form PASSporT (with a signature covered by the
destination, including a History-Info indicator (see Section 7). ES256 keys given in Appendix A) would look as follows:
eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJkZXN0Ijp7InRuI \
jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.YZX3UGjaX \
sAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cHmaq0Mof2N-bfvRXPXuc \
htDJm8VbrbQ
Note that the "div" element may contain other elements than just a
destination, including a History-Info indicator (see Section 8).
After the PASSporT header and claims have been constructed, their After the PASSporT header and claims have been constructed, their
signature is generated per the guidance in [RFC8225] - except for the signature is generated per the guidance in [RFC8225] - except for the
credential required to sign it. While in the ordinary construction credential required to sign it. While in the ordinary construction
of a PASSporT, the credential used to sign will have authority over of a PASSporT, the credential used to sign will have authority over
the identity in the "orig" claim (for example, a certificate with the identity in the "orig" claim (for example, a certificate with
authority over the telephone number in "orig" per [RFC8226]), for all authority over the telephone number in "orig" per [RFC8226]), for all
PASSporTs using the "div" type the signature MUST be created with a PASSporTs using the "div" type the signature MUST be created with a
credential with authority over the identity present in the "div" credential with authority over the identity present in the "div"
claim. So for the example above, where the original "dest" is claim. So for the example above, where the original "dest" is
"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.
Instead of having multiple unlinked PASSporTs associated with a Note that Identity header fields are not ordered in a SIP request,
single call, it is helpful to relying parties to nest diversion and in a case where there is a multiplicity of Identity header fields
PASSporTs, explicitly relating the original PASSporT to the diverted in a request, some sorting may be required to match "div" PASSporTs
one. Note that the approach of having multiple Identity headers in a to their originals.
SIP request was considered in prior versions of this specification,
but it could be confusing for some verification services. The "opt" PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6)
extension is REQUIRED for use within in-band SIP use cases as well as element in their claims; PASSporTs of type "div-o" (see Section 5)
out-of-band [I-D.ietf-stir-oob] scenarios. Nested PASSporTs could MUST contain an "opt".
result in lengthy Identity headers, and some operational experience
is needed to ascertain how resilient legacy implementations will be
to large headers.
4. Using 'div' in SIP 4. Using 'div' in SIP
This section specifies SIP-specific usage for the "div" PASSporT type This section specifies SIP-specific usage for the "div" PASSporT type
and its handling in the SIP Identity header field "ppt" parameter and its handling in the SIP Identity header field "ppt" parameter
value. Other using protocols of PASSporT may define behavior value. Other using protocols of PASSporT may define behavior
specific to their use of the "div" claim. specific to their use of the "div" claim.
4.1. Authentication Service Behavior 4.1. Authentication Service Behavior
An authentication service only adds an Identity header field value An authentication service only adds an Identity header field value
containing the "div" PASSporT type to a SIP request that already containing the "div" PASSporT type to a SIP request that already
contains at least one Identity header field value; it MUST NOT add a contains at least one Identity header field value; it MUST NOT add a
"div" PASSporT to an INVITE that contains no Identity headers field. "div" PASSporT to an INVITE that contains no Identity header field.
As the authentication service will be adding a new PASSporT that The retargeting entity SHOULD act as a verification service and
contains an encapsulation of the original, it SHOULD remove the validate the existing Identity header field value(s) in the request
before proceeding; in some high-volume environments, it may instead
put that burden of validating the chain entirely on the terminating
verification service. As the authentication service will be adding a
new PASSporT that refers to an original, it MUST NOT remove the
original request's Identity header field value before forwarding. original request's Identity header field value before forwarding.
Note that a request may contain multiple Identity header field values
generated by different authorities; as a consequence, the retargeting
authentication service may need to perform this operation on multiple
existing PASSporTs, adding a "div" PASSporT per PASSporT in the
original. When adding an Identity header field with a PASSporT
object containing a "div" claim, SIP authentication services MUST
also add a "ppt" parameter to that Identity header with a value of
"div". The resulting full form Identity header field to add to the
message might look as follows:
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 \ As was stated in Section 3, the authentication service MUST sign any
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJvcmlnIjp7InRuIjoiMTIxNTU1NTE \ "div" PASSporT with a credential that has a scope of authority
yMTIifSwiZGVzdCI6eyJ0biI6IjEyMTU1NTUxMjE0In0sImlhdCI6MTQ0MzIwODM0NSwiZGl2 \ covering the identity it populates in the "div" element value. Note
Ijp7InRuIjoiMTIxNTU1NTUxMjEzIn0sIm9wdCI6ImV5SjBlWEFpT2lKd1lYTnpjRzl5ZENJc \ that this is a significant departure from baseline STIR
0luQndkQ0k2SW1ScGRpSXNJbUZzWnlJNklrVlRNalUySWl3aWVEVjFJam9pYUhSMGNITTZMeT \ authentication service behavior, in which the PASSporT is signed by a
kzZDNjdVpYaGhiWEJzWlM1amIyMHZZMlZ5ZEM1d2EzZ2lmUT09LmV5SnZjbWxuSWpwN0luUnV \ credential with authority over the "orig" field. The "div" value
Jam9pTVRJeE5UVTFOVEV5TVRJaWZTd2laR1Z6ZENJNmV5SjBiaUk2SWpFeU1UVTFOVFV4TWpF \ reflects the URI that caused the call to be routed to the retargeting
ekluMHNJbWxoZENJNk1UUTBNekl3T0RNME5YMD0ucnEzcGpUMWhvUndha0VHakhDbldTd1Vuc \ entity, so in ordinary operations, it would already be the STIR
2hkMC16SjZGMVZPZ0ZXU2pIQnI4UWpwamxrLWNwRllwRllzb2pOQ3BUek8zUWZQT2xja0dhUz \ entity holding the appropriate private keying material for calls
ZoRWNrN3cifX0=.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpF \ originating from that identity.
YsojNCpTzO3QfPOlckGaS6hEck7w;
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 "dest" element
"dest" from a new Request-URI that is set for the SIP request before value of a "div" PASSporT from a new Request-URI that is set for the
it is forwarded. Older values of the Request-URI may appear in SIP request before it is forwarded. Older values of the Request-URI
header fields like Diversion or History-Info; this document specifies may appear in header fields like Diversion or History-Info; this
no specific interaction between the "div" mechanism and those SIP document specifies an optional interaction with History-Info below in
header fields. 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
containing a "div" claim, SIP authentication services MUST also add a
"ppt" parameter to that Identity header with a value of "div". For
the example PASSporT given in Section 3, the new Identity header
added after retargeting might look as follows:
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J \
0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJk \
ZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1 \
NTEyMTMifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEy \
MTIifX0.YZX3UGjaXsAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cH \
maq0Mof2N-bfvRXPXuchtDJm8VbrbQ; \
info=<https://biloxi.example.org/biloxi.cer>;ppt="div"
Note that in some deployments, an authentication service will need to
generate "div" PASSporTs for a request that contains multiple
non-"div" Identity header field values. For example, a request
arriving at a retargeting entity might contain in different Identity
header fields a baseline [RFC8224] PASSporT and a PASSporT of type
"rph" [I-D.ietf-stir-rph] signed by a separate authority. Provided
that these PASSporTs share the same "orig" and "dest" values, the
retargeting entity's authentication service SHOULD generate only one
"div" PASSporT. If the "orig" or "dest" of these PASSporTs differ,
however, one "div" PASSporT SHOULD be generated for each non-"div"
PASSporT. Furthermore note that a request may also be retargeted a
second time, at which point the subsequent retargeting entity SHOULD
generate one "div" PASSporT for each previous "div" PASSporT in the
request. This can create multiple chains of "div" PASSporTs in a
single request, which complicates the procedures that need to be
performed at verification services.
4.2. Verification Service Behavior 4.2. Verification Service Behavior
[RFC8224] Section 6.2 Step 5 requires that specifications defining [RFC8224] Section 6.2 Step 5 requires that specifications defining
"ppt" values describe any additional verifier behavior. The behavior "ppt" values describe any additional or alternative verifier
specified for the "div" value of "ppt" is as follows. behavior. The job of a SIP verification service handling one or more
"div" PASSporTs is very different from that of a traditional
verification service. At a high level, the immediate responsibility
of the verification service is to extract all PASSporTs from the two
or more Identity headers in a request, identify which are "div"
PASSporTs and which are not, and then order and link the "div"
PASSporTs to the original PASSporT(s) in order to build one or more
chains of retargeting.
In order to use the "div" extension, a verification service needs to In order to validate a SIP request using the "div" PASSporT type, a
inspect any nested PASSporT objects within PASSporTs it validates, as verification service needs to inspect all of the valid Identity
an Identity header field value containing "div" necessarily refers to header field values associated with a request, as an Identity header
an earlier PASSporT nested. If a nested PASSporT within a "div" field value containing "div" necessary refers to an earlier PASSporT
PASSporT contains a "dest" claim with a value not equivalent to the already in the message. For each "div" PASSporT, the verification
"div" claim in the "div" PASSporT, that "div" PASSporT SHOULD NOT be service MUST find an earlier PASSporT that contains a "dest" claim
considered valid. It is possible that this nested PASSporT will also with a value equivalent to the "div" claim in each "div" PASSporT.
contain a "div", and that it will in turn chain to a still earlier It is possible that this earlier PASSporT will also contain a "div",
PASSporT nested within it. Ultimately, by looking at this chain of and that it will in turn chain to a still earlier PASSporT stored in
transformations and validating the associated signatures, the a different Identity header field value. If a complete chain cannot
verification service will be able to ascertain that the appropriate be constructed, the verification service cannot complete "div"
parties were responsible for the retargeting of the call to its validation; it MAY still validate any non-"div" PASSporTs in the
ultimate destination; this can help the verification service to request per normal [RFC8224] procedures. If a chain has been
determine that the original PASSporT in the call was not simply used successfully constructed, the verification service extracts from the
in a cut-and-paste attack. This will help relying parties to make 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
the SIP request refers to. Its "dest" element value will be referred
to in the procedures that follow as the value of the "outermost
'dest' field."
Ultimately, by looking at this chain of transformations and
validating the associated signatures, the verification service will
be able to ascertain that the appropriate parties were responsible
for the retargeting of the call to its current destination. This can
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
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. matter of local policy and is thus outside the scope of this
specification. A verification service parses a chain of PASSporTs as
follows:
5. Definition of 'opt' First, the verification service MUST compare the value in the
outermost "dest" field to the target of the call. As it is
anticipated that SIP authentication services that create "div"
PASSporTs will populate the "dest" header from the retargeted
Request-URI (see Section 4.1), in ordinary SIP operations, the
Request-URI is where verification services will find the latest
call target. Note however that after a "div" PASSporT has been
added to a SIP request, the Request-URI may have been updated
during normal call processing to an identifier that no longer
contains the logical destination of a call; in this case, the
verification service MAY compare the "dest" field to a provisioned
telephone number for the recipient.
Second, the verification service MUST validate the signature over
the outermost "div" PASSporT, and establish that the credential
that signed the "div" PASSporT has the authority to attest for the
identifier in the "div" element of the PASSporT (per [RFC8224]
Section 6.2 Step 3).
Third, the verification service MUST validate that the "orig"
field of the innermost PASSporT of the chain (the only PASSporT in
the chain which will not be of PASSporT type "div") is equivalent
to the "orig" field of the outermost "div" PASSporT; in other
words, that the original calling identifier has not been altered
by retargeting authentication services. If the "orig" value has
changed, the verification service MUST treat the entire PASSporT
chain as invalid. The verification service SHOULD also verify
that all other "div" PASSporTs in the chain share the same "orig"
value. Then the verification service validates the relationship
of the "orig" field to the SIP-level call signaling per the
guidance in [RFC8224] Section 6.2 Step 2.
Fourth, the verification service MUST check the date freshness in
the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It
is furthermore RECOMMENDED that the verification service check
that the "iat" field of the innermost PASSporT is also within the
date freshness interval; otherwise the verification service could
allow attackers to replay an old, stale PASSporT embedded in a
fresh "div".
Fifth, the verification service MUST inspect and validate the
signatures on each and every PASSporT object in the chain between
the outermost "div" PASSporT and the innermost PASSporT. Note
that (per Section 4.1) a chain may terminate at more than one
innermost PASSporT, in cases where a single "div" is used to
retarget from multiple based PASSporTs.
Note that the To header field is not used in the first step above.
Optionally, the verification service MAY verify that the To header
field value of the received SIP signaling is equal to the "dest"
value in the innermost PASSporT; however, as has been observed in
some deployments, the original To header field value may be altered
by intermediaries to reflect changes of target. Deployments that
change the original To header field value to conceal the original
destination of the call from the ultimate recipient should note that
the original destination of a call may be preserved in the innermost
PASSporT. Future work on "div" might explore methods to implement
that sort of policy while retaining a secure chain of redirection.
5. The 'div-o' PASSporT Type
This specification defines a "div-o" PASSporT type that uses the
"div" claim element in conjunction with the opt (Section 6) PASSporT
claim element. As is the case with "div" PASSporT type, a "div-o"
PASSporT is created by an authentication service acting for a
retargeting entity, but instead of generating a separate "div"
PASSporT to be conveyed alongside an original PASSporT, the
authentication service in this case embeds the original PASSporT
inside the "opt" element of the "div-o" PASSporT. The "div-o"
extension is designed for use in non-SIP or gatewayed SIP
environments where the conveyance of PASSporTs in separate Identity
header fields in impossible, such as out-of-band [I-D.ietf-stir-oob]
STIR scenarios.
The syntax of "div-o" PASSporTs is very similar to "div". A "div-o"
PASSporT header object might look as follows:
{ "typ":"passport",
"ppt":"div-o",
"alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" }
Whereas a "div" PASSporT claims object contains only the "orig",
"dest", "iat", and "div" elements, the "div-o" additionally MUST
contain an "opt" element (see Section 6), which encapsulates the full
form of the previous PASSporT from which the call was retargeted,
triggering the generation of this "div-o". The value of the "opt"
element is identical to the base64 encoded PASSporT format given in
Appendix A of [RFC8225].
So, for an original PASSporT claims object of the form:
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551213"]},
"iat":1443208345 }
If the retargeting entity is changing the target from 12155551213 to
12155551214, the new PASSporT claims object for "div-o" would look as
follows:
{ "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]},
"iat":1443208345,
"div":{"tn":"121555551213"},
"opt":"4F7jsZv0mJ5bjg4Xik6Mfah3IO8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7 \
c0_0eQi4e9FVX-WmvX3uETtlVjAtgeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3N \
wb3J0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ. \
eyJkZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUs \
Im9yaWciOnsidG4iOiIxMjE1NTU1MTIxMiJ9fQ.4F7jsZv0mJ5bjg4Xik6Mfah3I \
O8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7c0_0eQi4e9FVX-WmvX3uETtlVjAtg"} }
While in ordinary operations, it is not expected that SIP would carry
a "div-o" PASSporT, it might be possible in some gatewaying
scenarios. The resulting full form Identity header field with a
"div-o" PASSporT would look as follows:
Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \
nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LnBreCJ9.eyJkZX \
N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \
In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \
I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \
YlhCc1pTNWpiMjB2WTJWeWRDNXdhM2dpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \
V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \
T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjRGN2pzWnYwbUo1YmpnNFhpaz \
ZNZmFoM0lPOEs2RklzVUlndnQwZEU3UW0zS1pyNVVGX1VwQ3J6N2MwXzBlUWk0ZTlG \
VlgtV212WDN1RVR0bFZqQXRnIiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.M \
CYorw_3FaH78VuERURlJp1hD6qh2eIct4RIebVtYp3es9HTsvCz1qXRWq3j0E9Pb2h \
YrMUXSQbBYQSviW5cCA; \
info=<https://biloxi.example.org/biloxi.cer>;ppt="div-o"
The authentication and verification service procedures required for
"div-o" will necessarily be specific to the protocol or environment
where it is used, and thus are left to future work.
6. Definition of 'opt'
The presence of an original PASSporT claims object element, The presence of an original PASSporT claims object element,
designated as "opt", signifies that a PASSporT encapsulates another designated as "opt", signifies that a PASSporT encapsulates another
entire PASSporT within it, typically a PASSporT that was transformed entire PASSporT within it, typically a PASSporT that was transformed
in some way to create the current PASSporT. Relying parties may need in some way to create the current PASSporT. Relying parties may need
to consult the encapsulated PASSporT in order to validate the to consult the encapsulated PASSporT in order to validate the
identity of a caller. "opt" as defined in this specification may be identity of a caller. "opt" as defined in this specification may be
used by future PASSporT extensions as well as in conjunction with used by future PASSporT extensions as well as in conjunction with
"div". "div-o".
"opt" MUST contain a quoted base64 encoded full-form PASSporT; it "opt" MUST contain a quoted base64 encoded full-form PASSporT as
MUST NOT contain a compact form PASSporT. For an example of a "div" specified by [RFC8225] Appendix A; it MUST NOT contain a compact form
PASSporT containing "opt," see Section 3. PASSporT. For an example of a "div-o" PASSporT containing "opt," see
Section 5.
6. '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 its "dest" value designates a different eventual recipient, because the original PASSporT "dest" value
original 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 UAC
receives the 3xx response, it will initiate a new request to the new receives the 3xx response, it will initiate a new request to the new
target (typically the target carried in the Contact header field target (typically the target carried in the Contact header field
value of the 3xx), and the "dest" of the PASSporT created for the new value of the 3xx), and the "dest" of the PASSporT created for the new
request will match that new target. As no impersonation attack can request will match that new target. As no impersonation attack can
arise from this case, it creates no new requirements for STIR. arise from this case, it creates no new requirements for STIR.
skipping to change at page 8, line 35 skipping to change at page 12, line 35
mind as well that the original SIP request could have carried mind as well that the original SIP request could have carried
multiple Identity header field values that had been added by multiple Identity header field values that had been added by
different authentication services in the request path, so a different authentication services in the request path, so a
redirecting entity might need to generate one nested "div" PASSporT redirecting entity might need to generate one nested "div" PASSporT
per each PASSporT in the original request. Often this will mean just per each PASSporT in the original request. Often this will mean just
one "div" PASSporT, but for some deployment scenarios, it could one "div" PASSporT, but for some deployment scenarios, it could
require an impractical number of combinations. But in very complex require an impractical number of combinations. But in very complex
call routing scenarios, attestation of source identity would only add call routing scenarios, attestation of source identity would only add
limited value anyway. limited value anyway.
STIR-aware intermediaries that redirect requests MAY therefore convey STIR-aware SIP intermediaries that redirect requests MAY therefore
one or more PASSporTs in the backwards direction within Identity convey one or more PASSporTs in the backwards direction within
headers. This document consequently updates [RFC8224] to permit Identity headers. These redirecting entities will act as
carrying Identity headers in SIP 300-class responses. It is left to authentication services for "div" as described in Section 4.1. This
authentication services to determine which Identity headers should be document consequently updates [RFC8224] to permit carrying Identity
copied into any new requests resulting from the redirection, if any: headers in SIP 300-class responses. It is left to the originating
user agent to determine which Identity headers should be copied from
the 3xx 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. These intermediaries MAY
also copy PASSporTs from the 3xx response and insert them into
sequential forking requests, if appropriate.
7. 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 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 field with an index value of "1.2.1",
claims object of the corresponding PASSporT with "div" might look the claims object of the corresponding PASSporT with "div" might look
like: like:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551214"}, "dest":{"tn":["12155551214"]},
"iat":1443208345, "iat":1443208345,
"div":{"tn":"121555551213", "div":{"tn":"121555551213",
"hi":"1.2.1"} "hi":"1.2.1"} }
"opt":[...]" }
Past experience has shown that there may be additional information Past experience has shown that there may be additional information
about the motivation for retargeting that relying parties might about the motivation for retargeting that relying parties might
consider when making authorization decisions about a call, see for consider when making authorization decisions about a call, see for
example the "reason" associated with the SIP Diversion header field example the "reason" associated with the SIP Diversion header field
[RFC5806]. Future extensions to this specification might incorporate [RFC5806]. Future extensions to this specification might incorporate
reasons into "div". reasons into "div".
8. Acknowledgments 9. Acknowledgments
We would like to thank Eric Burger, Dave Hancock, Chris Wendt and We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Eric
Robert Sparks for contributions to this document. Burger, and Robert Sparks for contributions to this document.
9. IANA Considerations 10. IANA Considerations
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].
9.1. 'div' registration 10.1. 'div' registration
Claim Name: "div" Claim Name: "div"
Claim Description: New Target of a Call Claim Description: New Target of a Call
Change Controller: IESG Change Controller: IESG
Specification Document(s): [RFCThis] Specification Document(s): [RFCThis]
9.2. 'opt' registration 10.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. Security Considerations 10.3. PASSporT Type Registrations
This specification defines two new PASSporT types for the PASSport
Type Registry defined in [RFC8225]. They are:
"div" as defined in Section 3.
"div-o" as defined in Section 5.
11. 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.
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 6) 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.
11. References 12. References
12.1. Normative References
11.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 11, line 30 skipping to change at page 15, line 42
[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>.
11.2. Informative References 12.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-03 (work
in progress), July 2018. in progress), July 2018.
[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>.
Appendix A. Appendix A: Keys for Examples
The following EC256 keys are used in the signing examples given in
this document.
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
-----END EC PRIVATE KEY-----
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@team.neustar Email: jon.peterson@team.neustar
 End of changes. 54 change blocks. 
166 lines changed or deleted 388 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/