Last Call Review of draft-ietf-siprec-metadata-20
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
David Eric Mandelberg / dseomn
OpenPGP digital signature