From nobody Tue Mar 18 10:45:28 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8401A0714; Tue, 18 Mar 2014 10:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 A1PHpw376puS; Tue, 18 Mar 2014 10:42:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B25D1A0296; Tue, 18 Mar 2014 10:42:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140318174258.31032.64242.idtracker@ietfa.amsl.com> Date: Tue, 18 Mar 2014 10:42:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/w51fr-NejSr9JKb-aM9VEoLyza4 X-Mailman-Approved-At: Tue, 18 Mar 2014 10:45:26 -0700 Cc: watteyne@eecs.berkeley.edu, pthubert@cisco.com, 6tisch-security@ietf.org Subject: [6tisch-security] New Non-WG Mailing List: 6tisch-security -- Extended Design Team for 6TiSCH security architecture X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:43:04 -0000 A new IETF non-working group email list has been created. List address: 6tisch-security@ietf.org Archive: http://www.ietf.org/mail-archive/web/6tisch-security/ To subscribe: https://www.ietf.org/mailman/listinfo/6tisch-security Purpose: This is a limited list that is used to support talks on 6TiSCH security architecture by Design Team members and extended Consulting Team. For additional information, please contact the list administrators. From nobody Thu Mar 20 06:52:19 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0D1A0740 for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.428, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 p-icnFFAoEhU for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 06:52:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C71AB1A06CF for <6tisch-security@ietf.org>; Thu, 20 Mar 2014 06:52:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ACF4120038 for <6tisch-security@ietf.org>; Thu, 20 Mar 2014 11:11:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 632B963AB2; Thu, 20 Mar 2014 09:51:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B21E63A9E for <6tisch-security@ietf.org>; Thu, 20 Mar 2014 09:51:58 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/oWs2kaC9ueyHJtnbGkL4PFi_PYk Subject: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:52:14 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= I want to start the discussion with Jonathan's message. I'd like some clear opinions about whether you want to do layer-2 provisioning using a protocol which is common with the application target (i.e. CoAP over DTLS). Or whether one wants to use a layer-2 specification which is already to some extend (ZigbeeIP) "out there" -- but which may have significant code impact. Some would like to see 1x rather than PANA as the layer-2.5. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=21 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.21) for (single-drop); Mon, 17 Mar 2014 17:41:10 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.2.13-Debian-2.2.13-19+squeeze3) with LMTPA; Mon, 17 Mar 2014 15:37:48 -0400 X-Sieve: CMU Sieve 2.2 Received: from colo4.roaringpenguin.com (colo4.roaringpenguin.com [174.142.115.36]) by tuna.sandelman.ca (Postfix) with ESMTPS id 88D7C2004E for ; Mon, 17 Mar 2014 15:37:48 -0400 (EDT) Received: from p02c12o145.mxlogic.net (p02c12o145.mxlogic.net [208.65.145.78]) by colo4.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id s2HIIR5M010767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Mar 2014 14:18:28 -0400 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 47c37235.2b4df1047940.19493.00-560.54845.p02c12o145.mxlogic.net (envelope-from ); Mon, 17 Mar 2014 12:18:28 -0600 (MDT) X-MXL-Hash: 53273c747c6e1403-93161fb19c3b32a9a2fb24c75cdbbb89996b4bf3 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id e5c37235.0.19291.00-378.54194.p02c12o145.mxlogic.net (envelope-from ); Mon, 17 Mar 2014 12:18:13 -0600 (MDT) X-MXL-Hash: 53273c650617a201-e190e1400e098cea82b6f450ef121362f1ed76c0 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 780B7740A5; Mon, 17 Mar 2014 11:18:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B4B631B-0107-4B29-9D4B-7EF52071E888" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: 2014-03-17: 6tisch security call From: Jonathan Simon In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272150A1@TGXML210.toshiba.local> Date: Mon, 17 Mar 2014 11:19:45 -0700 Cc: pthubert@cisco.com, Thomas Watteyne , Michael Richardson , rstruik.ext@gmail.com, tom.phinney@cox.net, pwetterw@cisco.com, maseewal@cisco.com, subirdas21@gmail.com, mbehring@cisco.com, paduffy@cisco.com, peppe@giuseppepiro.com, ncamwing@cisco.com, hmauldin@cisco.com Message-Id: References: <531DD632.2060009@cox.net> <531DDB20.5050600@gmail.com> <10925.1394631496@sandelman.ca> <532069C8.2050005@gmail.com> <23590.1394999032@sandelman.ca> <7BF67230-59CB-4691-B7A2-5C138C4733E4@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272150A1@TGXML210.toshiba.local> To: yoshihiro.ohba@toshiba.co.jp X-Mailer: Apple Mail (2.1874) X-AnalysisOut: [v=2.0 cv=Z/tb6gtA c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=6TPyDe91o6QA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=AUd_NHdVAAAA:8 a=fky-FVc1BcHmNdLykr4A:9 a=2c] X-AnalysisOut: [XsEN-qxLoA:10 a=19wCD08tTksA:10 a=vsVyj9psLt0A:10 a=w2H99W] X-AnalysisOut: [I3CKEA:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0YA:10 a=N7QUBrEu1A] X-AnalysisOut: [EA:10 a=xLpt9-x9cSEA:10 a=JfD0Fch1gWkA:10 a=wMGJFJGXEWgA:1] X-AnalysisOut: [0 a=o3V4ypo77vFU_lBT:21 a=ttSLr53X78j4g4wr:21 a=5XW15KfRyN] X-AnalysisOut: [NQ2pOqWvoA:9 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=YFt-ZLz] X-AnalysisOut: [lLI8A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014031709); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-Spam-Score: 0.00 () [Hold at 5.00] HTML_MESSAGE:0.001,SPF(none:0),DKIM(none:0) X-CanIt-Geo: ip=208.65.145.78; country=US; region=Colorado; city=Englewood; latitude=39.6237; longitude=-104.8738; http://maps.google.com/maps?q=39.6237,-104.8738&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-customers:default,base:default) X-Canit-Stats-ID: 02LCGisg1 - 4d3c401552d7 - 20140317 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?i=02LCGisg1&m=4d3c401552d7&t=20140317&c=f X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?i=02LCGisg1&m=4d3c401552d7&t=20140317&c=n X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?i=02LCGisg1&m=4d3c401552d7&t=20140317&c=s X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg X-Scanned-By: CanIt (www . roaringpenguin . com) on 174.142.115.36 --Apple-Mail=_6B4B631B-0107-4B29-9D4B-7EF52071E888 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb18030 WirelessHART does not have a separate provisioning network. It does have = two separate endpoint secure transport sessions - one for network = management (PCE) that is set up immediately, and a separate one for = data. The data session can be delayed until the joining device is = checked against an access control list or blacklist - this is referred = to as =A1=B0quarantine=A1=B1 in the HART spec. HART also uses a = =A1=B0proxy=A1=B1 node to handle routing, since the joining node lacks = route information when it joins. To join, the new node synchronizes to = a beacon, then sends in information about itself and discovered = neighbors, encrypted with its shared key. The manager decrypts this and = sends a response including a runtime session key, again encrypted with = the shared key. They then switch to using the session security. I had envisioned something similar for centrally managed in 6TiSCH, but = with PK. The beaconing node would proxy the PCE certificate. Joining = nodes would get the certificate at L2, and check it against a vendor or = site cert (a la M. Behringer), and then send in an L4 join request = encrypted with the PCEs public key. The PCE would respond with runtime = session info, encrypted with the node=A1=AFs public key. Using a = highly elided X509 cert (only has key and signature), this exchange = takes 2 messages in the upstream direction, and 2 L2 messages to get the = PCE=A1=AFs cert.=20 --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 30695 Huntwood Ave Hayward, CA 94544-7021 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION**=20 *****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2936, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you.=20 On Mar 17, 2014, at 10:40 AM, yoshihiro.ohba@toshiba.co.jp wrote: > Does WirelessHART model requires a separate provisioning network? If = so, it can be a deployment issue. > =20 > I do agree that Rene=810=843=810=854s bottom up approach is needed to = fully understand the problem space, and I would like to contribute to = such efforts. > =20 > Yoshihiro Ohba > =20 > =20 > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Tuesday, March 18, 2014 12:28 AM > To: Thomas Watteyne > Cc: Michael Richardson; Rene Struik; Tom Phinney; Patrick Wetterwald = (pwetterw); Maik Seewald (maseewal); Subir Das; ohba = yoshihiro(=810=857=A8=AE=810=B73=1A =1Ax=810=885=A8=AE = =810=843=810=8A8=810=845=810=886=810=845=810=872=810=845=810=871=810=843=81= 0=8B1=810=845=810=882=810=845=810=887=810=845=810=880); Michael = Behringer (mbehring); Jonathan Simon (jsimon@linear.com); Paul Duffy = (paduffy); Giuseppe Piro; Nancy Cam-Winget (ncamwing); Hank Mauldin = (hmauldin) > Subject: RE: 2014-03-17: 6tisch security call > =20 > Hello Thomas: > =20 > I do agree with the desire to stick to simple model ala WirelessHART. = At the same time, some flows will have to be mapped to IETF, and = Michael=810=843=810=854s flow 2 at the 6TiSCH meeting was about mapping = to RPL flows. > I was indicating that mapping onto to the necessary ND registration = flows would save round trips and be a better match than RPL. > In any fashion, I tend to agree with Ren=A1=A7=810=847 that the bottom = up approach in solution space is good work but not sufficient. > Seems to me that we have not yet figured the whole problem space, = usage scenarios, and requirements from scalability and constrained = devices/ medium. > This needs to be documented somewhere, together with the support in = existing standards as examples on how things can be done with which = expected security properties and hardware requirements. > =20 > Cheers, > =20 > Pascal > =20 > From: Thomas Watteyne [mailto:twatteyne@linear.com]=20 > Sent: dimanche 16 mars 2014 23:17 > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; Rene Struik; Tom Phinney; Patrick Wetterwald = (pwetterw); Maik Seewald (maseewal); Subir Das; Yoshihiro Ohba = (yoshihiro.ohba@toshiba.co.jp); Michael Behringer (mbehring); Jonathan = Simon (jsimon@linear.com); Paul Duffy (paduffy); Giuseppe Piro; Nancy = Cam-Winget (ncamwing) > Subject: Re: 2014-03-17: 6tisch security call > =20 > Thanks a millin for coordinating this effort Michael. The schedule = works for me. > =20 > I believe we now have very clear options (thanks for presenting those = in London).=20 > =20 > I strongly believe in the simplicity as very well proven track record = of the WirelessHART approach. Let's keep it as simple as possible and = not introduce dependencies on RPL and/or ND. Looking forward to hearing = more about your private discussions, and discussing this next Monday. > =20 > Hello from SFO. > =20 > Thomas >=20 > On Sunday, March 16, 2014, Pascal Thubert (pthubert) = wrote: > Works for me! >=20 > Thanks Michael (adding Nancy) >=20 > Pascal >=20 > > Le 16 mars 2014 =A1=A7=A1=E8 20:44, "Michael Richardson" = a =A1=A7=810=847crit : > > > > > > 1) I've asked the IETF secretariat for a mailing list for 6tisch = security > > discussion. > > There are perhaps people on this CC who are missing. > > > > 2) is there a liason to 802.15.9 among us? I understand that 15.9 = has > > renewed vigor, and is on it's way to define a 1x mechanism over = 15.4*. > > I think that this may be preferable to PANA, so I'd like to hear = more. > > > > 3) Pascal and I have discussed a way initialize the = WirelessHART-like > > mechanism using efficient-ND rather than RPL DIO, and this needs > > to be researched and written up. > > > > 4) my understanding is that the IEEE 802.1AR vendor certificates are > > being very successfully deployed by VoIP providers. This is a = real > > and live mechanism, supported by a number of PKI suppliers. My > > understanding is that this will be the right size for most = industrial > > uses, but simply will not work at the home level. That's okay, = 6tisch > > is not targetted initially a unmanaged homes. > > > > =3D=3D=3D=3D > > > > I'd like to cancel the 2014-03-17 call, and do a call on the 24th, = and > > then April 7th, 14th. The 21st is a holiday for many, so we skip = that. > > By the 21st, I'd like to have a document that, while it may have > > controversial and/or undecided pieces, the pieces should be = understood by > > all. By the 28th, I'd like to have a discussion to resolve = whatever > > issues may still exist. > > > > How does this work? > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting for hire =3D- > > > > > > >=20 >=20 > -- > Thomas Watteyne, Ph. D > Sr. Networking Design Engineer > Linear Technology, Dust Networks Product Group > 30695 Huntwood Ave > Hayward, CA 94544-7021 > +1 (510) 400-2978 > twatteyne@linear.com > =20 > This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2978, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you. --Apple-Mail=_6B4B631B-0107-4B29-9D4B-7EF52071E888 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb18030 WirelessHART does not have a separate provisioning = network. It does have two separate endpoint secure transport sessions - = one for network management (PCE) that is set up immediately, and a = separate one for data.  The data session can be delayed until the = joining device is checked against an access control list or blacklist - = this is referred to as =A1=B0quarantine=A1=B1 in the HART spec.   = HART also uses a =A1=B0proxy=A1=B1 node to handle routing, since the = joining node lacks route information when it joins.  To join, the = new node synchronizes to a beacon, then sends in information about = itself and discovered neighbors, encrypted with its shared key. =  The manager decrypts this and sends a response including a runtime = session key, again encrypted with the shared key. They then switch to = using the session security.

I had envisioned = something similar for centrally managed in 6TiSCH, but with PK. =  The beaconing node would proxy the PCE certificate. Joining nodes = would get the certificate at L2, and check it against a vendor or site = cert (a la M. Behringer), and then send in an L4 join request encrypted = with the PCEs public key. The PCE would respond with runtime session = info, encrypted with the node=A1=AFs public key.   Using a highly = elided X509 cert (only has key and signature), this exchange takes 2 = messages in the upstream direction, and 2 L2 messages to get the PCE=A1=AF= s cert. 

-- 
Jonathan Simon, Ph. D
Director of = Systems Engineering
Linear Technology, Dust Networks product = group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) = 400-2936
(510) 489-3799 FAX
jsimon@linear.com

**LINEAR = TECHNOLOGY CORPORATION** 
*****Internet Email = Confidentiality Notice***** 
 This e-mail = transmission, and any documents, files or previous = e-mail messages attached to it may contain confidential = information that is legally privileged. If you are not = the intended recipient, or a person responsible for delivering = it to the intended recipient, you are hereby notified that any = disclosure, copying, distribution or use of any of = the information contained in or attached to this transmission = is STRICTLY PROHIBITED. If you have received this transmission = in error, please immediately notify me by reply e-mail, or by = telephone at (510) 400-2936, and destroy the original transmission = and its attachments without reading or saving in any manner. = Thank you. 

On Mar 17, 2014, at 10:40 AM, yoshihiro.ohba@toshiba.co.jp<= /a> wrote:

Does WirelessHART model requires a separate provisioning = network?  If so, it can be a deployment = issue.
 
I do agree = that Rene=810=843=810=854s bottom up approach is needed to fully = understand the problem space, and I would like to contribute to such = efforts.
 
Yoshihiro = Ohba
 
 
From: Pascal Thubert (pthubert) = [mailto:pthubert@cisco.com] 
Sent: Tuesday, March 18, 2014 = 12:28 AM
To: Thomas = Watteyne
Cc: Michael Richardson; Rene = Struik; Tom Phinney; Patrick Wetterwald (pwetterw); Maik Seewald = (maseewal); Subir Das; ohba yoshihiro(=810=857=A8=AE=810=B73=1A =1Ax=810=885=A8=AE =810=843=810=8A8=810=845=810=886=810=845=810=872=810=845=810=871=810=843=810=8B1=810=845=810=882=810=845=810=887=810=845=810=880); Michael Behringer (mbehring); Jonathan Simon (jsimon@linear.com); Paul Duffy = (paduffy); Giuseppe Piro; Nancy Cam-Winget (ncamwing); Hank Mauldin = (hmauldin)
Subject: RE: 2014-03-17: 6tisch = security call
 
Hello = Thomas:
 
I do agree = with the desire to stick to simple model ala WirelessHART. At the same = time, some flows will have to be mapped to IETF, and Michael=810=843=810=85= 4s flow 2 at the 6TiSCH meeting was about mapping to RPL = flows.
I was indicating that mapping onto = to the necessary ND registration flows would save round trips and be a = better match than RPL.
In any fashion, I tend to = agree with Ren=A1=A7=810=847 that the bottom up approach in solution = space is good work but not sufficient.
Seems to me = that we have not yet figured the whole problem space, usage scenarios, = and  requirements from scalability and constrained devices/ = medium.
This needs to be documented = somewhere, together with the support in existing standards as examples = on how things can be done with which expected security properties and = hardware requirements.
 
Cheers,
 
Pascal
 
From: Thomas Watteyne [mailto:twatteyne@linear.com] 
Sent: dimanche 16 mars 2014 = 23:17
To: Pascal Thubert = (pthubert)
Cc: Michael Richardson; Rene = Struik; Tom Phinney; Patrick Wetterwald (pwetterw); Maik Seewald = (maseewal); Subir Das; Yoshihiro Ohba (yoshihiro.ohba@toshiba.co.jp); Michael = Behringer (mbehring); Jonathan Simon (jsimon@linear.com); Paul Duffy (paduffy); Giuseppe Piro; = Nancy Cam-Winget (ncamwing)
Subject: Re: 2014-03-17: 6tisch = security call
 
Thanks a millin for coordinating this = effort Michael. The schedule works for = me.
 
I believe we now have very clear options = (thanks for presenting those in = London). 
 
I strongly believe in = the simplicity as very well proven track record of the = WirelessHART approach. Let's keep it as simple as possible and not = introduce dependencies on RPL and/or ND. Looking forward to hearing more = about your private discussions, and discussing this next = Monday.
 
Hello from = SFO.
 
Thomas

On Sunday, March 16, 2014, = Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:
Works for me!

Thanks Michael (adding = Nancy)

Pascal

