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

[Paul Kyzivat <[e-mail]>]

David,

Comment at end.

On 2/17/16 12:54 PM, David Mandelberg wrote:
> On 02/15/2016 12:18 AM, Paul Kyzivat wrote:
>> On 2/14/16 4:03 PM, David Mandelberg wrote:
>>> 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.
>
> Yes, but a malicious SRC probably won't do what you're expecting of a
> benign SRC. I agree that the text in the draft is good *if* it were true
> that all SRCs are benign.
>
>
>> If two SRCs use the same UUID it will be because they intentionally
>> choose to do so.
>
> Or because the malicious SRC is intentionally choosing to do so, without
> permission or cooperation from the benign SRC.
>
>> 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.
>
> I agree. I'm worried only about malicious reuse of UUIDs.

So your concern is the security implications when we have a malicious 
SRC that has been authorized by the SRS?

If so, it seems like that can extend to lots of things beyond reuse of 
UUIDs.

(Going further afield, how does this differ from a malicious SIP UA that 
has the credentials to register a particular AoR? It could cause all 
sorts of mischief by unregistering valid UAs, etc. ISTM the bottom line 
is that it is impossible to avoid problems from a party with access to 
enough "secrets".)

But the problem actually seems less severe in the case of SIPREC. The 
SRS is performing what is essentially an append-only write process. The 
use of a duplicate UUID by a malicious SRC doesn't cause any valid 
information to be lost. And the SRS is free to track the source of each 
piece of information it records, so that the malicious info can be 
sorted out from the valid info once the bad guy has been identified.

We don't put any requirements on *how* and *how much* of the the 
received info an SRS records, so we don't have a way to discuss this.

	Thanks,
	Paul