[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] media-security-requirements and lawful intercept
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:ekr at networkresonance.com]
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip