Subject: [siprec] secDir review of draft-ietf-siprec-metadata

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 28 Feb 2016 18:51:52 +0000

Hello all,

There was a secDir review done by David Mandelberg. Attached is the email
for reference.

One of the comments from David is -

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

It is expected that If two SRCs use the same UUID  it MUST retain the
UUID/object mapping. However
a malicious SRC or a wrongly implemented SRC probably may end up in
mapping different objects to a same UUID and the draft needs to atleast
talk about this.

Towards this we propose to add the following text SIPREC metadata draft:

1) In security considerations we will add text that says that "the
procedures mentioned in security consideration section of protocol draft
MUST be implemented by SRS and SRC" which would take care of mutual
authentication of SRS and SRC thus covering the malicious SRC case that
David brought in his review.

2) In section 6.10 of SIPREC metadata we will add the below text to
identify that if SRS receives metadata that has same UUID mapping to
different objects it MUST treat that as a error.

<<EXISTING TEXT in last para of section 6.10>>:
The above mentioned unique-id mechanism SHOULD be used for each
   metadata element.  Multiple SRC's can refer to the same element/UUID
   (how each SRC learns the UUID here is out of scope of SIPREC)

<<NEW proposed text>>:
The above mentioned unique-id mechanism SHOULD be used for each
   metadata element.  Multiple SRC's can refer to the same element/UUID
   (how each SRC learns the UUID here is out of scope of SIPREC).

If two SRCs use the same UUID, it MUST retain the UUID/element mapping. If
the SRS
 detects that a UUID is mapped to more than one element at any point of
time it MUST treat this as a error. In general it is expected that a SRS
rejects or ignores the portions of metadata where it detects same UUID is
mapped to a different elements other than the expected element (the SRS
learns
 the mapped UUID when it sees a element for the first time in a metadata
instance).

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.

<<end>>

Please let us know your feedback on this proposed text.

Regards,
Ram

Subject: Re: secdir review of draft-ietf-siprec-metadata-20
From: David Mandelberg <[email-masked]>
To: Paul Kyzivat <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 21 Feb 2016 18:38:34 -0500
List-Id: <[email-masked]>

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/

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Feb 2016 16:20:44 -0500

>   the mapped UUID when it sees a element for the first time in a metadata

Ignoring is not the only safe strategy. Another reasonable one would be 
for the SRS to handle both, perhaps marking the recorded information as 
suspect. In most cases it could probably handle both by using a separate 
ID namespace for each element type. (I haven't checked the schema to 
check if there are any places where that won't work.)

In any case I'm not recommending any one strategy for handling the error 
- only noting that once the SRS recognizes that there is an error it 
should deal with it.

> acknowledged receipt of that object.

I'm concerned that this is a vague and may be unduly constraining. 
RFC4122 gives several alternative algorithms for generating UUIDs. Is 
this statement intended to forbid use of any of those? In general we 
should aim to be as forgiving as possible about the choice of algorithm. 
For one thing, some of the algorithms are more costly to execute than 
others. An SRC will need a lot of UUIDs, so it will have an interest in 
avoiding expensive algorithms.

In particular, "name-based" UUIDs are likely to be attractive. For 
instance they could allow two cooperating SSRCs to agree on an algorithm 
for generating UUIDs that would get the same result for a particular 
object in a particular call that they are both recording. Ant it is 
still safe if the "namespace-id" URL used in the computation is itself 
sufficiently random.

I'm not sure on the best way to resolve this. It could be to simply use 
some general words saying that the algorithm must to chosen so that the 
probability of accidental conflict is as low as if a truly random 
algorithm was used. Or we could go into detail regarding each of the 
algorithms in 4122, and qualify the use of each one.

	Thanks,
	Paul

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 29 Feb 2016 04:17:05 +0000

Hi Paul,

Please see inline

-----Original Message-----
From: siprec <[email-masked]> on behalf of Paul Kyzivat
<[email-masked]>
Date: Monday, 29 February 2016 at 2:50 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] secDir review of draft-ietf-siprec-metadata

>- only noting that once the SRS recognizes that there is an error it

Right. The above is just one action SRS can take and it is not the only
way for SRS handle error. That’s why I did not make it normative. Perhaps
I can re-word to:

For example, the SRS may choose to reject or ignore the portions of
metadata where it detects same UUID is
mapped to a different elements other than the expected element (the SRS
learns the mapped UUID when it sees a
 element for the first time in a metadata instance).

>algorithm was used.

I prefer this way other wise we are putting some restrictions on how SRC
should generate UUID.
Do you have some suggestions on how to word this ?

Ram

>Or we could go into detail regarding each of the

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 10:07:33 -0500

>   element for the first time in a metadata instance).

Yes, that would be ok.

> Do you have some suggestions on how to word this ?

Not beyond the above.

	Thanks,
	Paul

---

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

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Monday, 29 February 2016 at 8:37 PM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [siprec] secDir review of draft-ietf-siprec-metadata

>>Do you have some suggestions on how to word this ?

So I will add the below text. Is this fine ?

" The algorithm MUST to chosen so that the probability of accidental
conflict is as low as if a truly random algorithm was used.²

Ram

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 29 Feb 2016 22:24:36 +0530

Hi Ram/Paul,

The below statement is fine for me

" The algorithm MUST to chosen so that the probability of accidental
conflict is as low as if a truly random algorithm was used."

Regards
Partha

> From: siprec [mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Monday, February 29, 2016 8:48 PM
> To: Paul Kyzivat; [email-masked]