> -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 7. November 2007 17:19 > To: Elwell, John; 'IETF SIP List' > Subject: RE: [Sip] media-security-requirements and lawful intercept > > > > > -----Original Message----- > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 07, 2007 3:17 AM > > To: Dan Wing; IETF SIP List > > Subject: RE: [Sip] media-security-requirements and lawful intercept > > > > Dan, > > > > Speaking as an individual (not on behalf of another SDO), I don't > > believe it is possible to satisfy R24. > > > > With method a, the network element will not be able to provide > > appropriate credentials to satisfy a user that he is in > communication > > with the remote user. > > 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. One argument for DTLS-SRTP is the end-to-end security capability, which will be weakened for every call in this case. > > > 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? Are these blocking network components able to analyze the first byte of the packets and to distinguish between RTP and DTLS traffic? Kai _______________________________________________ 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
