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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Tue, 08 July 2014 16:10 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 960711B2B62; Tue, 8 Jul 2014 09:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7oh1eigVu2RO; Tue, 8 Jul 2014 09:10:39 -0700 (PDT)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C991A0104; Tue, 8 Jul 2014 09:10:38 -0700 (PDT)
Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil []) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s68GAaff018786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:10:37 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E"
Date: Tue, 08 Jul 2014 12:10:36 -0400
Message-Id: <F1CC6599-05FB-4845-BA65-F5BDA1884399@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-paws-protocol.all@tools.ietg.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
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/0Y1VTNvpVx8L7GIPXwVKgT3BLDQ
Subject: [secdir] Secdir Review of draft-ietf-paws-protocol
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: Tue, 08 Jul 2014 16:10:41 -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.  

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 PAWS protocol, the Master Device and the Database expose
themselves to the following risks:
o Accuracy: The Master Device receives incorrect spectrum availability
o Privacy: An unauthorized entity intercepts identifying data for
the Master Device or its Slave Devices, such as serial number and

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