[secdir] sec-dir review of draft-ietf-siprec-architecture-08

Derek Atkins <derek@ihtfp.com> Tue, 01 October 2013 15:34 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABAC21E8153; Tue, 1 Oct 2013 08:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level:
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLweEfQifEyd; Tue, 1 Oct 2013 08:34:17 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8D21E8085; Tue, 1 Oct 2013 08:34:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 496F626029C; Tue, 1 Oct 2013 11:34:05 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11250-05; Tue, 1 Oct 2013 11:34:04 -0400 (EDT)
Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 0566B260299; Tue, 1 Oct 2013 11:34:04 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r91FXrT6009484; Tue, 1 Oct 2013 11:33:53 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Date: Tue, 01 Oct 2013 11:33:53 -0400
Message-ID: <sjmfvslt38e.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: krehor@cisco.com, andrew.hutton@siemens-enterprise.com, leon.portman@gmail.com, siprec-chairs@tools.ietf.org, rajnish.jain@outlook.com
Subject: [secdir] sec-dir review of draft-ietf-siprec-architecture-08
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: Tue, 01 Oct 2013 15:34:22 -0000

Hi,

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.

   Session recording is a critical requirement in many communications
   environments such as call centers and financial trading.  In some of
   these environments, all calls must be recorded for regulatory,
   compliance, and consumer protection reasons.  Recording of a session
   is typically performed by sending a copy of a media stream to a
   recording device.  This document describes architectures for
   deploying session recording solutions in an environment which is
   based on the Session Initiation Protocol (SIP).

Retrieving recorded media is a potential Key Management problem which
this document completely ignores (and even claims is out of scope).
The key used to encrypt the recorded media (whether or not the media
is re-encrypted) must be stored and retrieved as part of the media
retrieval.  How this important data is stored and retrieved is left
out, leaving an implementation with no guidance on how to protect that
valuable asset.  In fact the document completely elides the question
of how a retriever obtains the data encryption key.  Even if it's just
additional guidance the Security Considerations should at least
explain the problem even if it doesn't provide a solution.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant