Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

[Dan Wing <[e-mail]>]

On May 6, 2013, at 8:28 AM, Henry Lum <[e-mail]> wrote:

> To clarify, the case where contact center does not control an endpoint recording a call, recording would happen on a media bridge (a SIP B2BUA) in the contact center. Using DTLS-SRTP can prove that it is a media bridge from the contact center while SDES does not as you pointed out. 
> 
> Does EKT provide any benefit in this case?

No, EKT doesn't provide strong identity unless the SRTP keying provides strong identity (e.g., MIKEY-RSA, DTLS-SRTP).

-d


> 
> Henry
> 
> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: May-06-13 10:57 AM
> To: Henry Lum
> Cc: Harald Alvestrand; [e-mail]
> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> 
> 
> On May 6, 2013, at 7:30 AM, Henry Lum <[e-mail]> wrote:
> 
>> Chiming in late.
>> 
>> Speaking from a contact center perspective, a lot of calls are required to be recorded. In order to allow active recording (such as SIPREC), the contact center has to provide a media endpoint for bridging media so that a copy of the media can be created. The users will have to trust the contact center to handle the media anyways, and the media must be decrypted and re-encrypted by some media element within the contact center to perform recording. To me DTLS-SRTP-EKT does not provide any additional benefit over SDES for this type of use case.
> 
> Only DTLS-SRTP proves the call is actually to the call center (bank, stock broker, reservation company).  Security Descriptions cannot prove the call is actually to the call center.  That's a big difference in security to know the call is terminated at the call center (which does call recording or whatever it needs to do), versus trusting every SIP hop along the path to not record the media, not inject audio ("buy 100 shares" turned into "buy 100 thousand shares"), and to not lie about where media terminates.  Both can be recorded by the call center, which is one of the parties involved with the call.
> 
> -d
> 
> 
> 
>> 
>> Regards,
>> Henry 
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Dan Wing
>> Sent: April-26-13 9:57 AM
>> To: Harald Alvestrand
>> Cc: [e-mail]
>> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
>> 
>> 
>> On Apr 26, 2013, at 6:33 AM, Harald Alvestrand <[e-mail]> wrote:
>> 
>>> On 04/26/2013 03:16 PM, Tim Panton wrote:
>>>> 
>>>> On 26 Apr 2013, at 12:37, Iñaki Baz Castillo wrote:
>>>> 
>>>>> Such a solution requires a very expensive gateway. Good for vendors but bad for all the rest.
>>>>> 
>>>> 
>>>> I don't understand why the DTLS gateway would be so expensive. It is _exactly_ the same
>>>> (conceptually) as the ICE processing - you filter off a few UDP packets from the stream, do some
>>>> stuff, send replies then once you are happy you punt some dynamic settings back up to the (s)rtp
>>>> layer.
>>> 
>>> So you're saying that the gateway doesn't have to decrypt and re-encrypt the packets?
>> 
>> Correct - the gateway does not have to decrypt and re-encrypt the SRTP packets.  The gateway only has to interwork the signaling between SDES and DTLS-SRTP-EKT.  Such signaling interworking is necessary when the call is initially set up and when the SRTP key is changed (e.g., a new person joins a call using their own key, or the SRTP key is exhausted [pretty unlikely, even with video]).  This was summarized in http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
>> 
>> 
>>> 
>>> I think EKT may be a problem, as Inaki pointed out, but I have less qualms about supporting DTLS and making it optional to use EKT on some calls than I have about mandating support for SDES.
>> 
>> -d
>> 
>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
>