Eric,
Eric Rescorla wrote:
On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen <[email protected]> wrote:
Eric Rescorla wrote:
This is already true
I don't see this being explained in the draft. Are you saying it based on
implementation?
5.5.1.13.
The procedures of Section 11 apply to RELOAD as well. However, in
this case, the "media" takes the form of application layer protocols
(RELOAD or SIP for example) over TLS or DTLS. Consequently, once ICE
processing completes, the agent will begin TLS or DTLS procedures to
establish a secure connection. The node which sent the Attach
request MUST be the TLS server. The other node MUST be the TLS
client. The nodes MUST verify that the certificate presented in the
handshake matches the identity of the other peer as found in the
Attach message. Once the TLS or DTLS signaling is complete, the
application protocol is free to use the connection.
This is vague. It should be explicitly stated using SSL terminology
"client authentication". SSL started as a client-server protocol, and in
its most common use HTTPS, clients are almost always anonymous. This
draft should be explicit about the client authentication mandate.
12.6.2.
Admission to an RELOAD Overlay Instance is controlled by requiring
that each peer have a certificate containing its peer ID. The
requirement to have a certificate is enforced by using certificate-
based mutual authentication on each connection.
Here should again explicitly echo that mutual authentication refers to
TLS/DTLS server and client authentication during handshake.
The level of trust established this way is equivalent to that provided by
the current draft-03. The intend is that with these mandates, the RELOAD
protocol itself can be simplified by removing all certificate and signature
related requirements. For example, in my earlier post, an overhead of 1292
bytes can be trimmed down to only 69 bytes!!! (removing the security block
and the STORE signature).
I still need to think about messages forwarded by instead of originated
from a peer, but let the discussion begin.
Uh this is the base case. Which is why the messages have signatures
Ekr
Let's give it some more thought. With client authentication, any two
directly connected peers "trust" each other based on their overlay
credentials. Therefore, single hop messages like DHT stablization can be
exchanged between them with no signature/certificates attached. That's a
great saving to consider.
Yes, this is a potential optimization. But unless something is seriously
wrong with the design (or the overlay is essentially quiescent), then
this sort of stabilization traffic should be a small amount of the overall
traffic, so it's not clear what the overall savings is.
This optimization requires hardly any effort either in your part to
write or in mine to implement. A short paragraph in the draft saying,
"If the message is originated from a directly connected peer, the
security block may contain a zero length certificates list, zero length
signer ID and zero length signature."
If a message is forwarded, say X->Y->Z, Y can doing man in the middle
attack. For Z to truly ensure that the message is from X, Z must FETCH X's
certificate from the overlay to verify the signature. For that reason,
sending the certificate has no real security meaning.
No, this is not correct. Certificates are independently verifiable by chaining
back to the overlay's root key. That's pretty much the point of certificates:
you can verify them no matter how you received them.
In the attack by Y described above, Y would sign and put its own
certificate chain in the security block, so the whole message is
verifiably correct. The only way Z can know this is an attack is by
enforcing other constrain of this draft. For example, if the STORE
resource ID is between Y and Z, then this is an attack.
Aha! What if the resource ID in X's request is between X and Y or before
X in the ring? Then Z will never notice the attack. Y can map calls to
x...@domain to Y's destination list. Am I right?
Now, it's true that there is no SECURITY value in sending the certificate
along with the message. Data origin authentication authentication is supplied
by a digital signature computed using the private key that corresponds to
the public key in the certificate. The certificate is attached to the message
to avoid the complexity of a system where you have to hold the message
while you try to retrieve the certificate.
-Ek
A security warning should be included in this draft about the potential
danger of trusting the certificate in the SecurityBlock. It's the proper
thing to do.
One more thing about SecurityBlock.certificates, in an overlay that
requires an enrollment server, what is the use case in which the peer's
certificate is not issued/signed by the enrollment server? In another
word, what is the use case where SecurityBlock.certificates contains
more than one (the peer's) certificate?
By the way, there is no need to include the certificate chain that
issued the enrollment server's certificate, because that chain would
have been verified during enrollment by each peer.
Thanks
--Michael
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
