Internet DRAFT - draft-birkos-p2psip-security-key-refresh
draft-birkos-p2psip-security-key-refresh
P2PSIP Working Group K. Birkos
INTERNET-DRAFT C. Papageorgiou
Intended Status: Experimental P. Galiotos
Expires: September 2010 (University of Patras)
T. Dagiuklas
(TEI of Mesolonghi)
C. Tselios
S. Kotsopoulos
(University of Patras)
March 1, 2010
Security Mechanisms and Key Refresh for P2PSIP Overlays
draft-birkos-p2psip-security-key-refresh-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
Birkos et al. Expires September 2010 [Page 1]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Birkos et al. Expires September 2010 [Page 2]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
Abstract
This document proposes security extensions that are applicable to
P2PSIP overlays that follow the base protocol described in the WG
leading drafts. The proposed extensions exploit symmetric/asymmetric
cryptography and a key refresh mechanism to protect the signaling
exchanged between the participating peers in order to enhance the
robustness of the system against several types of attacks that are
common to peer-to-peer networks. The refresh mechanism is either
supervised by higher-level trusted peers or exclusively controlled by
the members of the overlay.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Super Peers . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Security Credentials . . . . . . . . . . . . . . . . . . . 5
3 Securing Basic Overlay Operations . . . . . . . . . . . . . . . 5
3.1 Securing Join Process . . . . . . . . . . . . . . . . . . . 6
3.2 Securing Updates . . . . . . . . . . . . . . . . . . . . . 6
3.3 General Encryption Rules . . . . . . . . . . . . . . . . . 6
4 Refresh Mechanism . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Key Refresh Supervised by Super Peers . . . . . . . . . . . 7
4.2 Key Refresh Handled by Peers . . . . . . . . . . . . . . . 9
5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
7 Security Considerations . . . . . . . . . . . . . . . . . . . 11
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . 11
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Birkos et al. Expires September 2010 [Page 3]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
1 Introduction
This document defines security mechanisms that can be used as
optional features in P2PSIP overlays. REsource LOcation And Discovery
(RELOAD) [I-D.reload] already includes security features based on TLS
and public key certificates. The certificates are digitally signed by
a Certificate Authority (CA) during the Enrollment and Authentication
phase described in the base protocol. In small-scale overlays between
trusted users with no strict security requirements, the use of self-
signed certificates is an alternative [I-D.reload]. Other WG drafts
have also discussed security considerations [I-D.sec-ext][I-D.sec-
mech].
Peer-to-peer networks are prone to several types of attacks due to
their distributed nature. Attacks can target the structure of the
overlay, overlay routing and/or stored information. Protecting
signaling is necessary in order to hide the exchanged information
between peers during peers' joining/leaving the overlay and also
during maintenance and stabilization [I-D.sip-usage]. Apart from
that, refreshment of the used security credentials is a practice that
can enhance the robustness of the system against malicious activities
and remove any detected compromised peer.
This document aims at describing a basic protection strategy through
encryption using symmetric and asymmetric cryptography and defines
other uses of keys already included in the base protocol. In
addition, a key refresh mechanism is defined. According to this
mechanism, the keying material of the participating peers is
periodically refreshed and new certificates are generated so that the
binding between peer IDs and the new public keys can be verified. The
process can be supervised by higher-level peers called super peers.
[I-D.hierarchical] defines how a P2PSIP overlay based on peers that
belong to different levels of hierarchy should operate. In the
absence of super peers, each member of the overlay is responsible for
guaranteeing the validity of its new security credentials.
1.1 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 RFC 2119 [RFC2119].
Terms and definitions from the Concepts and Terminology for Peer to
Peer SIP [I-D.concepts] and the REsource LOcation And Discovery
(RELOAD) Base Protocol [I-D.reload] are extensively used in this
document. New terms that are introduced are presented below.
Super Peer: A higher-level peer with extensive computational
Birkos et al. Expires September 2010 [Page 4]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
capabilities which is responsible for monitoring peer joining
activities, overlay maintenance and refreshment of the security
credentials.
Master Key (MSK): A network-wide shared secret key used for
authentication and for identity protection purposes when a new
peer joins the overlay and also during the refreshment of the
security credentials. It is equivalent to the key used in the
Shared-Secret Security subsection as appeared in [I-D.reload].
Public/Private Key pair (PPK pair) : The pair of keys used in the
asymmetric cryptography. The sender encrypts a message using the
receiver's public key and the receiver uses its own private key to
decrypt the message.
2 Prerequisites
The security extensions described in this document depend on
symmetric and asymmetric cryptography and also on the existence of
super peers, which monitor certain activities regarding security
during the Refresh process. The Refresh process is described later in
this document.
2.1 Super Peers
Super peers are higher-level peers with extensive responsibilities
regarding the security of the P2PSIP overlay. Super peers are in
charge of signing public-key certificates and they consist a second
line of trust apart from the trusted certificate authority which
initially issues the certificates to peers that wish to join the
overlay. A bootstrap node MAY include super peer functionality.
2.2 Security Credentials
As in the original protocol, each node possesses a shared secret key.
In this I-D, this key is called MSK. The difference is that the MSK
does not only serve at the formation of TLS connections but also in
the authentication that takes place during the joining process and in
the protection of peer identities.
In addition, each peer generates a PPK pair prior to the Enrollment
and Authentication phase. The validity of the public key is proved by
the usage of the public key certificate which binds the node's public
key with the node's identity.
3 Securing Basic Overlay Operations
In the following, the usage of the security credentials is defined in
Birkos et al. Expires September 2010 [Page 5]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
order to protect the signaling.
3.1 Securing Join Process
According to [I-D.reload], at the beginning of the joining process,
the joining peer (JP) sends a JoinReq message to the admitting peer
(AP). The body of the JoinReq message SHOULD be encrypted with the
MSK. This practice has two advantages.
At first, it strengthens authentication since the MSK serves as a
secondary authentication credential complementary to public key
certificate that binds JP's public key with JP's identity. The fact
that a JP holds MSK enforce the fact that a legitimate peer tries to
become member of the overlay. Secondly, encrypting the body of the
JoinReq message with the MSK ensures that the identity of JP remain
secret to attackers that would possibly try to impersonate JP.
Upon reception of a JoinReq message, AP verifies the signature of the
CA and consequently the validity of the public key of JP that was
included in the certificate. Thus, from now on AP MAY encrypt the
body of every message destined to JP with JP's public key.
3.2 Securing Updates
Update messages are overlay-specific and are exchanged between peers
whenever a peer joins/leaves the overlay or during maintenance and
stabilization. Since UpdateReq messages carry information that might
be exploited by an attacker to disrupt connectivity at the overlay
level or to launch overlay routing attacks, the body of UpdateReq
messages SHOULD be encrypted with the public key of the recipient.
3.3 General Encryption Rules
In general, the body of every message that carries information that
should be protected against eavesdropping SHOULD be encrypted with
the recipient's public key. These messages include StoreReq,
FetchAns, FindAns and RouteQueryAns. Of course, encrypting additional
message types should be an OPTIONAL feature. An UpdateReq message
that designates a renewal of the security credentials SHOULD be
encrypted with the MSK as explained in section 5.1. The following
table summarizes the basic encryption rules that SHOULD be followed
by a P2PSIP system. PK denotes the public key of the recipient.
Birkos et al. Expires September 2010 [Page 6]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
+------------------+--------------+
|Message Code Name |Encrypted with|
+------------------+--------------+
|join_req | MSK |
|update_req | MSK/PK |
|store_req | PK |
|fetch_ans | PK |
|find_ans | PK |
|route_query_ans | PK |
+------------------+--------------+
4 Refresh Mechanism
The refresh mechanism specifies all the necessary procedures and the
series of actions in order to deliver fresh keying material to the
participating peers. The keying material that needs to be refreshed
is the PPK pairs of the participating peers. The refreshment of the
PPK pairs serves two distinct purposes. The main goal is to limit the
period during which the system is vulnerable in case an attacker or a
malicious user obtains the private key of a peer. A secondary goal is
to limit the amount of time available to attackers that may be using
cryptanalysis in order to reveal private keys.
In the proposed system, the validity of the PPK pairs is timely
bounded. Consequently, the validity of the corresponding public key
certificates is timely bounded as well. Peers generate their own PPK
pairs after having received an explicit request from a super peer. A
new certificate has to be produced. This certificate will verify the
binding between the peer ID and the new public key. In the absence of
a CA, the new certificate can either be self-signed or signed by the
super peer that issued the order for refreshment. Additionally, the
new certificate has to be stored in the overlay as described in [I-
D.sip-usage] and the neighbors of the peer with the refreshed PPK
pair need to obtain the new public key. These issues are addressed
next.
4.1 Key Refresh Supervised by Super Peers
In each P2PSIP overlay, many super peers may exist. Otherwise, the
reliance on a single super peer would consist a single point of
failure. Super peers are charged with supervising the refresh
process. Each super peer is responsible for the key refresh of a
portion of the participating peers according to the peers' position
in the identity space. For example, different super peers supervise
different sectors in the Chord ring in case Chord is used in the
Topology Plugin. For improved scalability and granularity, these
sectors should not be static. In other words, super peers should be
Birkos et al. Expires September 2010 [Page 7]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
responsible for sets of peers that are already connected to the
overlay based on the information disseminated via the Update
messages.
When the CA issues a certificate to a peer, it includes the validity
period in the certificate. A super peer periodically checks the
certificates of the peers in its jurisdiction. A time margin before a
certificate expires, called refresh margin, the super peer sends a
RefreshReq message to the owner of the certificate, i.e. to the peer
of which the PPK pair needs to be refreshed. We denote this peer as
Refreshed Peer (RP).
RP checks whether the validity period of the certificate justifies a
refresh action and decides whether it will proceed with the refresh
process. RP generates a new PPK pair by means of an asymmetric key
generation algorithm. The chosen algorithm as well as the required
input to produce the new keying material is beyond the scope of this
draft but RSA could be an option. RP sends the new public key to the
super peer via a RefreshAns message. The RefreshAns message is signed
with the old private key of RP and encrypted with the MSK. Signing
the RefreshAns with the old private key enables the super peer to
verify the identity of the creator of the new PPK pair. The super
peer verifies that RP has indeed created the PPK pair and not some
other malicious peer that tried to impersonate RP. Encrypting
RefreshAns with the MSK further protects the delivery of the new
public key, especially in case an attacker has retrieved RP's private
key.
The super peer then creates a certificate that binds RP's ID to RP's
new public key. The super peer signs the certificate and stores it in
the DHT. At the same time it sends a copy of the certificate to RP
via an UpdateReq message. RP responds with an UpdateAns to the super
peer. Finally, RP informs its neighbors about the refreshed public
key via UpdateReq messages. An UpdateReq message contains the
certificate signed by the super peer. RP's neighbors that receive the
UpdateReq verify super peer's signature and designate the acceptance
of the new public key by sending an UpdateAns to RP. Alternatively,
it can be RP the peer that sends the StoreReq message in order to
store the new certificate in the DHT. The following figure depicts
the exchanges messages. SP is the super peer, RP is the peer being
refreshed, NRP is a neighbor of RP and CRP is the peer that stores
RP's certificates (according to the Certificate Store Usage [I-
D.reload]).
Birkos et al. Expires September 2010 [Page 8]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
CRP SP RP NRP
| | | |
| | RefreshReq | |
| |----------->| |
| | RefreshAns | |
| StoreReq |<-----------| |
|<-----------| UpdateReq | |
| StoreAns |----------->| |
|----------->| UpdateAns | |
| |<-----------| UpdateReq |
| | |----------->|
| | | UpdateAns |
| | |<-----------|
| | | |
The Refresh process must guarantee the unobstructed operation of the
overlay regardless of impairments of lower layers. In case super peer
does not receive a RefreshAns by RP within a certain time limit, it
resends the RefreshReq message to RP. The time limit and the maximum
number of attempts after an unsuccessful refresh attempt are
parameters of the system. When the maximum number of trials has been
reached, the RP is considered disconnected. RP has to pass through
the Enrollment and Authentication phase in order to re-join the
overlay.
The super peers may participate in a distributed Intrusion Detection
System (IDS) and monitor peers' behavior in the overlay.
Consequently, the decision of a super peer to request refreshed PPK
pairs by a peer, depends on whether the activities of this peer
justify the fact that the peer should continue to be a member of the
overlay. The definition of an IDS suitable for a P2PSIP overlay is
beyond the scope of this document.
4.2 Key Refresh Handled by Peers
In this case, all the participating peers belong to the same level of
hierarchy and there are no online entities that can supervise key
refresh. Thus, the certificates containing the new public keys must
be self-signed by the peers even if the original certificates were
signed by the CA during Enrollment and Authentication. Moreover, each
peer has the responsibility to initiate the refresh process.
When RP's certificate is about to expire, RP generates a new PPK
pair. RP also generates a certificate that contains its new public
key bound to its ID. RP signs the certificate with its old private
key and stores it in the DHT. After that, RP sends the new
certificate to its neighbors via an UpdateReq message. The message is
encrypted with the MSK.
Birkos et al. Expires September 2010 [Page 9]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
Again, an unsuccessful refresh attempt results in RP disconnecting
from the overlay and trying to receive a valid and updated
certificate through Enrollment and Authentication. The following
figure presents the refresh process handled by peers.
CRP RP NRP
| | |
| StoreReq | |
|<-----------| |
| StoreAns | |
|----------->| |
| | UpdateReq |
| |----------->|
| | UpdateAns |
| |<-----------|
| | |
The refresh method described in this subsection is more lightweight,
produces less overhead and does not rely on any kind of online
trusted third parties. However, the offered security level is reduced
due to the use of self-signed certificates.
5 Conclusions
This memo describes an additional usage of security credentials for
enhancing the security levels of a P2PSIP overlay. Moreover, it
introduces a refresh process via which the keying material of the
peers is periodically renewed. The proposed solutions are designed to
adapt to the requirements and the characteristics as defined in the
leading WG drafts.
Birkos et al. Expires September 2010 [Page 10]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
6 Acknowledgement
The authors wish to acknowledge the support of the ICT European
Research Programme and all the partners in PEACE: PDMF&C, Instituto
de Telecomunicaciones, FhG Fokus, Kingston University, Thales,
Telefonica, Pale Blue.
7 Security Considerations
There are no security considerations at this time.
8 IANA Considerations
This draft includes no request to IANA at this time. Considerations
regarding the RefreshReq and RefreshAns messages defined in this
document will be included in future versions of the draft, after
proper discussion within the Working Group.
9 References
9.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
[I-D.reload] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S. and
Schulzrinne, H., "REsource LOcation And Discovery
(RELOAD) Base Protocol", draft-ietf-p2psip-base-06, (work
in progress), November 2009.
[I-D.sip-usage] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.
and Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-
p2psip-sip-03, (work in progress), October 2009.
[I-D.concepts] Bryan, D., Matthews, P., Shim, E., Willis, D. and
Dawkins, S., "Concepts and Terminology for Peer to Peer
SIP", draft-ietf-p2psip-concepts-02, (work in progress),
July 2008.
[I-D.sec-ext] Jennings, C. and Deverick, J., "Security Extensions
for RELOAD", draft-lowekamp-p2psip-reload-security-01,
(work in progress), July 2007.
Birkos et al. Expires September 2010 [Page 11]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
[I-D.sec-mech] Jennings, C., "Security Mechanisms for Peer to Peer
SIP",draft-jennings-p2psip-security-00, (work in
progress), February 2007.
[I-D.hierarchical] Lifeng, L., "Hierarchical P2PSIP Overlay", draft-
le-p2psip-hierachical-p2psip-overlay-00, (work in
progress), July 2009.
Author's Addresses
Konstantinos Birkos
University of Patras
26500
Patras, Greece
Phone: +30 2610 996465
EMail: kmpirkos@ece.upatras.gr
Christos Papageorgiou
University of Patras
26500
Patras, Greece
Phone: +30 2610 996465
EMail: xpapageo@ceid.upatras.gr
Panagiotis Galiotos
University of Patras
26500
Patras, Greece
Phone: +30 2610 996465
EMail: pgaliot@upatras.gr
Tasos Dagiuklas
TEI of Mesolonghi
30300
Nafpaktos, Greece
Phone: +30 26310 58486
EMail: ntan@teimes.gr
Christos Tselios
University of Patras
26500
Patras, Greece
Birkos et al. Expires September 2010 [Page 12]
INTERNET DRAFT Security Mechanisms and Key Refresh March 2010
Phone: +30 2610 996465
EMail: tselios@ece.upatras.gr
Stavros Kotsopoulos
University of Patras
26500
Patras, Greece
Phone: +30 2610 996466
EMail: kotsop@ece.upatras.gr
Birkos et al. Expires September 2010 [Page 13]
