Re: [6lowapp] Security and Commissioning

"Don Sturek" <d.sturek@att.net> Sat, 31 October 2009 23:35 UTC

Return-Path: <d.sturek@att.net>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545A13A6843 for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.963
X-Spam-Level:
X-Spam-Status: No, score=0.963 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dB-Xl+ZBOwj for <6lowapp@core3.amsl.com>; Sat, 31 Oct 2009 16:35:45 -0700 (PDT)
Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 8D9A53A62C1 for <6lowapp@ietf.org>; Sat, 31 Oct 2009 16:35:45 -0700 (PDT)
Received: (qmail 29915 invoked from network); 31 Oct 2009 23:36:04 -0000
Received: from adsl-69-105-139-197.dsl.sndg02.pacbell.net (d.sturek@69.105.139.197 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 31 Oct 2009 16:36:03 -0700 PDT
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-YMail-OSG: dN1BHBUVM1nVtnqVnX5nzc.CozPw1IsinQCUqi9zWwAb797tgJhcpXttkTTto5FzNJPWTsgeIIjaD3lvjv0kh3HCvdQMXDgUTMrzcrpNJwGiZbhNpx_yhUaHU8N4bFIQOa.5qL8MfVUeIGQMYVF6NNXYUcq659ifA_1xXiWaxiIERaVGeQypoUrExaqrEQu5.IlCXFjRw4lgH3wu8LqdpD9HtxJrlgvvGiMAUCZu6CEeKZC9YRHHjgpo6YOOaUJc7P8dqEya9v57xg4D1xOdpQMqYoId8gzL9wXqBJwyBQk7gz1kRrs-
X-Yahoo-Newman-Property: ymail-3
From: "Don Sturek" <d.sturek@att.net>
To: "'Cullen Jennings'" <fluffy@cisco.com>, <6lowapp@ietf.org>
References: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com>
In-Reply-To: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com>
Date: Sat, 31 Oct 2009 16:35:59 -0700
Message-ID: <005b01ca5a82$e8039e40$b80adac0$@sturek@att.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcpaUFQz9HEYdQwWQIGysMJkw5NgeAAMmyIg
Content-Language: en-us
Subject: Re: [6lowapp] Security and Commissioning
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2009 23:35:46 -0000

Hi Cullen,

I think I could easily outline the options for this type of commissioning.
About half that I know of are patented.  

Is this really something 6LowAPP would address though?

Don

-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Cullen Jennings
Sent: Saturday, October 31, 2009 10:34 AM
To: 6lowapp@ietf.org
Subject: [6lowapp] Security and Commissioning


Consider one of the use cases several people have discussed. You  
install a new light. You install a new light switch. Now, how do you  
bind them together in the type of deployments where you want security?

One way or another we need to meet the requirements of BCP 61. For  
many BOFs, how they will BCP 61 is fairly obvious and no one worries  
about it. However, for this BOF, it is not obvious. To get to a WG, I  
think we need to have enough of a sketch of how we are going to do the  
security that we can convince the security folks that we are not  
insane and that we will be able to meet the requirements of BCP 61 in  
the protocols developed. This duckling imprint approach was a stawman  
approach to this but it may be totally  useless and not what we want  
to in which case we should promptly eject it from the charter.

The question is, what are we going to do? Ideas? Can someone sketch  
out at the back of a cocktail napkin level enough of an idea on the  
one or more ways we want to deal wit this? If we agree on that I can  
do my best to figure out how to get that into the charter in a way  
that convinces the security people that they don't have to show up and  
say No.


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp