> > Method 'a' could be achieved if the interception (and DTLS > > handshake) > > occurred within the originating domain, prior to the RFC4474 > > signature. This can allow inserting the man in the middle at that > > point. This would need to be done for every call (not just > > calls being intercepted). > > This might be a solution, but not a very attractive one, since every > call is intercepted and needs to be decrypted and encrypted again.
Yes, I agree it is computationally expensive. > One > argument for DTLS-SRTP is the end-to-end security capability, > which will be weakened for every call in this case. LI weakens end-to-end security, no matter the technique chosen. Today things are very weak (media is unencrypted). Security Descriptions places trust on every SIP signaling element on the path. DTLS-SRTP, with the "a" technique, doesn't place trust on every element, but just one. > > > > > Assuming RFC 4474 is used as the basis for > > > authentication, the certificate provided by the > > > Authentication Service > > > acting on behalf of user A will sign the request and any > > > self-signed > > > certificate from UA that will be used in the DTLS handshake. Any > > > substitution of that certificate by a network element would > > > break the > > > signature. Any attempt at changing the From URI and > > > Identity header > > > field by an Authentication Service acting on behalf of the network > > > element would presumably use a certificate for that domain, not a > > > certificate for user A's domain, so it would be clear to user > > > B that the > > > call has come via that middle domain and is encrypted > > > only as far as > > > that middle domain. > > > > I agree that after the RFC4474 signature is created, other domains > > can't become a man in the middle. > > > > > With method b, as already stated one of the users has to agree to > > > disclose its key. > > > > The network can enforce that by blocking SRTP until the key is > > disclosed. Some networks that block RTP until 200 Ok for fraud > > prevention, and those same networks have LI requirements placed > > on them by their government. Those networks could, similarly, block > > SRTP until the key is disclosed, and could validate that the > > supplied key does decrypt SRTP (especially SRTP that is protected > > with an authentication tag). > > How is it possible to perform a DTLS handshake if the RTP traffic / > ports are blocked? It isn't. You would need to perform the DTLS handshake when the RTP path is open, or you would need to perform the DTLS handshake over RTCP (which is not part of the DTLS-SRTP specification set at this point in time; there is an offline discussion about this very problem with DTLS-SRTP and some solutions to that problem. I expect to see some email traffic on this specific issue shortly.) > Are these blocking network components able to analyze > the first byte of the packets and to distinguish between RTP and DTLS > traffic? Today, they do not do that, because they do not need to do that. They could become capable of doing that. It is my understanding that, because today there is no need for those elements to do such content-based filtering, only simple filters (allow/deny) have been defined in the relevant specifications and only simple filters have been implemented by vendors in product. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
