[secdir] Secdir review of draft-ietf-siprec-req
Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 16 April 2011 21:12 UTC
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 402EBE06E2 for <secdir@ietfc.amsl.com>; Sat, 16 Apr 2011 14:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.373
X-Spam-Level:
X-Spam-Status: No, score=-95.373 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXuW2CdwEJf7 for <secdir@ietfc.amsl.com>; Sat, 16 Apr 2011 14:12:21 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfc.amsl.com (Postfix) with ESMTP id 5C29EE06FE for <secdir@ietf.org>; Sat, 16 Apr 2011 14:12:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gsXz1Fh1g7niULKmVQAh8m3xTF8peMbMMDPyEtPPWgPynlmYlFjpx8IqLVdIzB370juM7fMhOeS7IVZZvOMZMrMfq+6hVwU5CFQgIxtpfiQlEYPpSe2dXJu+9RGDgGqE; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 24180 invoked from network); 16 Apr 2011 23:11:43 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Apr 2011 23:11:43 +0200
Message-ID: <4DAA0630.3020606@gondrom.org>
Date: Sat, 16 Apr 2011 22:12:16 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-siprec-req.all@tools.ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: rajnish.jain@ipc.com, leon.portman@nice.com, krehor@cisco.com, andrew.hutton@siemens-enterprise.com
Subject: [secdir] Secdir review of draft-ietf-siprec-req
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 16 Apr 2011 21:12:21 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. http://www.ietf.org/id/draft-ietf-siprec-req-09.txt The document is informational and describes use cases and requirements for SIP-based Media Recording. Overall I agree with the stated requirements in the document and consider the Privacy and Security Considerations sufficient. Privacy and Security sections could be enhanced by clarifying that the integrity and correctness of the recorded data is not ensured by (cryptographic) means to ensure that the CS has not been tampered with (also see below). At least AFAIK. This would have to be done by organizational and technical controls that prevent tampering with the recording UA and the data stream between end point UA and SRC. Best regards, Tobias Ps.: On a personal note a small suggestion/idea for the authors: - it seem the non-repudiation, authenticity and completeness (no dropped packets) of recorded CS linked to individual participants is basically unproven (if not impossible to prove in this setting?). I.e. an evil recording entity might twist incoming streams from participants to re-align given answers to different points in the stream or re-align its own statements. E.g. actual dialogue: 1. participant A "Do you want to buy this product?" 2. participant B: "No." 3. participant A "Do you want to abort this operation?" 4. participant B: "Yes." Could be twisted to: 1. participant A "Do you want to buy this product?" 4. participant B: "Yes." 3. participant A "Do you want to abort this operation?" 2. participant B: "No." or with only control of your own recorded data-stream: 3. participant A "Do you want to abort this operation?" 2. participant B: "No." 1. participant A "Do you want to buy this product?" 4. participant B: "Yes." I wonder whether authentication means (like signing) your session stream with a personal key and chronology integrity ensuring mechanisms (reliably linking messages to timestamps or previous messages from the other party) would be worth consideration and could prevent such an attack.
- [secdir] Secdir review of draft-ietf-siprec-req Tobias Gondrom
- Re: [secdir] Secdir review of draft-ietf-siprec-r… Leon Portman