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

[David Mandelberg <[e-mail]>]

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.


-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/