Skip to main content

Last Call Review of draft-ietf-siprec-architecture-08
review-ietf-siprec-architecture-08-secdir-lc-atkins-2013-10-03-00

Request Review of draft-ietf-siprec-architecture
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-10-01
Requested 2013-09-19
Authors Andrew Hutton , Leon Portman , Rajnish Jain , Ken Rehor
I-D last updated 2013-10-03
Completed reviews Genart Last Call review of -08 by Russ Housley (diff)
Genart Telechat review of -11 by Russ Housley (diff)
Secdir Last Call review of -08 by Derek Atkins (diff)
Assignment Reviewer Derek Atkins
State Completed
Request Last Call review on draft-ietf-siprec-architecture by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 12)
Result Has issues
Completed 2013-10-03
review-ietf-siprec-architecture-08-secdir-lc-atkins-2013-10-03-00
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 at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant