> > 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). > > [JRE] This wouldn't work if LI is not being done in the originating > domain. Enterprise UA issues INVITE request, enterprise proxy addes > Identity header field and forwards to public service provider, which > needs the possibility to intercept.
Good point; I had only been considering handsets in IMS (3GPP) networks. I'll give that some more thought. > > > 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). > > [JRE] I don't see how it could verify a key if the > authentication tag is not used. Maybe it is easier for SRTCP than for SRTP, > but that might > involve some unacceptable delay before the first SRTCP packet arrives. > Having said that, I would have thought the authentication tag would > normally be used, since otherwise the security provided is rather > dubious. Agreed. And, today, all of the SRTP crypto suites in RFC3711 have an authentication tag and as far as I know everyone is using it. However, it is my understanding that SRTP with Galois/Counter Mode (GCM) would not need (or use) an authentication tag. I don't know how a GCM key would be validated. That was my concern there. -d > > > > -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 > > _______________________________________________ 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
