[secdir] Secdir review of draft-ietf-geopriv-deref-protocol-04

Charlie Kaufman <charliek@microsoft.com> Thu, 26 January 2012 18:05 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13D021F86D9; Thu, 26 Jan 2012 10:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctjDX7UCG4CX; Thu, 26 Jan 2012 10:05:54 -0800 (PST)
Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9DF21F86D1; Thu, 26 Jan 2012 10:05:54 -0800 (PST)
Received: from mail164-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jan 2012 18:05:53 +0000
Received: from mail164-tx2 (localhost [127.0.0.1]) by mail164-tx2-R.bigfish.com (Postfix) with ESMTP id 66CC03E0202; Thu, 26 Jan 2012 18:05:53 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail164-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=charliek@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2 (MessageSwitch) id 1327601151763658_11246; Thu, 26 Jan 2012 18:05:51 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.254]) by mail164-tx2.bigfish.com (Postfix) with ESMTP id B6BCC80045; Thu, 26 Jan 2012 18:05:51 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jan 2012 18:05:49 +0000
Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.7]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Thu, 26 Jan 2012 10:05:41 -0800
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-geopriv-deref-protocol.all@tools.ietf.org" <draft-ietf-geopriv-deref-protocol.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-geopriv-deref-protocol-04
Thread-Index: AczcUlHhlR2Jyp4+QACa3zENEynQrQ==
Date: Thu, 26 Jan 2012 18:05:40 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B091241945C0D@TK5EX14MBXC117.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.79]
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091241945C0DTK5EX14MBXC117r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [secdir] Secdir review of draft-ietf-geopriv-deref-protocol-04
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: Thu, 26 Jan 2012 18:05:56 -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 specifies a relatively trivial extension to the HELD protocol to allow that protocol to be used to look up someone's (or something's) location. It's previous use was in connection with a device learning and/or setting its own location. It specifies an access control mechanism based on keeping location URIs secret and leaves open the possibility of alternate access control mechanisms being added in the future. It recommends use of TLS, but does not require it. The Security Considerations section addresses these issues well.

I see no security issues with this document.

I found no typos.

I have a few readability suggestions:

The document is not very free-standing, in that it would be difficult for someone outside the geopriv community to figure out what's going on in this document without reading some others first. It would be helpful if the introduction recommended some other RFC where such a context might be learned.

Section 3.3 paragraph 1 says: "This document does not describe a specific authentication mechanism. This means that authorization policies are unable to specifically identify authorized Location Recipients." As is clarified later in the section, what is really meant is that no mechanism for doing so is specified in this document. It is explicitly intended that such functionality be addable later without invalidating this document. In particular, paragraph 6 says: "Authentication of Location Recipients and use of identity-based authorization policy is not precluded." Clarifying that in the first paragraph would avoid confusion.

This last one is a real nit, but it bugged me...

Section 4.1 paragraph 3 says: "The LS MUST ignore any parameters that it does not understand unless it knows the parameters to be invalid". I would claim that you must understand something to know that it is invalid, and so would leave off the "unless" clause.