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

"Hutton, Andrew" <andrew.hutton@unify.com> Thu, 24 October 2013 15:38 UTC

Return-Path: <andrew.hutton@unify.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 B962611E8342; Thu, 24 Oct 2013 08:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 fGGyKxMZfYDQ; Thu, 24 Oct 2013 08:38:00 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id EA43E11E8357; Thu, 24 Oct 2013 08:36:59 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9EE0923F0482; Thu, 24 Oct 2013 17:36:57 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 17:36:57 +0200
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Derek Atkins <derek@ihtfp.com>
Thread-Topic: sec-dir review of draft-ietf-siprec-architecture-08
Thread-Index: AQHO0MjSFpuNNNCQs06E2FZPbdmFCZoD+qYw
Date: Thu, 24 Oct 2013 15:36:57 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C078BD@MCHP04MSX.global-ad.net>
References: <sjmfvslt38e.fsf@mocana.ihtfp.org> <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> <sjmsivqk9eh.fsf@mocana.ihtfp.org>
In-Reply-To: <sjmsivqk9eh.fsf@mocana.ihtfp.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "siprec-chairs@tools.ietf.org" <siprec-chairs@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "krehor@cisco.com" <krehor@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "leon.portman@gmail.com" <leon.portman@gmail.com>, "rajnish.jain@outlook.com" <rajnish.jain@outlook.com>
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 15:38:04 -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