Re: [secdir] [Sipping] draft-wing-sipping-srtp-key

["Dan Wing" <[e-mail]>]

Thanks for your review.

-d
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Eric Rescorla
> Sent: Sunday, February 15, 2009 8:59 AM
> To: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: [Sipping] (no subject)
> 
> $Id: draft-wing-sipping-srtp-key-04-rev.txt,v 1.2 2009/02/15 
> 15:41:29 ekr Exp $
> 
> 
> End-to-end VoIP security mechanisms such as DTLS-SRTP represent a
> threat to mechanisms in which a network element which is not a party
> to the call wishes to monitor or modify the contents of the media
> traffic. This document describes a mechanism for one of the parties
> to the communication to provide a copy of the keying material
> to such a third party subject to some set of authorization
> controls. 
> 
> I'm concerned that this document doesn't have a very clear
> statement of requirements. Rather, it seems to be attempting
> to fulfill a number of distinct use cases which don't have
> much in common except that they represent violations of the
> end-to-end security model of the SIP call.
> 
> This document describes two major use cases for this type of
> technology:
> 
> - Monitoring (call recording)
> - Transcoding
> 
> I don't think it's particularly useful to conflate these cases, which
> are really quite different. Monitoring is fundamentally a passive
> process: there is no need for the monitor to be able to modify the
> traffic. By contrast, transcoding is an active process: the transcoder
> is expected to modify the data. In reality, a transcoded call isn't
> a call between two endpoints, but rather two calls, each from one
> endpoint to the transcoder. I think it's a mistake to try do to
> these with the same mechanism. 
> 
> Similarly, this document fails to distinguish adequately between
> real-time and non-real-time use cases. Many monitoring/call recording
> applications are inherently non-real-time: you record the call
> and some time in the future, the call may or may not be replayed.
> This distinction has a number of implications, particularly since
> capture of the keying material and media can be separated. In
> particular, it may be desirable to deliver the keying 
> material long after
> the call has finished (for privacy reasons). It's not clear
> to me how this is accomplished with this draft. It's possible
> it could be initiated by the UA, but I don't see how it could
> be initiated by the monitor. Even in a UA initiated fashion,
> I don't see that the information provided by the SDP in S 11
> is sufficient to unambiguously identify the flow, in part
> due to network parameter reuse.
> 
> While I appreciate it's convenient to reuse the SDP parameters,
> it's not clear to me that it's a good idea to hand over the SRTP
> master key. If all you need to do is verify the call for 
> quality assurance, you don't need the integrity check, at
> least not initially. In fact, not having access to the integrity
> key protects against accusations that the recording device
> tampered. Similarly, it's not clear to me that it's desirable
> to have the same level of protection for the connection parameters
> as for the keys. Wouldn't it be useful for the monitoring application
> to know what connections it *potentially* has the keys for 
> but not have direct access to them until some future time?
> Again, this seems like something that would be more clear with
> a requirements analysis in terms of privacy requirements.
> 
> Finally, the elephant under the covers here is lawful intercept.
> the authors specifically disclaim it, but it's quite clear that 
> this is usable as an LI system. Indeed, many such systems
> (e.g., FORTEZZA) involve cooperation from the endpoint being
> monitored. 
> 
> Accordingly, I would recommend that rather than accepting this
> mechanism as a WG document, the WG do a thorough requirements
> analysis focusing on minimizing the privacy issues inherent in
> mechanisms of this type. Once there is consensus on the requirements,
> then it's possible to have a discussion of mechanisms.
> 
> 
> DETAILED COMMENTS
> 4.3.
> If the requirement for recording is this strong, wouldn't it
> be better not to rely on the UA doing the right thing? Rather
> enforce it in a firewall or IDS.
> 
> 7.2.2.
>    The signature of the SAML assertion should be produced using the
>    private key of the domain certificate.  This certificate 
> MUST have a
>    SubjAltName which matches the domain of user agent's SIP 
> proxy (that
>    is, if the SIP proxy is sip.example.com, the SubjAltName of the
>    domain certificate signing this SAML assertion MUST also be
>    example.com).  Here, the main focus is placed on communication of
>    clients with the ESC, which belongs to the client's home domain.
> 
> It's not clear to me why this is the correct authorizing certificate.
> 
> 
> 7.2.3.
> I don't really understand the need for the rcrypto thing.
> Why not just pretend you have two streams with distinct
> keys and use crypto= for both.
> 
> Actually, I don't really think it makes sense to use SDP
> here at all: the semantics of the SDP really aren't the same,
> since you're not offering to receive a media stream,
> you're advertising what you're going to send. 
> 
> As noted above, I think it would be better to send the
> traffic keys separately.
> 
> 7.2.4.
> This whole SAML thing seems pretty underspecified.
> 
> I don't think using SIPS here is adequate, since it doesn't
> provide any guarantee to the endpoint of the security treatment
> of the keying material. In fact, as I noted earlier, I'm not clear
> that S/MIME is good enough. I think you may want something
> multilevel.
> 
> 
> 9.3.
> This Disclosure thing seems a bit confusing. Isn't what you
> really need to inject the appropriate warnings in the media
> plane.
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP