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

[Paul Kyzivat <[e-mail]>]

David,

Thank you for being so clear. I think I now understand your perspective. 
I would like to have a discussion about this with the other authors and 
the WG before coming back with a definitive response.

	Thanks,
	Paul

On 2/21/16 6:38 PM, David Mandelberg wrote:
> Responses to your points are below, but I think it might also help if
> I'm more clear about how I think this issue could be resolved. Here's
> one way that seems reasonable to me, but is not the only way to prevent
> the issue I brought up (unless I'm wrong and it's not an issue).
>
> Add text specifying that if an SRS receives more than one object defined
> with the same UUID, the SRS MUST reject (or ignore?) all but the first
> definition of the object. (This would ensure that UUIDs are actually
> unique on a per-SRS basis.) Also, specify that an SRC MUST use a random
> or pseudo-random method of generating UUIDs, and an SRC MUST NOT share
> an object's UUID with anybody other than the SRS until after the SRS has
> acknowledged receipt of that object. (This would ensure that the UUID
> generated by the SRC points to the correct object.)
>
> Would that work?
>
>
> On 02/17/2016 01:23 PM, Paul Kyzivat wrote:
>> So your concern is the security implications when we have a malicious
>> SRC that has been authorized by the SRS?
>
> Yes, but I didn't see anything in the draft saying that an SRC needs to
> be authorized by the SRS, just that the SRS needs to be authorized by
> the SRC. Maybe I missed that? Or maybe the Security Considerations could
> be made more clear about exactly who needs to authenticate to whom and
> who needs to make what authorization decisions based on that authentication?
>
>
>> If so, it seems like that can extend to lots of things beyond reuse of
>> UUIDs.
>
> The only issue I noticed was with the UUIDs. Otherwise it looks like an
> SRS could record metadata from any untrusted SRC without any security
> concerns other than the use of bandwidth, disk space, etc. (I could have
> missed something of course.)
>
>
>> (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".)
>
> I'm not a SIP expert, but I think it needs to be made clear which pieces
> of data are secrets in order to reason about the security of a system.
> At present, I don't see any indication that UUIDs are meant to be
> secrets. If they are supposed to be secrets, then I don't think they're
> adequately protected from attackers who can guess the output of a
> (potentially non-random) UUID generator.
>
>
>> 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.
>
> I don't see any mention of append-only writing in the draft, so I don't
> know how a server implementer would know to avoid overwriting of the
> object for a specific UUID, thus modifying the meaning of metadata that
> had previously been recorded from a different SRC.
>
>