Internet DRAFT - draft-kaplan-stir-fried
draft-kaplan-stir-fried
STIR Working Group H. Kaplan
Internet Draft Oracle
Intended status: Informational September 3, 2013
Expires: March 30, 2014
Secure Telephone Identity Revisited (STIR)
Frequently Repeated Information and Explanation Document (FRIED)
draft-kaplan-stir-fried-00
Abstract
This document is a type of FAQ (Frequently Asked Questions) for new
STIR Working Group participants. Since its inception three months
ago there have been over 1,500 emails on the mailing list, before
the WG was even formed. Some of the emails repeat topics, because
newcomers cannot be expected to read all previous emails in the
archive. This document is an attempt to capture some of the
previously asked and answered questions.
This document is written by one individual, is not intended to be
published as an RFC, and is only meant as a temporary FAQ while the
Working Group begins. The document attempts to provide both high-
level information for non-experts, as well as low-level information
for protocol experts.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Kaplan Expires March 2014 [Page 1]
Internet-Draft STIR FRIED September 2013
This Internet-Draft will expire on March 3, 2014.
Copyright Notice
Copyright (c) 2013 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
(http://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..................................................4
2. Terminology...................................................4
3. Background....................................................5
3.1. What's the general problem?..............................5
3.2. Aren't there existing solutions to this problem?.........5
3.3. Can't we use other info to detect robocalls?.............6
3.4. What's STIR trying to solve then?........................7
3.5. Is STIR sufficient to stop robocalls or fraud?...........7
3.6. Why focus on calling number, vs. other identities?.......7
3.7. Hasn't it always been possible to fake caller-id?........8
3.8. Why are the attacks growing now?.........................8
3.9. Is this a USA-specific problem?..........................8
3.10. Why will carriers adopt this?...........................8
3.11. Will countries do this for international calls to others?9
3.12. Isn't this the same problem email has for spam?........10
3.13. What scale does a solution need to achieve?............10
4. Behavioral changes...........................................11
4.1. Will invalid calling numbers be blocked?................11
4.2. Will calls from non-STIR-enabled carriers be blocked?...11
4.3. What difference or changes will consumers see?..........11
4.4. Will this prevent legitimate caller-agent calls?........12
4.5. Will doctors still be able to use their office number?..12
4.6. Will this prevent legitimate out-sourced call-centers?..13
4.7. Who needs to implement this new technology?.............13
4.8. What other industry organizations are involved?.........13
5. Calling Number vs. Calling Name..............................13
5.1. What is "calling number" vs. "calling name"?............13
5.2. Why isn't STIR validating calling names?................13
Kaplan Expires March 2014 [Page 2]
Internet-Draft STIR FRIED September 2013
5.3. Why is it hard to validate calling names?...............14
6. Privacy......................................................14
6.1. Does STIR impact privacy?...............................15
6.2. How do anonymous calls work with STIR?..................15
6.3. But can't the carrier still determine the caller?.......15
6.4. Why do we need to hide the carrier's identity?..........15
6.5. Why do we need to hide subscriber identity info?........16
6.6. Why do we need to hide subscriber reachability info?....16
7. Solutions....................................................16
7.1. What are the proposed solutions so far, at a high-level?16
7.2. What does "in-band" vs. "out-of-band" mean?.............17
7.3. Why are there both an in-band and out-of-band solution?.17
7.4. Why can't we just do P-Asserted-Identity without STIR?..18
7.5. Why can't we just sign using a carrier-wide identity?...18
7.6. Why are we only focused on SIP?.........................19
7.7. What about other IP-based protocols?....................19
7.8. What SIP header is used for the calling number?.........19
7.9. Doesn't the SIP From or To URI string change along the path?
20
7.10. Does STIR crypto-sign the SIP From and To URI headers?.20
7.11. Does STIR change SIP From or To URI headers?...........21
8. In-band Solution Questions...................................21
8.1. Don't we already have in-band with RFC 4474 SIP Identity?21
8.2. What will happen to RFC 4474?...........................21
8.3. What are the proposed in-band solutions so far?.........21
8.4. Why not just carry a certificate in the SIP message?....22
9. Out-of-band Solution Questions...............................23
9.1. What are the proposed out-of-band solutions?............23
9.2. What are the major advantages of an out-of-band solution?23
9.3. What are the major disadvantages of an out-of-band solution?
23
10. Security Considerations.....................................23
10.1. What types of attackers are we worried about?..........23
10.2. What are the main threats we are worried about?........24
10.3. What types of DoS attacks are we worried about?........24
10.4. What types of cut-and-paste attacks are we worried about?25
10.5. Why are we not worried about MITM attacks?.............26
10.6. Why are we not worried about replay attacks?...........26
10.7. Is the call media (audio or video) secured by STIR?....26
11. General Security Terminology................................27
11.1. What is a private vs. public key?......................27
11.2. What does "cryptographically sign" mean?...............28
11.3. What is a certificate?.................................28
11.4. What is a PKI?.........................................29
11.5. What is a Web-PKI?.....................................30
11.6. What is wrong with the Web-PKI?........................30
11.7. What is an RPKI?.......................................31
11.8. What is DKIM?..........................................31
11.9. What is DNSSEC?........................................32
Kaplan Expires March 2014 [Page 3]
Internet-Draft STIR FRIED September 2013
11.10. Which security model is STIR going to use?............33
12. Glossary....................................................33
13. IANA Considerations.........................................36
14. Acknowledgments.............................................36
15. References..................................................36
15.1. Informative References.................................36
Author's Address.................................................37
1. Introduction
The IETF process for forming new Working Groups involves getting a
group of interested individuals from various backgrounds together to
define a problem and discuss possible solutions. There is a defined
process for forming the actual Working Group, but in general a
mailing list is created in advance so that interested individuals
can discuss things prior to the formal creation of the Working
Group. Typically, prior to being a Working Group the volume of
emails in the list, and number of participants, is not high. For
STIR, that has not been the case: there have been over 1500 emails
in the span of three months.
Since the STIR Working Group expects new participants to join in the
near future, repeating some of the more common questions and
background information is not efficient. It is hoped that this
document avoids some duplication of questions and answers that might
occur.
Usually Working Groups create formal overview documents and problem
statements and so on as official Working Group documents. That will
likely occur for STIR as well, but that takes time and rarely
explains things in concrete real-world terms non-experts can
understand. This document is a less formal approach, using a FAQ-
type model.
This is an Individual-Draft and the content is only based on the
view of one individual (the author).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
See section 12 for a glossary of terms related to STIR.
Kaplan Expires March 2014 [Page 4]
Internet-Draft STIR FRIED September 2013
3. Background
3.1. What's the general problem?
The problem that drove the IETF to form the STIR Working Group is
the growth in unsolicited calls in the PSTN - whether it is calls to
legacy POTS landlines, mobile phones, VoIP-based phones, business
lines, etc. The United States Federal Communications Commission
(FCC) approached several active IETF participants with expertise in
this area, to discuss the problem. The group determined that a
necessary piece was missing from any possible solution: the validity
of the source telephone number. The IETF formed a Working Group
with the goal of addressing that problem. STIR is that Working
Group.
Some people have described the problem as "robocallers", but that
term includes automated dialers used for telemarketing, political,
emergency, and other types of legitimate automated calls. The real
problem is both benign and malicious parties making phone calls to
people that don't want to receive their calls. Thus it's both
legitimate telemarketing-type calls, as well as malicious calls made
for the purpose of fraud, blackmail, etc. The number of such
malicious cases has risen dramatically in recent years, leading to
growing dissatisfaction and in some cases significant loss of money
or even potential loss of life [ems-attacks].
Note that the STIR work is not aimed at blocking "legitimate"
automated dialers, as that requires regulatory policy decisions, not
just technical mechanisms. STIR's focus is quite narrow, as
described in Section 3.4.
3.2. Aren't there existing solutions to this problem?
No. Numerous solutions have been attempted to combat such attacks,
with varying levels of success. The United States Federal Trade
Commission (FTC) even sponsored an open "Robocall Challenge" for
solutions to prevent illegal robocalls [robo-challenge].
Every solution proposed to solve the problem, however, ultimately
ends up creating some form of whitelist and/or blacklist reputation
model; in some cases the lists are created from crowd-sourced
reputations, in some cases from captcha-type tests, and in others
from a pay-to-play model.
Regardless of any solution's merits, or how the whitelist/blacklist
is created, in the end they all rely on the ability to match future
call attempts to some form of "list" to decide whether the call
attempt is good or bad. Therefore, all any attacker has to do is
generate a call attempt that either looks like a good actor on the
Kaplan Expires March 2014 [Page 5]
Internet-Draft STIR FRIED September 2013
whitelist, or does not look like a bad actor on the blacklist.
Doing so is fairly trivial today in the PSTN, both in SIP and SS7-
based technologies. Robocallers can generate constantly random
Caller-IDs to avoid blacklists, and can spoof known good Caller-IDs
to match whitelists.
In general, most solutions use the source telephone number of the
call (the calling party number) carried by the protocol signaling to
determine which list a call belongs in. Obviously this is only
useful if the calling number is in fact available and legitimate:
that it truly identifies the call originator, that it is not being
randomly changed for every call, and is not spoofing a legitimate
user.
A fundamental requirement of any solution to robocall-type attacks,
therefore, is for the called parties or their service providers to
have a means of verifying the source identity of received call
attempts.
Note that verifying source identity is not, by itself, sufficient to
solve the attacks. It is only a necessary precursor: a tool that
can be used to then build actual solutions with, such as reputation-
based systems; or it might even just be useful in tracing back the
source and securing their entry-path in order to prevent future
attacks. Clearly a legitimate/valid source number does not prove
the caller does not have malicious intentions.
3.3. Can't we use other info to detect robocalls?
Some existing solutions use more than just the calling number
information to classify calls, such as the peering trunk the call
was received from; but using any other information is going to fail
as well, ultimately. Using additional information may work for
specific service providers today, but that is more due to the nature
of their particular robocaller attacks today, and the nature of
those specific service provider deployments today. If many large
service providers were to try using additional information to
prevent robocallers, the nature of the attacks would quickly change
to bypass the filter-rules.
In general, calls arriving at carriers from peering interconnections
contain virtually no distinguishing data. Part of the reason for
this is due to the way legacy SS7 technology works; part of it is
due to the way interconnection has grown in the past decade. The
only truly distinguishing data is the calling number, whether it is
the number to be displayed or the billing number. Even tracking the
transit carrier trunk the call comes in from is not sufficient to
distinguish legitimate vs. malicious calls; legitimate calls from
Kaplan Expires March 2014 [Page 6]
Internet-Draft STIR FRIED September 2013
the same source number can arrive from different transit peers, and
often do today.
3.4. What's STIR trying to solve then?
The problem that STIR focuses on is not how to prevent attacks or
unsolicited calls in the PSTN-type network, but rather how to
validate the source telephone number of call requests; the source
telephone number that would be used for Caller-ID display, Calling
name (LIDB or CNAM) lookups, billing, or similar functions. The
source number may represent a specific human or device, or it may
represent a corporation or service.
In this context, the STIR goal is to determine whether the
originating device or system is authorized to use the source
telephone number identity claimed in a given request. In other
words: when someone makes a call using a telephone number, can they
really claim to represent that number?
If we can get that problem solved, then we can use that knowledge as
a tool to build reputation systems and other techniques to truly
prevent malicious attacks; as well as allow people to use other
means to block unsolicited legitimate calls. It also gives us a
tool to help track down the offending parties more quickly or
easily.
3.5. Is STIR sufficient to stop robocalls or fraud?
No. It's a necessary piece of the puzzle, but by itself STIR won't
stop them. See the answer to question 3.4. Note also that STIR
just verifies the calling number is valid; malicious parties can
still obtain valid E.164 numbers and use them to attack. For
example, in some countries one can buy SIM cards in bulk or in
vending machines without any identification, and then use the SIM
cards in SIM-boxes to perform bulk calling. Each call would use a
valid E.164 calling number of the SIM card.
3.6. Why focus on calling number, vs. other identities?
Because it's a real problem today, and telephone numbers are used by
billions of devices and people. There are many forms of identity:
calling names, email-style 'user@domain' names, social networking
usernames, trademarks, etc. But the current problem at-hand is the
"PSTN", whether it be legacy SS7-based or SIP-based, and telephone
numbers are the main form of identifier. Calling names are also
used in the PSTN, of course, but STIR is focused on the number (see
section 5).
Kaplan Expires March 2014 [Page 7]
Internet-Draft STIR FRIED September 2013
3.7. Hasn't it always been possible to fake caller-id?
Yes. The legacy PSTN has traditionally allowed business PBXs
connected with PRI trunks to generate whatever calling number they
wanted to for outbound calls. This was, and continues to be,
necessary to allow organizations to generate calls using a main
"corporate" type number, even from third parties; for example from
outsourced call-centers and branch offices.
This requirement or need is being maintained for any STIR solution.
That's why we describe it as "an identity they're authorized to use"
instead of as "their identity" - it may not be the telephone number
used to reach back to them, but it is a number they were either
directly assigned by the numbering authority, or that the real
number "owner" grants them the right to use for making calls.
3.8. Why are the attacks growing now?
Multiple factors have contributed to the growth:
o the decreasing costs of making phone calls
o the decreasing cost, complexity, time, and resources required
to connect to the PSTN trust-network with PRI-type service,
such as SIP trunks
o the growth in unregulated and over-the-top VoIP providers
o the availability of open-source software capable of making
robocalls with configurable source numbers
It should be noted that malicious robocalls are generated from
various entry points into the PSTN trust-network: for example legacy
PRI trunks, SIP and H.323 trunks, SIM-card boxes or gateways, and
subscriber VoIP accounts.
3.9. Is this a USA-specific problem?
No. The USA is one of the several countries for which the factors
listed in the answer to question 3.8 have reached large scale, so it
is one of the first to have the problem so far. It has already
become a growing problem in other countries [ofcom-work], and will
undoubtedly impact many more countries in the near future.
3.10. Why will carriers adopt this?
Besides the potential of federal regulation or mandates, there are
other motivations for carriers to implement solutions to reduce
unsolicited calls - at least malicious ones. Fraudulent and
unsolicited calls lead to widespread customer dissatisfaction, and
investigation is extremely expensive and time-consuming.
Kaplan Expires March 2014 [Page 8]
Internet-Draft STIR FRIED September 2013
In general, most paying subscribers expect the Caller-ID number they
see to be valid; and customer support is an expensive way of
handling false or invalid Caller-IDs. A loss of faith in the PSTN
impacts the value for all carriers. If it becomes like email, with
constant calls from nefarious sources, the impact will be severe.
Furthermore, some types of carrier customers even pay extra for
receiving Caller-ID number and calling name information; for example
business often pay for such services for calls they receive. If the
calling number becomes largely untrustworthy, and likewise the
calling name (which is based on the calling number), then the amount
carriers can charge for such services diminishes.
Non-malicious yet unsolicited calls are more difficult: the
originating and transit carriers have a monetary incentive to let
such calls be made, and terminating carriers frequently have a legal
obligation to let such calls reach their destination. In some
countries there are "do-not-call" lists, but not all countries have
such models and even for ones that do not all of them are strongly
enforced or enforceable. It might require regulatory policy changes
to truly block such calls.
For calls from unknown or invalid numbers, several possible actions
might occur: the numbers can be "anonymized" (shown to users as
'unknown'), or sent to voicemail, or routed to an Interactive Voice
Response (IVR) system to perform a captcha test or to explain the
problem and provide help or resolution support. These are just
examples of what might change.
Furthermore, third-party reputation systems might allow consumers
the ability to block unsolicited yet legal calls, for example
through smartphone apps that consumers can control. (see the end of
question 3.4)
3.11. Will countries do this for international calls to others?
That's unknown, but likely yes. There are some strong motivations
for them to do so. Ultimately most nations want to have their
legitimate international calls delivered, as well as have their
calling number displayed. If STIR becomes widely deployed in a
country, such as the United States, and malicious calls continue to
arrive from a given country-code, then the US carriers can start
anonymizing or outright blocking the calls.
International Telephony Denial of Service (TDOS) attacks have
already occurred against carriers in the US, with randomized
originating numbers from the foreign country-code; to stop it the
carriers throttled *all* calls from the attacking country-code until
the attack stopped. Governments should not want such measures to be
Kaplan Expires March 2014 [Page 9]
Internet-Draft STIR FRIED September 2013
adopted by other nation's carriers for their calls, for obvious
reasons.
3.12. Isn't this the same problem email has for spam?
Yes, the general problem is similar. The specifics for phone calls
are actually easier in some respects, and harder in others.
Email has a more difficult challenge because any email client can
send emails to any email server, anywhere on the Internet, directly
over IP; and they can claim any domain name they wish, even
legitimately by buying domain names for virtually free. Phone calls
are slightly easier because E.164 numbers are slightly more
difficult to acquire, and in practice there are only a limited
number of pre-established connections between carriers through which
call requests can be sent; carriers do not accept call requests from
just anyone anywhere directly.
On the other hand email has an easier time determining whether a
message is spam, because the email message contains a lot more
useful data for determining it, such as the message body of text.
If the email spam filter gets it wrong, it's not a huge deal - false
positives and false negatives are commonplace in email; if the phone
system rejects good calls, though, it can lead to lawsuits or even
loss of life.
3.13. What scale does a solution need to achieve?
World-wide, there are approximately 220 E.164 country-codes, ~20,000
carriers of various types or sizes, and on the order of ~100 Million
enterprises or businesses.
For E.164 phone numbers World-wide: there are ~7 Billion mobile
numbers in service (of which ~1.5B are smart-phones), and an
additional ~1.5 Billion numbers from land lines and other types of
phone service. The number of E.164 numbers has been growing by ~500
Million numbers per year for the past decade. The number of just
mobile numbers now exceeds the global population so the growth rate
is expected to taper off, unless they get used for other things such
as machine-to-machine (M2M) communications and if those technologies
grow.
For any given country-code, the largest one (China) has ~1.5 Billion
E.164 numbers in use; followed by India with ~1 Billion, and the USA
with ~500 Million.
Kaplan Expires March 2014 [Page 10]
Internet-Draft STIR FRIED September 2013
4. Behavioral changes
4.1. Will invalid calling numbers be blocked?
No, not initially. There will be some false positives at the
beginning, and blocking calls is a "big deal". Even if STIR works
perfectly and is deployed everywhere, it might require regulatory
policy changes for carriers to be able to actually block calls
without specific customer consent.
Instead, calls can be "anonymized" (shown to users as 'unknown'), or
sent to voicemail, or routed to an Interactive Voice Response (IVR)
system to perform a captcha test or to explain the problem and
provide help or resolution support. These are just some examples of
what might be done; the STIR Working Group standards will not
dictate what specific action to perform in such cases, but leave it
up to implementers to decide instead.
4.2. Will calls from non-STIR-enabled carriers be blocked?
No, not initially. For one thing it will take time to deploy STIR
technology, fix issues, etc.; without a "flag day" where everyone
starts using it, we can't reasonably block or even anonymize such
calls.
Once it's up and running in a few service providers, though, those
service providers may be able to determine which calling numbers
*should* be using STIR, because the technology allows that to be
known. This allows STIR-supporting service providers to "protect"
their numbers from being spoofed by malicious parties. For example
a bank can make sure no one else can falsely claim its numbers, by
having its numbers in the STIR databases.
Therefore if the service providers receive calls from such
"protected" calling numbers, and the call is not using STIR, then
that call can be anonymized, blocked, or routed to an attendant.
As more service providers implement STIR, more and more calling
numbers become "protected", and more and more calls are using STIR.
At some point, calls still not using STIR can be anonymized or
routed to an IVR; or even blocked if regulators allow it.
4.3. What difference or changes will consumers see?
The general long-term goal is to reduce the number of unsolicited
calls to consumers, and the short-term goal is to reduce and easily
trace-back malicious ones. Individual consumers might not perceive
any difference, although the number of complaints should decrease
overall.
Kaplan Expires March 2014 [Page 11]
Internet-Draft STIR FRIED September 2013
From a phone-display perspective, however, there have been
discussions on whether to add something to displays to show a
validated calling number vs. a legacy calling number. Due to
limitations of legacy POTS technology, the current Caller-ID display
is quite limited. A single character, such as the '*' asterisk or
'?' question mark might make sense to add for received calls that
don't use STIR. Alternatively, changing the number or name display
to 'unknown' has also been discussed. This topic is still under
discussion.
For calls from unknown or invalid numbers, several possible actions
might occur: the numbers can be "anonymized" (shown to users as
'unknown'), or sent to voicemail, or routed to an Interactive Voice
Response (IVR) system to perform a captcha test or to explain the
problem and provide help or resolution support. These are just
examples of what might change.
It should be noted that the STIR Working Group mechanism is not a
self-contained solution, but rather a tool to enable solutions to
achieve the long-term goals. See question 3.4.
4.4. Will this prevent legitimate caller-agent calls?
No. A caller-agent is a person or organization that makes calls on
behalf of someone else, using the calling number of the entity
they're representing. This is a generic concept, and applies to
many different real-world use-cases. For example an out-sourced
call-center making calls on behalf of a business, or a survey center
making calls on behalf of a political party or politician, or a
remote employee making calls on behalf of a company or organization.
There are many ways in which this happens today, some of which STIR
does not affect whatsoever. The one scenario that STIR affects is
when the caller-agent uses a calling number it wasn't authorized
directly by its carrier to use. The proposed solutions provide ways
to support that, but it might require the caller-agent and the
entity it represents to perform additional steps to authorize such
use. This topic is still under debate in the Working Group.
4.5. Will doctors still be able to use their office number?
Yes. The concern arise with regard to the ability to let doctors
and others to make calls using their personal phone with calling
number of their office number. This is covered in the answer to
question 4.4.
Kaplan Expires March 2014 [Page 12]
Internet-Draft STIR FRIED September 2013
4.6. Will this prevent legitimate out-sourced call-centers?
No. See the answer to question 4.4.
4.7. Who needs to implement this new technology?
In general, the target operators of the STIR in-band solutions are
the carriers. Certain types of businesses, government agencies, and
other organizations might need to implement the technology as well.
For example outbound call-centers might prefer to implement it,
rather than having their carriers do it.
4.8. What other industry organizations are involved?
Currently the participants and monitors of the STIR Working Group
include members from 3GPP, ATIS, ETSI, CableLabs, FCC, FTC, CRTC,
OFCOM, IMTC, and the SIP-Forum. The IETF has an official liaison
process but generally prefers to handle such things as informally as
possible.
The outcome of the STIR Working Group is expected to trigger changes
and additional work in some of the aforementioned organizations.
5. Calling Number vs. Calling Name
5.1. What is "calling number" vs. "calling name"?
In the STIR Working Group the source identity being validated is
really the calling telephone number, and only the number. The
"calling name" is a textual description people see when they receive
a phone call, distinct from the calling number. This is either a
human or company name, or a geographic location (e.g., city and
state). Frequently this text string is determined by the carrier
receiving the call, through either a LIDB or CNAM lookup process.
5.2. Why isn't STIR validating calling names?
Validating calling names is a much harder problem to solve, as
described in the answer to question 5.3. The scope of the STIR
Working Group is constrained to validating calling numbers, because
it is something we know we can achieve in a reasonable timeframe.
A separate mailing list has been created for a research-team to
discuss validating calling names: cnit@ietf.org. The results of
this research team might lead to an extension to STIR, or a separate
solution for calling name validation.
In the meantime, a STIR-validated calling number does improve things
even for calling name, because the calling number is typically used
Kaplan Expires March 2014 [Page 13]
Internet-Draft STIR FRIED September 2013
by the terminating carrier to determine calling name from a
database. Thus a validated calling number at least means the
calling name database lookup is querying for the right entry. Of
course if the name in the database is invalid, STIR does not help.
5.3. Why is it hard to validate calling names?
It has more challenges with regard to business pricing models; and
the existing architecture and mechanisms for calling name restrict
the types of validation solutions we could expect wide adoption for.
Even more importantly, a human or business 'name' has far more
challenges for determining validity, and will likely never be as
secure or accurate as a calling number.
With calling numbers, there is a defined authority model. At a
global level, the ITU defines country-code authority, so that
Germany can't be authoritative for UK numbers, for example. Within
each country-code the national numbering administrators are the
authority, and they assign numbers to carriers, who are then
authoritative for specific numbers, and so on. Calling numbers are
also unique, in that no two people or entities in the World have the
same number; one can be an agent representing the other, but only
one entity "owns" the number.
Calling names, on the other hand, don't have these properties.
There are many people with the same name, and many businesses with
the same name. There is no defined global authority for human or
business names; sometimes there is a name authority for a given
country, but sometimes there is not (e.g., in the US each state is
partially authoritative for business names). Even trademarks may or
may not be registered in numerous trademark databases, none of which
are authoritative globally, and multiple entities can own the same
trademark.
6. Privacy
The term "privacy" is a bit overloaded, but in the STIR context it
relates to the following separate issues:
o the ability for users to make anonymous calls to others
o hiding the caller's identity from carriers for anonymous calls
o hiding which carriers own which telephone numbers from the
general public
o hiding the identity of telephone subscribers from the general
public, including direct IP reachability information
Those issues are explained in the answer to questions in this
section.
Kaplan Expires March 2014 [Page 14]
Internet-Draft STIR FRIED September 2013
6.1. Does STIR impact privacy?
No. STIR does not make privacy any worse or better. The properties
of privacy in the PSTN (SIP or SS7) remain the same whether STIR is
deployed or not.
6.2. How do anonymous calls work with STIR?
The same way it works without STIR. Today, there are two basic
models for anonymous calls in the PSTN: a call is generated without
a calling number, or a call is generated with a calling number that
the carrier does not send or display to the receiving end. Both of
these models are already supported by SS7 and SIP, and STIR does not
change them. If a call is made without a calling number, STIR
doesn't identify anything; if a call is generated with a calling
number the carrier needs to hide, STIR supports that as well.
6.3. But can't the carrier still determine the caller?
Yes, insofar as they already can today for anonymous calls. STIR
makes it no worse or better.
6.4. Why do we need to hide the carrier's identity?
If someone knew all the telephone numbers a carrier has, they could
use the information for malicious purposes. For example, a
malicious attacker could target the carrier's customers if they knew
of a specific vulnerability of the carrier. Another example is a
competitor could call all of the carrier's customers with a special
discount offer for the purpose of getting them to switch their
carrier. Furthermore, knowing how many telephone numbers a carrier
has gained or lost allows one to estimate the carrier's quarterly
revenue growth or loss in advance of public disclosure, enabling
illegal stock market trading.
In general most carriers have access to databases that identify the
carrier-of-record for every telephone number in their country-code.
This is available today in the databases used for routing, billing,
and calling name purposes. But the carriers with such access are
under legally binding terms regarding what they can do with such
data.
For STIR, this is a concern if a public-key or certificate lookup
database is openly accessible on the public Internet. In such a
case, it must not reveal the carrier-of-record for telephone
numbers. It is trivial to create scripts to query the entire
database and learn every number for a given carrier.
Kaplan Expires March 2014 [Page 15]
Internet-Draft STIR FRIED September 2013
6.5. Why do we need to hide subscriber identity info?
The concern relates to preventing reverse-number lookups: the
ability to learn the name of the individual, business, or
organization based on their phone number. There is also a concern
with being able to determine the names of individuals with unlisted
numbers.
Although this type of information is sometimes already available on
public websites, some countries have very strict privacy laws that
forbid such information from being publicly available; and in
general there are many cases where it is inappropriate and dangerous
to reveal the particular user, business, or organization of a given
phone number.
6.6. Why do we need to hide subscriber reachability info?
The concern relates to hiding IP address information, such that one
could send call requests directly to the subscriber and bypass the
carriers. Some may view this concern as an anti-consumer business
protection policy, but in practice there is a real security and
privacy concern with exposing general consumer phone-service devices
to the public Internet. Most people pay carriers for phone service,
and do not expect to be exposing their home computer to attack; nor
do they expect to be providing their physical location, which can be
determined from IP addresses.
7. Solutions
Starting in this section and beyond, the term "source identity"
refers to the calling phone number as the "identity". The calling
name is not included, and is not in-scope for STIR (see section 5).
The "source identity verification information" is the information
used to determine the validity of the calling number for the call
request; for example the calling number, called number, timestamp,
and credentials.
7.1. What are the proposed solutions so far, at a high-level?
There is more than one proposed solution. There are two very
different proposed solution architectures: an "in-band" approach and
an "out-of-band" approach. The in-band one sends verification
information in the call signaling, while the out-of-band one sends
it some other way over the Internet. Just for the in-band there are
at least two different proposed mechanisms as well, [draft-ikes] and
[draft-4474bis], but at a very high level they are similar.
Kaplan Expires March 2014 [Page 16]
Internet-Draft STIR FRIED September 2013
At a high level both the in-band and out-of-band approaches have
some common properties:
o there is some common authority or authorities for a given
E.164 country-code, which everyone uses and trusts
o the authority authorizes originators of calls to claim
telephone numbers in the country-code, using credentials for
each E.164 number
o the call originators make calls using the credentials they've
been given for the E.164 number(s)
o the receivers of calls verify the credentials with the common
authority, and thus determines that the originator could claim
the E.164 number
The different solutions have different types of "credentials" and
how they're stored, retrieved, etc.
The different solutions have different expectations for who the
central "authority" is, who the "originators" are, and who the
"receivers" are. In the two in-band solutions, the authority is
generally assumed to be the national numbering administrator for a
given country-code, or an agent of theirs; the originators and
receivers are expected to be service providers, and possibly also
large enterprise PBXs. In the out-of-band solution, the authority
is not yet clearly articulated; the originators and receivers are
expected to be end-user devices such as smartphones, and possibly
also large enterprise PBXs.
To be clear, both architectural approaches allow end-user devices to
participate in the process; the difference is more around the
assumptions and pragmatic considerations based on who the expected
implementers and operators of the technologies will be in general.
7.2. What does "in-band" vs. "out-of-band" mean?
Calls are generated using signaling protocols, such as SIP, SS7 and
ISDN. An "in-band" solution carries the source identity validation
information in the call signaling, for example in a new SIP header
or in SS7 ISUP parameters. An "out-of-band" solution exchanges the
source identity validation information through some other means over
the Internet, separately from the call signaling.
7.3. Why are there both an in-band and out-of-band solution?
The STIR Working Group could not come to agreement on which model
would more likely succeed in getting widely deployed. To make
progress, the group decided to do both: work on the in-band first,
followed by the out-of-band, and let the market decide.
Kaplan Expires March 2014 [Page 17]
Internet-Draft STIR FRIED September 2013
7.4. Why can't we just do P-Asserted-Identity without STIR?
The SIP 'P-Asserted-Identity' (PAI) header defined in [RFC3325] is
widely deployed, and identifies the source caller identity that the
originating carrier asserts it to be. In other words, user devices
don't generate this header; carriers generate this header.
Therefore it is tempting to simply trust this header to be accurate.
Unfortunately we know that won't work, because we already know that
some originating carriers allow malicious originators (robocallers)
to generate whatever SIP headers they wish to.
A solution to that problem was proposed a few years ago, but is
untenable - see question 7.5.
7.5. Why can't we just sign using a carrier-wide identity?
Most carriers are trustworthy when it comes to generating legitimate
calling numbers and names. The PSTN has been running for decades
without the issues reaching the magnitude they have today. It is
tempting to simply have a carrier sign the call request with the
identity of the carrier itself, instead of having to use specific
credentials for every E.164 number it manages; we could just base
the number's validity on the trustworthiness or reputation of the
entire carrier.
A potential solution was described in [draft-asserter], such that
the originating carrier signs the PAI header using a private key for
the whole carrier. This would have been simpler than the currently
proposed STIR solutions. We don't believe this would have really
solved the problem, however, because in order to stop fake calling
numbers in such a model, the terminating carrier would need to
anonymize all calls from the originating carrier once the
originating carrier was determined to be "untrustworthy". Concerns
have been raised about the legal difficulty with deciding an entire
originating service provider is untrustworthy, especially in an
international context.
For example, if AT&T received a call request from Deutsche Telecom
(DT), and it was signed using a certificate for DT, of course AT&T
would trust the validity of any German calling number that DT claims
it to be from. But would AT&T trust German numbered calls from
Freenet GMBH, or WU-Solutions Ltd.? How many bad calls would it
take to decide one of those is untrustworthy? What if Freenet, and
completely legitimate German carrier, exceeded the threshold and
AT&T decides to start anonymizing or blocking their calls? Imagine
the issues that would raise legally and politically.
Because of these sorts of challenges, basing caller-id decision on
originating carrier reputations was determined to be impractical.
Kaplan Expires March 2014 [Page 18]
Internet-Draft STIR FRIED September 2013
Instead, STIR simply prevents a carrier from being able to claim a
number it isn't assigned or authorized to claim. Since the
authority is already performed today in each country-code, doing it
this way is legally and politically defensible.
7.6. Why are we only focused on SIP?
Because for phone-type service it is the communication protocol most
carriers and enterprises are migrating to today, and have been for
the past decade. It is not focused on any particular type of
carrier, vertical market segment, or any particular region of the
World. SS7 and ISDN continue to exist, clearly, but there is no
significant vendor product development in that technology, nor does
there appear to be any desire by carriers to invest more in it.
One of the proposed in-band solutions, [draft-ikes], does include
SS7 and ISDN support for STIR in a transparent manner for some
scenarios; and the out-of-band solution would also work across SS7
and ISDN. The focus of STIR remains, however, on SIP as the main
in-band protocol to support.
7.7. What about other IP-based protocols?
There are other real-time communications IP-based protocols: for
example XMPP, H.323, BICC, and soon WebRTC. WebRTC is not an inter-
domain protocol, but rather relies on other protocols such as SIP or
XMPP for inter-domain communications. XMPP is mostly used for
instant messaging and group chat, but does have some voice and video
calling abilities (a.k.a., Jingle). H.323 is still being used,
mostly in the video conferencing market, but also in some enterprise
PBX markets in certain parts of the World. BICC is still being used
in specific mobile operator interconnection trunks in certain parts
of the World; although most 3GPP and LTE mobile operators have
either already migrated to SIP or are in the process of doing so.
Any of these technologies could define their own calling number
validation mechanism someday. One of the proposed in-band STIR
solutions, [draft-ikes], is designed to be able to work through any
protocol, including XMPP, H.323, BICC, and WebRTC. It does not,
however, define the details for how the verification information
would be encoded in those protocols' messages, but leaves that up to
other Working Groups or other Standards Development Organizations
(SDOs) to do.
7.8. What SIP header is used for the calling number?
In general most devices use the SIP From header's URI username as
the source calling number. In some cases the P-Asserted-Identity
Kaplan Expires March 2014 [Page 19]
Internet-Draft STIR FRIED September 2013
header field is used instead. There are some proprietary headers in
use as well, but they're far less common.
Interestingly, while the headers to use for calling and called
numbers will be in the STIR RFCs, it is not necessary to use them as
they appear on-the-wire to make STIR work correctly. See question
7.10.
7.9. Doesn't the SIP From or To URI string change along the path?
Yes. In many inter-carrier call cases today, the SIP To and From
URIs change, sometimes drastically. There are many reasons this
occurs, some of which are documented in [draft-uris-change]. Even
in SS7, the logical equivalent of this is performed as part of
Global Title Translation.
Regardless, STIR works even when the To and From URI strings are
changed. It does this because it does not cryptographically sign
the literal encoded strings, but instead the abstract logical E.164
numbers they represent. See question 7.10.
7.10. Does STIR crypto-sign the SIP From and To URI headers?
No, not really. STIR signs the abstract logical E.164 numbers they
represent. The signer and verifier each sign a "canonical" E.164
number, which is not necessarily the exact string they send or
receive on-the-wire in the SIP messages, but is instead the
equivalent identity as an E.164 number.
For example, even if the To and/or From URI strings only contain a
national or local number, or are encoded as 'sip:<number>@domain'
format without a 'user=phone' parameter; if the STIR verifier treats
it as a telephone number, then it verifies it as the E.164-
equivalent numbers. Likewise, the signer cryptographically signs
the E.164-equivalent numbers.
If the originator didn't intend it to be a telephone number, or
intended it to be a different one, then the STIR verification will
fail. In such a case, however, the verification *should* fail,
because by definition the verifier should not believe it to be the
telephone number it thinks it is. Since the existing problem in
deployed SIP networks is not one of syntactic encoding confusion,
but instead one of malicious intent, there does not appear to be an
interoperability problem with determining the source number even
though the From and To URIs are changed along the SIP signaling
path.
Kaplan Expires March 2014 [Page 20]
Internet-Draft STIR FRIED September 2013
7.11. Does STIR change SIP From or To URI headers?
No. The carriers can do whatever they do today. If they change
them today, for whatever reason, then they can continue to change
them; if they don't change them, then they can continue to not
change them.
8. In-band Solution Questions
8.1. Don't we already have in-band with RFC 4474 SIP Identity?
No. SIP Identity per [RFC4474] has not been deployed, would not
have solved the problem for telephone numbers in particular, and
cannot solve the problem in the existing deployments. A solution to
the problem must avoid the issues SIP Identity would have had, had
it been attempted.
In particular, [RFC4474] signed portions of the SIP message that are
frequently changed by middleboxes. These portions did not need to
be signed to achieve just the goal of source identity telephone
number validation, so the new proposals sign much less. Also,
[RFC4474] was really only applicable for user@domain email-style SIP
names, not telephone numbers. There are some other problems with
[RFC4474], but those were the big ones.
8.2. What will happen to RFC 4474?
It might be deprecated and replaced with the STIR WG output, or
simply left alone and ignored. This is still TBD.
8.3. What are the proposed in-band solutions so far?
There have been several proposed solutions to the STIR problem over
the years, and more recently additional proposed candidates have
emerged in STIR: [draft-ikes] and [draft-4474bis], with [draft-
cider] as a proposed database model. Note these are all individual
drafts, and the Working Group has not truly begun discussing them in
detail yet.
The proposed solutions generally follow a model similar to
[RFC4474]: the originating SIP domain generates a cryptographic
signature over source identity information using a private key, and
inserts the signature along with the relevant information in a SIP
header(s) of the SIP message; the receiver of the SIP message then
uses the public key counterpart to verify the signature for the same
source identity information.
Kaplan Expires March 2014 [Page 21]
Internet-Draft STIR FRIED September 2013
The public key retrieved by the verifier is identified to be valid
for the given source identity (i.e., valid for a given phone
number), though how this retrieval and key-validity is done differs
between solutions, as described later.
The specific SIP fields signed by the solutions differ from
[RFC4474], in order to make the solutions work in real-world
deployments. This changes the threats and attack vectors they can
protect against. For example man-in-the-middle and replay attacks
are easier to perform than in [RFC4474], but this is not considered
a significant threat for existing deployments.
The proposed solutions separate the mechanism used for generating,
sending, and verifying the source identity assertion, from the
mechanism used for retrieving the public key and verifying the key
represents an authorized entity for the assertion. For example,
[draft-ikes] specifies how to cryptographically sign and send the
assertion in SIP headers, and perform signature verification when
receiving those headers; but [draft-cider] specifies how the
verifier retrieves the public key and can know it is valid for the
source identity being asserted. [draft-4474bis] specifies both in
the same document, but still logically separates the functions.
The [draft-cider] proposal uses a DNS-based mechanism similar to
DKIM. For telephone numbers, a common domain anchor is used for all
numbers in a given country-code, and an ENUM-style naming schema is
used for a DNS tree under the anchor. DNSSEC is then used to
provide digital signature chaining from the anchor down, and each
telephone number is a DNS node with a TXT RR of the public key value
used by STIRSEC.
Alternatively, [draft-4474bis] proposes a Certificate Authority
model similar to the Web-PKI, whereby a certificate is retrieved via
HTTP from a URL encoded in an Identity-Info header in the received
SIP message. For telephone numbers in particular, [draft-4474bis]
proposes the specific telephone number or range be encoded in a [to-
be-decided] field of the certificate, instead of a host or domain
name. It is not clear how the verifier knows the CA is
authoritative for that telephone number, as this portion of the
solution is still a work in progress for [draft-4474bis].
8.4. Why not just carry a certificate in the SIP message?
Carrying an X.509 certificate in a SIP INVITE request creates two
problems: the message size grows (a LOT), and multi-part MIME isn't
supported by many SIP systems. Therefore, including an X.509
certificate in the message would present a significant barrier for
adoption. Furthermore, if malicious originators can simply send the
certificate in the INVITE, then compromised keys could be easily
Kaplan Expires March 2014 [Page 22]
Internet-Draft STIR FRIED September 2013
used until the certificate lifetime expires (typically years); or
would require everyone to check certificate revocation lists (CRLs)
that can grow very large for the STIR use-case.
9. Out-of-band Solution Questions
9.1. What are the proposed out-of-band solutions?
The only currently proposed out-of-band solution is [draft-oob].
Note it is still a work in progress, and only an individual draft.
The Working Group has not discussed it yet in detail.
9.2. What are the major advantages of an out-of-band solution?
The major advantage is it can avoid carriers, avoid middleboxes, and
it works across legacy SS7, ISDN, or any call signaling technology,
because it is not carried in the call signaling.
9.3. What are the major disadvantages of an out-of-band solution?
There are many, potentially. But until the proposal becomes more
concretely defined it is difficult to really know. There is also
considerable disagreement in the Working Group regarding the
disadvantages, so they will not be listed here in order to avoid a
bias.
10. Security Considerations
This document is only a FAQ-type informational document, and thus no
security considerations apply to the document itself. A security
document will be produced by the STIR Working Group, but this
section covers some high-level questions or concerns that have been
raised for the general concept of STIR.
Questions related to privacy are covered in section 6.
10.1. What types of attackers are we worried about?
The main actors we're worried about are malicious originators of
call requests into the existing PSTN-type network-of-trust. This
includes malicious users, such as PRI-style SIP trunk customers,
VoIP subscribers, and over-the-top VoIP users; the type of access
they have doesn't matter as much as that they generate calls and are
not themselves carriers.
Some originating "providers" are known to be malicious in some ways
as well - not to their own users, but they are knowingly complicit
Kaplan Expires March 2014 [Page 23]
Internet-Draft STIR FRIED September 2013
in allowing their users to generate false calling numbers. Note
these aren't regulated or traditional carriers, but rather non-
traditional providers of outbound calling service. For example some
specialty providers with a business model of letting their customers
generate fake calling numbers, ostensibly for non-malicious
purposes. The concern isn't that these types of providers are
active attackers themselves, but rather that they purposefully want
to enable unauthorized calling number use by their customers.
We are also worried about malicious receivers of calls, inasmuch as
they might be able to generate new outbound calls using STIR
verification information from calls they previously received. For
example, it is trivial to get a bank or other business to call you
by simply filling out a web form for sales or service help; if you
could re-use that call's STIR information to make outbound calls
pretending to be the bank, then that would be a problem. This form
of attack is called a cut-and-paste attack.
We are not worried about transit carriers being malicious. Transit
carriers may be indifferent or sloppy, but not actively malicious.
Likewise terminating carriers (the carriers receiving calls and
delivering them to end users) are not malicious, since they act on
behalf of their customer subscribers receiving the calls.
10.2. What are the main threats we are worried about?
The assumptions so far have been:
o We are worried about denial-of-service (DoS) attacks, of a
certain form (see question 10.3)
o We are worried about cut-and-paste attacks, of a certain form
(see question 10.4)
o We are not worried about obfuscation attacks
o We are not worried about man-in-the-middle (MITM) attacks
o We are not worried about replay attacks
Details of the above are discussed in other questions and answers in
this document section.
10.3. What types of DoS attacks are we worried about?
Denial of Service (DoS) attacks come in many forms, and as the name
suggests it is a class of attack with the goal of denying service to
others. Some people use the term DoS to mean message flooding or
high call rate attacks, but those are just specific types of
resource exhaustion-based DoS attack.
For STIR, one DoS concern is an attack on the STIR infrastructure,
such as the PKI database. But that form of attack is unlikely, and
Kaplan Expires March 2014 [Page 24]
Internet-Draft STIR FRIED September 2013
even if it succeeds it doesn't prevent phone calls; it just may
prevent the calls from being verified and thus cause them to be
anonymized.
Another form of DoS attack is a malicious party sending SIP messages
with invalid or valid STIR information in the hopes of consuming
extra resources on the attack target (a form of resource exhaustion
attack). This is possible, but the amount of processing overhead
for just STIR isn't expected to be significantly more than general
call processing overhead, so STIR doesn't make it worse than before.
Another, slightly tangential DoS attack, is one where malicious
parties send SIP messages with valid or invalid STIR information for
the purpose of triggering reputation systems to black-list a valid
number. In other words the goal is to impact the reputation of a
legitimate number such as a business' number. That attack is not
really a role for SIR to prevent, however, as much as it is for a
reputation system to avoid.
10.4. What types of cut-and-paste attacks are we worried about?
A "cut-and-paste" attack has multiple meanings in the security
world. Traditionally it meant replacing some piece of information
in a message, file, or whatever, to cause something bad to happen;
for example being able to replace a portion of an encrypted message
or file such that it still decrypts but the resulting cleartext is
different. One of the purposes of cryptographically signing
something is to prevent such changes from being possible (without
being detected).
In the STIR context a cut-and-paste attack means the ability to
change any of the SIP message that isn't signed, such that you could
attack another target with that message in some way. Since very
little of the SIP message is actually digitally signed, so much
could be changed that the a cut-and-paste attack can be viewed a
different way: can an attacker take the digitally signed STIR
information, and re-use it in a brand new message of the attacker's
creation.
In STIR we don't really worry about a MITM performing a cut-and-
paste attack (see question 10.5), but rather a malicious user
receiving a valid STIR call and using that STIR information to
perform an attack. We know there are malicious users, and we know
they can easily get a high-value caller to call them; for example
they could get a bank or large corporation to call them by filling
out a web-form for sales or service. If they can re-use the STIR
information from the received bank call, to call someone else
pretending to be the bank, then that would be a problem.
Kaplan Expires March 2014 [Page 25]
Internet-Draft STIR FRIED September 2013
The biggest concern identified thus far is a cut-and-paste attack
whereby the malicious receiver of a call re-uses the STIR
information in such a way that it appears like a call-forwarding
event has occurred. Call-forwarding is a common service supported
in the PSTN, and is often performed within enterprise PBXs. Since
the malicious parties today are attaching to the PSTN-trust network
using PBX-type trunks, they would be allowed to perform call-
forwarding (as opposed to, for example, residential and mobile
subscribers who cannot perform it directly on their phones).
Since call-forwarding is very common feature, the STIR mechanism has
to allow it to happen; but this means STIR itself cannot prevent
malicious parties from performing call-forwarding, which means it is
susceptible to a cut-and-paste attack that mimics a call-forwarding
event. There are some solutions to this, but they're not very
palatable.
10.5. Why are we not worried about MITM attacks?
The current communication model for the PSTN makes it difficult to
become an active or passive MITM. If an attacker can become a MITM,
however, calling number validation is the least of the problems we
need to worry about. If it were easy to prevent a MITM attack for
STIR we would likely do so, but in practice it's impossible if we
want to make STIR deployable.
10.6. Why are we not worried about replay attacks?
Replay attacks are when the same call request is sent again and
again, as a form of attack. The only actors who could do this are
the call originator, originating carrier, transit carriers, and
terminating carrier. The call originator and originating carrier
can do it no matter what we do, since the originator can simply re-
sign requests at will. The transit and terminating carriers have no
motivation to do it, and we've already assumed they're not
malicious.
10.7. Is the call media (audio or video) secured by STIR?
No. STIR only verifies the calling number, not media. Media in the
PSTN cannot be securely identified nor protected from eavesdropping,
in practice; nor has that been an actual problem so far. SIP
provides some level of media security with SRTP, but in practice
that is only used hop-by-hop and only for certain hops; it is not
truly secure end-to-end generally.
Again, this has not been a real issue needing to be fixed in the
PSTN. It has been an issue in the sense that communications in the
PSTN are not secure from the carriers themselves, but they can learn
Kaplan Expires March 2014 [Page 26]
Internet-Draft STIR FRIED September 2013
almost as much useful information from the call signaling meta-data,
such as the Call Detail Records, as they can from the words spoken
during the call.
Furthermore, legally authorized wiretapping is a general requirement
for the PSTN. One of the properties wiretapping regulations
sometimes require is to not appear any different to the suspect
being monitored; enabling users to detect that the media is not
secure end-to-end would not fulfill that requirement.
11. General Security Terminology
Some participants in STIR Working Group might not be familiar with
the security mechanisms being discussed. There are several security
experts participating in the work, but to help others follow the
general concepts, this section attempts to answer some very basic
concept questions.
**WARNING**: this section's answers are not completely accurate or
comprehensive, nor are they intended to be. The answers have been
overly simplified to provide the rough general ideas and concepts
without bogging down in details.
11.1. What is a private vs. public key?
A private key and public key refer to the two separate,
mathematically linked sets of numbers used by public-key
cryptography, also known as asymmetric key cryptography. The
mathematical relationship is such that something encrypted by one
key can only be decrypted by the other key; but it is
computationally extremely hard to determine what the other key is
when you only have one of them. The private key refers to the one
kept secret and never revealed to anyone else, while the public key
is the one everyone else can see and use.
It's a bit confusing because most public websites refer to a
"public" key as being used for encryption, while a "private" key is
used for decryption. This is what occurs when public-key
cryptography is used for message encryption - i.e., to prevent
anyone from reading the message. For example this is how PGP uses
public key cryptography. For cryptographic digital signatures,
however, the key uses are different: the private key is used for
signing (similar to encrypting), while the public key is used for
verifying (similar to decrypting).
For digital signatures, therefore, the private key is used to "sign"
something such as a message or string; while the public key is
useable by everyone else to verify the signature. So long as the
Kaplan Expires March 2014 [Page 27]
Internet-Draft STIR FRIED September 2013
private key is never revealed to anyone else, receivers of the
signed message can know that the holder of the private key signed
it, by using the public key to verify the signature. Only the
private key twin of the public key could have created the signature.
In the case of STIR, what this means is that a call originator
generates a private and public key; the private key they keep to
themselves, and the public key counterpart they make available to
everyone else in some way. When the originator signs call-related
information, the call receiver can use the public key to verify the
originator truly signed it. By itself, however, this doesn't prove
the originator is authorized to claim the E.164 number. For that we
need a way for some trusted authority of phone numbers to say: "this
public key can claim this E.164 phone number". This is accomplished
in one of two proposed ways: either a certificate model as in
[draft-4474bis], or a DKIM-like model as in [draft-cider].
11.2. What does "cryptographically sign" mean?
The technical details don't matter; if you need to know, check
Wikipedia or read the relevant RFCs. At a high-level the general
concept is a simple one, and is similar to traditional handwritten
signatures: someone signs something with a signature only they could
have created, and other people can verify the signature without
themselves being able to create or forge the same signature. In
theory only the original signer could have created the same
signature. Of course handwritten signatures are easy to forge, but
cryptographic signatures are (in theory) nearly impossible to forge
unless the private key has been compromised.
Unlike human signatures, digital signatures use private and public
keys which are just numbers and don't represent an identity by
themselves. Something else is needed to tie an identity with the
public key used for verifying the signature. This is somewhat
similar to showing a Passport or Driver's license to prove your
signature really represents you. In the web SSL or TLS world, that
something else is an X.509 certificate. In the email DKIM world,
that something else is an entry in the Domain Name System (DNS).
11.3. What is a certificate?
A digital certificate is an electronic "document" that contains some
form of identity information and a public key, and is signed by a
Certificate Authority (CA). If you trust the CA, then by verifying
the CA's signature for the certificate essentially tells you that
the public key belongs to the identity in the certificate. This is
somewhat analogous to a passport: if you trust the government
issuing the passport, and you verify the passport is not forged,
Kaplan Expires March 2014 [Page 28]
Internet-Draft STIR FRIED September 2013
then you know that the person's name is tied to the picture and the
handwritten signature in the passport.
In order to verify the certificate, the CA's public key must also be
known, since that is used to verify the signature of the certificate
itself. That CA signature's public key is in another certificate,
typically a "root certificate". A root certificate has no higher
authority, and is either unsigned or self-signed by the CA. It is
typically pre-installed in systems that trust the CA, such as web
browsers, and updated periodically.
Digital certificates can also be used in a signing chain of trust,
whereby a root CA signs the certificate of an intermediate CA, which
is then used to sign the certificate of someone else. The final
certificate used by end organizations or devices is called an "end-
entity" certificate.
In the web world, there are approximately 160 trusted CAs around the
World. The identity being claimed in end-entity certificates are
domain or host names, such as 'www.example.com'. Your web browser
uses the public key in the certificate bound to that name during the
SSL or TLS handshake to determine that it's really talking to
www.example.com, for example.
For STIR, one of the proposed solutions [draft-4474bis] uses
certificates to prove E.164 authorization. The idea would be to
make the identity in the certificate be an E.164 number (or range),
and the public key would be used for verifying the signature
contained in the SIP message. The call receiver can then know the
originator can claim the E.164 number, because the SIP message was
signed with a private key whose public key counterpart is in the
certificate with the authorized E.164 number.
The CAs for such STIR-based certificates could be either trusted 3rd
parties, or the national numbering authorities for each country-
code. For specific details, refer to [draft-4474bis].
11.4. What is a PKI?
A Public Key Infrastructure (PKI) is an abstract term representing
the collection of architecture, mechanisms, policies, and properties
used for binding things to public keys and providing for their
distribution, revocation and usage. The "things" being bound to
public keys may be identities of some kind, resource identifiers,
objects, etc.
The most common example of a PKI is the "Web-PKI", which an X.509-
based PKI that binds fully-qualified domain names to public keys
using X.509 digital certificates. This is so prevalent that the
Kaplan Expires March 2014 [Page 29]
Internet-Draft STIR FRIED September 2013
term "PKI" is often used synonymously with X.509-based PKIs and in
particular the Web-PKI; but there are other types of PKIs, including
ones that don't use digital certificates at all. DKIM, for example,
is essentially a PKI based on DNS without using X.509 certificates.
11.5. What is a Web-PKI?
The Web-PKI is the Public Key Infrastructure used to bind fully-
qualified domain names (e.g., 'www.example.com') to public keys,
using X.509 digital certificates. It is most frequently used for
HTTP-based SSL or TLS (i.e., HTTPS). For example, it is used as
part of the protocol used by your browser when you go to a website
using 'https://www.example.com', so that your browser can determine
it really is talking to www.example.com.
The Web-PKI's certificates are signed by "trusted" CAs, which are
merely companies or organizations that most other entities trust to
practice good policies for the domain names they sign certificates
for. [RFC3647] defines some practices they should follow, but the
IETF does not audit or police the CAs to follow the practices.
There are approximately 160 trusted CAs around the World that many
popular web browsers trust and include the root certificates for.
There have, however, been problems with the Web-PKI model. See
question 11.6.
11.6. What is wrong with the Web-PKI?
The technology of X.509-based digital certificates is sound, but the
way they're used in Web-PKI has been shown to be dangerous. Issues
have occurred due to compromised Certificate Authorities and their
impact on all domain names. The most famous example of this is the
former Certificate Authority DigiNotar.
Certificate Authorities are not themselves authoritative for domain
names or any portion of the domain name space, therefore any trusted
CA can sign a certificate for any domain name whatsoever, and
everyone must blindly trust their validity. A malicious CA or an
attacker that has a CA's signing private key can generate a digital
certificate claiming to be any domain name at all, even for names
the CA never previously signed for. This means that the compromise
of one CA impacts everyone; even organizations that do not and have
never trusted the CA.
To address this problem, the IETF has defined DANE in [RFC6698],
which puts the Web-PKI certificates in DNS, in the DNS domain name
entry that the certificate claims to bind to a public key. Since
DNS is the authority for domain names, and by virtue of its
structure it provides a way to scope or restrict the names being
Kaplan Expires March 2014 [Page 30]
Internet-Draft STIR FRIED September 2013
claimed, the problems a compromised CA or DNS registrar could create
are limited. Using DNSSEC to sign the DNS domain entries could
arguably remove the need for CAs altogether someday. Using both,
however, provides a two-factor authentication model, since both the
DNS and a trusted CA would need to be compromised.
For STIR, the Web-PKI model's problems are only a concern if any CA
is allowed to claim any phone number. It is assumed that this would
not be possible; instead, a certificate delegation chain would be
used whereby a national numbering authority would only delegate
specific CAs to be able to sign for specific phone numbers or
ranges.
11.7. What is an RPKI?
A Resource Public Key Infrastructure (RPKI) is a type of X.509-based
PKI used for binding "resources" to public keys, where the resources
are IP addresses or prefixes or BGP Autonomous System (AS) numbers.
This is mostly used for the purpose of securing the Internet routing
infrastructure through BGPSEC, but also for securing neighbor
discovery in IPv6.
In order to bind multiple IP Addresses and AS numbers, the RPKI
defines an extension to X.509 certificates. This extension must be
understood and supported by verifiers, so it is not compatible with
Web-PKI type certificates.
For STIR, such a model could be employed where the "resources" are
E.164 numbers or ranges. The specifics of how the RPKI is managed
and deployed for BGP using RSYNC, however, might not make sense for
STIR.
11.8. What is DKIM?
DomainKeys Identified Mail (DKIM) is a form of PKI used for
verifying source domain names in received email messages, based on
[RFC6376]. It is not typically described as a PKI, but for all
intents and purposes it defines one. Instead of using X.509 digital
certificates, DKIM simply puts the public keys in DNS, in the DNS
domain name entries the public key is used for. In this way, it
provides a binding of email source domain name to a public key.
The "Certificate Authority" is the DNS itself, with a chain of trust
delegation based on the DNS delegation hierarchy. For example, if
you receive an email from "alice@example.com" signed using DKIM,
there will be a public key in the DNS entry for 'example.com'
(technically it's in '<selector>._domainkey.example.com' but that's
not important for this simple explanation).
Kaplan Expires March 2014 [Page 31]
Internet-Draft STIR FRIED September 2013
Typically DKIM is deployed with just normal DNS records, and DNSSEC
is not required. DNS is susceptible to forged answers, however, so
DNSSEC can be used as well to prevent this. With DNSSEC, the DNS
entries are signed in a similar fashion as digital certificates;
this results in a cryptographically secure PKI with several benefits
over a Web-PKI style model.
For STIR, one of the proposed solutions [draft-cider] uses a DKIM-
style DNS model to prove E.164 authorization. The idea is to
convert E.164 numbers to domain names in an ENUM-like model, and the
E.164 number's DNS entry contains the public key to be used for
verifying the signature contained in the SIP message. The call
receiver can then know the originator can claim the E.164 number,
because the SIP message was signed with a private key whose public
key counterpart is in the DNS entry for the authorized E.164 number.
The DNS delegation hierarchy could be used to delegate each country-
code to their respective numbering authorities or someone the
carriers trust, and the carriers in that country-code would populate
the public keys. The physical DNS servers would be run by the
trusted party or the national numbering authority, or a company they
contract to do so. For specific details, refer to [draft-cider].
11.9. What is DNSSEC?
Domain Name System Security Extensions (DNSSEC) defines a means for
the DNS infrastructure to be cryptographically secured from forgery.
It defines the procedures for the DNS hierarchy to be signed in a
chained model from the root down to each node, and defines the
additional DNS Resource Records (RRs) for signatures and public keys
to do so.
For example, IANA signs the DNS root and public keys for the
administrators of top-level domains ('.com', '.net', etc.), and the
administrators of the top-level domains use their private keys to
sign their records as well as the public keys for each of their
registered subdomain owners, who then use their private keys to sign
their entries, and so on.
When a client performs a DNS query for a resource record of a domain
name, a signature can be returned along with the resource record in
the same DNS response message; the signature uses a public key of
the parent domain, creating a chain ultimately leading back up to
the DNS root.
In this way it's similar to the chain of trust created by Web-PKI
trusted root CAs signing intermediate CAs, who then sign end-entity
certificates. But in DNSSEC there are no X.509 certificates - the
Kaplan Expires March 2014 [Page 32]
Internet-Draft STIR FRIED September 2013
DNS records create the same type of information without certificates
and without third-party trusted CAs.
For STIR, this is only applicable in the sense that a DNS-based
E.164 PKI such as [draft-cider] could use DNSSEC to protect its
responses from being forged, if DNS forgery is a concern.
11.10. Which security model is STIR going to use?
This is still being discussed. There are benefits and drawbacks for
each proposed solution, and many factors to consider. Some of the
variables involve non-technical issues, such as ease of adoption for
carriers vs. ease of adoption for end user devices such as
smartphones; or issues regarding the different vendor
implementations that might perform STIR, as well as market forces.
12. Glossary
The following terminology definitions are employed in this document
and in the STIR Working Group.
Attack - An attack is an action that attempts to violate the
security policy of a system, e.g., by exploiting a vulnerability.
There is often a many to one mapping of attacks to vulnerabilities,
because many different attacks may be used to exploit a
vulnerability.
BICC - Bearer-Independent Call Control, a call signaling protocol
similar to SS7/ISUP, but that can create non-TDM-circuit media
channels; for example it's frequently used with voice over ATM
(Asynchronous Transfer Mode), as well as voice over IP.
Calling Number - the telephone number of the caller.
Calling Name - the textual name of the caller, or a geographic
region the caller's number is based in. Calling name is not
available for all calls, nor in all countries. It is a popular
feature for calls in the US.
Captcha - Completely Automated Public Turing test to tell Computers
and Humans Apart, a term used to describe a test to determine if the
user is a human or not. Typically one sees this on a web site form,
with a distorted word displayed that the user must type in the form.
For calls, a captcha is usually a set of simple questions asked in
audio, that the caller must be able to answer correctly, for example
a math question that the user must then answer by pressing the
correct digits.
Kaplan Expires March 2014 [Page 33]
Internet-Draft STIR FRIED September 2013
Carrier - An organization managing (and typically selling) SIP
services to another Carrier, SIP Service Provider (SSP), enterprises
or businesses, and consumers. Carriers are not necessarily
regulated entities, and there are non-traditional ones such as over-
the-top service providers. In this document both regulated carriers
and any type of phone service providers are called "carriers".
Certification Authority (CA) - An entity that issues digital
certificates (e.g., X.509 certificates) and vouches for the binding
between the data items in a certificate.
CNAM - Calling Name Delivery, a feature enabling delivery of a
calling name for the call. CNAM is typically provided by the
terminating carrier querying either the LIDB in SS7 using TCAP, or a
third-party CNAM database provider.
DANE - DNS-Based Authentication of Named Entities, a technology used
to retrieve X.509 Certificates from DNS, based on RFC 6698. See the
answer to question 11.6.
DKIM - DomainKeys Identified Mail, a technology used to assert a
source domain name identity for email, using cryptographic
signatures, by putting the public keys in DNS. See question 11.8.
DNS - Domain Name System, a distributed database used in the
Internet for resolving domain names to addresses, as well as other
resource types.
E.164 number - a phone number in international ITU-T E.164 format,
which is understood by the originating and receiving entities to
represent a globally unique number, regardless of any syntactic
encoding for a domain portion. Changing the domain portion would
not fundamentally change the identity of the resource.
ECC - Elliptic Curve Cryptography, a type of public-key cryptography
based on mathematical properties of elliptic curves, as opposed to
those of prime numbers as is used in the more common RSA algorithm.
Email-style name - a 'user@domain' format identity, for which the
user portion is scoped to the domain portion; removing or changing
the domain portion would fundamentally change the identity of the
user.
H.323 - a VoIP protocol from the ITU, most commonly used today in
video conferencing applications, as well as voice applications.
IVR - Interactive Voice Response, a technology for machine-to-human
communications, typically implemented using a media server playing
out pre-recorded audio instructions and asking for feedback from
Kaplan Expires March 2014 [Page 34]
Internet-Draft STIR FRIED September 2013
humans using the keypad or voice commands. For example, automated
airline reservation systems are usually based on IVR.
LIDB - Line Information DataBase, a set of databases in the SS7
network with information for telephone numbers, such as the calling
name, payment policy, phone type, etc. LIDB servers are run by
carriers and third-party administrators, and are queried using TCAP.
They are mostly common in the US and Canada.
Man in the Middle (MITM) - A MITM is an entity that is able to
examine and modify traffic between two (or more) parties on a
communication path.
NANP - North American Numbering Plan, the telephone numbering plan
for the +1 international calling code, for approximately 20
countries and territories in North America (the USA, Canada,
Jamaica, etc.).
PBX - Private Branch Exchange, a system providing voice service to a
business or organization that owns the PBX.
PKI - Public Key Infrastructure, see question 11.4.
POTS - Plain Old Telephone Service, the legacy analog phone service
typically provided to residential subscribers.
PRI - Primary Rate Interface, a specific telecom service line type,
based on ISDN, usually used for connecting a PBX to a carrier's
switch.
PSTN - Public Switched Telephone Network, the connection of voice
service networks and devices, historically based on circuit-switch
technology using SS7 in the core and POTS, GSM, PRI and other
technologies for access. With regards to STIR, the SIP-based
service providers and equipment is also considered part of the PSTN.
Robocaller - an automated call-generating system, typically
implemented in software. Robocallers can be legitimate, for example
political campaign calling systems, or local school announcement
systems; but they can also be used for malicious purposes.
SIP - Session Initiation Protocol, as defined by [RFC3261] and its
extensions, is the dominant Voice over IP protocol in use in the
PSTN, both in carriers as well as in enterprise markets.
SMS - Short Message Service, the text messaging application used on
mobile phones.
Kaplan Expires March 2014 [Page 35]
Internet-Draft STIR FRIED September 2013
Source identity - the E.164 number, number code, or email-style name
used for identifying the originator of a message to the receiving
user; i.e., the identity used for "Caller-ID".
Spiral - a call spiral is a scenario where a call request gets
routed/forwarded through the same system or administrative domain
multiple times, without actually being an error condition. This can
occur due to call-forwarding or number portability.
STIR - Secure Telephone Identity Revisited, the name of the IETF
Working Group addressing calling number validation. This document
also uses it for the name of the solution mechanism.
XMPP - Extensible Messaging and Presence Protocol, an XML-based
protocol primarily used for session-based instant messaging, and
also for basic voice over IP sessions.
13. IANA Considerations
This document makes no request of IANA.
14. Acknowledgments
The types of questions and answers in this document arise from email
discussions in the STIR mailing list over the past few months, from
many individuals. No emails were used for direct copy and pasting
content, however.
15. References
15.1. Informative References
[RFC3325] Jennings, C., Peterson, J., Watson, M., "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, November
2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3647] Chokhani, S., et al, " Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices
Framework", RFC 3647, November 2003.
[RFC4474] Peterson, J., and Jennings, C., "Enhancements for
Authenticated Identity Management in the Session Initiation
Protocol (SIP)", RFC 4474, August 2006.
Kaplan Expires March 2014 [Page 36]
Internet-Draft STIR FRIED September 2013
[RFC6376] Crocker, D., Hansen, T., and Kucherawy, M., "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6698] Hoffman, P., Schlyter, J., "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[ems-attacks] https://krebsonsecurity.com/2013/04/dhs-warns-of-
tdos-extortion-attacks-on-public-emergency-networks
[ofcom-work] http://stakeholders.ofcom.org.uk/consultations/silent-
calls/joint-action-plan
[robo-challenge] http://robocall.challenge.gov
[draft-asserter] Kaplan, H., "Private Extensions to the Session
Initiation Protocol (SIP) for Asserter Identification within
Trusted Networks", draft-kaplan-sip-asserter-identity, March
2009.
[draft-ikes] Kaplan, H., "An Identity Key-based and Effective
Signature for Origin-Unknown Types", draft-kaplan-stir-ikes-
out, July 2013.
[draft-4474bis] Peterson, J., Jennings, C., Rescorla, E.,
"Authenticated Identity Management in the Session Initiation
Protocol (SIP)", draft-jennings-dispatch-rfc4474bis, July
2013.
[draft-cider] Kaplan, H., "A proposal for Identity in a DNS-based
Entrusted Registry (CIDER)", draft-kaplan-stir-cider, July
2013.
[draft-oob] Rescorla, E., "Secure Caller-ID Fallback Mode", draft-
rescorla-stir-fallback, July 2013.
[draft-uris-change] Kaplan, H., "Why URIs Are Changed Crossing
Domains", draft-kaplan-sip-uris-change, February 2008.
Author's Address
Hadriel Kaplan
Oracle
Email: hadriel.kaplan@oracle.com
Kaplan Expires March 2014 [Page 37]
