$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
