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
