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

["Ben Campbell" <[e-mail]>]

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

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

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.

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

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

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

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.