< draft-ietf-stir-oob-04.txt   draft-ietf-stir-oob-05.txt >
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track J. Peterson Intended status: Informational J. Peterson
Expires: September 12, 2019 Neustar Expires: January 9, 2020 Neustar
March 11, 2019 July 8, 2019
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-04.txt draft-ietf-stir-oob-05
Abstract Abstract
The PASSporT format defines a token that can be carried by signaling The PASSporT format defines a token that can be carried by signaling
protocols, including SIP, to cryptographically attest the identify of protocols, including SIP, to cryptographically attest the identify of
callers. Not all telephone calls use Internet signaling protocols, callers. Not all telephone calls use Internet signaling protocols,
however, and some calls use them for only part of their signaling however, and some calls use them for only part of their signaling
path. This document describes use cases that require the delivery of path, or cannot reliably deliver SIP header fields end-to-end. This
PASSporT objects outside of the signaling path, and defines document describes use cases that require the delivery of PASSporT
architectures and semantics to provide this functionality. objects outside of the signaling path, and defines architectures and
semantics to provide this functionality.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4
4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 7
5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 7 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 7
5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7
5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 8 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 8
5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 8 5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 8
6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 9 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 9
6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12
7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12
7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14
7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 14 7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 15
8. Authentication and Verification Service Behavior for Out-of- 8. Authentication and Verification Service Behavior for Out-of-
Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Authentication Service . . . . . . . . . . . . . . . . . 16 8.1. Authentication Service . . . . . . . . . . . . . . . . . 16
8.2. Verification Service . . . . . . . . . . . . . . . . . . 17 8.2. Verification Service . . . . . . . . . . . . . . . . . . 17
8.3. Gateway Placement Services . . . . . . . . . . . . . . . 18 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 18
9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 18 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 19
10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 20 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 21 11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 22 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
15. Informative References . . . . . . . . . . . . . . . . . . . 22 15. Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] describes widespread problems The STIR problem statement [RFC7340] describes widespread problems
enabled by impersonation in the telephone network, including illegal enabled by impersonation in the telephone network, including illegal
robocalling, voicemail hacking, and swatting. As telephone services robocalling, voicemail hacking, and swatting. As telephone services
are increasingly migrating onto the Internet, and using Voice over IP are increasingly migrating onto the Internet, and using Voice over IP
(VoIP) protocols such as SIP [RFC3261], it is necessary for these (VoIP) protocols such as SIP [RFC3261], it is necessary for these
protocols to support stronger identity mechanisms to prevent protocols to support stronger identity mechanisms to prevent
impersonation. For example, [RFC8224] defines an Identity header of impersonation. For example, [RFC8224] defines a SIP Identity header
SIP requests capable of carrying a PASSporT [RFC8225] object in SIP field capable of carrying PASSporT [RFC8225] objects in SIP as a
as a means to cryptographically attest that the originator of a means to cryptographically attest that the originator of a telephone
telephone call is authorized to use the calling party number (or, for call is authorized to use the calling party number (or, for native
native SIP cases, SIP URI) associated with the originator of the SIP cases, SIP URI) associated with the originator of the call.
call.
Not all telephone calls use SIP today, however, and even those that Not all telephone calls use SIP today, however, and even those that
do use SIP do not always carry SIP signaling end-to-end. Most calls do use SIP do not always carry SIP signaling end-to-end. Xalls from
from telephone numbers still traverse the Public Switched Telephone telephone numbers still routinely traverse the Public Switched
Network (PSTN) at some point. Broadly, calls fall into one of three Telephone Network (PSTN) at some point. Broadly, calls fall into one
categories: of three categories:
1. One or both of the endpoints is actually a PSTN endpoint. 1. One or both of the endpoints is actually a PSTN endpoint.
2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the
call transits the PSTN at some point. call transits the PSTN at some point.
3. Non-PSTN calls which do not transit the PSTN at all (such as 3. Non-PSTN calls which do not transit the PSTN at all (such as
native SIP end-to-end calls). native SIP end-to-end calls).
The first two categories represent the majority of telephone calls The first two categories represent the majority of telephone calls
skipping to change at page 3, line 46 skipping to change at page 3, line 46
band authentication scheme does not seem practical in the current band authentication scheme does not seem practical in the current
environment. environment.
But while the core network of the PSTN remains fixed, the endpoints But while the core network of the PSTN remains fixed, the endpoints
of the telephone network are becoming increasingly programmable and of the telephone network are becoming increasingly programmable and
sophisticated. Landline "plain old telephone service" deployments, sophisticated. Landline "plain old telephone service" deployments,
especially in the developed world, are shrinking, and increasingly especially in the developed world, are shrinking, and increasingly
being replaced by three classes of intelligent devices: smart phones, being replaced by three classes of intelligent devices: smart phones,
IP PBXs, and terminal adapters. All three are general purpose IP PBXs, and terminal adapters. All three are general purpose
computers, and typically all three have Internet access as well as computers, and typically all three have Internet access as well as
access to the PSTN. Additionally, various kinds of gateways access to the PSTN; they may be used for residential, mobile, or
increasingly front for deployments of legacy PBX and PSTN switches. enterprise telephone services. Additionally, various kinds of
All of this provides a potential avenue for building an gateways increasingly front for deployments of legacy PBX and PSTN
switches. All of this provides a potential avenue for building an
authentication system that implements stronger identity while leaving authentication system that implements stronger identity while leaving
PSTN systems intact. PSTN systems intact.
This capability also provides an ideal transitional technology while This capability also provides an ideal transitional technology while
in-band STIR adoption is ramping up. It permits early adopters to in-band STIR adoption is ramping up. It permits early adopters to
use the technology even when intervening network elements are not yet use the technology even when intervening network elements are not yet
STIR-aware, and through various kinds of gateways, it may allow STIR-aware, and through various kinds of gateways, it may allow
providers with a significant PSTN investment to still secure their providers with a significant PSTN investment to still secure their
calls with STIR. calls with STIR.
This specification therefore builds on the PASSporT [RFC8225] This specification therefore builds on the PASSporT [RFC8225]
mechanism and the work of [RFC8224] to define a way that a PASSporT mechanism and the work of [RFC8224] to define a way that a PASSporT
object created in the originating network of a call can reach the object created in the originating network of a call can reach the
terminating network even when it cannot be carried end-to-end in-band terminating network even when it cannot be carried end-to-end in-band
in the call signaling. This relies on a new service defined in this in the call signaling. This relies on a new service defined in this
document called a Call Placement Service (CPS) that permits the document called a Call Placement Service (CPS) that permits the
PASSporT object to be stored during call processing and retrieved for PASSporT object to be stored during call processing and retrieved for
verification purposes. verification purposes.
Potential implementors should note that this document merely defines
the operating environments in which this out-of-band STIR mechanism
is intended to operate. It provides use cases, gives a broad
description of the components and a potential solution architecture.
To flesh out the storage and retrieval of PASSporTs in the CPS within
this context, it includes a strawman protocol suitable for that
purpose. Deploying this framework would require additional
specification outside the scope of the current document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Operating Environments 3. Operating Environments
This section describes the environments in which the proposed out-of- This section describes the environments in which the proposed out-of-
band STIR mechanism is intended to operate. In the simplest setting, band STIR mechanism is intended to operate. In the simplest setting,
Alice is calling Bob through some set of gateways and/or the PSTN. Alice is calling Bob, and her call is routed through some set of
Both Alice and Bob have smart devices which can be modified, but they gateways and/or the PSTN which do not support end-to-end delivery of
do not have a clear connection between them: Alice cannot inject any STIR. Both Alice and Bob have smart devices which can access the
data into signaling which Bob can read, with the exception of the Internet (perhaps enterprise devices, or even end user ones), but
asserted destination and origination E.164 numbers. The calling they do not have a clear telephone signaling connection between them:
party number might originate from her own device or from the network. Alice cannot inject any data into signaling which Bob can read, with
These numbers are effectively the only data that can be used for the exception of the asserted destination and origination E.164
coordination between the endpoints. numbers. The calling party number might originate from her own
device or from the network. These numbers are effectively the only
data that can be used for coordination between the endpoints.
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ / \ +----------+ +----------+ / \ +----------+
| | | Gateways | | | | | | Gateways | | |
| Alice |<----->| and/or |<----->| Bob | | Alice |<----->| and/or |<----->| Bob |
| (caller) | | PSTN | | (callee) | | (caller) | | PSTN | | (callee) |
+----------+ \ / +----------+ +----------+ \ / +----------+
+--- +---+ +--- +---+
\ / \ /
+---------+ +---------+
In a more complicated setting, Alice and/or Bob may not have a smart In a more complicated setting, Alice and/or Bob may not have a smart
or programmable device, but one or both of them are behind a STIR- or programmable device, but instead just a traditional telephone.
aware gateway that can participate in out-of-band coordination, as However, one or both of them are behind a STIR-aware gateway that can
shown below: participate in out-of-band coordination, as shown below:
+---------+ +---------+
/ \ / \
+--- +---+ +--- +---+
+----------+ +--+ / \ +--+ +----------+ +----------+ +--+ / \ +--+ +----------+
| | | | | Gateways | | | | | | | | | | Gateways | | | | |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob | | Alice |<-|GW|->| and/or |<-|GW|->| Bob |
| (caller) | | | | PSTN | | | | (callee) | | (caller) | | | | PSTN | | | | (callee) |
+----------+ +--+ \ / +--+ +----------+ +----------+ +--+ \ / +--+ +----------+
+--- +---+ +--- +---+
\ / \ /
+---------+ +---------+
In such a case, Alice might have an analog connection to her gateway/ In such a case, Alice might have an analog (e.g., PSTN) connection to
switch which is responsible for her identity. Similarly, the gateway her gateway/ switch which is responsible for her identity.
would verify Alice's identity, generate the right calling party Similarly, the gateway would verify Alice's identity, generate the
number information and provide that number to Bob using ordinary POTS right calling party number information and provide that number to Bob
mechanisms. using ordinary Plain Ol' Telephone Service (POTS) mechanisms.
4. Dataflows 4. Dataflows
Because in these operating environments endpoints cannot pass Because in these operating environments endpoints cannot pass
cryptographic information to one another directly through signaling, cryptographic information to one another directly through signaling,
any solution must involve some rendezvous mechanism to allow any solution must involve some rendezvous mechanism to allow
endpoints to communicate. We call this rendezvous service a "call endpoints to communicate. We call this rendezvous service a "call
placement service" (CPS), a service where a record of call placement, placement service" (CPS), a service where a record of call placement,
in this case a PASSporT, can be stored for future retrieval. In in this case a PASSporT, can be stored for future retrieval. In
principle this service could communicate any information, but principle this service could communicate any information, but
minimally we expect it to include a full-form PASSporT that attests minimally we expect it to include a full-form PASSporT that attests
the caller, callee, and the time of the call. The callee can use the the caller, callee, and the time of the call. The callee can use the
existence of a PASSporT for a given incoming call as rough validation existence of a PASSporT for a given incoming call as rough validation
of the asserted origin of that call. (See Section 11 for limitations of the asserted origin of that call. (See Section 11 for limitations
of this design.) of this design.)
This architecture does not mandate that any particular sort of entity This architecture does not mandate that any particular sort of entity
operate a CPS, or mandate any means to discover a CPS. A CPS could operate a CPS, or mandate any means to discover a CPS. A CPS could
be run internally within a network, or made publicly available. One be run internally within a network, or made publicly available. One
or more CPSs could be run by a carrier, as repositories for PASSporTs or more CPSes could be run by a carrier, as repositories for
for calls sent to its customers, or a CPS could be built-in to an PASSporTs for calls sent to its customers, or a CPS could be built-in
enterprise PBX, or even a smartphone. To the degree possible, it is to an enterprise PBX, or even a smartphone. To the degree possible,
here specified generically, as an idea that may have applicability to it is here specified generically, as an idea that may have
a variety of STIR deployments. applicability to a variety of STIR deployments.
There are roughly two plausible dataflow architectures for the CPS: There are roughly two plausible dataflow architectures for the CPS:
The callee registers with the CPS. When the caller wishes to 1. The callee registers with the CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, place a call to the callee, it sends the PASSporT to the CPS,
which immediately forwards it to the callee. which immediately forwards it to the callee, or,
The caller stores the PASSporT with the CPS at the time of call 2. The caller stores the PASSporT with the CPS at the time of call
placement. When the callee receives the call, it contacts the CPS placement. When the callee receives the call, it contacts the
and retrieves the PASSporT. CPS and retrieves the PASSporT.
While the first architecture is roughly isomorphic to current VoIP While the first architecture is roughly isomorphic to current VoIP
protocols, it shares their drawbacks. Specifically, the callee must protocols, it shares their drawbacks. Specifically, the callee must
maintain a full-time connection to the CPS to serve as a notification maintain a full-time connection to the CPS to serve as a notification
channel. This comes with the usual networking costs to the callee channel. This comes with the usual networking costs to the callee
and is especially problematic for mobile endpoints. Indeed, if the and is especially problematic for mobile endpoints. Indeed, if the
endpoints had the capabilities to implement such an architecture, endpoints had the capabilities to implement such an architecture,
they could surely just use SIP or some other protocol to set up a they could surely just use SIP or some other protocol to set up a
secure session; even if the media were going through the traditional secure session; even if the media were going through the traditional
PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we
focus on the second architecture in which the PSTN incoming call focus on the second architecture in which the PSTN incoming call
serves as the notification channel and the callee can then contact serves as the notification channel and the callee can then contact
the CPS to retrieve the PASSporT. In some environments, for example the CPS to retrieve the PASSporT. In specialized environments, for
a call center that receives a large volume of incoming calls that example a call center that receives a large volume of incoming calls
originated in the PSTN, the notification channel approach might be that originated in the PSTN, the notification channel approach might
viable. be viable.
5. Use Cases 5. Use Cases
The following are the motivating use cases for this mechanism. Bear The following are the motivating use cases for this mechanism. Bear
in mind that just as in [RFC8224] there may be multiple Identity in mind that just as in [RFC8224] there may be multiple Identity
headers in a single SIP INVITE, so there may be multiple PASSporTs in headers in a single SIP INVITE, so there may be multiple PASSporTs in
this out-of-band mechanism associated with a single call. For this out-of-band mechanism associated with a single call. For
example, a SIP user agent might create a PASSporT for a call with an example, a SIP user agent might create a PASSporT for a call with an
end user credential, and as the call exits the originating end user credential, and as the call exits the originating
administrative domain the network authentication service might create administrative domain the network authentication service might create
its own PASSporT for the same call. As such, these use cases may its own PASSporT for the same call. As such, these use cases may
overlap in the processing of a single call. overlap in the processing of a single call.
5.1. Case 1: VoIP to PSTN Call 5.1. Case 1: VoIP to PSTN Call
A call originates in the SIP world in a STIR-aware administrative A call originates in a SIP environment in a STIR-aware administrative
domain. The local authentication service for that administrative domain. The local authentication service for that administrative
domain creates a PASSporT which is carried in band in the call per domain creates a PASSporT which is carried in band in the call per
[RFC8224]. The call is routed out of the originating administrative [RFC8224]. The call is routed out of the originating administrative
domain and reaches a gateway to the PSTN. Eventually, the call will domain and reaches a gateway to the PSTN. Eventually, the call will
terminate on a mobile smartphone that supports this out-of-band terminate on a mobile smartphone that supports this out-of-band
mechanism. mechanism.
In this use case, the originating authentication service can store In this use case, the originating authentication service can store
the PASSporT with the appropriate CPS for the target telephone number the PASSporT with the appropriate CPS for the target telephone number
as a fallback in case SIP signaling will not reach end-to-end. When as a fallback in case SIP signaling will not reach end-to-end. When
the destination mobile smartphone receives the call over the PSTN, it the destination mobile smartphone receives the call over the PSTN, it
consults the CPS and discovers a PASSporT from the originating consults the CPS and discovers a PASSporT from the originating
telephone number waiting for it. It uses this PASSporT to verify the telephone number waiting for it. It uses this PASSporT to verify the
calling party number. calling party number.
5.2. Case 2: Two Smart PSTN endpoints 5.2. Case 2: Two Smart PSTN endpoints
A call originates with an enterprise PBX that has both Internet A call originates with an enterprise PBX that has both Internet
access and a built-in gateway to the PSTN. It will immediately drop access and a built-in gateway to the PSTN, which communicates through
its call to the PSTN, but before it does, it provisions a PASSporT on traditional telephone signaling protocols. The PBX immediately drops
the call to the PSTN, but before it does, it provisions a PASSporT on
the CPS associated with the target telephone number. the CPS associated with the target telephone number.
After normal PSTN routing, the call lands on a smart mobile handset After normal PSTN routing, the call lands on a smart mobile handset
that supports the STIR out-of-band mechanism. It queries the that supports the STIR out-of-band mechanism. It queries the
appropriate CPS over the Internet to determine if a call has been appropriate CPS over the Internet to determine if a call has been
placed to it by a STIR-aware device. It finds the PASSporT placed to it by a STIR-aware device. It finds the PASSporT
provisioned by the enterprise PBX and uses it to verify the calling provisioned by the enterprise PBX and uses it to verify the calling
party number. party number.
5.3. Case 3: PSTN to VoIP Call 5.3. Case 3: PSTN to VoIP Call
A call originates with an enterprise PBX that has both Internet A call originates with an enterprise PBX that has both Internet
access and a built-in gateway to the PSTN. It will immediate drop access and a built-in gateway to the PSTN. It will immediately drop
the call to the PSTN, but before it does, it provisions a PASSporT the call to the PSTN, but before it does, it provisions a PASSporT
with the CPS associated with the target telephone number. However, with the CPS associated with the target telephone number. However,
it turns out that the call will eventually route through the PSTN to it turns out that the call will eventually route through the PSTN to
an Internet gateway, which will translate this into a SIP call and an Internet gateway, which will translate this into a SIP call and
deliver it to an administrative domain with a STIR verification deliver it to an administrative domain with a STIR verification
service. service.
In this case, there are two subcases for how the PASSporT might be In this case, there are two subcases for how the PASSporT might be
retrieved. In subcase 1, the Internet gateway that receives the call retrieved. In subcase 1, the Internet gateway that receives the call
from the PSTN could query the appropriate CPS to determine if the from the PSTN could query the appropriate CPS to determine if the
skipping to change at page 8, line 22 skipping to change at page 8, line 37
In this case, the originating authentication service does not support In this case, the originating authentication service does not support
the out-of-band mechanism, so instead the gateway to the PSTN the out-of-band mechanism, so instead the gateway to the PSTN
extracts the PASSporT from the SIP request and provisions it to the extracts the PASSporT from the SIP request and provisions it to the
CPS. (When the call reaches the gateway to the PSTN, the gateway CPS. (When the call reaches the gateway to the PSTN, the gateway
might first check the CPS to see if a PASSporT object had already might first check the CPS to see if a PASSporT object had already
been provisioned for this call, and only provision a PASSporT if none been provisioned for this call, and only provision a PASSporT if none
is present). is present).
Ultimately, the call may terminate on the PSTN, or be routed back to Ultimately, the call may terminate on the PSTN, or be routed back to
the IP world. In the former case, perhaps the destination endpoints a SIP environment. In the former case, perhaps the destination
queries the CPS to retrieve the PASSporT provisioned by the first endpoint queries the CPS to retrieve the PASSporT provisioned by the
gateway. Or if the call ultimately returns to the IP world, it might first gateway. Or if the call ultimately returns to a SIP
be the gateway from the PSTN back to the Internet that retrieves the environment, it might be the gateway from the PSTN back to the
PASSporT from the CPS and attaches it to the new SIP INVITE it Internet that retrieves the PASSporT from the CPS and attaches it to
creates, or it might be the terminating administrative domain's the new SIP INVITE it creates, or it might be the terminating
verification service that checks the CPS when an INVITE arrives with administrative domain's verification service that checks the CPS when
no Identity header field. Either way the PASSporT can survive the an INVITE arrives with no Identity header field. Either way the
gap in SIP coverage caused by the PSTN leg of the call. PASSporT can survive the gap in SIP coverage caused by the PSTN leg
of the call.
5.5. Case 5: Enterprise Call Center 5.5. Case 5: Enterprise Call Center
A call originates from a mobile user, and a STIR authentication A call originates from a mobile user, and a STIR authentication
service operated by their carrier creates a PASSporT for the call. service operated by their carrier creates a PASSporT for the call.
As the carrier forwards the call via SIP, it attaches the PASSporT to As the carrier forwards the call via SIP, it attaches the PASSporT to
the SIP call with an Identity header. In case the call will not go the SIP call with an Identity header. As a fallback in case the call
end-to-end over SIP, the carrier also stores the PASSporT in a CPS. will not go end-to-end over SIP, the carrier also stores the PASSporT
in a CPS.
The call is then routed over SIP for a time, before it transitions to The call is then routed over SIP for a time, before it transitions to
the PSTN and ultimately is handled by a legacy PBX at a high-volume the PSTN and ultimately is handled by a legacy PBX at a high-volume
call center. The call center supports the out-of-band service, and call center. The call center supports the out-of-band service, and
has a high-volume interface to a CPS to retrieve PASSporTs for has a high-volume interface to a CPS to retrieve PASSporTs for
incoming calls; agents at the call center use a general purpose incoming calls; agents at the call center use a general purpose
computer to manage inbound calls and can receive STIR notifications computer to manage inbound calls and can receive STIR notifications
through it. When the PASSporT arrives at the CPS, it is sent through through it. When the PASSporT arrives at the CPS, it is sent through
a subscription/notification interface to a system that can correlate a subscription/notification interface to a system that can correlate
incoming calls with valid PASSporTs. The call center agent sees that incoming calls with valid PASSporTs. The call center agent sees that
a valid calls from the originating number has arrived. a valid call from the originating number has arrived.
6. Storing and Retrieving PASSporTs 6. Storing and Retrieving PASSporTs
The use cases show a variety of entities accessing the CPS to store The use cases show a variety of entities accessing the CPS to store
and retrieve PASSporTs. The question of how the CPS authorizes the and retrieve PASSporTs. The question of how the CPS authorizes the
storage and retrieval of PASSporT is thus a key design decision in storage and retrieval of PASSporT is thus a key design decision in
the architecture. The STIR architecture assumes that service the architecture. The STIR architecture assumes that service
providers and in some cases end user devices will have credentials providers and in some cases end user devices will have credentials
suitable for attesting authority over telephone numbers per suitable for attesting authority over telephone numbers per
[RFC8226]. These credentials provide the most obvious way that a CPS [RFC8226]. These credentials provide the most obvious way that a CPS
can authorize the storage and retrieval of PASSporTs. However, as can authorize the storage and retrieval of PASSporTs. However, as
use cases 3 and 4 in Section 5 show, it may sometimes make sense for use cases 3, 4 and 5 in Section 5 show, it may sometimes make sense
the entity storing or retrieving PASSporTs to be an intermediary for the entity storing or retrieving PASSporTs to be an intermediary
rather than a device associated with either the originating or rather than a device associated with either the originating or
terminating side of a call, and those intermediaries often would not terminating side of a call, and those intermediaries often would not
have access to STIR credentials covering the telephone numbers in have access to STIR credentials covering the telephone numbers in
question. Requiring authorization based on a credential to store question. Requiring authorization based on a credential to store
PASSporTs is therefore undesirable, though potentially acceptable if PASSporTs is therefore undesirable, though potentially acceptable if
sufficient steps are taken to mitigate any privacy risk of leaking sufficient steps are taken to mitigate any privacy risk of leaking
data. data.
It is an explicit design goal of this mechanism to minimize the It is an explicit design goal of this mechanism to minimize the
potential privacy exposure of using a CPS. Ideally, the out-of-band potential privacy exposure of using a CPS. Ideally, the out-of-band
mechanism should not result in a worse privacy situation than in-band mechanism should not result in a worse privacy situation than in-band
[RFC8224] STIR: for in-band, we might say that a SIP entity is [RFC8224] STIR: for in-band, we might say that a SIP entity is
authorized to receive a PASSporT if it is an intermediate or final authorized to receive a PASSporT if it is an intermediate or final
target of the routing of a SIP request. As the originator of a call target of the routing of a SIP request. As the originator of a call
cannot necessarily predict the routing path a call will follow, an cannot necessarily predict the routing path a call will follow, an
out-of-band mechanism could conceivably even improve on the privacy out-of-band mechanism could conceivably even improve on the privacy
story. story.
Broadly, the architecture recommended here thus is one focused on Broadly, the architecture recommended here thus is one focused on
permitting any entity to store encrypted PASSporTs at the CPS, permitting any entity to store encrypted PASSporTs at the CPS,
indexed under the called number. PASSporTs will be encrypted with indexed under the called number. PASSporTs will be encrypted with an
the public key associated with the called number, so these PASSporTs encryption key signed by the public key associated with the called
may safely be retrieved by any entity, as only holders of the number, so these PASSporTs may safely be retrieved by any entity, as
corresponding private key will be able to decrypt the PASSporT. This only holders of the corresponding private key will be able to decrypt
also prevents the CPS itself from learning the contents of PASSporTs, the PASSporT. This also prevents the CPS itself from learning the
and thus metadata about calls in progress, which makes the CPS a less contents of PASSporTs, and thus metadata about calls in progress,
attractive target for pervasive monitoring (see [RFC7258]). As a which makes the CPS a less attractive target for pervasive monitoring
first step, transport-level security can provide confidentiality from (see [RFC7258]). As a first step, transport-level security can
eavesdroppers for both the storage and retrieval of PASSporTs. To provide confidentiality from eavesdroppers for both the storage and
bolster the privacy story, prevent denial-of-service flooding of the retrieval of PASSporTs. To bolster the privacy story, prevent
CPS, and to complicate traffic analysis, a few additional mechanisms denial-of-service flooding of the CPS, and to complicate traffic
are also recommended below. analysis, a few additional mechanisms are also recommended below.
6.1. Storage 6.1. Storage
There are a few dimensions to authorizing the storage of PASSporTs. There are a few dimensions to authorizing the storage of PASSporTs.
Encrypting PASSporTs prior to storage entails that a CPS has no way Encrypting PASSporTs prior to storage entails that a CPS has no way
to tell if a PASSporT is valid; it simply conveys encrypted blocks to tell if a PASSporT is valid; it simply conveys encrypted blocks
that it cannot access itself, and can make no authorization decision that it cannot access itself, and can make no authorization decision
based on the PASSporT contents. There is certainly no prospect for based on the PASSporT contents. There is certainly no prospect for
the CPS to verify the PASSporTs itself. the CPS to verify the PASSporTs itself.
Note that this architecture requires clients that store PASSporTs to Note that this architecture requires clients that store PASSporTs to
have access to a public key associated with the intended called party have access to an encryption key associated with the intended called
to be used to encrypt the PASSporT. Discovering this key requires party to be used to encrypt the PASSporT. Discovering this key
the existence of a key lookup service; depending on how the CPS is requires the existence of a key lookup service (see Section 11);
architected, however, some kind of key store or repository could be depending on how the CPS is architected, however, some kind of key
implemented adjacent to it, and perhaps even incorporated into its store or repository could be implemented adjacent to it, and perhaps
operation. Key discovery is made more complicated by the fact that even incorporated into its operation. Key discovery is made more
there can potentially be multiple entities that have authority over a complicated by the fact that there can potentially be multiple
telephone number: a carrier, a reseller, an enterprise, and an end entities that have authority over a telephone number: a carrier, a
user might all have credentials permitting them to attest that they reseller, an enterprise, and an end user might all have credentials
are allowed to originate calls from a number, say. PASSporTs for permitting them to attest that they are allowed to originate calls
out-of-band use therefore might need to be encrypted with multiple from a number, say. PASSporTs for out-of-band use therefore might
keys in the hopes that one will be decipherable by the relying party. need to be encrypted with multiple keys in the hopes that one will be
decipherable by the relying party.
Again, the most obviously way to authorize storage is to require the Again, the most obvious way to authorize storage is to require the
originator to authenticate themselves to the CPS with their STIR originator to authenticate themselves to the CPS with their STIR
credential. However, since the call is indexed at the CPS under the credential. However, since the call is indexed at the CPS under the
called number, this can weaken the privacy story of the architecture, called number, this can weaken the privacy story of the architecture,
as it reveals to the CPS both the identity of the caller and the as it reveals to the CPS both the identity of the caller and the
callee. Moreover, it does not work for the gateway use cases callee. Moreover, it does not work for the gateway use cases
described above; to support those use cases, we must effectively described above; to support those use cases, we must effectively
allow any entity to store PASSporTs at a CPS. This does not degrade allow any entity to store PASSporTs at a CPS. This does not degrade
the anti-impersonation security of STIR, because entities who do not the anti-impersonation security of STIR, because entities who do not
possess the necessary credentials to sign the PASSporT will not be possess the necessary credentials to sign the PASSporT will not be
able to create PASSporTs that will be treated as valid by verifiers. able to create PASSporTs that will be treated as valid by verifiers.
skipping to change at page 11, line 32 skipping to change at page 11, line 45
calls. calls.
Because the entity placing a call may discover multiple keys Because the entity placing a call may discover multiple keys
associated with the called party number, multiple valid PASSporTs may associated with the called party number, multiple valid PASSporTs may
be stored in the CPS. A particular called party who retrieves be stored in the CPS. A particular called party who retrieves
PASSporTs from the CPS may have access to only one of those keys. PASSporTs from the CPS may have access to only one of those keys.
Thus, the presence of one or more PASSporTs that the called party Thus, the presence of one or more PASSporTs that the called party
cannot decrypt - which would be indistinguishable from the "dummy" cannot decrypt - which would be indistinguishable from the "dummy"
PASSporTS created by the CPS when no calls are in progress - does not PASSporTS created by the CPS when no calls are in progress - does not
entail that there is no call in progress. A retriever likely will entail that there is no call in progress. A retriever likely will
need decrypt all PASSporTs retrieved from the CPS, and may find only need to decrypt all PASSporTs retrieved from the CPS, and may find
one that is valid. only one that is valid.
Note that in out-of-band call forwarding cases, special behavior is Note that in out-of-band call forwarding cases, special behavior is
required to manage the relationship between PASSporTs using the required to manage the relationship between PASSporTs using the
diversion extension [I-D.ietf-stir-passport-divert]. The originating diversion extension [I-D.ietf-stir-passport-divert]. The originating
authentication service would encrypt the initial PASSporT with the authentication service would encrypt the initial PASSporT with the
public key of the intended destination, but once a call is forwarded, public encryption key of the intended destination, but once a call is
it may go to a destination that does not possess the corresponding forwarded, it may go to a destination that does not possess the
private key and thus could not decrypt the original PASSporT. This corresponding private key and thus could not decrypt the original
requires the retargeting entity to generated encrypted PASSporTs that PASSporT. This requires the retargeting entity to generated
show a secure chain of diversion: a retargeting storer SHOULD use the encrypted PASSporTs that show a secure chain of diversion: a
"div-o" PASSporT type, with its "opt" extension, as specified in retargeting storer SHOULD use the "div-o" PASSporT type, with its
[I-D.ietf-stir-passport-divert] in order to nest the original "opt" extension, as specified in [I-D.ietf-stir-passport-divert] in
PASSporT within the encrypted diversion PASSporT. order to nest the original PASSporT within the encrypted diversion
PASSporT.
7. Solution Architecture 7. Solution Architecture
In this section, we discuss a high-level architecture for providing In this section, we discuss a high-level architecture for providing
the service described in the previous sections. This discussion is the service described in the previous sections. This discussion is
deliberately sketchy, focusing on broad concepts and skipping over deliberately sketchy, focusing on broad concepts and skipping over
details. The intent here is merely to provide an overall details. The intent here is merely to provide an overall
architecture, not an implementable specification. A more concrete architecture, not an implementable specification. A more concrete
example of how this might be specified is given in Section 9. example of how this might be specified is given in Section 9.
7.1. Credentials and Phone Numbers 7.1. Credentials and Phone Numbers
We start from the premise of the STIR problem statement [RFC7340] We start from the premise of the STIR problem statement [RFC7340]
that phone numbers can be associated with credentials which can be that phone numbers can be associated with credentials which can be
used to attest ownership of numbers. For purposes of exposition, we used to attest ownership of numbers. For purposes of exposition, we
will assume that ownership is associated with the endpoint (e.g., a will assume that ownership is associated with the endpoint (e.g., a
smartphone) but it might well be associated with a provider or smartphone) but it might well be associated with a provider or
gateway acting for the endpoint instead. It might be the case that gateway acting for the endpoint instead. It might be the case that
multiple entities are able to act for a given number, provided that multiple entities are able to act for a given number, provided that
they have the appropriate authority. [RFC8226] describes a they have the appropriate authority. [RFC8226] describes a
credentials system suitable for this purpose; the question of how an credential system suitable for this purpose; the question of how an
entity is determined to have control of a given number is out of entity is determined to have control of a given number is out of
scope for the current document. scope for the current document.
7.2. Call Flow 7.2. Call Flow
An overview of the basic calling and verification process is shown An overview of the basic calling and verification process is shown
below. In this diagram, we assume that Alice has the number below. In this diagram, we assume that Alice has the number
+1.111.111.1111 and Bob has the number +2.222.222.2222. +1.111.555.1111 and Bob has the number +2.222.555.2222.
Alice Call Placement Service Bob Alice Call Placement Service Bob
--------------------------------------------------------------------
Store PASSporT for 2.222.222.2222--> Store PASSporT for 2.222.555.2222 -->
Call from 1.111.111.1111 ---------------------------------------------> Call from 1.111.555.1111 ------------------------------------------>
<------------- Retrieve PASSporT(s) <-------------- Request PASSporT(s)
for 2.222.222.2222? for 2.222.555.2222
Encrypted PASSporT Obtain Encrypted PASSporT -------->
-(2.222.222.2222,1.111.111.1111)--> (2.222.555.2222, 1.111.555.1111)
[Ring phone with callerid [Ring phone with callerid
= 1.111.111.1111] = 1.111.555.1111]
When Alice wishes to make a call to Bob, she contacts the CPS and When Alice wishes to make a call to Bob, she contacts the CPS and
stores an encrypted PASSporT on the CPS indexed under Bob's number. stores an encrypted PASSporT on the CPS indexed under Bob's number.
The CPS then awaits retrievals for that number. The CPS then awaits retrievals for that number.
Once Alice has stored the PASSporT, she then places the call to Bob Once Alice has stored the PASSporT, she then places the call to Bob
as usual. At this point, Bob's phone would usually ring and display as usual. At this point, Bob's phone would usually ring and display
Alice's number (+1.111.111.1111), which is informed by the existing Alice's number (+1.111.555.1111), which is informed by the existing
PSTN mechanisms for relying a calling party number (i.e., the CIN PSTN mechanisms for relaying a calling party number (i.e., the CIN
field of the IAM). Instead, Bob's phone transparently contacts the field of the IAM). Instead, Bob's phone transparently contacts the
CPS and requests any current PASSporTs for calls to his number. The CPS and requests any current PASSporTs for calls to his number. The
CPS responds with any such PASSporTs (assuming they exist). If such CPS responds with any such PASSporTs (assuming they exist). If such
a PASSporT exists, and the verification service in Bob's phone a PASSporT exists, and the verification service in Bob's phone
decrypts it using his private key, validates it, then Bob's phone can decrypts it using his private key, validates it, then Bob's phone can
present the calling party number information as valid. Otherwise, present the calling party number information as valid. Otherwise,
the call is unverifiable. Note that this does not necessarily mean the call is unverifiable. Note that this does not necessarily mean
that the call is bogus; because we expect incremental deployment, that the call is bogus; because we expect incremental deployment,
many legitimate calls will be unverifiable. many legitimate calls will be unverifiable.
7.3. Security Analysis 7.3. Security Analysis
The primary attack we seek to prevent is an attacker convincing the The primary attack we seek to prevent is an attacker convincing the
callee that a given call is from some other caller C. There are two callee that a given call is from some other caller C. There are two
scenarios to be concerned with: scenarios to be concerned with:
The attacker wishes to impersonate a target when no call from that 1. The attacker wishes to impersonate a target when no call from
target is in progress. that target is in progress.
The attacker wishes to substitute himself for an existing call 2. The attacker wishes to substitute himself for an existing call
setup as described in Section 7.4. setup as described in Section 7.4.
If an attacker can inject fake PASSporT into the CPS or in the If an attacker can inject fake PASSporT into the CPS or in the
communication from the CPS to the callee, he can mount either attack. communication from the CPS to the callee, he can mount either attack.
As PASSporTs should be digitally signed by an appropriate authority As PASSporTs should be digitally signed by an appropriate authority
for the number and verified by the callee (see Section 7.1), this for the number and verified by the callee (see Section 7.1), this
should not arise in ordinary operations. For privacy and robustness should not arise in ordinary operations. For privacy and robustness
reasons, using TLS on the originating side when storing the PASSporT reasons, using TLS [RFC8446] on the originating side when storing the
at the CPS is RECOMMENDED. PASSporT at the CPS is RECOMMENDED.
The entire system depends on the security of the credential The entire system depends on the security of the credential
infrastructure. If the authentication credentials for a given number infrastructure. If the authentication credentials for a given number
are compromised, then an attacker can impersonate calls from that are compromised, then an attacker can impersonate calls from that
number. However, that is no different from in-band [RFC8224] STIR. number. However, that is no different from in-band [RFC8224] STIR.
A secondary attack we must also prevent is denial-of-service against A secondary attack we must also prevent is denial-of-service against
the CPS, which requires some form of rate control solution that will the CPS, which requires some form of rate control solution that will
not degrade the privacy properties of the architecture. not degrade the privacy properties of the architecture.
7.4. Substitution Attacks 7.4. Substitution Attacks
All that receipt of the PASSporT from the CPS proves to the called All that receipt of the PASSporT from the CPS proves to the called
party is that Alice is trying to call Bob (or at least was as of very party is that Alice is trying to call Bob (or at least was as of very
recently) - it does not prove that any particular incoming call is recently) - it does not prove that any particular incoming call is
from Alice. Consider the scenario in which we have a service which from Alice. Consider the scenario in which we have a service which
provides an automatic callback to a user-provided number. In that provides an automatic callback to a user-provided number. In that
case, the attacker can try to arrange for a false caller-id value, as case, the attacker can try to arrange for a false caller-id value, as
shown below: shown below:
Attacker Callback Service CPS Bob Attacker Callback Service CPS Bob
----------------------------------------------------------------------- --------------------------------------------------------------------
Place call to Bob ----------> Place call to Bob ---------->
Store PASSporT for Store PASSporT for
CS:Bob --------------> CS:Bob ------------->
Call from CS (forged caller-id info) --------------------------------> Call from CS (forged caller-id info) ----------------------------->
Call from CS ---------------------------> X Call from CS ------------------------> X
<----- Retrieve PASSporT <-- Retrieve PASSporT
for CS:Bob for CS:Bob
PASSporT for CS:Bob ---------------------------> PASSporT for CS:Bob ------------------------>
[Ring phone with callerid = CS] [Ring phone with callerid =
111.555.1111]
In order to mount this attack, the attacker contacts the Callback In order to mount this attack, the attacker contacts the Callback
Service (CS) and provides it with Bob's number. This causes the CS Service (CS) and provides it with Bob's number. This causes the CS
to initiate a call to Bob. As before, the CS contacts the CPS to to initiate a call to Bob. As before, the CS contacts the CPS to
insert an appropriate PASSporT and then initiates a call to Bob. insert an appropriate PASSporT and then initiates a call to Bob.
Because it is a valid CS injecting the PASSporT, none of the security Because it is a valid CS injecting the PASSporT, none of the security
checks mentioned above help. However, the attacker simultaneously checks mentioned above help. However, the attacker simultaneously
initiates a call to Bob using forged caller-id information initiates a call to Bob using forged caller-id information
corresponding to the CS. If he wins the race with the CS, then Bob's corresponding to the CS. If he wins the race with the CS, then Bob's
phone will attempt to verify the attacker's call (and succeed since phone will attempt to verify the attacker's call (and succeed since
they are indistinguishable) and the CS's call will go to busy/voice they are indistinguishable) and the CS's call will go to busy/voice
mail/call waiting. Note: in a SIP environment, the callee might mail/call waiting. Note: in a SIP environment, the callee might
notice that there were multiple INVITEs and thus detect this attack. notice that there were multiple INVITEs and thus detect this attack.
7.5. Rate Control for CPS Storage 7.5. Rate Control for CPS Storage
In order to prevent the flooding of a CPS with bogus PASSporTs, we In order to prevent the flooding of a CPS with bogus PASSporTs, we
propose the use of "blind signatures". A sender will initially propose the use of "blind signatures" (see [RFC5636]). A sender will
authenticate to the CPS using its STIR credentials, and acquire a initially authenticate to the CPS using its STIR credentials, and
signed token from the CPS that will be presented later when storing a acquire a signed token from the CPS that will be presented later when
PASSporT. The flow looks as follows: storing a PASSporT. The flow looks as follows:
Sender CPS Sender CPS
Authenticate to CPS ---------------------> Authenticate to CPS --------------------->
Blinded(K_temp) -------------------------> Blinded(K_temp) ------------------------->
<------------- Sign(K_cps, Blinded(K_temp)) <------------- Sign(K_cps, Blinded(K_temp))
[Disconnect] [Disconnect]
Sign(K_cps, K_temp)) Sign(K_cps, K_temp)
Sign(K_temp, E(K_receiver, PASSporT)) ---> Sign(K_temp, E(K_receiver, PASSporT)) --->
At an initial time when no call is yet in progress, a potential At an initial time when no call is yet in progress, a potential
client connects to the CPS, authenticates, and sends a blinded client connects to the CPS, authenticates, and sends a blinded
version of a freshly generated public key. The CPS returns a signed version of a freshly generated public key. The CPS returns a signed
version of that blinded key. The sender can then unblind the key and version of that blinded key. The sender can then unblind the key and
gets a signature on K_temp from the CPS. gets a signature on K_temp from the CPS.
Then later, when a client wants to store a PASSporT, it connects to Then later, when a client wants to store a PASSporT, it connects to
the CPS anonymously (preferably over a network connection that cannot the CPS anonymously (preferably over a network connection that cannot
skipping to change at page 15, line 40 skipping to change at page 16, line 13
policy might reject storage attempts and require acquisition of a new policy might reject storage attempts and require acquisition of a new
K_temp after storing more than a certain number of PASSporTs indexed K_temp after storing more than a certain number of PASSporTs indexed
under the same destination number in a short interval. This does not under the same destination number in a short interval. This does not
of course allow the CPS to tell when bogus data is being provisioned of course allow the CPS to tell when bogus data is being provisioned
by an attacker, simply the rate at which data is being provisioned. by an attacker, simply the rate at which data is being provisioned.
Potentially, feedback mechanisms could be developed that would allow Potentially, feedback mechanisms could be developed that would allow
the called parties to tell the CPS when they are receiving unusual or the called parties to tell the CPS when they are receiving unusual or
bogus PASSporTs. bogus PASSporTs.
This architecture also assumes that the CPS will age out PASSporTs. This architecture also assumes that the CPS will age out PASSporTs.
A CPS SHOULD NOT keep any stored PASSporT for more than sixty A CPS SHOULD NOT keep any stored PASSporT for no longer than a value
seconds. Any reduction in this window makes substitution attacks that might be selected for the verification service policy for
(see Section 7.4) harder to mount, but making the window too small freshness of the "iat" value as described in [RFC8226]. Any
might conceivably age PASSporTs out while a heavily redirected call reduction in this window makes substitution attacks (see Section 7.4)
is still alerting. harder to mount, but making the window too small might conceivably
age PASSporTs out while a heavily redirected call is still alerting.
8. Authentication and Verification Service Behavior for Out-of-Band 8. Authentication and Verification Service Behavior for Out-of-Band
[RFC8224] defines an authentication service and a verification [RFC8224] defines an authentication service and a verification
service as functions that act in the context of SIP requests and service as functions that act in the context of SIP requests and
responses. This specification thus provides a more generic responses. This specification thus provides a more generic
description of authentication service and verification service description of authentication service and verification service
behavior that might or might not involve any SIP transactions, but behavior that might or might not involve any SIP transactions, but
depends only on placing a request for communications from an depends only on placing a request for communications from an
originating identity to one or more destination identities. originating identity to one or more destination identities.
skipping to change at page 16, line 30 skipping to change at page 17, line 4
associated with a STIR certificate [RFC8225]. associated with a STIR certificate [RFC8225].
Step 2: The authentication service MUST determine that the originator Step 2: The authentication service MUST determine that the originator
of communications can claim the originating identity. This is a of communications can claim the originating identity. This is a
policy decision made by the authentication service that depends on policy decision made by the authentication service that depends on
its relationship to the originator. For an out-of-band application its relationship to the originator. For an out-of-band application
built-in to the calling device, for example, this is the same check built-in to the calling device, for example, this is the same check
performed in Step 1: does the calling device hold a private key, one performed in Step 1: does the calling device hold a private key, one
corresponding to a STIR certificate, that can sign for the corresponding to a STIR certificate, that can sign for the
originating identity? originating identity?
Step 3: The authentication service MUST acquire the public encryption
Step 3: The authentication service MUST acquire the public key of the key of the destination, which will be used to encrypt the PASSporT
destination, which will be used to encrypt the PASSporT. It MUST (see Section 11). It MUST also discover (see Section 10) the CPS
also discover (see Section 10) the CPS associated with the associated with the destination. The authentication service may
destination. The authentication service may already have the key and already have the encryption key and destination CPS cached, or may
destination CPS cached, or may need to query a service to acquire the need to query a service to acquire the key. Note that per
key. Note that per Section 7.5 the authentication service may also Section 7.5 the authentication service may also need to acquire a
need to acquire a token for PASSporT storage from the CPS upon CPS token for PASSporT storage from the CPS upon CPS discovery. It is
discovery. It is anticipated that the discovery mechanism (see anticipated that the discovery mechanism (see Section 10) used to
Section 10) used to find the appropriate CPS will also find the find the appropriate CPS will also find the proper key server for the
proper key server for the public key of the destination. In some public key of the destination. In some cases, a destination may have
cases, a destination may have multiple public keys associated with multiple public encryption keys associated with it. In that case,
it. In that case, the authentication service MUST collect all of the authentication service MUST collect all of those keys.
those keys.
Step 4: The authentication service MUST create the PASSporT object. Step 4: The authentication service MUST create the PASSporT object.
This includes acquiring the system time to populate the "iat" claim, This includes acquiring the system time to populate the "iat" claim,
and populating the "orig" and "dest" claims as described in and populating the "orig" and "dest" claims as described in
[RFC8225]. The authentication service MUST then encrypt the [RFC8225]. The authentication service MUST then encrypt the
PASSporT. If in Step 3 the authentication service discovered PASSporT. If in Step 3 the authentication service discovered
multiple public keys for the destination, it MUST create one multiple public keys for the destination, it MUST create one
encrypted copy for each public key it discovered. encrypted copy for each public key it discovered.
Finally, the authentication service stores the encrypted PASSporT(s) Finally, the authentication service stores the encrypted PASSporT(s)
skipping to change at page 19, line 6 skipping to change at page 19, line 27
here which uses a REST API to store and retrieve objects at the CPS. here which uses a REST API to store and retrieve objects at the CPS.
The calling party stores the PASSporT at the CPS prior to initiating The calling party stores the PASSporT at the CPS prior to initiating
the call; the PASSporT is stored at a location at the CPS that the call; the PASSporT is stored at a location at the CPS that
corresponds to the called number. Note that it is possible for corresponds to the called number. Note that it is possible for
multiple parties to be calling a number at the same time, and that multiple parties to be calling a number at the same time, and that
for called numbers such as large call centers, many PASSporTs could for called numbers such as large call centers, many PASSporTs could
legitimately be stored simultaneously, and it might prove difficult legitimately be stored simultaneously, and it might prove difficult
to correlate these with incoming calls. to correlate these with incoming calls.
Assume that an authentication service has created the following Assume that an authentication service has created the following
PASSporT for a call to the telephone number 2.222.222.2222 (note that PASSporT for a call to the telephone number 2.222.555.2222 (note that
these are dummy values): these are dummy values):
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz
aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI
jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1
VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w
Through some discovery mechanism (see Section 10), the authentication Through some discovery mechanism (see Section 10), the authentication
service discovers the network location of a web service that acts as service discovers the network location of a web service that acts as
the CPS for 2.222.222.2222. Through the same mechanism, we will say the CPS for 2.222.555.2222. Through the same mechanism, we will say
that it has also discovered one public key for that destination. It that it has also discovered one public encryption key for that
uses that public key to encrypt the PASSporT, resulting in the destination. It uses that encryption key to encrypt the PASSporT,
encrypted PASSporT: resulting in the encrypted PASSporT:
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
Having concluded the numbered steps in Section 8.1, including Having concluded the numbered steps in Section 8.1, including
acquiring any token (per Section 6.1) needed to store the PASSporT at acquiring any token (per Section 6.1) needed to store the PASSporT at
the CPS, the authentication service then stores the encrypted the CPS, the authentication service then stores the encrypted
PASSporT: PASSporT:
POST /cps/2.222.222.2222/ppts HTTP/1.1 POST /cps/2.222.555.2222/ppts HTTP/1.1
Host: cps.example.com Host: cps.example.com
Content-Type: application/passport Content-Type: application/passport
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
The web service assigns a new location for this encrypted PASSporT in The web service assigns a new location for this encrypted PASSporT in
the collection, returning a 201 OK with the location of the collection, returning a 201 OK with the location of
/cps/2.222.222.2222/ppts/ppt1. Now the authentication service can /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can
place the call, which may be signaled by various protocols. Once the place the call, which may be signaled by various protocols. Once the
call arrives at the terminating side, a verification service contacts call arrives at the terminating side, a verification service contacts
its CPS to ask for the set of incoming calls for its telephone number its CPS to ask for the set of incoming calls for its telephone number
(2.222.222.2222). (2.222.222.2222).
GET /cps/2.222.222.2222/ppts GET /cps/2.222.555.2222/ppts
Host: cps.example.com Host: cps.example.com
This returns to the verification service a list of the PASSporTs This returns to the verification service a list of the PASSporTs
currently in the collection, which currently consists of only currently in the collection, which currently consists of only
/cps/2.222.222.2222/ppts/ppt1. The verification service then sends a /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a
new GET for /cps/2.222.222.2222/ppts/ppt1/ which yields: new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/passport Content-Type: application/passport
Link: <https://cps.example.com/cps/2.222.222.2222/ppts> Link: <https://cps.example.com/cps/2.222.555.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
That concludes Step 1 of Section 8.2; the verification service then That concludes Step 1 of Section 8.2; the verification service then
goes on to the next step, processing that PASSporT through its goes on to the next step, processing that PASSporT through its
various checks. A complete protocol description for CPS interactions various checks. A complete protocol description for CPS interactions
skipping to change at page 21, line 21 skipping to change at page 21, line 49
There exist a number of common directory systems that might be There exist a number of common directory systems that might be
used to translate telephone numbers into the URIs of a CPS. ENUM used to translate telephone numbers into the URIs of a CPS. ENUM
[RFC6116] is commonly implemented, though no "golden root" central [RFC6116] is commonly implemented, though no "golden root" central
ENUM administration exists that could be easily reused today to ENUM administration exists that could be easily reused today to
help the endpoints discover a common CPS. Other protocols help the endpoints discover a common CPS. Other protocols
associated with queries for telephone numbers, such as the TeRI associated with queries for telephone numbers, such as the TeRI
[I-D.ietf-modern-teri] protocol, could also serve for this [I-D.ietf-modern-teri] protocol, could also serve for this
application. application.
Another possibility is to use a single distributed service for Another possibility is to use a single distributed service for
this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] this function. VIPR [I-D.jennings-vipr-overview] proposed a
proposed a RELOAD [RFC6940] usage for telephone numbers to help RELOAD [RFC6940] usage for telephone numbers to help direct calls
direct calls to enterprises on the Internet. It would be possible to enterprises on the Internet. It would be possible to describe
to describe a similar RELOAD usage to identify the CPS where calls a similar RELOAD usage to identify the CPS where calls for a
for a particular telephone number should be stored. One advantage particular telephone number should be stored. One advantage that
that the STIR architecture has over VIPR is that it assumes a the STIR architecture has over VIPR is that it assumes a
credential system that proves authority over telephone numbers; credential system that proves authority over telephone numbers;
those credentials could be used to determine whether or not a CPS those credentials could be used to determine whether or not a CPS
could legitimately claim to be the proper store for a given could legitimately claim to be the proper store for a given
telephone number. telephone number.
This document does not prescribe any single way to do service This document does not prescribe any single way to do service
discovery for a CPS; it is envisioned that initial deployments will discovery for a CPS; it is envisioned that initial deployments will
provision the location of the CPS at the AS and VS. provision the location of the CPS at the AS and VS.
11. Credential Lookup 11. Encryption Key Lookup
In order to encrypt a PASSporT (see Section 6.1), the caller needs In order to encrypt a PASSporT (see Section 6.1), the caller needs
access to the callee's credentials (specifically their public key). access to the callee's public encryption key. Note that because STIR
This requires some sort of directory/lookup system. Some initial uses ECDSA for signing PASSporTs, the public key used to verify
STIR deployments have fielded certificate repositories so that PASSporTs is not suitable for this function, and thus the encryption
verification services can acquire the signing credentials for key must be discovered separately. This requires some sort of
directory/lookup system.
Some initial STIR deployments have fielded certificate repositories
so that verification services can acquire the signing credentials for
PASSporTs, which are linked through a URI in the "x5u" element of the PASSporTs, which are linked through a URI in the "x5u" element of the
PASSporT. These certificate repositories could clearly be repurposed PASSporT. These certificate repositories could clearly be repurposed
for allowing authentication services to download the credentials for for allowing authentication services to download the public
the called party - provided they can be discovered by calling encryption key for the called party - provided they can be discovered
parties. This document does not specify any particular discovery by calling parties. This document does not specify any particular
scheme, but a list of requirements and considerations would be discovery scheme, but instead offers some general guidance about
something like: potential approaches.
Obviously, if there is a single central database and the caller and It is a desirable property that the public encryption key for a given
callee each contact it in real time to determine the other's party be linked to their STIR credential. We therefore propose that
credentials, then this represents a real privacy risk, as the central an ECDH [RFC7748] public-private key pair be generated for a subcert
database learns about each call. A number of mechanisms are [I-D.ietf-tls-subcerts] of the STIR credential. That subcert could
potentially available to mitigate this: be looked up along with the STIR credential of the called party.
Further details of this subcert, and the exact lookup mechanism
involved, are deferred for future protocol work.
Have endpoints pre-fetch credentials for potential counterparties Obviously, if there is a single central database that the caller and
(e.g., their address book or the entire database). callee each access in real time to download the other's keys, then
this represents a real privacy risk, as the central key database
learns about each call. A number of mechanisms are potentially
available to mitigate this:
Have endpoints pre-fetch keys for potential counterparties (e.g.,
their address book or the entire database).
Have caching servers in the user's network that proxy their Have caching servers in the user's network that proxy their
fetches and thus conceal the relationship between the user and the fetches and thus conceal the relationship between the user and the
credentials they are fetching. keys they are fetching.
Clearly, there is a privacy/timeliness tradeoff in that getting up- Clearly, there is a privacy/timeliness tradeoff in that getting up-
to-date knowledge about credential validity requires contacting the to-date knowledge about credential validity requires contacting the
credential directory in real-time (e.g., via OCSP). This is somewhat credential directory in real-time (e.g., via OCSP [RFC2560]). This
mitigated for the caller's credentials in that he can get short-term is somewhat mitigated for the caller's credentials in that he can get
credentials right before placing a call which only reveals his short-term credentials right before placing a call which only reveals
calling rate, but not who he is calling. Alternately, the CPS can his calling rate, but not who he is calling. Alternately, the CPS
verify the caller's credentials via OCSP, though of course this can verify the caller's credentials via OCSP, though of course this
requires the callee to trust the CPS's verification. This approach requires the callee to trust the CPS's verification. This approach
does not work as well for the callee's credentials, but the risk does not work as well for the callee's credentials, but the risk
there is more modest since an attacker would need to both have the there is more modest since an attacker would need to both have the
callee's credentials and regularly poll the database for every callee's credentials and regularly poll the database for every
potential caller. potential caller.
We consider the exact best point in the tradeoff space to be an open We consider the exact best point in the tradeoff space to be an open
issue. issue.
12. Acknowledgments 12. Acknowledgments
The ideas in this document come out of discussions with Richard The ideas in this document come out of discussions with Richard
Barnes and Cullen Jennings. We'd also like to thank Jonathan Barnes and Cullen Jennings. We'd also like to thank Russ Housley,
Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Jonathan
Rosenberg and Robert Sparks for helpful suggestions. Rosenberg and Robert Sparks for helpful suggestions.
13. IANA Considerations 13. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
14. Security Considerations 14. Security Considerations
This entire document is about security, but the detailed security This entire document is about security, but the detailed security
properties depend on having a single concrete scheme to analyze. properties will vary depending on how the framework is applied and
deployed. General guidance for dealing with the most obvious
security challenges posed by this framework is given in Section 7.3
and Section 7.4, along proposed solutions for problems like denial-
of-service attacks or traffic analysis against the CPS.
Although there are considerable security challenges associated with
widespread deployment of a public CPS, those must be weighed against
the potential usefulness of a service that delivers a STIR assurance
without requiring the passage of end-to-end SIP.
15. Informative References 15. Informative References
[I-D.ietf-modern-teri] [I-D.ietf-modern-teri]
Peterson, J., "An Architecture and Information Model for Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-ietf-modern- Telephone-Related Information (TeRI)", draft-ietf-modern-
teri-00 (work in progress), July 2018. teri-00 (work in progress), July 2018.
[I-D.ietf-stir-passport-divert] [I-D.ietf-stir-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls", Peterson, J., "PASSporT Extension for Diverted Calls",
draft-ietf-stir-passport-divert-05 (work in progress), draft-ietf-stir-passport-divert-05 (work in progress),
February 2019. February 2019.
[I-D.rosenberg-dispatch-vipr-overview] [I-D.ietf-tls-subcerts]
Rosenberg, J., Jennings, C., and M. Petit-Huguenin, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Verification Involving PSTN Reachability: Requirements "Delegated Credentials for TLS", draft-ietf-tls-
and Architecture Overview", draft-rosenberg-dispatch-vipr- subcerts-03 (work in progress), February 2019.
overview-04 (work in progress), October 2010.
[I-D.jennings-vipr-overview]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013.
[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>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>.
[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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent,
"Traceable Anonymous Certificate", RFC 5636,
DOI 10.17487/RFC5636, August 2009,
<https://www.rfc-editor.org/info/rfc5636>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011, DOI 10.17487/RFC6116, March 2011,
<https://www.rfc-editor.org/info/rfc6116>. <https://www.rfc-editor.org/info/rfc6116>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S.,
and H. Schulzrinne, "REsource LOcation And Discovery and H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940,
January 2014, <https://www.rfc-editor.org/info/rfc6940>. January 2014, <https://www.rfc-editor.org/info/rfc6940>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[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>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
Mozilla Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
 End of changes. 78 change blocks. 
218 lines changed or deleted 288 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/