> -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 11, 2007 2:47 PM > To: Dan Wing > Cc: 'IETF SIP List' > Subject: Re: [Sip] media-security-requirements and lawful intercept > > At Tue, 6 Nov 2007 09:50:42 -0800, > Dan Wing wrote: > > > > 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. > > Wow, this sure produced a lot of discussion. I'd like to make a few > points: > > 1. It's not clear to me that people are correctly parsing LI > requirements. I'm not an expert on CALEA, let alone laws in other > countries, but it's not my understanding that there is any > regulatory requirement that forces carriers of voice or data > traffic to arrange for disclosure of plaintext when they don't have > the keys. I.e., if I buy data service from Comcast and choose to > run a VPN, there is no requirement that Comcast somehow obtain the > keys to deliver them to the FBI. > > It's less clear to me what the requirements are for 3G-style > carriers when the endpoints are doing the crypto. I.e., I'm quite > certain that if AT&T terminates the crypto they need to provide the > plaintext on request, but a lot less certain that they need to > provide the plaintext if the crypto is end-to-end.
Timothy Dwight posted a followup on 3GPP's requirement that should be helpful on those points. What remains unsaid in that quoted text is crypto performed by the endpoint itself (as with DTLS-SRTP). We could navel-gaze how governments might view that, or look at this from a business perspective: If you are a service provider, and you're looking at RTP, SRTP with Security Descriptions, or SRTP with DTLS-SRTP, what is the business opportunity versus business risk of adopting each of those technologies. The business opportunity is pretty straightforward: would you get more subscribers if you offered a secure service. The business risk is more murky: will a government agency decide you still need to provide decryption keys, because you still obstensibly "own" the endpoint (afterall, a cellular provider does own the radio license for that endpoint). > 2. It's extremely difficult to guarantee that the keys for > communication are being properly escrowed in the face of the > possibility that one or both of the communicating parties is > cheating. This is especially difficult if you want to avoid having > real-time access to the escrow keys used to encrypt the traffic > keys, which is generally good practice. So, I would be very > surprised if there were any regulatory requirement that LI work in > the face of endpoint cheating. > > 3. Given (2) above, I don't see how R24 can be achieved, since > two cooperating peers can always guarantee that their plaintext > is not subject to LI if they can arrange for any side channel > for key agreement. It is well-acknowledged that two cooperating peers can establish their own private communication, over the top of whatever communications channel they can set up normally. > 4. I don't actually think there's any protocol engineering required > here. The problem of how to arrange for TLS traffic key disclosure > to third parties without modifying the wire protocol has been quite > extensively studied and a broad variety of approaches exist, > covering a range of levels of active/passiveness, real-timeness, > cooperation from the endpoints, etc. Techniques exist which are > significantly better than those indicated by Dan. For instance, > consider that if you have the TLS server's private key and you're > doing RSA, you can do completely passive inspection with no > cooperation from either side. I am aware of that technique; however, for SIP calls with the offer in the in the Invite, you could only intercept outgoing calls, because incoming calls cause your intercept target to be the TLS client. I don't believe that technique is viable to meet R24. > Another example would be [GBGP03]. I was not aware of that technique; thanks for the pointer. That technique seems useful. (Direct link, http://crypto.stanford.edu/~pgolle/papers/escrow.pdf) > Also, as Jon Peterson observed, the owner of the namespace can > always enforce any restrictions that it wants. It's possible that > imposes significant performance costs, but it's not clear that > that's true in all cases with clever implementation. > > I don't really have time right now to go into any of this stuff > in more detail, but I'd certainly be happy to sit down with > anyone who cares in YVR and explain the state of the art. Thanks for the offer. > I don't > really see that this is really relevant to what happens in this > WG, though. If 3GPP decides to use something other than DTLS-SRTP, we will have two standards for SRTP keying -- the IETF standard and the non-IETF standard. I do not consider that desirable. -d > -Ekr > > > [GBGP03] E.-J. Goh, D. Boneh, P. Golle, B. Pinkas", > The Design and Implementation of Protocol-Based Hidden > Key Recovery", 2003. _______________________________________________ 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
