[secdir] review of draft-ietf-martini-reqs-07.txt

"Hilarie Orman" <ho@alum.mit.edu> Tue, 22 June 2010 01:47 UTC

Return-Path: <hilarie@purplestreak.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 59BE43A691A for <secdir@core3.amsl.com>; Mon, 21 Jun 2010 18:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.772
X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id VPZpAaKZV5Bc for <secdir@core3.amsl.com>; Mon, 21 Jun 2010 18:47:07 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by core3.amsl.com (Postfix) with ESMTP id AAA4F3A6835 for <secdir@ietf.org>; Mon, 21 Jun 2010 18:47:06 -0700 (PDT)
Received: from mx03.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1OQsZz-00010d-BZ; Mon, 21 Jun 2010 19:47:11 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1OQsZw-0002dT-OY; Mon, 21 Jun 2010 19:47:10 -0600
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o5M1mfiB006862; Mon, 21 Jun 2010 19:48:41 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o5M1mdgA006857; Mon, 21 Jun 2010 19:48:39 -0600
Date: Mon, 21 Jun 2010 19:48:39 -0600
Message-Id: <201006220148.o5M1mdgA006857@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: Hilarie Orman <ho@alum.mit.edu>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: ; sa07 0; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;secdir@ietf.org
X-Spam-Relay-Country: _RELAYCOUNTRY_
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com)
Cc: Bernard_Aboba@hotmail.com, gonzalo.camarillo@ericsson.com, hkaplan@acmepacket.com, spencer@wonderhamster.org, john.elwell@siemens-enterprise.com, rjsparks@nostrum.com
Subject: [secdir] review of draft-ietf-martini-reqs-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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, 22 Jun 2010 01:47:18 -0000

Security review of draft-ietf-martini-reqs-07.txt,
Multiple AOR reachability in SIP 

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

The abstract:
 This document states requirements for a standardized SIP registration
 mechanism for multiple addresses of record, the mechanism being
 suitable for deployment by SIP service providers on a large scale in
 support of small to medium sized Private Branch Exchanges (PBXs).
 The requirements are for a solution that can, as a minimum, support
 AORs based on E.164 numbers.

There are 21 requirements, and two of them address security.

I think requirement 14 leaves out a couple of things:
  REQ14 - The mechanism MUST be able to operate over a transport that
  provides integrity protection and confidentiality.
It should probably require "end-to-end" integrity protection and
confidentiality between the two entities (SIP-PBX and the SSP).

And I think requirement 15 should say something about how the two
entites are expected to agree on an authentication method, and that
the authentication should apply to every registration message
exchanged by the entities.  That is, once they have authenticated,
then that information should be tied to requirement 14 and ensure that
the integrity and/or confidentiality is defined between the two
entities (by use of, for example, an authenticated key exchange
protocol) on all subsequent messages between the two.  
   REQ15 - The mechanism MUST support authentication of the SIP-PBX by
   the SSP and vice versa.
I'd also add that it MUST support termination of authenticaton and

Minor non-security things:

Requirement 4 has a triple negative ("not" "prevent" "without"), and
I'm not sure what the heck it means.

Requirement 5 has a typo, probably "internally" for "internal".