draft-ietf-stir-oob-05.txt   draft-ietf-stir-oob-06.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: January 9, 2020 Neustar Expires: May 7, 2020 Neustar
July 8, 2019 November 4, 2019
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-05 draft-ietf-stir-oob-06
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 January 9, 2020. This Internet-Draft will expire on May 7, 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . 15
8. Authentication and Verification Service Behavior for Out-of- 8. Authentication and Verification Service Behavior for Out-of-
Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Authentication Service . . . . . . . . . . . . . . . . . 16 8.1. Authentication Service . . . . . . . . . . . . . . . . . 16
8.2. Verification Service . . . . . . . . . . . . . . . . . . 17 8.2. Verification Service . . . . . . . . . . . . . . . . . . 18
8.3. Gateway Placement Services . . . . . . . . . . . . . . . 18 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 19
9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 19 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 19
10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 22 11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15. Informative References . . . . . . . . . . . . . . . . . . . 24 15. Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 a SIP Identity header impersonation. For example, [RFC8224] defines a SIP Identity header
field capable of carrying PASSporT [RFC8225] objects in SIP as a field capable of carrying PASSporT [RFC8225] objects in SIP as a
means to cryptographically attest that the originator of a telephone means to cryptographically attest that the originator of a telephone
call is authorized to use the calling party number (or, for native call is authorized to use the calling party number (or, for native
SIP cases, SIP URI) associated with the originator of the call. SIP cases, SIP URI) associated with the originator of the 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. Xalls from do use SIP do not always carry SIP signaling end-to-end. Calls from
telephone numbers still routinely traverse the Public Switched telephone numbers still routinely traverse the Public Switched
Telephone Network (PSTN) at some point. Broadly, calls fall into one Telephone Network (PSTN) at some point. Broadly, calls fall into one
of three 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
skipping to change at page 4, line 12 skipping to change at page 4, line 12
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] Then techniques described in this document therefore build on the
mechanism and the work of [RFC8224] to define a way that a PASSporT PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a
object created in the originating network of a call can reach the way that a PASSporT object created in the originating network of a
terminating network even when it cannot be carried end-to-end in-band call can reach the terminating network even when it cannot be carried
in the call signaling. This relies on a new service defined in this end-to-end in-band in the call signaling. This relies on a new
document called a Call Placement Service (CPS) that permits the service defined in this document called a Call Placement Service
PASSporT object to be stored during call processing and retrieved for (CPS) that permits the PASSporT object to be stored during call
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
is intended to operate. It provides use cases, gives a broad is intended to operate. It provides use cases, gives a broad
description of the components and a potential solution architecture. description of the components and a potential solution architecture.
To flesh out the storage and retrieval of PASSporTs in the CPS within Various environments may have their own security requirements: a
this context, it includes a strawman protocol suitable for that public deployment of out-of-band STIR faces far greater challenges
purpose. Deploying this framework would require additional than a constrained intranetwork deployment. To flesh out the storage
specification outside the scope of the current document. and retrieval of PASSporTs in the CPS within this context, this
document includes a strawman protocol suitable for that purpose.
Deploying this framework in any given environment would require
additional specification outside the scope of the current document.
2. Terminology 2. Terminology
TThe 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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Operating Environments 3. Operating Environments
skipping to change at page 7, line 29 skipping to change at page 7, line 30
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, which communicates through access and a built-in gateway to the PSTN, which communicates through
traditional telephone signaling protocols. The PBX immediately drops traditional telephone signaling protocols. The PBX immediately
the call to the PSTN, but before it does, it provisions a PASSporT on routes the call to the PSTN, but before it does, it provisions a
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
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 immediately drop access and a built-in gateway to the PSTN. It will immediately route
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
original caller created and provisioned a PASSporT for this call. If original caller created and provisioned a PASSporT for this call. If
so, it can retrieve the PASSporT and, when it creates a SIP INVITE so, it can retrieve the PASSporT and, when it creates a SIP INVITE
for this call, add a corresponding Identity header per [RFC8224]. for this call, add a corresponding Identity header field per
When the SIP INVITE reaches the destination administrative domain, it [RFC8224]. When the SIP INVITE reaches the destination
will be able to verify the PASSporT normally. Note that to avoid administrative domain, it will be able to verify the PASSporT
discrepancies with the Date header field value, only full-form normally. Note that to avoid discrepancies with the Date header
PASSporT should be used for this purpose. In subcase 2, the gateway field value, only full-form PASSporT should be used for this purpose.
does not retrieve the PASSporT itself, but instead the verification In subcase 2, the gateway does not retrieve the PASSporT itself, but
service at the destination administrative domain does so. Subcase 1 instead the verification service at the destination administrative
would perhaps be valuable for deployments where the destination domain does so. Subcase 1 would perhaps be valuable for deployments
administrative domain supports in-band STIR but not out-of-band STIR. where the destination administrative domain supports in-band STIR but
not out-of-band STIR.
5.4. Case 4: Gateway Out-of-band 5.4. Case 4: Gateway Out-of-band
A call originates in the SIP world in a STIR-aware administrative A call originates in the SIP world 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 eventually reaches a gateway to the PSTN. domain and eventually reaches a gateway to the PSTN.
In this case, the originating authentication service does not support In this case, the originating authentication service does not support
skipping to change at page 9, line 4 skipping to change at page 9, line 10
administrative domain's verification service that checks the CPS when administrative domain's verification service that checks the CPS when
an INVITE arrives with no Identity header field. Either way the an INVITE arrives with no Identity header field. Either way the
PASSporT can survive the gap in SIP coverage caused by the PSTN leg PASSporT can survive the gap in SIP coverage caused by the PSTN leg
of the call. 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. As a fallback in case the call the SIP call with an Identity header field. As a fallback in case
will not go end-to-end over SIP, the carrier also stores the PASSporT the call will not go end-to-end over SIP, the carrier also stores the
in a CPS. 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
skipping to change at page 12, line 7 skipping to change at page 12, line 14
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.
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 generated PASSporT. This requires the retargeting entity to generate encrypted
encrypted PASSporTs that show a secure chain of diversion: a PASSporTs that show a secure chain of diversion: a retargeting storer
retargeting storer SHOULD use the "div-o" PASSporT type, with its SHOULD use the "div-o" PASSporT type, with its "opt" extension, as
"opt" extension, as specified in [I-D.ietf-stir-passport-divert] in specified in [I-D.ietf-stir-passport-divert] in order to nest the
order to nest the original PASSporT within the encrypted diversion original PASSporT within the encrypted diversion PASSporT.
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.
skipping to change at page 13, line 25 skipping to change at page 13, line 25
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 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.
Once Alice has stored the PASSporT, she then places the call to Bob When Alice places the call, Bob's phone would usually ring and
as usual. At this point, Bob's phone would usually ring and display display Alice's number (+1.111.555.1111), which is informed by the
Alice's number (+1.111.555.1111), which is informed by the existing existing PSTN mechanisms for relaying a calling party number (e.g.,
PSTN mechanisms for relaying a calling party number (i.e., the CIN the CIN field of the IAM). Instead, Bob's phone transparently
field of the IAM). Instead, Bob's phone transparently contacts the contacts the CPS and requests any current PASSporTs for calls to his
CPS and requests any current PASSporTs for calls to his number. The number. The CPS responds with any such PASSporTs (assuming they
CPS responds with any such PASSporTs (assuming they exist). If such exist). If such a PASSporT exists, and the verification service in
a PASSporT exists, and the verification service in Bob's phone Bob's phone decrypts it using his private key, validates it, then
decrypts it using his private key, validates it, then Bob's phone can Bob's phone can present the calling party number information as
present the calling party number information as valid. Otherwise, valid. Otherwise, the call is unverifiable. Note that this does not
the call is unverifiable. Note that this does not necessarily mean necessarily mean that the call is bogus; because we expect
that the call is bogus; because we expect incremental deployment, 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:
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.
skipping to change at page 15, line 15 skipping to change at page 15, line 11
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.
notice that there were multiple INVITEs and thus detect this attack.
In order to prevent a passive attacker from using traffic analysis or
similar means to learn precisely when a call is placed, it is
essential that the connection between the caller and the CPS be
encrypted as recommended above. Callers could store dummy PASSporTs
at the CPS at random intervals in order to make it more difficult for
an eavesdropper to use traffic analysis to determine that a call was
about to be placed.
Note that in a SIP environment, the callee might notice that there
were multiple INVITEs and thus detect this attack, but in some PSTN
interworking scenarios, or highly intermediated networks, only one
call setup attempt will reach the target. Also note that the success
of this substitution attack depends on the attacker landing their
call within the narrow window that the PASSporT is retained in the
CPS, so shortening that window will reduce the opportunity for the
attack. Finally, smart endpoints could implement some sort of state
coordination to ensure that both sides believe the call is in
progress, though methods of supporting that are outside the scope of
this document.
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" (see [RFC5636]). A sender will propose the use of "blind signatures" (see [RFC5636]). A sender will
initially authenticate to the CPS using its STIR credentials, and initially authenticate to the CPS using its STIR credentials, and
acquire a signed token from the CPS that will be presented later when acquire a signed token from the CPS that will be presented later when
storing a PASSporT. The flow looks as follows: storing a PASSporT. The flow looks as follows:
Sender CPS Sender CPS
skipping to change at page 16, line 40 skipping to change at page 17, line 10
8.1. Authentication Service 8.1. Authentication Service
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 something other identifier. For a domain or a telephone number or some other identifier. For
example, the authentication service could hold the private key example, the authentication service could hold the private key
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
skipping to change at page 17, line 31 skipping to change at page 17, line 50
[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)
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 cleartext version rather than an encrypted version sent to the carry a cleartext version rather than an encrypted version sent to
CPS. In that case, out-of-band would serve as a fallback mechanism the CPS. In that case, out-of-band would serve as a fallback
in case the request was not conveyed over SIP end-to-end. Also, note mechanism in case the request was not conveyed over SIP end-to-end.
that the authentication service MAY use a compact form of the
PASSporT for a SIP request, whereas the version stored at the CPS 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
MUST always be a full form PASSporT. MUST always be a full form PASSporT.
8.2. Verification Service 8.2. Verification Service
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
skipping to change at page 18, line 46 skipping to change at page 19, line 15
intermediary implementations, or changing how the user is alerted or intermediary implementations, or changing how the user is alerted or
how identity is rendered in UA implementations. 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, extract a PASSporT from could receive a call with an Identity header field, extract a
the Identity header, and store that PASSporT at a CPS. PASSporT from the Identity header field, and store that PASSporT at a
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 this may
entail discovering several keys. The gateway then collects the in- entail discovering several keys. The gateway then collects the in-
band PASSporT(s) from the in-band signaling, encrypts the band PASSporT(s) from the in-band signaling, encrypts the
PASSporT(s), and stores them at the CPS. 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 an 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.
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
skipping to change at page 21, line 33 skipping to change at page 22, line 5
service discovery mechanism for out-of-band STIR should enable service discovery mechanism for out-of-band STIR should enable
federation of the CPS function. Likely models include ones where a federation of the CPS function. Likely models include ones where a
carrier operates one or more CPS instances on behalf of its carrier operates one or more CPS instances on behalf of its
customers, enterprises run a CPS instance on behalf of their PBX customers, enterprises run a CPS instance on behalf of their PBX
users, or where third-party service providers offer a CPS as a cloud users, or where third-party service providers offer a CPS as a cloud
service. service.
Some service discovery possibilities under consideration include the Some service discovery possibilities under consideration include the
following: following:
For some deployments in closed (e.g. intranetwork) environments,
the CPS location can simply be provisioned in implementations,
obviating the need for a discovery protocol.
If a credential lookup service is already available (see If a credential lookup service is already available (see
Section 11), the CPS location can also be recorded in the callee's Section 11), the CPS location can also be recorded in the callee's
credentials; an extension to [RFC8226] could for example provide a credentials; an extension to [RFC8226] could for example provide a
link to the location of the CPS where PASSporTs should be stored link to the location of the CPS where PASSporTs should be stored
for a destination. for a destination.
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
skipping to change at page 22, line 13 skipping to change at page 22, line 38
a similar RELOAD usage to identify the CPS where calls for a a similar RELOAD usage to identify the CPS where calls for a
particular telephone number should be stored. One advantage that particular telephone number should be stored. One advantage 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 Authentication Service and
Verification Service.
11. Encryption Key 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 public encryption key. Note that because STIR access to the callee's public encryption key. Note that because STIR
uses ECDSA for signing PASSporTs, the public key used to verify uses ECDSA for signing PASSporTs, the public key used to verify
PASSporTs is not suitable for this function, and thus the encryption PASSporTs is not suitable for this function, and thus the encryption
key must be discovered separately. This requires some sort of key must be discovered separately. This requires some sort of
directory/lookup system. directory/lookup system.
skipping to change at page 23, line 29 skipping to change at page 24, line 9
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 Russ Housley, Barnes and Cullen Jennings. We'd also like to thank Russ Housley,
Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Jonathan Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang,
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. 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. without requiring the passage of end-to-end SIP. Ultimately, the
security properties of this mechanism are at least comparable to in-
band STIR: the substitution attack documented in Section 7.4 could be
implemented by any in-band SIP intermediary or eavesdropper who
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
destination.
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-06 (work in progress),
February 2019. July 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-03 (work in progress), February 2019. subcerts-04 (work in progress), July 2019.
[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.
[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,
 End of changes. 26 change blocks. 
76 lines changed or deleted 110 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/