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

"Ben Campbell" <ben@nostrum.com> Thu, 25 June 2015 20:35 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC2C1AD066; Thu, 25 Jun 2015 13:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUO6U0vrC9D8; Thu, 25 Jun 2015 13:35:30 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7571AD062; Thu, 25 Jun 2015 13:35:30 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5PKZFD3086541 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 25 Jun 2015 15:35:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Hilarie Orman" <hilarie@purplestreak.com>
Date: Thu, 25 Jun 2015 15:35:14 -0500
Message-ID: <46F73FD7-A802-4D31-9407-5BB0BA410182@nostrum.com>
In-Reply-To: <201506151848.t5FImZ8e006065@sylvester.rhmr.com>
References: <201506151848.t5FImZ8e006065@sylvester.rhmr.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/mi-FzQH_nwTpDCSv8-5nCRIl990>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, iesg@ietf.org, draft-ietf-sipcore-6665-clarification@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-sipcore-6665-clarification-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 20:35:31 -0000

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.