At Fri, 02 Oct 2009 07:20:50 -0700, Michael Chen wrote: > > 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.
I'll take a look at doing this, but as usual, it would help if you send text. > > 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." I'm not convinced this is that simple: it requires carrying this origin information from the connection level around to the signature processing level, as well as new logic for the sender to know when this is safe or not. That's new logic and new code paths, which means new things to get wrong--bad in security systems. I'd like to see some data suggesting this is an important optimization. > >> 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. Huh? How is it in attack for Y to take a message originated by X and claim it was originated by itself? Y can always generate any message it wants and sign it. That's how signature-based message authentication works. Moreover, why would this be an attack on X or Z, since Y is *legitimately* allowed to generate messages and Z would (correctly) conclude that the message came from Y, not X. The fact that Y is copying X's message is irrelevant. > 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? I have no idea what you are talking about. > > 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. I don't understand what you're talking about here either. The cryptographic elements of an authenticated message in RELOAD are: - The contents - A signature, generated using the sender's private key - The sender's identity - A certificate binding the sender's public key to the sender's identity. In order to validate this, the verifier needs to: - Verify the signature on the certificate (using the CA's public key, which is known a priori) - Verify that the sender's identity matches the identity in the certificate - Verify that the signature on the contents is correct (using the sender's public key, which is found in the certificate). This can be (needs to be) done regardless of the provenance of the certificate because the certificate is directly verifiable. The system does not depend on the certificate being provided by a trusted source. The only time when you do not need to verify the certificate is if you have previously verified it and cached the result. You never trust that the certificate is correct otherwise. > 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? When there are elements which need to be verified with different certificates. For instance, if node A stores a value with node B, which then does a replica store to node C, then the B->C store will have two signatures: - The signature over the value, using A's key - The signature over the message, using B's key The SecurityBlock will then contain both A and B's certificates. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
