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

[Raj Jain <[e-mail]>]

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: [e-mail]
> To: [e-mail]
> CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: 24 October 2013 15:53
> > To: Hutton, Andrew
> > Cc: Derek Atkins; [e-mail]; [e-mail]; siprec-
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > 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" <[e-mail]> 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:[e-mail]]
> > >> Sent: 01 October 2013 16:34
> > >> To: [e-mail]; [e-mail]
> > >> Cc: [e-mail]; [e-mail];
> > >> [e-mail]; [e-mail]; 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
> > >>        [e-mail]             www.ihtfp.com
> > >>        Computer and Internet Security Consultant
> > >
> > >
> > 
> > --
> >        Derek Atkins                 617-623-3745
> >        [e-mail]             www.ihtfp.com
> >        Computer and Internet Security Consultant