Re: [secdir] sec-dir review of draft-ietf-siprec-architecture-08
Raj Jain <rajnish.jain@outlook.com> Thu, 24 October 2013 17:51 UTC
Return-Path: <rajnish.jain@outlook.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 0816611E81DE; Thu, 24 Oct 2013 10:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 OOMTxwhxXOdk; Thu, 24 Oct 2013 10:51:24 -0700 (PDT)
Received: from bay0-omc3-s24.bay0.hotmail.com (bay0-omc3-s24.bay0.hotmail.com [65.54.190.162]) by ietfa.amsl.com (Postfix) with ESMTP id 66CED11E8370; Thu, 24 Oct 2013 10:47:46 -0700 (PDT)
Received: from BAY168-W92 ([65.54.190.189]) by bay0-omc3-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 10:47:46 -0700
X-TMN: [nlQ8V74ZHZq03v1J9GLaGnCqeHlGOWRd]
X-Originating-Email: [rajnish.jain@outlook.com]
Message-ID: <BAY168-W92B7D41F5864087CDA48979B0C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_4e700fd4-c116-462d-9386-aa3881da5d52_"
From: Raj Jain <rajnish.jain@outlook.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, Derek Atkins <derek@ihtfp.com>
Date: Thu, 24 Oct 2013 13:47:45 -0400
Importance: Normal
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net>
References: <sjmfvslt38e.fsf@mocana.ihtfp.org>, <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net>, <sjmsivqk9eh.fsf@mocana.ihtfp.org>, <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Oct 2013 17:47:46.0279 (UTC) FILETIME=[25EC5F70:01CED0E1]
X-Mailman-Approved-At: Thu, 24 Oct 2013 10:57:28 -0700
Cc: Leon Portman <leon.portman@gmail.com>, "krehor@cisco.com" <krehor@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "siprec-chairs@tools.ietf.org" <siprec-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Thu, 24 Oct 2013 17:52:22 -0000
I think Andy's approach to addressing this is appropriate. The way recording systems deal with the security issues of archived media content seems out of scope of SIPREC. A statement can be made to clarify this the way Andy is proposing. > From: andrew.hutton@unify.com > To: derek@ihtfp.com > CC: iesg@ietf.org; secdir@ietf.org; siprec-chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; leon.portman@gmail.com > Subject: RE: sec-dir review of draft-ietf-siprec-architecture-08 > Date: Thu, 24 Oct 2013 15:36:57 +0000 > > Hi Derek, > > I am ok with putting something in the security considerations to say the key management requirements for storage and retrieval is something that the recording system will need to consider but I would still say that saying anything more than that is out of scope. > > What do others think? > > Andy > > > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: 24 October 2013 15:53 > > To: Hutton, Andrew > > Cc: Derek Atkins; iesg@ietf.org; secdir@ietf.org; siprec- > > chairs@tools.ietf.org; krehor@cisco.com; rajnish.jain@outlook.com; > > leon.portman@gmail.com > > Subject: Re: sec-dir review of draft-ietf-siprec-architecture-08 > > > > Hi Andrew, > > > > Sorry for the delay in responding. > > > > I personally feel that there is a big difference between the > > interactive, real-time SIP components versus a service that is > > specifically designed to record and replay content later. The key > > management of the real-time components is all immediate, there is no > > storage required, once the keys get to the endpoints you're done and > > all > > you do is transmit encrypted content. > > > > However a storage system has significantly different requirements. It > > has to store the keys that protect the content, and it must store those > > keys securely. It then has to be able to securely distribute those > > keys > > only to authorized receipients. > > > > So yes, I think it is important to talk about at least the requirements > > for what the recording agent MUST do, even if you don't necessarily > > specify HOW the agent must do it. E.g. I think it's okay to say > > something like "the stored content must be protected using a cipher at > > least as strong (or stronger) than the original content" -- i.e., you > > don't need to specify "you MUST use AES-256". Yet I still think you > > need to talk about the key management requirements of the storage (and > > more importantly retrieval). > > > > Thanks, > > > > -derek > > > > "Hutton, Andrew" <andrew.hutton@unify.com> writes: > > > > > Hi Derek, > > > > > > Thanks for your comment and sorry for taking a while to get back to > > you. > > > > > > The security considerations section contains the following text: > > > > > > " It is the responsibility of the Session Recording Server to protect > > > the Replicated Media and Recording Metadata once it has been > > received > > > and archived. The mechanism for protecting the storage and > > retrieval > > > from the SRS is out of scope of this work." > > > > > > > > > Personally I think this is reasonable as we never say anything in SIP > > > related specifications what a UA should do with the media once it has > > > been received and this work is all about delivering the media and > > > related metadata to the recording system not what it does with it > > > afterwards. > > > > > > Is it really necessary to go any further than this? > > > > > > Regards > > > Andy (SIPREC Co-Chair). > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Derek Atkins [mailto:derek@ihtfp.com] > > >> Sent: 01 October 2013 16:34 > > >> To: iesg@ietf.org; secdir@ietf.org > > >> Cc: siprec-chairs@tools.ietf.org; krehor@cisco.com; > > >> rajnish.jain@outlook.com; leon.portman@gmail.com; Hutton, Andrew > > >> Subject: sec-dir review of draft-ietf-siprec-architecture-08 > > >> > > >> 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 > > > > > > > > > > -- > > 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