RE: [Sip] media-security-requirements and lawful intercept

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com] 
> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip