draft-ietf-stir-oob-06.txt   draft-ietf-stir-oob-07.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: May 7, 2020 Neustar Expires: September 10, 2020 Neustar
November 4, 2019 March 9, 2020
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-06 draft-ietf-stir-oob-07
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, or cannot reliably deliver SIP header fields end-to-end. This path, or cannot reliably deliver SIP header fields end-to-end. This
document describes use cases that require the delivery of PASSporT document describes use cases that require the delivery of PASSporT
objects outside of the signaling path, and defines architectures and objects outside of the signaling path, and defines architectures and
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 May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 9 5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14
7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 15 7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 16
8. Authentication and Verification Service Behavior for Out-of- 8. Authentication and Verification Service Behavior for Out-of-
Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Authentication Service . . . . . . . . . . . . . . . . . 16 8.1. Authentication Service (AS) . . . . . . . . . . . . . . . 17
8.2. Verification Service . . . . . . . . . . . . . . . . . . 18 8.2. Verification Service (VS) . . . . . . . . . . . . . . . . 18
8.3. Gateway Placement Services . . . . . . . . . . . . . . . 19 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 19
9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 19 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 20
10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 22 11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
15. Informative References . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 16. Informative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 a SIP Identity header impersonation. For example, [RFC8224] defines a SIP Identity header
skipping to change at page 3, line 39 skipping to change at page 3, line 40
an in-band authentication system. As such, those devices largely an in-band authentication system. As such, those devices largely
cannot be modified to pass signatures originating on the Internet--or cannot be modified to pass signatures originating on the Internet--or
indeed any inband signaling data--intact. Even if fields for indeed any inband signaling data--intact. Even if fields for
tunneling arbitrary data can be found in traditional PSTN signaling, tunneling arbitrary data can be found in traditional PSTN signaling,
in some cases legacy elements would strip the signatures from those in some cases legacy elements would strip the signatures from those
fields; in others, they might damage them to the point where they fields; in others, they might damage them to the point where they
cannot be verified. For those first two categories above, any in- cannot be verified. For those first two categories above, any in-
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 While the core network of the PSTN remains fixed, the endpoints of
of the telephone network are becoming increasingly programmable and 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; they may be used for residential, mobile, or access to the PSTN; they may be used for residential, mobile, or
enterprise telephone services. Additionally, various kinds of enterprise telephone services. Additionally, various kinds of
gateways increasingly front for deployments of legacy PBX and PSTN gateways increasingly front for deployments of legacy PBX and PSTN
switches. All of this provides a potential avenue for building an 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.
Then techniques described in this document therefore build on the The techniques described in this document therefore build on the
PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a
way that a PASSporT object created in the originating network of a way that a PASSporT object created in the originating network of a
call can reach the terminating network even when it cannot be carried call can reach the terminating network even when it cannot be carried
end-to-end in-band in the call signaling. This relies on a new end-to-end in-band in the call signaling. This relies on a new
service defined in this document called a Call Placement Service service defined in this document called a Call Placement Service
(CPS) that permits the PASSporT object to be stored during call (CPS) that permits the PASSporT object to be stored during call
processing and retrieved for verification purposes. processing and retrieved for verification purposes.
Potential implementors should note that this document merely defines Potential implementors should note that this document merely defines
the operating environments in which this out-of-band STIR mechanism the operating environments in which this out-of-band STIR mechanism
skipping to change at page 6, line 15 skipping to change at page 6, line 18
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 CPSes could be run by a carrier, as repositories for or more CPSes could be run by a carrier, as repositories for
PASSporTs for calls sent to its customers, or a CPS could be built-in PASSporTs for calls sent to its customers, or a CPS could be built-in
to an enterprise PBX, or even a smartphone. To the degree possible, to an enterprise PBX, or even a smartphone. To the degree possible,
it is here specified generically, as an idea that may have it is specified here generically, as an idea that may have
applicability to 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:
1. 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, or, which immediately forwards it to the callee, or,
2. 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 placement. When the callee receives the call, it contacts the
skipping to change at page 7, line 19 skipping to change at page 7, line 22
A call originates in a SIP environment 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 (per the practices of
as a fallback in case SIP signaling will not reach end-to-end. When Section 10) for the target telephone number as a fallback in case SIP
the destination mobile smartphone receives the call over the PSTN, it signaling will not reach end-to-end. When the destination mobile
consults the CPS and discovers a PASSporT from the originating smartphone receives the call over the PSTN, it consults the CPS and
telephone number waiting for it. It uses this PASSporT to verify the discovers a PASSporT from the originating telephone number waiting
calling party number. for it. It uses this PASSporT to verify the 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, which communicates through access and a built-in gateway to the PSTN, which communicates through
traditional telephone signaling protocols. The PBX immediately traditional telephone signaling protocols. The PBX immediately
routes the call to the PSTN, but before it does, it provisions a routes the call to the PSTN, but before it does, it provisions a
PASSporT on the CPS associated with the target telephone number. PASSporT on 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
skipping to change at page 10, line 9 skipping to change at page 10, line 9
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 an indexed under the called number. PASSporTs will be encrypted with a
encryption key signed by the public key associated with the called public key associated with the called number, so these PASSporTs may
number, so these PASSporTs may safely be retrieved by any entity, as safely be retrieved by any entity, as only holders of the
only holders of the corresponding private key will be able to decrypt corresponding private key will be able to decrypt the PASSporT. This
the PASSporT. This also prevents the CPS itself from learning the also prevents the CPS itself from learning the contents of PASSporTs,
contents of PASSporTs, and thus metadata about calls in progress, and thus metadata about calls in progress, which makes the CPS a less
which makes the CPS a less attractive target for pervasive monitoring attractive target for pervasive monitoring (see [RFC7258]). As a
(see [RFC7258]). As a first step, transport-level security can first step, transport-level security can provide confidentiality from
provide confidentiality from eavesdroppers for both the storage and eavesdroppers for both the storing and retrieval of PASSporTs. To
retrieval of PASSporTs. To bolster the privacy story, prevent bolster the privacy story, prevent denial-of-service flooding of the
denial-of-service flooding of the CPS, and to complicate traffic CPS, and to complicate traffic analysis, a few additional mechanisms
analysis, a few additional mechanisms are also recommended below. 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.
skipping to change at page 11, line 41 skipping to change at page 11, line 41
As PASSporTs stored at the CPS are encrypted with a key belonging to As PASSporTs stored at the CPS are encrypted with a key belonging to
the intended destination, the CPS can safely allow anyone to download the intended destination, the CPS can safely allow anyone to download
PASSporTs for a called number without much fear of compromising PASSporTs for a called number without much fear of compromising
private information about calls in progress - provided that the CPS private information about calls in progress - provided that the CPS
always returns at least one encrypted blob in response to a request, always returns at least one encrypted blob in response to a request,
even if there was no call in progress. Otherwise, entities could even if there was no call in progress. Otherwise, entities could
poll the CPS constantly, or eavesdrop on traffic, to learn whether or poll the CPS constantly, or eavesdrop on traffic, to learn whether or
not calls were in progress. The CPS MUST generate at least one not calls were in progress. The CPS MUST generate at least one
unique and plausible encrypted response to all retrieval requests, unique and plausible encrypted response to all retrieval requests,
and these dummy encrypted PASSporTs MUST NOT be repeated for later and these dummy encrypted PASSporTs MUST NOT be repeated for later
calls. calls. An encryption scheme needs to be carefully chosen to make
messages look indistinguishable from random when encrypted, so that
information about called party is not discoverable from legitimate
encrypted PASSporTs.
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 to decrypt all PASSporTs retrieved from the CPS, and may find need to decrypt all PASSporTs retrieved from the CPS, and may find
only one that is valid. only one that is valid.
In order to prevent the CPS from learning the numbers that a callee
controls, callees might also request PASSporTs for numbers that they
do not own, that they have no hope of decrypting. Implementations
could even allow a callee to request PASSporTs for a range or prefix
of numbers: a trade-off where that callee is willing to sift through
bulk quantities of undecryptable PASSporTs for the sake of hiding
from the CPS what numbers it controls.
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 encryption key of the intended destination, but once a call is public encryption key of the intended destination, but once a call is
forwarded, it may go to a destination that does not possess the forwarded, it may go to a destination that does not possess the
corresponding private key and thus could not decrypt the original corresponding private key and thus could not decrypt the original
PASSporT. This requires the retargeting entity to generate encrypted PASSporT. This requires the retargeting entity to generate encrypted
PASSporTs that show a secure chain of diversion: a retargeting storer PASSporTs that show a secure chain of diversion: a retargeting storer
SHOULD use the "div-o" PASSporT type, with its "opt" extension, as SHOULD use the "div-o" PASSporT type, with its "opt" extension, as
skipping to change at page 13, line 8 skipping to change at page 13, line 14
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.555.1111 and Bob has the number +2.222.555.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.555.2222 --> Store Encrhypted PASSporT for 2.222.555.2222 ->
Call from 1.111.555.1111 ------------------------------------------> Call from 1.111.555.1111 ------------------------------------------>
<-------------- Request PASSporT(s) <-------------- Request PASSporT(s)
for 2.222.555.2222 for 2.222.555.2222
Obtain Encrypted PASSporT --------> Obtain Encrypted PASSporT -------->
(2.222.555.2222, 1.111.555.1111) (2.222.555.2222, 1.111.555.1111)
[Ring phone with callerid [Ring phone with verified callerid
= 1.111.555.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.
When Alice places the call, Bob's phone would usually ring and When Alice places the call, Bob's phone would usually ring and
display Alice's number (+1.111.555.1111), which is informed by the display Alice's number (+1.111.555.1111), which is informed by the
existing PSTN mechanisms for relaying a calling party number (e.g., existing PSTN mechanisms for relaying a calling party number (e.g.,
the CIN field of the IAM). Instead, Bob's phone transparently the CIN field of the IAM). Instead, Bob's phone transparently
contacts the CPS and requests any current PASSporTs for calls to his contacts the CPS and requests any current PASSporTs for calls to his
number. The CPS responds with any such PASSporTs (assuming they number. The CPS responds with any such PASSporTs (or dummy PASSporTs
exist). If such a PASSporT exists, and the verification service in if no relevant ones are currently stored). If such a PASSporT
Bob's phone decrypts it using his private key, validates it, then exists, and the verification service in Bob's phone decrypts it using
Bob's phone can present the calling party number information as his private key, validates it, then Bob's phone can present the
valid. Otherwise, the call is unverifiable. Note that this does not calling party number information as valid. Otherwise, the call is
necessarily mean that the call is bogus; because we expect unverifiable. Note that this does not necessarily mean that the call
incremental deployment, many legitimate calls will be unverifiable. is bogus; because we expect incremental deployment, 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:
1. The attacker wishes to impersonate a target when no call from 1. The attacker wishes to impersonate a target when no call from
that target is in progress. that target is in progress.
2. 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.
If an attacker can inject fake PASSporT into the CPS or in the If an attacker can inject fake PASSporTs 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. Any attacker who is aware
of calls in progress can attempt to mount a race to subtitute
themselves as described in Section 7.4. For privacy and robustness
reasons, using TLS [RFC8446] on the originating side when storing the reasons, using TLS [RFC8446] on the originating side when storing the
PASSporT 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 the 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 ---------->
(from 111.555.1111)
Store PASSporT for Store PASSporT for
CS:Bob -------------> CS:Bob ------------->
Call from CS (forged caller-id info) -----------------------------> Call from Attacker (forged CS 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 = [Ring phone with callerid =
111.555.1111] 111.555.1111]
skipping to change at page 15, line 16 skipping to change at page 15, line 39
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. mail/call waiting.
In order to prevent a passive attacker from using traffic analysis or In order to prevent a passive attacker from using traffic analysis or
similar means to learn precisely when a call is placed, it is similar means to learn precisely when a call is placed, it is
essential that the connection between the caller and the CPS be essential that the connection between the caller and the CPS be
encrypted as recommended above. Callers could store dummy PASSporTs encrypted as recommended above. Authentication services could store
at the CPS at random intervals in order to make it more difficult for dummy PASSporTs at the CPS at random intervals in order to make it
an eavesdropper to use traffic analysis to determine that a call was more difficult for an eavesdropper to use traffic analysis to
about to be placed. determine that a call was about to be placed.
Note that in a SIP environment, the callee might notice that there Note that in a SIP environment, the callee might notice that there
were multiple INVITEs and thus detect this attack, but in some PSTN were multiple INVITEs and thus detect this attack, but in some PSTN
interworking scenarios, or highly intermediated networks, only one interworking scenarios, or highly intermediated networks, only one
call setup attempt will reach the target. Also note that the success call setup attempt will reach the target. Also note that the success
of this substitution attack depends on the attacker landing their of this substitution attack depends on the attacker landing their
call within the narrow window that the PASSporT is retained in the call within the narrow window that the PASSporT is retained in the
CPS, so shortening that window will reduce the opportunity for the CPS, so shortening that window will reduce the opportunity for the
attack. Finally, smart endpoints could implement some sort of state attack. Finally, smart endpoints could implement some sort of state
coordination to ensure that both sides believe the call is in coordination to ensure that both sides believe the call is in
skipping to change at page 16, line 32 skipping to change at page 17, line 8
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 no longer than a value A CPS SHOULD NOT keep any stored PASSporT for no longer than a value
that might be selected for the verification service policy for that might be selected for the verification service policy for
freshness of the "iat" value as described in [RFC8226]. Any freshness of the "iat" value as described in [RFC8224] (i.e. sixty
reduction in this window makes substitution attacks (see Section 7.4) seconds). Any reduction in this window makes substitution attacks
harder to mount, but making the window too small might conceivably (see Section 7.4) harder to mount, but making the window too small
age PASSporTs out while a heavily redirected call is still alerting. might conceivably age PASSporTs out while a heavily redirected call
is still alerting.
An alternative potential approach to blind signatures would be the
use of oblivious pseudorandom functions (VOPRFs, per
[I-D.privacy-pass]), which move prove faster.
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.
8.1. Authentication Service 8.1. Authentication Service (AS)
Out-of-band authentication services perform steps similar to those Out-of-band authentication services perform steps similar to those
defined in [RFC8224] with some exceptions: defined in [RFC8224] with some exceptions:
Step 1: The authentication service MUST determine whether it is Step 1: The authentication service MUST determine whether it is
authoritative for the identity of the originator of the request, that authoritative for the identity of the originator of the request, that
is, the identity it will populate in the "orig" claim of the is, the identity it will populate in the "orig" claim of the
PASSporT. It can do so only if it possesses the private key of one PASSporT. It can do so only if it possesses the private key of one
or more credentials that can be used to sign for that identity, be it or more credentials that can be used to sign for that identity, be it
a domain or a telephone number or some other identifier. For a domain or a telephone number or some other identifier. For
skipping to change at page 18, line 4 skipping to change at page 18, line 32
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)
at the CPS discovered in Step 3. Only after that is completed should at the CPS discovered in Step 3. Only after that is completed should
any call be initiated. Note that a call might be initiated over SIP, any call be initiated. Note that a call might be initiated over SIP,
and the authentication service would place the same PASSporT in the and the authentication service would place the same PASSporT in the
Identity header field value of the SIP request - though SIP would Identity header field value of the SIP request - though SIP would
carry a cleartext version rather than an encrypted version sent to carry a cleartext version rather than an encrypted version sent to
the CPS. In that case, out-of-band would serve as a fallback the CPS. In that case, out-of-band would serve as a fallback
mechanism in case the request was not conveyed over SIP end-to-end. mechanism in case the request was not conveyed over SIP end-to-end.
Also, note that the authentication service MAY use a compact form of Also, note that the authentication service MAY use a compact form of
the PASSporT for a SIP request, whereas the version stored at the CPS the PASSporT for a SIP request, whereas the version stored at the CPS
MUST always be a full form PASSporT. MUST always be a full form PASSporT.
8.2. Verification Service 8.2. Verification Service (VS)
When a call arrives, an out-of-band verification service performs When a call arrives, an out-of-band verification service performs
steps similar to those defined in [RFC8224] with some exceptions: steps similar to those defined in [RFC8224] with some exceptions:
Step 1: The verification service contacts the CPS and requests all Step 1: The verification service contacts the CPS and requests all
current PASSporTs for its destination number; or alternatively it may current PASSporTs for its destination number; or alternatively it may
receive PASSporTs through a push interface from the CPS in some receive PASSporTs through a push interface from the CPS in some
deployments. The verification service MUST then decrypt all deployments. The verification service MUST then decrypt all
PASSporTs using its private key. Some PASSporTs may not be PASSporTs using its private key. Some PASSporTs may not be
decryptable for any number of reasons: they may be intended for a decryptable for any number of reasons: they may be intended for a
different verification service, or they may be "dummy" values different verification service, or they may be "dummy" values
inserted by the CPS for privacy purposes. The next few steps will inserted by the CPS for privacy purposes. The next few steps will
narrow down the set of PASSporTs that the verification service will narrow down the set of PASSporTs that the verification service will
examine from that initial decryptable set. examine from that initial decryptable set.
Step 2: The verification service MUST determine if any "ppt" Step 2: The verification service MUST determine if any "ppt"
extensions in the PASSporTs are unsupported. It takes only the set extensions in the PASSporTs are unsupported. It takes only the set
of supported PASSporTs and applies the next step to them. of supported PASSporTs and applies the next step to them.
Step 3: The verification service MUST determine if there is an Step 3: The verification service MUST determine if there is an
overlap between the calling party number number presented in call overlap between the calling party number presented in call signaling
signaling and the "orig" field of any decrypted PASSporTs. It takes and the "orig" field of any decrypted PASSporTs. It takes the set of
the set of matching PASSporTs and applies the next step to them. matching PASSporTs and applies the next step to them.
Step 4: The verification service MUST determine if the credentials Step 4: The verification service MUST determine if the credentials
that signed each PASSporT are valid, and if the verification service that signed each PASSporT are valid, and if the verification service
trusts the CA that issued the credentials. It takes the set of trusts the CA that issued the credentials. It takes the set of
trusted PASSporTs to the next step. trusted PASSporTs to the next step.
Step 5: The verification service MUST check the freshness of the Step 5: The verification service MUST check the freshness of the
"iat" claim of each PASSporT. The exact interval of time that "iat" claim of each PASSporT. The exact interval of time that
determines freshness is left to local policy. It takes the set of determines freshness is left to local policy. It takes the set of
fresh PASSporTs to the next step. fresh PASSporTs to the next step.
Step 6: The verification service MUST check the validity of the Step 6: The verification service MUST check the validity of the
signature over each PASSporT, as described in [RFC8225]. signature over each PASSporT, as described in [RFC8225].
Finally, the verification service will end up with one or more valid Finally, the verification service will end up with one or more valid
PASSporTs corresponding to the call it has received. This document PASSporTs corresponding to the call it has received. In keeping with
does not prescribe any particular treatment of calls that have valid baseline STIR, this document does not dictate any particular
PASSporTs associated with them. The handling of the message after treatment of calls that have valid PASSporTs associated with them;
the verification process depends on how the verification service is the handling of the call after the verification process depends on
implemented and on local policy. However, it is anticipated that how the verification service is implemented and on local policy.
local policies could involve making different forwarding decisions in However, it is anticipated that local policies could involve making
intermediary implementations, or changing how the user is alerted or different forwarding decisions in intermediary implementations, or
how identity is rendered in UA implementations. changing how the user is alerted or how identity is rendered in UA
implementations.
8.3. Gateway Placement Services 8.3. Gateway Placement Services
The STIR out-of-band mechanism also supports the presence of gateway The STIR out-of-band mechanism also supports the presence of gateway
placement services, which do not create PASSporTs themselves, but placement services, which do not create PASSporTs themselves, but
instead take PASSporTs out of signaling protocols and store them at a instead take PASSporTs out of signaling protocols and store them at a
CPS before gatewaying to a protocol that cannot carry PASSporTs CPS before gatewaying to a protocol that cannot carry PASSporTs
itself. For example, a SIP gateway that sends calls to the PSTN itself. For example, a SIP gateway that sends calls to the PSTN
could receive a call with an Identity header field, extract a could receive a call with an Identity header field, extract a
PASSporT from the Identity header field, and store that PASSporT at a PASSporT from the Identity header field, and store that PASSporT at a
CPS. CPS.
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of To place a PASSporT at a CPS, a gateway MUST perform Step 3 of
Section 8.1 above: that is, it must discover the CPS and public key Section 8.1 above: that is, it must discover the CPS and public key
associated with the destination of the call, and may need to acquire associated with the destination of the call, and may need to acquire
a PASSporT storage token (see Section 6.1). Per Step 3 this may a PASSporT storage token (see Section 6.1). Per Step 3 of
entail discovering several keys. The gateway then collects the in- Section 8.1 this may entail discovering several keys. The gateway
band PASSporT(s) from the in-band signaling, encrypts the then collects the in-band PASSporT(s) from the in-band signaling,
PASSporT(s), and stores them at the CPS. encrypts the PASSporT(s), and stores them at the CPS.
A similar service could be performed by a gateway that retrieves A similar service could be performed by a gateway that retrieves
PASSporTs from a CPS and inserts them into signaling protocols that PASSporTs from a CPS and inserts them into signaling protocols that
support carrying PASSporTS in-band. This behavior may be defined by support carrying PASSporTS in-band. This behavior may be defined by
future specifications. future specifications.
9. Example HTTPS Interface to the CPS 9. Example HTTPS Interface to the CPS
As a rough example, we show a Call Placement Service implementation As a rough example, we show a Call Placement Service implementation
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.
skipping to change at page 20, line 5 skipping to change at page 20, line 29
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.555.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 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
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.555.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 encryption key for that that it has also discovered one public encryption key for that
destination. It uses that encryption key to encrypt the PASSporT, destination. It uses that encryption key to encrypt the PASSporT,
resulting in the encrypted PASSporT: resulting in the encrypted PASSporT:
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
skipping to change at page 23, line 12 skipping to change at page 23, line 33
so that verification services can acquire the signing credentials for 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 public for allowing authentication services to download the public
encryption key for the called party - provided they can be discovered encryption key for the called party - provided they can be discovered
by calling parties. This document does not specify any particular by calling parties. This document does not specify any particular
discovery scheme, but instead offers some general guidance about discovery scheme, but instead offers some general guidance about
potential approaches. potential approaches.
It is a desirable property that the public encryption key for a given It is a desirable property that the public encryption key for a given
party be linked to their STIR credential. We therefore propose that party be linked to their STIR credential. An ECDH [RFC7748] public-
an ECDH [RFC7748] public-private key pair be generated for a subcert private key pair might be generated for a subcert
[I-D.ietf-tls-subcerts] of the STIR credential. That subcert could [I-D.ietf-tls-subcerts] of the STIR credential. That subcert could
be looked up along with the STIR credential of the called party. be looked up along with the STIR credential of the called party.
Further details of this subcert, and the exact lookup mechanism Further details of this subcert, and the exact lookup mechanism
involved, are deferred for future protocol work. involved, are deferred for future protocol work.
Obviously, if there is a single central database that the caller and Obviously, if there is a single central database that the caller and
callee each access in real time to download the other's keys, then callee each access in real time to download the other's keys, then
this represents a real privacy risk, as the central key database this represents a real privacy risk, as the central key database
learns about each call. A number of mechanisms are potentially learns about each call. A number of mechanisms are potentially
available to mitigate this: available to mitigate this:
skipping to change at page 24, line 16 skipping to change at page 24, line 32
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 Russ Housley, Barnes and Cullen Jennings. We'd also like to thank Russ Housley,
Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang,
Jonathan Rosenberg and Robert Sparks for helpful suggestions. Jonathan 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. Privacy Considerations
Delivering PASSporTs out-of-band offers a different set of privacy
properties than traditional in-band STIR. In-band operations convey
PASSporTs as headers in SIP messages in cleartext, which any
forwarding intermediaries can potentially inspect. By contrast, out-
of-band STIR stores these PASSporTs at a service after encrypting
them as described in Section 6, effectively creating a path between
the authentication and verification service in which the CPS is the
sole intermediary, but the CPS cannot read the PASSporTs.
Potentially, out-of-band PASSporT delivery could thus improve on the
privacy story of STIR.
The principle actors in the operation of out-of-band are the AS, VS,
and CPS. The AS and VS functions differ from baseline [RFC8224]
behavior, in that they interact with an CPS over a non-SIP interface,
of which the REST interface in Section 9 serves as an example. Some
out-of-band deployments may also require a discovery service for the
CPS itself (Section 10) and/or encryption keys (Section 11). Even
with encrypted PASSporTs, the network interactions by which the AS
and VS interact with the CPS, and to a lesser extent any discovery
services, thus create potential opportunities for data leakage about
calling and called parties.
The process of storing and retrieving PASSporTs at a CPS can itself
reveal information about calls being placed. The mechanism takes
care not to require that the AS authenticate itself to the CPS,
relying instead on a blind signature mechanism for flood control
prevention. Section 7.4 discusses the practice of storing "dummy"
PASSporTs at random intervals to thwart traffic analysis, and as
Section 8.2 notes, a CPS is required to return a dummy PASSporT even
if there is no PASSporT indexed for that calling number, which
similarly enables the retrieval side to randomly request PASSporTs
when there are no calls in progress. These measures can help to
mitigiate information disclosure in the system. In implementations
that require service discovery (see Section 10), perhaps through key
discovery (Section 11), similar measures could be used to make sure
that service discovery does not itself disclose information about
calls.
Ultimately, this document only provides a framework for future
implementation of out-of-band systems, and the privacy properties of
a given implementation will depend on architectural assumptions made
in those environments. More closed systems for intranet operations
may adopt a weaker security posture but otherwise mitigate the risks
of information disclosure, where more open environment will require
careful implementation of the practices described here.
For general privacy risks associated with the operations of STIR,
also see the Privacy Considerations of [RFC8224].
15. Security Considerations
This entire document is about security, but the detailed security This entire document is about security, but the detailed security
properties will vary depending on how the framework is applied and properties will vary depending on how the framework is applied and
deployed. General guidance for dealing with the most obvious deployed. General guidance for dealing with the most obvious
security challenges posed by this framework is given in Section 7.3 security challenges posed by this framework is given in Section 7.3
and Section 7.4, along proposed solutions for problems like denial- and Section 7.4, along proposed solutions for problems like denial-
of-service attacks or traffic analysis against the CPS. of-service attacks or traffic analysis against the CPS.
Although there are considerable security challenges associated with Although there are considerable security challenges associated with
widespread deployment of a public CPS, those must be weighed against widespread deployment of a public CPS, those must be weighed against
the potential usefulness of a service that delivers a STIR assurance the potential usefulness of a service that delivers a STIR assurance
without requiring the passage of end-to-end SIP. Ultimately, the without requiring the passage of end-to-end SIP. Ultimately, the
security properties of this mechanism are at least comparable to in- security properties of this mechanism are at least comparable to in-
band STIR: the substitution attack documented in Section 7.4 could be band STIR: the substitution attack documented in Section 7.4 could be
implemented by any in-band SIP intermediary or eavesdropper who implemented by any in-band SIP intermediary or eavesdropper who
happened to see the PASSporT in transit, say, and launch its own call happened to see the PASSporT in transit, say, and launch its own call
with a copy of that PASSporT to race against the original to the with a copy of that PASSporT to race against the original to the
destination. destination.
15. Informative References 16. 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-06 (work in progress), draft-ietf-stir-passport-divert-07 (work in progress),
July 2019. November 2019.
[I-D.ietf-tls-subcerts] [I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", draft-ietf-tls- "Delegated Credentials for TLS", draft-ietf-tls-
subcerts-04 (work in progress), July 2019. subcerts-06 (work in progress), February 2020.
[I-D.jennings-vipr-overview] [I-D.jennings-vipr-overview]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability: Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings- Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013. vipr-overview-06 (work in progress), December 2013.
[I-D.privacy-pass]
Davidson, A. and N. Sullivan, "The Privacy Pass Protocol",
draft-privacy-pass-00 (work in progress), November 2019.
[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. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999, DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>. <https://www.rfc-editor.org/info/rfc2560>.
 End of changes. 42 change blocks. 
92 lines changed or deleted 166 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/