Re: [secdir] secdir review of draft-ietf-siprec-metadata-20

[Paul Kyzivat <[e-mail]>]

David,

Thank you for the review. I will try to respond. (Note that I haven't 
consulted with the other authors on this response, so they may have 
something else to say.) Please see inline below.

On 2/14/16 4:03 PM, David Mandelberg wrote:
> 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.

The UUIDs used in the metadata are intended to be *unique*. Distinct 
SRCs that construct new UUIDs are expected to follow the rules for 
constructing them so that they are indeed unique.

If two SRCs use the same UUID it will be because they intentionally 
choose to do so. Typically this will be by some back channel to 
communicate among themselves. (I suppose there could potentially be some 
algorithmic way for them to construct UUIDs in a coordinated way, but I 
won't speculate on that.)

By design there should be no accidental reuse of UUIDs.

	Thanks,
	Paul