Internet Engineering Task Force I. Brown INTERNET-DRAFT University College London Expiration Date: 5 February 2002 5 July 2001 Securing prioritised emergency traffic Ian Brown Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom draft-brown-ieps-sec-00.txt I.Brown@cs.ucl.ac.uk Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Copyright (C) Internet Society 2001. All rights reserved. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. Abstract The International Emergency Preference Scheme and International Emergency Multimedia Service are ITU recommendations that give priority to emergency communications related to disaster recovery. This memo describes the security requirements of providing equivalent functionality in private and public IP networks. Brown UCL [Page 1] Internet-Draft IEPS security 5 July 2001 Table of Contents 1 Introduction 2 2 Objective 2 3 Background 3 3.1 IPSEC 3 3.2 TLS 4 3.3 SIP and RTP 5 4 Authentication 6 4.1 PIN-based 6 4.2 Cryptographic 6 4.3 Fraud Detection 7 5 Recommended Approach 7 6 Scenarios 7 6.1 PSTN-to-IP-to-PSTN 7 6.2 PSTN-to-IP 8 6.3 IP-to-PSTN 9 6.4 Pure IP 9 7 Recommendations 10 8 Security Considerations 10 9 References 10 10 Full Copyright Statement 11 1. Introduction The International Emergency Preference Scheme is a set of mechanisms specified for use in the Public Switched Telephone Network to increase the probability of completion for certain telephone calls during emergencies such as hurricanes or earthquakes. Calls are given a higher probability of completion by exchanges waiting for resources to become available rather than rejecting the call attempt when congestion is encountered, and attempting to use alternate carrier routing if network congestion is encountered. IEPS calls are also exempted from restrictive network management controls [ITU00a]. The Government Emergency Telecommunications System (GETS) already operating in the United States includes these mechanisms. As telecommunications providers start using the Internet Protocol across their backbone networks, IEPS support is a feature they may wish to extend to the new transport layers to continue their ability to provide this service to support emergency recovery operations through service level agreements. The end-points of telephone calls may also start migrating to public or private IP networks. An effort is underway in the IETF to standardise mechanisms to provide IEPS support across these composite networks [Carlberg00]. A companion ITU effort has also developed an International Emergency Multimedia Service that will provide similar functionality across a much wider range of applications in packet-switched networks [ITU01]. This document considers the security requirements implicit in such support in more detail. We begin by outlining our security objectives Brown UCL [Page 2] Internet-Draft IEPS security 5 July 2001 and considering the background of existing IP security protocols that can be used to meet these objectives. We then describe our recommended approach and show how secure IEPS/IEMS support can be provided in different configurations of PSTN and IP networks. We conclude with recommendations to implementers of IEPS/IEMS-enabled IP networks. 2. Objective There are two primary security requirements for IEPS/IEMS: preventing theft and denial of service by unauthorised users and ensuring the integrity of calls using the system. As far as possible, we wish to build on the security mechanisms within existing IEPS systems and existing Internet standards. Ideally, IEPS users should not require separate authorisation mechanisms for the PSTN and IP networks. We also aim to minimise complexity of the system in order to reduce cost and maximise security. Finally, we want to provide a flexible framework within which telecommunications providers may use the methods best suited to their networks. 3. Background Several security protocols are already in use by IP telephony applications. IPSEC and TLS are general-purpose network and transport layer protocols that ensure the confidentiality and integrity of communications. SIP and RTP are application-layer protocols that define call signalling and content formats, and use application- specific security extensions. This background section describes these protocols in more detail. Further background information is available in a report from Telcordia [Telcordia00]. 3.1 IPSEC The Internet Protocol Security (IPSEC) working group of the Internet Engineering Task Force is completing standardisation of security mechanisms for IP packets. Their work is a mandatory part of IPv6 and can also be supported using option fields in IPv4. The specifications provide an algorithm-independent framework into which specific cryptographic methods can be inserted [Thayer98]. Two mechanisms are used to protect packet data. The Authentication Header (AH) allows data to be signed, assuring its authenticity and integrity but not secrecy. The Encapsulating Security Payload (ESP) provides confidentiality. Both mechanisms can be used in tunnel mode (an entire IP packet is encapsulated within another before applying the security services) or transport mode (only higher-layer data is secured). ESP mode can also incorporate authentication procedures, but AH allows the protection of immutable and predictable IP headers, which ESP cannot provide in transport mode. Brown UCL [Page 3] Internet-Draft IEPS security 5 July 2001 The Authentication Header goes between the IP and higher layer headers of a packet, and contains information that the recipient can use to authenticate the sender and contents of the rest of the packet. This is more efficient than applying transformations to the entire packet. An anti-replay service can prevent old traffic being resent to a host, using sequence numbers in the authentication header. ESP is used to encrypt data before it leaves the sender, hiding its contents until it reaches the receiver, who decrypts it using the secret key they share with the sender. In tunnel mode, the source and destination of the encapsulated packet can be hidden, so preventing some traffic analysis attacks. The padding used to ensure the data being encrypted is the correct length for use with a specific cipher can also be extended to conceal the true length of that data, providing further traffic flow confidentiality. Transport mode is simpler, and normally used between end systems. If a security gateway is at either end of a connection, tunnel mode must be used. Tunnel mode is also less disruptive to the current Internet infrastructure, as packets look entirely normal to routers. Only at the end of their journey are the encrypted and authenticated contents of a packet revealed. Security gateways can forward such packets to hosts without IPSEC support. AH and ESP both require communicating hosts to share secret keys to authenticate and encrypt transmitted data. It is relatively simple to manually configure hosts with fixed keys, but this is completely unscalable. Hosts also need to agree on the cryptographic systems they both understand. The Internet Key Exchange (IKE) allows two hosts to agree on these parameters [Harkins98]. After setting up a secure ISAKMP (Internet Security Association and Key Management Protocol) link [Maughan98], IKE hosts generate keys for, and negotiate, IPSEC Security Associations. Each association is used by network code to select the transformations it will apply to each packet. The exchange is finally authenticated to prevent a man-in-the-middle attack, and optionally identify each host. Various types of certificate can be used at this stage to increase the security of the authentication. ITU Recommendations H.323 and H.248, IETF Megaco, and AT&T PacketCable use IPSEC to protect signalling messages. H.323's call control messages and PacketCable's call content can also be secured using IPSEC. 3.2 TLS Secure Sockets Layer (SSL) is probably the most widely used security standard on the Internet. It is a transport-level protocol designed by Netscape to enable secure communication Brown UCL [Page 4] Internet-Draft IEPS security 5 July 2001 between a Web browser and server. Almost all secure Web access takes place over a SSL connection. TLS (Transport Layer Security) is the standardised successor to SSL [Dierks99]. Its goal is to provide privacy and data integrity between two communicating applications. TLS is composed of two protocols: the record protocol, which provides a private and reliable connection, and the handshake protocol, used to authenticate client and server and negotiate cryptographic algorithms and keys. The record protocol fragments data into blocks of 214 bytes or less. Each block can be compressed, encrypted, and authenticated using a MAC (Message Authentication Code). A key calculation algorithm is used to generate keys, Initialisation Vectors for the encryption and MAC secrets from secret parameters supplied by the handshake protocol. The handshake protocol negotiates each session: a session identifier, compression method, cipher specification (encryption and MAC algorithms), 48-byte master secret, a resumable flag and optional certificates for either party. A resumable session can be used to set up several connections. A session can be renegotiated at any time during a connection. Alert messages of varying levels may be sent; "fatal" alerts cause the connection to be terminated and session invalidated for future connections. H.323 can use TLS to protect call signalling and control messages. 3.3 SIP and RTP The Session Initiation Protocol allows participants to be invited to multimedia videoconferencing sessions using a simple ASCII- based protocol. Extensions have been defined to allow authenticated and private invitations using the secure e-mail S/MIME and PGP formats [Handley99]. These invitations can also contain keys used to encrypt the conference material itself using the Real-time Transport Protocol [Schulzrinne96]. The now- discredited Data Encryption Standard is the standardised cipher used for this encryption. RTP does not provide authentication services, and originally expected all of its security capabilities to be superseded by services provided by IPSEC once that becomes widespread. A Secure RTP standard is now being defined that allows RTP packets to be encrypted and authenticated whilst still allowing header compression, which is useful for low-capacity wireless links [Blom01]. PacketCable can also use the RC4 encryption algorithm with RTP to protect call content. 4. Authentication Brown UCL [Page 5] Internet-Draft IEPS security 5 July 2001 IEPS/IEMS users must demonstrate they are authorised to use the service before placing a call, in a similar way to calling card owners. GETS users are authenticated by a twelve-digit personal identification number (PIN); fraud detection techniques are also used to watch for suspicious usage patterns. IP devices could use cryptographic methods to authenticate their users to the network. It would also be possible to reuse the authentication framework from the next generation mobile phone protocol 3GPP [ETSI00]. 4.1 PIN-based GETS users are currently authenticated by an interexchange carrier contracted to provide the service using a PIN entered through the originating telephone. GETS users dial a toll-free number beginning with the non-geographic area code 710, then enter a PIN and the number they wish to call. Databases of authorised PINs are regularly distributed to the interexchange carriers by the responsible government agency, the National Communications System. This system relies on physical line security to protect PINs and the carrier's infrastructure security to prevent call hijacking. This system can be used virtually unchanged with IEPS over IP. It could even be extended for use as a password with dial-up Internet connections. Carriers just need to ensure their networks recognise an equivalent of the 710 area code, verify such calls with an authentication centre, and use the resulting approval or non- approval to decide whether to give the call priority. Users could also be provided with one-time PIN devices such as RSA's SecurID card. This calculates a new PIN every 60 seconds using a secret shared between the card and the authorisation centre along with a user-entered PIN. 4.2 Cryptographic More secure authentication of IP devices is possible using cryptographic mechanisms. Authorised IEPS/IEMS users would be provided with a shared secret key or digital certificate to authenticate themselves to IEPS-capable networks. To protect these secret keys and allow them to be used from a wide variety of locations, they would almost certainly be stored on a smartcard. This would require that communications devices contain smartcard readers. One way to achieve widespread interoperable authentication with PSTN and IP devices would be to use 3GPP Subscriber Identification Modules. The user's home network would provide priority service to authorised users locally, and signal to remote networks that a given roaming user was authorised for emergency preference service. Brown UCL [Page 6] Internet-Draft IEPS security 5 July 2001 4.3 Fraud detection The IEPS/IEMS threat model is mostly concerned with theft of service. Because network operators can limit total prioritised calls to a small percentage of their total capacity, prevention of all unauthorised usage is not an absolute priority. Fraud detection techniques can be used later to identify and update compromised PINs and systems, and to attempt to trace the perpetrators. Techniques used by GETS operators include detection of simultaneous use of a given PIN, use of one PIN from distant locations within a short time period, and other more sophisticated usage pattern analysis. While fraudulent use can often be recognised in real-time, carriers do not terminate such calls immediately but instead log details for later investigation. The impact of denial of service attacks can be reduced by authorising users with the minimum resources required. Devices originating such attacks may be temporarily ignored by an authentication service. 5. Recommended Approach We believe that the following protocols best meet our objectives: IPSEC should be used to protect the confidentiality and integrity of call signalling and content. This protocol has gone through nearly 10 years of development and analysis. Its long development period and potential widespread use have led to far more detailed scrutiny than application-specific protocols from large numbers of independent security engineers, who have discovered and corrected several flaws. And unlike TLS, IPSEC support is mandatory in all IPv6 devices. This reduces the complexity and potential security problems of adding security libraries and code to individual applications. IPSEC is widely supported by existing IP telephony protocols. Whilst Secure RTP offers some advantages for audio, the far wider requirements of IEMS make it an unsuitable general solution here. Standardizing on this protocol also removes the potential PKI duplication necessary in supporting other protocols. Although IPSEC, TLS and SIP can all theoretically use X.509 certificates [ITU00b], getting them to inter-work correctly in practice might cause difficulties in initial implementations. PIN-based authorization should remain the primary access control mechanism. This removes the need for users to remember how different mechanisms and secrets work in placing calls using PSTN or IP telephones – and from needing to work out which is which! Where possible, IEPS/IEMS authorization should be integrated with existing authentication protocols to reduce unnecessary overhead. Fraud Brown UCL [Page 7] Internet-Draft IEPS security 5 July 2001 detection should continue to be used to detect unauthorized use of the system. In the longer term, smartcard/SIM-based authentication may become more feasible. 6. Scenarios This section examines in more detail how our recommended approach would be applied in the primary scenarios identified for IEPS use [Carlberg00]. 6.1 PSTN-to-IP-to-PSTN The most imminent scenario for IEPS-over-IP use is where a carrier's backbone network uses IP to transport calls between two PSTN domains. Authorisation of the call originator occurs as before using a PIN entered through the telephone. The carrier then uses traffic engineering to give enhanced priority to that data as it enters and flows across the IP backbone network. It uses the IEPS telephony methods to increase the likelihood of successful call set-up at its gateway back into the PSTN. The carrier uses its standard infrastructure security to prevent unauthorised use of the facility and protect the integrity of calls. If the carrier has IP peering arrangements with other networks that are closer to a call's end-point, the prioritised traffic can flow directly onto their networks rather than first travelling back into the PSTN. Peering agreements must describe the level of prioritised traffic that may travel between the two networks, and a method of signalling that traffic priority. DiffServ codepoints [Blake98] are a convenient way to do so. The ingress points will perform traffic policing to ensure compliance with the agreement and limit the theft of service possible given compromise of the originating network. For added confidentiality and integrity protection, the carrier may choose to tunnel the traffic between the backbone ingress and egress points using IPSEC. 6.2 PSTN-to-IP An even simpler scenario is where the end-point of the call is an IP device. Again, the caller is authorised using a PIN, and the resulting voice traffic marked as prioritised by the carrier's PSTN-IP gateway. The use of a standardised marking is more important here, as the traffic is likely to flow across several IP networks to its destination. At each gateway, the ingress point performs traffic policing. If a network in the path to the final traffic destination does not support IEPS Quality of Service prioritisation, the call will lose its priority on that network. Unless that network performs traffic policing, other networks later in the route will be unwilling to Brown UCL [Page 8] Internet-Draft IEPS security 5 July 2001 accept marked traffic. They would otherwise be open to a massive theft of service threat. If traffic policing is performed and IEPS packets are accepted, the call will regain priority as it moves back onto IEPS-capable networks. To protect the confidentiality and integrity of the call traffic as it travels across diverse networks, the PSTN-IP gateway should tunnel it directly to the endpoint using IPSEC. The outer packet must be marked to allow recognition by intermediate routers. 6.3 IP-to-PSTN An IP device placing a call to a PSTN telephone must first discover an appropriate PSTN gateway. While the details of that discovery procedure are outside the scope of this document, the simplest method is to connect to a known address within the user's ISP network, which then carries out the appropriate forwarding. The device's first-hop network must recognise that its user is allowed IEPS/IEMS service. This can be integrated into the network's login procedure: only certain users will be so authorised. Alternatively the user may authenticate themselves to the network using the same procedure as on the PSTN: by dialling a known number and PIN. In the first case, the user requires a mechanism to start the IP device marking outgoing packets as prioritised. In the second, the network may signal to the device that it should do so, or mark the packets itself at its ingress point. An IEPS-compliant gateway back into the PSTN recognises the prioritised IP traffic and uses IEPS telephony methods to increase the likelihood of successful call setup. These methods can also be used to prioritise the first-hop telephone call connecting an IP device using a dial-up connection to an ISP. If the signalling and content gateways are not co-located, the former must securely instruct the latter to route the call traffic onto the circuit set up by the signalling gateway. To protect the confidentiality and integrity of the call traffic, it should be tunnelled by the originating IP device using IPSEC to the IP-PSTN gateway. This will also allow devices on non-IEPS compatible networks to authorise themselves to an IEPS-supporting IP-PSTN gateway using any of the standard IPSEC authentication mechanisms. Their traffic on the PSTN side of the connection will then be prioritised. 6.4 Pure IP The simplest scenario is that both end-points of an IEPS/IEMS call are IP devices linked by public or private internets. Again, the call originator must mark call traffic packets as prioritised. The Brown UCL [Page 9] Internet-Draft IEPS security 5 July 2001 ingress point of their first-hop network must recognise that the originator is authorised for this service, and allow the marked packets to flow across its network. As before, packet prioritisation will be lost if the packets must flow across a non- IEPS-compliant network. For this reason, IEPS-compatible networks may attempt to use policy-based routing to keep such traffic on IEPS-capable networks. For maximum assurance of call integrity and confidentiality, there should be an end-to-end IPSEC link between the originator and recipient of a call. 7. Recommendations We recommend that IEPS/IEMS-compliant networks should meet the following requirements: * IEPS/IEMS users should be authorised using a PIN or as part of their network sign-on procedure. * Authorised users may send packets marked as IEPS/IEMS traffic. Their ingress network may alternatively mark packets. Networks must either discard IEPS-marked packets sent by unauthorised users or relabel those packets with a standard priority marking. * Inter-domain IP gateways must police prioritised traffic according to the service-level agreement between the domains. Gateways must not accept IEPS-marked packets from networks that do not police IEPS traffic; such packets may be dropped or re-marked. * Gateways between domains using different QoS mechanisms (such as DiffServ and Weighted Fair Queuing) must be able to translate IEPS markings appropriately. * IP-to-PSTN gateways should use IEPS telephony mechanisms to provide priority for calls set up by IEPS/IEMS traffic. * PSTN-to-IP gateways should mark packets resulting from an IEPS telephony call as IEPS/IEMS-authorised. * IP traffic should be protected using IPSEC to the maximum possible extent. 8. Security Considerations This entire document is about security. 9. Acknowledgements Many thanks to Ken Carlberg, Hal Folts, Stu Goldman, Jack Garrity, James Polk and Gary Thom for their comments on this draft. Brown UCL [Page 10] Internet-Draft IEPS security 5 July 2001 10. Author's Address Ian Brown Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom Phone: +44 20 7679 3704 Fax: +44 20 7387 1397 E-mail: I.Brown@cs.ucl.ac.uk 11. References [Blake98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998. [Blom01] R. Blom, E. Carrara, D. McGrew, M. Naslund, K. Norrman, and D. Oran, The Secure Real Time Transport Protocol, IETF work-in- progress, February 2001. [Carlberg00] K. Carlberg and I. Brown, Framework for Supporting IEPS in IP Telephony, IETF work-in-progress, November 2000. [Dierks99] T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999. [ETSI00] ETSI TR 33.102, 3GPP security architecture, December 2000. [Handley99] M. Handley et al, SIP: Session Initiation Protocol, RFC 2453, March 1999. [Harkins98] D. Harkins and D. Carrel, The Internet Key Exchange, RFC 2409, November 1998. [ITU00a] ITU-T Recommendation E.106, Description of an International Emergency Preference Scheme (IEPS), draft-itu-t-ieps-description- 00.txt, March 2000 [ITU00b] ITU-T Recommendation X.509, The Directory: Public-key and attribute certificate frameworks, March 2000 [ITU01] ITU-T Draft Recommendation F.706, International Emergency Multimedia Service, 2001 [Maughan98] D. Maughhan et al, Internet Security Association and Key Management Protocol, RFC 2408, November 1998. [Schulzrinne96] H. Schulzrinne, S. Casner, R. Frederick, and V. Brown UCL [Page 11] Internet-Draft IEPS security 5 July 2001 Jacobson, RTP: A Transport Protocol for Real-time Applications, RFC 1889, January 1996. [Telcordia00] Telcordia Technologies, Next Generation, Voice over Packet, and Hybrid Networks Security Issues, Report to National Communications System, September 2000. [Thayer98] R. Thayer, N. Doraswamy, and R. Glenn, IP Security Document Roadmap, RFC 2411, November 1998. 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brown UCL [Page 12]