P2PSIP Working Group M. Matuszewski
Internet-Draft J-E. Ekberg
Intended status: Informational P. Laitinen
Expires: August 30, 2007 Nokia
February 26, 2007
Security requirements in P2PSIP
draft-matuszewski-p2psip-security-requirements-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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Matuszewski, et al. Expires August 30, 2007 [Page 1]
Internet-Draft Security threats in P2PSIP February 2007
Abstract
This document is an analysis of security threats in the Peer-to-Peer
SIP reference model proposed in the P2PSIP concepts and terminology
for P2PSIP document. Typical security ontology is used as
classification for the threats. The main security goals for the
architecture and its components are presented.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. A P2PSIP system . . . . . . . . . . . . . . . . . . . . . 4
3. Goals related to security . . . . . . . . . . . . . . . . . . 6
3.1. End user requirements . . . . . . . . . . . . . . . . . . 6
3.2. System requirements . . . . . . . . . . . . . . . . . . . 6
3.2.1. Data access . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. End user enrollment . . . . . . . . . . . . . . . . . 6
3.2.3. Detection and rejection of badly behaving nodes . . . 7
3.2.4. Dependence of reachability of a centralized server . . 7
3.2.5. Preference of existing security mechanisms . . . . . . 7
3.3. Summary of the system requirements . . . . . . . . . . . . 7
4. Security threats . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Message Insertion, Modification, Deletion . . . . . . . . 9
4.3. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . 9
4.4. Offline Cryptographic Attacks . . . . . . . . . . . . . . 9
4.5. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 9
4.6. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 10
4.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
4.8. Communication security threats . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Matuszewski, et al. Expires August 30, 2007 [Page 2]
Internet-Draft Security threats in P2PSIP February 2007
1. Introduction
The scope of this document is to list security threats concerning
P2PSIP overlay architecture as described in the Concepts and
Terminology for Peer to Peer SIP document [1]. This document does
not intend to propose solutions to overcome security threats, but it
is more intended to list the threats that must be addressed in
forthcoming P2PSIP specifications.
Matuszewski, et al. Expires August 30, 2007 [Page 3]
Internet-Draft Security threats in P2PSIP February 2007
2. Definitions
This section defines a number of concepts that are key to understand
the rest of the document.
2.1. General
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 RFC 2119 [2].
2.2. A P2PSIP system
A P2PSIP system consists of a P2PSIP overlay as defined in and an
enrolment server that issues unique identities and credentials and
may provide an initial set of bootstrap nodes [1].
Matuszewski, et al. Expires August 30, 2007 [Page 4]
Internet-Draft Security threats in P2PSIP February 2007
--->PSTN
+------+ N +------+ +---------+ /
| | A | | | Gateway |-/
| UA |####T#####| UA |#####| Peer |########
| Peer | N | Peer | | G | # P2PSIP
| E | A | F | +---------+ # Client
| | T | | # Protocol
+------+ N +------+ # |
# A # |
NATNATNATNAT # |
# # | \__/
NATNATNATNAT +-------+ v / \
# N | |=====/ UA \
+------+ A P2PSIP Overlay | | /Client\
| | T | Peer | |___C__|
| UA | N Route Data | Q | ^
| Peer | A +-------+ |
| D | T P2PSIP Peer Protocol # |
| | N # |
+------+ A # |
# T # |
# N +-------+ +-------+ # |
# A | | | | # |
#########T####| Proxy |########| Redir |####### |
N | Peer | | Peer |<----------\ |
A | P | | R | v v
T +-------+ +-------+ +-----------+
# Enrolment #
# Server #
\__/ <------------------------------> # #
/\ ^ +-----------+
/ \ |
/ UA \ |
/______\ Enrolment protocol
SIP UA A
A P2PSIP system
Matuszewski, et al. Expires August 30, 2007 [Page 5]
Internet-Draft Security threats in P2PSIP February 2007
3. Goals related to security
This section describes goals related to the security of the P2PSIP
system.
3.1. End user requirements
The end user expectations can be put very simply. The user wants
available and reliable service that enables him to interact with
other end users and resources in a secure way. This means that the
P2PSIP System MUST provide:
o lookup and discovery of end users and resources that is secure and
reliable,
o certainty of end user identity,
o confidentiality and integrity of end-to-end multimedia
communication,
o easy and secure enrolment of end users to the P2PSIP system.
3.2. System requirements
In order for a P2PSIP system to function properly and that the end
user gets a proper service, there are several aspects that the P2PSIP
system must take in to account.
3.2.1. Data access
First and foremost, the data stored in the P2PSIP system must be
authentic, i.e., only authorized users are able to insert and modify
their the P2PSIP resource (user) records in the P2PSIP system.
However, this should be specified in such a way that it does not
impose new unnecessary requirements on the base P2P algorithm (e.g.,
DHT implementations).
3.2.2. End user enrollment
The ease for end users to enroll to a P2PSIP system should be ensured
as said in the section 4.1. The enrollment process defines the set
of end users and resources that may participate in a P2PSIP system.
This process is defined by the P2PSIP system, and the policy who can
participate to is done during this process. For example, whether end
users are charged for the usage of the P2PSIP system, and how often
they must re-new their subscription to the P2PSIP system.
Matuszewski, et al. Expires August 30, 2007 [Page 6]
Internet-Draft Security threats in P2PSIP February 2007
Although the end user probably is the entity that enrolls to the
P2PSIP system, the credentials that are the result of the enrollment
are used to grant a device / devices the right to function as a peer,
client or any other operative function possible in the system. Thus
the security of enrollment also translates to the security of the
device itself where the credentials are stored, and threats related
to device security in general.
3.2.3. Detection and rejection of badly behaving nodes
Finally, it should be possible to detect malfunctioning and badly
behaving nodes in a P2PSIP system. As the policy taken by the P2PSIP
system operator/community may be very liberal, any end user can
obtain the right to be a user of a P2PSIP system. It may be that
some end users behave badly intentionally in which case it should be
possible to identify those end users, and exclude or reject them from
the P2PSIP system.
3.2.4. Dependence of reachability of a centralized server
Also, considering the nature of P2P in general, the dependence of
reachability of a centralized server should be minimized. Naturally
there may be unavoidable situations such as the enrollment process,
where this is not possible. However, the normal functioning of
connecting to as well as inserting, modifying, retrieving of P2PSIP
resource (user) records from the P2PSIP system should not be depend
on the reachability of a global server.
3.2.5. Preference of existing security mechanisms
Although P2PSIP defines a new architecture, and thereby new
interfaces and protocols, for security there are several standardized
solutions for access control and communication security. Using
established protocols minimizes potential security loopholes that
need to be patched later, and implementation is eased if chosen
security protocols already are widely implemented and used.
3.3. Summary of the system requirements
System expectations related to security issues are summarized below:
o Authenticity and integrity of the data stored in P2PSIP system
MUST be assured.
o Security requirements on the base P2P algorithm (e.g., DHT
implementations) used in P2PSIP SHOULD be minimized.
Matuszewski, et al. Expires August 30, 2007 [Page 7]
Internet-Draft Security threats in P2PSIP February 2007
o Dependence of reachability of a centralized server SHOULD be
minimized.
o The enrollment process of a P2PSIP system defines the set of
clients and peers that MAY participate in this P2PSIP system.
o Existing security mechanisms SHOULD be used as much as possible to
protect P2PSIP functions, and avoid the need for standardizing new
mechanisms.
o Malfunctioning and badly behaving P2PSIP nodes can be identified
and mechanisms for exclusion of those nodes from the P2PSIP system
exists.
Matuszewski, et al. Expires August 30, 2007 [Page 8]
Internet-Draft Security threats in P2PSIP February 2007
4. Security threats
4.1. Replay Attacks
Replay attacks are a form of network attacks where a valid data
transmission is repeated or delayed. Thus, the architecture must
consider this issue in the process of both enrollment and
modification of P2PSIP resource (user) records in a P2PSIP overlay.
During those procedures, an attacker may be able to enroll
credentials for himself, or replace existing entry in the system by
an older entry.
4.2. Message Insertion, Modification, Deletion
The message insertion, modification, and deletion attacks are where
the attacker is able to alter the messages being exchanged between
two end points. With these types of attacks the integrity of the
P2PSIP system becomes compromised including the enrollment procedure
and data stored in the P2PSIP overlay.
4.3. Man-In-The-Middle
Man-in-the middle (m-i-m) attacks are prevalent in pairing and
authentication procedures. Thus, the architecture must consider this
issue in the process of enrollment, as well as during modification of
P2PSIP resource (user) records in a P2PSIP overlay. During
communication m-i-m attacks may lead to data leakage and
modification. However, by using well-established authentication
protocols, at least the m-i-m threat is mitigated.
4.4. Offline Cryptographic Attacks
The incentive to break a secure system dominates the effort to do so.
It is likely that P2PSIP systems do not pose a likely target for
attacks, and if state-of-the art security methods are used, the
needed effort to break the system by breaking cryptography is very
likely to be higher than by finding and exploiting software errors
and vulnerabilities.
4.5. Unauthorized Usage
The basic notions of authentication and authorization, when
implemented correctly and consistently SHOULD protect against
unauthorized usage of the P2PSIP system. However, the
trustworthiness of an identity may be weak i.e. the enrollment system
might be fairly open and allow devices and persons that wish to
attack the system. Thus, there is a significant threat of attacks
from within the system.
Matuszewski, et al. Expires August 30, 2007 [Page 9]
Internet-Draft Security threats in P2PSIP February 2007
4.6. Inappropriate Usage
As the lookup and routing in the P2PSIP essentially provides a
distributed storage for P2PSIP resource (user) records, this can be
used in an inappropriate manner. Definitely the individual services
provided by P2PSIP (messaging, real-time communication) have their
respective threat models regarding inappropriate use (Spam, viruses,
...) but these can be considered out of scope for this document.
4.7. Denial of Service
In the proposed P2PSIP architecture, the P2PSIP resource (user)
records are not maintained in a central, trustworthy storage system -
rather it is distributed among peers participating in the system.
This implies that the presence of malicious nodes in the storage can
be considered to be probable rather than possible. In cases where
authentication in the DHT is weak or where the system is fairly open
to new participants the "infiltration" is trivial (e.g., Sybil
attack). However, DHT:s typically distribute the the P2PSIP resource
(user) records among its nodes in a fashion where the outcome (the
storage node) is hard to predict - also copying of the P2PSIP
resource (user) records to several nodes for increased robustness is
the norm. Thus the infiltration - if done in a trivial manner,
typically must be done with a fairly big number of nodes to achieve a
probability of success in bringing down the system or at least
denying service regarding selected peers and clients.
Another critical point where a D-o-S attack can be mounted is the
enrollment system. This is probably quite monolithic, and typical
"network" D-o-S attacks (like SYN flooding) are probably possible in
this domain. Related by different is the reservation of known
identities belonging to "other devices" and persons in the context of
a single P2PSIP instance.
4.8. Communication security threats
This document assumes that the actual SIP service implementation
provides its own communication security, and that P2PSIP adds to that
only in providing a means for the communication endpoints to
establish a shared key for further security needs. Otherwise, the
communication security threats in that domain is out-of-scope for
this discussion.
As the intention is to modify the DHT as little as possible, it can
be assumed that the "storage facility and its communication" i.e. the
DHT is unprotected. Instead, data stored there is protected
independently of communication and where it is stored.
Matuszewski, et al. Expires August 30, 2007 [Page 10]
Internet-Draft Security threats in P2PSIP February 2007
The main places where communication security becomes an issue in the
P2PSIP context is the enrollment process (where the actual
communication mechanism may be out of scope) and the communication
between a client and the corresponding peer. The last one is subject
to all typical threats in this domain - however they have been
individually considered in the earlier sections of this chapter.
Matuszewski, et al. Expires August 30, 2007 [Page 11]
Internet-Draft Security threats in P2PSIP February 2007
5. Security Considerations
This memo discusses security threats in P2PSIP overlay networks.
Security aspects are discussed throughout the document. However,
this document does not introduce any security risk by itself.
Matuszewski, et al. Expires August 30, 2007 [Page 12]
Internet-Draft Security threats in P2PSIP February 2007
6. IANA Considerations
There are no IANA considerations associated to this memo.
Matuszewski, et al. Expires August 30, 2007 [Page 13]
Internet-Draft Security threats in P2PSIP February 2007
7. References
7.1. Normative References
[1] Bryan, D., Matthews, P., Shim, P., and P. Willis, "Concepts and
Terminology for Peer to Peer SIP",
draft-willis-p2psip-concepts-03.txt (work in progress),
April 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Matuszewski, et al. Expires August 30, 2007 [Page 14]
Internet-Draft Security threats in P2PSIP February 2007
Authors' Addresses
Marcin Matuszewski
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: marcin.matuszewski@nokia.com
Jan-Erik Ekberg
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: jan-erik.ekberg@nokia.com
Pekka Laitinen
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: pekka.laitinen@nokia.com
Matuszewski, et al. Expires August 30, 2007 [Page 15]
Internet-Draft Security threats in P2PSIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Matuszewski, et al. Expires August 30, 2007 [Page 16]