Lawful Intercept ISOC MEMBER BRIEFING #22 --------------------------------------------------------- July, 2006 by Fred Baker --------------------------------------------------------- Lawful Intercept 1. Defining Lawful Intercept Lawful interception is the mechanism and process of legally sanctioned official access to private communications, such as telephone calls or e-mail messages. In general, this is carried out under the legal mandates of a country by a network operator or service provider, who gives law enforcement officials access to the communications of private individuals or organizations. Countries around the world are drafting and enacting laws to regulate lawful interception procedures, and several standardization groups are creating Lawful Intercept technology specifications. Mechanisms used for access to private communications fall broadly into four categories: record review, pen register or trap-and-trace, content intercept of a specific subject, and content intercept of data whose content appears to be relevant to an intelligence activity. Billing record review: The fact that one telephone number has called another, especially if there is a pattern of frequent calls or calls at important times, may suggest that persons having access to the relevant instruments talk with each other, and in the presence of other information may be interesting to a criminal investigation. This is so commonly used that in many countries it is not classified as an Lawful Intercept procedure. Pen register or trap-and-trace: A US procedure that results in timely notification to law enforcement that a surveillance subject is using a communication instrument and informs them of the other party's number. Pen Register taps detail the numbers a subject calls, and Trap-and- trace taps detail the numbers the subject is called by. Content intercept: An interception procedure that captures the actual communications of a specific surveillance subject. Intelligence intercept: Agencies may request the interception of all information for further processing. This has significant processing requirements and is not done in criminal investigations in western countries. There are a number of requirements that generally apply to the security of Lawful Intercept taps. These include: Confidentiality: Very few people are permitted to know of the existence of the tap. In the case of the criminal, the reason is obvious. But there is also concern for the reputation of the subject, who may be guilty of no crime, and general concern that a secret held among many is not a secret. Transparency: The data delivered to law enforcement must be the data that was actually exchanged. This data may be used by both prosecution and defense and must therefore be whole and correct. Specificity: The warrant for an intercept specifies what must be delivered. This is generally the communications of a specific person. The service provider is required, to the extent of its capability, to provide all warranted communications, and only those communications. 2. History Intelligence analysts have intercepted the communications of their adversaries for thousands of years. This has mostly been in military matters; both ancient Greece and China developed encryption technologies as a way to defeat this. With the development of modern telephone and data communication networks and criminal networks that use them, law enforcement in many countries has sought access to communications content for the purpose of mapping criminal networks and gleaning what is possible from their conversations. Who talks with whom is as important as what they actually say, as the evidence useful in court is generally of the more traditional variety, but communications can direct an investigation in productive directions. 2.1. Legal History There have been several key legal steps in recent years, enacting laws regulating existing uses of the capability. In US law, these have included the Omnibus Crime Control and Safe Streets Act (OCCSSA) of 1968, the Foreign Intelligence Surveillance Act (FISA) of 1978, and the Communications Assistance for Law Enforcement Act (CALEA) of 1994, and more recently the passage of the Providing Appropriate Tools Required to Intercept and Obstruct Terrorism (PATRIOT) of 2001. As a result of a mandate from the European Union, EU members are writing their previously secret procedures into law, resulting in the UK's Regulation of Investigatory Powers Act of 2000, the publication of the Dutch TIIT, and other regulations and specifications. Many countries throughout the world are similarly documenting and regulating their procedures. These regulations have generally provided for interception of communications in the telephone network, and more generally the interception of communications of any kind. In most parts of the world, this is applicable only to traffic passing through a public carrier such as an ISP. In the US, recent FCC rulings seem to extend this to enterprise networks such as universities and corporate networks. The courts have not, however, ruled on this extension of the regulation. Under the Council of Europe"s auspices, a Cybercrime treaty [COE] has been written that was signed by 26 countries upon its completion in 2001 and has been amended since. This has two operative titles regarding Lawful Intercept. In Title V, entitled "Real-time collection of computer data", Article 20 discussed the real-time collection of traffic data, which in the telephone system is understood to mean Call Detail Records, and Article 21 discusses the interception of content data. Both instruct signatory countries to adopt legislation compelling service providers to collect the indicated information and deliver it to law enforcement under the appropriate authority. The document may be found at . There has also been a great deal of controversy on the topic, with various citizen and political action groups working to limit the capability or the use of Lawful Intercept, and law enforcement insists that it is one of the most useful tools available to them. 2.2. Technical History in the Internet Technically, the IETF has looked at the problems related to forensic use of the network twice, and commented that it imposes costs and choices that may not be the same as their telephone counterparts, and may not be commensurate with the evils they counter. In 1993-1996, various proposals suggested (and in France required) encryption keys used by a company or person be archived, so that if a file was subpoenaed later it would be possible to recover its contents. On the surface, this seemed reasonable, as businesses have a business need to gain access to their own records. However, the IETF determined that mandated key archival [RFC1984] or recovery procedures had a significant cost: the reason that the data was encrypted was compromised. For example, if private keys were archived so that financial transactions could be performed by a trusted third party and the third party were compromised, fraudulent transactions could be the result or a valid transaction might be repudiated. The IETF's perspective is that while technically many things are possible, not all of them are wise, and this one is particularly unwise. More recently, the IETF was asked to modify the Megaco protocol (H.248) [RFC3525] to incorporate telephony's lawful intercept features, in support of the interception of voice sessions under CALEA. The IETF commented in [RFC2804] that voice is just one of many applications that run over the Internet, so modifying a protocol specific to voice is not a reasonable approach. Rather, if one wants to intercept IP datagrams from or to a surveillance subject, and noting that most countries that have Lawful Intercept regulated in a publicly readable document (and specifically the [COE]) apply the same rules to all communications as opposed to simply voice, one should build a feature that intercepts IP datagrams. Modifying the protocol only addresses applications that use that protocol, which do not even include all instances of voice calls, much less other IP traffic. The IETF went on to assert that it didn't care to get into the topic, but called on those who did to publish their specifications so that the Internet community could comment on their security features. This was in fact done with [RFC3924]. ETSI then picked up the topic, proposing in its initial proposal that the obvious way to implement Lawful Intercept is to split every fiber or lambda in every ISP and run one instance under the door of the relevant law enforcement agency. This is relatively inexpensive for the ISP and very secure in the sense that nobody outside the LEA need know that an intercept order had even been placed. However, that had legal problems in many countries, most notably with the audit systems that verify lawful use, and [RFC3924] was written to document an approach that, while more complex, preserved the privacy of those who were not surveillance subjects and the ability to have verifiable audit trails. The Danish Police have more recently proposed a variation on trap- and-trace, under the considerations of Article 20 of the [COE]. Starting from the observation that [I-D.ietf-ipfix-protocol] records the source and destination IP address of a data flow along with other information, and noting that application logs (web, email, instant messaging, and the like) note information regarding who talks with whom, they asked to have logs maintained for a period of six to twenty-four months detailing the equivalent of a Call Detail Record for every session terminating within that country along with information detailing who owned the IP addresses at the time, to the extent that is known. This information is envisioned as being available to police through appropriate legal authorization, for contact network analysis. This is seen as a prototype for the Data Retention statute recently adopted by the European Commission [EU-Retention], the specification for which may be found at . The advantage of such an approach over continuous interception of all content should be obvious; however, ISPs generally don't keep such records, and when they do delete them within days of having done so, for reasons related to privacy. Since it has no value to the ISP, the imposition of such record-keeping is costly to the ISP, and may have legal ramifications. Also, since application addressing information is not generally known to the ISP, which operates at the network layer, it is not obvious that the intention can be acheived without the collaboration of the communicating entity, which would in this case be or be related to the surveillance subject. 3. Technical issues The principal technical issues in Lawful Intercept technology have to do the implications of identifying and capturing "interesting" traffic in a legally useful manner, or with the security issues in the technology. There are obviously political and legal issues as well, on which the world is not of one mind. 3.1. Content Intercept In a content intercept, the implications of identifying and capturing "interesting" information include the issues of o identifying the relevant datagrams, o duplicating them, o tagging them according to what intercept order they belong to o reliably transporting them to the mediation device (the system that presents the intercepted information to the law enforcement agency), and o protecting them while in transit, normally using encryption. This must be done in real time, at whatever rate the surveillance subject can generate them. For example, it may be that the surveillance subject is using servers co-located at ISPs and is therefore limited in rate only by the ISP's capacity; in such a case, it may be quite rational to expect the surveillance subject to move files at hundreds or thousands of megabits per second - a far cry from the 64 KBPS common in voice intercept applications. Thus, data classification must occur at line rate with even very high end lines, something that older equipment may not do. Thus, the deployment of a lawful intercept capability may require upgrading line cards in ISPs. This can be done piecemeal if interception is an uncommon occurrence; if it is something that has to be done on all interfaces in the ISP at all times, it may imply a widespread simultaneous upgrade. "Reliable" transport of data can be problematic, if this implies carriage in TCP, because of TCP's congestion management mechanisms and the necessity of calculating a checksum. The problems here include the rate of data transfer to the CPU in question and the functions being asked of it. While ETSI has proposed the use of a profile of TCP that doesn't implement congestion avoidance, past implementations of such profiles have not worked well in the Internet. [RFC3924] suggests the use of a protocol derived from RTP NOR, which retransmits on a NACK and whose sessions will survive temporary outages. One solution to these issues is the use of dedicated interception hardware. One generally doesn't presume special hardware dedicated to this function, and the CPU in the router or switch is designed to support the needs of the control plane, not a high rate data processing function. If dedicated hardware is called for, this also represents a cost to the ISP that deploys it. Encryption is generally also a cost function; unless the CPU already has encryption support built in, this often requires installation of an encryption card. Finally, bandwidth to deliver the content is a cost function. There are ways to economize on bandwidth, such as putting a mediation device in each point of presence; mediation devices are not free either. None of this is to say that content interception is impossible; in fact, it is very possible. But if the deployment schedule or the technology required is chosen poorly, it can be very expensive to deploy and to carry out once deployed. Since ISPs often operate on thin margins, companies may choose to go out of business rather than comply with the mandate. A wise government will find ways to fund the deployment, and to plan the deployment with the ISPs so that they are not faced with this possibility. 3.2. Data Retention Data retention using [I-D.ietf-ipfix-protocol] is far simpler, and seems likely to meet the needs of an investigation that simply wants to know what system talks with what system. Even this is not free, however. At high rates, the process of summarizing information and sending the summary to the mediation device can still overwhelm the CPU. For ISP purposes, as a result, IPFIX is often a statistical process, summarizing a subset of the data flows with a view to estimating the results. Extending this in the manner that the Danish have suggested - capturing session detail records for every session terminated within the country at all times and storing it for six to twenty-four months - even maintaining an IPFIX flow record (32 bytes or more for every session, which on average means for every 10-20 datagrams traversing an interface) can be a heavy imposition. ISPs generally do this for a single interface for a given customer for a short period of time, with a view to understanding a problem that a customer is facing, or in a statistical manner for the purpose of diagnosing attacks, with the data being discarded very rapidly. Doing it for all interfaces all the time implies a requirement for additional switching hardware, and for significant offline storage. Also, note that IPFIX gives network layer information, which identifies the IP addresses in an exchange, but does not identify the individuals. To gain the same information for an application like electronic mail, instant messaging, or internet telephony, one must derive this from server logs. Further, note that not all applications have servers to retain logs. For example, the instant messaging application Jabber uses SIP, which has the option of using a proxy to effect a session setup but does not require that (sessions may be set up directly from endpoint to endpoint), and in any event the data exchanged goes directly from endpoint to endpoint. Similarly, while SMTP mail is carried from server to server (called a mail Transfer Agent, or MTA), there are generally many successive servers in an exchange, and the ISP carrying the mail knows only of its own servers. It is possible for ISPs to restrict traffic that is labeled as SMTP to their own servers, but someone seeking to evade such a restriction can do so simply by using a different port number. As a result, the ISPs carrying the IP traffic generally have little knowledge of the actual communicating endpoints. 3.3. Implications The implication is that lawful intercept functionality can be deployed in a manner that meets the needs of law enforcement to investigate criminals and crimes, but for reasons of cost and complexity, there are good ways to do it and ways that are harder. 4. Dangers in Lawful Interception One of the concerns raised in the Internet community regarding Lawful Intercept is that once the capability is deployed, it can be used by anyone with the ability to coerce its deployment. One well-known example is the use of wiretap by the LAPD Narcotics Bureau, which has allegedly under-reported the use of the capability and has allegedly used it in a manner that has denied defendants their right to knowledge of the evidence against them. Another is the recent Pellicano wiretap indictment, in which a private investigator allegedly used contacts in the Los Angeles and Beverly Hills police departments and at the phone company to illegally wiretap phones as well as to gain access to the confidential National Crime Information Center (NCIC) database. A specific and very high profile case has arisen in Greece. According to reports, more than 100 mobile phone numbers belonging mostly to members of the Greek government and top-ranking civil servants have been found to have been illegally tapped for a period of at least one year. The details of the case were presented at a press conference given by three government ministers on Thursday February 2, 2006. The phones tapped included those of the Prime Minister Costas Caramanlis and members of his family, the Mayor of Athens, Dora Bakoyannis, most phones of the top officers at the Ministry of Defense, the Ministry of Foreign Affairs, and the Ministry of Public Order, members of the ruling party, the Hellenic Navy General Staff, the previous Minister of Defense (at the time a member of the opposition party), and one phone of the American Embassy. Moreover, the mobile phones of former National Defense Minister Giannos Papantoniou and businessmen of Arab descent were also at the foresight of the wiretapping ring, as well as of former governmental officials from the Panhellenic Socialist Movement (PASOK). In short, the information made available through wiretap is not always made available to the police, and when it is, is not always used as the legislation intends. As such, strong audit trails and public visibility are critical to the use and deployment of the capability. 5. ISOC Position First, we do not recommend the use of content interception unless it is determined to be of significant value. Since an increasing proportion of Internet traffic is encrypted, notably the traffic carried by the applications Skype, KaZaa, and BitTorrent, and the increasing popularity of VPN technology, intercepted content is not necessarily of great value. Note that information available in the unencrypted headers is available through Data Retention techniques like IPFIX. Second, Data Retention on a broad basis has no value to the ISP, and is therefore itself a costly procedure that is useful to law enforcement in a vanishingly small percentage of cases. As such, from a technical perspective, we recommend that data retention be deployed only after a warrant has been issued, rather than across a general population on a standing basis. As mentioned, we take the position that auditability and regular audits are a critical component. This is not a matter of disrespect towards the police or the government, but noting the vulnerabilities that they are subject to. We understand the argument that in the wake of recent tragedies it has become expedient to be able to look backwards, as one does not necessarily know whom to tap. The result of that line of reasoning, though, is to treat all people as suspect, which has an acid effect on the structure of society, and in the US in particular violates the constitutional notion that people are "innocent until proven guilty". Rather, we suggest that it may be preferable to make it easier to initiate a temporary data retention procedure, in order to avoid having to impose it throughout the population. ISOC has for a long time held that there are six fundamental abilities that are important to Internet deployment. These are the abilities to connect, speak, innovate, share, choose, and trust. While law enforcement capabilities have grown in response to those who are not trustworthy, whose choices are not the best for society, who share materials that harm their audience and often those involved in their creation, and whose innovations are to the detriment of society, the society in which we live is not characterized by these people. As such, ISOC believes that it is the duty of law enforcement to protect those for whom these abilities are appropriate, and to preserve those abilities for their use. In breaching them to catch criminals, we should not breach them for those who are not. We therefore strongly recommend the conservative deployment of these technologies, targeted narrowly at the criminal element, rather than in a manner that is costly to the general public, and potentially harmful to the law-abiding citizen. We also recommend that governments that mandate interception services materially contribute to the costs of their deployment, operation, and necessary training of ISP and law enforcement staff. 6. References [COE] Council of Europe, "Convention on Cybercrime", 2001. [EU-Retention] European Parliament, "Directive 2006/.../EC of the European Parliament and of the Council of Ministers on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC", 2006. URL: http://ec.europa.eu/commission_barroso/frattini/doc/2006/pr_21_02_06_en.pdf [I-D.ietf-ipfix-protocol] Claise, B., "IPFIX Protocol Specification", draft-ietf-ipfix-protocol-19 (work in progress), September 2005. URL: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-19.txt [RFC1984] IAB, IESG, Carpenter, B.(brian@dxcoms.cern.ch), and F. Baker(fred@cisco.com), "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. URL: ftp://ftp.isi.edu/in-notes/rfc1984.txt [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. URL: ftp://ftp.isi.edu/in-notes/rfc2804.txt [RFC3525] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. URL: ftp://ftp.isi.edu/in-notes/rfc3525.txt [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture for Lawful Intercept in IP Networks", RFC 3924, October 2004. URL: ftp://ftp.isi.edu/in-notes/rfc3924.txt __________________________________________________________________________ Expanded Coverage from ISOC In-depth articles, papers, links and other resources on a variety of topics are available from the ISOC site at: www.isoc.org/internet/issues Relevant IETF RFC's RFC 3696 Application Techniques for Checking and Transformation of Names RFC 3490 Internationalizing Domain Names in Applications (IDNA) RFC 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) RFC 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) RFC 3454 Preparation of Internationalized Strings (stringprep) IESG Statement When the IDNA RFCs were approved as Proposed Standards and for publication, the IESG issued a statement that put that work in context. That statement has been posted at http://www.ietf.org/IESG/STATEMENTS /IDNstatement.txt. For More Information "National and Local Characters in DNS TLD Names", http://www.ietf.org/internet-drafts/ draft-klensin-idn-tld-03.txt, contains a discussion of this issue from a somewhat more technical point of view. Related Organizations www.ietf.org www.rfc-editor.org About the Author Dr. John C. Klensin is now an independent consultant following a distinguished career as Internet Architecture Vice President at AT&T, Distinguished Engineering Fellow at MCI WorldCom, and Principal Research Scientist at MIT. He served on the Internet Architecture Board from 1996-2002 and was its Chair from 2000 until the end of his term. Earlier, he served as IETF Area Director for Applications and was Chair, Co-chair, and/or Editor for IETF Working Groups focused on messaging and IETF process issues. He was involved in the early procedural and definitional work for DNS administration and top-level domain definitions and was part of the committee that worked out the transition of DNS-related responsibilities between USC-ISI and what became ICANN. He participated actively in a number of efforts to expand internationalization of the Internet, ranging from early character set requirements work, through the efforts to permit and identify non-ASCII character sets in email, and including IDN efforts in the IETF, ICANN, and elsewhere. He was also involved in the design and development of the Internet's email system from its beginnings, and has been heavily involved in internationalization issues, for the Internet and in other areas, for many years. Acknowledgments The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and Ripe NCC, Sida. More information on the Platinum Sponsorship Program: http://www.isoc.org/isoc/membership/platinum.shtml About the Background Paper Series Published by: The Internet Society 1775 Wiehle Avenue, Suite 102 Reston, Virginia 20190 USA Tel: +1 703 326 9880 Fax: +1 703 326 9881 4, rue des Falaises CH-1205 Geneva Switzerland Tel: +41 22 807 1444 Fax: +41 22 807 1445 Email: info@isoc.org Web: http://www.isoc.org/ Series Editor: Martin Kupres Copyright © Internet Society 2006. All rights reserved.