> -----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). > 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). -d > John > > > -----Original Message----- > > From: Dan Wing [mailto:[EMAIL PROTECTED] > > Sent: 06 November 2007 17:51 > > To: 'IETF SIP List' > > Subject: [Sip] media-security-requirements and lawful intercept > > > > Other SDOs have lawful intercept requirements, which are currently > > captured in requirement R24 in > > draft-ietf-sip-media-security-requirements-00: > > > > "R24: The media security key management protocol SHOULD > > NOT allow end users to determine whether their > > end-to-end interaction is subject to lawful > > interception." > > > > DTLS-SRTP was selected by IETF as the IETF's preferred mechanism > > to establish SRTP keys for unicast, point-to-point SRTP sessions. > > > > There appear to be two methods to meet R24 with DTLS-SRTP. They > > are: > > > > a. provide a network element on every SRTP call which relays > > media, performs a DTLS handshake, and decrypts and re-encrypts > > SRTP, or; > > > > b. have endpoints perform key disclosure for every call (using a > > technique similar to draft-wing-sipping-srtp-key), and perform > > validation of that disclosed key on every call. > > > > If these methods to meet R24 are deemed acceptable to other SDOs, > > we don't find any reason for those SDOs to reject IETF's decision > > to use DTLS-SRTP as the preferred mechanism to establish SRTP > > keys for unicast, point-to-point SRTP sessions. > > > > Comments welcome. > > -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 > > > > > _______________________________________________ > 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 _______________________________________________ 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