> Le 16 mars 2014 =A1=A7=A1=E8 20:44, = "Michael Richardson" <mcr+ietf@sandelman.ca> a =A1=A7=810=847crit = :
>
>
> 1) I've asked the IETF secretariat for a = mailing list for 6tisch security
>   discussion.
> =   There are perhaps people on this CC who are = missing.
>
> 2) is there a liason to 802.15.9 among us? =  I understand that 15.9 has
>   renewed vigor, and is on = it's way to define a 1x mechanism over 15.4*.
>   I think = that this may be preferable to PANA, so I'd like to hear = more.
>
> 3) Pascal and I have discussed a way initialize = the WirelessHART-like
>   mechanism using efficient-ND rather = than RPL DIO, and this needs
>   to be researched and written = up.
>
> 4) my understanding is that the IEEE 802.1AR vendor = certificates are
>   being very successfully deployed by VoIP = providers.  This is a real
>   and live mechanism, = supported by a number of PKI suppliers.  My
>   = understanding is that this will be the right size for most = industrial
>   uses, but simply will not work at the home = level. That's okay, 6tisch
>   is not targetted initially a = unmanaged homes.
>
> =3D=3D=3D=3D
>
> I'd like = to cancel the 2014-03-17 call, and do a call on the 24th, and
> = then April 7th, 14th. The 21st is a holiday for many, so we skip = that.
> By the 21st, I'd like to have a document that, while it = may have
> controversial and/or undecided pieces, the pieces = should be understood by
> all.   By the 28th, I'd like to = have a discussion to resolve whatever
> issues may still = exist.
>
> How does this work?
>
> --
> = Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software = Works
> -=3D IPv6 IoT consulting for hire = =3D-
>
>
>


--
Thomas Watteyne, Ph. = D
Sr. Networking Design = Engineer
Linear Technology, Dust Networks Product = Group
30695 Huntwood Ave
Hayward, CA = 94544-7021
+1 (510) = 400-2978
 
This e-mail = transmission, and any documents, files or previous e-mail messages = attached to it may contain confidential information that is legally = privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2978, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank = you.

