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:@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 '._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]