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

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 15 June 2015 18:48 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 38ACC1A1B98; Mon, 15 Jun 2015 11:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.11
X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_FROM_12LTRDOM=0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OJi-FyCcQCvo; Mon, 15 Jun 2015 11:48:53 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9B41A1B7B; Mon, 15 Jun 2015 11:48:53 -0700 (PDT)
Received: from in01.mta.xmission.com ([]) by out02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1Z4ZRD-0006fO-RM; Mon, 15 Jun 2015 12:48:51 -0600
Received: from [] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1Z4ZRD-0003sT-3F; Mon, 15 Jun 2015 12:48:51 -0600
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t5FImZM7006067; Mon, 15 Jun 2015 12:48:35 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t5FImZ8e006065; Mon, 15 Jun 2015 12:48:35 -0600
Date: Mon, 15 Jun 2015 12:48:35 -0600
Message-Id: <201506151848.t5FImZ8e006065@sylvester.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: secdir@ietf.org
X-XM-AID: U2FsdGVkX1+TFHRi/KofjOS6rM1N1dDl
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ******;secdir@ietf.org
X-Spam-Timing: total 428 ms - load_scoreonly_sql: 0.22 (0.1%), signal_user_changed: 6 (1.4%), b_tie_ro: 4.0 (0.9%), parse: 1.15 (0.3%), extract_message_metadata: 10 (2.4%), get_uri_detail_list: 1.94 (0.5%), tests_pri_-1000: 3.6 (0.8%), tests_pri_-950: 1.56 (0.4%), tests_pri_-900: 1.38 (0.3%), tests_pri_-400: 23 (5.4%), check_bayes: 21 (5.0%), b_tokenize: 6 (1.3%), b_tok_get_all: 6 (1.5%), b_comp_prob: 3.5 (0.8%), b_tok_touch_all: 3.1 (0.7%), b_finish: 1.07 (0.3%), tests_pri_0: 370 (86.7%), tests_pri_500: 6 (1.4%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/e8hj7sDQUiF1MEk9oNAeWzaTgdM>
Cc: iesg@ietf.org, draft-ietf-sipcore-6665-clarification@tools.ietf.org
Subject: [secdir] Security review of draft-ietf-sipcore-6665-clarification-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: <http://www.ietf.org/mail-archive/web/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: Mon, 15 Jun 2015 18:48:55 -0000

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

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.