= --Apple-Mail=_6B4B631B-0107-4B29-9D4B-7EF52071E888-- --=-=-= -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyryfoqHRg3pndX9AQLh8QP/YrfI2WlR9KRhbqJx91RaHJpGTVyotBIW C3lrdQEIf115ftxUoeeCXCLodcJdP3/TScWf7uRbycGCRF/ZYIDCsmSh5EZwt+MY sgfCd0yZPsj0KVUb0ItwdAoHEcfYSTCTiQx48c+TE/h+8kKD6iN1yi/NzPClYOGC WC8g+M4Yirs= =OmT9 -----END PGP SIGNATURE----- --==-=-=-- From nobody Thu Mar 20 09:13:39 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC621A075E for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 06:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 DkVDUG1xqOpm for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 06:55:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 124271A0740 for <6tisch-security@ietf.org>; Thu, 20 Mar 2014 06:55:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DA6BD20038; Thu, 20 Mar 2014 11:14:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EA92763AB2; Thu, 20 Mar 2014 09:55:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D640F63A9E; Thu, 20 Mar 2014 09:55:31 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org, yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272152A2@TGXML210.toshiba.local> References: <531DD632.2060009@cox.net> <531DDB20.5050600@gmail.com> <10925.1394631496@sandelman.ca> <532069C8.2050005@gmail.com> <23590.1394999032@sandelman.ca> <7BF67230-59CB-4691-B7A2-5C138C4733E4@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272150A1@TGXML210.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B272152A2@TGXML210.toshiba.local> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/XWaUwZEJcBw270WImosL2F0lx4M X-Mailman-Approved-At: Thu, 20 Mar 2014 09:13:36 -0700 Cc: pthubert@cisco.com, paduffy@cisco.com, peppe@giuseppepiro.com, rstruik.ext@gmail.com, pwetterw@cisco.com, maseewal@cisco.com, hmauldin@cisco.com, twatteyne@linear.com, tom.phinney@cox.net, mbehring@cisco.com, ncamwing@cisco.com, jsimon@linear.com, subirdas21@gmail.com Subject: Re: [6tisch-security] 2014-03-17: 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 6tisch-security@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:55:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable wrote: > If a separate provisioning network is not used and a =E2=80=9Cproxy= =E2=80=9D is used for > unauthenticated nodes instead of end-to-end routing to carry > authentication > traffic to a central server, it seems WirelessHART model is the same = as > ZigBee > IP model besides authentication protocols used for the two models. Or > am I missing something? I don't understand the comparsion. Are you talking about the trust model? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting for hire =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyrzU4qHRg3pndX9AQJJEAQA3AvekiQdZFLstN1+/gNuEgoSRFtHUygu HClsKPo0hzs5irNTDotK/DTEnyQ2eccFJCnxkjk4aJzld8R4QTlbkJROnQvjmrRl Fr+yiu3uCdHrnjs4mQXn1AM4E/YeWOpIZNe9EvPcJILFJk5vhqLWMpmyneimIIdR 5MBxJwqQpQo= =l1bO -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 20 09:13:41 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD4D1A08E7 for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 07:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 SxdcU-ATa3ZZ for <6tisch-security@ietfa.amsl.com>; Thu, 20 Mar 2014 07:09:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 318A21A08EA for <6tisch-security@ietf.org>; Thu, 20 Mar 2014 07:08:58 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B7DE20038; Thu, 20 Mar 2014 11:28:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F11A663AB2; Thu, 20 Mar 2014 10:08:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DC5DF63A9E; Thu, 20 Mar 2014 10:08:48 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org, yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B27215737@TGXML210.toshiba.local> References: <531DD632.2060009@cox.net> <531DDB20.5050600@gmail.com> <10925.1394631496@sandelman.ca> <532069C8.2050005@gmail.com> <23590.1394999032@sandelman.ca> <7BF67230-59CB-4691-B7A2-5C138C4733E4@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272150A1@TGXML210.toshiba.local> <25459.1395151153@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B27215737@TGXML210.toshiba.local> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/SXmd752PLZyN79fPlp96nAjNFP4 X-Mailman-Approved-At: Thu, 20 Mar 2014 09:13:36 -0700 Cc: pthubert@cisco.com, paduffy@cisco.com, peppe@giuseppepiro.com, rstruik.ext@gmail.com, pwetterw@cisco.com, maseewal@cisco.com, hmauldin@cisco.com, twatteyne@linear.com, tom.phinney@cox.net, mbehring@cisco.com, ncamwing@cisco.com, jsimon@linear.com, subirdas21@gmail.com Subject: Re: [6tisch-security] 2014-03-17: 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: 6tisch-security@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:09:07 -0000 --=-=-= wrote: > I meant by "separate" to use a PAN-ID different from that is used for > the network where provisioned node will join. Yes, from the point of L2 ID, the join network is separate. > wrote: >> Does WirelessHART model requires a separate provisioning network? If >> so, it can be a deployment issue. > Define "separate" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUyr2cIqHRg3pndX9AQJDIgQAiUOhdZAPJaYljd7V2HbH0xdHzV7xfxtV 6DnUIm7XlsAuAzamltbU7qyWNK8fgCypfu+G0N7icHgXeaa5fJacCNM7g9a7mj4Z NjCa/SROs219YIO5OpDctYadW/B2opWVxqzLnzIW5iqascS+U3zXJKfv3BxiSgjm 2/1GSCsDaGk= =da9O -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 20 10:58:37 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653C1A07C1; Thu, 20 Mar 2014 10:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 qDBgxEQN_vUQ; Thu, 20 Mar 2014 10:58:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF41A08D3; Thu, 20 Mar 2014 10:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1550; q=dns/txt; s=iport; t=1395338306; x=1396547906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fuJzHV67w6Nxgy1MoB0up929/T2rA1Op4Op6n0rUA6E=; b=ffAvZ6aeAKV76F4MNs6Zliui59yWwqH3LRrSK3h7taesfig0qTPXRnYF nYLvjbAYJUXdDlT7c8wa2TQXYNG04CtcY6hIWFHc5WmM1s2C/BVRSdyKK lEN+a8KF+Ij0w2oJjKbrkUKnmnE4f8HsFmrYPI9OgDPszFfzh3NR1aqcs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHgrK1OtJV2c/2dsb2JhbABZgwaBEsJRgRoWdIIlAQEBBG4LDAQCAQgRAQMBAQsdBzIUAwYIAgQBDQUIh3HPbheODScxBwaDHoEUAQOJGqFdgy2BaUI X-IronPort-AV: E=Sophos;i="4.97,696,1389744000"; d="scan'208";a="311688688" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 20 Mar 2014 17:58:26 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2KHwOSs027955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 17:58:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 12:58:24 -0500 From: "Pascal Thubert (pthubert)" To: Hannes Tschofenig , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch] Question: Extended Design Team for 6TiSCH security architecture Thread-Index: AQHPQtNPIOdkYPAl80iiBr8YT2rh3JrqKh7A Date: Thu, 20 Mar 2014 17:58:23 +0000 Deferred-Delivery: Thu, 20 Mar 2014 17:58:00 +0000 Message-ID: References: <532888A0.3050901@gmx.net> In-Reply-To: <532888A0.3050901@gmx.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/tstel9DAi8Zfl5dTBwhf52cL6_g Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch-security] [6tisch] Question: Extended Design Team for 6TiSCH security architecture X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:58:36 -0000 Hi Hannes: Sorry for the confusion;=20 the 6tisch-security@ietf.org mailing list is a limited list that is used to= support talks on 6TiSCH security architecture by Design Team members and e= xtended Consulting Team members. 6TiSCH has formed a dedicated Design Team = to work the security component of the architecture and established a weekly= call on Mondays with regular reports both at the 6TiSCH weekly or at the W= G meetings. An extended Consulting Team helps in the task.=20 People who wish to participate need to contact the 6TiSCH chairs or Michael= Richardson would leads the DT. There might still be a bit of a churn between DT and CT but at this moment = the DT members are: Michael Richardson, Ren=E9 Struik, Tom Phinney, Subir Das, Michael Behringe= r, Jonathan Simon, Nancy Cam-Winget and Yoshihiro Ohba. =20 And the CT members are Kris Pister, Giuseppe Piro, Thomas Watteyne, Pascal Thubert and Paul Duffy. The extended CT adds so far: Patrick Wetterwald, Maik Seewald, Hank Mauldin and Ines Robles. Cheers, Pascal > -----Original Message----- > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Hannes Tschofe= nig > Sent: mardi 18 mars 2014 18:56 > To: 6tisch@ietf.org > Subject: [6tisch] Question: Extended Design Team for 6TiSCH security > architecture >=20 > Hi all, >=20 > I just saw the announcement of a design team mailing list and I checked t= he > mailing for the announcement of the design team and I found nothing. >=20 > Ciao > Hannes From nobody Sun Mar 23 18:37:20 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433711A0099 for <6tisch-security@ietfa.amsl.com>; Sun, 23 Mar 2014 18:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 hOEFOMFlaR01 for <6tisch-security@ietfa.amsl.com>; Sun, 23 Mar 2014 18:37:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id ACDE31A0097 for <6tisch-security@ietf.org>; Sun, 23 Mar 2014 18:37:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A0F8620049 for <6tisch-security@ietf.org>; Sun, 23 Mar 2014 22:56:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8A2D663AB2; Sun, 23 Mar 2014 21:37:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 71D4163AA2 for <6tisch-security@ietf.org>; Sun, 23 Mar 2014 21:37:15 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <23590.1394999032@sandelman.ca> References: <531DD632.2060009@cox.net> <531DDB20.5050600@gmail.com> <10925.1394631496@sandelman.ca> <532069C8.2050005@gmail.com> <23590.1394999032@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/7dWZnMQ5VimNZmt3So6oDvbuCZM Subject: [6tisch-security] agenda for 2014-03-24 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 01:37:19 -0000 --=-=-= 1) pro/con discussion of EAP-TLS based system join vs seperate JOIN network. 30 minutes. 2) 1x vs PANA for layer-2. 15 minutes. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUy+MS4qHRg3pndX9AQJTwgP8D/fKsRP+636knzV5PnmvbQ3rs28YCzkV ctkytwlWRFzIYY+U1c1a7Pz6uhurWUQLxnnsPs/v3/KrHBLtL+pVTheuHJ7UcJ1l 8YgD3LjB2D5BtJFpCApQoELDJ6YJBUD9RHt8qBmhSAbebcTEFgLapPR7eM3yrP5N JLixFDzMvLk= =jkQd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 04:05:07 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F0F1A01B4 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 04:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 TkauiXNzw4ZP for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 04:05:03 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4038A1A01AB for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 04:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=882; q=dns/txt; s=iport; t=1395659102; x=1396868702; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VGDUGnraj1f1xZWAUaCgk2lEv8AOFTAxVaEzg/2Nsm4=; b=DJwynDBRD1mBtN2Moj/61D8Bzb1xHBr962vq19GE2HTnafJqBnoZlcRg AYRswqdvHD5RPnv/7tPreOm1B+UG9AW85bgZMNAgsrZHThmy96lCYN81L vbdn/2nvqteNVL2JFsAd+HGcgSKw5j4UYwyq9BUpEe+eLN3Qtjc2gn2jG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHYQMFOtJV2d/2dsb2JhbABZgwaBEsJwgRUWdIIlAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEARIIh3HNfxeOSTgGgx6BFAEDqnuDLYIr X-IronPort-AV: E=Sophos;i="4.97,720,1389744000"; d="scan'208";a="29830217" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 24 Mar 2014 11:05:01 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2OB51sU026893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 11:05:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.171]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 06:05:01 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security call Thread-Index: AQHPREObr0/w1C739kSok8mPhJQ2MZrwGRww Date: Mon, 24 Mar 2014 11:05:01 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2649@xmb-rcd-x14.cisco.com> References: <7409.1395323518@sandelman.ca> In-Reply-To: <7409.1395323518@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/R1Gy1F0_oCQqCM6y00muBfWiOQA Subject: Re: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:05:05 -0000 Sorry, while the US has switched to daylight saving and Europe not yet, I h= ave an overlap, and can't make today. Next week it's okay again... Michael -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: 20 March 2014 14:52 To: 6tisch-security@ietf.org Subject: [6tisch-security] Jonathan Simon: Re: 2014-03-17: 6tisch security = call I want to start the discussion with Jonathan's message. I'd like some clear opinions about whether you want to do layer-2 provision= ing using a protocol which is common with the application target (i.e. CoAP= over DTLS). Or whether one wants to use a layer-2 specification which is already to som= e extend (ZigbeeIP) "out there" -- but which may have significant code impa= ct. Some would like to see 1x rather than PANA as the layer-2.5. From nobody Mon Mar 24 06:50:05 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF11A0211 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 06:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 ccmoXmi5vEAQ for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 06:50:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CC1121A020B for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 06:49:58 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B2A120033 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 11:09:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7E70763ABA; Mon, 24 Mar 2014 09:49:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6CEF463AB6 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 09:49:56 -0400 (EDT) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <7409.1395323518@sandelman.ca> References: <7409.1395323518@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/xP3CXuj65yGYs3_z_mIXwpkZiNc Subject: [6tisch-security] 2014-03-24: 6tisch security call X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 13:50:02 -0000 --=-=-= The URL to access is: https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908 I'm at +1 613 276-6809, IM: mcr@xmpp.credil.org or mcharlesr@gmail.com, if you need more than that to get in. To remind two things: 1) the Note Well applies. 2) the call is being recorded. 3) the list is being archived. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzA4BIqHRg3pndX9AQILXQQA2eIClFqh0RDjmE78xDhrQqfbcG88B1oF 2jVFMol47WYOKuMEAlkqhNrg9Ll+s5oe4ueHG2BH7uImB/PMT6U6WLFet7oEGbw4 tWDz1ytV4jF8TNEdFQ6fiMl8l6S7QfqO2brRHCEVJxOy6mklzumdVH4B7z/4q3ih Wc90VpKguJ8= =NV0c -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 07:00:23 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB2F1A0217 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 07:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=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 EWSrlI8ZeuRn for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 07:00:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id BD8B81A0215 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 07:00:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D745720033 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 11:19:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 050AE63ABA; Mon, 24 Mar 2014 10:00:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EA78963AB6 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 10:00:18 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <7409.1395323518@sandelman.ca> References: <7409.1395323518@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/psywcWavweUUT0G3dszpp49lBeQ Subject: [6tisch-security] 2014-03-24: 6tisch security call - etherpad X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:00:21 -0000 --=-=-= please join the notes at: http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security?useMonospaceFont=true -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzA6coqHRg3pndX9AQKYDgP/YFRSPsImrn2Iajc7Sa0HRkPZRM0Uaw5j flgg0gnxpQVyF5ED4qgj+B8H/EfTE5gNQLwqHFB5ST81LdimDN9Ac9HTK3z6zebO qGKI0yTHR0stbc6x4lVzT5OJlmvOw0rde/wCwGqwn0Yy9v6BGOnAwyEzbN81QQqn nB4nfiYQDSo= =hS3r -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 08:27:14 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C161A01C2 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 08:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, WEIRD_PORT=0.001] autolearn=no 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 ZaMapB6EojcT for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 08:27:09 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1CD1A0220 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 08:27:09 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s2OFR7MQ021105; Tue, 25 Mar 2014 00:27:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s2OFR7QS024585; Tue, 25 Mar 2014 00:27:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA24584; Tue, 25 Mar 2014 00:27:07 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s2OFR7R9023916; Tue, 25 Mar 2014 00:27:07 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id s2OFR7BN020173; Tue, 25 Mar 2014 00:27:07 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.147]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 00:27:07 +0900 From: To: , <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] 2014-03-24: 6tisch security call - etherpad Thread-Index: AQHPR2lpJFJlj7laG0Sg7XvT4lWye5rwVt8w Date: Mon, 24 Mar 2014 15:27:06 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> References: <7409.1395323518@sandelman.ca> <10596.1395669618@sandelman.ca> In-Reply-To: <10596.1395669618@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.112] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/0ziANtbcwoA8T2Z3EPnyQjmERTA Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:27:11 -0000 During today's call, I mentioned support for both certificate-based authent= ication and pre-shared key based authentication to allow the widest deploym= ent of 6tisch, and EAP fits to support both types of credentials. I know that CoAP/DTLS can also support both types of credentials. However,= another advantage of supporting EAP is that it allows us to make use of ex= isting AAA (authentication, authorization and accounting) infrastructure vi= a RADIUS. Use of CoAP/DTLS would need more protocol extension work on both= DTLS/CoAP and RADIUS for interfacing with AAA, and this protocol impact sh= ould be considered when choosing a solution or solutions for 6tisch securit= y. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Monday, March 24, 2014 11:00 PM To: 6tisch-security@ietf.org Subject: [6tisch-security] 2014-03-24: 6tisch security call - etherpad please join the notes at: http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security?useMo= nospaceFont=3Dtrue -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Mar 24 08:41:18 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC71A0257 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 08:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=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 VfMnEEkWxvyL for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 08:41:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE01A0255 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 08:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2059; q=dns/txt; s=iport; t=1395675672; x=1396885272; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=I7aHutv+hiAUD8cn7YXlmuNRD21dWmVmoHmEJsFA61c=; b=Y7IvnHrGU1zb1+PqUqnPjcitfEzeP3gxPATzggn1AMhBxDyTZcleEktW 7HlRtqcMq3wXsA//gpCe1ikLc38BPbq9iwfqagniUmTC/kooYfeRB3qwa 3DpjX6l7hqqFQNESwd1C7tElt1vICwjhycdmua9Xqf7/WgiDncRMJx2Zd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAKxQMFOtJV2a/2dsb2JhbABZgwY7V7s4hmRRgRkWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEggTh14Nzj4Xjkk4BoMegRQEmXyQf4Mtgis X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="29902726" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 24 Mar 2014 15:41:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2OFf5Za019239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 15:41:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.171]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 10:41:04 -0500 From: "Michael Behringer (mbehring)" To: "yoshihiro.ohba@toshiba.co.jp" , "mcr+ietf@sandelman.ca" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] 2014-03-24: 6tisch security call - etherpad Thread-Index: AQHPR2loac9XTudt00WyM/539uir05rwsAUA//+vrIA= Date: Mon, 24 Mar 2014 15:41:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2AD1@xmb-rcd-x14.cisco.com> References: <7409.1395323518@sandelman.ca> <10596.1395669618@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Jkethy0tvJCT10U9v_sfdQNs9uU Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:41:16 -0000 Sorry for not being able to join today's call.=20 Regarding the CoAP vs EAP discussion, has anyone written down in a table fo= rmat what the differences, pros and cons of each are? I'm starting to make = that table in my head to be able to follow this discussion, but it strikes = me that probably someone better than me has already done that :-)=20 Michael -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f yoshihiro.ohba@toshiba.co.jp Sent: 24 March 2014 16:27 To: mcr+ietf@sandelman.ca; 6tisch-security@ietf.org Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad During today's call, I mentioned support for both certificate-based authent= ication and pre-shared key based authentication to allow the widest deploym= ent of 6tisch, and EAP fits to support both types of credentials. I know that CoAP/DTLS can also support both types of credentials. However,= another advantage of supporting EAP is that it allows us to make use of ex= isting AAA (authentication, authorization and accounting) infrastructure vi= a RADIUS. Use of CoAP/DTLS would need more protocol extension work on both= DTLS/CoAP and RADIUS for interfacing with AAA, and this protocol impact sh= ould be considered when choosing a solution or solutions for 6tisch securit= y. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Monday, March 24, 2014 11:00 PM To: 6tisch-security@ietf.org Subject: [6tisch-security] 2014-03-24: 6tisch security call - etherpad please join the notes at: http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security?useMo= nospaceFont=3Dtrue -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Mon Mar 24 09:32:17 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D105A1A026F for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 09:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] 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 fvRaJeimX--L for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 09:32:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 20BFF1A0236 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 09:32:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B88A20049; Mon, 24 Mar 2014 13:51:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3024663ABA; Mon, 24 Mar 2014 12:32:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2143663AA2; Mon, 24 Mar 2014 12:32:12 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> References: <7409.1395323518@sandelman.ca> <10596.1395669618@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Jxv7p9I0ILVWHjmi23dzrDgvwIY Cc: yoshihiro.ohba@toshiba.co.jp Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:32:15 -0000 --=-=-= wrote: > During today's call, I mentioned support for both certificate-based > authentication and pre-shared key based authentication to allow the > widest deployment of 6tisch, and EAP fits to support both types of > credentials. Yes, but there are several ways that EAP can do this. There are some non-TLS methods that can use PSKs, and there are PSK methods that use TLS. I assume we want the latter! Ditto DTLS... The PSK poses significant scaling and lifecycle problems. > I know that CoAP/DTLS can also support both types of credentials. > However, another advantage of supporting EAP is that it allows us to > make use of existing AAA (authentication, authorization and accounting) > infrastructure via RADIUS. Use of CoAP/DTLS would need more protocol > extension work on both DTLS/CoAP and RADIUS for interfacing with AAA, > and this protocol impact should be considered when choosing a solution > or solutions for 6tisch security. Should we go with an ESP-TLS solution, one of things that we need to specify is how that bootstrap results in an introduction between the mote and an (ACE-inspired) authorization server. That authorization server would have "super-user" on the mote, and be able to create new trust relationships appropriate for the PCE (if there is one), and whatever applications exist. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzBeC4qHRg3pndX9AQK+/AQA3ojxknRu+E8KGWgt1QjI/ZRf5hhShBWr ABr0ciYiwnVEuNcb1aU93hHNz9sUm5zxTuWVYWeD4ln+XtDYz5I+Leia/PkBGtgn 8LpptwCfJ9a8lpOuYwUCghTuchRDjDWJIVj6rnRJkKeZ/WihvChgr/R7arIfOVUQ TT0of7pCc4Y= =jirU -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 24 10:45:31 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50721A022B for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 aoPEC9m5dMxn for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 09:10:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DC1A01B9 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 09:10:02 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BD6D20049 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 13:29:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 14C9863ABA; Mon, 24 Mar 2014 12:10:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F0C4063AA2 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 12:10:01 -0400 (EDT) From: Michael Richardson To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2AD1@xmb-rcd-x14.cisco.com> References: <7409.1395323518@sandelman.ca> <10596.1395669618@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272170E7@TGXML210.toshiba.local> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9C2AD1@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/-zTW7eHgO8qAFmOCWYNJNf5VXuw X-Mailman-Approved-At: Mon, 24 Mar 2014 10:45:27 -0700 Subject: Re: [6tisch-security] 2014-03-24: 6tisch security call - etherpad X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 16:10:05 -0000 Michael Behringer (mbehring) wrote: > Regarding the CoAP vs EAP discussion, has anyone written down in a > table format what the differences, pros and cons of each are? I'm > starting to make that table in my head to be able to follow this > discussion, but it strikes me that probably someone better than me has > already done that :-) Yup: we started at: > please join the notes at: > http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security?useMonospaceFont=true From nobody Mon Mar 24 16:17:00 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2659D1A0305 for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 CtZXrkfriiNX for <6tisch-security@ietfa.amsl.com>; Mon, 24 Mar 2014 16:16:55 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80B1A02FD for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 16:16:55 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j5so18847237qga.4 for <6tisch-security@ietf.org>; Mon, 24 Mar 2014 16:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JygGm3DPNYBcEhetlwe7UdQMeqa1LvQe3eILIikLfIs=; b=u+tCV8I0qhdJ07BciLj/MsrPcw98CJXxLLF9pXWxLsXEuQjmktkU9EbQ5ZT/kA5wfa L66FN3hVeXPRTZzfYVQ8/QAytFGYBizY7Mtq+3J4MkOQtEB90SQn9oe8KN+ov1z5fQAN sH440mRkN5/TcdB6SH/OIqQ3dDET3Mg3ndb8K9g5FZp61y4WAhkHzIKxDL0uke0GDhH1 xpbv/66iZTf2KDI3J4bcFHhX/hY6LDYDzABSB2B72BDPWhlDh9T6JN7c/yDZkD/eLp3V 8JU/QNIv4EfG2jDnuGp6HiS1FQ/vPL28+dq93tJCPp7+Y65TMk7hvBMXlF7bgFhDXqlX VSZw== X-Received: by 10.140.82.175 with SMTP id h44mr75441188qgd.68.1395703014401; Mon, 24 Mar 2014 16:16:54 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id 104sm14137478qgq.1.2014.03.24.16.16.52 for <6tisch-security@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 16:16:53 -0700 (PDT) Message-ID: <5330BCE1.9030508@gmail.com> Date: Mon, 24 Mar 2014 19:16:49 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: 6tisch-security@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/11_Qs_-AKhfD7o_QeCFwqc3HS44 Subject: [6tisch-security] on 802.15.9 (kmp) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 23:16:58 -0000 Dear colleagues: During the 6tisch security conf call earlier today, March 24, 2014, the current IEEE 802.15.9 project ("kmp") was mentioned. For your information, please find below the web link to the PAR (and comments on the PAR) {both posted November 9, 2011}: https://mentor.ieee.org/802.15/dcn/11/15-11-0613-06-0kmp-key-management-protocol-par.doc https://mentor.ieee.org/802.15/dcn/11/15-11-0805-02-0kmp-par-comments.doc To my knowledge, the end product of this effort will be a so-called "best practice", not a standard. I do not have access to the current specification. However, for status at the end of the IEEE 802 meeting in Beijing last week (March 21, 2014), see https://mentor.ieee.org/802.15/dcn/14/15-14-0208-00-0009-tg9-meeting-minutes-beijing-march-2014.docx Best regards, Rene -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Mar 27 22:19:44 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E61A0446; Thu, 27 Mar 2014 22:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 GYhVV842-NMs; Thu, 27 Mar 2014 22:19:33 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADFA1A0443; Thu, 27 Mar 2014 22:19:33 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so4491453pad.21 for ; Thu, 27 Mar 2014 22:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=YW6yfHX+7yHb/7moLTc/eRRBrnoKq/Q6WDHiDfI/3tM=; b=lEgyXRVx7cakVYYrjdjZoaYGsaTQV7DlTR4nXZO5iCf4MB/q+eDBCGnv2XKv16oIx1 w4wl4enWj7gWBz8MmyTa3/YUm0VXzmbdlmFhMGamlcg277iVLxDo/BYFQ6v0sIR/8flm 15q6J8f3YoHtZLklYBcY1pTnKSnzeT3Ff/uE/MwybX2H0kZ9jat+sx3VXn2oCXOhUEmD Na0DWPMNOAKGxfu20xY6Du6j3Lr245DgntX96TrT0YZVh4AtHg+bbI1TPIALefoklrNg gCctUqDv5fAEwfSv0JyLZXTjFk79r8JwBKHjjs5/nhDGYFhEpSMoAwkCqGzN87c7cvKd AL/w== X-Received: by 10.66.251.42 with SMTP id zh10mr6321826pac.84.1395983971296; Thu, 27 Mar 2014 22:19:31 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.154.130 with HTTP; Thu, 27 Mar 2014 22:19:11 -0700 (PDT) From: Thomas Watteyne Date: Thu, 27 Mar 2014 22:19:11 -0700 X-Google-Sender-Auth: zEBVdWCdkjBMv4vDzXAyiSmMB3s Message-ID: To: 6tisch-security@ietf.org Content-Type: multipart/alternative; boundary=047d7b15fe7bb8ac7104f5a3d889 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/QsbctOMz9dJ167oQThQZSM5Ya7I Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: [6tisch-security] Minutes security discussion 24 March 2014 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 05:19:36 -0000 --047d7b15fe7bb8ac7104f5a3d889 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, You will find the minutes of the last security discussion at https://bitbucket.org/6tisch/meetings/wiki/140324_webex_security, also copy-pasted below. Please fix anything we might have missed directly in the e-mail and reply. Thomas ---- Minutes Webex 24 March 2014, 6TiSCH Security Taking notes *(using Etherpad)= * - Thomas Watteyne - Pascal Thubert - Michael Richardson Present *(alphabetically)* - Giuseppe Piro - Jonathan Simon - Michael Richardson - Pascal Thubert - Paul Duffy - Ren=E9 Struik - Subir Das - Thomas Watteyne - Tom Phinney - Yoshihiro Ohba Recording - Webex recording (audio+slides,streaming) - https://cisco.webex.com/ciscosales/lsr.php?RCID=3Da4f1df64424d4cc382dc0d= 35c4796f47 *[51min]* Minutes - *[07.12]* *Michael* introduces agenda. Indicates note well, that meeting is recorded, minutes taken, presence logged. Makes sure all on Etherpad. - Pros and cons of EAP-TLS method (whether over PANA or 1X), vs. "separate" join network with object model with 6top protocol and data collection/actuation. - Comments on 1X from Paul Duffy. IEEE802.15.9 group is chartered to design something similar to 1X in IEEE802.15.4 space. - Rene comments about 15.9 - 15.9 security WG from IEEE. - *[Rene Struik]* 15.9 effort started several years ago. This KMP group codifies methods to transfer key management messages. - *[Michael Richardson]* Functionally equivalent to PANA - *[Rene Struik]* Any technical work? Not equivalent to PANA. - [??] PANA can carry 1X-type messages over L3 - *[Subir Das]* Understanding is that 15.9 is not chartered to design mechanism similar to PANA. Not sure we should call it as chartered to design something similar to PANA. - *[Michael Richardson]* discussion with Bob Moskowitz indicating 15.9 will allow to transport PANA-like messages. - *[Michael Richardson]* does not matter, let's discuss at some other time. You have a client which wants to join; EAP-TLS, you get a network = key through that process allowing the mote to join the network. Only reason = to talk about 15.9 is because Paul Duffy indicated preferred 1X instead of PANA. - *Michael* updates list of pro/con This list is indicates at the end of these minutes - Conceivably TLS and DTLS can share a lot of code though they are different services - *[Rene Struik]* Technical argument for preferring 1X? - *[Michael Richardson]* pre-existence of deployments/customers. Preference. - *[Pascal Thubert]* we want to understand what properties we want to get and the cost for getting there, 1x vs. PANA is not the question for = now - *[Michael Richardson]* you have to have EAP and TLS code in mote - *[Subir Das]* are we assuming that mote will run CoAP interface? - *[Michael Richardson]* yes, at least because 6top interface on top of CoAP - *[Subir Das]* if runs CoAP, will have DTLS by default? - *[Michael Richardson]* will assume runs CoAP for sensors/actuators. - *[Jonathan Simon]* sounds reasonable. If CoAP is mechanisms that devices use for data and management, than joining model which stays clos= e to that is a good idea. Simple solutions that don't have a lot of extra layer or parallel technologies is better. - *[Michael Richardson]* have written down as PRO. Anybody has recommendation for 1X/PANA method? No answer. - *[Michael Richardson]* ZigBeeIP has been shipping devices with the PANA/1X approach - *[Michael Richardson]* once you get to authorization server, EAP-TLS is used, regardless of whether you come in through PANA or 1X. Same thin= g. - *[Subir Das]* this framework does allow for centralized/distributed case. ZigBeeIP has some relay functionality to reach authentication serv= er if not a single hop away - *[Michael Richardson]* proxy uses PANA to contact authorization server. The adjacent node relays the information through the mesh to the authentication server. At that point, it's PANA. With 1X, something else= ? Probably radius or something else. - *[Subir Das]* normally done by radius in WiFi case - *[Michael Richardson]* yes, but single hop and not thousands of authenticators talking to radius server. - *[Paul Duffy]* couple of points: - PANA or 1X both needs to be relayed - PANA relaying has been RFCed, not a problem. - From a radius/relaying standpoint, PANA and 1X are very similar. - *Michael* summarizes: discussion PANA/1X (EAP-TLS) solution vs. method with uses CoAP/DTLS and YANG model similar to WirelessHART - *[Michael Richardson]* EAP-TLS over something. If someone has ZigBeeIP authentication infrastructure for lighting, they could use it for plant. Same technology. Agreed that having common infrastructure is a feature? - *[Paul Duffy]* not a lot of ZigBeeIP deployed. Cisco not a fan of PANA in ZigBeeIP, but has many devices that use 1X. Cisco tries to use things off the shelf. 1X is smaller footprint. - *[Paul Duffy]* Is the CoAP/DTLS approach brand new? - *[Paul Duffy]* No running code for IP but WirelessHART does it that way just not over IP, just over layer 2. - *[Paul Duffy]* People inside Cisco might not like that at all because all the way up to L4. Minimal amount of footprint is preference. - *[Paul Duffy]* Minimize attack footprints by strictly L2 approach 1x. - *[Jonathan Simon]* L2 from 15.4 perspective? - *[Paul Duffy]* yes - *[Paul Duffy]* if solution relies on L2, L3 and L4, than most of the stack needs to be functioning - *[Michael Richardson]* about footprint: robots requires CoAP/DTLS to run for application - *[Paul Duffy]* security compromise, cannot answer directly. you would be making compromise. - *[Jonathan Simon]* if the mechanism that all are happy with to send data is not the same one as the one used to join network then security concern for join is principally for blocking denial of service. You need= to go through those steps to send data. That looks like what we need to decide: DoS vs. simplifying. - *[Paul Duffy]* Utility answer: L2 access control is one the last things we'd like to remove. Immutable device identify: related to IEEE802.15.1AR - *[Michael Richardson]* Assumes 1AR can be used in all of solutions. No other standard solution as mature as 1AR. - *[Paul Duffy]* think correct, could ask authors. Involved with ZigBeeIP, 802.1AR, smart grid issues. - *[Paul Duffy]* has been implemented most in grid - *[Rene Struik]* question 1AR: don't understand what is so special about it. Just certificate? - *[Paul Duffy]* set of guidelines for strong device identity - *[Rene Struik]* but uses SHA1, which is deprecated, right? 1AR provides mechanism to issue certificate and find which device belongs to which entity - *[Paul Duffy]* not just certificate method, other elements such as random number - *[Michael Richardson]* also mechanism to update and replace certificates to create new device IDs. Seems that are all pieces needed: accept mote, replace, obsolete, change ownership, etc. - *[Rene Struik]* we need more precision. Have no way what is being discussed about what matters and what is missing. - *[Paul Duffy]* happy to read specification different from 1AR - *[Michael Richardson]* question is not whether 1AR is good/bad. It exists. Question is: given what 1AR gives us, how can be transport the network claim to the mote and the authentication claim of the mote. One = of standard protocols is PANA or 1X transport of EAP-TLS. Other mechanism i= s to use the certificates 1AR gives us directly in DTLS. In 6TiSCH, if we have a PCE, the PCE needs to program schedule in motes. PCE need "super user" access to motes, 1AR certificates provide that ownership statement= . We need interoperability between motes and authentication servers from different vendors. We don't expect people to handle mote to authenticate= , needs to be much more automated. 1AR is routinely done by companies such= as Verizon for VoIP phones; there are products which use that. - *[Subir Das]* are we trying to lock down the device to a particular vendor? - *[Michael Richardson]* initially, transfer between vendor and user. from APIs in 1AR, once the initial owner takes ownership, possibility to change identity so doesn't need to talk to vendor. Allows transferring ownership. - *[Subir Das]* we could just think of it as a certificate. We should have different options. - *[Michael Richardson]* other mechanisms like transferring ownership can be added to talk. Crux is for mote to be able to validate certificat= e chain. - *[Michael Richardson]* the mote is able to validate a variety of certificate statements. - *[Paul Duffy]* about 1AR, let's not assume it's perfect. May need to be modified, but strong guidance to IoT space. - *[07.55]* *[Michael Richardson]* Let's move on. we spent lot of time on PANA/1AR. Round table with final comments. - *[Yoshihiro Ohba]* don't disagree supporting 1x but pre-shared key authentication should be supported as well; - *[Michael Richardson]* can you write as e-mail? - *[Tom Phinney]* nothing to add. concerned with scalability and replacement. But think those issues are being addressed e.g. by Ren=E9. Tend to agree wit the Cisco concerns about scalability. - *[Thomas Watteyne]* Was taking notes. Interesting discussion. Leaning towards side that all of our data is transported over CoAP. D= ata transported over CoAP, also CoAP might be used by the PCE. CoAP is no= t optional, has to be there and secured. Reusing it for join reduces th= e footprint in the motes. - *[Subir Das]* nothing to add - *[Ren=E9 Struik]* look at flexible authentication and device replacement - *[Jonathan Simon]* Scalability and not having protocols that require 10 passes to just get ready to send data - *[Paul Duffy]* That is a concern, indeed. - *[Pascal Thubert]* Concerned that we are looking at solutions, but we haven't documented requirement space. Not clear we cover all requirements. Happy to keep in mind Michael B. Anything else we are missing? - *[Michael Richardson]* we are NOT having a call next week, we resume on 4/7. Please email to the 6TiSCH list and send a summary Notes These notes were taken by Michael Richardson during the call - 6TISCH SECURITY ARCHITECTURE - assumption: mote runs CoAP and DTLS already for 6top, and also for actual sensors/actuators. - 802.1AR, "immutable device identity" is origin of trust relationship (almost ubiquitous in AMI GRID) - 1X/PANA METHOD - PRO: - specified by ZigBee IP - common authorization infrastructure with ZigBee IP. - minimizes attack footprint - deals with DoS on network traffic much earlier - CON: - requires EAP, TLS - code is used only once to get on the network - WIRELESSHART/JOIN NETWORK METHOD (whether ND ARO or RPL DIO) - PRO: - reuses existing CoAP and DTLS code base. - CON: - requires layer-3/layer-4 to be operating. --047d7b15fe7bb8ac7104f5a3d889 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

