[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 []) 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-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 ([]) by localhost (ietfc.amsl.com []) (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 []) 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) ( 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: 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.


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.