Last Call Review of draft-ietf-siprec-metadata-20
review-ietf-siprec-metadata-20-secdir-lc-mandelberg-2016-02-17-00

Request Review of draft-ietf-siprec-metadata
Requested rev. no specific revision (document currently at 22)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-02-22
Requested 2016-02-11
Authors Ram R, Parthasarathi Ravindran, Paul Kyzivat
Draft last updated 2016-02-17
Completed reviews Secdir Last Call review of -20 by David Mandelberg (diff)
Assignment Reviewer David Mandelberg 
State Completed
Review review-ietf-siprec-metadata-20-secdir-lc-mandelberg-2016-02-17
Reviewed rev. 20 (document currently at 22)
Review result Has Issues
Review completed: 2016-02-17

Review
review-ietf-siprec-metadata-20-secdir-lc-mandelberg-2016-02-17

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.

This document specifies a metadata format for information about recorded
SIP sessions. The Security Considerations section has good text about
the protection of metadata in this format, but I found one potential
security issue with the way an SRS (server) is supposed to handle the
metadata. I think this draft is ready with issues.

Section 6.10 says that "multiple SRC's [clients] can refer to the same
element/UUID (how each SRC learns the UUID here is out of scope of
SIPREC)". But what happens if two clients try to define different
objects with the same UUID? Does one of the objects take precedence for
all clients? If all of the benign clients are relying on referencing an
object A with UUID 1, and a malicious client is able to send an object B
also with UUID 1, that might compromise the integrity of the metadata
sent by the benign clients. This could be mitigated by requiring that
UUIDs are generated (pseudo-)randomly and are kept confidential from
potential adversaries, but I don't think the draft says either of these
things.

-- 
David Eric Mandelberg / dseomn


http://david.mandelberg.org/






Attachment:


signature.asc




Description:

 OpenPGP digital signature