You will find the minutes of the l= ast security discussion at=A0https://bitbucket.org/6tisch/meetings/wiki/1= 40324_webex_security, also copy-pasted below.

Please fix anything we might have missed directly in th= e e-mail and reply.

Thomas

----

Minutes Webex 24 March 2014, 6TiSCH Security

Taking notes=A0(using Etherpad)

  • Thomas Watteyne
  • Pascal Thubert
  • Michael Richardson

Present=A0(alphabetically)

  • Giuseppe Piro
  • Jonathan Simon
  • Michael Richardson
  • Pascal Thubert
  • Paul Duffy
  • Ren=E9 St= ruik
  • Subir Das
  • Thomas Watteyne
  • Tom Phinney=
  • Yoshihiro Ohba

Recording

Minutes

  • [07.12]=A0Michael=A0introduces agenda. Indicates note well, that meeting is recorded, min= utes taken, presence logged. Makes sure all on Etherpad.
  • Pros and cons of EAP-TLS method (whether over PANA or 1X), vs. "separa= te" join network with object model with 6top protocol and data collect= ion/actuation.
  • Comments on 1X from P= aul Duffy. IEEE802.15.9 group is chartered to design something similar to 1= X in IEEE802.15.4 space.
  • Rene comments about 15.9
  • 15.9 security WG from IEEE.
  • [Rene Struik]=A015.9 effort started seve= ral years ago. This KMP group codifies methods to transfer key management m= essages.
  • [Michael Richardson]=A0= Functionally equivalent to PANA
  • [Rene Struik]=A0Any technical work? Not equivalent to PANA.
  • [??] PANA can carry 1X-type messages over L3
  • [Subir Das]=A0Understanding is that 15.9 is not c= hartered to design mechanism similar to PANA. Not sure we should call it as= chartered to design something similar to PANA.
  • [Michael Richardson]=A0= discussion with Bob Moskowitz indicating 15.9 will allow to transport PANA-= like messages.
  • [Michael Rich= ardson]=A0does not matter, let's discuss at some other time. Y= ou have a client which wants to join; EAP-TLS, you get a network key throug= h that process allowing the mote to join the network. Only reason to talk a= bout 15.9 is because Paul Duffy indicated preferred 1X instead of PANA.
  • Michael=A0updates list = of pro/con

    This list is indic= ates at the end of these minutes

  • Conceivably TLS and DTLS can share a lot of code though they = are different services
  • [Rene Struik]=A0Technic= al argument for preferring 1X?
  • [Michael Richardson]=A0pre-existence of deployments/customers. = Preference.
  • [Pascal Thubert]=A0we w= ant to understand what properties we want to get and the cost for getting t= here, 1x vs. PANA is not the question for now
  • [Michael Richardson]=A0you have to have EAP and TLS code i= n mote
  • [Subir Das]= =A0are we assuming that mote will run CoAP interface?
  • [Michael Richardson]=A0yes, at least because 6top interfac= e on top of CoAP
  • [Subir Das]= =A0if runs CoAP, will have DTLS by default?
  • [Michael Richardson]=A0will assume runs CoAP for sensors/a= ctuators.
  • [Jonathan Simon]=A0sounds reasonable. If CoAP is mechanisms that devices use for dat= a and management, than joining model which stays close to that is a good id= ea. Simple solutions that don't have a lot of extra layer or parallel t= echnologies is better.
  • [Michael Richardson]=A0= have written down as PRO. Anybody has recommendation for 1X/PANA method?

    No answer.

  • [Michael Richardso= n]=A0ZigBeeIP has been shipping devices with the PANA/1X approach<= /li>
  • [Michael Richardson]=A0= once you get to authorization server, EAP-TLS is used, regardless of whethe= r you come in through PANA or 1X. Same thing.
  • [Subir Das]=A0this framework does allow for centralized/di= stributed case. ZigBeeIP has some relay functionality to reach authenticati= on server if not a single hop away
  • [Michael Richardson]=A0proxy uses PANA to contact authoriz= ation server. The adjacent node relays the information through the mesh to = the authentication server. At that point, it's PANA. With 1X, something= else? Probably radius or something else.
  • [Subir Das]=A0normally = done by radius in WiFi case
  • = [Michael Richardson]=A0yes, but single hop and not thousands of au= thenticators talking to radius server.
  • [Paul Duffy]=A0couple o= f points:
    • PANA or 1X both needs to be relayed
    • PANA relaying has been RFCed, not a problem.
    • From a radius/relaying standpoint, PANA = and 1X are very similar.
  • <= strong>Michael=A0summarizes: discussion PANA/1X (EAP-TLS) solution= vs. method with uses CoAP/DTLS and YANG model similar to WirelessHART
  • [Michael Richardson]=A0= EAP-TLS over something. If someone has ZigBeeIP authentication infrastructu= re for lighting, they could use it for plant. Same technology. Agreed that = having common infrastructure is a feature?
  • [Paul Duffy]=A0not a lo= t of ZigBeeIP deployed. Cisco not a fan of PANA in ZigBeeIP, but has many d= evices that use 1X. Cisco tries to use things off the shelf. 1X is smaller = footprint.
  • [Paul Duffy]=A0Is the C= oAP/DTLS approach brand new?
  • [Paul Duffy]=A0No running code for IP but WirelessHART does it th= at way just not over IP, just over layer 2.
  • [Paul Duffy]=A0People i= nside Cisco might not like that at all because all the way up to L4. Minima= l amount of footprint is preference.
  • [Paul Duffy]=A0Minimize attack footprints by strictly L2 a= pproach 1x.
  • [Jonathan Simon]=A0L2 f= rom 15.4 perspective?
  • [Paul = Duffy]=A0yes
  • [Paul = Duffy]=A0if solution relies on L2, L3 and L4, than most of the sta= ck needs to be functioning
  • [Michael Richardson]=A0= about footprint: robots requires CoAP/DTLS to run for application
  • [Paul Duffy]=A0security comp= romise, cannot answer directly. you would be making compromise.
  • [Jonathan Simon]=A0if t= he mechanism that all are happy with to send data is not the same one as th= e one used to join network then security concern for join is principally fo= r blocking denial of service. You need to go through those steps to send da= ta. That looks like what we need to decide: DoS vs. simplifying.
  • [Paul Duffy]=A0Utility = answer: L2 access control is one the last things we'd like to remove. I= mmutable device identify: related to IEEE802.15.1AR
  • [Michael Richardson]=A0Assumes 1AR can be used in all of s= olutions. No other standard solution as mature as 1AR.
  • [Paul Duffy]=A0think correct, could ask= authors. Involved with ZigBeeIP, 802.1AR, smart grid issues.
  • [Paul Duffy]=A0has been= implemented most in grid
  • [R= ene Struik]=A0question 1AR: don't understand what is so specia= l about it. Just certificate?
  • [Paul Duffy]=A0set of g= uidelines for strong device identity
  • [Rene Struik]=A0but uses SHA1, which is deprecated, right= ? 1AR provides mechanism to issue certificate and find which device belongs= to which entity
  • [Paul Duffy]=A0not just= certificate method, other elements such as random number
  • [Michael Richardson]=A0also mechanis= m to update and replace certificates to create new device IDs. Seems that a= re all pieces needed: accept mote, replace, obsolete, change ownership, etc= .
  • [Rene Struik]=A0we need= more precision. Have no way what is being discussed about what matters and= what is missing.
  • [Paul Duff= y]=A0happy to read specification different from 1AR
  • [Michael Richardson]=A0= question is not whether 1AR is good/bad. It exists. Question is: given what= 1AR gives us, how can be transport the network claim to the mote and the a= uthentication claim of the mote. One of standard protocols is PANA or 1X tr= ansport of EAP-TLS. Other mechanism is to use the certificates 1AR gives us= directly in DTLS. In 6TiSCH, if we have a PCE, the PCE needs to program sc= hedule in motes. PCE need "super user" access to motes, 1AR certi= ficates provide that ownership statement. We need interoperability between = motes and authentication servers from different vendors. We don't expec= t people to handle mote to authenticate, needs to be much more automated. 1= AR is routinely done by companies such as Verizon for VoIP phones; there ar= e products which use that.
  • [Subir Das]=A0are we tr= ying to lock down the device to a particular vendor?
  • [Michael Richardson]=A0initially, transfe= r between vendor and user. from APIs in 1AR, once the initial owner takes o= wnership, possibility to change identity so doesn't need to talk to ven= dor. Allows transferring ownership.
  • [Subir Das]=A0we could = just think of it as a certificate. We should have different options.
    • [Michael Richardson]=A0ot= her mechanisms like transferring ownership can be added to talk. Crux is fo= r mote to be able to validate certificate chain.
  • [Michael Richardson]=A0= the mote is able to validate a variety of certificate statements.
  • [Paul Duffy]=A0about 1AR, le= t's not assume it's perfect. May need to be modified, but strong gu= idance to IoT space.
  • [07.55]=A0[Michael Rich= ardson]=A0Let's move on. we spent lot of time on PANA/1AR. Rou= nd table with final comments.
    • [Yoshihiro Ohba]=A0don't disagree supporting 1x but pr= e-shared key authentication should be supported as well;
    • [Michael Richardson]=A0can you write = as e-mail?
    • [Tom Phinney]=A0nothing= to add. concerned with scalability and replacement. But think those issues= are being addressed e.g. by Ren=E9. Tend to agree wit the Cisco concerns a= bout scalability.
    • [Thomas Watteyne]=A0Was= taking notes. Interesting discussion. Leaning towards side that all of our= data is transported over CoAP. Data transported over CoAP, also CoAP might= be used by the PCE. CoAP is not optional, has to be there and secured. Reu= sing it for join reduces the footprint in the motes.
    • [Subir Das]=A0nothing t= o add
    • [Ren=E9 Struik]=A0look at flexible authentication and device replacement
    • [Jonathan Simon]=A0Scalability and not having protocols th= at require 10 passes to just get ready to send data
    • [Paul Duffy]=A0That is a concern, indeed.<= /li>
    • [Pascal Thubert]=A0Conc= erned that we are looking at solutions, but we haven't documented requi= rement space. Not clear we cover all requirements. Happy to keep in mind Mi= chael B. Anything else we are missing?
  • [Michael Richardson]=A0we are NOT having a call next week, we resume on 4/7. Please emai= l to the 6TiSCH list and send a summary

Notes

These notes were t= aken by Michael Richardson during the call

  • 6TISCH SECURITY ARCHITECTURE
    • assumption: mote runs CoAP = and DTLS already for 6top, and also for actual sensors/actuators.
    • 802.1AR, "immutable device identity" is origin of trust relations= hip (almost ubiquitous in AMI GRID)
  • 1X/PANA METHOD
    • PRO:
      • specified b= y ZigBee IP
      • common authorization inf= rastructure with ZigBee IP.
      • minimize= s attack footprint
      • deals with DoS on network traffic much e= arlier
    • CON:
      • requires EAP, TLS
      • code is used only once to get on the network
  • WIRELESSHART/JOIN NETWORK METHOD (whether ND A= RO or RPL DIO)
    • P= RO:
      • reuses existing CoAP and DTLS code base.=
    • CON:
      • requires layer-3/layer-4 to be opera= ting.
