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

From: David Mandelberg <[email-masked]>
Date: Sun, 14 Feb 2016 16:03:05 -0500

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Feb 2016 00:18:49 -0500

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.

> potential adversaries, but I don't think the draft says either of these

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 15 Feb 2016 15:31:32 +0000

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 <[email-masked]>
Date: Monday, 15 February 2016 at 10:48 AM
To: David Mandelberg <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: secdir review of draft-ietf-siprec-metadata-20
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>
Resent-Date: Monday, 15 February 2016 at 10:48 AM

---

From: David Mandelberg <[email-masked]>
Date: Wed, 17 Feb 2016 12:54:30 -0500

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

> 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

I agree. I'm worried only about malicious reuse of UUIDs.

---

From: David Mandelberg <[email-masked]>
Date: Wed, 17 Feb 2016 12:58:37 -0500

> the same UUID it MUST ensure a UUID is always mapped to same object across

It was clear to me that this was the intent. My question was about what
happens when a single malicious SRC violates this by introducing a new
object with an existing UUID. I don't think the draft specifies how the
SRS behaves in this case, nor does it say anything to prevent a
malicious SRC from being able to do this.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Feb 2016 13:23:20 -0500

David,

Comment at end.

> 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

---

From: David Mandelberg <[email-masked]>
Date: Sun, 21 Feb 2016 18:38:34 -0500

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?

> 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

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

> is that it is impossible to avoid problems from a party with access to

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2016 10:15:15 -0500

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