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

"Dan Wing" <dwing@cisco.com> Mon, 16 February 2009 22:47 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ED83A689D; Mon, 16 Feb 2009 14:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuRe38mbripT; Mon, 16 Feb 2009 14:47:48 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B2FB23A6838; Mon, 16 Feb 2009 14:47:47 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,218,1233532800"; d="scan'208";a="250652739"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2009 22:47:58 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1GMlwiA007006; Mon, 16 Feb 2009 14:47:58 -0800
Received: from dwingwxp01 ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1GMlvR4001416; Mon, 16 Feb 2009 22:47:57 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Eric Rescorla'" <ekr@networkresonance.com>
References: <20090215165929.EEB8C50822@romeo.rtfm.com>
Date: Mon, 16 Feb 2009 14:47:57 -0800
Message-ID: <02cd01c99088$9d1d87c0$c2f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20090215165929.EEB8C50822@romeo.rtfm.com>
Thread-Index: AcmPi6BWsER1VqurSGGf2lj+chKElwA/O4XA
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6387; t=1234824478; x=1235688478; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[Sipping]=20draft-wing-sipping-srtp-key |Sender:=20; bh=V9Xxe9sZ4SoKPmIAH93btvkWFwv1rACDXzR4AQJdKow=; b=czhsed5Lzbm9t9hsCHhkekVXQpAvHv4l0iSOqvwys3ZaQ3ZaQDnIgPeHcR PhVBhoLm83eGfRdKJwnx194K8KKWfUuumigsOmIWF0t/aWLYvXCbY7pyVZdW SbJcciz7/q;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Mailman-Approved-At: Tue, 17 Feb 2009 07:21:44 -0800
Cc: draft-wing-sipping-srtp-key@tools.ietf.org, sipping@ietf.org, secdir@ietf.org
Subject: Re: [secdir] [Sipping] draft-wing-sipping-srtp-key
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2009 22:47:49 -0000

Thanks for your review.

-d
 

> -----Original Message-----
> From: sipping-bounces@ietf.org 
> [mailto:sipping-bounces@ietf.org] On Behalf Of Eric Rescorla
> Sent: Sunday, February 15, 2009 8:59 AM
> To: sipping@ietf.org; secdir@ietf.org; 
> draft-wing-sipping-srtp-key@tools.ietf.org
> 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP