[secdir] Secdir review of draft-ietf-sipping-service-identification-03

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 04 August 2009 04:06 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 15CA33A68B2; Mon, 3 Aug 2009 21:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id tpTBpV1wF5QV; Mon, 3 Aug 2009 21:06:43 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 5047B3A6F02; Mon, 3 Aug 2009 21:06:43 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAP9Qd0qrR7PD/2dsb2JhbAC8JYgpjxoFgjIBgWU
X-IronPort-AV: E=Sophos;i="4.43,318,1246838400"; d="scan'208";a="359785180"
Received: from sj-dkim-3.cisco.com ([]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 04:06:46 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com []) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7446k16018983; Mon, 3 Aug 2009 21:06:46 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com []) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7446jQ2028535; Tue, 4 Aug 2009 04:06:46 GMT
Received: from xmb-sjc-225.amer.cisco.com ([]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 21:06:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2009 21:06:44 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5087BD0CD@xmb-sjc-225.amer.cisco.com>
Thread-Topic: Secdir review of draft-ietf-sipping-service-identification-03
Thread-Index: AcoUuPrL24p3k07XRa6+EYrM2OnQvQ==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <secdir@ietf.org>, <sipping-chairs@tools.ietf.org>, <draft-ietf-sipping-service-identification@tools.ietf.org>, <iesg@ietf.org>, <gonzalo.camarillo@ericsson.com>
X-OriginalArrivalTime: 04 Aug 2009 04:06:45.0850 (UTC) FILETIME=[FB70EBA0:01CA14B8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1506; t=1249358806; x=1250222806; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Secdir=20review=20of=20draft-ietf-sipping-servi ce-identification-03 |Sender:=20; bh=b4+ehHvzCV0Hmd6AoKpfctzCtF8LhoIXlJA0UzTsmT0=; b=dOX7QlKDGO9pWU5c5SACfI8ALuzjxPG2o1iXtsiMnwHxXUw9SgzcsKM/Kb R5lxu2hLrViNmi1Qa03YlKhGIevmAFroj9Q0vtRoYFgNGxIqiDfcnzt2IZT3 bgrM9qyoqK;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Subject: [secdir] Secdir review of draft-ietf-sipping-service-identification-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 04 Aug 2009 04:06:44 -0000

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.

This document describes the reason why implicit service identification
is preferable of explicit service identification.  From a security point
of view I agree with this since explicit identification introduces a
mapping layer which can be a place where security vulnerabilities can
creep in.  I thought the security considerations were a bit light since
implicit identification still requires the participants to validate,
perhaps authenticate and authorize,  the signaling information that they
are using to identify the service.   The secure validation of SIP
signaling should be covered in other documents, perhaps a reference to
their security consideration should be included.  For example, the
document mentions that the URI can be a critical piece in determining
the service identity:  what document describes how to authenticate and
authorize this URI down to the level of granularity needed to
differentiate service identity?   I don't think it is necessary to
provide links to means for validating every possible piece of signaling
information, but links to the main mechanisms used in across different
scenarios would be good.