[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [P2PSIP] D/TLS with client authentication

Eric,

Eric Rescorla wrote: 
On Thu, Oct 1, 2009 at 1:44 PM, Michael Chen <michaelc at idssoftware.com> 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 at 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