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

Derek Atkins <derek@ihtfp.com> Thu, 24 October 2013 14:54 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 4244211E8330; Thu, 24 Oct 2013 07:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hR9qYiOLGmx2; Thu, 24 Oct 2013 07:54:56 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 006DE11E833F; Thu, 24 Oct 2013 07:53:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A277F2602B8; Thu, 24 Oct 2013 10:53:33 -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 05712-05; Thu, 24 Oct 2013 10:53:31 -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 8E6BA260211; Thu, 24 Oct 2013 10:53:31 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r9OErRQo014022; Thu, 24 Oct 2013 10:53:27 -0400
From: Derek Atkins <derek@ihtfp.com>
To: "Hutton\, Andrew" <andrew.hutton@unify.com>
References: <sjmfvslt38e.fsf@mocana.ihtfp.org> <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net>
Date: Thu, 24 Oct 2013 10:53:26 -0400
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BF527F@MCHP04MSX.global-ad.net> (Andrew Hutton's message of "Wed, 16 Oct 2013 14:20:21 +0000")
Message-ID: <sjmsivqk9eh.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: "leon.portman@gmail.com" <leon.portman@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, "krehor@cisco.com" <krehor@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "siprec-chairs@tools.ietf.org" <siprec-chairs@tools.ietf.org>, "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 14:54:58 -0000

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