draft-ietf-ecrit-security-threats-00.txt | draft-ietf-ecrit-security-threats-01.txt | |||
---|---|---|---|---|
ECRIT T. Taylor | ECRIT T. Taylor | |||
Internet-Draft (Editor) Nortel | Internet-Draft (Editor) Nortel | |||
Expires: September 21, 2006 H. Tschofenig | Expires: October 19, 2006 H. Tschofenig | |||
Siemens | Siemens | |||
H. Schulzrinne | H. Schulzrinne | |||
Columbia U. | Columbia U. | |||
M. Shanmugam | M. Shanmugam | |||
Siemens | Siemens | |||
March 20, 2006 | April 17, 2006 | |||
Security Threats and Requirements for Emergency Call Marking and Mapping | Security Threats and Requirements for Emergency Call Marking and Mapping | |||
draft-ietf-ecrit-security-threats-00.txt | draft-ietf-ecrit-security-threats-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on September 21, 2006. | This Internet-Draft will expire on October 19, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document reviews the security threats associated with the two | This document reviews the security threats associated with the two | |||
current work items of the ECRIT Working Group. The first is the | current work items of the ECRIT Working Group. The first is the | |||
marking of signalling messages to indicate that they are related to | marking of signalling messages to indicate that they are related to | |||
skipping to change at page 2, line 21 | skipping to change at page 2, line 21 | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Marking, mapping, and the emergency call routing process . . . 5 | 3. Marking, mapping, and the emergency call routing process . . . 5 | |||
4. Objectives of attackers . . . . . . . . . . . . . . . . . . . 6 | 4. Objectives of attackers . . . . . . . . . . . . . . . . . . . 6 | |||
5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.1. Attacks involving the emergency identifier . . . . . . . . 7 | 5.1. Attacks involving the emergency identifier . . . . . . . . 7 | |||
5.2. Attacks against or using the mapping process . . . . . . . 7 | 5.2. Attacks against or using the mapping process . . . . . . . 7 | |||
5.2.1. Attacks against the emergency response system . . . . 7 | 5.2.1. Attacks against the emergency response system . . . . 8 | |||
5.2.2. Attacks to prevent a specific individual from | 5.2.2. Attacks to prevent a specific individual from | |||
receiving aid . . . . . . . . . . . . . . . . . . . . 9 | receiving aid . . . . . . . . . . . . . . . . . . . . 9 | |||
5.2.3. Attacks to gain information about an emergency . . . . 9 | 5.2.3. Attacks to gain information about an emergency . . . . 9 | |||
6. Security requirements relating to ECRIT work items . . . . . . 11 | 6. Security requirements relating to ECRIT work items . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 | |||
skipping to change at page 5, line 36 | skipping to change at page 5, line 36 | |||
client to pass location information to the mapping server and to | client to pass location information to the mapping server and to | |||
receive back a URI which can be used to direct call signalling to a | receive back a URI which can be used to direct call signalling to a | |||
PSAP. | PSAP. | |||
Since mapping requires location information for input, when and where | Since mapping requires location information for input, when and where | |||
the location information is acquired imposes constraints upon when | the location information is acquired imposes constraints upon when | |||
mapping can be done and which devices can act as mapping clients. | mapping can be done and which devices can act as mapping clients. | |||
The key distinction in "when" is before the emergency or during the | The key distinction in "when" is before the emergency or during the | |||
emergency. The key distinction in "where" is at the emergency | emergency. The key distinction in "where" is at the emergency | |||
caller's device or at another device in the signalling path between | caller's device or at another device in the signalling path between | |||
the emergency caller and the PSAP. The device that acquires the | the emergency caller and the PSAP. The mapping client can be the | |||
location information can be the mapping client, and so can any device | device that acquires the location information or any device | |||
downstream of that point. It is even possible for a PSAP itself to | downstream of that point. It is even possible for a PSAP itself to | |||
initiate mapping, to determine whether an arriving call should be | initiate mapping, to determine whether an arriving call should be | |||
handled by a call taker at that PSAP or should be proxied to another | handled by a call taker at that PSAP or should be proxied to another | |||
PSAP. | PSAP. | |||
4. Objectives of attackers | 4. Objectives of attackers | |||
Attackers may direct their efforts either against a portion of the | Attackers may direct their efforts either against a portion of the | |||
emergency response system or against an individual. Attacks against | emergency response system or against an individual. Attacks against | |||
the emergency response system have three possible objectives: | the emergency response system have three possible objectives: | |||
o to deny system services to all users in a given area. The | o to deny system services to all users in a given area. The | |||
motivation may range from thoughtless vandalism, to wide-scale | motivation may range from thoughtless vandalism, to wide-scale | |||
criminality, to terrorism. One interesting variant on this | criminality, to terrorism. One interesting variant on this | |||
motivation is the case where a victim of a large emergency hopes | motivation is the case where a victim of a large emergency hopes | |||
to gain faster service by blocking others' competing calls for | to gain faster service by blocking others' competing calls for | |||
help. | help. | |||
o attacks by the caller to gain fraudulent use of services, by using | o to gain fraudulent use of services, by using an emergency | |||
an emergency identifier to bypass normal authentication, | identifier to bypass normal authentication, authorization, and | |||
authorization, and accounting procedures. | accounting procedures. | |||
o to divert emergency responders to non-emergency sites. No attacks | o to divert emergency responders to non-emergency sites. No attacks | |||
affecting the ECRIT Working Group's decisions on the emergency | affecting the ECRIT Working Group's decisions on the emergency | |||
identifier and mapping protocol have been identified that achieve | identifier and mapping protocol have been identified that achieve | |||
this objective | this objective | |||
Attacks against an individual fall into two classes: | Attacks against an individual fall into two classes: | |||
o attacks to prevent an individual from receiving aid; | o attacks to prevent an individual from receiving aid; | |||
skipping to change at page 7, line 31 | skipping to change at page 7, line 31 | |||
it without applying normal procedures for authentication and | it without applying normal procedures for authentication and | |||
authorization because the signalling carries the emergency | authorization because the signalling carries the emergency | |||
identifier. | identifier. | |||
d. The service provider routes it according to the called address | d. The service provider routes it according to the called address | |||
(e.g., SIP Request-URI), without verifying that this is the | (e.g., SIP Request-URI), without verifying that this is the | |||
address of a PSAP (noting that a URI by itself does not indicate | address of a PSAP (noting that a URI by itself does not indicate | |||
the nature of the entity it is pointing to). | the nature of the entity it is pointing to). | |||
If these conditions are satisfied, the attacker can bypass normal | If these conditions are satisfied, the attacker can bypass normal | |||
ASP/VSP authorization procedures for arbitrary destinations, simply | service provider authorization procedures for arbitrary destinations, | |||
by reprogramming the emergency caller's device to add the emergency | simply by reprogramming the emergency caller's device to add the | |||
identifier to non-emergency call signalling. Most probably in this | emergency identifier to non-emergency call signalling. Most probably | |||
case, the call signalling will not include any location information. | in this case, the call signalling will not include any location | |||
information. | ||||
An attacker wishing to disrupt the emergency call routing system may | An attacker wishing to disrupt the emergency call routing system may | |||
use a similar technique to target components of that system for a | use a similar technique to target components of that system for a | |||
denial of service attack. The attacker will find this attractive to | denial of service attack. The attacker will find this attractive to | |||
reach components that handle emergency calls only. Flooding attacks | reach components that handle emergency calls only. Flooding attacks | |||
are the most likely application of the technique, but it may also be | are the most likely application of the technique, but it may also be | |||
used to identify target components for other attacks by analyzing the | used to identify target components for other attacks by analyzing the | |||
content of responses to the original signalling messages. | content of responses to the original signalling messages. | |||
5.2. Attacks against or using the mapping process | 5.2. Attacks against or using the mapping process | |||
skipping to change at page 8, line 16 | skipping to change at page 8, line 20 | |||
increase the probability that emergency calls are routed to the wrong | increase the probability that emergency calls are routed to the wrong | |||
PSAP. This has a double consequence: emergency response to the | PSAP. This has a double consequence: emergency response to the | |||
affected calls is delayed, and PSAP call taker resources outside the | affected calls is delayed, and PSAP call taker resources outside the | |||
immediate area of the emergency are consumed due to the extra effort | immediate area of the emergency are consumed due to the extra effort | |||
required to redirect the calls. Alternatively, attacks that cause | required to redirect the calls. Alternatively, attacks that cause | |||
the client to receive a URI that does not lead to a PSAP have the | the client to receive a URI that does not lead to a PSAP have the | |||
immediate effect of causing emergency calls to fail. | immediate effect of causing emergency calls to fail. | |||
Three basic attacks on the mapping process can be identified: denial | Three basic attacks on the mapping process can be identified: denial | |||
of service, impersonation of the mapping server, or corruption of the | of service, impersonation of the mapping server, or corruption of the | |||
mapping database. Denial of service in turn can be achieved in | mapping database. Denial of service can be achieved in several ways: | |||
several ways: | ||||
o by a flooding attack on the mapping server; | o by a flooding attack on the mapping server; | |||
o by taking control of the mapping server and either preventing it | o by taking control of the mapping server and either preventing it | |||
from responding or causing it send incorrect responses; or | from responding or causing it to send incorrect responses; or | |||
o by taking control of a router through which the mapping queries | o by taking control of a router through which the mapping queries | |||
and responses pass and using that control to block them. An | and responses pass and using that control to block them. An | |||
adversary may also attempt to modify the mapping protocol | adversary may also attempt to modify the mapping protocol | |||
signaling messages. Additionally, it might be possible to replay | signaling messages. Additionally, the adversary may be able to | |||
past communication exchanges to fool an emergency caller by | replay past communication exchanges to fool an emergency caller by | |||
returning incorrect results. | returning incorrect results. | |||
In an impersonation attack, the attacker induces the mapping client | In an impersonation attack, the attacker induces the mapping client | |||
to direct its queries to a host under the attacker's control rather | to direct its queries to a host under the attacker's control rather | |||
than the real mapping server. Impersonation itself is an issue for | than the real mapping server. Impersonation itself is an issue for | |||
mapping server discovery rather than for the mapping protocol | mapping server discovery rather than for the mapping protocol | |||
directly. However, the mapping protocol may help to protect against | directly. However, the mapping protocol may help to protect against | |||
acceptance of responses from an impersonating entity. | acceptance of responses from an impersonating entity. | |||
Corruption of the mapping database cannot be mitigated directly by | Corruption of the mapping database cannot be mitigated directly by | |||
skipping to change at page 10, line 4 | skipping to change at page 10, line 6 | |||
The primary information that interceptions of mapping requests and | The primary information that interceptions of mapping requests and | |||
responses will reveal are a location, a URI identifying a PSAP, and | responses will reveal are a location, a URI identifying a PSAP, and | |||
the addresses of the mapping client and server. The location | the addresses of the mapping client and server. The location | |||
information can be directly useful to an attacker if the attacker has | information can be directly useful to an attacker if the attacker has | |||
high assurance that the observed query is related to an emergency | high assurance that the observed query is related to an emergency | |||
involving the target. The other pieces of information may provide | involving the target. The other pieces of information may provide | |||
the basis for further attacks on emergency call routing, but because | the basis for further attacks on emergency call routing, but because | |||
of the time factor, are unlikely to be applicable to the routing of | of the time factor, are unlikely to be applicable to the routing of | |||
the current call. However, if the mapping client is the emergency | the current call. However, if the mapping client is the emergency | |||
caller's device, the attacker may gain information that allows for | caller's device, the attacker may gain information that allows for | |||
interference with the call after it has been set up or interception | interference with the call after it has been set up or for | |||
of the media stream between the caller and the PSAP. | interception of the media stream between the caller and the PSAP. | |||
6. Security requirements relating to ECRIT work items | 6. Security requirements relating to ECRIT work items | |||
This section describes the security requirements which must be | This section describes the security requirements which must be | |||
fulfilled to prevent or reduce the effectiveness of the attacks | fulfilled to prevent or reduce the effectiveness of the attacks | |||
described in Section 5. The requirements are presented in the same | described in Section 5. The requirements are presented in the same | |||
order as the attacks. | order as the attacks. | |||
From Section 5.1: | From Section 5.1: | |||
Attack: fraudulent calls. | Attack: fraudulent calls. | |||
Requirement: for calls which meet conditions a-c of Section 5.1, the | Requirement: for calls which meet conditions a) to c) of Section 5.1, | |||
ASP/VSP call routing entity MUST verify that the destination address | the service provider's call routing entity MUST verify that the | |||
(e.g., SIP Request-URI) presented in the call signalling is that of a | destination address (e.g., SIP Request-URI) presented in the call | |||
PSAP. | signalling is that of a PSAP. | |||
Attack: use of emergency identifier to probe in order to identify | Attack: use of emergency identifier to probe in order to identify | |||
emergency call routing entities. | emergency call routing entities. | |||
Requirement: topology hiding SHOULD be applied to call signalling | Requirement: topology hiding SHOULD be applied to call signalling | |||
returned to the emergency caller, so that the identity of | returned to the emergency caller, so that the identity of | |||
intermediate routing entities is not disclosed. The obvious | intermediate routing entities is not disclosed. The obvious | |||
exception is where these entities are already visible to the caller. | exception is where these entities are already visible to the caller. | |||
Note that there is little point in hiding the PSAP itself. | Note that there is little point in hiding the PSAP itself. | |||
skipping to change at page 11, line 45 | skipping to change at page 11, line 45 | |||
Requirement: The mapping protocol MUST NOT create new opportunities | Requirement: The mapping protocol MUST NOT create new opportunities | |||
for flooding attacks, including amplification attacks. | for flooding attacks, including amplification attacks. | |||
Attack: insertion of interfering messages. | Attack: insertion of interfering messages. | |||
Requirement: The protocol MUST permit the mapping client to verify | Requirement: The protocol MUST permit the mapping client to verify | |||
that the response it receives is responding to the query it sent out. | that the response it receives is responding to the query it sent out. | |||
Attack: man-in-the-middle alteration of messages. | Attack: man-in-the-middle alteration of messages. | |||
Requirement: The protocol MUST maintain request and response | Requirement: The protocol or the system within which it is | |||
integrity. | implemented MUST maintain request and response integrity. | |||
Attack: impersonation of the mapping server. | Attack: impersonation of the mapping server. | |||
Requirement: the security considerations for any discussion of | Requirement: the security considerations for any discussion of | |||
mapping server discovery MUST address measures to prevent | mapping server discovery MUST address measures to prevent | |||
impersonation of the mapping server. | impersonation of the mapping server. | |||
Requirement: the protocol MUST permit the mapping client to | Requirement: the protocol or the system within which it is | |||
authenticate the source of mapping responses. | implemented MUST permit the mapping client to authenticate the source | |||
of mapping responses. | ||||
Attack: corruption of the mapping database. | Attack: corruption of the mapping database. | |||
Requirement: the security considerations for the mapping protocol | Requirement: the security considerations for the mapping protocol | |||
MUST address measures to prevent database corruption by an attacker. | MUST address measures to prevent database corruption by an attacker. | |||
Requirement: to provide an audit trail, the protocol SHOULD allow the | Requirement: to provide an audit trail, the protocol SHOULD allow the | |||
inclusion of an identifier in its response that indicates which | inclusion of an identifier in its response that indicates which | |||
database records were used in preparing the response. This | database records were used in preparing the response. This | |||
identifier SHOULD be encrypted along with randomizing information | identifier SHOULD be encrypted along with randomizing information | |||
such as date/time, to minimize the information provided to an | such as date/time, to minimize the information provided to an | |||
attacker in mapping responses. | attacker in mapping responses. | |||
From Section 5.2.2: no new requirements. | From Section 5.2.2: no new requirements. | |||
From Section 5.2.3: | From Section 5.2.3: | |||
Attack: snooping of location and other information. | Attack: snooping of location and other information. | |||
Requirement: the protocol MUST maintain confidentiality of the | Requirement: the protocol or the system within which it is | |||
request and response. | implemented MUST maintain confidentiality of the request and | |||
response. | ||||
7. Security Considerations | 7. Security Considerations | |||
This document addresses security threats and security requirements. | This document addresses security threats and security requirements. | |||
Therefore, security is considered throughout this document. | Therefore, security is considered throughout this document. | |||
8. Acknowledgements | 8. Acknowledgements | |||
The writing of this document has been a task made difficult by the | The writing of this document has been a task made difficult by the | |||
temptation to consider the security concerns of the entire personal | temptation to consider the security concerns of the entire personal | |||
skipping to change at page 16, line 20 | skipping to change at page 16, line 20 | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and | [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and | |||
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. | J. Polk, "Geopriv Requirements", RFC 3693, February 2004. | |||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ecrit-requirements] | [I-D.ecrit-requirements] | |||
Schulzrinne, H. and R. Marshall, "Requirements for | Schulzrinne, H. and R. Marshall, "Requirements for | |||
Emergency Context Resolution with Internet Technologies", | Emergency Context Resolution with Internet Technologies", | |||
February 2006. | March 2006. | |||
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC | [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC | |||
Text on Security Considerations", BCP 72, RFC 3552, | Text on Security Considerations", BCP 72, RFC 3552, | |||
July 2003. | July 2003. | |||
Authors' Addresses | Authors' Addresses | |||
Tom Taylor | Tom Taylor | |||
Nortel | Nortel | |||
1852 Lorraine Ave | 1852 Lorraine Ave | |||
End of changes. 17 change blocks. | ||||
32 lines changed or deleted | 34 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |