[secdir] Security Directorate early review comments (from Paul Hoffman)

Sumanth Channabasappa <sumanth@cablelabs.com> Tue, 21 August 2012 16:31 UTC

Return-Path: <sumanth@cablelabs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1163921F87B7; Tue, 21 Aug 2012 09:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VWOaH6JEZL6m; Tue, 21 Aug 2012 09:31:52 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com []) by ietfa.amsl.com (Postfix) with ESMTP id 73B0521F87B6; Tue, 21 Aug 2012 09:31:49 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl []) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q7LGVlZG020740; Tue, 21 Aug 2012 10:31:48 -0600
Received: from srvxchg.cablelabs.com ( by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 21 Aug 2012 10:31:47 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([]) by srvxchg ([]) with mapi; Tue, 21 Aug 2012 10:31:48 -0600
From: Sumanth Channabasappa <sumanth@cablelabs.com>
To: "Drinks@ietf.org" <Drinks@ietf.org>
Date: Tue, 21 Aug 2012 10:31:45 -0600
Thread-Topic: Security Directorate early review comments (from Paul Hoffman)
Thread-Index: Ac1/unXInveEUfdeQQi+APx35OQepA==
Message-ID: <CC591411.11BB3%sumanth@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CC59141111BB3sumanthcablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
X-Mailman-Approved-At: Fri, 24 Aug 2012 05:44:28 -0700
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Security Directorate early review comments (from Paul Hoffman)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <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, 21 Aug 2012 16:31:53 -0000

WG Participants,

As you know we requested an early review from the security directorate, the apps area, and a couple of other external reviewers on the two I-Ds that are currently I last call.

I am forwarding the comments from Paul Hoffman (on behalf of the security directorate) since he is not on the mailing list. Please include him on your responses.

- S

-- From Paul Hoffman

Greetings. I have been requested to review draft-ietf-drinks-spp-framework for the Security Directorate. This review is being done during WG Last Call instead of IETF Last Call as a special request. I note that literally no one has spoken up in the WG during WG Last Call since it began three weeks ago.

SPPF is a protocol for provisioning session establishment data into data registries and SIP service providers. Well, actually it's not. It is a description of the data format and some handwaving about how to transport that data. The mandatory-to-implement transport is listed in a different document, draft-ietf-drinks-spp-protocol-over-soap (for which there is no reference in this document...).

The transport protocol requirements listed in section 4 of this document are fairly generic, as are the security requirements. The descriptions of the transport requirements are fine. The security requirements are not so great: while servers MUST be able to authenticate clients, confidentiality and integrity protection SHOULD be provided. Given that the mandatory-to implement transport is SOAP, this approximately translates to "must do some sort or minimal client authentication, should consider using TLS but lots of clients and servers probably won't actually do it". I think that undershoots moderns security practices, which would have TLS be mandatory.

Even though this is a security review, I cannot resist a non-security question: SOAP? In 2012? Really? <sigh>