On point #1, 3GPP 33.106 says under "Security of Processes": "NWOs/APs/SvPs shall not be responsible for decrypting, or ensuring the LEA's ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the NWOs/APs/SvPs and the NWOs/APs/SvPs possesses the information necessary to decrypt the communication or the NWOs/ APs/SvPs provides encryption keys but does not provide the encryption itself. In the case that the NWOs/ APs/SvPs provides encryption keys to the subscriber or customer but does not provide the encryption itself, the NWOs/ APs/SvPs shall provide the keys to the LEA if required by national regulations."
The same text is found in ETSI TISPAN TS 133 106. tim > -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 11, 2007 4: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. > > 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. > > 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. Another example would be [GBGP03]. > > 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. I don't > really see that this is really relevant to what happens in this > WG, though. > > -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 > _______________________________________________ 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
