Subject: [secdir] Security review of draft-ietf-sipcore-6665-clarification-00

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 15 Jun 2015 12:48:35 -0600

Security review of draft-ietf-sipcore-6665-clarification-00 
 A clarification on the use of Globally Routable User Agent URIs (GRUUs)
 in the Session Initiation Protocol (SIP) Event Notification Framework

Do not be alarmed.  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.

SIP is big, very big, and I've not even come close to reading all the
defining documents.  Thus, I'm on shaky ground here.  I believe that a
GRUU stands for a collection of contact handles for an individual,
and it is thus an identifier for a protocol entity.

The clarification addresses when to use GRUUs, and the answer is
something like "for all dialogs, unless the dialog is forbidden."
The clarification emphasizes that it applies to INVITE dialogs.

According to the text, implementers have not always used a GRUU
as a local target.  Is this deliberate or accidental?  Is there
some perceived advantage to avoiding GRUUs for INVITE?  If so,
can the clarification explain why it is a misconception?

I don't really understand why GRUUs are to be avoided for forbidden
dialogs.  Perhaps it is an optimization that would be obvious to
a skilled SIP implementor.

Beyond that, I am not at all sure about the effect of GRUUs on the
overall security of the protocol.  If they are used for all dialogs,
might that open the door to some sort of amplication attack?  Does
it allow some sort of probing that could widen the attack surface?
I would like to see a sentence or two in the security considerations
explaining why not.

An editorial comment about the text "... to allow you to send ...".
"You" is a confusing informality in a protocol description.  The
formal name of the role ("notifier"?) should be used.

Hilarie

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 25 Jun 2015 15:35:14 -0500

Hi,

I believe Adam is on vacation, or otherwise offline. Thus I will attempt 
a response, inline:

Thanks!

Ben.

On 15 Jun 2015, at 13:48, Hilarie Orman wrote:

[...]

>
> SIP is big, very big, ...

Yes. Yes, it is. :-)

> ... and I've not even come close to reading all the

I think it falls more to accidental in this particular case. That is, 
the original text in RFC 6665 was interpreted by some to only apply to 
SUBSCRIBE-created dialogs. That was not the intent.

> a skilled SIP implementor.

It's the other way around. It's not that GRUUs are to be avoided--it's 
that if the local contact for a dialog is _not_ a GRUU, then any request 
that might create a subscription to the dialog's state is forbidden.

> I would like to see a sentence or two in the security considerations

This draft does not change the intended use of GRUUs described in RFC 
6665. It's only purpose is to clarify that intent. Thus the security 
considerations already in RFC6665 should be sufficient. (If for some 
reason they are not sufficient, that's a different problem, and should 
be addressed separately from this draft.)

> formal name of the role ("notifier"?) should be used.

The "you" here doesn't refer to the notifier. It refers to any UA in the 
abstract. While a more formal construct might be "allow one to send" or 
even "allow SIP UAs to send", I'm inclined to leave it as is.