Re: [smartpower-interest] Looking for references/pointers to security research on wireless ad-hoc networks

Hector <sant9442@gmail.com> Fri, 29 April 2011 17:18 UTC

Return-Path: <sant9442@gmail.com>
X-Original-To: smartpower-interest@ietfa.amsl.com
Delivered-To: smartpower-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14F8E06A1 for <smartpower-interest@ietfa.amsl.com>; Fri, 29 Apr 2011 10:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phx9W3hwkEM3 for <smartpower-interest@ietfa.amsl.com>; Fri, 29 Apr 2011 10:18:06 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0EE069F for <smartpower-interest@ietf.org>; Fri, 29 Apr 2011 10:18:05 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1686599gyf.31 for <smartpower-interest@ietf.org>; Fri, 29 Apr 2011 10:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cR7K5bq+DfzHxDjim0RJ6dzmkKJ+O6QuthI8VPbKuKs=; b=eC/cA82otYQaMT/WkAMvoMASltEoWEm7C6hobbCaT7qY9/rAE+/CIa9OS33XyWuAIm EW3RwxtIgzXBTkUKq3dOtHzIRDmr67LdDN72ApDzy8EB1nI9zpJJuKmrp/LH8dQiVSst o0Lnw1xzz1q61AOQpspnHkwvoaFpbiugNpn8c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=nLTb3wFlRpRbaCiJ5wK55DPcRXCmh7qkHp9bygzw2lrxBverlUzfwbmAANVjSL9ptO 8i6g4CFGB5gw+TK+GzYpncCIGdQIEeWXJsHZ2KIFHc5n8U97mpK4eaCM6NTVvmUBtN/V KTdPUf4toPLaUUP09h5yRIucswkRDsdp4+oGM=
Received: by 10.150.183.18 with SMTP id g18mr4250333ybf.396.1304097484016; Fri, 29 Apr 2011 10:18:04 -0700 (PDT)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net [99.3.147.93]) by mx.google.com with ESMTPS id w19sm282312ybe.25.2011.04.29.10.18.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 10:18:02 -0700 (PDT)
Message-ID: <4DBAF2F2.5040302@gmail.com>
Date: Fri, 29 Apr 2011 13:18:42 -0400
From: Hector <sant9442@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Greg Daley <gdaley@au.logicalis.com>
References: <C9DAEC3B.20B7C%bora@pnnl.gov> <C9DAEC7B.20B7F%bora@pnnl.gov> <8155FD1BB2ABCD40AC6F8149BBE997E0D783212430@sdcexchms.netstarnetworks.com>
In-Reply-To: <8155FD1BB2ABCD40AC6F8149BBE997E0D783212430@sdcexchms.netstarnetworks.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "smartpower-interest@ietf.org" <smartpower-interest@ietf.org>
Subject: Re: [smartpower-interest] Looking for references/pointers to security research on wireless ad-hoc networks
X-BeenThere: smartpower-interest@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Smart Power Interest <smartpower-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smartpower-interest>, <mailto:smartpower-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpower-interest>
List-Post: <mailto:smartpower-interest@ietf.org>
List-Help: <mailto:smartpower-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpower-interest>, <mailto:smartpower-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 17:18:11 -0000

Depending on what packet mechanism he can settle with, a RFC5322-based 
payload using self-signed DKIM signatures with ADSP exclusive 
self-signed policy declarations will work by first addressing fault 
detection (policy violations) requirement.  What remains is valid 
authenticated payloads.

The trust is another matter as you pointed out.  Strict DKIM has been 
remodeled for a minimum layered single identity trustconcept, abeit 
3rd party certification.

That's been the long central contentious issue in DKIM working group - 
POLICY vs TRUST.  My position is that you need both. Filter the 
violations first and that includes policies to exclude 3rd party 
signers or authorize them.  Extensions for ADSP has been written to 
support authorized signers.

Without having a central entity is some what more difficult (i.e. DNS, 
public key location, etc) requiring some P2P networking knowledge. 
"Something" has to be shared.  I can imagine if this is private 
network of devices, the vendor will be the central trust identity.

   DomainKeys Identified Mail (DKIM) Signatures
   RFC4871 http://tools.ietf.org/html/rfc4871

   DKIM Author Domain Signing Practices (ADSP)
   RFC5617 http://datatracker.ietf.org/doc/rfc5617/

   DKIM Authorized Third-Party Signers  (ADSP extension I-D)
   http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/

We are going to be using DKIM to assist in private mail networks 
first, external networking second with strong support for the 
deterministic nature of ADSP secured DKIM payloads.  This was outlined 
in my I-D:

   DKIM Signature Authorization Protocol (DSAP)
   http://tools.ietf.org/html/draft-santos-dkim-dsap-00

-- 
Hector Santos, CTO
http://www.santronics.com

Greg Daley wrote:
> Hi Akyol, 
> 
> This sort of issue associated with authorization without a central authority is similar to other works
> on peer-to-peer networking, without centralized authentication service.
> 
> The question is whether trust has been established previously (and we are recovering based on known 
> relationships) or trust has never been present.
> 
> In the second case, it may be impossible to establish trust because of the low cost associated with
> creation of fake identities on the wireless medium (Even with some sort of agreement protocol, it may
> be possible to overwhelm the network using the unfortunately named Sybil attack).
> 
> In the first case, it may be possible to establish the identity of a peer by establishing common trust using
> common trust relationships (back to a known source, perhaps using Certificates). 
> 
> Albeit this may be subject to attacks where the certified identity is compromised, and the existing connectivity
> to a CRL or online Certificate validity server (using for example OCSP) is overwhelmed.
> 
> Another approach is to provide authentication via existing connected nodes back to the centralized site, but
> using protections back to the central server.  I believe this may be covered by an independent submission
> that is still being discussed on the (concluded) PANA Working group  mailing list.
> 
> http://www.ietf.org/mail-archive/web/pana/current/maillist.html
> 
> Sincerely,
> 
> Greg Daley
> Consultant
> Logicalis Australia Pty Ltd
>   	 
> E: gdaley@au.logicalis.com
> M: +61 401 772 770
> P: +61 3 8532 4042
> F: +61 3 8532 4032
>  
> 
>> -----Original Message-----
>> From: smartpower-interest-bounces@ietf.org 
>> [mailto:smartpower-interest-bounces@ietf.org] On Behalf Of 
>> Akyol, Bora A
>> Sent: Tuesday, 26 April 2011 2:18 AM
>> To: smartpower-interest@ietf.org
>> Subject: [smartpower-interest] Looking for 
>> references/pointers to security research on wireless ad-hoc networks
>>
>>
>> Hi everyone.
>>
>> After doing the mandatory literature searches on IEEE, ACM 
>> and Google Scholar, I am looking to see if I have missed
>> any ongoing work at IETF regarding authorization and 
>> authentication of devices or software in wireless ad-hoc 
>> networks where
>> a centralized entity may not exist. Note that I am not 
>> looking for work on routing in MANET or encryption technologies.
>>
>> This is related to ongoing smart grid work that I am doing.
>>
>> Thank you very much for your help,
>>
>> --
>> Bora Akyol, Pacific Northwest National Laboratory
>> +1 509 371 6682, bora@pnnl.gov<mailto:bora@pnnl.gov>, www.pnnl.gov
>> _______________________________________________
>> smartpower-interest mailing list
>> smartpower-interest@ietf.org
>> https://www.ietf.org/mailman/listinfo/smartpower-interest
>>
> _______________________________________________
> smartpower-interest mailing list
> smartpower-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/smartpower-interest