--047d7b15fe7bb8ac7104f5a3d889-- From nobody Sun Mar 30 11:38:54 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0060B1A07F4 for <6tisch-security@ietfa.amsl.com>; Sun, 30 Mar 2014 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Cf0PyRpcM3fv for <6tisch-security@ietfa.amsl.com>; Sun, 30 Mar 2014 11:38:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D8F591A07EF for <6tisch-security@ietf.org>; Sun, 30 Mar 2014 11:38:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E766320028 for <6tisch-security@ietf.org>; Sun, 30 Mar 2014 15:58:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 53C7563ABA; Sun, 30 Mar 2014 14:38:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2EDDD63AA2 for <6tisch-security@ietf.org>; Sun, 30 Mar 2014 14:38:28 -0400 (EDT) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <23590.1394999032@sandelman.ca> References: <531DD632.2060009@cox.net> <531DDB20.5050600@gmail.com> <10925.1394631496@sandelman.ca> <532069C8.2050005@gmail.com> <23590.1394999032@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/oN6bIy3awk0b5Y-t-y1HjuLPCSs Subject: [6tisch-security] 6tisch security call(s) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 18:38:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable To re-iterate: Michael Richardson wrote: > I'd like to cancel the 2014-03-17 call, and do a call on the 24th, and > then April 7th, 14th. The 21st is a holiday for many, so we skip that. > By the 21st, I'd like to have a document that, while it may have > controversial and/or undecided pieces, the pieces should be understood > by all. By the 28th, I'd like to have a discussion to resolve whatev= er > issues may still exist. So, this means: 1) no call 2014-03-31. 2) call 2014-04-07. 3) call 2014-04-14. 4) no call 2014-04-21. 5) call 2014-04-28. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUzhknoqHRg3pndX9AQI4nwP/W/BmUFJf4wrr9pWxKLdJ8F8ADtFIaJcp byNS9VpNrIBVQq0j0lwBb3zx2HH5NZKAYKEjTocPzM4aIxl0TUwn4d1DjtyRtSen d068n3xNpib+jxGeKH+klZ0HDtislo13ZjoLfK1RnYUab3HQI92+vgH/TWdJQBUA mA30uHvpL4o= =xKEt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 30 11:44:01 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC56F1A08A8 for <6tisch-security@ietfa.amsl.com>; Sun, 30 Mar 2014 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 80ZbyG1IsNQ5 for <6tisch-security@ietfa.amsl.com>; Sun, 30 Mar 2014 11:43:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 76F871A08BC for <6tisch-security@ietf.org>; Sun, 30 Mar 2014 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=888; q=dns/txt; s=iport; t=1396205033; x=1397414633; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=j1KoNnhz79nFxBIB/I1OlUUPFYcw3UQCfuXX0AyVwYQ=; b=eeG1iI7wQpoD2p+MR4YuAuGtE+lYOXD6wdPTYQI3W1uSyrwaTq81rtKq 2Yqam4BqtgK8YvSvRJWFe3W1ER50zygsZzxN8kAqLT7bvnxg1xW0rIVhE CYQZxP9A4TmSWFEkD9AxvuVboaNXoM6joCoe6yFaU98ETMWV2sUiW7VjM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJNlOFOtJV2Y/2dsb2JhbABZgwaBEsMRgQ4WdIIlAQEBBDpRAQgYHkIlAgQBEod50GwXjwaEOAEDmE6SNYMwgis X-IronPort-AV: E=Sophos;i="4.97,761,1389744000"; d="scan'208";a="314003589" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 30 Mar 2014 18:43:52 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2UIhqRG000752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Mar 2014 18:43:52 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.114]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Sun, 30 Mar 2014 13:43:52 -0500 From: "Maik Seewald (maseewal)" To: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] 6tisch security call(s) Thread-Index: AQHPTEdQxzy4arxWkUaUOP3ANn8zl5r6fYQA Date: Sun, 30 Mar 2014 18:43:51 +0000 Message-ID: In-Reply-To: <7829.1396204708@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.60.75.74] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FFA12053E87BC43AF9744C120627D58@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ScRiajrUisglapIwyCW3xDFtqv8 Subject: Re: [6tisch-security] 6tisch security call(s) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 18:43:57 -0000 Thanks for the clarification. Mike On 30.03.14 20:38, "Michael Richardson" wrote: > >To re-iterate: > >Michael Richardson wrote: > > I'd like to cancel the 2014-03-17 call, and do a call on the 24th, >and > > then April 7th, 14th. The 21st is a holiday for many, so we skip >that. > > By the 21st, I'd like to have a document that, while it may have > > controversial and/or undecided pieces, the pieces should be >understood > > by all. By the 28th, I'd like to have a discussion to resolve >whatever > > issues may still exist. > >So, this means: >1) no call 2014-03-31. >2) call 2014-04-07. >3) call 2014-04-14. >4) no call 2014-04-21. >5) call 2014-04-28. > >--=20 >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > From nobody Mon Mar 31 04:17:25 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C1E1A0680 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 04:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3imLXVn5vf54 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 04:17:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD921A0667 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 04:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16870; q=dns/txt; s=iport; t=1396264638; x=1397474238; h=from:to:subject:date:message-id:mime-version; bh=V63xhgm/2JgrjlVKmXcY0ulPfWX6OxIX6sruz40gBUg=; b=KPD3euHTyY7teECiJie+YNtCjoy3aZ0Org/liGS1AQPh71SanSUwtxLA Vnltxx9iO0b1wUkve1pStU1Fts9CwRMy+nAlftT2uBVeiftFpvTGt4miB Bp/A4zNeSaJU1EV5xQtQmbT5Waqk/WtM+mPjnVpVnUeVZzP0XpMHZSn6z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAAdOOVOtJA2N/2dsb2JhbABZgkJEO1eDCsANGYECFnSCJwEEIwpeARwOGQcCBDAaDAEEGxOHXp54jxyiFReOLgEBHiCDBzWBFASrA4FxgT+BawcXBhw X-IronPort-AV: E=Sophos;i="4.97,764,1389744000"; d="scan'208,217";a="314109664" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 31 Mar 2014 11:17:18 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s2VBHHVn030735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 11:17:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.150]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 06:17:17 -0500 From: "Michael Behringer (mbehring)" To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: =?utf-8?B?Q29tbWVudHMgb24g4oCcNi1UaVNDSCBTZWN1cml0eSAtIFNvbWUgTm90ZXMg?= =?utf-8?B?YW5kIFRob3VnaHRzIG9uIFNlY3VyaXR5IFByb3BlcnRpZXM7IERhdGU6IDIw?= =?utf-8?B?MTQtMDMtMjTigJ0=?= Thread-Index: Ac9Ko9OTehHhREeyQVKPjFHxR0JWyg== Date: Mon, 31 Mar 2014 11:17:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/aCoi1As5zjGs-3DCiA9-StilRdk Subject: [6tisch-security] =?utf-8?q?Comments_on_=E2=80=9C6-TiSCH_Security?= =?utf-8?q?_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Date=3A_20?= =?utf-8?b?MTQtMDMtMjTigJ0=?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:17:24 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134xmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVuw6ksIHRlYW0sDQoNClVwIGZyb250LCBJIGhhdmVu4oCZdCBoYWQgdGhlIHRpbWUgdG8gY2F0 Y2ggdXAgd2l0aCB0aGUgZGV0YWlscyBvZiB0aGUgV0csIHNvIG1heSBub3QgYmUgYXdhcmUgb2Yg Y29udGV4dCwgcHJldmlvdXMgZGVjaXNpb25zLCBldGMuIFBsZWFzZSBsZXQgbWUga25vdyB3aGVy ZSBJ4oCZbSBtaXNzaW5nIHRoZSBwb2ludCBhbmQgZWR1Y2F0ZSBtZS4NCg0KQ29tbWVudHMgb24g 4oCcNi1UaVNDSCBTZWN1cml0eSAtIFNvbWUgTm90ZXMgYW5kIFRob3VnaHRzIG9uIFNlY3VyaXR5 IFByb3BlcnRpZXM7IERhdGU6IDIwMTQtMDMtMjTigJ0NCg0KU2xpZGUgNDogQWxsIHN0YXRlbWVu dHMgYXJlIGhpZ2ggbGV2ZWwgYW5kIG5vdCB5ZXQgcHJlY2lzZSwgYnV0IEkgZ3Vlc3MgdGhlIHBv aW50IGlzIHRvIG1vdmUgaW50byB0aGUgcmlnaHQgZGlyZWN0aW9uIGF0IHRoaXMgcG9pbnQuIChX aGljaCBpdCBkb2VzKS4NCg0K4oCcU2VjdXJpdHktcmVsYXRlZOKAnToNClRoaXJkIGJ1bGxldDog QXJlIHlvdSB0cnlpbmcgdG8gc2F5IOKAnEEgZGV2aWNlIG11c3QgYXV0b21hdGljYWxseSByZWNv dmVyIGZyb20gRG9TIGF0dGFja3PigJ0/IChXaGF0IGVsc2U/KSAgTWFrZXMgc2Vuc2UgdG8gbWUu DQpGb3VydGggYnVsbGV0OiBDYW4geW91IGdpdmUgYW4gZXhhbXBsZT8gRG8geW91IG1lYW4gdGhh dCB0aGUgc2VjdXJpdHkgcHJvdG9jb2xzIHNob3VsZCBub3Qgc2lnbmlmaWNhbnRseSBpbmNyZWFz ZSB0aGUgYXR0YWNrIHN1cmZhY2Ugb24gY29tcGFyaXNvbiB0byBhIGRldmljZSB3aXRob3V0IHN1 Y2ggcHJvdG9jb2xzPyBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUg4oCcbmV0d29yayBvdXRhZ2Xi gJ0gcG9pbnQuDQoNCkNhbiB5b3UgZXhwYW5kIG9uIOKAnGhvbW9nZW5vdXMgdHJ1c3QgbW9kZWxz 4oCdIHBsZWFzZT8NCg0KU29tZSBzdGF0ZW1lbnRzIG9uIHRoaXMgc2xpZGUgbWFrZSBtZSBuZXJ2 b3VzLCBsaWtlIHRoZSBsYXN0IGxpbmUg4oCcRGVwZW5kZW5jeSBvbiBvbi1ib2FyZCB0cnVzdGVk IHBsYXRmb3JtcyBhbmQgdHJ1c3RlZCBJL08gaW50ZXJmYWNlcyBzaG91bGQgYmUgcmVkdWNlZOKA nS4gQUNFIGlzIGRlZmluaW5nIDMgY2xhc3NlcyBvZiBkZXZpY2VzIHdpdGggdmFyeWluZyBjYXBh YmlsaXRpZXMsIGFuZCBJIHRoaW5rIHdlIHNob3VsZCBkbyB0aGUgc2FtZSwgcmlnaHQ/IFNvIHRo ZSBmYWN0IHRoYXQgbG93LWVuZCBkZXZpY2VzIG1heSBub3Qgc3VwcG9ydCB0cnVzdGVkIHBsYXRm b3JtIG1vZHVsZXMgc2hvdWxkIG5vdCBtZWFuIHdlIGRvbuKAmXQgc3VwcG9ydCBpdC4gSW4gZmFj dCwgSSB0aGluayB0aG9zZSBhcmUgYSBrZXkgZWxlbWVudCBpbiBhIHNlY3VyZSBzb2x1dGlvbiAo Zm9yIGEgY2VydGFpbiBkZXZpY2UgY2xhc3MsIGZvciBzdXJlKS4NCg0KSSBzdWdnZXN0IHdlIHN0 YXJ0IGludHJvZHVjaW5nIHRoZSBjb25jZXB0IG9mIGEg4oCcZG9tYWlu4oCdIGluIHRoaXMgZGVj ay4gVG8gbWUsIGEgZG9tYWluIGlzIGEgc2V0IG9mIG5vZGVzIHdpdGggYSBjb21tb24gdHJ1c3Qg YW5jaG9yLiBUaGF0IGNvdWxkIGJlIGEgQ0EtdHlwZSB0cnVzdCBhbmNob3IsIGJ1dCBpdCBjb3Vs ZCBhbHNvIGJlIGRvbmUgZGlmZmVyZW50bHksIGZvciBleGFtcGxlIGJ5IHByZS1zdGFnaW5nIGRv bWFpbi13aWRlIHNoYXJlZCBzZWNyZXRzLiBJbiB0aGUgYXV0aGVudGljYXRpb24gc3RlcCAoc2xp ZGUgNSksIGRldmljZXMgZXhjaGFuZ2UgYW5kIChwcm9iYWJseSkgdmFsaWRhdGUgdGhlaXIgaWRl bnRpdGllcy4gSWYgd2Ugd2FudCB0byByZWR1Y2UgZGVwZW5kZW5jaWVzIG9uIGNlbnRyYWwgcmVz b3VyY2VzIChzbGlkZSA0OiDigJxTZWN1cml0eSBwcm90b2NvbHMgc2hvdWxkIGFsbG93IHRvIGJl IHJ1biBsb2NhbGx5LCB3aXRob3V0IHRoaXJkIHBhcnR5IGludm9sdmVtZW50LCBpZiBhdCBhbGwg cG9zc2libGXigJ0pIHRoZW4gZWFjaCBub2RlIG5lZWRzIHRvIGJlIGFibGUgdG8gYXV0aGVudGlj YXRlIGFuZCBhdXRob3Jpc2UgZWFjaCBvdGhlciBub2RlLiBUaGUgc2ltcGxlc3QgZm9ybSBvZiBh dXRob3JpemF0aW9uIGlzIOKAnHRoaXMgbm9kZSBiZWxvbmdzIHRvIHRoZSBzYW1lIGRvbWFpbiwg SeKAmWxsIHJvdXRlIHRyYWZmaWMgdGhyb3VnaC9mcm9tIHRoaXMgZGV2aWNl4oCdLiBUaG91Z2h0 cz8NCg0KQ29udmVyc2VseSwgd2l0aG91dCB0aGUgY29uY2VwdCBvZiBhIGRvbWFpbiwgSSBkb27i gJl0IHJlYWxseSBzZWUgaG93IGF1dGhlbnRpY2F0aW9uIGNhbiB3b3JrPw0KDQpEZXZpY2UgZW5y b2xtZW50IChzbGlkZSA1KTogaW4geW91ciBtb2RlbCBhIGRldmljZSBhbHdheXMgZW5yb2xzIHRv IGFuIGFjY2VzcyBwb2ludC4gSSB0aGluayB3ZSBzaG91bGQgbWFrZSB0aGlzIG1vZGVsIG1vcmUg ZmxleGlibGUsIGFuZCBhbGxvdyBhbm90aGVyIGNsaWVudCB0byBwcm94eSBzdWNoIHByb2NlZHVy ZXMuIEluIGRyYWZ0LXByaXRpa2luLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFzdHJ1Y3R1cmVzIHdl IHNwZWFrIG9mIGEg4oCccHJveHnigJ0sIHdoaWNoIGNvdWxkIGJlIGluIHRoaXMgbW9kZWwgZWl0 aGVyIGFub3RoZXIgY2xpZW50IG9yIGFuIGFjY2VzcyBwb2ludC4NCg0KSSB3b3VsZCBwcmVmZXIg aWYgd2UgaGFkIGEgZGlhZ3JhbSB0aGF0IHJlZmxlY3RzIHRoYXQuIE9yLCBpbiBjYXNlIHdlIGNh bm5vdCBzdXBwb3J0IHRoYXQsIHdlIHNob3VsZCBzdGF0ZSB0aGF0IGVucm9sbWVudCBNVVNUIGhh cHBlbiBpbiB0aGUgcmVhY2ggb2YgYW4gYWNjZXNzIHBvaW50LiAoQmVjYXVzZSB0aGF0IHdvdWxk IGJlIHRoZSBjb25zZXF1ZW5jZSwgcmlnaHQ/KQ0KDQrigJxBdXRob3JpemF0aW9uIGRlY2lzaW9u IG1heSBiZSBkZWxlZ2F0ZWQgdG8gc2VydmVyIEtEQyBvciBvdGhlciAzcmQtcGFydHkgZGV2aWNl 4oCdOiBJbiBteSBicmFpbiB0aGUgS0RDIEFMV0FZUyBtYWtlcyB0aGUgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbnMuIE90aGVyIG5vZGVzIG1heSBjYWNoZSBzdWNoIGluZm9ybWF0aW9uIG9mIGNvdXJz ZS4gSS5lLiwgYSBub2RlIG9yIGFjY2VzcyBwb2ludCBjYW5ub3QgbWFrZSBhbiBhdXRob3JpemF0 aW9uIGRlY2lzaW9uLiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpTbGlkZSA1LCBib3R0b206 IElmIEkgcmVhZCB0aGlzIGNvcnJlY3RseSwgd2UgZG8gTk9UIGV4cGVjdCBhIG5ldyBjbGllbnQg dG8gaGF2ZSBhbiBhc3NpZ25lZCBJUCBhZGRyZXNzIEJFRk9SRSB0aGlzIHByb2Nlc3Mgc3RhcnRz PyAoaW4geW91ciBmbG93LCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgY29tZXMgYWZ0ZXIgYXV0aG9y aXphdGlvbikuIFRvIGJlIGNsZWFyLCBJIGZ1bGx5IHN1cHBvcnQgdGhpcywgb3VyIG1vZGVsIGlu IGRyYWZ0LXByaXRpa2luLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFzdHJ1Y3R1cmVzIGFzc3VtZXMg b25seSBsaW5rIGxvY2FsIGFkZHJlc3Nlcy4gQXJlIHlvdSB0aGlua2luZyBhbG9uZyB0aGUgc2Ft ZSBsaW5lcz8NCg0KU2xpZGUgNjog4oCcQWNjZXNzIFBvaW50IEIgZGVjaWRlcyBvbiB3aGV0aGVy L2hvdyB0byBhdXRob3JpemUgZGV2aWNlIEHigJ06IEhvdyBjYW4gYW4gYWNjZXNzIHBvaW50IG1h a2UgdGhpcyBkZWNpc2lvbj8gSW4gbXkgd29ybGQsIGl0IGNhbuKAmXQuIChzZWUgYWJvdmUpLiBD YW4geW91IGdpdmUgYW4gZXhhbXBsZSBoZXJlIHBsZWFzZT8NCg0KU2xpZGUgNzogQ2FuIHlvdSBk ZWZpbmUg4oCcVGhpcmQgcGFydHnigJ0gcGxlYXNlPyBJbiBteSB1bmRlcnN0YW5kaW5nLCBub3Jt YWxseSB0aGUgS0RDIGlzIHBhcnQgb2YgdGhlIOKAnGRvbWFpbuKAnSBhcyBJIGNhbGwgaXQuIFNv IEkgd291bGRu4oCZdCBjYWxsIGl0IOKAnHRoaXJkIHBhcnR54oCdLiBJbiBvdXIgbW9kZWwgdGhl cmUgaXMgdGhlIOKAnE1BU0HigJ0sIHdoaWNoIGlzIGEgdmVuZG9yIG9yIGludGVncmF0b3IgY2xv dWQgc2VydmljZS4gVGhhdCB0byBtZSB3b3VsZCBiZSBhIHRoaXJkIHBhcnR5LiBBcmUgd2Ugc2F5 aW5nIHRoZSBzYW1lPw0KDQpMZXQgbWUgc3RvcCBoZXJlIGZvciBub3csIGVub3VnaCBxdWVzdGlv bnMgZm9yIG9uZSBtYWlsISDimLogIEdlbmVyYWxseSwgaXQgd291bGQgYmUgZ3JlYXQgaWYgd2Ug Y291bGQgbWFwIG91ciB0d28gd29ybGRzIHRvZ2V0aGVyLCBzbyB0aGF0IHdl4oCZcmUgdGFsa2lu ZyB0aGUgc2FtZSBsYW5ndWFnZS4gU29ycnkgaWYgSeKAmW0gdGhlIG9kZCBvbmUgb3V0IGhlcmUs IEnigJlkIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgcGF0aWVudCBoZWxwIHRob3VnaCEgOi0pDQoN ClRhbGsgbGF0ZXIgaW4gdGhlIDZ0aXNjaCBzZWN1cml0eSBjYWxsLg0KDQpNaWNoYWVsDQoNCg0K DQoNCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134xmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVuw6ksIHRlYW0sIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5VcCBmcm9udCwgSSBoYXZlbuKAmXQgaGFkIHRoZSB0aW1lIHRvIGNh dGNoIHVwIHdpdGggdGhlIGRldGFpbHMgb2YgdGhlIFdHLCBzbyBtYXkgbm90IGJlIGF3YXJlIG9m IGNvbnRleHQsIHByZXZpb3VzIGRlY2lzaW9ucywgZXRjLiBQbGVhc2UgbGV0IG1lIGtub3cgd2hl cmUgSeKAmW0gbWlzc2luZyB0aGUgcG9pbnQgYW5kIGVkdWNhdGUgbWUuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q29tbWVudHMgb24g4oCcNi1UaVNDSCBTZWN1cml0eSAtIFNvbWUgTm90ZXMg YW5kIFRob3VnaHRzIG9uIFNlY3VyaXR5IFByb3BlcnRpZXM7IERhdGU6IDIwMTQtMDMtMjTigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2xpZGUgNDogQWxsIHN0YXRlbWVudHMgYXJlIGhpZ2gg bGV2ZWwgYW5kIG5vdCB5ZXQgcHJlY2lzZSwgYnV0IEkgZ3Vlc3MgdGhlIHBvaW50IGlzIHRvIG1v dmUgaW50byB0aGUgcmlnaHQgZGlyZWN0aW9uIGF0IHRoaXMgcG9pbnQuIChXaGljaCBpdCBkb2Vz KS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxTZWN1cml0eS1yZWxhdGVk4oCdOiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXJkIGJ1bGxldDogQXJlIHlvdSB0 cnlpbmcgdG8gc2F5IOKAnEEgZGV2aWNlIG11c3QgYXV0b21hdGljYWxseSByZWNvdmVyIGZyb20g RG9TIGF0dGFja3PigJ0/IChXaGF0IGVsc2U/KSZuYnNwOyBNYWtlcyBzZW5zZSB0byBtZS4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm91cnRoIGJ1bGxldDogQ2FuIHlv dSBnaXZlIGFuIGV4YW1wbGU/IERvIHlvdSBtZWFuIHRoYXQgdGhlIHNlY3VyaXR5IHByb3RvY29s cyBzaG91bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlIGF0dGFjayBzdXJmYWNlIG9u IGNvbXBhcmlzb24gdG8gYSBkZXZpY2Ugd2l0aG91dCBzdWNoIHByb3RvY29scz8gSSBkb27igJl0 IHVuZGVyc3RhbmQgdGhlIOKAnG5ldHdvcmsgb3V0YWdl4oCdIHBvaW50Lg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNhbiB5b3UgZXhwYW5kIG9uIOKAnGhvbW9nZW5vdXMgdHJ1c3QgbW9kZWxz 4oCdIHBsZWFzZT8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgc3RhdGVtZW50cyBvbiB0 aGlzIHNsaWRlIG1ha2UgbWUgbmVydm91cywgbGlrZSB0aGUgbGFzdCBsaW5lIOKAnERlcGVuZGVu Y3kgb24gb24tYm9hcmQgdHJ1c3RlZCBwbGF0Zm9ybXMgYW5kIHRydXN0ZWQgSS9PIGludGVyZmFj ZXMgc2hvdWxkIGJlIHJlZHVjZWTigJ0uIEFDRSBpcyBkZWZpbmluZyAzIGNsYXNzZXMgb2YgZGV2 aWNlcyB3aXRoIHZhcnlpbmcgY2FwYWJpbGl0aWVzLCBhbmQgSSB0aGluayB3ZSBzaG91bGQNCiBk byB0aGUgc2FtZSwgcmlnaHQ/IFNvIHRoZSBmYWN0IHRoYXQgbG93LWVuZCBkZXZpY2VzIG1heSBu b3Qgc3VwcG9ydCB0cnVzdGVkIHBsYXRmb3JtIG1vZHVsZXMgc2hvdWxkIG5vdCBtZWFuIHdlIGRv buKAmXQgc3VwcG9ydCBpdC4gSW4gZmFjdCwgSSB0aGluayB0aG9zZSBhcmUgYSBrZXkgZWxlbWVu dCBpbiBhIHNlY3VyZSBzb2x1dGlvbiAoZm9yIGEgY2VydGFpbiBkZXZpY2UgY2xhc3MsIGZvciBz dXJlKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0IHdlIHN0YXJ0IGludHJvZHVj aW5nIHRoZSBjb25jZXB0IG9mIGEg4oCcZG9tYWlu4oCdIGluIHRoaXMgZGVjay4gVG8gbWUsIGEg ZG9tYWluIGlzIGEgc2V0IG9mIG5vZGVzIHdpdGggYSBjb21tb24gdHJ1c3QgYW5jaG9yLiBUaGF0 IGNvdWxkIGJlIGEgQ0EtdHlwZSB0cnVzdCBhbmNob3IsIGJ1dCBpdCBjb3VsZCBhbHNvIGJlIGRv bmUgZGlmZmVyZW50bHksIGZvciBleGFtcGxlIGJ5IHByZS1zdGFnaW5nDQogZG9tYWluLXdpZGUg c2hhcmVkIHNlY3JldHMuIEluIHRoZSBhdXRoZW50aWNhdGlvbiBzdGVwIChzbGlkZSA1KSwgZGV2 aWNlcyBleGNoYW5nZSBhbmQgKHByb2JhYmx5KSB2YWxpZGF0ZSB0aGVpciBpZGVudGl0aWVzLiBJ ZiB3ZSB3YW50IHRvIHJlZHVjZSBkZXBlbmRlbmNpZXMgb24gY2VudHJhbCByZXNvdXJjZXMgKHNs aWRlIDQ6IOKAnFNlY3VyaXR5IHByb3RvY29scyBzaG91bGQgYWxsb3cgdG8gYmUgcnVuIGxvY2Fs bHksIHdpdGhvdXQgdGhpcmQNCiBwYXJ0eSBpbnZvbHZlbWVudCwgaWYgYXQgYWxsIHBvc3NpYmxl 4oCdKSB0aGVuIGVhY2ggbm9kZSBuZWVkcyB0byBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSBhbmQg YXV0aG9yaXNlIGVhY2ggb3RoZXIgbm9kZS4gVGhlIHNpbXBsZXN0IGZvcm0gb2YgYXV0aG9yaXph dGlvbiBpcyDigJx0aGlzIG5vZGUgYmVsb25ncyB0byB0aGUgc2FtZSBkb21haW4sIEnigJlsbCBy b3V0ZSB0cmFmZmljIHRocm91Z2gvZnJvbSB0aGlzIGRldmljZeKAnS4gVGhvdWdodHM/DQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29udmVyc2VseSwgd2l0aG91dCB0aGUgY29uY2VwdCBvZiBh IGRvbWFpbiwgSSBkb27igJl0IHJlYWxseSBzZWUgaG93IGF1dGhlbnRpY2F0aW9uIGNhbiB3b3Jr Pw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRldmljZSBlbnJvbG1lbnQgKHNsaWRlIDUpOiBp biB5b3VyIG1vZGVsIGEgZGV2aWNlIGFsd2F5cyBlbnJvbHMgdG8gYW4gYWNjZXNzIHBvaW50LiBJ IHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoaXMgbW9kZWwgbW9yZSBmbGV4aWJsZSwgYW5kIGFsbG93 IGFub3RoZXIgY2xpZW50IHRvIHByb3h5IHN1Y2ggcHJvY2VkdXJlcy4gSW4gZHJhZnQtcHJpdGlr aW4tYm9vdHN0cmFwcGluZy1rZXlpbmZyYXN0cnVjdHVyZXMNCiB3ZSBzcGVhayBvZiBhIOKAnHBy b3h54oCdLCB3aGljaCBjb3VsZCBiZSBpbiB0aGlzIG1vZGVsIGVpdGhlciBhbm90aGVyIGNsaWVu dCBvciBhbiBhY2Nlc3MgcG9pbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBw cmVmZXIgaWYgd2UgaGFkIGEgZGlhZ3JhbSB0aGF0IHJlZmxlY3RzIHRoYXQuIE9yLCBpbiBjYXNl IHdlIGNhbm5vdCBzdXBwb3J0IHRoYXQsIHdlIHNob3VsZCBzdGF0ZSB0aGF0IGVucm9sbWVudCBN VVNUIGhhcHBlbiBpbiB0aGUgcmVhY2ggb2YgYW4gYWNjZXNzIHBvaW50LiAoQmVjYXVzZSB0aGF0 IHdvdWxkIGJlIHRoZSBjb25zZXF1ZW5jZSwgcmlnaHQ/KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij7igJxBdXRob3JpemF0aW9uIGRlY2lzaW9uIG1heSBiZSBkZWxlZ2F0ZWQgdG8gc2VydmVyIEtE QyBvciBvdGhlciAzcmQtcGFydHkgZGV2aWNl4oCdOiBJbiBteSBicmFpbiB0aGUgS0RDIEFMV0FZ UyBtYWtlcyB0aGUgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMuIE90aGVyIG5vZGVzIG1heSBjYWNo ZSBzdWNoIGluZm9ybWF0aW9uIG9mIGNvdXJzZS4gSS5lLiwgYSBub2RlIG9yIGFjY2VzcyBwb2lu dCBjYW5ub3QgbWFrZQ0KIGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24uIEFtIEkgbWlzc2luZyBz b21ldGhpbmc/IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbGlkZSA1LCBib3R0b206IElmIEkg cmVhZCB0aGlzIGNvcnJlY3RseSwgd2UgZG8gTk9UIGV4cGVjdCBhIG5ldyBjbGllbnQgdG8gaGF2 ZSBhbiBhc3NpZ25lZCBJUCBhZGRyZXNzIEJFRk9SRSB0aGlzIHByb2Nlc3Mgc3RhcnRzPyAoaW4g eW91ciBmbG93LCBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgY29tZXMgYWZ0ZXIgYXV0aG9yaXphdGlv bikuIFRvIGJlIGNsZWFyLCBJIGZ1bGx5IHN1cHBvcnQgdGhpcywgb3VyDQogbW9kZWwgaW4gZHJh ZnQtcHJpdGlraW4tYm9vdHN0cmFwcGluZy1rZXlpbmZyYXN0cnVjdHVyZXMgYXNzdW1lcyBvbmx5 IGxpbmsgbG9jYWwgYWRkcmVzc2VzLiBBcmUgeW91IHRoaW5raW5nIGFsb25nIHRoZSBzYW1lIGxp bmVzPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNsaWRlIDY6IOKAnEFjY2VzcyBQb2ludCBC IGRlY2lkZXMgb24gd2hldGhlci9ob3cgdG8gYXV0aG9yaXplIGRldmljZSBB4oCdOiBIb3cgY2Fu IGFuIGFjY2VzcyBwb2ludCBtYWtlIHRoaXMgZGVjaXNpb24/IEluIG15IHdvcmxkLCBpdCBjYW7i gJl0LiAoc2VlIGFib3ZlKS4gQ2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgaGVyZSBwbGVhc2U/DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2xpZGUgNzogQ2FuIHlvdSBkZWZpbmUg4oCcVGhpcmQg cGFydHnigJ0gcGxlYXNlPyBJbiBteSB1bmRlcnN0YW5kaW5nLCBub3JtYWxseSB0aGUgS0RDIGlz IHBhcnQgb2YgdGhlIOKAnGRvbWFpbuKAnSBhcyBJIGNhbGwgaXQuIFNvIEkgd291bGRu4oCZdCBj YWxsIGl0IOKAnHRoaXJkIHBhcnR54oCdLiBJbiBvdXIgbW9kZWwgdGhlcmUgaXMgdGhlIOKAnE1B U0HigJ0sIHdoaWNoIGlzIGEgdmVuZG9yIG9yIGludGVncmF0b3IgY2xvdWQgc2VydmljZS4NCiBU aGF0IHRvIG1lIHdvdWxkIGJlIGEgdGhpcmQgcGFydHkuIEFyZSB3ZSBzYXlpbmcgdGhlIHNhbWU/ IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUgc3RvcCBoZXJlIGZvciBub3csIGVub3Vn aCBxdWVzdGlvbnMgZm9yIG9uZSBtYWlsISA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj4NCko8L3NwYW4+Jm5ic3A7IEdlbmVyYWxseSwgaXQgd291bGQgYmUgZ3JlYXQgaWYgd2Ug Y291bGQgbWFwIG91ciB0d28gd29ybGRzIHRvZ2V0aGVyLCBzbyB0aGF0IHdl4oCZcmUgdGFsa2lu ZyB0aGUgc2FtZSBsYW5ndWFnZS4gU29ycnkgaWYgSeKAmW0gdGhlIG9kZCBvbmUgb3V0IGhlcmUs IEnigJlkIHJlYWxseSBhcHByZWNpYXRlIHlvdXIgcGF0aWVudCBoZWxwIHRob3VnaCEgOi0pDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFsayBsYXRlciBpbiB0aGUgNnRpc2NoIHNlY3VyaXR5 IGNhbGwuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWNoYWVsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134xmbrcdx14ciscoc_-- From nobody Mon Mar 31 07:09:33 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46771A0A6F for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 raNUaMdAwkaO for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:09:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0540E1A083D for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 07:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4182; q=dns/txt; s=iport; t=1396274966; x=1397484566; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=zAR2WINs5CBbhpN3POdCF6dCZ9IzzVdbDMXT3XJ29sg=; b=aN+OaBUYA+xhTcygeUMnogvIs76XPllRnAE3oxCIJNBqLIhv5VwCE7GT CukhZpAjl0GSHTiBos2FTYJGHJP/sDZyF/v7XTOGi/TrXlwXbLLiThQyp 1DSAO5svWufA5SN0MpatFPtAR3arowKttTB8ThPRFVU2nedxf5TxNO8kf o=; X-IronPort-AV: E=Sophos;i="4.97,765,1389744000"; d="scan'208,217";a="314090992" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 31 Mar 2014 14:09:26 +0000 Received: from [161.44.68.195] ([161.44.68.195]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2VE9O7Z012436; Mon, 31 Mar 2014 14:09:25 GMT Message-ID: <53397714.1050003@cisco.com> Date: Mon, 31 Mar 2014 10:09:24 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------000702080508070902000004" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/gVOfXAtl6cry0Rras7mksA0i35I Subject: Re: [6tisch-security] =?windows-1252?q?Comments_on_=936-TiSCH_Securit?= =?windows-1252?q?y_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Da?= =?windows-1252?q?te=3A_2014-03-24=94?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:09:31 -0000 This is a multi-part message in MIME format. --------------000702080508070902000004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote: > > Some statements on this slide make me nervous, like the last line > “Dependency on on-board trusted platforms and trusted I/O interfaces > should be reduced”. ACE is defining 3 classes of devices with varying > capabilities, and I think we should do the same, right? > Hi Michael Can you clarify re: the three device classes ACE is defining? I want to be sure we're not confusing these with CORE device classifications. > So the fact that low-end devices may not support trusted platform > modules should not mean we don’t support it. In fact, I think those > are a key element in a secure solution (for a certain device class, > for sure). > > Agreed. Cheers --------------000702080508070902000004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote:

 

