$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.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
