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

[Catherine Meadows <[e-mail]>]

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: [phone]
fax: [phone]
email: [e-mail]

On Jul 8, 2014, at 12:17 PM, Catherine Meadows <[e-mail]> 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: [phone]
> fax: [phone]
> email: [e-mail]
> 
> On Jul 8, 2014, at 12:10 PM, Catherine Meadows <[e-mail]> wrote:
> 
>> 
>> 
>> 
>> Catherine Meadows
>> Naval Research Laboratory
>> Code 5543
>> 4555 Overlook Ave., S.W.
>> Washington DC, 20375
>> phone: [phone]
>> fax: [phone]
>> email: [e-mail]
>> 
>