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]