Thanks for your review. -d > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Eric Rescorla > Sent: Sunday, February 15, 2009 8:59 AM > To: sipping@xxxxxxxx; secdir@xxxxxxxx; > draft-wing-sipping-srtp-key@xxxxxxxxxxxxxx > Subject: (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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
