draft-ietf-stir-oob-01.txt   draft-ietf-stir-oob-02.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: May 2, 2018 Neustar Expires: September 6, 2018 Neustar
October 29, 2017 March 5, 2018
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-01.txt draft-ietf-stir-oob-02.txt
Abstract Abstract
The PASSporT format defines a token that can be carried by signaling The PASSporT format defines a token that can be carried by signaling
protocols, including SIP, to cryptographically attest the identify of protocols, including SIP, to cryptographically attest the identify of
callers. Not all telephone calls use Internet signaling protocols, callers. Not all telephone calls use Internet signaling protocols,
however, and some calls use them for only part of their signaling however, and some calls use them for only part of their signaling
path. This document describes use cases that require the delivery of path. This document describes use cases that require the delivery of
PASSporT objects outside of the signaling path, and defines PASSporT objects outside of the signaling path, and defines
architectures and semantics to provide this functionality. architectures and semantics to provide this functionality.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 2, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . 7 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7
6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8
6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11
7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12
7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13
7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13
8. Call Placement Service Discovery . . . . . . . . . . . . . . 14 8. Authentication and Verification Service Behavior for Out-of-
9. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 15 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Authentication Service . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.2. Verification Service . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . 16 9. HTTPS Interface to the CPS . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
15. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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, [I-D.ietf-stir-rfc4474bis] defines an impersonation. For example, [RFC8224] defines an Identity header of
Identity header of SIP requests capable of carrying a PASSporT SIP requests capable of carrying a PASSporT [RFC8225] object in SIP
[I-D.ietf-stir-passport] object in SIP as a means to as a means to cryptographically attest that the originator of a
cryptographically attest that the originator of a telephone call is telephone call is authorized to use the calling party number (or, for
authorized to use the calling party number (or, for native SIP cases, native SIP cases, SIP URI) associated with the originator of the
SIP URI) associated with the originator of the call. of the request. call. of the request.
Not all telephone calls use SIP today, however; and even those that Not all telephone calls use SIP today, however; and even those that
do use SIP do not always carry SIP signaling end-to-end. Most calls do use SIP do not always carry SIP signaling end-to-end. Most calls
from telephone numbers still traverse the Public Switched Telephone from telephone numbers still traverse the Public Switched Telephone
Network (PSTN) at some point. Broadly, calls fall into one of three Network (PSTN) at some point. Broadly, calls fall into one of three
categories: 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
skipping to change at page 3, line 50 skipping to change at page 4, line 8
potential avenue for building an authentication system that potential avenue for building an authentication system that
implements stronger identity while leaving PSTN systems intact. implements stronger identity while leaving 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 This specification therefore builds on the PASSporT [RFC8225]
[I-D.ietf-stir-passport] mechanism and the work of mechanism and the work of [RFC8224] to define a way that a PASSporT
object created in the originating network of a call can reach the
[I-D.ietf-stir-rfc4474bis] to define 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 end-to-end in-band terminating network even when it cannot be carried end-to-end in-band
in the call signaling. This relies on a new service defined in this in the call signaling. This relies on a new service defined in this
document that permits the PASSporT object to be stored during call document that permits the PASSporT object to be stored during call
processing and retrieved for verification purposes. processing and retrieved for verification purposes.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
skipping to change at page 5, line 35 skipping to change at page 5, line 35
Because in these operating environments endpoints cannot pass Because in these operating environments endpoints cannot pass
cryptographic information to one another directly through signaling, cryptographic information to one another directly through signaling,
any solution must involve some rendezvous mechanism to allow any solution must involve some rendezvous mechanism to allow
endpoints to communicate. We call this rendezvous service a "call endpoints to communicate. We call this rendezvous service a "call
placement service" (CPS), a service where a record of call placement, placement service" (CPS), a service where a record of call placement,
in this case a PASSporT, can be stored for future retrieval. In in this case a PASSporT, can be stored for future retrieval. In
principle this service could communicate any information, but principle this service could communicate any information, but
minimally we expect it to include a full-form PASSporT that attests minimally we expect it to include a full-form PASSporT that attests
the caller, callee, and the time of the call. The callee can use the the caller, callee, and the time of the call. The callee can use the
existence of a PASSporT for a given incoming call as rough validation existence of a PASSporT for a given incoming call as rough validation
of the asserted origin of that call. (See Section 9 for limitations of the asserted origin of that call. (See Section 11 for limitations
of this design.) of this design.)
There are roughly two plausible dataflow architectures for the CPS: There are roughly two plausible dataflow architectures for the CPS:
The callee registers with the CPS. When the caller wishes to The callee registers with the CPS. When the caller wishes to
place a call to the callee, it sends the PASSporT to the CPS, place a call to the callee, it sends the PASSporT to the CPS,
which immediately forwards it to the callee. which immediately forwards it to the callee.
The caller stores the PASSporT with the CPS at the time of call The caller stores the PASSporT with the CPS at the time of call
placement. When the callee receives the call, it contacts the CPS placement. When the callee receives the call, it contacts the CPS
skipping to change at page 6, line 15 skipping to change at page 6, line 15
they could surely just use SIP or some other protocol to set up a they could surely just use SIP or some other protocol to set up a
secure session; even if the media were going through the traditional secure session; even if the media were going through the traditional
PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we
focus on the second architecture in which the PSTN incoming call focus on the second architecture in which the PSTN incoming call
serves as the notification channel and the callee can then contact serves as the notification channel and the callee can then contact
the CPS to retrieve the PASSporT. the CPS to retrieve the PASSporT.
5. Use Cases 5. Use Cases
The following are the motivating use cases for this mechanism. Bear The following are the motivating use cases for this mechanism. Bear
in mind that just as in [I-D.ietf-stir-rfc4474bis] there may be in mind that just as in [RFC8224] there may be multiple Identity
multiple Identity headers in a single SIP INVITE, so there may be headers in a single SIP INVITE, so there may be multiple PASSporTs in
multiple PASSporTs in this out-of-band mechanism associated with a this out-of-band mechanism associated with a single call. For
single call. For example, a SIP user agent might create a PASSporT example, a SIP user agent might create a PASSporT for a call with an
for a call with an end user credential, and as the call exits the end user credential, and as the call exits the originating
originating administrative domain the network authentication service administrative domain the network authentication service might create
might create its own PASSporT for the same call. As such, these use its own PASSporT for the same call. As such, these use cases may
cases may overlap in the processing of a single call. overlap in the processing of a single call.
5.1. Case 1: VoIP to PSTN Call 5.1. Case 1: VoIP to PSTN Call
A call originates in the SIP world in a STIR-aware administrative A call originates in 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
[I-D.ietf-stir-rfc4474bis]. The call is routed out of the [RFC8224]. The call is routed out of the originating administrative
originating administrative domain and reaches a gateway to the PSTN. domain and reaches a gateway to the PSTN. Eventually, the call will
Eventually, the call will terminate on a mobile smartphone that terminate on a mobile smartphone that supports this out-of-band
supports this out-of-band mechanism. mechanism.
In this use case, the originating authentication service can store In this use case, the originating authentication service can store
the PASSporT with the appropriate CPS for the target telephone number the PASSporT with the appropriate CPS for the target telephone number
as a fallback in case SIP signaling will not reach end-to-end. When as a fallback in case SIP signaling will not reach end-to-end. When
the destination mobile smartphone receives the call over the PSTN, it the destination mobile smartphone receives the call over the PSTN, it
consults the CPS and discovers a PASSporT from the originating consults the CPS and discovers a PASSporT from the originating
telephone number waiting for it. It uses this PASSporT to verify the telephone number waiting for it. It uses this PASSporT to verify the
calling party number. calling party number.
5.2. Case 2: Two Smart PSTN endpoints 5.2. Case 2: Two Smart PSTN endpoints
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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 for this call, add a corresponding Identity header per [RFC8224].
[I-D.ietf-stir-rfc4474bis]. When the SIP INVITE reaches the When the SIP INVITE reaches the destination administrative domain, it
destination administrative domain, it will be able to verify the will be able to verify the PASSporT normally. Note that to avoid
PASSporT normally. Note that to avoid discrepancies with the Date discrepancies with the Date header field value, only full-form
header field value, only full-form PASSporT should be used for this PASSporT should be used for this purpose. In subcase 2, the gateway
purpose. In subcase 2, the gateway does not retrieve the PASSporT does not retrieve the PASSporT itself, but instead the verification
itself, but instead the verification service at the destination service at the destination administrative domain does so. Subcase 1
administrative domain does so. Subcase 1 would perhaps be valuable would perhaps be valuable for deployments where the destination
for deployments where the destination administrative domain supports administrative domain supports in-band STIR but not out-of-band STIR.
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
[I-D.ietf-stir-rfc4474bis]. The call is routed out of the [RFC8224]. The call is routed out of the originating administrative
originating administrative domain and eventually reaches a gateway to domain and eventually reaches a gateway to the PSTN.
the PSTN.
In this case, the originating authentication service does not support In this case, the originating authentication service does not support
the out-of-band mechanism, so instead the gateway to the PSTN the out-of-band mechanism, so instead the gateway to the PSTN
extracts the PASSporT from the SIP request and provisions it to the extracts the PASSporT from the SIP request and provisions it to the
CPS. (When the call reaches the gateway to the PSTN, the gateway CPS. (When the call reaches the gateway to the PSTN, the gateway
might first check the CPS to see if a PASSporT object had already might first check the CPS to see if a PASSporT object had already
been provisioned for this call, and only provision a PASSporT if none been provisioned for this call, and only provision a PASSporT if none
is present). is present).
Ultimately, the call may terminate on the PSTN, or be routed back to Ultimately, the call may terminate on the PSTN, or be routed back to
skipping to change at page 8, line 36 skipping to change at page 8, line 33
private key will be able to decrypt the PASSporT. This also prevents private key will be able to decrypt the PASSporT. This also prevents
the CPS itself from learning the contents of PASSporTs, and thus the CPS itself from learning the contents of PASSporTs, and thus
metadata about calls in progress, which would make the CPS a less metadata about calls in progress, which would make the CPS a less
attractive target for pervasive monitoring (see [RFC7258]). Ho attractive target for pervasive monitoring (see [RFC7258]). Ho
bolster the privacy story, prevent denial-of-service flooding of the bolster the privacy story, prevent denial-of-service flooding of the
CPS, and to complicate traffic analysis, a few additional mechanisms CPS, and to complicate traffic analysis, a few additional mechanisms
are also recommended. are also recommended.
The STIR architecture assumes that service providers and in some The STIR architecture assumes that service providers and in some
cases end user devices will have credentials suitable for attesting cases end user devices will have credentials suitable for attesting
authority over telephone numbers per [I-D.ietf-stir-certificates]. authority over telephone numbers per [RFC8226]. These credentials
These credentials provide the most obvious way that a CPS can provide the most obvious way that a CPS can authorize the storage and
authorize the storage and retrieval of PASSporTs. However, as use retrieval of PASSporTs. However, as use cases 3 and 4 in Section 5
cases 3 and 4 in Section 5 show, it may sometimes make sense for the show, it may sometimes make sense for the entity storing or
entity storing or retrieving PASSporTs to be an intermediary rather retrieving PASSporTs to be an intermediary rather than a device
than a device associated with either the originating or terminating associated with either the originating or terminating side of a call,
side of a call, and those intermediaries often would not have access and those intermediaries often would not have access to STIR
to STIR credentials covering the telephone numbers in question. credentials covering the telephone numbers in question. Requiring
Requiring authorization based on a credential to store PASSporTs is authorization based on a credential to store PASSporTs is therefore
therefore undesirable, though potentially acceptible if sufficient undesirable, though potentially acceptible if sufficient steps are
steps are taken to mitigate the privacy risk as described in the next taken to mitigate the privacy risk as described in the next section.
section.
Furthermore, it is an explicit design goal of this mechanism to Furthermore, it is an explicit design goal of this mechanism to
minimize the potential privacy exposure of using a CPS. Ideally, the minimize the potential privacy exposure of using a CPS. Ideally, the
out-of-band mechanism should not result in a worse privacy situation out-of-band mechanism should not result in a worse privacy situation
than in-band [I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might than in-band [RFC8224] STIR: for in-band, we might say that a SIP
say that a SIP entity is authorized to receive a PASSporT if it is an entity is authorized to receive a PASSporT if it is an intermediate
intermediate or final target of the routing of a SIP request. As the or final target of the routing of a SIP request. As the originator
originator of a call cannot necessarily predict the routing path a of a call cannot necessarily predict the routing path a call will
call will follow, an out-of-band mechanism could conceivably even follow, an out-of-band mechanism could conceivably even improve on
improve on the privacy story. As a first step, transport-level the privacy story. As a first step, transport-level security can
security can provide confidentiality from eavesdroppers for both the provide confidentiality from eavesdroppers for both the storage and
storage and retrieval of PASSporTs. retrieval of PASSporTs.
6.1. Storage 6.1. Storage
For authorizing the storage of PASSporTs, the architecture can permit For authorizing the storage of PASSporTs, the architecture can permit
some flexibility. Note that in this architecture a CPS has no way to some flexibility. Note that in this architecture a CPS has no way to
tell if a PASSporT is valid; it simply conveys encrypted blocks that tell if a PASSporT is valid; it simply conveys encrypted blocks that
it cannot access itself. In that architecture, it does not matter it cannot access itself. In that architecture, it does not matter
whether the CPS received a PASSporT from the authentication service whether the CPS received a PASSporT from the authentication service
that created it or from an intermediary gateway downstream in the that created it or from an intermediary gateway downstream in the
routing path as in case 4. routing path as in case 4.
skipping to change at page 12, line 14 skipping to change at page 12, line 14
7.1. Credentials and Phone Numbers 7.1. Credentials and Phone Numbers
We start from the premise of the STIR problem statement [RFC7340] We start from the premise of the STIR problem statement [RFC7340]
that phone numbers can be associated with credentials which can be that phone numbers can be associated with credentials which can be
used to attest ownership of numbers. For purposes of exposition, we used to attest ownership of numbers. For purposes of exposition, we
will assume that ownership is associated with the endpoint (e.g., a will assume that ownership is associated with the endpoint (e.g., a
smartphone) but it might well be associated with a provider or smartphone) but it might well be associated with a provider or
gateway acting for the endpoint instead. It might be the case that gateway acting for the endpoint instead. It might be the case that
multiple entities are able to act for a given number, provided that multiple entities are able to act for a given number, provided that
they have the appropriate authority. [I-D.ietf-stir-certificates] they have the appropriate authority. [RFC8226] describes a
describes a credentials system suitable for this purpose; the credentials system suitable for this purpose; the question of how an
question of how an entity is determined to have control of a given entity is determined to have control of a given number is out of
number is out of scope for the current document. scope for the current document.
7.2. Call Flow 7.2. Call Flow
An overview of the basic calling and verification process is shown An overview of the basic calling and verification process is shown
below. In this diagram, we assume that Alice has the number below. In this diagram, we assume that Alice has the number
+1.111.111.1111 and Bob has the number +2.222.222.2222. +1.111.111.1111 and Bob has the number +2.222.222.2222.
Alice Call Placement Service Bob Alice Call Placement Service Bob
----------------------------------------------------------------------- -----------------------------------------------------------------------
skipping to change at page 13, line 34 skipping to change at page 13, line 34
communication from the CPS to the callee, he can mount either attack. communication from the CPS to the callee, he can mount either attack.
As PASSporTs should be digitally signed by an appropriate authority As PASSporTs should be digitally signed by an appropriate authority
for the number and verified by the callee (see Section 7.1), this for the number and verified by the callee (see Section 7.1), this
should not arise in ordinary operations. For privacy and robustness should not arise in ordinary operations. For privacy and robustness
reasons, using TLS on the originating side when storing the PASSporT reasons, using TLS on the originating side when storing the PASSporT
at the CPS is recommended. 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 number. However, that is no different from in-band [RFC8224] STIR.
[I-D.ietf-stir-rfc4474bis] STIR.
7.4. Substitution Attacks 7.4. Substitution Attacks
All that receipt of the PASSporT from the CPS proves to the called All that receipt of the PASSporT from the CPS proves to the called
party is that Alice is trying to call Bob (or at least was as of very party is that Alice is trying to call Bob (or at least was as of very
recently) - it does not prove that any particular incoming call is recently) - it does not prove that any particular incoming call is
from Alice. Consider the scenario in which we have a service which from Alice. Consider the scenario in which we have a service which
provides an automatic callback to a user-provided number. In that provides an automatic callback to a user-provided number. In that
case, the attacker can try to arrange for a false caller-id value, as case, the attacker can try to arrange for a false caller-id value, as
shown below: shown below:
skipping to change at page 14, line 36 skipping to change at page 14, line 36
insert an appropriate PASSporT and then initiates a call to Bob. insert an appropriate PASSporT and then initiates a call to Bob.
Because it is a valid CS injecting the PASSporT, none of the security Because it is a valid CS injecting the PASSporT, none of the security
checks mentioned above help. However, the attacker simultaneously checks mentioned above help. However, the attacker simultaneously
initiates a call to Bob using forged caller-id information initiates a call to Bob using forged caller-id information
corresponding to the CS. If he wins the race with the CS, then Bob's corresponding to the CS. If he wins the race with the CS, then Bob's
phone will attempt to verify the attacker's call (and succeed since phone will attempt to verify the attacker's call (and succeed since
they are indistinguishable) and the CS's call will go to busy/voice they are indistinguishable) and the CS's call will go to busy/voice
mail/call waiting. Note: in a SIP environment, the callee might mail/call waiting. Note: in a SIP environment, the callee might
notice that there were multiple INVITEs and thus detect this attack. notice that there were multiple INVITEs and thus detect this attack.
8. Call Placement Service Discovery 8. Authentication and Verification Service Behavior for Out-of-Band
[RFC8224] defines an authentication service and a verification
service as functions that act in the context of SIP requests and
responses. This specification thus provides a more generic
description of authentication service and verification service
behavior that might or might not involve any SIP transactions, but
depends only on placing a request for communications from an
originating identity to one or more destination identities.
8.1. Authentication Service
Out-of-band authentication services perform steps similar to those
defined in [RFC8224] with some exceptions:
Step 1: The authentication service MUST determine whether it is
authoritative for the identity of the originator of the request, that
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
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
example, the authentication service could hold the private key
associated with a STIR certificate [RFC8225].
Step 2: The authentication service MUST determine that the originator
of communications can claim the originating identity. This is a
policy decision made by the authentication service that depends on
its relationship to the originator. For an out-of-band application
built in to the calling device, for example, this is the same check
performed in Step 1: does the calling device have a private key, such
one corresponding to a STIR certificate, that can sign for the
originating identity?
Step 3: The authentication service MUST acquire the public key of the
destination, which will be used to encrypt the PASSporT. It must
also discover (see Section 10) the CPS associated with the
destination. The authentication service may already have the key and
destination CPS cached, or may need to query a service to acquire the
key. Note that per Section 6.1 the authentication service may also
need to acquire a token for PASSporT storage from the CPS upon CPS
discovery. It is anticipated that the discovery mechanism (see
Section 10) used to find the appropriate CPS will also find the
proper key server for the public key of the destination. In some
cases, a destination may have multiple public keys associated with
it. In that case, the authentication service MUST collect all of
those keys.
Step 4: The authentication service MUST create the PASSporT object.
This includes acquiring the system time to populate the "iat" claim,
and populating the "orig" and "dest" claims as described in
[RFC8225]. The authentication service MUST then encrypt the
PASSporT. If in Step 3 the authentication service discovered
multiple public keys for the destination, it MUST create one
encrypted copy for each public key it discovered.
Finally, the authentication service stores the encrypted PASSporT(s)
at the CPS discovered in Step 3. Only after that is completed should
any call initiated. Note that a call might be initiated over SIP,
and the authentication service would place the same PASSporT in the
Identity header field value of the SIP request - though SIP would
carry cleartext version rather than an encrypted version sent to 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. 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.
8.2. Verification Service
When a call arrives, an out-of-band verification service performs
steps similar to those defined in [RFC8224] with some exceptions:
Step 1: The verification service contacts the CPS and requests all
current PASSporTs for its destination number. The verification
service MUST then decrypt all PASSporTs using its private key. Some
PASSporTs may not be decryptable for any number of reasons: they may
be intended for a different verification service, or they may be
"dummy" values inserted by the CPS for privacy purposes. The next
few steps will narrow down the set of PASSporTs that the verification
service will examine from that initial decryptable set.
Step 2: The verification service MUST determine if any "ppt"
extensions in the PASSporTs are unsupported. It takes only the set
of supported PASSporTs and applies the next step to them.
Step 3: The verification service MUST determine if there is an
overlap between the called party number number presented in call
signaling and the "orig" field of any decrypted PASSporTs. It takes
the set of matching PASSporTs and applies the next step to them.
Step 4: The verification service MUST determine if the credentials
that signed each PASSporT are valid, and if the verification service
trusts the CA that issued the credentials. It takes the set of
trusted PASSporTs to the next step.
Step 5: The verification service MUST check the freshness of the
"iat" claim of each PASSporT. The exact interval of time that
determines freshness is left to local policy. It takes the set of
fresh PASSporTs to the next step.
Step 6: The verification service MUST check the validity of the
signature over each PASSporT, as described in described in [RFC8225].
Finally, the verification service will end up with one or more valid
PASSporTs corresponding to the call it has received. This document
does not prescribe any particular treatment of calls that have valid
PASSporTs associated with them. The handling of the message after
the verification process depends on how the verification service is
implemented and on local policy. However, it is anticipated that
local policies could involve making different forwarding decisions in
intermediary implementations, or changing how the user is alerted or
how identity is rendered in UA implementations.
8.3. Gateway Placement Services
The out-of-band mechanism also supports the presence of gateway
placement services, which do not create PASSporTs themselves, but
instead take PASSporTs out of signaling protocols and store them at a
CPS before gatewaying to a protocol that cannot carry PASSporTs
itself. For example, a SIP gateway that sends calls to the PSTN
could receive a call with an Identity header, extract a PASSporT from
the Identity header, and store that PASSporT at a CPS.
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
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
entail discovering several keys. The gateway then collects the in-
band PASSporT(s) from the in-band signaling, encrypts the
PASSporT(s), and stores them at the CPS.
A similar service could be performed by a gateway that retrieves
PASSporTs from a CPS and inserts them into signaling protocols that
support carrying PASSporTS in-band. This behavior may be defined by
future specifications.
9. HTTPS Interface to the CPS
The default Call Placement Service implementation 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 call; the PASSporT is
stored at a location at the CPS that corresponds to the called
number. Note that it is possible for multiple parties to be calling
a number at the same time, and that for called numbers such as large
call centers, many PASSporTs could legitimately be stored
simultaneously, and it might prove difficult to correlate these with
incoming calls.
Assume that an authentication service has created the following
PASSporT for a call to the telephone number 2.222.222.2222: [TBD -
these are currently dummy values, will mock up real examples later]
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz
aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI
jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1
VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w
Through some out-of-band mechanism (see Section 10) the
authentication service discovers the network location of a web
service that acts as the CPS for 2.222.222.2222. Through the same
mechanism, we will say that it has also discovered one public key for
that destination. It uses that public key to encrypt the PASSporT,
resulting in the encrypted PASSporT:
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
Having concluded the numbered steps in Section 8.1, including
acquiring any token (per Section 6.1) needed to store the PASSporT at
the CPS, the authentication service then stores the encrypted
PASSporT:
POST /cps/2.222.222.2222/ppts HTTP/1.1
Host: cps.example.com
Content-Type: application/passport
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
The web service assigns a new location for this encrypted PASSporT in
the collection, returning a 201 OK with the location of
/cps/2.222.222.2222/ppts/ppt1. Now the authentication service can
place the call, which may be signaled by various protocols. Once the
call arrives at the terminating side, a verification service
interrogates its CPS to ask for the set of incoming calls for its
telephone number (2.222.222.2222).
GET /cps/2.222.222.2222/ppts
Host: cps.example.com
This returns to the verification service a list of the PASSporTs
currently in the collection, which currently consists of only
/cps/2.222.222.2222/ppts/ppt1. The verification service then sends a
new GET for /cps/2.222.222.2222/ppts/ppt1/ which yields:
HTTP/1.1 200 OK
Content-Type: application/passport
Link: <https://cps.example.com/cps/2.222.222.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
That concludes Step 1 of Section 8.2; the verification service then
goes on to the next step, processing that PASSporT through its
various checks.
10. CPS Discovery
In order for the two ends of the out-of-band dataflow to coordinate, In order for the two ends of the out-of-band dataflow to coordinate,
they must agree on a way to discover a CPS and retrieve PASSporT they must agree on a way to discover a CPS and retrieve PASSporT
objects from it based solely on the rendezvous information available: objects from it based solely on the rendezvous information available:
the calling party number and the called number. Because the storage the calling party number and the called number. Because the storage
of PASSporTs in this architecture is indexed by the called party of PASSporTs in this architecture is indexed by the called party
number, it makes sense to discover a CPS based on the called party number, it makes sense to discover a CPS based on the called party
number as well. There are a number of potential service discovery number as well. There are a number of potential service discovery
mechanisms that could be used for this purpose. The means of service mechanisms that could be used for this purpose. The means of service
discovery may vary by use case. discovery may vary by use case.
skipping to change at page 15, line 13 skipping to change at page 19, line 44
obvious scaling problems, and would as well allow the CPS to gather obvious scaling problems, and would as well allow the CPS to gather
metadata about a very wide set of callers and callees. These issues metadata about a very wide set of callers and callees. These issues
can be alleviated by operational models with a federated CPS; any can be alleviated by operational models with a federated CPS; any
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. federation of the CPS function.
Some service discovery possibilities under consideration include the Some service discovery possibilities under consideration include the
following: following:
If a credential lookup service is already available (see If a credential lookup service is already available (see
Section 9), 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 [I-D.ietf-stir-certificates] could credentials; an extension to [RFC8226] could for example provide a
for example provide a link to the location of the CPS where link to the location of the CPS where PASSporTs should be stored
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
help the endpoints discover a common CPS. Other protocols help the endpoints discover a common CPS. Other protocols
associated with queries for telephone numbers, such as the TeRI associated with queries for telephone numbers, such as the TeRI
[I-D.peterson-modern-teri] protocol, could also serve for this [I-D.peterson-modern-teri] protocol, could also serve for this
application. application.
skipping to change at page 15, line 42 skipping to change at page 20, line 24
for a particular telephone number should be stored. One advantage for a particular telephone number should be stored. One advantage
that the STIR architecture has over VIPR is that it assumes a that 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.
Future versions of this specification will identify suitable service Future versions of this specification will identify suitable service
discovery mechanisms for out-of-band STIR. discovery mechanisms for out-of-band STIR.
9. Credential Lookup 11. Credential Lookup
In order to encrypt a PASSporT (see Section 6.1), the caller needs In order to encrypt a PASSporT (see Section 6.1), the caller needs
access to the callee's credentials (specifically their public key). access to the callee's credentials (specifically their public key).
This requires some sort of directory/lookup system. This document This requires some sort of directory/lookup system. This document
does not specify any particular scheme, but a list of requirements does not specify any particular scheme, but a list of requirements
would be something like: would be something like:
Obviously, if there is a single central database and the caller and Obviously, if there is a single central database and the caller and
callee each contact it in real time to determine the other's callee each contact it in real time to determine the other's
credentials, then this represents a real privacy risk, as the central credentials, then this represents a real privacy risk, as the central
skipping to change at page 16, line 31 skipping to change at page 21, line 13
verify the caller's credentials via OCSP, though of course this verify the caller's credentials via OCSP, though of course this
requires the callee to trust the CPS's verification. This approach requires the callee to trust the CPS's verification. This approach
does not work as well for the callee's credentials, but the risk does not work as well for the callee's credentials, but the risk
there is more modest since an attacker would need to both have the there is more modest since an attacker would need to both have the
callee's credentials and regularly poll the database for every callee's credentials and regularly poll the database for every
potential caller. potential caller.
We consider the exact best point in the tradeoff space to be an open We consider the exact best point in the tradeoff space to be an open
issue. issue.
10. 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 Robert Sparks Barnes and Cullen Jennings. We'd also like to thank Robert Sparks
for helpful suggestions. for helpful suggestions.
11. IANA Considerations 13. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Security Considerations 14. Security Considerations
This entire document is about security, but the detailed security This entire document is about security, but the detailed security
properties depend on having a single concrete scheme to analyze. properties depend on having a single concrete scheme to analyze.
13. Informative References 15. Informative References
[I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir-
certificates-14 (work in progress), May 2017.
[I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-11 (work in
progress), February 2017.
[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-00 (work in progress), draft-ietf-stir-passport-divert-01 (work in progress),
July 2017. October 2017.
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017.
[I-D.peterson-modern-teri] [I-D.peterson-modern-teri]
Peterson, J., "An Architecture and Information Model for Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson- Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-03 (work in progress), July 2017. modern-teri-03 (work in progress), July 2017.
[I-D.rosenberg-dispatch-vipr-overview] [I-D.rosenberg-dispatch-vipr-overview]
Rosenberg, J., Jennings, C., and M. Petit-Huguenin, Rosenberg, J., Jennings, C., and M. Petit-Huguenin,
"Verification Involving PSTN Reachability: Requirements "Verification Involving PSTN Reachability: Requirements
and Architecture Overview", draft-rosenberg-dispatch-vipr- and Architecture Overview", draft-rosenberg-dispatch-vipr-
skipping to change at page 18, line 14 skipping to change at page 22, line 31
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
Mozilla Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 26 change blocks. 
104 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/