Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)

Pete Resnick <presnick@qti.qualcomm.com> Wed, 20 August 2014 21:03 UTC

Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16211A6F55; Wed, 20 Aug 2014 14:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.669
X-Spam-Level:
X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 nv6lB98nCPw6; Wed, 20 Aug 2014 14:03:45 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98861A6EF1; Wed, 20 Aug 2014 14:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408568625; x=1440104625; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WfLyjZzjr8ITtUxxJtNYgYOT+7cFClBGHpAbBGJFOlw=; b=O60E83Q31CwK8nEAULQ2kGN5cCQqVpSEvE/lsbwy3DaE1TZ6b9yPu/fe cF/3Dji2EQPGmG/WnvGWUzl0EudjOabjcX3dfnSkW9e3I0tGTOnNG0lfN 7OiDyYFKQx6vHmKZTDuN/nzWchn10B6wn31b72AxlW5UN+2j2UaTy8geP A=;
X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59388815"
Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2014 14:03:44 -0700
X-IronPort-AV: E=Sophos;i="5.01,904,1400050800"; d="scan'208";a="31119459"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 14:03:43 -0700
Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:03:43 -0700
Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:03:42 -0700
Message-ID: <53F50D2D.2010203@qti.qualcomm.com>
Date: Wed, 20 Aug 2014 16:03:41 -0500
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com>
In-Reply-To: <20140820203127.25270.64032.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/bZz70gPi9bLQ_KqTEo5ZlOkUDOw
Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG <iesg@ietf.org>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 21:03:48 -0000

On 8/20/14 3:31 PM, Kathleen Moriarty wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> [...]
> Can clients query any database entries or is the interface restricted to
> the list of supported interactions?   I assume the answer is that it is
> limited to the set of database interactions defined, but could not find
> any statement saying that in this draft or the prior requirements in
> RFC6953.
>    

I'm not sure exactly what you mean here. Are you asking whether the 
client or server ask for/send back more than the minimum data? Sure, 
that's what the "*other" business is about. Or are you asking whether 
additional queries/responses can be defined? I suppose they could. But 
I'm not sure what you're asking, or what the concern is. Can you elaborate?

> Authentication is only a MAY in the Security Considerations Section,
> which raises another possible concern for me.
>
> Since clients can get back pretty much all of the defined datatypes
> (DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the 
server in the request so that the client can match the response to the 
query.

> and authentication is not required,
> there should be a discussion on the risks of revealing this information
> for both the privacy reasons Stephen and Alissa outlined as well as
> possible security concerns.  I think this should be on a field basis in
> terms of sensitive elements where relevant.
>    

The rest of the responses are the publicly available spectrum 
information. I'm not seeing sensitive data there.

> I could see how you might want/need the types of information gathered
> within an administrative domain or accessed by a restricted set of users,
> but revealing data like what is contained in deviceDescriptor (includes
> model) as well as sensitive fields in other classes
> (AntennaCharacteristics) seems like a risk as it could be used in
> targeted attacks if there are known vulnerabilities to those devices.
> The attacks could target specific regions at specific times to effect
> events or to be used as part of some larger attack (could include
> physical).  This may sound crazy, but layered attacks are very real.
>    

This seems like it would be a problem for sniffing unencrypted data 
*from* another client, but I'm not getting how this sort of attack works 
by a client owned by the attacker querying the database.

Before I get back to the rest of your query, help me understand this far.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478