[secdir] Secdir Review of draft-ietf-paws-protocol-14

Catherine Meadows <catherine.meadows@nrl.navy.mil> Fri, 15 August 2014 20:51 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759721A06C7; Fri, 15 Aug 2014 13:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Level:
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6YSF3YAHzDm; Fri, 15 Aug 2014 13:51:34 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BB11A06C6; Fri, 15 Aug 2014 13:51:33 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s7FKpVYW011389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Aug 2014 16:51:31 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
In-Reply-To: <B31B07E4-92F3-4806-AF85-CBECE8B23AD4@nrl.navy.mil>
Date: Fri, 15 Aug 2014 16:51:31 -0400
Message-Id: <4C83FE05-DABB-40F1-A544-7E8FE54B2605@nrl.navy.mil>
References: <F1CC6599-05FB-4845-BA65-F5BDA1884399@nrl.navy.mil> <B31B07E4-92F3-4806-AF85-CBECE8B23AD4@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-paws-protocol.all@tools.ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7xT94Wly8xqKxfnATOVr5gcZbxw
Subject: [secdir] Secdir Review of draft-ietf-paws-protocol-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 15 Aug 2014 20:51:37 -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 ID describes a protocol, PAWS,  that allows wireless devices to access currently unused portions of the radio spectrum.
The protocol works between a geospatial database and a device with geolocation capabilities.  The device reports its location
and other relevant information to the database, which in turns gives it information about which portions of the spectrum is available to it.
This removes the responsibility for managing the complex information about spectrum available from the device and to the database,
which is better equipped to handle it.  I previously reviewed version 12 of this ID, and although some changes and additions have been made to the Security Considerations
section, they are minor and do not change my previous review, which ran as follows:

The ID has a very thorough and well-written Security Considerations section, which  covers the security threats against such a protocol.  They identify two
main threats

 By using the PAWSl, the Master Device and the Database expose
themselves to the following risks:

o Accuracy: The Master Device receives incorrect spectrum availability
information.
o Privacy: An unauthorized entity intercepts identifying data for
the Master Device or its Slave Devices, such as serial number and
location.

Note that core PAWS does not address client authentication, on the grounds that unauthorized clients could find out the existence of white
space on their own without the help of PAWS, and in that case there would be nothing preventing them from using it. The ID does point out though that client authentication may be required by specific regulatory domains,
and so it is possible for the Database to require client authentication, e.g. by TLS.  The authors appropriately point out the limitations of using TLS for authentication, particularly
when the keys are trusted to small ubiquitous devices.   

I believe this draft is ready.
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Jul 8, 2014, at 12:17 PM, Catherine Meadows <catherine.meadows@nrl.navy.mil>; wrote:

> I am resending this, because I got one of the email addresses wrong.
> 
> Cathy
> 
> 
> Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil
> 
> On Jul 8, 2014, at 12:10 PM, Catherine Meadows <catherine.meadows@nrl.navy.mil>; wrote:
> 
>> 
>> 
>> 
>> Catherine Meadows
>> Naval Research Laboratory
>> Code 5543
>> 4555 Overlook Ave., S.W.
>> Washington DC, 20375
>> phone: 202-767-3490
>> fax: 202-404-7942
>> email: catherine.meadows@nrl.navy.mil
>> 
>