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

["Hutton, Andrew" <[e-mail]>]

Sounds good will use your text.

Thanks
Andy

> -----Original Message-----
> From: Derek Atkins [mailto:[e-mail]]
> Sent: 01 November 2013 13:57
> 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,
> 
> "Hutton, Andrew" <[e-mail]> writes:
> 
> > Hi Derek,
> >
> >
> > Would the following change in the security considerations section
> > resolve your issue:
> >
> >
> > "It is the responsibility of the SRS 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"
> >
> > To
> >
> > "It is the responsibility of the SRS to protect the Replicated Media
> > and Recording Metadata once it has been received and archived. The
> > stored content must be protected using a cipher at least as strong
> (or
> > stronger) than the original content however the mechanism for
> > protecting the storage and retrieval from the SRS is out of scope of
> > this work"
> 
> This is a good start.  Could you also add something like:
> 
>   The keys used to store the data must also be securely maintained by
>   the SRS and should only be released, securely, to authorized parties.
>   How to secure these keys, properly authorize a receiving party, or
>   securely distribute the keying material is out of scope of this work
> 
> > Regards
> > Andy
> 
> -derek
> 
> >> -----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
> >
> >
> 
> --
>        Derek Atkins                 617-623-3745
>        [e-mail]             www.ihtfp.com
>        Computer and Internet Security Consultant