P2PSIP Working Group M. Matuszewski
Internet-Draft J-E. Ekberg
Intended status: Informational P. Laitinen
Expires: January 10, 2008 Nokia
July 9, 2007
Security requirements in P2PSIP
draft-matuszewski-p2psip-security-requirements-01.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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Matuszewski, et al. Expires January 10, 2008 [Page 1]
Internet-Draft Security requirements in P2PSIP July 2007
Abstract
This document is an analysis of security threats in the Peer-to-Peer
SIP reference model presented in the P2PSIP concepts and terminology
for P2PSIP document [1]. Typical security ontology is used as
classification for the threats. The main security requirements for
the architecture and its components are also presented.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. A P2PSIP network entity . . . . . . . . . . . . . . . . . 4
2.3. A P2PSIP system . . . . . . . . . . . . . . . . . . . . . 4
3. Security threats . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Message Insertion, Modification, Deletion . . . . . . . . 6
3.3. Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . 7
3.4. Offline Cryptographic Attacks . . . . . . . . . . . . . . 7
3.5. Unauthorized Usage . . . . . . . . . . . . . . . . . . . . 7
3.6. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 8
3.7. Denial of Service . . . . . . . . . . . . . . . . . . . . 8
3.8. Communication security threats . . . . . . . . . . . . . . 9
4. Security requirements . . . . . . . . . . . . . . . . . . . . 10
4.1. User requirements . . . . . . . . . . . . . . . . . . . . 10
4.2. System requirements . . . . . . . . . . . . . . . . . . . 10
4.2.1. Dependence of reachability of a centralized server . . 10
4.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Preference of existing security mechanisms . . . . . . 11
4.2.4. Requirements on a base P2P algorithm . . . . . . . . . 11
4.2.5. Node and user identification . . . . . . . . . . . . . 11
4.2.6. Enrollment . . . . . . . . . . . . . . . . . . . . . . 11
4.2.7. Replay attacks . . . . . . . . . . . . . . . . . . . . 12
4.2.8. Data access . . . . . . . . . . . . . . . . . . . . . 12
4.2.9. Data validation . . . . . . . . . . . . . . . . . . . 13
4.2.10. Denial of Service (DOS) attacks . . . . . . . . . . . 13
4.2.11. Privacy . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.12. Detection and rejection of badly behaving nodes . . . 13
4.2.13. Summary of the system requirements . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Matuszewski, et al. Expires January 10, 2008 [Page 2]
Internet-Draft Security requirements in P2PSIP July 2007
1. Introduction
The scope of this document is to analyse security threats concerning
a P2PSIP overlay architecture as described in the concepts and
terminology for Peer-to-Peer SIP (P2PSIP) document [1] and list
security requirements for the architecture and its components. This
document does not intend to propose solutions to overcome security
threats, but it is more intended to list the security requirements
that must be addressed in forthcoming P2PSIP specifications. This
document complements the P2PSIP protocol framework and requirements
document [3].
Matuszewski, et al. Expires January 10, 2008 [Page 3]
Internet-Draft Security requirements in P2PSIP July 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 network entity
A P2PSIP network entity is a user, peer, client, or other operative
function or node that may become a part of a P2PSIP overlay.
2.3. A P2PSIP system
A P2PSIP system consists of a P2PSIP overlay as defined in [1] and
one or more enrolment servers that issues unique identities and
credentials that are used to authenticate and admit a P2PSIP network
entity to the overlay and may provide an initial set of bootstrap
nodes.
Matuszewski, et al. Expires January 10, 2008 [Page 4]
Internet-Draft Security requirements in P2PSIP July 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 # Enrolment |
# N +-------+ +-------+ # protocol->|
# A | | | | # | |
#########T####| Proxy |########| Redir |###### v |
N | Peer | | Peer |<----------\ |
A | P | | R | v v
T +-------+ +-------+ +-----------+
# Enrolment #
# Server #
\__/ <------------------------------> # #
/\ +-----------+
/ \
/ UA \
/______\
SIP UA A
A P2PSIP system
Matuszewski, et al. Expires January 10, 2008 [Page 5]
Internet-Draft Security requirements in P2PSIP July 2007
3. Security threats
This section analyses security threats in the Peer-to-Peer SIP
reference model.
3.1. Replay Attacks
Replay attacks are a form of network attacks where a valid data
transmission is repeated or delayed. A badly behaving node may take
an older message sent by another node, resend it to the overlay, and
thus replace any newer data with the old information present in this
message. During those procedures, an attacker may be able to enroll
credentials for himself, or replace existing entry in the P2PSIP
overlay by an older entry. Thus, the architecture must consider this
issue in the process of both enrollment and modification of P2PSIP
resource (user) records in a P2PSIP overlay.
3.2. Message Insertion, Modification, Deletion
The message insertion, modification, and deletion attacks are where
an attacker is able to alter the messages being exchanged between two
end points. A badly behaving node may:
o change the data record in the overlay by changing incoming
message,
o discard query messages by discarding incoming messages,
o generate incorrect responses to requests received from a legimite
node that are directed to some other nodes.
For example, the attack described in the last bullet above may lead
to a lookup process being redirected to a malicious node or a
requestor receiving corrupted data pointing to some other node. This
would cause the overlay to contain unauthorized or outdated
information about a resource or corrupted data being returned to the
requestor. With these types of attacks the integrity of the P2PSIP
system becomes compromised. This includes both the enrollment
procedure and data stored in the P2PSIP overlay.
This means that an attacker not only can prevent access to P2PSIP
resource (user) records, but can also degradate the performance of
the P2PSIP system making it useless from the end-user perspective.
The second problem is of high importance in P2PSIP overlays that
store user's reachability data which is much more time-critical than
content stored in file sharing networks.
Matuszewski, et al. Expires January 10, 2008 [Page 6]
Internet-Draft Security requirements in P2PSIP July 2007
3.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. A badly behaving node can hijack a connection
established between two legimite nodes, or just listen and/or modify
messages exchanged between two nodes (as described in sections 3.1
and 3.2). For example an attacker may place two malicious nodes in
the overlay. One of the nodes would redirect/proxy queries to the
second malicious node that would appear as a target node.
The issue is prevailing in a deployment scenario where some peers act
as SIP registrars or/and SIP proxies that allow a conventional SIP UA
to access resources of the overlay. In a distributed environment
such as the P2PSIP overlay it is very difficult to trust all of peers
in the overlay. An unmodified SIP UA sends an SIP Invite request
towards an unknown peer that acts as a SIP proxy. If the SIP
messages are not cryptographically protected, this peer may act
maliciously and proxy a request to other than intended node or modify
SDP messages in order to stay on the media path. Similarly a peer
that acts as SIP Registrar may modify registration information before
it sends it to a peer that is responsible for storing the P2PSIP user
record of a registering SIP UA.
In a similar way if a bootstrap process is fully decentralised and a
bootstrap node is not trusted or authentication of the bootstrap node
is not possible, then the joining node can easily be attacked, e.g.
it may be redirected to another overlay controlled by the attacker.
However, by using well-established authentication protocols, the
m-i-m threat can be mitigated.
3.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.
3.5. Unauthorized Usage
The basic notions of authentication and authorization, when
implemented correctly and consistently SHOULD protect against
Matuszewski, et al. Expires January 10, 2008 [Page 7]
Internet-Draft Security requirements in P2PSIP July 2007
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.
A peer may do a multitude of attacks towards the overlay including:
o ignoring, changing, and deleting records in DHT that is it
responsible for,
o misbehaving during data lookups (ie, giving wrong node addresses,
discarding queries)
These attacks would cause DHT to contain unauthorized, outdated,
and/or missing information about a resource as well as might cause
lookups to fail.
3.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. If there is no access control to a
resources stored in the overlay and any node can retrieve information
stored in the overlay, an attacker may request data stored in the the
P2PSIP resource (user) records and perform inappropriate usage
attacks. 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.
3.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 peers can be considered
to be probable rather than possible. In cases where authentication
in the overlay is weak or where the system is fairly open to new
participants the "infiltration" is trivial (e.g., Sybil attack).
If nodes in the overlay can freely choose peer IDs and easily modify
previously selected peer IDs the attacker may use join-leave attacks
to place a malicious peer intentionally at any location in overlay
and obtain control of the location in the overlay where the attacked
user or resource (e.g. TURN@overlay.net) is registered. A malicious
peer may discard, modify the data it is supposed to store and may
discard lookup requests or reply with incorrect entries to the
Matuszewski, et al. Expires January 10, 2008 [Page 8]
Internet-Draft Security requirements in P2PSIP July 2007
incoming requests.
However, DHTs typically distribute the the P2PSIP resource (user)
records among its nodes in a fashion where the outcome (the storage
node) is hard to predict and 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.
The attacker may also try to register large number of resources to
the P2PSIP overlay increasing processing load on the nodes that are
responsible for storing the resources and limiting the overall
capacity of the P2PSIP overlay network. It may also try to register
all popular names preventing the name holders from registering their
prefered URIs.
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.
3.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 base P2P algorithm (e.g., DHT
implementations) 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.
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 or between peers. The
last ones are 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 January 10, 2008 [Page 9]
Internet-Draft Security requirements in P2PSIP July 2007
4. Security requirements
This section describes requirements related to the security of a
P2PSIP system. We divided the requirements into user requirements
and system requirements.
4.1. User requirements
The user wants available and reliable service that enables him to
interact with other users and resources in a secure way. This means
that the P2PSIP system MUST provide:
o lookup and discovery of users and resources that is secure and
reliable,
o certainty of user and resource identity,
o confidentiality and integrity of end-to-end multimedia
communication,
o easy and secure enrolment to the P2PSIP system,
o privacy.
4.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.
4.2.1. Dependence of reachability of a centralized server
Considering the nature of P2P in general, the dependence of
reachability of a centralized server should be minimized. 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, and deleting of P2PSIP
resource (user) records from the P2PSIP system should not depend on
the reachability of a centralised server.
4.2.2. Scalability
P2PSIP security should scale from a small ad-hoc network to a network
with hundred millions of network nodes and users.
Matuszewski, et al. Expires January 10, 2008 [Page 10]
Internet-Draft Security requirements in P2PSIP July 2007
4.2.3. 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.
4.2.4. Requirements on a base P2P algorithm
All of security operations should be specified in such a way that
they do not impose new unnecessary requirements on a base P2P
algorithm (e.g., DHT implementations) and limit its scalability.
4.2.5. Node and user identification
The P2PSIP system must preserve user and resource identities. It
must not be possible to steal a P2PSIP identity from another user.
In order to prevent so-called Sybil attacks the attacker should not
be able to easily register a unlimited number of IDs of his choice in
the P2SIP overlay. The P2PSIP system should be able to control ID
assignment. Once assigned, an ID or a set of IDs should be difficult
to change.
Because some attackers may try to use identities of another P2PSIP
network entities it must be possible to verify the identity of
another party.
4.2.6. Enrollment
The ease for users to enroll to a P2PSIP system should be ensured as
said in the section 4.1. The enrollment process defines the set of
users and P2PSIP network entities that may participate in a P2PSIP
system and issues them credentials. This process is defined by the
P2PSIP system, and the policy who can participate to is done during
this process. The enrolment process policy may define:
o how many and what user IDs and peer IDs an user or a network node
may register,
o whether users are charged for the usage of the P2PSIP system,
o and how often they must re-new their subscription to the P2PSIP
system.
As it was indicated in [3] the enrollment process may take several
Matuszewski, et al. Expires January 10, 2008 [Page 11]
Internet-Draft Security requirements in P2PSIP July 2007
measures in admitting a user or a network node to the P2PSIP system,
for example:
o may require strong identity such as employment or provided by a
trusted 3rd party or by the P2P operator,
o may charge for the enrollment,
o may apply reputation mechnisms.
Although the 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 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.
OPEN ISSUES: Who enrols to the P2PSIP system only a user or also
peers? Do we need separate credentials for peers and users? What
happens if a user is an owner of two or more nodes e.g. two peer
nodes or two clients? Does each node requires a separate credential
or only one credential is needed for all nodes that belong to a user?
Can two devices be "logged on" at the same time?
4.2.7. Replay attacks
An attacker should not be able to repeat or delay valid data
transmission during enrollment and modification of P2PSIP resource
(user) records in a P2PSIP overlay.
4.2.8. Data access
An attacker should not be able to easily corrupt, delete, or
overwrite data stored in P2PSIP resource (user) records as well as
routing tables. Only authorized users should be able to modify,
delete or overwrite their P2PSIP resource (user) records in the
P2PSIP system. P2PSIP security should allow users and P2PSIP network
entities to register the same resources (e.g. TURN@overlay.net),
however each entity should have rights only to its own part of a
resource record. In other words each entity should be able to
perform the same operations on its own part of a resource record as
in the case when a particular resurce belongs to only one user.
The owner of the P2PSIP resource (user) records should be able to
authorize other users and network entities to modify, delete their
P2PSIP resource (user) records.
Matuszewski, et al. Expires January 10, 2008 [Page 12]
Internet-Draft Security requirements in P2PSIP July 2007
4.2.9. Data validation
First and foremost it should be possible to verify that the data
stored in or retrieved from the P2PSIP overlay is authentic, i.e. was
not tampered by unauthorized P2PSIP network entities.
The peer that stores a P2PSIP resource (user) records should be able
to validate the data received in the process of P2PSIP resource
(user) record insertion and modification.
4.2.10. Denial of Service (DOS) attacks
It should not be possible to obtain control of the location in the
overlay where the attacked user or resource is registered. The
P2PSIP architecture should make sure that data stored in a P2PSIP
overlay is persistent, meaning that even if a number of nodes (but
not all of nodes in the overlay) fails the data stored by those nodes
should not be lost. In addition the attacker should not be able to
register unlimited number of resources in the overlay.
4.2.11. Privacy
The security of P2PSIP systems must guarantee privacy of the P2PSIP
network participants. The P2PSIP security should make an option for
the users to indicate which other P2PSIP network entities can
retrieve data stored in their P2PSIP resource (user) records. This
means that the owner of a P2PSIP resource (user) record or an
authorised P2PSIP network entity should be able to limit the access
to his own records, and this feature should be enforced by the P2P
network.
It should also be difficult to monitor who is communicating with a
particular user, or retreieve any contextual data about the user
without the user's explicit consent. The P2PSIP network entities
should be provided with option to encrypt data exchanged with other
P2PSIP network entities.
4.2.12. Detection and rejection of badly behaving nodes
It should be possible to limit potential damage caused by
malfunctioning and badly behaving nodes in a P2PSIP system. As the
policy taken by the P2PSIP system operator/community may be very
liberal, any user can obtain the right to be a user of a P2PSIP
system. It may be that some users behave badly intentionally in
which case it should be possible limit the impact of the badly
behaving nodes on the overall system security. It should be possible
to identify badly behaving nodes, and exclude or reject them from the
P2PSIP system.
Matuszewski, et al. Expires January 10, 2008 [Page 13]
Internet-Draft Security requirements in P2PSIP July 2007
4.2.13. Summary of the system requirements
P2PSIP system requirements related to security issues are summarized
below:
Req. 1: Dependence of reachability of a centralized server SHOULD be
minimized.
Req. 2: P2PSIP security SHOULD scale from a small ad-hoc network to a
network with hundred millions of network nodes and users.
Req. 3: Existing security mechanisms SHOULD be used as much as
possible to protect P2PSIP functions, and avoid the need for
standardizing new mechanisms.
Req. 4: Security requirements on the base P2P algorithm (e.g., DHT
implementations) used in P2PSIP SHOULD be minimized and SHOULD NOT
limit its scalability.
Req. 5: An enrollment process MUST be secured.
Req. 6: The registered identities in a P2PSIP overlay MUST be
preserved. The attacker should not be able to steal identity from
another user.
Req. 7: The enrollment process SHOULD make it difficult for an
attacker to register many identites in a P2PSIP overlay and easily
modify the registered identities.
Req. 8: It should be difficult to select a particular peer ID e.g.
peer ID assignment process SHOULD introduce some degree of randomness
to peer identites.
Req. 9: It MUST be possible to authenticate P2PSIP network entities.
Req. 10: It MUST NOT be possible to repeat or delay valid data
transmission during enrollment and modification of P2PSIP resource
(user) records.
Req. 11: The P2PSIP security MUST support integrity protection of the
data being inserted or retrieved to/from an overlay.
Req. 12: The P2PSIP network entities MUST be provided with an option
to encrypt data exchanged with other P2PSIP network entities.
Req. 13: Only authorized users and P2PSIP network entities MUST be
able to join the P2PSIP system and insert, modify, delete or
overwrite P2PSIP resource (user) records in the P2PSIP system.
Matuszewski, et al. Expires January 10, 2008 [Page 14]
Internet-Draft Security requirements in P2PSIP July 2007
Req. 14: If many users or P2PSIP network entities register the same
resource in the P2PSIP overlay, each entity MUST have only rights to
its own part of a resource record.
Req. 15: An owner of P2PSIP resource (user) record MAY indicate which
users or network entities can retrieve, modify, and delete data
stored in their P2PSIP resource (user) records. P2PSIP peer SHOULD
support access control set by the owner of P2PSIP resource (user)
record.
Req. 16: P2PSIP overlay protocols MUST be designed such a way so that
the effect of DOS attacks on the P2PSIP overlay are being minimized.
Req. 17: It SHOULD be possible to limit the impact of the badly
behaving P2PSIP nodes on the overall system security. There SHOULD
be an option to identify malfunctioning or badly behaving nodes, and
exclude or reject them from the P2PSIP system.
Matuszewski, et al. Expires January 10, 2008 [Page 15]
Internet-Draft Security requirements in P2PSIP July 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 January 10, 2008 [Page 16]
Internet-Draft Security requirements in P2PSIP July 2007
6. IANA Considerations
There are no IANA considerations associated to this memo.
Matuszewski, et al. Expires January 10, 2008 [Page 17]
Internet-Draft Security requirements in P2PSIP July 2007
7. Normative References
[1] Bryan, D., Matthews, P., Shim, P., and D. Willis, "Concepts and
Terminology for Peer to Peer SIP",
draft-willis-p2psip-concepts-04.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.
[3] Bryan, D., Baset, S., Matuszewski, M., and H. Sinnreich, "P2PSIP
Protocol Framework and Requirements",
draft-bryan-p2psip-requirements-00.txt (work in progress),
July 2007.
[4] 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 January 10, 2008 [Page 18]
Internet-Draft Security requirements in P2PSIP July 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 January 10, 2008 [Page 19]
Internet-Draft Security requirements in P2PSIP July 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 January 10, 2008 [Page 20]