Some statements on this slide make me nervous, like the last line “Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced”. ACE is defining 3 classes of devices with varying capabilities, and I think we should do the same, right?


Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be sure we're not confusing these with CORE device classifications.

So the fact that low-end devices may not support trusted platform modules should not mean we don’t support it. In fact, I think those are a key element in a secure solution (for a certain device class, for sure).

 



Agreed.

Cheers



--------------000702080508070902000004-- From nobody Mon Mar 31 07:19:59 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20111A0A1B for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.21 X-Spam-Level: X-Spam-Status: No, score=-9.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no 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 yht9iM7MjZfb for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:19:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 394001A087B for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 07:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6306; q=dns/txt; s=iport; t=1396275588; x=1397485188; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ILHH1HcZTyVT+SezbVXMVPoNYRfImJJpeJIHIz42568=; b=gbXRJWupuj+K4YXScuybGqeesOGpBmqlOzQVR0JiIeh6Q860rK/aydGK iltlJNwIDFdvmaxgXvsD7rmq66RfpJOjXt5Yn9GjJZyvkh57mEONeXKXi WwInVLg7aOP2i7hCLzBFi/cI9Kw0jNNxMpWuyEpGsyAAFpGqaCKjxfv02 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAOB4OVOtJA2I/2dsb2JhbABZgkJEO1fDF4EfFnSCJQEBAQICLVwCAQgRAwEBAQsZCzIdCAEBBAESCAESh14N0EUXjk4gGIMkgRQEqwOBcYE/gis X-IronPort-AV: E=Sophos; i="4.97,765,1389744000"; d="scan'208,217"; a="31705195" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 31 Mar 2014 14:19:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VEJl0d006675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 14:19:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.150]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 09:19:47 -0500 From: "Michael Behringer (mbehring)" To: "Paul Duffy (paduffy)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: =?Windows-1252?Q?[6tisch-security]_Comments_on_=936-TiSCH_Security_-_Some?= =?Windows-1252?Q?_Notes_and_Thoughts_on_Security_Properties;_Date:_2014-0?= =?Windows-1252?Q?3-24=94?= Thread-Index: Ac9Ko9OTehHhREeyQVKPjFHxR0JWygCcObgAAAolYtA= Date: Mon, 31 Mar 2014 14:19:46 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> <53397714.1050003@cisco.com> In-Reply-To: <53397714.1050003@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/tQ2yjvvw4zyHacOtWx3R7OKjWTU Subject: Re: [6tisch-security] =?windows-1252?q?Comments_on_=936-TiSCH_Securit?= =?windows-1252?q?y_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Da?= =?windows-1252?q?te=3A_2014-03-24=94?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:19:53 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Paul, I=92m referring to slide 8 of http://www.ietf.org/proceedings/89/slid= es/slides-89-ace-2.pdf. Michael From: Paul Duffy (paduffy) Sent: 31 March 2014 16:09 To: Michael Behringer (mbehring); 6tisch-security@ietf.org Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Some Notes= and Thoughts on Security Properties; Date: 2014-03-24=94 On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote: Some statements on this slide make me nervous, like the last line =93Depend= ency on on-board trusted platforms and trusted I/O interfaces should be red= uced=94. ACE is defining 3 classes of devices with varying capabilities, an= d I think we should do the same, right? Hi Michael Can you clarify re: the three device classes ACE is defining? I want to be = sure we're not confusing these with CORE device classifications. So the fact that low-end devices may not support trusted platform modules s= hould not mean we don=92t support it. In fact, I think those are a key elem= ent in a secure solution (for a certain device class, for sure). Agreed. Cheers --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Paul, I=92m referring = to slide 8 of h= ttp://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Som= e Notes and Thoughts on Security Properties; Date: 2014-03-24=94=

 

On 3/31/2014 7:17 AM, Michael Behringer (mbehring) w= rote:

 

Some statements on this slide make me nervous, like = the last line =93Dependency on on-board trusted platforms and trusted I/O i= nterfaces should be reduced=94. ACE is defining 3 classes of devices with v= arying capabilities, and I think we should do the same, right?


Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be = sure we're not confusing these with CORE device classifications.


So the fact that low-end devices may not support tru= sted platform modules should not mean we don=92t support it. In fact, I thi= nk those are a key element in a secure solution (for a certain device class= , for sure).

 

&nbs= p;


Agreed.

Cheers


