Internet Engineering Task Force I. Brown INTERNET-DRAFT University College London Expiration Date: 30 December 2002 June 2002 A Security Framework for Emergency Communications 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 2002. All rights reserved. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. Abstract The Public Switched Telephone Network includes several mechanisms that increase the probability of completion for telephone calls made by authorised disaster relief personnel during emergencies such as hurricanes or terrorist attacks. This memo describes the security requirements of providing this functionality in private and public IP networks, and how these requirements can be met using existing protocols. It also specifies which enhancements are necessary to these protocols to allow enhanced functionality such as roaming access. Brown Expires 30 December 2002 [Page 1] Internet-Draft ETS security June 2002 Table of Contents 1 Introduction 2 2 Objective 3 3 Background 3 3.1 IPSEC 3 3.2 TLS 5 3.3 SIP and RTP 5 3.4 H.235 6 4 Authentication 6 4.1 PIN-based 6 4.2 Cryptographic 7 4.3 Fraud Detection 7 4.4 Roaming access 7 5 Recommended Approach 8 6 Scenarios 9 6.1 PSTN-to-IP-to-PSTN 9 6.2 PSTN-to-IP 9 6.3 IP-to-PSTN 10 6.4 Pure IP 11 6.5 Roaming 11 7 Recommendations and Requirements 11 8 Security Considerations 12 9 Acknowledgements 13 10 Author's Address 13 11 Normative References 13 12 Informative References 14 13 Full Copyright Statement 14 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 terrorist attacks. 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 [Carlberg02]. Brown Expires 30 December 2002 [Page 2] Internet-Draft ETS security June 2002 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 an Emergency Telecommunications Service in more detail. We begin by outlining our security objectives and describing the existing IP security protocols that can be used to meet these objectives. We then explain our recommended approach and show how secure ETS support can be provided in different configurations of PSTN and IP networks. We conclude with recommendations to implementers of ETS-enabled IP networks and requirements for IETF protocols that would allow enhanced functionality such as roaming ETS access. 2. Objective There are two primary security requirements for ETS: preventing theft and denial of service by unauthorised users and ensuring the confidentiality and 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, ETS users should not require separate authorisation mechanisms for the PSTN and IP networks, or should be able to use pre-existing authorisation mechanisms. 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) extensions are a mandatory part of IPv6 and can also be supported 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 [Kent98a]. The Encapsulating Security Payload (ESP) provides confidentiality [Kent98b]. Both Brown Expires 30 December 2002 [Page 3] Internet-Draft ETS security June 2002 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. 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. Data can be placed in an Encapsulating Security Payload 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. 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. Brown Expires 30 December 2002 [Page 4] Internet-Draft ETS security June 2002 3.2 TLS TLS (Transport Layer Security) is designed to provide privacy and data integrity between two communicating applications (most commonly, a Web server and browser). It is composed of two main 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 2^14 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. Because TLS runs over TCP it is vulnerable to several Denial of Service attacks that have been found on that protocol [eg Bellovin89]. H.323 and SIP 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 conferencing sessions using a simple ASCII-based protocol. Nodes can communicate securely using TLS, and authenticated and private invitations can be sent using the secure S/MIME format [Handley99]. S/MIME also allows invitations to be secured end-to-end, hiding information not necessary for the routing of the invitation from intermediate points. Further privacy for session initiators can be obtained using the privacy services being developed for SIP [Peterson02]. Invitations can also contain keys used to encrypt the conference material itself using the Real-time Transport Protocol [Schulzrinne96]. The 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 Brown Expires 30 December 2002 [Page 5] Internet-Draft ETS security June 2002 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]. A more flexible key exchange protocol is also being defined [Arkko02]. PacketCable can use the RC4 encryption algorithm with RTP to protect call content. 3.4 H.235 The ITU-T's Recommendation H.235 specifies the use of security services by H-series multimedia terminals. It focuses on providing authentication and privacy for call signalling using its own security protocol, TLS or IPSEC, and for call traffic using RTP security extensions. It allows password and certificate-based authentication of users. 4. Authentication ETS 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 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 adapt the authentication framework from the next-generation mobile phone protocol 3GPP [ETSI00]. Users away from their home network can be authenticated with protocols being developed by the Authentication, Authorisation and Accounting (AAA) working group. 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. 4.1 PIN-based US 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. Users would configure a specific ISP account that Brown Expires 30 December 2002 [Page 6] Internet-Draft ETS security June 2002 used a GETS-type access number to dial-up, and then authenticate themselves as someone authorised for ETS service. They would then receive priority in setting up the dial-in connection, along with priority on the IP side of the ISP's network. System-wide user PINs could be replaced by one-time PINs calculated using 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. These shared secrets rather than the PINs themselves would have to be distributed to all points that need to authenticate users; relying on one central authentication centre would create a central point of failure for the whole system. 4.2 Cryptographic More secure authentication of IP devices is possible using on-line cryptographic mechanisms. Authorised ETS users would be provided with a shared secret key or digital certificate [ITU00b] 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 an application on 3GPP Universal Subscriber Identity 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. Again, redundant authorisation points must be provided so that user access is not prevented by the unavailability of one authentication centre. 4.3 Fraud Detection The ETS threat model is most 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. 4.4 Roaming Access Brown Expires 30 December 2002 [Page 7] Internet-Draft ETS security June 2002 The Diameter protocol being developed by the Authentication, Authorisation and Accounting working group allows access networks to authenticate roaming users with their home networks and bill for services provided, as long as it has a roaming agreement with their home network or a roaming consortium containing their home network [Calhoun02]. It is an extensible protocol that allows additional data flows between access and home networks to be defined and used by specific applications. Once an access network has authenticated an ETS user it will provide basic IP service. If an extension to Diameter was defined to allow the transport of Quality of Service information from home to access network, ETS users could also be provided with prioritised service at the link, network [Braun01] and application layers. The Next Steps in Signalling working group is developing building blocks by which such remote QoS support can be provided. A protocol is also being developed by the Seamoby working group to allow context such as QoS to be transferred between access points as a roaming user moves within and between networks. This could allow ETS priority to be maintained for an on-the-move mobile terminal without the need to re-register for this service at each new access point within one session. 5. Recommended Approach The following protocols best meet the requirements we have outlined: A security model of the type used by DiffServ [Blake98] should be the basis for preventing theft of service. ETS-enabled networks must authenticate end users before allowing them to send prioritised traffic over their networks. Prioritised traffic may be passed between two ETS-enabled networks; their interconnection agreement should specify translation between different schemes being used to provide that priority, and a limit on the ETS traffic as a percentage of total capacity. An ETS-compliant network must not accept ETS- marked traffic from users or interconnect points that are not authorised for that service; such traffic should be given only normal priority on the network. Content integrity and confidentiality may be provided using any of the standardised security protocols outlined in section two. TLS and SRTP will be widely deployed in telephony and videoconferencing applications supporting SIP and RTP. H.325 may be used between multimedia terminals supporting that protocol suite. IPSEC can also be used for other IP traffic such as e-mail transport or Web access, and will be widely supported in IPv6 devices. PIN-based authorisation should remain the primary access control mechanism for simple telephony devices in the short-to-medium term. This removes the need for users to remember how different mechanisms and secrets work in placing calls using PSTN or IP Brown Expires 30 December 2002 [Page 8] Internet-Draft ETS security June 2002 telephones - and from needing to work out which is which! In more complex devices, ETS authorisation should be integrated with existing authentication schemes to reduce unnecessary overhead in protocols and on users' memories. Fraud detection should continue to be used to detect unauthorized use of the system. In the longer term, smartcard/SIM-based authentication should become more feasible. 6. Scenarios This section examines in more detail how our recommended approach would be applied in the primary scenarios identified for ETS use [Carlberg02]. 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 as a percentage of total capacity 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, with pre-configured IKE Security Associations to reduce call setup latency. 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 traffic is likely to flow across several IP networks to its destination. At each gateway, the ingress point performs traffic policing and priority marking translation. If a network in the path to the final traffic destination does not Brown Expires 30 December 2002 [Page 9] Internet-Draft ETS security June 2002 support ETS 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 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 protocols such as SRTP and TLS. If IPSEC is used with DiffServ, 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 rely on a trusted SIP proxy within the user's ISP network, which then carries out the appropriate forwarding. More advanced routing is possible using a protocol such as Telephony Routing over IP [Rosenberg00]. The device's access network must recognise that its user is allowed ETS service to provide network-layer priority. This can be integrated into the network's login procedure: only certain users will be so authorised. The user's device may mark packets as prioritised, or the network may do so at its ingress point. To obtain priority call setup in the PSTN, the user must prove that they are authorised to receive this service to the PSTN gateway. They may do this by authenticating themselves as a user allowed this facility, either to a trusted SIP proxy in their home network or directly to the gateway. Alternatively the user may authenticate themselves to a remote PSTN gateway using the same procedure as on the PSTN: by dialling a known number and PIN. This requires either that the PSTN gateway is able to route calls to non-geographic numbers such as the 710 area code used by the US GETS system, or that it is able to provide the verification service itself. If the PSTN 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, the originating IP device should tunnel it to the IP-PSTN gateway using protocols such as TLS and SRTP. This will also allow devices on non-ETS-enabled networks to authorise themselves to an ETS- supporting IP-PSTN gateway using any of the security protocol's authentication mechanisms. Their traffic on the PSTN side of the Brown Expires 30 December 2002 [Page 10] Internet-Draft ETS security June 2002 connection can then be prioritised. 6.4 Pure IP The simplest scenario is that both end-points of an ETS call are IP devices linked by public or private internets. Again, the call originator must mark call traffic packets as prioritised. The 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- ETS-enabled network. For this reason, ETS-enabled networks may attempt to use policy-based routing to keep such traffic on ETS- capable networks. For maximum assurance of call integrity and confidentiality, there should be an end-to-end secured link between the originator and recipient of a call using protocols such as TLS and SRTP. 6.5 Roaming A roaming ETS user must first authenticate themselves to a local access network using a protocol such as the Extensible Authentication Protocol [Blunk98]. That network will verify the user's credentials with their home network using Diameter, which also needs to signal back the enhanced QoS that should be provided for the user. The access network can then allow the use of priority mechanisms at the link and network layers. As an ETS user moves between different access points in the access network, their priority should be signalled between points using the context transfer protocol being developed by the Seamoby working group. To locate a PSTN gateway suitable for a specific telephone number, an ETS user may attempt to discover a local TRIP Location Server [Rosenberg00] or use a location server on their home network. The latter option has the advantage that the user can be pointed to gateways that have a business relationship with their home network (and hence will be able to authenticate the user and charge for calls) and that support PSTN call prioritisation mechanisms. 7. Recommendations and Requirements We recommend that ETS-compliant IP networks should meet the following requirements: * ETS users should be authorised using a PIN or as part of the user profile stored by their network or remote PSTN gateway. This authorisation may be verified remotely for roaming users with AAA protocols. The authorisation of a given user must be a highly available service. Brown Expires 30 December 2002 [Page 11] Internet-Draft ETS security June 2002 * Network-layer priority mechanisms such as DiffServ may be applied to ETS traffic from authorised users. Networks must relabel ETS- marked traffic sent by unauthorised users with a standard priority marking. Priority mechanisms in link-layer protocols may also be enabled on access links for authorised users. * Inter-domain IP gateways must police prioritised traffic according to the service-level agreement between the domains. Gateways must not accept ETS-marked traffic from networks that do not police ETS priority; such traffic should be re-marked to a normal priority level. * Gateways between domains using different QoS mechanisms (such as DiffServ and Weighted Fair Queuing) must be able to translate ETS markings appropriately. * IP-to-PSTN gateways should use IEPS telephony mechanisms to provide priority call setup for calls marked as ETS by authorised users. ETS calls from unauthorised users must be treated with normal priority. * PSTN-to-IP gateways should mark sessions resulting from an IEPS telephony call as ETS-authorised and apply network-layer priority schemes to signalling and media traffic as dictated by local policy. * A gateway or proxy that verifies the authorisation of a given session to receive prioritisation should allow other intermediaries to check where possible that this verification has been done. * The confidentiality and integrity of IP traffic should be protected using a security protocol such as SRTP, TLS, H.235 or IPSEC to the maximum possible extent. In order to provide ETS support to roaming users, the following protocol additions are required: * The Diameter protocol must allow home networks to signal to a remote network that a given user is authorised for ETS priority. This may be through a specific indicator or as part of a more general approach to signalling Quality of Service levels. * The Seamoby protocol should allow priority to be included in the context transferred between access points. 8. Security Considerations This entire document is about security. Operators of ETS-capable networks must maintain the overall security of their network to prevent more general attacks upon ETS and other traffic. Brown Expires 30 December 2002 [Page 12] Internet-Draft ETS security June 2002 9. Acknowledgements Many thanks to Ken Carlberg, Martin Euchner, Hal Folts, Stu Goldman, Jack Garrity, Kimberly King, James Polk, Eric Rescorla and Gary Thom for their comments on this draft. 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 Normative References [Arkko02] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", Internet draft, February 2002. [Blake98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [Blom01] Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K., and D. Oran, "The Secure Real Time Transport Protocol", IETF work-in- progress, February 2002. [Blunk98] Blunk L. and J. Vollbrecht, "PPP Extensible Authentication Protocol", RFC 2284, March 1998. [Calhoun02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G. and J. Loughney, "Diameter Base Protocol", IETF work-in-progress, April 2002. [Carlberg02] Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP Telephony", IETF work-in-progress, April 2002. [Dierks99] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [Kent98a] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [Kent98b] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. Brown Expires 30 December 2002 [Page 13] Internet-Draft ETS security June 2002 [Handley99] Handley, M. et al, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [Harkins98] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. [ITU00b] ITU-T Recommendation X.509, "The Directory: Public-key and attribute certificate frameworks", March 2000. [Maughan98] Maughhan, D. et al, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [Peterson02] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", IETF work-in-progress, March 2002. [Rosenberg00] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony Routing over IP", RFC 2871, June 2000. [Schulzrinne96] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC 1889, January 1996. [Thayer98] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. 12 Informative References [Bellovin89] Bellovin, S.M., "Security Problems in the TCP/IP Protocol Suite," Computer Communications Review 2:19, pp. 32-48, April 1989. [Braun01] Braun, T., Ru, L. and G. Stattenberger, "An AAA Architecture Extension for Providing Differentiated Services to Mobile IP Users", 6th IEEE Symposium on Computers and Communications (ISCC 2001), Hammamet, Tunisia, July 2001. [ETSI00] ETSI TR 33.102, "3GPP security architecture", December 2000. [ITU00a] ITU-T Recommendation E.106, "Description of an International Emergency Preference Scheme (IEPS)", March 2000. [ITU01] ITU-T Draft Recommendation F.706, "International Emergency Multimedia Service", 2001 [Telcordia00] Telcordia Technologies, "Next Generation, Voice over Packet, and Hybrid Networks Security Issues", Report to National Communications System, September 2000. 13 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. Brown Expires 30 December 2002 [Page 14] Internet-Draft ETS security June 2002 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 Expires 30 December 2002 [Page 15] Brown Expires 30 December 2002 [Page 16]