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
- [6lowapp] Security and Commissioning Cullen Jennings
- Re: [6lowapp] Security and Commissioning Don Sturek
- Re: [6lowapp] Security and Commissioning Cullen Jennings