ECRIT H. Schulzrinne Internet-Draft Columbia U. Expires: March 11, 2006 M. Shanmugam TUHH P. Taylor, Ed. Nortel H. Tschofenig Siemens September 7, 2005 Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. This Internet-Draft will expire on March 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document reviews the security threats to routing of emergency calls through the Internet Protocol network to Public Safety Answering Points, including a discussion of potential countermeasures Schulzrinne, et al. Expires March 11, 2006 [Page 1] Internet-Draft Threats and Req. for Emergency September 2005 and associated tradeoffs. This document places particular emphasis on threats to the successful mapping from caller location to a route to the appropriate Public Safety Answering Point. Broader issues of security of the emergency services system will be dealt with in a separate document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations of Attackers of ECRIT . . . . . . . . . . . . . . 5 4. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Integrity and Privacy Threats . . . . . . . . . . . . . . 6 4.2. Attacks on PSAP . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. DoS on PSAP . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Impersonating a PSAP . . . . . . . . . . . . . . . . . 8 4.3. Attacks on mapping server . . . . . . . . . . . . . . . . 9 4.3.1. DoS on mapping server . . . . . . . . . . . . . . . . 9 4.3.2. Impersonating a mapping server . . . . . . . . . . . . 9 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 5.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 11 5.2. Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 11 5.3. Limiting Bogus Calls . . . . . . . . . . . . . . . . . . . 12 5.4. Corrupting Database Information . . . . . . . . . . . . . 12 5.5. Distributed Directory Security . . . . . . . . . . . . . . 13 5.6. Query-Response Verification . . . . . . . . . . . . . . . 13 5.7. Asserted Location . . . . . . . . . . . . . . . . . . . . 13 6. Threat's Table . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Schulzrinne, et al. Expires March 11, 2006 [Page 2] Internet-Draft Threats and Req. for Emergency September 2005 1. Introduction Public Switched Telephone Network (PSTN) users can summon help for emergency services such as ambulance, fire and police using a well- known unique number (e.g., 911 in North America, 112 in in Europe). A key factor in the handling of such calls is the ability of the system to determine caller location and route to the appropriate Public Safety Answering Point (PSAP) based on that location. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. To achieve this, a number of protocols and protocol extensions need to interwork successfully. Since the Internet is hostile place, it is important to understand the security threats for emergency services. Otherwise, an adversary can use the infrastructure to place fraudulent calls, mount denial of service attacks, etc. However, this is a broad topic and needs to be subdivided into manageable parts. Hence the present document restricts itself to threats to the successful routing of emergency calls, especially the operation of mapping from caller location to a route to the PSAP responsible for that location. This document focuses on the security threats and security requirements for the IP-based emergency service infrastructure only without interaction with PSTN infrastructure elements. The specific issues associated with the derivation and secure delivery of caller location are dealt in the IETF GEOPRIV working group, and are out of scope of the present document. As a corollary, the present document does not distinguish between the case where location is provided by reference and the case where it is provided by value within session signalling. This document is organized as follows: Section 2 describes basic terminology, Section 3 describes some motivation of attackers in the context of ECRIT, Section 4 illustrates security threats and possible countermeasures associated with them and Section 5 lists the implied security-related requirements relating to the mapping sub-system. Schulzrinne, et al. Expires March 11, 2006 [Page 3] Internet-Draft Threats and Req. for Emergency September 2005 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 [RFC2119]. Emergency Caller, Public Safety Answering Point (PSAP), Access Infrastructure Provider, Application (Voice) Service Provider, Emergency Call Taker, Mapping server etc. is taken from [I-D.ietf- ecrit-requirements]. Additionally, we use the following terms throughout the document: Emergency Call Routing Chain (Support): This term refers to entities that route the emergency call to the appropriate PSAP based on information like location information, language, etc. If SIP is used as a protocol for session setup and call routing, for example, then this entity would correspond to a SIP proxy. Directory: This entity refers to a distributed directory protocol. DNS is one example of such as distributed directory but there are other protocols that might fulfill the requirements listed in [I-D.ietf-ecrit-requirements] for such a protocol. Mapping database: The database used by the mapping server in formulating a response to a directory query. Asserted Location Information: The term asserted location information refers to the property that the recipient of such an object is able to verify that it was generated by a particular party that is authorized todo so. Schulzrinne, et al. Expires March 11, 2006 [Page 4] Internet-Draft Threats and Req. for Emergency September 2005 3. Motivations of Attackers of ECRIT The motivation for an attacker, in the context of emergency, is to hinder user(s) not to avail the emergency service. This can be done by variety of means such as impersonating a PSAP, directory server, forging or spoofing location, identity etc., However,there are several other potential motivations that cause concern. Attackers might also wish to learn the nature emergency information by eavesdropping an emergency call in order to reuse or extract the relevant information that might cause potential problems to the end hosts such as replay attacks, revealing the identity of the user. Attackers may want to prevent or delay an emergency caller by modifying some information in the message typically modifying the loation of the caller, while placing the emergency call. In some cases, this will lead the emergency repsonders to dispatch the services to the spoofed area and might not be available to the other callers. It might also be possible for an attacker to impede the users not to reach an appropriate PSAP by corrupting or modifying the location of an end host or the information returned from the mapping protocol. Since the regulatory aspects of the emergency call often does not manadate authentication of the caller, it is easy for an attacker to forge some data(location information) to an PSAP, thereby forcing the emergency responders to dispatch the services, which might cause denial of service to its legitimate users. Finally, some attackers may simply want to halt the operation of an entire emergency architecture through denial-of-service attacks. Schulzrinne, et al. Expires March 11, 2006 [Page 5] Internet-Draft Threats and Req. for Emergency September 2005 4. Security Threats This section discusses various security threats related to emergency call handling. We distinguish between three major types of security threats (in the context of emergency calls), namely threats to the integrity and privacy of the signaling and media, attacks on PSAP and mapping relevant attacks. 4.1. Integrity and Privacy Threats Within an emergency call, the threats to the integrity and privacy of the signaling (session setup) and media transmission are similar to those for other applications and thus not discussed further. 4.2. Attacks on PSAP This section discusses various security threats related to public safety answering point. 4.2.1. DoS on PSAP In an emergency services context, denial-of-service attacks on PSAP can impact the availability of three types of resources, namely (1) PSAP network facilities, both at the network layer and for call signaling, (2) call taker resources and (3) first responders. DoS attacks on PSAP and its network facilities can be deflected using standard denial-of-service detection and mitigation techniques. Call taker resources are scarce, but other PSAPs may be able to assist with call filtering if an attack is localized. Both of these types of attacks can be automated and correspond to the more DOS attacks more typically discussed in security considerations for protocols. Denial-of-service attacks on first responders are launched by having human callers send these first responders to bogus emergencies, by providing false location or incident information. There are two cases: namely, a single attacker pretending to be in multiple locations and multiple, coordinated attackers. For the case of a single attacker, the attack can only succeed if either a single false report exhausts first-responder resources or this attacker is able to provide both a fake identity and a fake location. (If either is Schulzrinne, et al. Expires March 11, 2006 [Page 6] Internet-Draft Threats and Req. for Emergency September 2005 genuine or the same, it is relatively easy to detect and prevent such attacks.) If multiple attackers are coordinating their DoS attack on first- responder resources, they do not need to remain anonymous or provide false location information, although doing so allows such attacks to be launched from a much wider geographic area. 4.2.1.1. Countermeasures There is no single measure that is likely to prevent all denial-of- service attacks, but a combination of measures can be used to reduce the possible number of perpetrators and increase the chances that the attacker can be identified and apprehended, discouraging future attacks. We enumerate possible countermeasures and their limitations below. These countermeasures can be divided into real-time measures that allow to flag or reject calls, as well as forensic measures that increase the chances of apprehending the crank caller. It should be noted that crank emergency calls are quite possible in the existing PSTN-based system, where often location information is not available and the identity of the caller is not known. However, the attacker is generally limited in its ability to reach random PSAPs, as calls are routed based on the caller's wireline or wireless location. Thus, it is difficult for a caller to launch such attacks from afar. Turing test: Distributed denial-of-service attacks launched by botnets can be prevented by having the system require some indication of a human caller before forwarding the call to a human call taker. In practice, this may not be easy during an emergency call where callers may speak many different languages or be too scared to respond to prompts to enter or say certain information or in some cases, they might not be able to respond. IP address checking: Some types of attacks can be limited to a single instance per attacker by tracing the signaling request of the caller. This may well be effective in preventing some kinds of DDOS attacks as well as the attempt of a single attacker to place multiple emergency calls in succession. This remedy may be limited if the attacker is able to "launder" signaling or media packets through a variety of intermediaries. IP address tracing may also be helpful in apprehending a malcreant later. Thus, signaling protocols should try to capture as much of the request history, including the source of the mapping request, as possible. Schulzrinne, et al. Expires March 11, 2006 [Page 7] Internet-Draft Threats and Req. for Emergency September 2005 IP address mapping: In some cases, the IP address of the caller, captured in SIP Via headers or the source address of RTP packets, can be used to roughly determine the geographic location of the caller [RFC1876], using IP geomapping techniques. This may provide hints that the geographic location reported may be suspicious, but VPNs and other tunneling mechanisms do not allow to make an absolute determination. Verified application service provider: Identifying the application service provider may provide clues to the PSAP as to whether the call might merit additional scrutiny. Verified identity: If the identity of the caller can be verified in some way, it becomes more difficult for a single attacker to place a series of emergency calls. For this, it is not necessary that the identity be tied to a real person, just that it is difficult to rapidly mint new identities or if the (authenticated) identity can be traced back to a real-world person. Verified location: In some cases, a trusted third party may be able to ascertain the location of the caller, but care has to be taken that the identity and the location are indeed closely coupled. In many systems, even a signed identity can be used by a third party. Having the location provider cryptographically tie the location object to a network address may make it more difficult to succeed in a cut-and-paste attack. In some cases, PSAPs under attack will only be able to make probabilistic judgements as to which calls are more likely to be fraudulent and may use such indications to, for example, query the caller more closely for incident details. 4.2.2. Impersonating a PSAP An adversary might pretend to operate a PSAP. When either an end host or an intermediate device wants to determine the PSAP that is responsible for a particular geographical area by sending a query to the directory an adversary might return a faked response. Returning an incorrect response message does not require the adversary to be somewhere along the path. It is sufficient for an adversary to be located in a broadcast medium and the adversary has to reply as soon as a query is observed (if no security protection is utilized). If the response indicates a legitimate but inappropriate (i.e., a PSAP that is authoritive for a different geographical area) then the emergency call interaction will be able to continue but will suffer from delays until the emergency call can be forwarded to the correct PSAP, potentially involving human interaction (by the Emergency Call Taker). Schulzrinne, et al. Expires March 11, 2006 [Page 8] Internet-Draft Threats and Req. for Emergency September 2005 4.3. Attacks on mapping server This section discusses various security threats related to directory protocols. 4.3.1. DoS on mapping server An adversary might mount a DoS/DDoS attack against one or multiple mapping server to prevent an emergency caller from obtaining emergency service contact URIs. 4.3.1.1. Countermeasures Generic DoS attacks, such as SYN flooding, can be handled by using best current practices and hence it is not discussed here. To avoid launching DoS, the mapping server should be capable of limiting the queries from a single IP, especially when an anonymous mapping is requested, at a particular time. This limit should consider the proxy case. It may also log the relevant information like IP address, query information from the requests in order to indicate the query flooding. Dealing with all sorts of denial of service attacks against the emergency infrastructure and at directory servers is difficult. Protection needs to be provided at different protocol layers and also at different locations in the network. Additionally, it is essential to ensure that directory queries submitted by adversary towards the directory server do not cause a major performance impact for the server with the consequence that potentially genuine requests may need to be rejected due to overload and a timely response is not possible. 4.3.2. Impersonating a mapping server An adversary might run a faked mapping server aiming to pretend that it is a legitimate server. This would lead an emergency caller to get bogus URI(s) that hinder a caller not to avail the emergency service. It is necessary for the client to authenticate and possibly to authorize the mapping server as part of the emergency call procedure. 4.3.2.1. Countermeasures In order to provide authentication of the mapping server to the client, the following methods can be used: Schulzrinne, et al. Expires March 11, 2006 [Page 9] Internet-Draft Threats and Req. for Emergency September 2005 Channel Security: It is possible to establish a secure channel e.g., TLS to ensure the authenticity of the given mapped information. Additionally, there are several advantages in establishing a secure channel such as confidentiality protection, replay protection and in case if the mapping server realizes that it is under flooding attack (query) it might also request the certificate, if available, to verify the identity of the requesting client. Consequently, this step might decrease the performance of the mapping service since the certificate processing and key exchange mechanism pose serious performance degradation for the mapping server. Object Security: It is possible to use object security e.g., S/MIME to sign the individual information in the query/response message of the mapping service. This mechanism with various settings also provides authentication, a degree of confidentiality protection of the sender and prevents from the replay attacks. Assuming that there is no prior relationship between the emergency caller and the mapping server (in the worst case) public key based authentication seems to be the best choice. Additional approaches for bootstrapping the security associations by exploiting existing relationships (such as between the network access infrastructure provider and an directory server) might simplify the key management. The authorization can be provided using certificates and this aspect left for further study. Schulzrinne, et al. Expires March 11, 2006 [Page 10] Internet-Draft Threats and Req. for Emergency September 2005 5. Security Requirements Compiling security requirements to address the threats listed in the previous section might is impacted by several constraints: Security mechanisms may lead to a certain performance overhead (e.g., several roundtrips). A certain security infrastructure is required that might lead to deployment problems. For example, end user certificates, certificates for networks, usage of authorization certificate, etc. might need to be deployed before any of these mechanisms are useful. Many of these aspects are related to regulatory and legal requirements that may vary from country to country. Typically, these mechanisms cannot be mandated by an IETF specification. Some of the requirements impose solutions that are out-of-scope of this working group. Given the above-listed constraints the requirements that have to be addressed by work that is done within ECRIT have to be highlighted. Other requirements have to be read as 'if you would like to address this threat, then you might want to consider this requirement' rather than 'any solution must address fulfill this requirement'. 5.1. Denial of Service Attacks Care must be taken when desigining an architecture in order to reduce chance for a denial of service attack. Also, it is important to understand that the ability to mount DoS attacks must also be considered as part of the architecture work when legal and regulatory requirements are known and need to be fulfilled. 5.2. Impersonating a PSAP The Emergency Caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls and disrupts the emergency infrastructure. o Countermeasure: A user agent MUST be able to authenticate a PSAP. Unlike in the PSTN case IP based networks provide a better opportunity to spoof a PSAP since physical access to the cable plant is required in the PSTN case, while this may not true for the IP Schulzrinne, et al. Expires March 11, 2006 [Page 11] Internet-Draft Threats and Req. for Emergency September 2005 case. 5.3. Limiting Bogus Calls In order to discourage bogus calls to the PSAP, authentication of caller could be helpful. To provision the authentication of the caller , Network Access Authentication could be useful since it will provide a certain degree of authentication. But the emergency architecture itself does not mandate any authentication for the emergency call. The reason for this is that the authentication procedure may introduce delays that might break the integrity of the emergency call procedure, since the emergency call is a time sensitive operation or the caller may do not have permissions in the visited network or he might be in panic at that time. So it will be helpful to consider the options like attaching the certificate of the caller, device that will be helpful in the procedure to trace back the caller. This certificate could be a VSP, ISP or a device certificate (pay phone) which can be exclusively used to find bogus callers and prosecute them later. This verification could be done after the failure of emergency dispatching procedure and we can use this information for house-keeping and also to avoid future attacks. 5.4. Corrupting Database Information If the mapping client i.e., the entity that requests location information using a mapping protocol accepts the emergency contact information from an unauthenticated mapping server i.e., the entity that provides location information, it is highly possible to receive bogus or prank emergency contact URIs. Particularly the caching properties of a distributed directory might be exploited. To ensure the secure retrieval of information, the following properties are assumed: o The maping client MUST be able to authenticate the mapping server. o The interaction between the mapping client and the mapping server MUST be integrity and replay protected. o The mapping server MUST be provide data origin authentication thereby ensuring that the provided data items are indeed from the claimed source. o The mapping server SHOULD provide information to ensure that it is authoritive for the provided information. Schulzrinne, et al. Expires March 11, 2006 [Page 12] Internet-Draft Threats and Req. for Emergency September 2005 5.5. Distributed Directory Security To fasten the location to URI look up mechanism, the mapping service might cache relevant information from other mapping servers. In this case, the mapping server which caches information SHOULD make sure that the information provided by the remote mapping server is authoritative i.e., provided by the owner(server) of that region and it is authorized to do so. Also, the database must be periodically synchronized with the original copy in order to provision the freshness of the information. Any synchronization or update in the caching database must be secure and it is left to the best current practice methods. 5.6. Query-Response Verification The peer which issues the mapping request must verify the authenticity of the data. When the query is issued on behalf of the mapping client then the mapping server must take necessary steps to determine conclusively that the data came from a genuine mapping server or an authoritative mapping server (remote). If the query procedure is done by the client then the client must authenticate both the home mapping server and remote mapping servers before accepting the response information. Also the data sender must prove the freshness of the given information in order to avoid cut-and-paste attacks, this type of attacks can be mitigated by using time stamps. 5.7. Asserted Location location validation ensures that an address exists and is mappable to a PSAP. A valid address, however, does not imply that the call actually originated from that location. We refer to location verification as the assurance that the call was placed at the location claimed, including any error margins provided. Verifying location is generally more difficult than location validation as there is currently no generally trusted service that can vouch for the location of the caller. In some cases, AIPs or ISPs may be able to indicate the location of the caller with high confidence and they may possess cryptographic certificates that are trusted by the PSAP. This may not require a global certification authority (CA), as a regional PSAP typically only deals with a modest number of larger enterprises and thus could obtain their public keys even if self-signed. Schulzrinne, et al. Expires March 11, 2006 [Page 13] Internet-Draft Threats and Req. for Emergency September 2005 However, even if the AIP or ISP provides a signed location, it is difficult to ensure that such a signed location object is only used for calls from that location, as it will have to be copied from a location delivery protocol to the call signaling protocol. For example, a third party could obtain such a signed location object and use it elsewhere. Naturally, timestamps will restrict such useage to the order of minutes or hours, depending on how often location information is updated. A PSAP may want to be able to answer the following questions: o Who originally provided this particular location information? o Did the call originate from that particular geospatial or civic address and who says so and how do they know? Schulzrinne, et al. Expires March 11, 2006 [Page 14] Internet-Draft Threats and Req. for Emergency September 2005 6. Threat's Table This section provides a matrix/table or tree which is helpful to capture the basic list of threats and data items. [Editor's Note: Further work is needed here.] single user threats vs. large-scale threats real-time vs. after-the-fact items that can be used for identification (spatial, network, identity, carrier) 1. Single-target threats a. Attacker wishes to prevent the emergency caller from reaching help. i. DOS attack against emergency caller's access link. ii. DOS attack against entity in the emergency call routing chain. iii. Impersonation of entity in the emergency call routing chain. iv. DOS attack against the mapping responder. v. Impersonation of the mapping responder. vi. Corruption of the mapping database. vii. DOS attack against the PSAP. viii.Impersonation of the PSAP. b. Attacker wishes to cause malicious dispatch of emergency resources to a target individual. i. Impersonation of target individual. ii. Replay of valid signalling, possibly with modification to point to target. c. Attacker wishes to capture information about an emergency, to the attacker's profit (e.g., "ambulance chaser") or to use against the emergency caller. i. Disclosure of signalling information. ii. Disclosure of session content. 2. Mass-target threats a. Attacker wishes to deny service to a particular large-scale emergency. i. DOS attack against entity in the emergency call routing chain. Schulzrinne, et al. Expires March 11, 2006 [Page 15] Internet-Draft Threats and Req. for Emergency September 2005 ii. Impersonation of entity in the emergency call routing chain. iii. DOS attack against the mapping responder. iv. Impersonation of the mapping responder. v. Corruption of the mapping database. vi. DOS attack against the PSAP. vii. Impersonation of the PSAP. (a). Real-time Information used to identify the emergency caller i. Network Access (user) Identity, (Device identity, e.g., if the user places the call by his PDA in a 3G environment) ii. Identify using IP addresses based on the region. (e.g., calls from france may not be attended in germany) (b). Off-line Information used to identify the emergency caller i. Certificate of the Voice Service provider ii. Certificate of the Internet Service Provider iii. Identity of the Access network iv. Logging the signaling path to trace back the caller v. Logging the call information (such as location, IP etc.,) Schulzrinne, et al. Expires March 11, 2006 [Page 16] Internet-Draft Threats and Req. for Emergency September 2005 7. Security Considerations This document addresses security threats and security requirements. Therefore, security is considered throughout this document. Schulzrinne, et al. Expires March 11, 2006 [Page 17] Internet-Draft Threats and Req. for Emergency September 2005 8. IANA Considerations This document does not require actions by the IANA. Schulzrinne, et al. Expires March 11, 2006 [Page 18] Internet-Draft Threats and Req. for Emergency September 2005 9. References 9.1. Normative References [I-D.ietf-ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", May 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 9.2. Informative References [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", January 1996. Schulzrinne, et al. Expires March 11, 2006 [Page 19] Internet-Draft Threats and Req. for Emergency September 2005 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Murugaraj Shanmugam Technische Universitaet Hamburg-Harburg Department of Security in Distributed applications Harburger Schlossstrasse 20 Hamburg-Harburg 21079 Germany Email: murugaraj.shanmugam@tuhh.de Tom Taylor (editor) Nortel 1852 Lorraine Ave. Ottawa, Ontario K1H 6Z8 Canada Email: taylor@nortel.com Hannes Tschofenig Siemens otto-Hahn ring 6 Munich, Bayern 81739 Germany Email: hannes.tschofenig@siemens.com Schulzrinne, et al. Expires March 11, 2006 [Page 20] Internet-Draft Threats and Req. for Emergency September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Expires March 11, 2006 [Page 21]