--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7xmbrcdx14ciscoc_-- From nobody Mon Mar 31 07:21:43 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB51A0A1B for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 9IbQXL8vYang for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:21:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B44C61A087B for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 07:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7299; q=dns/txt; s=iport; t=1396275695; x=1397485295; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=WBckZ4Stb9K+iLNEtP0k/Nlhi4vGjYSjQmJ1jeq6wr4=; b=M+IdV0ziTybWgznXAVe8jaKQCvVTJH+o6Y/SRT5jXMOpYEZZBzzY96Jb Zaz01lcmdTToWM93E7t2/fGeJozZOtPGThFL5EADoJ/5mHjSvhP0Yr3pY OUj8583nAMigDtK80lOaU/T+6s+lZCZGsnMWk7VRVvikmia/D2IkEnEyW E=; X-IronPort-AV: E=Sophos;i="4.97,765,1389744000"; d="scan'208,217";a="314148588" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 31 Mar 2014 14:21:34 +0000 Received: from [161.44.68.195] ([161.44.68.195]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VELXio014021; Mon, 31 Mar 2014 14:21:34 GMT Message-ID: <533979ED.9090406@cisco.com> Date: Mon, 31 Mar 2014 10:21:33 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> <53397714.1050003@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------050606040301050205000802" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/HaLmUNEnD4eQTgg9OgdlXVu8zGE Subject: Re: [6tisch-security] =?windows-1252?q?Comments_on_=936-TiSCH_Securit?= =?windows-1252?q?y_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Da?= =?windows-1252?q?te=3A_2014-03-24=94?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:21:40 -0000 This is a multi-part message in MIME format. --------------050606040301050205000802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit OK, you were referring to the core designations. Thanks On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote: > > Paul, I’m referring to slide 8 of > http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf. > > Michael > > *From:*Paul Duffy (paduffy) > *Sent:* 31 March 2014 16:09 > *To:* Michael Behringer (mbehring); 6tisch-security@ietf.org > *Subject:* Re: [6tisch-security] Comments on “6-TiSCH Security - Some > Notes and Thoughts on Security Properties; Date: 2014-03-24” > > On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote: > > Some statements on this slide make me nervous, like the last line > “Dependency on on-board trusted platforms and trusted I/O > interfaces should be reduced”. ACE is defining 3 classes of > devices with varying capabilities, and I think we should do the > same, right? > > > Hi Michael > > Can you clarify re: the three device classes ACE is defining? I want > to be sure we're not confusing these with CORE device classifications. > > > So the fact that low-end devices may not support trusted platform > modules should not mean we don’t support it. In fact, I think those > are a key element in a secure solution (for a certain device class, > for sure). > > > Agreed. > > Cheers > > --------------050606040301050205000802 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
OK, you were referring to the core designations.  Thanks


On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote:

Paul, I’m referring to slide 8 of http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

 

On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote:

 

Some statements on this slide make me nervous, like the last line “Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced”. ACE is defining 3 classes of devices with varying capabilities, and I think we should do the same, right?


Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be sure we're not confusing these with CORE device classifications.


So the fact that low-end devices may not support trusted platform modules should not mean we don’t support it. In fact, I think those are a key element in a secure solution (for a certain device class, for sure).

 

 


Agreed.

Cheers



--------------050606040301050205000802-- From nobody Mon Mar 31 07:40:55 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8321A0A24 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 De2qz1NwyHio for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:40:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B783D1A6F2D for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 07:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8956; q=dns/txt; s=iport; t=1396276843; x=1397486443; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=H1u49ZbYJN4+WIr1/CYZ/uG/Pl3IlriS7p6LIQRbbBc=; b=V1wSCBwEGsRldTg2OGbT/j/2F1oK7mNWdlKzYcbbMeUEEJ2J2d5sBcsF qzG2Iby56MIK6L4v+cR7nKpBY+7/6Vm2F3wW9jliZcAowOMXpRFvYnwCs Xjm5we1EOCjV55MlFY894QQPszx1mVN6+jQexrqxZ0Rgw31J6MsRZZy4a o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMFAAp+OVOtJV2a/2dsb2JhbABZgkJEO1fDF4EfFnSCJQEBAQICLUAcAgEIEQMBAQELGQQHMhQJCAEBBAESCAESh14N0EsXjk4gFwGDJIEUBKsDgXGBP4Ir X-IronPort-AV: E=Sophos;i="4.97,765,1389744000"; d="scan'208,217";a="313875070" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 31 Mar 2014 14:40:41 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VEefAE003239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 14:40:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.150]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 09:40:40 -0500 From: "Michael Behringer (mbehring)" To: "Paul Duffy (paduffy)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: =?Windows-1252?Q?[6tisch-security]_Comments_on_=936-TiSCH_Security_-_Some?= =?Windows-1252?Q?_Notes_and_Thoughts_on_Security_Properties;_Date:_2014-0?= =?Windows-1252?Q?3-24=94?= Thread-Index: Ac9Ko9OTehHhREeyQVKPjFHxR0JWygCcObgAAAolYtD//7I5gIAATqpQ Date: Mon, 31 Mar 2014 14:40:39 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> <53397714.1050003@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7@xmb-rcd-x14.cisco.com> <533979ED.9090406@cisco.com> In-Reply-To: <533979ED.9090406@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.139] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/5qPBaDJSFyPsV0NDif6PwTLpRsQ Subject: Re: [6tisch-security] =?windows-1252?q?Comments_on_=936-TiSCH_Securit?= =?windows-1252?q?y_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Da?= =?windows-1252?q?te=3A_2014-03-24=94?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:40:48 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, still learning a lot here, I=92m not a =93small device=94 guy at all= , so will need to be corrected from time to time ;-) Michael From: Paul Duffy (paduffy) Sent: 31 March 2014 16:22 To: Michael Behringer (mbehring); 6tisch-security@ietf.org Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Some Notes= and Thoughts on Security Properties; Date: 2014-03-24=94 OK, you were referring to the core designations. Thanks On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote: Paul, I=92m referring to slide 8 of http://www.ietf.org/proceedings/89/slid= es/slides-89-ace-2.pdf. Michael From: Paul Duffy (paduffy) Sent: 31 March 2014 16:09 To: Michael Behringer (mbehring); 6tisch-security@ietf.org Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Some Notes= and Thoughts on Security Properties; Date: 2014-03-24=94 On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote: Some statements on this slide make me nervous, like the last line =93Depend= ency on on-board trusted platforms and trusted I/O interfaces should be red= uced=94. ACE is defining 3 classes of devices with varying capabilities, an= d I think we should do the same, right? Hi Michael Can you clarify re: the three device classes ACE is defining? I want to be = sure we're not confusing these with CORE device classifications. So the fact that low-end devices may not support trusted platform modules s= hould not mean we don=92t support it. In fact, I think those are a key elem= ent in a secure solution (for a certain device class, for sure). Agreed. Cheers --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Sorry, still learning = a lot here, I=92m not a =93small device=94 guy at all, so will need to be c= orrected from time to time ;-)

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:22
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Som= e Notes and Thoughts on Security Properties; Date: 2014-03-24=94=

 

OK, you were referring to the core designations.&nbs= p; Thanks


On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote:

Paul, I=92m referring = to slide 8 of h= ttp://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on =936-TiSCH Security - Som= e Notes and Thoughts on Security Properties; Date: 2014-03-24=94

 

On 3/31/2014 7:17 AM, Michael Behringer (mbehring) w= rote:

 

Some statements on this slide make me nervous, like = the last line =93Dependency on on-board trusted platforms and trusted I/O i= nterfaces should be reduced=94. ACE is defining 3 classes of devices with v= arying capabilities, and I think we should do the same, right?


Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be = sure we're not confusing these with CORE device classifications.



So the fact that low-end devices may not support tru= sted platform modules should not mean we don=92t support it. In fact, I thi= nk those are a key element in a secure solution (for a certain device class= , for sure).

 

 <= /o:p>


Agreed.

Cheers



&nbs= p;

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783xmbrcdx14ciscoc_-- From nobody Mon Mar 31 07:43:55 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29F51A6F26 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 hdIrOsMi9xVG for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 07:43:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 714F81A6F22 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 07:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10758; q=dns/txt; s=iport; t=1396277009; x=1397486609; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=CXTFZ3WMAe6Y498+npGd1fV4CgDpHsAOV+Avi0OeoGQ=; b=Jky3OwM91Q4Y9ywEGFSnVLy2xJJyyp19Vc6dbNxHx5khGAPz/ot2gUVU R0Ojjbkbpb0Mtn/Hc3sHpiYX88ChdlWYs78HuTS0l1kdaLZG5SFzBa/VC qFynx66Jk11b7YVrfgHgsq8NCHQDG3vrRfMzCkESFZXoZ9mVsq6PaCwPS k=; X-IronPort-AV: E=Sophos;i="4.97,765,1389744000"; d="scan'208,217";a="314059700" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 31 Mar 2014 14:43:29 +0000 Received: from [161.44.68.195] ([161.44.68.195]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2VEhSwN005484; Mon, 31 Mar 2014 14:43:28 GMT Message-ID: <53397F10.8060500@cisco.com> Date: Mon, 31 Mar 2014 10:43:28 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9134@xmb-rcd-x14.cisco.com> <53397714.1050003@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D96C7@xmb-rcd-x14.cisco.com> <533979ED.9090406@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF1D9D9783@xmb-rcd-x14.cisco.com> Content-Type: multipart/alternative; boundary="------------060903070901060602090202" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/KUVbG93CBr9KnDLW-98epRA8Zuo Subject: Re: [6tisch-security] =?windows-1252?q?Comments_on_=936-TiSCH_Securit?= =?windows-1252?q?y_-_Some_Notes_and_Thoughts_on_Security_Properties=3B_Da?= =?windows-1252?q?te=3A_2014-03-24=94?= X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:43:43 -0000 This is a multi-part message in MIME format. --------------060903070901060602090202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit No worries at all. I'm in the process of reviewing several related IETF and IEEE constrained security efforts. Just making sure I've got them lined up correctly. On 3/31/2014 10:40 AM, Michael Behringer (mbehring) wrote: > > Sorry, still learning a lot here, I’m not a “small device” guy at all, > so will need to be corrected from time to time ;-) > > Michael > > *From:*Paul Duffy (paduffy) > *Sent:* 31 March 2014 16:22 > *To:* Michael Behringer (mbehring); 6tisch-security@ietf.org > *Subject:* Re: [6tisch-security] Comments on “6-TiSCH Security - Some > Notes and Thoughts on Security Properties; Date: 2014-03-24” > > OK, you were referring to the core designations. Thanks > > > On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote: > > Paul, I’m referring to slide 8 of > http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf. > > Michael > > *From:*Paul Duffy (paduffy) > *Sent:* 31 March 2014 16:09 > *To:* Michael Behringer (mbehring); 6tisch-security@ietf.org > > *Subject:* Re: [6tisch-security] Comments on “6-TiSCH Security - > Some Notes and Thoughts on Security Properties; Date: 2014-03-24” > > On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote: > > Some statements on this slide make me nervous, like the last > line “Dependency on on-board trusted platforms and trusted I/O > interfaces should be reduced”. ACE is defining 3 classes of > devices with varying capabilities, and I think we should do > the same, right? > > > Hi Michael > > Can you clarify re: the three device classes ACE is defining? I > want to be sure we're not confusing these with CORE device > classifications. > > > > So the fact that low-end devices may not support trusted platform > modules should not mean we don’t support it. In fact, I think > those are a key element in a secure solution (for a certain device > class, for sure). > > > Agreed. > > Cheers > > > --------------060903070901060602090202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
No worries at all.

I'm in the process of reviewing several related IETF and IEEE constrained security efforts.  Just making sure I've got them lined up correctly.


On 3/31/2014 10:40 AM, Michael Behringer (mbehring) wrote:

Sorry, still learning a lot here, I’m not a “small device” guy at all, so will need to be corrected from time to time ;-)

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:22
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

 

OK, you were referring to the core designations.  Thanks


On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote:

Paul, I’m referring to slide 8 of http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.

 

Michael

 

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

 

On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote:

 

Some statements on this slide make me nervous, like the last line “Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced”. ACE is defining 3 classes of devices with varying capabilities, and I think we should do the same, right?


Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be sure we're not confusing these with CORE device classifications.



So the fact that low-end devices may not support trusted platform modules should not mean we don’t support it. In fact, I think those are a key element in a secure solution (for a certain device class, for sure).

 

 


Agreed.

Cheers



 


--------------060903070901060602090202-- From nobody Mon Mar 31 11:24:01 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045441A6F77 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 11:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 eSPbcTiEB46u for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 11:23:55 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by ietfa.amsl.com (Postfix) with ESMTP id C5EFB1A08B3 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 11:23:54 -0700 (PDT) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o144.mxlogic.net(mxl_mta-8.0.0-0) with ESMTP id 5b2b9335.0.24191.00-299.66976.p01c11o144.mxlogic.net (envelope-from ); Mon, 31 Mar 2014 12:23:51 -0600 (MDT) X-MXL-Hash: 5339b2b724d76ad2-b679dfc4f7f661374c4cbd59540f63ed5630995c Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 4E86274099 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 11:23:49 -0700 (PDT) From: Jonathan Simon Content-Type: multipart/alternative; boundary="Apple-Mail=_B17BB287-6A83-432A-9FF6-D5C7838635AC" Message-Id: <03E348D4-66F0-4A1A-953A-5D173DA131E4@linear.com> Date: Mon, 31 Mar 2014 11:25:37 -0700 To: 6tisch-security@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AnalysisOut: [v=2.1 cv=dsNVCjQ4 c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:17 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqDINYqSAAAA:8 a] X-AnalysisOut: [=YlVTAMxIAAAA:8 a=MrN2XfGy36kjgnryYe4A:9 a=mTJJ0by3Jl-00ng] X-AnalysisOut: [t:21 a=21wFBHY-vPGXYLZR:21 a=pILNOxqGKmIA:10 a=19wCD08tTks] X-AnalysisOut: [A:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0YA:10] X-AnalysisOut: [ a=xLpt9-x9cSEA:10 a=48vgC7mUAAAA:8 a=nU4qkYXXl0lyNiqrn74A] X-AnalysisOut: [:9 a=X5zaaVFBPgsFjRP0:21 a=E0cQJzLi4FIPc1Ut:21 a=43FeubSCI] X-AnalysisOut: [kK2f2r9:21 a=_W_S_7VecoQA:10 a=yNDdFi2Ng6kA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014033109); S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/RmQwT85xM1SlgIj4CVxU0KVVzGQ Subject: [6tisch-security] EAP-TLS X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:23:58 -0000 --Apple-Mail=_B17BB287-6A83-432A-9FF6-D5C7838635AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Since the last call focused a lot on EAP-TLS, I did a thought = experiment. I am not an expert on this, so I may have parts wrong=85=20 I am assuming the minimal draft bandwidth, which is 5 slots/s. Each = slot can contain about 100 bytes of useable data after MAC headers. = Since the node will be contending with other nodes, there are about 1.5 = slots/s of useable BW before collapse, so I=92ll call this 1 packet/s. = Lets assume that the joining nodes can stay synchronized at no packet = cost - i.e. they know when the beacons are coming and use them to stay = synchronized. Note that the beacon schedule is not communicated in the = beacon, only the slots for sending and getting packets, so this requires = either a lot of time in rx or some pre-shared knowledge of schedule.=20 So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 s. = Later on this will be happening in parallel as more nodes join, but 10 = children at a time per beaconing node seems a reasonable number for a = moderately dense network.=20 In order to get access to the network, the transactions go something = like this: (supplicant) (authenticator) =20 EAP start -> =20 <- EAP request identity EAP response identity -> <-TLS start=20 TLS client hello -> <- TLS hello, request cert , etc. TLS response cert -> <- TLS change cipher=20 TLS response -> =85.. some time later=85. <- EAP success =20 So 5 packets to get things started... .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 = packets (3 in each direction for mutual authentication).=20 =85add another couple of packets for deriving the session key.=20 .. a few more for agreeing on cipher suite and cleanup. At this point the PCE will be able to send a couple packets to configure = things with CoAP, after which the node can start the process again for = the next hop. So call it 170 s per hop. That=92s 1/2 an hour to form a 10 hop, 100 = node network. Not great. Note that the EAP-TLS spec (RFC 5216) says that = TLS_RSA_WITH_3DES_EDE_CBC_SHA is required and lists 3 recommended cipher = suites, in addition to the one we=92ll probably want to use for DTLS = later. I=92m assuming a minimum 2048-bit key for RSA - that=92s 10+ = packets each way if we use in place of ECDSA above. If we don=92t use = TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to support it = to be compliant, no? --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 30695 Huntwood Ave Hayward, CA 94544-7021 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION**=20 *****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2936, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you.=20 --Apple-Mail=_B17BB287-6A83-432A-9FF6-D5C7838635AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Since the last call focused a lot on EAP-TLS, I = did a thought experiment. I am not an expert on this, so I may have = parts wrong=85 

I am assuming the minimal draft = bandwidth, which is 5 slots/s.  Each slot can contain about 100 = bytes of useable data after MAC headers.  Since the node will be = contending with other nodes, there are about 1.5 slots/s of useable BW = before collapse, so I=92ll call this 1 packet/s.  Lets assume that = the joining nodes can stay synchronized at no packet cost - i.e. they = know when the beacons are coming and use them to stay synchronized. Note = that the beacon schedule is not communicated in the beacon, only the = slots for sending and getting packets, so this requires either a lot of = time in rx or some pre-shared knowledge of = schedule. 

So a joining node can exchange = 1 packet/s, or 10 nodes at 1 packet/10 s.  Later on this will be = happening in parallel as more nodes join, but 10 children at a time per = beaconing node seems a reasonable number for a moderately dense = network. 

In order to get access to the = network, the transactions go something like = this:

(supplicant)    (authenticator) =  
EAP start ->           =          
<- EAP request = identity
EAP response identity ->
<-TLS = start 
 TLS client hello = ->
<- TLS hello, request cert , = etc.
TLS response cert ->
<- TLS = change cipher 
TLS response ->
=85.. = some time later=85.
<- EAP success       =         

So 5 packets = to get things started...
.. assuming ECDSA X.509 certs (300 = bytes), cert exchange is at least 6 packets (3 in each direction for = mutual authentication). 
=85add another couple of packets = for deriving the session key. 
.. a few more for agreeing = on cipher suite and cleanup.

At this point the = PCE will be able to send a couple packets to configure things with CoAP, = after which the node can start the process again for the next = hop.

So call it 170 s per hop.  That=92s = 1/2 an hour to form a 10 hop, 100 node network. Not = great.

Note that the EAP-TLS spec (RFC 5216) says that TLS_RSA_WITH_3DES_EDE_CBC_SHA = is required and lists 3 recommended cipher = suites, in addition to the one we=92ll probably want to use for DTLS = later.  I=92m assuming a minimum 2048-bit key for RSA - that=92s = 10+ packets each way if we use in place of ECDSA above.   If we = don=92t use TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to = support it to be compliant, no?
-- 
Jonathan Simon, Ph. D
Director of = Systems Engineering
Linear Technology, Dust Networks product = group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) = 400-2936
(510) 489-3799 FAX
jsimon@linear.com

