[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/