draft-ietf-stir-oob-02.txt   draft-ietf-stir-oob-03.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: September 6, 2018 Neustar Expires: January 3, 2019 Neustar
March 5, 2018 July 2, 2018
STIR Out-of-Band Architecture and Use Cases STIR Out-of-Band Architecture and Use Cases
draft-ietf-stir-oob-02.txt draft-ietf-stir-oob-03.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 September 6, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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. Authentication and Verification Service Behavior for Out-of- 8. Authentication and Verification Service Behavior for Out-of-
Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Authentication Service . . . . . . . . . . . . . . . . . 14 8.1. Authentication Service . . . . . . . . . . . . . . . . . 14
8.2. Verification Service . . . . . . . . . . . . . . . . . . 16 8.2. Verification Service . . . . . . . . . . . . . . . . . . 16
8.3. Gateway Placement Services . . . . . . . . . . . . . . . 17 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 17
9. HTTPS Interface to the CPS . . . . . . . . . . . . . . . . . 17 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 17
10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 19 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 20 11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
15. Informative References . . . . . . . . . . . . . . . . . . . 21 15. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
skipping to change at page 11, line 31 skipping to change at page 11, line 31
associated with the called party number, multiple valid PASSporTs may associated with the called party number, multiple valid PASSporTs may
be stored in the CPS. A particular called party who retrieves be stored in the CPS. A particular called party who retrieves
PASSporTs from the CPS may have access to only one of those keys. PASSporTs from the CPS may have access to only one of those keys.
Thus, the presence of one or more PASSporTs that the called party Thus, the presence of one or more PASSporTs that the called party
cannot decrypt - which would be indistinguishable from the "dummy" cannot decrypt - which would be indistinguishable from the "dummy"
PASSporTS created by the CPS when no calls are in progress - does not PASSporTS created by the CPS when no calls are in progress - does not
entail that there is no call in progress. A retriever likely will entail that there is no call in progress. A retriever likely will
need decrypt all PASSporTs retrieved from the CPS, and may find only need decrypt all PASSporTs retrieved from the CPS, and may find only
one that is valid. one that is valid.
Note that in call forwarding cases, the difficulties in managing the Note that in out-of-band call forwarding cases, special behavior is
relationship between PASSporTs with the diversion extension required to manage the relationship between PASSporTs using the
[I-D.ietf-stir-passport-divert] become more serious. The originating diversion extension [I-D.ietf-stir-passport-divert]. The originating
authentication service would encrypt the PASSporT with the public key authentication service would encrypt the initial PASSporT with the
of the intended destination, but when a call is forwarded, it may go public key of the intended destination, but once a call is forwarded,
to a destination that does not possess the corresponding private key. it may go to a destination that does not possess the corresponding
This requires special behavior on the part of the retargeting entity, private key and thus could not decrypt the original PASSporT. This
and probably the CPS as well, to accommodate encrypted PASSporTs that requires the retargeting entity to generated encrypted PASSporTs that
show a secure chain of diversion. A storer could for example notify show a secure chain of diversion: a retargeting storer SHOULD use the
the CPS that the divert PASSporT it is storing relates to a specific "opt" extension to "div" specified in [I-D.ietf-stir-passport-divert]
PASSporT already in the CPS, but in so doing, the storer will in order to nest the original PASSporT within the encrypted diversion
inevitably reveal more metadata to the CPS. PASSporT.
7. Solution Architecture 7. Solution Architecture
In this section, we discuss a strawman architecture for providing the In this section, we discuss a high-level architecture for providing
service described in the previous sections. This discussion is the service described in the previous sections. This discussion is
deliberately sketchy, focusing on broad concepts and skipping over deliberately sketchy, focusing on broad concepts and skipping over
details. The intent here is merely to provide an overall details. The intent here is merely to provide an overall
architecture, not an implementable specification. 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 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
skipping to change at page 17, line 30 skipping to change at page 17, line 30
a PASSporT storage token (see Section 6.1). Per Step 3 this may a PASSporT storage token (see Section 6.1). Per Step 3 this may
entail discovering several keys. The gateway then collects the in- entail discovering several keys. The gateway then collects the in-
band PASSporT(s) from the in-band signaling, encrypts the band PASSporT(s) from the in-band signaling, encrypts the
PASSporT(s), and stores them at the CPS. PASSporT(s), and stores them at the CPS.
A similar service could be performed by a gateway that retrieves A similar service could be performed by a gateway that retrieves
PASSporTs from a CPS and inserts them into signaling protocols that PASSporTs from a CPS and inserts them into signaling protocols that
support carrying PASSporTS in-band. This behavior may be defined by support carrying PASSporTS in-band. This behavior may be defined by
future specifications. future specifications.
9. HTTPS Interface to the CPS 9. Example HTTPS Interface to the CPS
The default Call Placement Service implementation uses a REST API to As an rough example, we should a Call Placement Service
store and retrieve objects at the CPS. The calling party stores the implementation here which uses a REST API to store and retrieve
PASSporT at the CPS prior to initiating the call; the PASSporT is objects at the CPS. The calling party stores the PASSporT at the CPS
stored at a location at the CPS that corresponds to the called prior to initiating the call; the PASSporT is stored at a location at
number. Note that it is possible for multiple parties to be calling the CPS that corresponds to the called number. Note that it is
a number at the same time, and that for called numbers such as large possible for multiple parties to be calling a number at the same
call centers, many PASSporTs could legitimately be stored time, and that for called numbers such as large call centers, many
simultaneously, and it might prove difficult to correlate these with PASSporTs could legitimately be stored simultaneously, and it might
incoming calls. prove difficult to correlate these with incoming calls.
Assume that an authentication service has created the following Assume that an authentication service has created the following
PASSporT for a call to the telephone number 2.222.222.2222: [TBD - PASSporT for a call to the telephone number 2.222.222.2222 (note that
these are currently dummy values, will mock up real examples later] these are dummy values):
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz
aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI
jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1
VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w
Through some out-of-band mechanism (see Section 10) the Through some discovery mechanism (see Section 10), the authentication
authentication service discovers the network location of a web service discovers the network location of a web service that acts as
service that acts as the CPS for 2.222.222.2222. Through the same the CPS for 2.222.222.2222. Through the same mechanism, we will say
mechanism, we will say that it has also discovered one public key for that it has also discovered one public key for that destination. It
that destination. It uses that public key to encrypt the PASSporT, uses that public key to encrypt the PASSporT, resulting in the
resulting in the encrypted PASSporT: encrypted PASSporT:
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
Having concluded the numbered steps in Section 8.1, including Having concluded the numbered steps in Section 8.1, including
acquiring any token (per Section 6.1) needed to store the PASSporT at acquiring any token (per Section 6.1) needed to store the PASSporT at
the CPS, the authentication service then stores the encrypted the CPS, the authentication service then stores the encrypted
skipping to change at page 19, line 17 skipping to change at page 19, line 17
Link: <https://cps.example.com/cps/2.222.222.2222/ppts> Link: <https://cps.example.com/cps/2.222.222.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
That concludes Step 1 of Section 8.2; the verification service then That concludes Step 1 of Section 8.2; the verification service then
goes on to the next step, processing that PASSporT through its goes on to the next step, processing that PASSporT through its
various checks. various checks. A complete protocol description for CPS interactions
is left to future work.
10. CPS Discovery 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
skipping to change at page 20, line 21 skipping to change at page 20, line 22
proposed a RELOAD [RFC6940] usage for telephone numbers to help proposed a RELOAD [RFC6940] usage for telephone numbers to help
direct calls to enterprises on the Internet. It would be possible direct calls to enterprises on the Internet. It would be possible
to describe a similar RELOAD usage to identify the CPS where calls to describe a similar RELOAD usage to identify the CPS where calls
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 This document does not prescribe any single way to do service
discovery mechanisms for out-of-band STIR. discovery for a CPS; it is envisioned that initial deployments will
provision at the AS and VS.
11. 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
skipping to change at page 21, line 32 skipping to change at page 21, line 34
14. Security Considerations 14. Security Considerations
This entire document is about security, but the detailed security This entire document is about security, but the detailed security
properties depend on having a single concrete scheme to analyze. properties depend on having a single concrete scheme to analyze.
15. Informative References 15. Informative References
[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-01 (work in progress), draft-ietf-stir-passport-divert-02 (work in progress),
October 2017. March 2018.
[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-04 (work in progress), March 2018.
[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-
overview-04 (work in progress), October 2010. overview-04 (work in progress), October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
 End of changes. 15 change blocks. 
44 lines changed or deleted 47 lines changed or added

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