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

["Ram Mohan R (rmohanr)" <[e-mail]>]

I agree with all of Paul's responses. One more point to add to Paul¹s
response-
1) If two SRCs use the same UUID  (because they intentionally
choose to do so ) it MUST retain the UUID/object mapping. In
other words, if UUID 1 was referring ³participant-1" object in RS1 by
SRC1, the same UUID1 can be used by other SRCs to only refer
Participant-1 and not any other objects.

If it was not clear from the draft we can add a line in draft to the
effect of - " If multiple SRCs use
the same UUID it MUST ensure a UUID is always mapped to same object across
all Recording Sessions".

Regards,
Ram



-----Original Message-----
From: Paul Kyzivat <[e-mail]>
Date: Monday, 15 February 2016 at 10:48 AM
To: David Mandelberg <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[e-mail]>,
"[e-mail]"
<[e-mail]>
Subject: Re: secdir review of draft-ietf-siprec-metadata-20
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>
Resent-Date: Monday, 15 February 2016 at 10:48 AM

>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
>