[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
- [secdir] sec-dir review of draft-ietf-siprec-arch… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Hutton, Andrew
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Hutton, Andrew
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Raj Jain
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Hutton, Andrew
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Derek Atkins
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Hutton, Andrew
- Re: [secdir] sec-dir review of draft-ietf-siprec-… Hutton, Andrew