Subject: [P2PSIP] Review of draft-birkos-p2p-security-key-refresh-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Mar 2010 17:51:45 -0700

$Id$

GENERAL
This document describes two mechanisms:

- a technique for frequent refreshes of the
  asymmetric key pair used for node authentication in RELOAD.
- an (undefined) mechanism for encrypting messages in transit.

WRT to the first mechanism, the authors write:

   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.

I don't understand this security rationale. When a node refreshes
its key, it authenticates its request using its existing cryptographic
key pair. How does this provide additional security value over
simply using the same key pair indefinitely?

WRT to the second, the mechanism is completely unspecified, so it's
hard to tell whether it's of any value. In the existing RELOAD
system, when peers desire confidentiality they can simply set
up a TLS session. Why is message-based encryption superior?
As discussed below, there are a number of settings in which
it seems very problematic.

DETAILED COMMENTS
S 1.1.
How do nodes become super peers? This is left unspecified, but they
presumably must be nominated by the certificate authority. How
does this work?

S 2.2.
   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.

What does this bring to the party? If you have a network secured with an
MSK, then nobody can form any TLS connection to any node without knowing
the MSK. Thus, any message received over the overlay should have
been generated by someone who knew the MSK. If you don't trust
BPs to check this, why do you trust them to secure the MSK? Note
also the since the first thing that the JPs do is Attach to the
AP, the AP gets to directly verify the JP's knowledge of the MSK in
any case.

S 3.1.

                                 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.

This doesn't make any sense. All traffic is enciphered with TLS
and so the JP will not make a connection to any node which does
not know the MSK. And since all nodes in the overlay know the
MSK, I don't see that htis adds any additional security.
Third, the identity of JP is secured with public key cryptography,
knowing its identity does not permit impersonation.

S 3.3.
   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

I don't understand how this works. When you generate a StoreReq (for
instance) you don't know what peer is responsible for that region.
Under what PK do you encrypt it?

S 4.
   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.

Doesn't this turn the super peer into a replacement CA? This is a remarkable
amount of trust to put in a peer.

S 4.1.
   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

How can we not define which algorithms work? Interop requires this.

   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.

What is your threat model here? How does an attack  who has RP's private
key not have MSK, which is known to every node in the overlay.