**LINEAR = TECHNOLOGY CORPORATION** 
*****Internet Email = Confidentiality Notice***** 
 This e-mail = transmission, and any documents, files or previous = e-mail messages attached to it may contain confidential = information that is legally privileged. If you are not = the intended recipient, or a person responsible for delivering = it to the intended recipient, you are hereby notified that any = disclosure, copying, distribution or use of any of = the information contained in or attached to this transmission = is STRICTLY PROHIBITED. If you have received this transmission = in error, please immediately notify me by reply e-mail, or by = telephone at (510) 400-2936, and destroy the original transmission = and its attachments without reading or saving in any manner. = Thank you. 

= --Apple-Mail=_B17BB287-6A83-432A-9FF6-D5C7838635AC-- From nobody Mon Mar 31 11:30:12 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1B81A08B4 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 11:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Heqa5hMDd9E4 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 11:30:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4051A6F7C for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 11:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14549; q=dns/txt; s=iport; t=1396290603; x=1397500203; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1H//+EHyrx+EAyS9kUoElbdt7IF1I1/7RZhSCnA3QmQ=; b=CSIqcfe1qWA6bgkgRv0+JGIIXl5wJWss51MS8RNlchb0UZlKRQxcM6Qz QSQSO9dMnS9BsU/7bfomxaHJT7II8Kk1JfjpVTFRqhU1Tsl5RhNjLo6yW p1gZwIgTqIp9ba5sVQPAtQvptb24xi9xvfaYuuXQS3DnzRu+4Tf+0QWGR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcFAOuzOVOtJV2d/2dsb2JhbABQBgOCQkQ7V7ooiHSBIRZ0giUBAQEEJwY+HgIBCA4DBAEBCx0HMhQJCAIEARIIh3EN0DEXiVCETQcKAR8hFgERgxOBFASIZYt9hR+RAoMwgXI5 X-IronPort-AV: E=Sophos;i="4.97,767,1389744000"; d="scan'208,217";a="314111354" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 31 Mar 2014 18:30:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2VIU2eb014211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 18:30:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 13:30:01 -0500 From: "Pascal Thubert (pthubert)" To: Jonathan Simon , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] EAP-TLS Thread-Index: AQHPTQ5jvzZeIPch8kKMxxQa7S594Jr7g7vg Date: Mon, 31 Mar 2014 18:30:01 +0000 Deferred-Delivery: Mon, 31 Mar 2014 18:30:00 +0000 Message-ID: References: <03E348D4-66F0-4A1A-953A-5D173DA131E4@linear.com> In-Reply-To: <03E348D4-66F0-4A1A-953A-5D173DA131E4@linear.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.193.184] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8425B068Exmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/6lEm0jLQen8rhXwDrMKzgs-TEhI Subject: Re: [6tisch-security] EAP-TLS X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:30:10 -0000 --_000_E045AECD98228444A58C61C200AE1BD8425B068Exmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jonathan: Thanks for this! Certainly does not look promising, and gives us a better o= utlook on what our constraints are. OTOH, I understand that DICE is working on a lighter DTLS, which hopefully = would better fit in constrained devices. It will be interesting to run the exact same computation on their proposal; Pascal From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Jonathan Simon Sent: lundi 31 mars 2014 20:26 To: 6tisch-security@ietf.org Subject: [6tisch-security] EAP-TLS Since the last call focused a lot on EAP-TLS, I did a thought experiment. I= am not an expert on this, so I may have parts wrong... I am assuming the minimal draft bandwidth, which is 5 slots/s. Each slot c= an contain about 100 bytes of useable data after MAC headers. Since the no= de will be contending with other nodes, there are about 1.5 slots/s of usea= ble BW before collapse, so I'll call this 1 packet/s. Lets assume that the= joining nodes can stay synchronized at no packet cost - i.e. they know whe= n the beacons are coming and use them to stay synchronized. Note that the b= eacon schedule is not communicated in the beacon, only the slots for sendin= g and getting packets, so this requires either a lot of time in rx or some = pre-shared knowledge of schedule. So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 s. L= ater on this will be happening in parallel as more nodes join, but 10 child= ren at a time per beaconing node seems a reasonable number for a moderately= dense network. In order to get access to the network, the transactions go something like t= his: (supplicant) (authenticator) EAP start -> <- EAP request identity EAP response identity -> <-TLS start TLS client hello -> <- TLS hello, request cert , etc. TLS response cert -> <- TLS change cipher TLS response -> ..... some time later.... <- EAP success So 5 packets to get things started... .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 pack= ets (3 in each direction for mutual authentication). ...add another couple of packets for deriving the session key. .. a few more for agreeing on cipher suite and cleanup. At this point the PCE will be able to send a couple packets to configure th= ings with CoAP, after which the node can start the process again for the ne= xt hop. So call it 170 s per hop. That's 1/2 an hour to form a 10 hop, 100 node ne= twork. Not great. Note that the EAP-TLS spec (RFC 5216) s= ays that TLS_RSA_WITH_3DES_EDE_CBC_SHA is required and lists 3 recommended = cipher suites, in addition to the one we'll probably want to use for DTLS l= ater. I'm assuming a minimum 2048-bit key for RSA - that's 10+ packets eac= h way if we use in place of ECDSA above. If we don't use TLS_RSA_WITH_3DE= S_EDE_CBC_SHA, we still need tested code to support it to be compliant, no? -- Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 30695 Huntwood Ave Hayward, CA 94544-7021 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION** *****Internet Email Confidentiality Notice***** This e-mail transmission, and any documents, files or previous e-mail mess= ages attached to it may contain confidential information that is legally pr= ivileged. If you are not the intended recipient, or a person responsible fo= r delivering it to the intended recipient, you are hereby notified that any= disclosure, copying, distribution or use of any of the information contain= ed in or attached to this transmission is STRICTLY PROHIBITED. If you have = received this transmission in error, please immediately notify me by reply = e-mail, or by telephone at (510) 400-2936, and destroy the original transmi= ssion and its attachments without reading or saving in any manner. Thank yo= u. --_000_E045AECD98228444A58C61C200AE1BD8425B068Exmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jonathan:

 <= /p>

Thanks for this! Certainl= y does not look promising, and gives us a better outlook on what our constr= aints are.

OTOH, I understand that D= ICE is working on a lighter DTLS, which hopefully would better fit in const= rained devices.

It will be interesting to= run the exact same computation on their proposal;

 <= /p>

Pascal<= /p>

 <= /p>

From: 6tisch-s= ecurity [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Jonathan Simon
Sent: lundi 31 mars 2014 20:26
To: 6tisch-security@ietf.org
Subject: [6tisch-security] EAP-TLS

 

Since the last call focused a lot on EAP-TLS, I did = a thought experiment. I am not an expert on this, so I may have parts wrong= … 

 

I am assuming the minimal draft bandwidth, which is = 5 slots/s.  Each slot can contain about 100 bytes of useable data afte= r MAC headers.  Since the node will be contending with other nodes, th= ere are about 1.5 slots/s of useable BW before collapse, so I’ll call this 1 packet/s.  Lets assume that the j= oining nodes can stay synchronized at no packet cost - i.e. they know when = the beacons are coming and use them to stay synchronized. Note that the bea= con schedule is not communicated in the beacon, only the slots for sending and getting packets, so this requires either a = lot of time in rx or some pre-shared knowledge of schedule. 

 

So a joining node can exchange 1 packet/s, or 10 nod= es at 1 packet/10 s.  Later on this will be happening in parallel as m= ore nodes join, but 10 children at a time per beaconing node seems a reason= able number for a moderately dense network. 

 

In order to get access to the network, the transacti= ons go something like this:

 

(supplicant)    (authenticator)  

EAP start ->           &= nbsp;        

<- EAP request identity

EAP response identity ->

<-TLS start 

 TLS client hello ->

<- TLS hello, request cert , etc.

TLS response cert ->

<- TLS change cipher 

TLS response ->

….. some time later….

<- EAP success          =     

 

So 5 packets to get things started...

.. assuming ECDSA X.509 certs (300 bytes), cert exch= ange is at least 6 packets (3 in each direction for mutual authentication).=  

…add another couple of packets for deriving th= e session key. 

.. a few more for agreeing on cipher suite and clean= up.

 

At this point the PCE will be able to send a couple = packets to configure things with CoAP, after which the node can start the p= rocess again for the next hop.

 

So call it 170 s per hop.  That’s 1/2 an = hour to form a 10 hop, 100 node network. Not great.

 

Note that the EAP-TLS spec (RFC 5216) s= ays that TLS_RSA_WITH_3DES_EDE_CBC_SHA is required an= d lists 3 recommended cipher suites, in addition to the one we’ll probably want to use for DTLS later.  I’m assum= ing a minimum 2048-bit key for RSA - that’s 10+ packets each way = if we use in place of ECDSA above.   If we don’t use TLS_RSA_WIT= H_3DES_EDE_CBC_SHA, we still need tested code to support it to be compliant= , no?

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e= -mail messages attached to it may contain confidential informatio= n that is legally privileged. If you are not the intended recipie= nt, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, = ;distribution or use of any of the information contained in or attache= d to this transmission is STRICTLY PROHIBITED. If you have receiv= ed this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the ori= ginal transmission and its attachments without reading or saving = in any manner. Thank you. 

 

--_000_E045AECD98228444A58C61C200AE1BD8425B068Exmbrcdx01ciscoc_-- From nobody Mon Mar 31 12:09:08 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEC31A6F81 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 12:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Tm8Y2LYlAqn5 for <6tisch-security@ietfa.amsl.com>; Mon, 31 Mar 2014 12:08:58 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 09D3A1A6F63 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 12:08:57 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so7923467iec.7 for <6tisch-security@ietf.org>; Mon, 31 Mar 2014 12:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=sW9tuluZMHCRdPgzZ+xq8/y+ytgPoVcS/RpFASAmUfY=; b=Bfw6en4zqct0fV/uFnw7UfXkbPW8unS0WFHbPo/89Kp6Bkz0sleLXYF35sU0Z01M4t u/3NWLSoMOsTxDXb7Fol9l5M2yEW4QCV3R7ACguZn3IkQh23rBbhYaKEsvSM7RMbiwrP pqrG7SqHf0P6/Nw71WciX3DO0CrTbckrYqy40FE8CKa1Vh5xwS7UdNfZmFDZVFyS2ecE uOtetUfE44v/x1VWznTMTKwJ0Dp2Cq+k81aCFB1dmvZbu13mvO/JX0lP+/GumsJBPYhs 74zKZaW6un0VkRcfRyEzunKpLie4ql4gcHX2A6x0usO+HApHpLhmz2YOQki5XRe4E2G/ 3Kjw== X-Received: by 10.43.67.70 with SMTP id xt6mr5592850icb.84.1396292934712; Mon, 31 Mar 2014 12:08:54 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id ix1sm26912791igc.15.2014.03.31.12.08.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 12:08:53 -0700 (PDT) Message-ID: <5339BD3F.6020704@gmail.com> Date: Mon, 31 Mar 2014 15:08:47 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jonathan Simon , 6tisch-security@ietf.org References: <03E348D4-66F0-4A1A-953A-5D173DA131E4@linear.com> In-Reply-To: <03E348D4-66F0-4A1A-953A-5D173DA131E4@linear.com> Content-Type: multipart/alternative; boundary="------------060105080604060609000903" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/j8COtxXN04ZhBq2L_8CFFn5PVug Subject: Re: [6tisch-security] EAP-TLS X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:09:06 -0000 This is a multi-part message in MIME format. --------------060105080604060609000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jonathan: From your note below it is clear that communication latency is a true killer. In your back-of-the-envelope calculation, you seem to assume that joining protocols need to be carried out serially (you mentioned joining node can exchange 1 packet/s, or 10 nodes at 1 packed/10s). Couldn't one conceivably execute these in parallel as well? No matter how many smart things one does to compress joining protocol messages, one needs at least three message flows (in practice: four) to obtain a key agreement protocol with the right set of security properties. So, that provides a lower bound. This also illustrates that the details of the communication channel (viz. 802.15.4e and TSCH) do matter in higher-layer protocol design considerations (nothing new here, but worth pointing out nevertheless). For some related email traffic on this topic, see our email exchange of February 4, 2014 on the general 6tisch list: http://www.ietf.org/mail-archive/web/6tisch/current/msg01782.html (At the time, I suggest that scheduling of joining protocol slots deserves lots of attention.) Best regards, Rene On 3/31/2014 2:25 PM, Jonathan Simon wrote: > Since the last call focused a lot on EAP-TLS, I did a thought > experiment. I am not an expert on this, so I may have parts wrong... > > I am assuming the minimal draft bandwidth, which is 5 slots/s. Each > slot can contain about 100 bytes of useable data after MAC headers. > Since the node will be contending with other nodes, there are about > 1.5 slots/s of useable BW before collapse, so I'll call this 1 > packet/s. Lets assume that the joining nodes can stay synchronized at > no packet cost - i.e. they know when the beacons are coming and use > them to stay synchronized. Note that the beacon schedule is not > communicated in the beacon, only the slots for sending and getting > packets, so this requires either a lot of time in rx or some > pre-shared knowledge of schedule. > > So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 > s. Later on this will be happening in parallel as more nodes join, > but 10 children at a time per beaconing node seems a reasonable number > for a moderately dense network. > > In order to get access to the network, the transactions go something > like this: > > (supplicant) (authenticator) > EAP start -> > <- EAP request identity > EAP response identity -> > <-TLS start > TLS client hello -> > <- TLS hello, request cert , etc. > TLS response cert -> > <- TLS change cipher > TLS response -> > ..... some time later.... > <- EAP success > > So 5 packets to get things started... > .. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 > packets (3 in each direction for mutual authentication). > ...add another couple of packets for deriving the session key. > .. a few more for agreeing on cipher suite and cleanup. > > At this point the PCE will be able to send a couple packets to > configure things with CoAP, after which the node can start the process > again for the next hop. > > So call it 170 s per hop. That's 1/2 an hour to form a 10 hop, 100 > node network. Not great. > > Note that the EAP-TLS spec (RFC 5216 > ) says that > TLS_RSA_WITH_3DES_EDE_CBC_SHA is _required_ and lists 3 recommended > cipher suites, in addition to the one we'll probably want to use for > DTLS later. I'm assuming a minimum 2048-bit key for RSA - that's 10+ > packets each way if we use in place of ECDSA above. If we don't use > TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to support it > to be compliant, no? > -- > Jonathan Simon, Ph. D > Director of Systems Engineering > Linear Technology, Dust Networks product group > 30695 Huntwood Ave > Hayward, CA 94544-7021 > (510) 400-2936 > (510) 489-3799 FAX > jsimon@linear.com > > **LINEAR TECHNOLOGY CORPORATION** > *****Internet Email Confidentiality Notice***** > This e-mail transmission, and any documents, files or previous > e-mail messages attached to it may contain confidential information > that is legally privileged. If you are not the intended recipient, or > a person responsible for delivering it to the intended recipient, you > are hereby notified that any disclosure, copying, distribution or use > of any of the information contained in or attached to this > transmission is STRICTLY PROHIBITED. If you have received > this transmission in error, please immediately notify me by reply > e-mail, or by telephone at (510) 400-2936, and destroy the > original transmission and its attachments without reading or saving in > any manner. Thank you. > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------060105080604060609000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Jonathan:

From your note below it is clear that communication latency is a true killer.

In your back-of-the-envelope calculation, you seem to assume that joining protocols need to be carried out serially (you mentioned joining node can exchange 1 packet/s, or 10 nodes at 1 packed/10s). Couldn't one conceivably execute these in parallel as well?

No matter how many smart things one does to compress joining protocol messages, one needs at least three message flows (in practice: four) to obtain a key agreement protocol with the right set of security properties. So, that provides a lower bound.

This also illustrates that the details of the communication channel (viz. 802.15.4e and TSCH) do matter in higher-layer protocol design considerations (nothing new here, but worth pointing out nevertheless).

For some related email traffic on this topic, see our email exchange of February 4, 2014 on the general 6tisch list:
http://www.ietf.org/mail-archive/web/6tisch/current/msg01782.html
(At the time, I suggest that scheduling of joining protocol slots deserves lots of attention.)

Best regards, Rene

On 3/31/2014 2:25 PM, Jonathan Simon wrote:
Since the last call focused a lot on EAP-TLS, I did a thought experiment. I am not an expert on this, so I may have parts wrong… 

I am assuming the minimal draft bandwidth, which is 5 slots/s.  Each slot can contain about 100 bytes of useable data after MAC headers.  Since the node will be contending with other nodes, there are about 1.5 slots/s of useable BW before collapse, so I’ll call this 1 packet/s.  Lets assume that the joining nodes can stay synchronized at no packet cost - i.e. they know when the beacons are coming and use them to stay synchronized. Note that the beacon schedule is not communicated in the beacon, only the slots for sending and getting packets, so this requires either a lot of time in rx or some pre-shared knowledge of schedule. 

So a joining node can exchange 1 packet/s, or 10 nodes at 1 packet/10 s.  Later on this will be happening in parallel as more nodes join, but 10 children at a time per beaconing node seems a reasonable number for a moderately dense network. 

In order to get access to the network, the transactions go something like this:

(supplicant)    (authenticator)  
EAP start ->                    
<- EAP request identity
EAP response identity ->
<-TLS start 
 TLS client hello ->
<- TLS hello, request cert , etc.
TLS response cert ->
<- TLS change cipher 
TLS response ->
….. some time later….
<- EAP success               

So 5 packets to get things started...
.. assuming ECDSA X.509 certs (300 bytes), cert exchange is at least 6 packets (3 in each direction for mutual authentication). 
…add another couple of packets for deriving the session key. 
.. a few more for agreeing on cipher suite and cleanup.

At this point the PCE will be able to send a couple packets to configure things with CoAP, after which the node can start the process again for the next hop.

So call it 170 s per hop.  That’s 1/2 an hour to form a 10 hop, 100 node network. Not great.

Note that the EAP-TLS spec (RFC 5216) says that TLS_RSA_WITH_3DES_EDE_CBC_SHA is required and lists 3 recommended cipher suites, in addition to the one we’ll probably want to use for DTLS later.  I’m assuming a minimum 2048-bit key for RSA - that’s 10+ packets each way if we use in place of ECDSA above.   If we don’t use TLS_RSA_WITH_3DES_EDE_CBC_SHA, we still need tested code to support it to be compliant, no?
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. 
 



_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------060105080604060609000903--