diff options
Diffstat (limited to 'doc/rfc/rfc8816.txt')
| -rw-r--r-- | doc/rfc/rfc8816.txt | 1328 |
1 files changed, 1328 insertions, 0 deletions
diff --git a/doc/rfc/rfc8816.txt b/doc/rfc/rfc8816.txt new file mode 100644 index 0000000..3675487 --- /dev/null +++ b/doc/rfc/rfc8816.txt @@ -0,0 +1,1328 @@ + + + + +Internet Engineering Task Force (IETF) E. Rescorla +Request for Comments: 8816 Mozilla +Category: Informational J. Peterson +ISSN: 2070-1721 Neustar + February 2021 + + +Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and + Use Cases + +Abstract + + The Personal Assertion Token (PASSporT) format defines a token that + can be carried by signaling protocols, including SIP, to + cryptographically attest the identity of callers. However, not all + telephone calls use Internet signaling protocols, and some calls use + them for only part of their signaling path, while some cannot + reliably deliver SIP header fields end-to-end. This document + describes use cases that require the delivery of PASSporT objects + outside of the signaling path, and defines architectures and + semantics to provide this functionality. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8816. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Operating Environments + 4. Dataflows + 5. Use Cases + 5.1. Case 1: VoIP to PSTN Call + 5.2. Case 2: Two Smart PSTN Endpoints + 5.3. Case 3: PSTN to VoIP Call + 5.4. Case 4: Gateway Out-of-Band + 5.5. Case 5: Enterprise Call Center + 6. Storing and Retrieving PASSporTs + 6.1. Storage + 6.2. Retrieval + 7. Solution Architecture + 7.1. Credentials and Phone Numbers + 7.2. Call Flow + 7.3. Security Analysis + 7.4. Substitution Attacks + 7.5. Rate Control for CPS Storage + 8. Authentication and Verification Service Behavior for + Out-of-Band + 8.1. Authentication Service (AS) + 8.2. Verification Service (VS) + 8.3. Gateway Placement Services + 9. Example HTTPS Interface to the CPS + 10. CPS Discovery + 11. Encryption Key Lookup + 12. IANA Considerations + 13. Privacy Considerations + 14. Security Considerations + 15. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + The STIR problem statement [RFC7340] describes widespread problems + enabled by impersonation in the telephone network, including illegal + robocalling, voicemail hacking, and swatting. As telephone services + are increasingly migrating onto the Internet, and using Voice over IP + (VoIP) protocols such as SIP [RFC3261], it is necessary for these + protocols to support stronger identity mechanisms to prevent + impersonation. For example, [RFC8224] defines a SIP Identity header + field capable of carrying PASSporT objects [RFC8225] in SIP as a + means to cryptographically attest that the originator of a telephone + call is authorized to use the calling party number (or, for native + SIP cases, SIP URI) associated with the originator of the call. + + Not all telephone calls use SIP today, however, and even those that + do use SIP do not always carry SIP signaling end-to-end. Calls from + telephone numbers still routinely traverse the Public Switched + Telephone Network (PSTN) at some point. Broadly, calls fall into one + of three categories: + + 1. One or both of the endpoints is actually a PSTN endpoint. + + 2. Both of the endpoints are non-PSTN (SIP, Jingle, etc.) but the + call transits the PSTN at some point. + + 3. Non-PSTN calls that do not transit the PSTN at all (such as + native SIP end-to-end calls). + + The first two categories represent the majority of telephone calls + associated with problems like illegal robocalling: many robocalls + today originate on the Internet but terminate at PSTN endpoints. + However, the core network elements that operate the PSTN are legacy + devices that are unlikely to be upgradable at this point to support + an in-band authentication system. As such, those devices largely + cannot be modified to pass signatures originating on the Internet -- + or indeed any in-band signaling data -- intact. Even if fields for + tunneling arbitrary data can be found in traditional PSTN signaling, + in some cases legacy elements would strip the signatures from those + fields; in others, they might damage them to the point where they + cannot be verified. For those first two categories above, any in- + band authentication scheme does not seem practical in the current + environment. + + While the core network of the PSTN remains fixed, the endpoints of + the telephone network are becoming increasingly programmable and + sophisticated. Landline "plain old telephone service" deployments, + especially in the developed world, are shrinking, and increasingly + being replaced by three classes of intelligent devices: smart phones, + IP Private Branch Exchanges (PBXs), and terminal adapters. All three + are general purpose computers, and typically all three have Internet + access as well as access to the PSTN; they may be used for + residential, mobile, or enterprise telephone services. Additionally, + various kinds of gateways increasingly front for deployments of + legacy PBX and PSTN switches. All of this provides a potential + avenue for building an authentication system that implements stronger + identity while leaving PSTN systems intact. + + This capability also provides an ideal transitional technology while + in-band STIR adoption is ramping up. It permits early adopters to + use the technology even when intervening network elements are not yet + STIR-aware, and through various kinds of gateways, it may allow + providers with a significant PSTN investment to still secure their + calls with STIR. + + The techniques described in this document therefore build on the + PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe 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 in the call signaling. This relies on a new + service defined in this document called a Call Placement Service + (CPS) that permits the PASSporT object to be stored during call + processing and retrieved for verification purposes. + + Potential implementors should note that this document merely defines + the operating environments in which this out-of-band STIR mechanism + is intended to operate. It provides use cases, gives a broad + description of the components, and a potential solution architecture. + Various environments may have their own security requirements: a + public deployment of out-of-band STIR faces far greater challenges + than a constrained intra-network deployment. To flesh out the + storage 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 this document. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Operating Environments + + This section describes the environments in which the proposed out-of- + band STIR mechanism is intended to operate. In the simplest setting, + Alice calls Bob, and her call is routed through some set of gateways + and/or the PSTN that do not support end-to-end delivery of STIR. + Both Alice and Bob have smart devices that can access the Internet + (perhaps enterprise devices, or even end-user ones), but they do not + have a clear telephone signaling connection between them: Alice + cannot inject any data into signaling that Bob can read, with the + exception of the asserted destination and origination E.164 numbers. + The calling party number might originate from her own device or from + the network. These numbers are effectively the only data that can be + used for coordination between the endpoints. + + +---------+ + / \ + +--- +---+ + +----------+ / \ +----------+ + | | | Gateways | | | + | Alice |<----->| and/or |<----->| Bob | + | (caller) | | PSTN | | (callee) | + +----------+ \ / +----------+ + +--- +---+ + \ / + +---------+ + + In a more complicated setting, Alice and/or Bob may not have a smart + or programmable device, but instead just a traditional telephone. + However, one or both of them are behind a STIR-aware gateway that can + participate in out-of-band coordination, as shown below: + + +---------+ + / \ + +--- +---+ + +----------+ +--+ / \ +--+ +----------+ + | | | | | Gateways | | | | | + | Alice |<-|GW|->| and/or |<-|GW|->| Bob | + | (caller) | | | | PSTN | | | | (callee) | + +----------+ +--+ \ / +--+ +----------+ + +--- +---+ + \ / + +---------+ + + In such a case, Alice might have an analog (e.g., PSTN) connection to + her gateway or switch that is responsible for her identity. + Similarly, the gateway would verify Alice's identity, generate the + right calling party number information, and provide that number to + Bob using ordinary Plain Old Telephone Service (POTS) mechanisms. + +4. Dataflows + + Because in these operating environments, endpoints cannot pass + cryptographic information to one another directly through signaling, + any solution must involve some rendezvous mechanism to allow + endpoints to communicate. We call this rendezvous service a Call + Placement Service (CPS), a service where a record of call placement, + in this case a PASSporT, can be stored for future retrieval. In + principle, this service could communicate any information, but + 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 + existence of a PASSporT for a given incoming call as rough validation + of the asserted origin of that call. (See Section 11 for limitations + of this design.) + + This architecture does not mandate that any particular sort of entity + operate a CPS or mandate any means to discover a CPS. A CPS could be + run internally within a network or made publicly available. One or + more CPSes could be run by a carrier, as repositories for PASSporTs + for calls sent to its customers, or a CPS could be built into an + enterprise PBX or even a smartphone. To the degree possible, it is + specified here generically as an idea that may have applicability to + a variety of STIR deployments. + + There are roughly two plausible dataflow architectures for the CPS: + + 1. The callee registers with the CPS. When the caller wishes to + place a call to the callee, it sends the PASSporT to the CPS, + which immediately forwards it to the callee. + + 2. The caller stores the PASSporT with the CPS at the time of call + placement. When the callee receives the call, it contacts the + CPS and retrieves the PASSporT. + + While the first architecture is roughly isomorphic to current VoIP + protocols, it shares their drawbacks. Specifically, the callee must + maintain a full-time connection to the CPS to serve as a notification + channel. This comes with the usual networking costs to the callee + and is especially problematic for mobile endpoints. Indeed, if the + endpoints had the capabilities to implement such an architecture, + 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 + PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we + focus on the second architecture in which the PSTN incoming call + serves as the notification channel, and the callee can then contact + the CPS to retrieve the PASSporT. In specialized environments, for + example, a call center that receives a large volume of incoming calls + that originated in the PSTN, the notification channel approach might + be viable. + +5. Use Cases + + The following are the motivating use cases for this mechanism. Bear + in mind that, just as in [RFC8224], there may be multiple Identity + header fields in a single SIP INVITE, so there may be multiple + PASSporTs in this out-of-band mechanism associated with a single + call. For example, a SIP user agent might create a PASSporT for a + call with an end-user credential, and as the call exits the + originating administrative domain, the network authentication service + might create its own PASSporT for the same call. As such, these use + cases may overlap in the processing of a single call. + +5.1. Case 1: VoIP to PSTN Call + + A call originates in a SIP environment in a STIR-aware administrative + domain. The local authentication service for that administrative + domain creates a PASSporT that is carried in band in the call per + [RFC8224]. The call is routed out of the originating administrative + domain and reaches a gateway to the PSTN. Eventually, the call will + terminate on a mobile smartphone that supports this out-of-band + mechanism. + + In this use case, the originating authentication service can store + the PASSporT with the appropriate CPS (per the practices of + Section 10) for the target telephone number 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 consults the CPS and + discovers a PASSporT from the originating telephone number waiting + for it. It uses this PASSporT to verify the calling party number. + +5.2. Case 2: Two Smart PSTN Endpoints + + A call originates with an enterprise PBX that has both Internet + access and a built-in gateway to the PSTN, which communicates through + traditional telephone signaling protocols. The PBX immediately + routes the call to the PSTN, but before it does, it provisions a + PASSporT on the CPS associated with the target telephone number. + + After normal PSTN routing, the call lands on a smart mobile handset + that supports the STIR out-of-band mechanism. It queries the + appropriate CPS over the Internet to determine if a call has been + placed to it by a STIR-aware device. It finds the PASSporT + provisioned by the enterprise PBX and uses it to verify the calling + party number. + +5.3. Case 3: PSTN to VoIP Call + + A call originates with an enterprise PBX that has both Internet + 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 + with the CPS associated with the target telephone number. However, + 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 + deliver it to an administrative domain with a STIR verification + service. + + In this case, there are two subcases for how the PASSporT might be + retrieved. In subcase 1, the Internet gateway that receives the call + from the PSTN could query the appropriate CPS to determine if the + original caller created and provisioned a PASSporT for this call. If + so, it can retrieve the PASSporT and, when it creates a SIP INVITE + for this call, add a corresponding Identity header field per + [RFC8224]. When the SIP INVITE reaches the destination + administrative domain, it will be able to verify the PASSporT + normally. Note that to avoid discrepancies with the Date header + field value, only a full-form PASSporT should be used for this + purpose. In subcase 2, the gateway does not retrieve the PASSporT + itself, but instead the verification service at the destination + administrative domain does so. Subcase 1 would perhaps be valuable + for deployments where the destination administrative domain supports + in-band STIR but not out-of-band STIR. + +5.4. Case 4: Gateway Out-of-Band + + A call originates in the SIP world in a STIR-aware administrative + domain. The local authentication service for that administrative + domain creates a PASSporT that is carried in band in the call per + [RFC8224]. The call is routed out of the originating administrative + domain and eventually reaches a gateway to the PSTN. + + In this case, the originating authentication service does not support + the out-of-band mechanism, so instead the gateway to the PSTN + extracts the PASSporT from the SIP request and provisions it to the + 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 + been provisioned for this call, and only provision a PASSporT if none + is present). + + Ultimately, the call may terminate on the PSTN or be routed back to a + SIP environment. In the former case, perhaps the destination + endpoint queries the CPS to retrieve the PASSporT provisioned by the + first gateway. If the call ultimately returns to a SIP environment, + it might be the gateway from the PSTN back to the Internet that + retrieves the PASSporT from the CPS and attaches it to the new SIP + INVITE it creates, or it might be the terminating administrative + domain's verification service that checks the CPS when an INVITE + arrives with no Identity header field. Either way, the PASSporT can + survive the gap in SIP coverage caused by the PSTN leg of the call. + +5.5. Case 5: Enterprise Call Center + + A call originates from a mobile user, and a STIR authentication + service operated by their carrier creates a PASSporT for the call. + As the carrier forwards the call via SIP, it attaches the PASSporT to + the SIP call with an Identity header field. As a fallback in case + the call will not go end-to-end over SIP, the carrier also stores the + PASSporT in a CPS. + + The call is then routed over SIP for a time, before it transitions to + the 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 + has a high-volume interface to a CPS to retrieve PASSporTs for + incoming calls; agents at the call center use a general purpose + computer to manage inbound calls and can receive STIR notifications + through it. When the PASSporT arrives at the CPS, it is sent through + a subscription/notification interface to a system that can correlate + incoming calls with valid PASSporTs. The call center agent sees that + a valid call from the originating number has arrived. + +6. Storing and Retrieving PASSporTs + + The use cases show a variety of entities accessing the CPS to store + and retrieve PASSporTs. The question of how the CPS authorizes the + storage and retrieval of PASSporTs is thus a key design decision in + the architecture. The STIR architecture assumes that service + providers and, in some cases, end-user devices will have credentials + suitable for attesting authority over telephone numbers per + [RFC8226]. These credentials provide the most obvious way that a CPS + can authorize the storage and retrieval of PASSporTs. However, as + use cases 3, 4, and 5 in Section 5 show, it may sometimes make sense + for the entity storing or retrieving PASSporTs to be an intermediary + rather than a device associated with either the originating or + terminating side of a call; those intermediaries often would not have + access to STIR credentials covering the telephone numbers in + question. Requiring authorization based on a credential to store + PASSporTs is therefore undesirable, though potentially acceptable if + sufficient steps are taken to mitigate any privacy risk of leaking + data. + + It is an explicit design goal of this mechanism to minimize the + potential privacy exposure of using a CPS. Ideally, the out-of-band + mechanism should not result in a worse privacy situation than in-band + STIR [RFC8224]: for in-band, we might say that a SIP entity is + authorized to receive a PASSporT if it is an intermediate or final + target of the routing of a SIP request. As the originator of a call + cannot necessarily predict the routing path a call will follow, an + out-of-band mechanism could conceivably even improve on the privacy + story. + + Broadly, the architecture recommended here thus is one focused on + permitting any entity to store encrypted PASSporTs at the CPS, + indexed under the called number. PASSporTs will be encrypted with a + public key associated with the called number, so these PASSporTs may + safely be retrieved by any entity because only holders of the + corresponding private key will be able to decrypt the PASSporT. This + also prevents the CPS itself from learning the contents of PASSporTs, + and thus metadata about calls in progress, which makes the CPS a less + attractive target for pervasive monitoring (see [RFC7258]). As a + first step, transport-level security can provide confidentiality from + eavesdroppers for both the storing and retrieval of PASSporTs. To + bolster the privacy story, to prevent denial-of-service flooding of + the CPS, and to complicate traffic analysis, a few additional + mechanisms are also recommended below. + +6.1. Storage + + There are a few dimensions to authorizing the storage of PASSporTs. + Encrypting PASSporTs prior to storage entails that a CPS has no way + to tell if a PASSporT is valid; it simply conveys encrypted blocks + that it cannot access itself and can make no authorization decision + based on the PASSporT contents. There is certainly no prospect for + the CPS to verify the PASSporTs itself. + + Note that this architecture requires clients that store PASSporTs to + have access to an encryption key associated with the intended called + party to be used to encrypt the PASSporT. Discovering this key + requires the existence of a key lookup service (see Section 11), + depending on how the CPS is architected; however, some kind of key + store or repository could be implemented adjacent to it and perhaps + even incorporated into its operation. Key discovery is made more + complicated by the fact that there can potentially be multiple + entities that have authority over a telephone number: a carrier, a + reseller, an enterprise, and an end user might all have credentials + permitting them to attest that they are allowed to originate calls + from a number, say. PASSporTs for out-of-band use therefore might + need to be encrypted with multiple keys in the hopes that one will be + decipherable by the relying party. + + Again, the most obvious way to authorize storage is to require the + originator to authenticate themselves to the CPS with their STIR + credential. However, since the call is indexed at the CPS under the + called number, this can weaken the privacy story of the architecture, + as it reveals to the CPS both the identity of the caller and the + callee. Moreover, it does not work for the gateway use cases + described above; to support those use cases, we must effectively + allow any entity to store PASSporTs at a CPS. This does not degrade + the anti-impersonation security of STIR, because entities who do not + possess the necessary credentials to sign the PASSporT will not be + able to create PASSporTs that will be treated as valid by verifiers. + In this architecture, it does not matter whether the CPS received a + PASSporT from the authentication service that created it or from an + intermediary gateway downstream in the routing path as in case 4 + above. However, if literally anyone can store PASSporTs in the CPS, + an attacker could easily flood the CPS with millions of bogus + PASSporTs indexed under a calling number, and thereby prevent the + called party from finding a valid PASSporT for an incoming call + buried in a haystack of fake entries. + + The solution architecture must therefore include some sort of traffic + control system to prevent flooding. Preferably, this should not + require authenticating the source, as this will reveal to the CPS + both the source and destination of traffic. A potential solution is + discussed below in Section 7.5. + +6.2. Retrieval + + For retrieval of PASSporTs, this architecture assumes that clients + will contact the CPS through some sort of polling or notification + interface to receive all current PASSporTs for calls destined to a + particular telephone number, or block of numbers. + + As PASSporTs stored at the CPS are encrypted with a key belonging to + the intended destination, the CPS can safely allow anyone to download + PASSporTs for a called number without much fear of compromising + private information about calls in progress -- provided that the CPS + always returns at least one encrypted blob in response to a request, + even if there was no call in progress. Otherwise, entities could + poll the CPS constantly, or eavesdrop on traffic, to learn whether or + not calls were in progress. The CPS MUST generate at least one + unique and plausible encrypted response to all retrieval requests, + and these dummy encrypted PASSporTs MUST NOT be repeated for later + calls. An encryption scheme needs to be carefully chosen to make + messages look indistinguishable from random when encrypted, so that + information about the called party is not discoverable from + legitimate encrypted PASSporTs. + + Because the entity placing a call may discover multiple keys + associated with the called party number, multiple valid PASSporTs may + be stored in the CPS. A particular called party who retrieves + PASSporTs from the CPS may have access to only one of those keys. + Thus, the presence of one or more PASSporTs that the called party + cannot decrypt -- which would be indistinguishable from the "dummy" + PASSporTs created by the CPS when no calls are in progress - does not + entail that there is no call in progress. A retriever likely will + need to decrypt all PASSporTs retrieved from the CPS, and may find + only one that is valid. + + In order to prevent the CPS from learning the numbers that a callee + controls, callees might also request PASSporTs for numbers that they + do not own, that they have no hope of decrypting. Implementations + could even allow a callee to request PASSporTs for a range or prefix + of numbers: a trade-off where that callee is willing to sift through + bulk quantities of undecryptable PASSporTs for the sake of hiding + from the CPS which numbers it controls. + + Note that in out-of-band call forwarding cases, special behavior is + required to manage the relationship between PASSporTs using the + diversion extension [PASSPORT-DIVERT]. The originating + authentication service encrypts the initial PASSporT with the public + encryption key of the intended destination, but once a call is + forwarded, it may go to a destination that does not possess the + corresponding private key and thus could not decrypt the original + PASSporT. This requires the retargeting entity to generate encrypted + PASSporTs that show a secure chain of diversion: a retargeting storer + SHOULD use the "div-o" PASSporT type, with its "opt" extension, as + specified in [PASSPORT-DIVERT], in order to nest the original + PASSporT within the encrypted diversion PASSporT. + +7. Solution Architecture + + In this section, we discuss a high-level architecture for providing + the service described in the previous sections. This discussion is + deliberately sketchy, focusing on broad concepts and skipping over + details. The intent here is merely to provide an overall + architecture, not an implementable specification. A more concrete + example of how this might be specified is given in Section 9. + +7.1. Credentials and Phone Numbers + + We start from the premise of the STIR problem statement [RFC7340] + that phone numbers can be associated with credentials that can be + used to attest ownership of numbers. For purposes of exposition, we + will assume that ownership is associated with the endpoint (e.g., a + smartphone), but it might well be associated with a provider or + gateway acting for the endpoint instead. It might be the case that + multiple entities are able to act for a given number, provided that + they have the appropriate authority. [RFC8226] describes a + credential system suitable for this purpose; the question of how an + entity is determined to have control of a given number is out of + scope for this document. + +7.2. Call Flow + + An overview of the basic calling and verification process is shown + below. In this diagram, we assume that Alice has the number + +1.111.555.1111 and Bob has the number +2.222.555.2222. + + Alice Call Placement Service Bob + -------------------------------------------------------------------- + + Store Encrypted PASSporT for 2.222.555.2222 -> + + Call from 1.111.555.1111 ------------------------------------------> + + + <-------------- Request PASSporT(s) + for 2.222.555.2222 + + Obtain Encrypted PASSporT --------> + (2.222.555.2222, 1.111.555.1111) + + [Ring phone with verified callerid + = 1.111.555.1111] + + 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. + The CPS then awaits retrievals for that number. + + When Alice places the call, Bob's phone would usually ring and + display Alice's number (+1.111.555.1111), which is informed by the + existing PSTN mechanisms for relaying a calling party number (e.g., + the Calling Party's Number (CIN) field of the Initial Address Message + (IAM)). Instead, Bob's phone transparently contacts the CPS and + requests any current PASSporTs for calls to his number. The CPS + responds with any such PASSporTs (or dummy PASSporTs if no relevant + ones are currently stored). If such a PASSporT exists, and the + verification service in Bob's phone decrypts it using his private + key, validates it, then Bob's phone can present the calling party + number information as valid. Otherwise, the call is unverifiable. + Note that this does not necessarily mean that the call is bogus; + because we expect incremental deployment, many legitimate calls will + be unverifiable. + +7.3. Security Analysis + + 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 + scenarios to be concerned with: + + 1. The attacker wishes to impersonate a target when no call from + that target is in progress. + + 2. The attacker wishes to substitute himself for an existing call + setup. + + If an attacker can inject fake PASSporTs into the CPS or in the + communication from the CPS to the callee, he can mount either attack. + As PASSporTs should be digitally signed by an appropriate authority + for the number and verified by the callee (see Section 7.1), this + should not arise in ordinary operations. Any attacker who is aware + of calls in progress can attempt to mount a race to substitute + themselves as described in Section 7.4. For privacy and robustness + reasons, using TLS [RFC8446] on the originating side when storing the + PASSporT at the CPS is RECOMMENDED. + + The entire system depends on the security of the credential + infrastructure. If the authentication credentials for a given number + are compromised, then an attacker can impersonate calls from that + number. However, that is no different from in-band STIR [RFC8224]. + + A secondary attack we must also prevent is denial-of-service against + the CPS, which requires some form of rate control solution that will + not degrade the privacy properties of the architecture. + +7.4. Substitution Attacks + + All that the receipt of the PASSporT from the CPS proves to the + called party is that Alice is trying to call Bob (or at least was as + of very recently) -- it does not prove that any particular incoming + call is from Alice. Consider the scenario in which we have a service + 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 shown below: + + Attacker Callback Service CPS Bob + -------------------------------------------------------------------- + Place call to Bob ----------> + (from 111.555.1111) + Store PASSporT for + CS:Bob -------------> + + Call from Attacker (forged CS caller-id info) --------------------> + + Call from CS ------------------------> X + + + <-- Retrieve PASSporT + for CS:Bob + + PASSporT for CS:Bob ------------------------> + + [Ring phone with callerid = + 111.555.1111] + + In order to mount this attack, the attacker contacts the Callback + 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 + insert an appropriate PASSporT and then initiates a call to Bob. + Because it is a valid CS injecting the PASSporT, none of the security + checks mentioned above help. However, the attacker simultaneously + 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 + 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 + mail/call waiting. + + 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. Authentication services 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 + + In order to prevent the flooding of a CPS with bogus PASSporTs, we + propose the use of "blind signatures" (see [RFC5636]). A sender will + initially authenticate to the CPS using its STIR credentials and + acquire a signed token from the CPS that will be presented later when + storing a PASSporT. The flow looks as follows: + + Sender CPS + + Authenticate to CPS ---------------------> + Blinded(K_temp) -------------------------> + <------------- Sign(K_cps, Blinded(K_temp)) + [Disconnect] + + + Sign(K_cps, K_temp) + Sign(K_temp, E(K_receiver, PASSporT)) ---> + + At an initial time when no call is yet in progress, a potential + client connects to the CPS, authenticates, and sends a blinded + version of a freshly generated public key. The CPS returns a signed + version of that blinded key. The sender can then unblind the key and + get a signature on K_temp from the CPS. + + Then later, when a client wants to store a PASSporT, it connects to + the CPS anonymously (preferably over a network connection that cannot + be correlated with the token acquisition) and sends both the signed + K_temp and its own signature over the encrypted PASSporT. The CPS + verifies both signatures and, if they verify, stores the encrypted + passport (discarding the signatures). + + This design lets the CPS rate limit how many PASSporTs a given sender + can store just by counting how many times K_temp appears; perhaps CPS + policy might reject storage attempts and require acquisition of a new + K_temp after storing more than a certain number of PASSporTs indexed + under the same destination number in a short interval. This does + not, of course, allow the CPS to tell when bogus data is being + provisioned by an attacker, simply the rate at which data is being + provisioned. Potentially, feedback mechanisms could be developed + that would allow the called parties to tell the CPS when they are + receiving unusual or bogus PASSporTs. + + This architecture also assumes that the CPS will age out PASSporTs. + A CPS SHOULD NOT keep any stored PASSporT for longer than the + recommended freshness policy for the "iat" value as described in + [RFC8224] (i.e., sixty seconds) unless some local policy for a CPS + deployment requires a longer or shorter interval. Any reduction in + this window makes substitution attacks (see Section 7.4) harder to + mount, but making the window too small might conceivably age + PASSporTs out while a heavily redirected call is still alerting. + + An alternative potential approach to blind signatures would be the + use of verifiable oblivious pseudorandom functions (VOPRFs, per + [PRIVACY-PASS]), which may prove faster. + +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 (AS) + + 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 some 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 into the calling device, for example, this is the same check + performed in Step 1: does the calling device hold a private key, one + corresponding to a STIR certificate, that can sign for the + originating identity? + + Step 3: The authentication service MUST acquire the public encryption + key of the destination, which will be used to encrypt the PASSporT + (see Section 11). It MUST also discover (see Section 10) the CPS + associated with the destination. The authentication service may + already have the encryption key and destination CPS cached, or may + need to query a service to acquire the key. Note that per + Section 7.5, 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 encryption 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 be 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 a cleartext version rather than an encrypted version sent to + the CPS. In that case, out-of-band would serve as a fallback + mechanism if 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 (VS) + + 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; or alternatively it may + receive PASSporTs through a push interface from the CPS in some + deployments. 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 calling party 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 [RFC8225]. + + Finally, the verification service will end up with one or more valid + PASSporTs corresponding to the call it has received. In keeping with + baseline STIR, this document does not dictate any particular + treatment of calls that have valid PASSporTs associated with them; + the handling of the call 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 user + agent implementations. + +8.3. Gateway Placement Services + + The STIR 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 field, extract a + 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 + 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 of + Section 8.1, 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. Example HTTPS Interface to the CPS + + As a rough example, we show a CPS implementation here that uses a + Representational State Transfer (REST) API [REST] 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.555.2222 (note that + these are dummy values): + + eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 + jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI + jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 + IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd + 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ + + Through some discovery mechanism (see Section 10), the authentication + service discovers the network location of a web service that acts as + the CPS for 2.222.555.2222. Through the same mechanism, we will say + that it has also discovered one public encryption key for that + destination. It uses that encryption 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.555.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 contacts + its CPS to ask for the set of incoming calls for its telephone number + (2.222.222.2222). + + GET /cps/2.222.555.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.555.2222/ppts/ppt1/ which yields: + + HTTP/1.1 200 OK + Content-Type: application/passport + Link: <https://cps.example.com/cps/2.222.555.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. A complete protocol description for CPS interactions + is left to future work. + +10. CPS Discovery + + 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 + objects from it based solely on the rendezvous information available: + the calling party number and the called number. Because the storage + 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 as well. There are a number of potential service discovery + mechanisms that could be used for this purpose. The means of service + discovery may vary by use case. + + Although the discussion above is written largely in terms of a single + CPS, having a significant fraction of all telephone calls result in + storing and retrieving PASSporTs at a single monolithic CPS has + obvious scaling problems, and would as well allow the CPS to gather + metadata about a very wide set of callers and callees. These issues + can be alleviated by operational models with a federated CPS; any + service discovery mechanism for out-of-band STIR should enable + federation of the CPS function. Likely models include ones where a + carrier operates one or more CPS instances on behalf of its + customers, an enterprise runs a CPS instance on behalf of its PBX + users, or a third-party service provider offers a CPS as a cloud + service. + + Some service discovery possibilities under consideration include the + following: + + For some deployments in closed (e.g., intra-network) 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 + Section 11), the CPS location can also be recorded in the callee's + credentials; an extension to [RFC8226] could, for example, provide + a link to the location of the CPS where PASSporTs should be stored + for a destination. + + There exist a number of common directory systems that might be + used to translate telephone numbers into the URIs of a CPS. ENUM + [RFC6116] is commonly implemented, though no "golden root" central + ENUM administration exists that could be easily reused today to + help the endpoints discover a common CPS. Other protocols + associated with queries for telephone numbers, such as the + Telephone-Related Information (TeRI) protocol [MODERN-TERI], could + also serve for this application. + + Another possibility is to use a single distributed service for + this function. Verification Involving PSTN Reachability (VIPR) + [VIPR-OVERVIEW] proposed a REsource LOcation And Discovery + (RELOAD) [RFC6940] usage for telephone numbers to help direct + calls to enterprises on the Internet. It would be possible to + describe a similar RELOAD usage to identify the CPS where calls + for a particular telephone number should be stored. One advantage + that the STIR architecture has over VIPR is that it assumes a + credential system that proves authority over telephone numbers; + those credentials could be used to determine whether or not a CPS + could legitimately claim to be the proper store for a given + telephone number. + + This document does not prescribe any single way to do service + discovery for a CPS; it is envisioned that initial deployments will + provision the location of the CPS at the authentication service and + verification service. + +11. Encryption Key Lookup + + 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 + uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for + signing PASSporTs, the public key used to verify PASSporTs is not + suitable for this function, and thus the encryption key must be + discovered separately. This requires some sort of directory/lookup + system. + + Some initial STIR deployments have fielded certificate repositories + so that verification services can acquire the signing credentials for + PASSporTs, which are linked through a URI in the "x5u" element of the + PASSporT. These certificate repositories could clearly be repurposed + for allowing authentication services to download the public + encryption key for the called party -- provided they can be + discovered by calling parties. This document does not specify any + particular discovery scheme, but instead offers some general guidance + about potential approaches. + + It is a desirable property that the public encryption key for a given + party be linked to their STIR credential. An Elliptic Curve + Diffie-Hellman (ECDH) [RFC7748] public-private key pair might be + generated for a subcert [TLS-SUBCERTS] of the STIR credential. That + subcert could be looked up along with the STIR credential of the + called party. Further details of this subcert, and the exact lookup + mechanism involved, are deferred for future protocol work. + + Obviously, if there is a single central database that the caller and + callee each access in real time to download the other's keys, then + this represents a real privacy risk, as the central key database + learns about each call. A number of mechanisms are potentially + available to mitigate this: + + Have endpoints pre-fetch keys for potential counterparties (e.g., + their address book or the entire database). + + Have caching servers in the user's network that proxy their + fetches and thus conceal the relationship between the user and the + keys they are fetching. + + Clearly, there is a privacy/timeliness trade-off in that getting up- + to-date knowledge about credential validity requires contacting the + credential directory in real-time (e.g., via the Online Certificate + Status Protocol (OCSP) [RFC6960]). This is somewhat mitigated for + the caller's credentials in that he can get short-term credentials + right before placing a call which only reveals his calling rate, but + not who he is calling. Alternately, the CPS can verify the caller's + credentials via OCSP, though of course this requires the callee to + trust the CPS's verification. This approach 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 callee's credentials and + regularly poll the database for every potential caller. + + We consider the exact best point in the trade-off space to be an open + issue. + +12. IANA Considerations + + This document has no IANA actions. + +13. Privacy Considerations + + Delivering PASSporTs out-of-band offers a different set of privacy + properties than traditional in-band STIR. In-band operations convey + PASSporTs as headers in SIP messages in cleartext, which any + forwarding intermediaries can potentially inspect. By contrast, out- + of-band STIR stores these PASSporTs at a service after encrypting + them as described in Section 6, effectively creating a path between + the authentication and verification service in which the CPS is the + sole intermediary, but the CPS cannot read the PASSporTs. + Potentially, out-of-band PASSporT delivery could thus improve on the + privacy story of STIR. + + The principle actors in the operation of out-of-band are the AS, VS, + and CPS. The AS and VS functions differ from baseline behavior + [RFC8224], in that they interact with a CPS over a non-SIP interface, + of which the REST interface in Section 9 serves as an example. Some + out-of-band deployments may also require a discovery service for the + CPS itself (Section 10) and/or encryption keys (Section 11). Even + with encrypted PASSporTs, the network interactions by which the AS + and VS interact with the CPS, and to a lesser extent any discovery + services, thus create potential opportunities for data leakage about + calling and called parties. + + The process of storing and retrieving PASSporTs at a CPS can itself + reveal information about calls being placed. The mechanism takes + care not to require that the AS authenticate itself to the CPS, + relying instead on a blind signature mechanism for flood control + prevention. Section 7.4 discusses the practice of storing "dummy" + PASSporTs at random intervals to thwart traffic analysis, and as + Section 8.2 notes, a CPS is required to return a dummy PASSporT even + if there is no PASSporT indexed for that calling number, which + similarly enables the retrieval side to randomly request PASSporTs + when there are no calls in progress. Note that the caller's IP + address itself leaks information about the caller. Proxying the + storage of the CPS through some third party could help prevent this + attack. It might also be possible to use a more sophisticated system + such as Riposte [RIPOSTE]. These measures can help to mitigate + information disclosure in the system. In implementations that + require service discovery (see Section 10), perhaps through key + discovery (Section 11), similar measures could be used to make sure + that service discovery does not itself disclose information about + calls. + + Ultimately, this document only provides a framework for future + implementation of out-of-band systems, and the privacy properties of + a given implementation will depend on architectural assumptions made + in those environments. More closed systems for intranet operations + may adopt a weaker security posture but otherwise mitigate the risks + of information disclosure, whereas more open environments will + require careful implementation of the practices described here. + + For general privacy risks associated with the operations of STIR, + also see the privacy considerations covered in Section 11 of + [RFC8224]. + +14. Security Considerations + + This entire document is about security, but the detailed security + properties will vary depending on how the framework is applied and + deployed. General guidance for dealing with the most obvious + security challenges posed by this framework is given in Sections 7.3 + and 7.4, along proposed solutions for problems like denial-of-service + attacks or traffic analysis against the CPS. + + Although there are considerable security challenges associated with + widespread deployment of a public CPS, those must be weighed against + the potential usefulness of a service that delivers a STIR assurance + without requiring the passage of end-to-end SIP. 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 launched its own + call with a copy of that PASSporT to race against the original to the + destination. + +15. Informative References + + [MODERN-TERI] + Peterson, J., "An Architecture and Information Model for + Telephone-Related Information (TeRI)", Work in Progress, + Internet-Draft, draft-ietf-modern-teri-00, 2 July 2018, + <https://tools.ietf.org/html/draft-ietf-modern-teri-00>. + + [PASSPORT-DIVERT] + Peterson, J., "PASSporT Extension for Diverted Calls", + Work in Progress, Internet-Draft, draft-ietf-stir- + passport-divert-09, 13 July 2020, + <https://tools.ietf.org/html/draft-ietf-stir-passport- + divert-09>. + + [PRIVACY-PASS] + Davidson, A. and N. Sullivan, "The Privacy Pass Protocol", + Work in Progress, Internet-Draft, draft-privacy-pass-00, 3 + November 2019, + <https://tools.ietf.org/html/draft-privacy-pass-00>. + + [REST] Fielding, R., "Architectural Styles and the Design of + Network-based Software Architectures, Chapter 5: + Representational State Transfer", Ph.D. + Dissertation, University of California, Irvine, 2010. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, + "Traceable Anonymous Certificate", RFC 5636, + DOI 10.17487/RFC5636, August 2009, + <https://www.rfc-editor.org/info/rfc5636>. + + [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to + Uniform Resource Identifiers (URI) Dynamic Delegation + Discovery System (DDDS) Application (ENUM)", RFC 6116, + DOI 10.17487/RFC6116, March 2011, + <https://www.rfc-editor.org/info/rfc6116>. + + [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., + and H. Schulzrinne, "REsource LOcation And Discovery + (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, + January 2014, <https://www.rfc-editor.org/info/rfc6940>. + + [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., + Galperin, S., and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - OCSP", + RFC 6960, DOI 10.17487/RFC6960, June 2013, + <https://www.rfc-editor.org/info/rfc6960>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure + Telephone Identity Problem Statement and Requirements", + RFC 7340, DOI 10.17487/RFC7340, September 2014, + <https://www.rfc-editor.org/info/rfc7340>. + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, <https://www.rfc-editor.org/info/rfc7748>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, + "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>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RIPOSTE] Corrigan-Gibbs, H., Boneh, D., and D. Mazières, "Riposte: + An Anonymous Messaging System Handling Millions of Users", + May 2015, <https://people.csail.mit.edu/henrycg/pubs/ + oakland15riposte/>. + + [TLS-SUBCERTS] + Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, + "Delegated Credentials for TLS", Work in Progress, + Internet-Draft, draft-ietf-tls-subcerts-10, 24 January + 2021, + <https://tools.ietf.org/html/draft-ietf-tls-subcerts-10>. + + [VIPR-OVERVIEW] + Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- + Huguenin, "Verification Involving PSTN Reachability: + Requirements and Architecture Overview", Work in Progress, + Internet-Draft, draft-jennings-vipr-overview-06, 9 + December 2013, <https://tools.ietf.org/html/draft- + jennings-vipr-overview-06>. + +Acknowledgments + + The ideas in this document came out of discussions with Richard + Barnes and Cullen Jennings. We'd also like to thank Russ Housley, + Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, + Jonathan Rosenberg, and Robert Sparks for helpful suggestions. + +Authors' Addresses + + Eric Rescorla + Mozilla + + Email: ekr@rtfm.com + + + Jon Peterson + Neustar, Inc. + 1800 Sutter St Suite 570 + Concord, CA 94520 + United States of America + + Email: jon.peterson@team.neustar |