From nobody Mon Nov 3 17:27:36 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 F15071A1B4B for <6tisch-security@ietfa.amsl.com>; Mon, 3 Nov 2014 17:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 472sPxFFep9B for <6tisch-security@ietfa.amsl.com>; Mon, 3 Nov 2014 17:27:32 -0800 (PST) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6771A1B49 for <6tisch-security@ietf.org>; Mon, 3 Nov 2014 17:27:31 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o148.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id f7b28545.0.103851.00-308.274672.p02c11o148.mxlogic.net (envelope-from ); Mon, 03 Nov 2014 18:27:31 -0700 (MST) X-MXL-Hash: 54582b8327c92440-18448021de8d4bd0515c0bf8579345c625f6fb13 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 251CF740A7; Mon, 3 Nov 2014 17:27:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0D5201B-379C-4401-8638-799B627C53D2" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: <844.1414780388@sandelman.ca> Date: Mon, 3 Nov 2014 17:26:37 -0800 Message-Id: References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <844.1414780388@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=DKqb4k9b c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=SyYMxH9GAAAA:8 a=48vgC7mUAA] X-AnalysisOut: [AA:8 a=6fZ3n9FySCB434k0eSEA:9 a=UD4KI_ZCS721o1PH:21 a=PuRM] X-AnalysisOut: [l5FvUhuaL3CE:21 a=pILNOxqGKmIA:10 a=19wCD08tTksA:10 a=vsVy] X-AnalysisOut: [j9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0YA:10 a=oe9oftIU] X-AnalysisOut: [zKABO7lK56QA:9 a=yu4BC9qivw10QUpP:21 a=fTlqGMEOZMg2-ods:21] X-AnalysisOut: [ a=RBZBzHBemeuzMnIX:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014110323); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/p_bsFLUIEhoinTssGTrjOEA91AU Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: Tue, 04 Nov 2014 01:27:35 -0000 --Apple-Mail=_B0D5201B-379C-4401-8638-799B627C53D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 275 bytes is a good start ;)=20 I notice that of that only 135 bytes is key/signature, so I think = there=92s still room for improvement=85 --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (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 Oct 31, 2014, at 11:33 AM, Michael Richardson = wrote: >=20 > Jonathan Simon wrote: >> Yes - I don=92t know where the effort belongs though. I think we = need a >> standard way of compressing an X.509 cert with the goal of fitting it >> in under 200 bytes. Maybe this compressed cert is only used at = joining >> in 6TiSCH, or maybe border routers can compress/decompress along with >> the 6LoWPAN header so we can use it end-to-end. >=20 > There is no reason the certificate compression needs to be in *6lo* > it can be part of DTLS. >=20 > A 256 EC public key takes 88 bytes raw. > Running gzip on that file expands it to 114 bytes :-) > (not surprising, it ought be rather random, gzip header overhead) >=20 > Turning that into a self-signed certificate with a CN=3D12347624: >=20 > Certificate: > Data: > Version: 1 (0x0) > Serial Number: > 86:52:cb:df:30:2c:88:c1 > Signature Algorithm: ecdsa-with-SHA1 > Issuer: CN=3D12347624 > Validity > Not Before: Oct 31 18:28:09 2014 GMT > Not After : Nov 30 18:28:09 2014 GMT > Subject: CN=3D12347624 > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > EC Public Key: > pub: > 04:4c:24:f9:e5:8d:ee:e5:b9:da:23:51:d2:fb:35: > 83:4d:71:69:57:ca:78:7e:3c:f9:a7:cc:ed:b5:e3: > 12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6e:6b:d1:b6: > 5d:26:90:b5:d9:b5:af:18:d3:42:8d:fc:11:93:58: > 37:03:be:c9:cc > ASN1 OID: secp256k1 > Signature Algorithm: ecdsa-with-SHA1 > 30:44:02:20:15:a6:93:d1:9f:81:65:53:34:d7:9c:28:81:73: > d6:39:c6:3d:e1:ed:65:31:67:9c:5a:16:6c:12:ae:f6:09:6f: > 02:20:42:af:3a:07:94:15:cd:c9:f0:9a:b2:65:7c:5e:c6:55: > 61:ee:35:e3:4f:39:53:29:2c:5e:31:15:8b:40:ec:42 >=20 > 428 bytes in base64 format, 275 bytes binary, gzip'ed 274 bytes! > -----BEGIN CERTIFICATE----- > MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAxMIMTIzNDc2 > MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQDEwgx > MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01x > aVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww > CQYHKoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ > bwIgQq86B5QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI=3D > -----END CERTIFICATE----- >=20 > I don't think it matters what protocol one uses for join; it won't get = a lot > smaller than this. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca = http://cp.mcafee.com/d/5fHCN8q3x0SyMyMeuKOqenPtPqbwVBcSyUepvdEK3zhOyCOqejr= zPPPz5XCN6ABqM1hYEvIundDOx-NVsTLLEcLIfZvAnbILCzDHTbFITd7fcTh7fcYJteOaaJXEY= G7DR8OJMddECQjt-hojuv78I9CzATsS02FI4fflS7mT3rAVkIjbQ-Pspjb5O5mUm-waBYTu00C= TAjhOCr1vF6y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkAavgQgr10Qg2dpgB0yq87jWC= a6TT3pJPEX6hR | ruby on rails [ >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > = http://cp.mcafee.com/d/1jWVIe6jqb2b0VWX9EVvdTdEK3CkPqbwVBYSyUed7aar9EVdKff= fecnKr4qilH057Ox-NVsSva7X7BPu--wO-M_R-hsKO-qeuLsKCPsQsYPt4sYPORQX8EGTKzOEu= vkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjB= iNcLjXdNBcIn8lrxrW0GnPtU02ruhd7apI5-Aq83iSVelb4OZfIT6kONFtd403s_sQsCy0i-cP= h1igFZ3h1I43h08RB2k29EwtfGoErvsdV2yc --Apple-Mail=_B0D5201B-379C-4401-8638-799B627C53D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 275 = bytes is a good start ;) 

I notice that of that = only 135 bytes is key/signature, so I think there=92s still room for = improvement=85

-- 
Jonathan Simon, Ph. D
Director of = Systems Engineering
Linear Technology, Dust Networks product = group
32990 Alvarado-Niles Road, Suite 910
Union City, CA = 94587
(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 Oct 31, 2014, at 11:33 AM, Michael Richardson <mcr+ietf@sandelman.ca> = wrote:


Jonathan Simon <jsimon@linear.com> = wrote:
Yes - I don=92t know where the = effort belongs though.  I think we need a
standard way of = compressing an X.509 cert with the goal of fitting it
in under 200 = bytes. Maybe this compressed cert is only used at joining
in 6TiSCH, = or maybe border routers can compress/decompress along with
the = 6LoWPAN header so we can use it end-to-end.

There is = no reason the certificate compression needs to be in *6lo*
it can be = part of DTLS.

A 256 EC public key takes 88 bytes raw.
Running = gzip on that file expands it to 114 bytes :-)
(not surprising, it = ought be rather random, gzip header overhead)

Turning that into a = self-signed certificate with a CN=3D12347624:

Certificate:
=    Data:
=        Version: 1 (0x0)
=        Serial Number:
=            86:52:cb= :df:30:2c:88:c1
       Signature = Algorithm: ecdsa-with-SHA1
=        Issuer: CN=3D12347624
=        Validity
=            Not = Before: Oct 31 18:28:09 2014 GMT
=            Not = After : Nov 30 18:28:09 2014 GMT
=        Subject: CN=3D12347624
=        Subject Public Key Info:
=            Public = Key Algorithm: id-ecPublicKey
=            EC = Public Key:
=             &n= bsp;  pub:
=             &n= bsp;      04:4c:24:f9:e5:8d:ee:e5:b9:da:23:5= 1:d2:fb:35:
=             &n= bsp;      83:4d:71:69:57:ca:78:7e:3c:f9:a7:c= c:ed:b5:e3:
=             &n= bsp;      12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6= e:6b:d1:b6:
=             &n= bsp;      5d:26:90:b5:d9:b5:af:18:d3:42:8d:f= c:11:93:58:
=             &n= bsp;      37:03:be:c9:cc
=             &n= bsp;  ASN1 OID: secp256k1
   Signature = Algorithm: ecdsa-with-SHA1
=        30:44:02:20:15:a6:93:d1:9f:81:65= :53:34:d7:9c:28:81:73:
=        d6:39:c6:3d:e1:ed:65:31:67:9c:5a= :16:6c:12:ae:f6:09:6f:
=        02:20:42:af:3a:07:94:15:cd:c9:f0= :9a:b2:65:7c:5e:c6:55:
=        61:ee:35:e3:4f:39:53:29:2c:5e:31= :15:8b:40:ec:42

428 bytes in base64 format, 275 bytes binary, = gzip'ed 274 bytes!
-----BEGIN = CERTIFICATE-----
MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAx= MIMTIzNDc2
MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQD= Ewgx
MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01xaVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww
CQYH= KoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ
bwIgQq86B5= QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI=3D
-----END = CERTIFICATE-----

I don't think it matters what protocol one uses = for join; it won't get a lot
smaller than this.

--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
]   Michael = Richardson, Sandelman Software Works =        | network architect =  [
]     mcr@sandelman.ca  http://cp.mcafee.com/d/5fHCN8q3x0SyMyMeuKOqenPtPqbw= VBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTLLEcLIfZvAnbILCzDHTb= FITd7fcTh7fcYJteOaaJXEYG7DR8OJMddECQjt-hojuv78I9CzATsS02FI4fflS7mT3rAVkIjb= Q-Pspjb5O5mUm-waBYTu00CTAjhOCr1vF6y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkA= avgQgr10Qg2dpgB0yq87jWCa6TT3pJPEX6hR =        |   ruby on rails =    [




--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
-=3D IPv6 IoT consulting = =3D-



_______________________________________________
6ti= sch-security mailing list
6tisch-security@ietf.org
h= ttp://cp.mcafee.com/d/1jWVIe6jqb2b0VWX9EVvdTdEK3CkPqbwVBYSyUed7aar9EVdKfff= ecnKr4qilH057Ox-NVsSva7X7BPu--wO-M_R-hsKO-qeuLsKCPsQsYPt4sYPORQX8EGTKzOEuv= kzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBi= NcLjXdNBcIn8lrxrW0GnPtU02ruhd7apI5-Aq83iSVelb4OZfIT6kONFtd403s_sQsCy0i-cPh= 1igFZ3h1I43h08RB2k29EwtfGoErvsdV2yc

= = --Apple-Mail=_B0D5201B-379C-4401-8638-799B627C53D2-- From nobody Mon Nov 3 18:08: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 5C2CB1A1B84 for <6tisch-security@ietfa.amsl.com>; Mon, 3 Nov 2014 18:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_42=0.6, 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 fdQdW77npW0R for <6tisch-security@ietfa.amsl.com>; Mon, 3 Nov 2014 18:07:54 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09D31A1B4F for <6tisch-security@ietf.org>; Mon, 3 Nov 2014 18:07:54 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id x19so6446856ier.5 for <6tisch-security@ietf.org>; Mon, 03 Nov 2014 18:07:54 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type; bh=Numx4l1Ll2SDBb8qk4P1mUArnxQOhrFrOWor6KCSmi0=; b=QRmc+q3VDO5LrKZQk2ByHv1x2sBacQIsXA910+C+xnTMGrSLZPL2mb+ZIVXb1ptEdW 1USC9oAgdoUeX9j8g1cg2trxCwPH61fWGxsjujTXIhYdvq8z7HmrJvihP+VNV1heFn+G sYO3AJPfLjr9DjEa4bPgNxxtkA90qScUBd0QrePMzvKHdqqnWOavP6z93Lle1pBG6lDv +zLD8tBIhxPOJJBFttermiEl4JoSdd5s3VAT9sacpQ0o3LALz4p0GqO44qxkTImsl2qR 85uONE2tsJUN2xURqt9UsOP8E8oaIuJ3jOg0uQ9GIDptnFtnnmBnl1a9qxgKCThVvlEl fIvg== X-Received: by 10.50.39.84 with SMTP id n20mr17451593igk.1.1415066873972; Mon, 03 Nov 2014 18:07:53 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id ft10sm4458861igb.19.2014.11.03.18.07.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 18:07:53 -0800 (PST) Message-ID: <545834F5.4060504@gmail.com> Date: Mon, 03 Nov 2014 21:07:49 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jonathan Simon , Michael Richardson References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <844.1414780388@sandelman.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070303090009070504000708" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/2YvvGi4fnVkPet5sGYBhPBv-6P4 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: Tue, 04 Nov 2014 02:07:57 -0000 This is a multi-part message in MIME format. --------------070303090009070504000708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan: Please see item #c of my email of Friday below. [excerpt of my email as of Fri October 31, 2014, 12:26pm EDT] c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message). On 11/3/2014 8:26 PM, Jonathan Simon wrote: > 275 bytes is a good start ;) > > I notice that of that only 135 bytes is key/signature, so I think > there’s still room for improvement… > > -- > Jonathan Simon, Ph. D > Director of Systems Engineering > Linear Technology, Dust Networks product group > 32990 Alvarado-Niles Road, Suite 910 > Union City, CA 94587 > (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 Oct 31, 2014, at 11:33 AM, Michael Richardson > > wrote: > >> >> Jonathan Simon > wrote: >>> Yes - I don’t know where the effort belongs though. I think we need a >>> standard way of compressing an X.509 cert with the goal of fitting it >>> in under 200 bytes. Maybe this compressed cert is only used at joining >>> in 6TiSCH, or maybe border routers can compress/decompress along with >>> the 6LoWPAN header so we can use it end-to-end. >> >> There is no reason the certificate compression needs to be in *6lo* >> it can be part of DTLS. >> >> A 256 EC public key takes 88 bytes raw. >> Running gzip on that file expands it to 114 bytes :-) >> (not surprising, it ought be rather random, gzip header overhead) >> >> Turning that into a self-signed certificate with a CN=12347624: >> >> Certificate: >> Data: >> Version: 1 (0x0) >> Serial Number: >> 86:52:cb:df:30:2c:88:c1 >> Signature Algorithm: ecdsa-with-SHA1 >> Issuer: CN=12347624 >> Validity >> Not Before: Oct 31 18:28:09 2014 GMT >> Not After : Nov 30 18:28:09 2014 GMT >> Subject: CN=12347624 >> Subject Public Key Info: >> Public Key Algorithm: id-ecPublicKey >> EC Public Key: >> pub: >> 04:4c:24:f9:e5:8d:ee:e5:b9:da:23:51:d2:fb:35: >> 83:4d:71:69:57:ca:78:7e:3c:f9:a7:cc:ed:b5:e3: >> 12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6e:6b:d1:b6: >> 5d:26:90:b5:d9:b5:af:18:d3:42:8d:fc:11:93:58: >> 37:03:be:c9:cc >> ASN1 OID: secp256k1 >> Signature Algorithm: ecdsa-with-SHA1 >> 30:44:02:20:15:a6:93:d1:9f:81:65:53:34:d7:9c:28:81:73: >> d6:39:c6:3d:e1:ed:65:31:67:9c:5a:16:6c:12:ae:f6:09:6f: >> 02:20:42:af:3a:07:94:15:cd:c9:f0:9a:b2:65:7c:5e:c6:55: >> 61:ee:35:e3:4f:39:53:29:2c:5e:31:15:8b:40:ec:42 >> >> 428 bytes in base64 format, 275 bytes binary, gzip'ed 274 bytes! >> -----BEGIN CERTIFICATE----- >> MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAxMIMTIzNDc2 >> MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQDEwgx >> MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01x >> aVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww >> CQYHKoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ >> bwIgQq86B5QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI= >> -----END CERTIFICATE----- >> >> I don't think it matters what protocol one uses for join; it won't >> get a lot >> smaller than this. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca >> http://cp.mcafee.com/d/5fHCN8q3x0SyMyMeuKOqenPtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTLLEcLIfZvAnbILCzDHTbFITd7fcTh7fcYJteOaaJXEYG7DR8OJMddECQjt-hojuv78I9CzATsS02FI4fflS7mT3rAVkIjbQ-Pspjb5O5mUm-waBYTu00CTAjhOCr1vF6y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkAavgQgr10Qg2dpgB0yq87jWCa6TT3pJPEX6hR >> | ruby on rails [ >> >> >> >> >> -- >> Michael Richardson > >, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> http://cp.mcafee.com/d/1jWVIe6jqb2b0VWX9EVvdTdEK3CkPqbwVBYSyUed7aar9EVdKfffecnKr4qilH057Ox-NVsSva7X7BPu--wO-M_R-hsKO-qeuLsKCPsQsYPt4sYPORQX8EGTKzOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02ruhd7apI5-Aq83iSVelb4OZfIT6kONFtd403s_sQsCy0i-cPh1igFZ3h1I43h08RB2k29EwtfGoErvsdV2yc > > > > _______________________________________________ > 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 --------------070303090009070504000708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jonathan:

Please see item #c of my email of Friday below.

[excerpt of my email as of Fri October 31, 2014, 12:26pm EDT]
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).



On 11/3/2014 8:26 PM, Jonathan Simon wrote:
275 bytes is a good start ;) 

I notice that of that only 135 bytes is key/signature, so I think there’s still room for improvement…

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(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 Oct 31, 2014, at 11:33 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Jonathan Simon <jsimon@linear.com> wrote:
Yes - I don’t know where the effort belongs though.  I think we need a
standard way of compressing an X.509 cert with the goal of fitting it
in under 200 bytes. Maybe this compressed cert is only used at joining
in 6TiSCH, or maybe border routers can compress/decompress along with
the 6LoWPAN header so we can use it end-to-end.

There is no reason the certificate compression needs to be in *6lo*
it can be part of DTLS.

A 256 EC public key takes 88 bytes raw.
Running gzip on that file expands it to 114 bytes :-)
(not surprising, it ought be rather random, gzip header overhead)

Turning that into a self-signed certificate with a CN=12347624:

Certificate:
   Data:
       Version: 1 (0x0)
       Serial Number:
           86:52:cb:df:30:2c:88:c1
       Signature Algorithm: ecdsa-with-SHA1
       Issuer: CN=12347624
       Validity
           Not Before: Oct 31 18:28:09 2014 GMT
           Not After : Nov 30 18:28:09 2014 GMT
       Subject: CN=12347624
       Subject Public Key Info:
           Public Key Algorithm: id-ecPublicKey
           EC Public Key:
               pub:
                   04:4c:24:f9:e5:8d:ee:e5:b9:da:23:51:d2:fb:35:
                   83:4d:71:69:57:ca:78:7e:3c:f9:a7:cc:ed:b5:e3:
                   12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6e:6b:d1:b6:
                   5d:26:90:b5:d9:b5:af:18:d3:42:8d:fc:11:93:58:
                   37:03:be:c9:cc
               ASN1 OID: secp256k1
   Signature Algorithm: ecdsa-with-SHA1
       30:44:02:20:15:a6:93:d1:9f:81:65:53:34:d7:9c:28:81:73:
       d6:39:c6:3d:e1:ed:65:31:67:9c:5a:16:6c:12:ae:f6:09:6f:
       02:20:42:af:3a:07:94:15:cd:c9:f0:9a:b2:65:7c:5e:c6:55:
       61:ee:35:e3:4f:39:53:29:2c:5e:31:15:8b:40:ec:42

428 bytes in base64 format, 275 bytes binary, gzip'ed 274 bytes!
-----BEGIN CERTIFICATE-----
MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAxMIMTIzNDc2
MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQDEwgx
MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01x
aVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww
CQYHKoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ
bwIgQq86B5QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI=
-----END CERTIFICATE-----

I don't think it matters what protocol one uses for join; it won't get a lot
smaller than this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://cp.mcafee.com/d/5fHCN8q3x0SyMyMeuKOqenPtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTLLEcLIfZvAnbILCzDHTbFITd7fcTh7fcYJteOaaJXEYG7DR8OJMddECQjt-hojuv78I9CzATsS02FI4fflS7mT3rAVkIjbQ-Pspjb5O5mUm-waBYTu00CTAjhOCr1vF6y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkAavgQgr10Qg2dpgB0yq87jWCa6TT3pJPEX6hR        |   ruby on rails    [




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-



_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
http://cp.mcafee.com/d/1jWVIe6jqb2b0VWX9EVvdTdEK3CkPqbwVBYSyUed7aar9EVdKfffecnKr4qilH057Ox-NVsSva7X7BPu--wO-M_R-hsKO-qeuLsKCPsQsYPt4sYPORQX8EGTKzOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02ruhd7apI5-Aq83iSVelb4OZfIT6kONFtd403s_sQsCy0i-cPh1igFZ3h1I43h08RB2k29EwtfGoErvsdV2yc



_______________________________________________
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
--------------070303090009070504000708-- From nobody Mon Nov 3 18:10:11 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 EE7181A1B8A; Mon, 3 Nov 2014 18:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_28=0.6, 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 nw2NXXhURyqb; Mon, 3 Nov 2014 18:09:59 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741E61A1B84; Mon, 3 Nov 2014 18:09:59 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id y20so6698751ier.34 for ; Mon, 03 Nov 2014 18:09:58 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type; bh=7ej15vUEG12PHLr08IPFRnZdFQFXW+aWNqTn6pZSMak=; b=WFX09iRpahhoROu3hX0vkVSiCEE55T/dqBvHsjuUIocsNMITS7hYzlkhiDfr4SnuJD yiUkRYvP7RK2GWqHBaLwe48WXJSSw8OS3rydJU4xvSFW3byBcKWGz/rmv3KV1VVdMZ70 9XDsup/CO0ud0JXn2pWIhbDVIyPUp7cnwWY00V0bE0XXRzWQwz9fSyA2iC3ZF+FwPiJY 66MfHmW1rXF9gs7gUEMmwpVeiiu2W7MTz4uHVDbjQG3BxvVm1hUXAqFjIrlncaPEAW6x fSw5Jz1CDlBy1PVA3wCh7ZDYRd+Rr82VvqFQMm77qE62rlIFucdLQsczKzlfeuxs2PHn NBEg== X-Received: by 10.42.230.15 with SMTP id jk15mr10978298icb.55.1415066998855; Mon, 03 Nov 2014 18:09:58 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id nu1sm4326747igb.0.2014.11.03.18.09.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 18:09:58 -0800 (PST) Message-ID: <54583572.6020502@gmail.com> Date: Mon, 03 Nov 2014 21:09:54 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jonathan Simon , "Pascal Thubert (pthubert)" References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <5453B837.5040305@gmail.com> In-Reply-To: <5453B837.5040305@gmail.com> Content-Type: multipart/alternative; boundary="------------040700030201080200050008" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/yTe2fDVK-i7fpfqCMzO56ROVSOA Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows 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: Tue, 04 Nov 2014 02:10:04 -0000 This is a multi-part message in MIME format. --------------040700030201080200050008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jonathan: Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014). Best regards, Rene On 10/31/2014 12:26 PM, Rene Struik wrote: > Hi Jonathan: > > The join protocol includes (1) authentication; (2) authorization; (3) > configuration steps. > Without hands tied behind the back with protocol design, I anticipate > the main communication overhead of the join protocol to be with the > configuration step (#3) and *not* with the underlying authenticated > key agreement scheme (#1). Here, configuration relates both to > security manager to joining node info and vice-verse. > > See also item #a of my May 20, 2014 email -- _which is still > outstanding BTW._ > Que - Would you like to take this one on? {as first step, what about > providing a rough number, say, 1500 bytes [fill in correct number here]}. > > Some brief feedback on certificate sizes: > a) certificates should definitely have policy fields, including key > validity period. > b) certificate compression is of course possible, including that of > certificate issuer (whether the latter would be prudent remains to be > seen). > c) some of your figures are too pessimistic, e.g., P-256 keys are 65 > bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 > could be used as SubjectPublicKey field, but depends on naming issues > (see item #b of my May 20, 2014 message). > d) there is no absolute need to use X509 certs, which would add > considerable freedom to cut down overhead. > > I estimate one can implement the authentication scheme (#1) with one > or two 802.15.4e frames in each protocol flow (assuming cert chains of > length one). > > Email of May 20, 2014 with outstanding issues: > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html > a) Packet sizes: > get more info on packet sizes configuration parms, as w/HART uses. > Note RS: during call, Tom Phinney suggested contacting Wally Bratt > from HART Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust > Networks have info on packet sizes/structure?; ISA SP100.11a metrics > would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco > have useful data points here? > b) Device Ids: > With industrial control, network manager would look up "tag name" > device in pre-configured database. Details on tag name syntax, how > assigned, and how bound to, e.g., EUI-64 are missing. Note RS: > Perhaps, Tom Phinney could point at tag name syntax and lifecycle > aspects here? > > On 10/31/2014 11:48 AM, Jonathan Simon wrote: >> Pascal - >> >> Yes - I don’t know where the effort belongs though. I think we need >> a standard way of compressing an X.509 cert with the goal of fitting >> it in under 200 bytes. Maybe this compressed cert is only used at >> joining in 6TiSCH, or maybe border routers can compress/decompress >> along with the 6LoWPAN header so we can use it end-to-end. >> >> — >> >> Jonathan >> >> On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) >> > wrote: >> >>> Hello Jonathan: >>> Are you suggesting that we define a “6LoWPAN compression” for a >>> certificate? >>> Cheers, >>> Pascal >>> *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org]*On >>> Behalf Of*Jonathan Simon >>> *Sent:*vendredi 31 octobre 2014 00:31 >>> *To:*6tisch-security@ietf.org >>> *Subject:*[6tisch-security] X.509 Cert sizes and joining flows >>> I voiced my concern a while back about certificate exchanges making >>> joining really slow: >>> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html >>> >>> There I assumed a 300-byte compressed cert. Obviously, a 1500-byte >>> cert is going to be 5x worse. >>> One reason the certs are big is that there is a lot of stuff we >>> don't need, or may not need, or could compress a la 6lo. >>> Version: could be elided? >>> Serial number: Maybe this is the EUI of the device (elidable). >>> Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to >>> cover the full expanded X.509 fields. >>> Issuer: may be compressible? >>> Validity: 26 bytes - do we need to be able to revoke certs, or could >>> this be handled on an app level. >>> Subject: can be empty >>> SubjectPublicKeyInfo: contains an algorithm definition (which can be >>> elided if we only use one) or compressed (if we support a few), and >>> the public key (32 bytes) >>> IssuerUniqueIdentifier: optional >>> SubjectUniqueIdentifier: optional >>> Extensions: optional, but if we don't include a subject we might >>> want to support subjectAltName, again probably in compressed form. >>> SignatureAlgorithm: can be elided if we only use one or compressed >>> if we support a few >>> Other fields? >>> Point is, I think we can get this to fit into 2 packets and I think >>> that should be our target unless there’s a really a compelling >>> reason to include fields. >>> -- >>> Jonathan Simon >> >> >> >> This body part will be downloaded on demand. > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040700030201080200050008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Jonathan:

Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014).

Best regards, Rene

On 10/31/2014 12:26 PM, Rene Struik wrote:
Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) configuration steps.
Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- which is still outstanding BTW.
Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key validity period.
b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one).

Email of May 20, 2014 with outstanding issues:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes: 
get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this).  Note RS: Shouldn't, e.g., Dust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" device in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
Pascal -

Yes - I don’t know where the effort belongs though.  I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

— 

Jonathan 

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Hello Jonathan:
 
Are you suggesting that we define a “6LoWPAN compression” for a certificate?
 
Cheers,
 
Pascal
 
From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Jonathan Simon
Sent: vendredi 31 octobre 2014 00:31
To: 6tisch-security@ietf.org
Subject: [6tisch-security] X.509 Cert sizes and joining flows
 
I voiced my concern a while back about certificate exchanges making joining really slow:
 
 
There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.
 
One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.
 
Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).
Signature:  ~80 bytes for secp256r1 (128-bits protection).  Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support subjectAltName, again probably in compressed form.
SignatureAlgorithm: can be elided if we only use one or compressed if we support a few
Other fields?
 
Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there’s a really a compelling reason to include fields.
 
-- 
Jonathan Simon



This body part will be downloaded on demand.


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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------040700030201080200050008-- From nobody Mon Nov 3 20:27:15 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 6222F1A6EF9; Mon, 3 Nov 2014 20:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 SF8H98hP3afk; Mon, 3 Nov 2014 20:27:10 -0800 (PST) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4752C1A1C03; Mon, 3 Nov 2014 20:27:09 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o147.mxlogic.net(mxl_mta-8.2.0-0) with ESMTP id c9558545.0.87062.00-345.214316.p01c11o147.mxlogic.net (envelope-from ); Mon, 03 Nov 2014 21:27:09 -0700 (MST) X-MXL-Hash: 5458559d4ac8df2f-2bd25e51f53ffd51bf7ad1763bfa6e67b47ad9f0 Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 5B95C741EB; Mon, 3 Nov 2014 20:27:08 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rl12so6574734iec.24 for ; Mon, 03 Nov 2014 20:27:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.40.141 with SMTP id o135mr12267478ioo.26.1415075227895; Mon, 03 Nov 2014 20:27:07 -0800 (PST) Received: by 10.107.15.151 with HTTP; Mon, 3 Nov 2014 20:27:07 -0800 (PST) In-Reply-To: <54583572.6020502@gmail.com> References: <3C90505D-AF81-493B-A29A-86F2A1A5A207@linear.com> <5453B837.5040305@gmail.com> <54583572.6020502@gmail.com> Date: Mon, 3 Nov 2014 20:27:07 -0800 Message-ID: From: Jonathan Simon To: Rene Struik Content-Type: multipart/alternative; boundary=001a1141f0104a105f050700e0c8 X-AnalysisOut: [v=2.1 cv=U/WGDIbu c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=pGLkceISAAAA:8 a=YlVTAMxIAAAA:8 a=1XWaLZrsAA] X-AnalysisOut: [AA:8 a=48vgC7mUAAAA:8 a=SyYMxH9GAAAA:8 a=AUd_NHdVAAAA:8 a=] X-AnalysisOut: [xNjghb5tWkwzJ54BojIA:9 a=LuZtJmNiMv6PlYp_:21 a=PepowG6E4-t] X-AnalysisOut: [p0P4j:21 a=QEXdDO2ut3YA:10 a=wUAfXdCGL-oA:10 a=G1HyQLfxkfk] X-AnalysisOut: [A:10 a=19wCD08tTksA:10 a=vsVyj9psLt0A:10 a=yRLhjdVT-pYA:10] X-AnalysisOut: [ a=uztyEWA5df8A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_ds0YA:10 a=A] X-AnalysisOut: [eFSex2-gKoA:10 a=QxAq9r8ObNgA:10 a=B6niZy2Ubl4A:10 a=nJULN] X-AnalysisOut: [bPdoQ66ZcHodqAA:9 a=FP_DtNxTU6GU4ckT:21 a=E9H_5z5ZNP6pEb0u] X-AnalysisOut: [:21 a=zXgT6hFItCxjYJJd:21] X-Spam: [F=0.6941747573; CM=0.500; MH=0.694(2014110326); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/IrPfjUGYIT_Ku-o-qZ5ZCH7BM2s Cc: "Pascal Thubert \(pthubert\)" , Jonathan Simon , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] X.509 Cert sizes and joining flows X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jsimon@linear.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: Tue, 04 Nov 2014 04:27:14 -0000 --001a1141f0104a105f050700e0c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For minimal, there's a link key and a DTLS session to establish. Maybe something else I'm missing. In a typical WirelessHART network, there are multiple end-to-end CCM* security sessions, run-time slotframes and links, mesh-under routing information, set one or more timing parents, a bunch of timers (e.g. for statistics collection) - somewhere ~ 5-600 bytes, but it isn't necessarily as compact as CoAP could be. Jonathan On Mon, Nov 3, 2014 at 6:09 PM, Rene Struik wrote: > Hi Jonathan: > > Do you have some ballpark numbers for the size of configuration info to > play around with? Please see below (my Que to you of Fri Oct 31, 2014). > > Best regards, Rene > > On 10/31/2014 12:26 PM, Rene Struik wrote: > > Hi Jonathan: > > The join protocol includes (1) authentication; (2) authorization; (3) > configuration steps. > Without hands tied behind the back with protocol design, I anticipate the > main communication overhead of the join protocol to be with the > configuration step (#3) and *not* with the underlying authenticated key > agreement scheme (#1). Here, configuration relates both to security manag= er > to joining node info and vice-verse. > > See also item #a of my May 20, 2014 email -- *which is still outstanding > BTW.* > Que - Would you like to take this one on? {as first step, what about > providing a rough number, say, 1500 bytes [fill in correct number here]}. > > Some brief feedback on certificate sizes: > a) certificates should definitely have policy fields, including key > validity period. > b) certificate compression is of course possible, including that of > certificate issuer (whether the latter would be prudent remains to be see= n). > c) some of your figures are too pessimistic, e.g., P-256 keys are 65 byte= s > in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be us= ed > as SubjectPublicKey field, but depends on naming issues (see item #b of m= y > May 20, 2014 message). > d) there is no absolute need to use X509 certs, which would add > considerable freedom to cut down overhead. > > I estimate one can implement the authentication scheme (#1) with one or > two 802.15.4e frames in each protocol flow (assuming cert chains of lengt= h > one). > > Email of May 20, 2014 with outstanding issues: > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.htm= l > > a) Packet sizes: > get more info on packet sizes configuration parms, as w/HART uses. Note > RS: during call, Tom Phinney suggested contacting Wally Bratt from HART > Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust Networks have > info on packet sizes/structure?; ISA SP100.11a metrics would also help, a= s > would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points > here? > b) Device Ids: > With industrial control, network manager would look up "tag name" device > in pre-configured database. Details on tag name syntax, how assigned, and > how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney cou= ld > point at tag name syntax and lifecycle aspects here? > > On 10/31/2014 11:48 AM, Jonathan Simon wrote: > > Pascal - > > Yes - I don=E2=80=99t know where the effort belongs though. I think we = need a > standard way of compressing an X.509 cert with the goal of fitting it in > under 200 bytes. Maybe this compressed cert is only used at joining in > 6TiSCH, or maybe border routers can compress/decompress along with the > 6LoWPAN header so we can use it end-to-end. > > =E2=80=94 > > Jonathan > > On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > Hello Jonathan: > > Are you suggesting that we define a =E2=80=9C6LoWPAN compression=E2=80=9D= for a > certificate? > > Cheers, > > Pascal > > *From:* 6tisch-security [mailto:6tisch-security-bounces@ietf.org > <6tisch-security-bounces@ietf.org>] *On Behalf Of *Jonathan Simon > *Sent:* vendredi 31 octobre 2014 00:31 > *To:* 6tisch-security@ietf.org > *Subject:* [6tisch-security] X.509 Cert sizes and joining flows > > I voiced my concern a while back about certificate exchanges making > joining really slow: > > > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.htm= l > > > There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert > is going to be 5x worse. > > One reason the certs are big is that there is a lot of stuff we don't > need, or may not need, or could compress a la 6lo. > > Version: could be elided? > Serial number: Maybe this is the EUI of the device (elidable). > Signature: ~80 bytes for secp256r1 (128-bits protection). Needs to > cover the full expanded X.509 fields. > Issuer: may be compressible? > Validity: 26 bytes - do we need to be able to revoke certs, or could > this be handled on an app level. > Subject: can be empty > SubjectPublicKeyInfo: contains an algorithm definition (which can be > elided if we only use one) or compressed (if we support a few), and the > public key (32 bytes) > IssuerUniqueIdentifier: optional > SubjectUniqueIdentifier: optional > Extensions: optional, but if we don't include a subject we might want to > support subjectAltName, again probably in compressed form. > SignatureAlgorithm: can be elided if we only use one or compressed if we > support a few > Other fields? > > Point is, I think we can get this to fit into 2 packets and I think that > should be our target unless there=E2=80=99s a really a compelling reason = to include > fields. > > -- > Jonathan Simon > > > > > This body part will be downloaded on demand. > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (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. --001a1141f0104a105f050700e0c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For minimal, there's a link key and a DTLS sessio= n to establish. Maybe something else I'm missing.

In a typ= ical WirelessHART network, there are multiple end-to-end CCM* security sess= ions,=C2=A0 run-time slotframes and links, mesh-under routing information, = set one or more timing parents, a bunch of timers (e.g. for statistics coll= ection)=C2=A0 -=C2=A0 somewhere ~ 5-600 bytes, but it isn't necessarily= as compact as CoAP could be.

Jonathan

On Mon, Nov 3, 2014 at 6:09 PM, Rene = Struik <rstruik.ext@gmail.com> wrote:
=20 =20 =20
Hi Jonathan:

Do you have some ballpark numbers for the size of configuration info to play around with? Please see below (my Que to you of Fri Oct 31, 2014).

Best regards, Rene

On 10/31/2014 12:26 PM, Rene Struik wrote:
=20
Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) configuration steps.
Without hands tied behind the back with protocol design, I anticipate the main communication overhead of the join protocol to be with the configuration step (#3) and *not* with the underlying authenticated key agreement scheme (#1). Here, configuration relates both to security manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- which is still outstanding BTW.
Que - Would you like to take this one on? {as first step, what about providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key validity period.
b) certificate compression is of course possible, including that of certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 could be used as SubjectPublicKey field, but depends on naming issues (see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or two 802.15.4e frames in each protocol flow (assuming cert chains of length one).

Email of May 20, 2014 with outstanding issues:
http://w= ww.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes:=C2=A0
get more info on packet sizes configuration parms, as w/HART uses. Note RS: during call, Tom Phinney suggested contacting Wally Bratt from HART Comm. Foundation for this).=C2=A0 Note RS: Shouldn't, e.g., D= ust Networks have info on packet sizes/structure?; ISA SP100.11a metrics would also help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" devic= e in pre-configured database. Details on tag name syntax, how assigned, and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
=20 Pascal -

Yes - I don=E2=80=99t know where the effort belongs though.=C2= =A0 I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

=E2=80=94=C2=A0=

Jonathan=C2=A0

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <p= thubert@cisco.com> wrote:

Hello Jonathan:
=C2=A0
Are you suggesting that we define a =E2=80=9C6LoWPAN compress= ion=E2=80=9D for a certificate?
=C2=A0
Cheers,
=C2=A0
Pascal
=C2=A0
From:=C2=A06tisch-security [ma= ilto:6tisch-security-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Jonathan Simon
Sent:=C2=A0vendredi 31 octobre 2014 00:31
To:=C2=A06tisch-security@ietf.org
Subject:=C2=A0[6tisch-secur= ity] X.509 Cert sizes and joining flows
=C2=A0
I voiced my concern a while back about certificate exchanges making joining really slow:
=C2=A0
=C2=A0
There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.
=C2=A0
One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.
=C2=A0
Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).<= /u>
Signature: =C2=A0~80 bytes for secp256r1 (128-bits protection). =C2=A0Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.=
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support=C2=A0subjectAltName, again probably i= n compressed form.
SignatureAlgorithm:=C2=A0can be elided if we only use one or compressed if we support a few
Other fields?
=C2=A0
Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there=E2=80=99s a really a compelling reason = to include fields.
=C2=A0
--=C2=A0
Jonathan Simon



This body part will be downloaded on demand.


--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=



--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com

**LINEAR TECHNOLOGY=C2=A0CORPORATION**=C2=A0<= br> *****Internet Email Confidentiality=C2=A0Notice*****=C2=A0
=C2=A0This e-mail transmission, and any=C2=A0documents, files or previous= =20 e-mail=C2=A0messages attached to it may contain=C2=A0confidential informati= on that is=C2=A0legally privileged. If you are not the=C2=A0intended recipient, or= a=20 person=C2=A0responsible for delivering it to the=C2=A0intended recipient, you are hereby=C2=A0notified that any disclosure,=20 copying,=C2=A0distribution or use of any of the=C2=A0information contained = in or=20 attached=C2=A0to this transmission is STRICTLY=C2=A0PROHIBITED. If you have= =20 received this=C2=A0transmission in error, please=C2=A0immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original=C2=A0transmission and its atta= chments=C2=A0without reading or saving in any=C2=A0manner. Thank you.
--001a1141f0104a105f050700e0c8-- From nobody Tue Nov 4 07:30:34 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 9A95D1A8A10 for <6tisch-security@ietfa.amsl.com>; Tue, 4 Nov 2014 07:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.997, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01, 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 77_KiB2-3ai2 for <6tisch-security@ietfa.amsl.com>; Tue, 4 Nov 2014 07:30:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AFD1A8A0E for <6tisch-security@ietf.org>; Tue, 4 Nov 2014 07:30:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F40220028 for <6tisch-security@ietf.org>; Tue, 4 Nov 2014 10:32:07 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3F06B637F4; Tue, 4 Nov 2014 10:30:28 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 27EDA637F2 for <6tisch-security@ietf.org>; Tue, 4 Nov 2014 10:30:28 -0500 (EST) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> X-Attribution: mcr 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/3ZVVbRjHZr09aPI_9ms364wBQL8 Subject: [6tisch-security] minutes from call 2014-10-28 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: Tue, 04 Nov 2014 15:30:32 -0000 --=-=-= My appologies for taking so long to get these out. The call this week is in 30 minutes at: > Meeting number: 645 146 419 Meeting password: timeslot Audio > connection: 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > etherpad for meeting: > http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt > please note that google/browser-using-google-data might complain about it > being a phising site, it is likely a false positive, and I've let > ietf-action know about it. 2014-10-28 call started 11am EST. Attending - Thomas Watteyne - Michael Richardson - Jonathan Simon - Kris Pister - Mike Seewald - Nancy Cam-Winget We started the meeting by attempting to recap the discussion in the Mailing List. Michael asks Kris to do the recap. The thread starts at: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00212.html The result of the discussion is that we have some terminology problems with the use of "join key" --- we agreed that we would use the following terms: join network - A 802.15.4e network whose well known global encryption and authentication key is "JOIN6TISCH". unique join key - a symmetric key shared between a newly joining node, and the JCE. This key supports smaller installations for which asymmetric methods are considered too large well known beacon key - this is the key "JOIN6TISCH" MR discussed that while the unique join key might in some situations not be unique (we can not prevent use of pin "0000" a la Bluetooth headsets), we should never make a protocol that depends upon the key being known by more than one node. We then had a discussion about the term "trust anchors". MCR said that the use of this term will cause some security people to assume that this is related to the set of trust anchors present in web browsers; that some interaction with the Verisign/Komodo/etc. is intended, when it really is about connection to some industry consortia, or perhaps only to the vendor's CA. We covered the problem of the node knowing if it is joining the right network, that "this is the JCE you are looking for" (Star Wars droids reference). The oil refinery situation was raised; where competitors have equipment within radio distance of each other, and often sell/lease it among themselves. MR: suggestion: certificate given by JCE to node, contains authorization with "I am your owner". there is a set of delegation in supply chain. node can authenticatie that. node need to go to its vendor KP: so go out to the Internet and contact the vendor? MR: don't suggest node or JCE do this online. Michael Belinger raised fraud and reselling. issue is that, when you purchase a node, you have to install. vendor could veto a resell market if was involved online. example with lightbulbs MR: opinion is that the way you get that certificate is out of scope. Here is your MAC id and certificate of who owns you We had a discussion about possible ways that this introduces a vendor-lockin DRM, and the negative press that might result. This is the reason for the 802.1AR installation of a LDevID after the join process, as this permits/supports resell and further econonic activity without permission of the vendor. We agreed that there would never be a requirement to go out to the Internet. MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to explain relative to SIDR, but SIDR work was not known. We discussed why we have a well-known-beacon key at all: mixing traffic from other sources users of that spectrum, and also concern that some MACs may be unable to deal with unencrypted and encrypted traffic being received at the same time. We had a discussion about the 10/11 flows which are summarized as follows: MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop by hop and e2e DTLC/6top) MR: TLS session setup consists of 2 exchanges: . client hello (client presents his capabilities) . server helo (new node) responds his capabilities) . those packets re 100-150 bytes. possibly 60-70 bytes. suspect will be 2 frames . allow to agree on cipher, need crypto agility . would be ideal is JCE presents 2 options, AES-TCM and other . second exchange involves client certification, and response with server certificate and DH . packet ~1-2kB size. can be in smaller pieces . biggest pieces in this is supplier chain of certificate that proves own this node . upper part of chain COULD be cached by join assistant. but, most of statements will be mote-specific Agenda for next, second DODAG, how do we get that mode online: text in section 3 starting with: "The specific mechanism to enable end to end connectivity with the JCE" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVFjxEYCLcPvd0N1lAQLTVQf/YF8iwDhjUCUWv/8WhBad4dWJwg/d3y9e T8YavPTOvUwLOYKbNSsnSxAv4yhfFtg4xPOD+AzowR+oNqVvkDhK2T67TScZIwTK rCqSb5asbPVeOYjJupSPjRC/812767cLrkuRJfs/LFelGie62UZOr5YLgjJaao2D Yjpu/pjMvCuPUUKIJ05/QQjM3I5FdasS8ReeBM+EC9YeFspIn5ac5+Zu2XHTZTR7 6RkLGo1lgDqikUjRGbrNfC0tKbTC+fsaRB99nZJaGXSunlRyEoMuFTWUDZKZYjOl 0Sq2aCAw1+1nKIjL7q6S7UQmbbpWkGYseHhIeHWFJ4M6fv+LCaCFgQ== =lLYH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 4 09:16: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 E8CD71A9149; Tue, 4 Nov 2014 09:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, 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 LRgXrQ3oNbNJ; Tue, 4 Nov 2014 09:16:31 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A801A90DF; Tue, 4 Nov 2014 09:16:31 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id r10so14054313pdi.30 for ; Tue, 04 Nov 2014 09:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=G2rQyfOC9IP8fi+L6hWLate4i7MHvtlPrE2M6s8k4b0=; b=u5IQbZHKy2L0HkwFb3CAKgPi3KSBRWPikaHSIDsrszO7l7A6kF/njtqKYSjkFB/WgG A7779T4MjCGLSanbtNgw4HWOQXNhNT6RMUwJcIDBBXqCLUDAvN0GySidL3gYD/0pyQOi qr47kL1YMQsSJnTXD7hPPMcQiLvfn2Ao5MvuzGKAphv45PCkTK20GXcu9bgQxMhHu8fO MHoGWtXM5fJWbZ90ea5pguCZZrTXIJFL3bYJ7/3astaZhoaaHIxKchsefeLELN9cT9tx S4omjNQIpotoqKDXIimYgr+XLtAH67C/rmNuPP0FObGNYHRq6+uxV26EW3dD5ib2zihw Pysw== X-Received: by 10.70.45.40 with SMTP id j8mr11591897pdm.130.1415121390357; Tue, 04 Nov 2014 09:16:30 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.88.42 with HTTP; Tue, 4 Nov 2014 09:16:10 -0800 (PST) In-Reply-To: <7180.1415115028@sandelman.ca> References: <7180.1415115028@sandelman.ca> From: Thomas Watteyne Date: Tue, 4 Nov 2014 09:16:10 -0800 X-Google-Sender-Auth: Vh5aEJJxu9mBSvhT6utJsJheqwk Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=047d7bf18b76c9549005070b9f83 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/XuBphj99UzEuWdrrGty2BGBvuns Subject: Re: [6tisch-security] minutes from call 2014-10-28 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: Tue, 04 Nov 2014 17:16:34 -0000 --047d7bf18b76c9549005070b9f83 Content-Type: text/plain; charset=UTF-8 [adding the 6TiSCH ML] On Tue, Nov 4, 2014 at 7:30 AM, Michael Richardson wrote: > > My appologies for taking so long to get these out. > The call this week is in 30 minutes at: > > Meeting number: 645 146 419 Meeting password: timeslot Audio > > connection: 1-877-668-4493 Call-in toll free number (US/Canada) > > 1-650-479-3208 Call-in toll number (US/Canada) > > > > https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02 > > > etherpad for meeting: > > http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt > > > please note that google/browser-using-google-data might complain > about it > > being a phising site, it is likely a false positive, and I've let > > ietf-action know about it. > > > 2014-10-28 call started 11am EST. > > Attending > - Thomas Watteyne > - Michael Richardson > - Jonathan Simon > - Kris Pister > - Mike Seewald > - Nancy Cam-Winget > > We started the meeting by attempting to recap the discussion in the Mailing > List. Michael asks Kris to do the recap. The thread starts at: > > http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00212.html > > The result of the discussion is that we have some terminology problems with > the use of "join key" --- we agreed that we would use the following terms: > > join network - A 802.15.4e network whose well known global > encryption and authentication key is "JOIN6TISCH". > unique join key - a symmetric key shared between a newly joining node, > and > the JCE. This key supports smaller installations for > which > asymmetric methods are considered too large > well known beacon key - this is the key "JOIN6TISCH" > > MR discussed that while the unique join key might in some situations not be > unique (we can not prevent use of pin "0000" a la Bluetooth headsets), we > should never make a protocol that depends upon the key being known by more > than one node. > > We then had a discussion about the term "trust anchors". > MCR said that the use of this term will cause some security people to > assume > that this is related to the set of trust anchors present in web browsers; > that some interaction with the Verisign/Komodo/etc. is intended, when it > really is about connection to some industry consortia, or perhaps only to > the > vendor's CA. > > We covered the problem of the node knowing if it is joining the right > network, that "this is the JCE you are looking for" (Star Wars droids > reference). The oil refinery situation was raised; where competitors have > equipment within radio distance of each other, and often sell/lease it > among > themselves. > > MR: suggestion: certificate given by JCE to node, contains authorization > with > "I am your owner". there is a set of delegation in supply chain. node > can > authenticatie that. node need to go to its vendor > > KP: so go out to the Internet and contact the vendor? > MR: don't suggest node or JCE do this online. Michael Belinger raised > fraud and > reselling. issue is that, when you purchase a node, you have to > install. vendor could veto a resell market if was involved online. > example > with lightbulbs > > MR: opinion is that the way you get that certificate is out of scope. Here > is > your MAC id and certificate of who owns you > > We had a discussion about possible ways that this introduces a > vendor-lockin > DRM, and the negative press that might result. This is the reason for the > 802.1AR installation of a LDevID after the join process, as this > permits/supports resell and further econonic activity without permission of > the vendor. > > We agreed that there would never be a requirement to go out to the > Internet. > > MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to > explain relative to SIDR, but SIDR work was not known. > > We discussed why we have a well-known-beacon key at all: mixing traffic > from > other sources users of that spectrum, and also concern that some MACs may > be > unable to deal with unencrypted and encrypted traffic being received at the > same time. > > We had a discussion about the 10/11 flows which are summarized as follows: > > MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop > by hop and e2e DTLC/6top) > MR: TLS session setup consists of 2 exchanges: > . client hello (client presents his capabilities) > . server helo (new node) responds his capabilities) > . those packets re 100-150 bytes. possibly 60-70 bytes. suspect will > be 2 frames > . allow to agree on cipher, need crypto agility > . would be ideal is JCE presents 2 options, AES-TCM and other > . second exchange involves client certification, and response with > server certificate and DH > . packet ~1-2kB size. can be in smaller pieces > . biggest pieces in this is supplier chain of certificate that proves > own this node > . upper part of chain COULD be cached by join assistant. but, most of > statements will be mote-specific > > Agenda for next, second DODAG, how do we get that mode online: > text in section 3 starting with: > "The specific mechanism to enable end to end connectivity with the JCE" > > > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7bf18b76c9549005070b9f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[adding the 6TiSCH ML]
On Tue, Nov 4, 2014 at 7:30 AM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

My appologies for taking so long to get these out.
The call this week is in 30 minutes at:
=C2=A0 =C2=A0 > Meeting number: 645 146 419 Meeting password: timeslot A= udio
=C2=A0 =C2=A0 > connection: 1-877-668-4493 Call-in toll free number (US/Canada)
=C2=A0 =C2=A0 > 1-= 650-479-3208 Call-in toll number (US/Canada)

=C2=A0 =C2=A0 > https://ietf.webex.com/iet= f/j.php?MTID=3Dm026b87ec5a630ca1ec44f2e79329ba02

=C2=A0 =C2=A0 > etherpad for meeting:
=C2=A0 =C2=A0 > http://etherpad.tools.ietf.org:900= 0/p/6tisch-security-6top-xml.txt

=C2=A0 =C2=A0 > please note that google/browser-using-google-data might = complain about it
=C2=A0 =C2=A0 > being a phising site, it is likely a false positive, and= I've let
=C2=A0 =C2=A0 > ietf-action know about it.


2014-10-28 call started 11am EST.

Attending
- Thomas Watteyne
- Michael Richardson
- Jonathan Simon
- Kris Pister
- Mike Seewald
- Nancy Cam-Winget

We started the meeting by attempting to recap the discussion in the Mailing=
List.=C2=A0 Michael asks Kris to do the recap.=C2=A0 The thread starts at:<= br> =C2=A0 http://www.ietf.org/mail-archive/web/6= tisch-security/current/msg00212.html

The result of the discussion is that we have some terminology problems with=
the use of "join key" --- we agreed that we would use the followi= ng terms:

=C2=A0 join network - A 802.15.4e network whose well known global
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encryption an= d authentication key is "JOIN6TISCH".
=C2=A0 unique join key - a symmetric key shared between a newly joining nod= e, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the JCE.=C2= =A0 This key supports smaller installations for which
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asymmetric me= thods are considered too large
=C2=A0 well known beacon key - this is the key "JOIN6TISCH"

MR discussed that while the unique join key might in some situations not be=
unique (we can not prevent use of pin "0000" a la Bluetooth heads= ets), we
should never make a protocol that depends upon the key being known by more<= br> than one node.

We then had a discussion about the term "trust anchors".
MCR said that the use of this term will cause some security people to assum= e
that this is related to the set of trust anchors present in web browsers; that some interaction with the Verisign/Komodo/etc. is intended, when it really is about connection to some industry consortia, or perhaps only to t= he
vendor's CA.

We covered the problem of the node knowing if it is joining the right
network, that "this is the JCE you are looking for" (Star Wars dr= oids
reference).=C2=A0 The oil refinery situation was raised; where competitors = have
equipment within radio distance of each other, and often sell/lease it amon= g
themselves.

MR: suggestion: certificate given by JCE to node, contains authorization wi= th
=C2=A0 =C2=A0 "I am your owner". there is a set of delegation in = supply chain. node can
=C2=A0 =C2=A0 authenticatie that. node need to go to its vendor

KP: so go out to the Internet and contact the vendor?
MR: don't suggest node or JCE do this online. Michael Belinger raised f= raud and
=C2=A0 =C2=A0 reselling. issue is that, when you purchase a node, you have = to
=C2=A0 =C2=A0 install. vendor could veto a resell market if was involved on= line. example
=C2=A0 =C2=A0 with lightbulbs

MR: opinion is that the way you get that certificate is out of scope. Here = is
=C2=A0 =C2=A0 your MAC id and certificate of who owns you

We had a discussion about possible ways that this introduces a vendor-locki= n
DRM, and the negative press that might result.=C2=A0 This is the reason for= the
802.1AR installation of a LDevID after the join process, as this
permits/supports resell and further econonic activity without permission of=
the vendor.

We agreed that there would never be a requirement to go out to the Internet= .

MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to explain relative to SIDR, but SIDR work was not known.

We discussed why we have a well-known-beacon key at all: mixing traffic fro= m
other sources users of that spectrum, and also concern that some MACs may b= e
unable to deal with unencrypted and encrypted traffic being received at the=
same time.

We had a discussion about the 10/11 flows which are summarized as follows:<= br>
MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop by= hop and e2e DTLC/6top)
MR: TLS session setup consists of 2 exchanges:
=C2=A0 =C2=A0 . client hello (client presents his capabilities)
=C2=A0 =C2=A0 . server helo (new node) responds his capabilities)
=C2=A0 =C2=A0 . those packets re 100-150 bytes. possibly 60-70 bytes. suspe= ct will be 2 frames
=C2=A0 =C2=A0 . allow to agree on cipher, need crypto agility
=C2=A0 =C2=A0 . would be ideal is JCE presents 2 options, AES-TCM and other=
=C2=A0 =C2=A0 . second exchange involves client certification, and response= with server certificate and DH
=C2=A0 =C2=A0 . packet ~1-2kB size. can be in smaller pieces
=C2=A0 =C2=A0 . biggest pieces in this is supplier chain of certificate tha= t proves own this node
=C2=A0 =C2=A0 . upper part of chain COULD be cached by join assistant. but,= most of
=C2=A0 =C2=A0 statements will be mote-specific

Agenda for next, second DODAG, how do we get that mode online:
text in section 3 starting with:
=C2=A0 =C2=A0"The specific mechanism to enable end to end connectivity= with the JCE"







--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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


--047d7bf18b76c9549005070b9f83-- From nobody Wed Nov 12 08:50:53 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 BA6E31A8AC8; Wed, 12 Nov 2014 08:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.997, RP_MATCHES_RCVD=-0.594, 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 eNcWk_nxUDC4; Wed, 12 Nov 2014 08:50:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535671A895E; Wed, 12 Nov 2014 08:50:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B472D20098; Wed, 12 Nov 2014 11:52:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 549EA637F4; Wed, 12 Nov 2014 11:50:45 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 333F6637F2; Wed, 12 Nov 2014 11:50:45 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org, 6tisch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 210B.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/-F1TVehdA4fVqZ7ZfkwNxZq-GNM Subject: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 16:50:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This text is the architecture results of the secure (zero-touch) design tea= m. The realization that we should use loose source routes is due to Pascal. I believe this goes into a new section between 10. Centralized vs. and 11. IANA Considerations. Interspersed is some text that I think goes i= n to section 12. Security Considerations.=20 If you are interested in the history of this text, or some additional more = implementation side ideas, then I recommend reviewing the diff http://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security-6= top-03&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--sec= urity-6top-04 10B. Architectural requirements of join protocol 10B.1. Entities involves in the join process The following actors are involved: there is a new joining node. It is (radio) adjacent to the join assistant. The join assistant is part of the production network, and participates in one or more DODAGs, such that it is reachable from the 6LBR, and the JCE. 10B.2. Join Protocol deliverables This section works from the ultimate goal, and goes backwards to prerequisite actions. (Section 6 presents the protocol from beginning to end order) The ultimate goal of the join protocol is to provide a new node with a locally significant security credentials that it is able to take part in the network directly. The credentials may vary by deployment. They can be one of: 1) a network-wide shared symmetric key (this is the production network key, or MasterKey) 2) a locally significant (one-level only) 802.11AR type LDevID certificate (which allows it to negotiate a pair-wise keys) One of these two items is delivered by JCE to the joining node using the 6top protocol. That is, the JCE provisions using a secure "northbound" interface. The authentication of this interface the subject of the Join Protocol as explained below. The above credential are used for authentication to generate per-peer L2, using a key exchange protocol. The choice of key exchange protocol, and what kind of link and multicast keying needs to be done is also provisioned by the JCE. There are a number of options for doing this, such as: 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] (IMPORTANT, a good option. Uses certificates from common CA) 2) work in 802.15.9 (uses certificates from common CA) 3) Security Framework and Key Management Protocol Requirements for 6TiSCH [I-D.ohba-6tisch-security] (this document provides the phase 0 required, using the network-wide shared key) 4) Layer-2 security aspects for the IEEE 802.15.4e MAC [I-D.piro-6tisch-security-issues]: the MasterKey is used to derive per-peer L2 keys Per-peer L2 keying is critical when doing peer-2-peer schedule negotiation over 15.4 Information Elements. Therefore a network-wide layer-2 key is inappropriate for the self-organizing networks, and a protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. For networks where there is a PCE present and it will do all schedule computation, then the only trust relationship necessary is between the individual node and the PCE, and it MAY be acceptable to have a network-wide L2 key derived in ways such as [I-D.piro-6tisch-security-issues] describes in section ?. The trust relationship between the PCE and the joining node flows from the LDevID certificate loaded by the JCE. When the PCE and JCE are co- located, the existing 6top/DTLS security association could be reused. 10B.3. Join Protocol connection setup The intermediate level goal of the join protocol is to enable a Join Coordination Entity (JCE) to reach out to the new node, and install the credentials detailed above. The JCE must authenticate itself to the joining node so that the joining node will know that it has joined the correct network, and the joining node must authenticate itself to the JCE so that the JCE will know that this node belongs in the network. This two way authentication occurs in the 6top/CoAP/ DTLS session that is established between the JCE and the joining node. [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] explains how to access that information model using CoAP. This information model will include security attributes for the network. The JCE would therefore reach out to the joining node and simply provision appropriate security properties into the joining node, much like the PCE will provision schedules. This 6top-based secure join protocol has defined a push model for security provisioning by the JCE. This has been done for three reasons: 1) 6tisch nodes already have to have a 6top CoAP server for schedule provising 2) this permits the JCE to manage how many nodes are trying to join at the same time, and limit how much bandwidth/energy is used for the join operation, and also for the JCE to prioritize the join order for nodes. 3) making the JCE initiate the DTLS connection significantly simplies the certificate chains that must be exchanged as the most constrained side (the joining node) provides it's credentials first, and lets the less constrained JCE figure out what kind of certificate chain will be required to authenticate the JCE to the joining node. In EAP-TLS/802.1x situations, the TLS channel is created in the opposite direction, and it would have to complete in a tentative way, and then further authorization occur in-band. 10B.4. End to End considerations for Join Protocol In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node, there needs to be end-to-end IPv6 connectivity between those two entities. The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node. The joining node sends traffic to the join assistant, which forwards it using the normal RPL DODAG upwards routes, and which will reach the JCE using regular routing. The challenge is getting connectivity from the JCE to the joining node, as the DODAG will have no information about this node. Instead, the JCE will use loose-source routes to address packets first to the Join Assistant, which will then forward to the joining node. This has an interaction with the (strict) source routes used by non-storing DODAGs which would be used by the 6LBR to reach the Join Assistant. There are some alternatives to having full end to end connectivity which are discussed in the security considerations section. 12.1. Security Considerations: alternatives to source routes This goes into security-considerations section A number of alternatives were considered for creating end to end connectivity between the joining node and the JCE, but were rejected. (1) IPIP tunnel between Join Assistant and JCE (2) using straight RPL routing: the Join Assistant sends a DAO (3) using a separate RPL DODAG for join traffic (4) establishing a specific multi-hop 6tisch track for join traffic for each Join Assistant 12.1.1.1. IPIP tunnel This mechanism requires 40 bytes overhead per packet, and may require specific state to be created on the Join Assistant, or may open the network up to a resource exhaustion by malicious join nodes. This mechanism was rejected on due to byte count, because it would require code only needed for join, and because doing it securely may require a per-tunnel state to be maintained on the join assistant. 12.1.1.2. join existing DODAG This mechanism is to just have the new node join the DODAG as a leaf node. The join assistant would issue a DAO for the new node. If a storing DODAG was used, this would directly cost state in all parent nodes of the Join Assistant, subjecting the lower-rank parts of the network to significant denial of service attacks. On a non-storing DODAG the situation is significantly better: no state is created by the presence of the leaf node except in the 6LBR, where available resources may be higher. This mechanism was rejected in favour of the loose source routed option as this the loose source routed option always works even for storing DODAGs, and is otherwise exactly equivalent in terms of network bandwidth cost. 12.1.1.3. join a DODOAG for joining One option to deal with the problem of resource consumption in the storing DODAG case is to use a second DODAG. This mechanism was rejected as it consumes resources in all nodes for the second DODAG, and many implementations support on a single DODAG. While storing DODAGs have a lighter network impact than non-storing ones (due to the lack of source routes), the PCE can control how much network bandwidth can be wasted by malicious join nodes using the regular 6tisch mechanisms, and this can be tuned. A second DODAG would be a sunk cost with no tuning possible. 12.1.1.4. create 6tisch track to form mesh-under This mechanism would use 6tisch tracks so that traffic from the JCE would be switched from 6LBR to join node. A track would be required to each join assistant. This is an optimized form of source routing. This mechanism was not rejected, rather it was observed that it may be applied to any mechanism that uses source routing, and is an optimization; it has a certain cost in the form of intermediary node state, but that this state is not created by a malicious join node, rather it is created by the PCE. 10B.5. Join node discovery mechanism Continuing to work backwards, in order the JCE reach out to provision the Joining Node, it needs to know that the new node is present. This is done by taking advantage of the 6lowPAN Address Resolution Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address to also be sent up to the 6LBR for duplicate detection using the DAR/ DAC mechanism. The 6LBR simply needs to tell the JCE about this. A new protocol may be required for the situation where the JCE, PCE and 6LBR are not co-located; it may be that this protocol could be simply a DAR in some encapsulation. The details of this are currently out of scope for the architecture, as they affect interoperability between different vendors of JCE/6LBR/PCE rather than interoperability between the assistance/offload infrastructure, and the contrained nodes. Future work may specify this part. In addition to needing to know the joining devices address from the DAR/NS, the JCE also needs to know the joining node's IDevID. This is to determine if the node should even get any attention. At this point, the IDevID can be forged, it will be authenticated during the setup of the 6top control protocol in the DTLS certificate exchange. If the serialNumber attribute of the IDevID is less than 64 bits, then it is possible that it could be placed into the EUI-64 option of the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] EARO. The JCE needs to know the joining node's serialNumber to know if this is device that it should even attempt to provision; and if so, it may need to retrieve an appropriate certificate chain (see [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for the JCE to prove it is the legitimate owner of the joining node. Neither 802.1AR nor [RFC5280] provide any structure for the serialNumber, except that they are positive integers of up-to 20 octets in size (numbers up to 2^160). This specification would require that the serialNumber encoded in the IDevID be the same as the EUI-64 used by the device. Some consideration needs to be given as to whether there are privacy considerations to doing this: any observer that can see the join traffic, can also see the source MAC address of the node as well. Prior to being able to announce itself in a NS, the joining node needs to find the Join Network. This is done by listening to an extended beacon which are broadcast in designated slotframes by Join Assistants. The Extended Beacon provides a way for the Joining Node to synchronize itself to the overall timeslot schedule and provides an Aloha period in which the Joining Node can send a Router Soliticiation, and receive an appropriate Router Advertisement giving the Joining Node a prefix and default route to which to send join traffic. It may be possible to eliminate a message exchange if space for a Router Advertisement can be found as part of the Join Network Extended Beacon. This Enhanced Beacon would be distinct to the Join Network, and would be encrypted with the well-known Join Network key. 10B.5.1. prefixes to use for join traffic What prefix would the joining node for communication? There are three options: (1) just use link-local addresses (this may require that some traffic between 6LBR and JCE be IPIP tunneled) (2) use a prefix specifically for join traffic (may be easier with a join-only DODAG) (3) use the same prefix as the rest of the traffic (may require more complex ACLs, and leaks information to attackers) The simplest method is to use the link-local addresses for the 6top connection, and the cost of an IPIP tunnel between the unconstrained 6LBR and the JCE is not considered significant. =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) iQEVAwUBVGOP4oCLcPvd0N1lAQK7UggAo1DCIBps2qxJI1ZiwvtN9vx7lQ1k6SaL HbV9ANFrATeV9tGZ4SfbIrMO/7EQeK6MckzH8qeQuMNNlZ+afYAPwyIqp3mneZpR MW2eWubQju3nWoZyu7G8cwzm3XHNKNjBjgUPZckOZBytmDE0neuYqpVbn4Rja0lB DQwaX9O9jZ9jr83ppX43z6//k1EbeteNOUs+RxqVRheEjlk1lWm66CHyaMgt9bro dBwb9fdUaNGFy/BaemLBe51yBa8Kp/AMqaZBfOiLWqpIzu3oSo2CkrEGfqvC/AMV drV/HG0vM4BwbfT2jLH88arYYwNwZDhObWDiIc3hhD0iT+OPVOmTKw== =fzhi -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 12 10:38: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 EEBBB1A00E9; Wed, 12 Nov 2014 10:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 8labmi_y5hsB; Wed, 12 Nov 2014 10:37:54 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A031ACE07; Wed, 12 Nov 2014 10:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15714; q=dns/txt; s=iport; t=1415817462; x=1417027062; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sWkzxSPlvLciXEGZGeVRT72vtYpLPZYlYuaS8J5dftw=; b=b7P+CY+SGEEY/37m8qbePnYRu2P+YkcslgGHHZbB7Q4wB4sK348dtggZ nb9ZQcz2U7kIWqbNL5tKxU0F/mk3pHSNNbWsYwKcfXJKyN74pTmoM5gEP DUn0uvQf7CPa4ZIovAW4LFhhTu04IB5Cl1xUGMhnqcQ30LKT3BZIPTlsU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALCnY1StJV2S/2dsb2JhbABbgw5UVAUEzDKHTQKBHRYBAQEBAX2EAgEBAQMBcgwHBAIBCBEBAwEBCx0HMhQDBggCBAESCAGILwkIBdA7AQEBAQEBAQEBAQEBAQEBAQEBAQEYjUYBgnYmOAaDJ4EeBYRvhl6GbYcbggSEDI19hzaCACCBXG2BB0GBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="95989911" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 12 Nov 2014 18:37:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sACIbePa011906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 18:37:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 12:37:40 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/pjTtNRE7Q7r4E+PcMhv5UkmHZxdUT0g Date: Wed, 12 Nov 2014 18:37:39 +0000 Deferred-Delivery: Wed, 12 Nov 2014 18:37:00 +0000 Message-ID: References: <20507.1415811045@sandelman.ca> In-Reply-To: <20507.1415811045@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.86.6] 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/xqvqPw5XQe9ZhgefCh6xe3zmR4U Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 18:37:58 -0000 Hello Michael: For the initial connection to the join assistant, we said that we'd use a w= ell-known key by default, following Ren=E9's initial recommendation. At som= e point of time, we also discussed the possibility to override that key by = configuration to allow to differentiate networks, making that key effective= ly a sort of ssid. I do not see any of this reflected below. Do I miss anything, else would yo= u agree that we add that stuff? Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Michael Richardson > Sent: mercredi 12 novembre 2014 08:51 > To: 6tisch-security@ietf.org; 6tisch@ietf.org > Subject: [6tisch-security] proposed security text for architecture draft >=20 >=20 > This text is the architecture results of the secure (zero-touch) design t= eam. > The realization that we should use loose source routes is due to Pascal. >=20 > I believe this goes into a new section between 10. Centralized vs. > and 11. IANA Considerations. Interspersed is some text that I think goes= in to > section 12. Security Considerations. >=20 > If you are interested in the history of this text, or some additional mor= e > implementation side ideas, then I recommend reviewing the diff > http://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security= -6top- > 03&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--secur= ity- > 6top-04 >=20 >=20 > 10B. Architectural requirements of join protocol >=20 > 10B.1. Entities involves in the join process >=20 > The following actors are involved: there is a new joining node. It > is (radio) adjacent to the join assistant. The join assistant is > part of the production network, and participates in one or more > DODAGs, such that it is reachable from the 6LBR, and the JCE. >=20 > 10B.2. Join Protocol deliverables >=20 > This section works from the ultimate goal, and goes backwards to > prerequisite actions. (Section 6 presents the protocol from > beginning to end order) >=20 > The ultimate goal of the join protocol is to provide a new node with > a locally significant security credentials that it is able to take > part in the network directly. The credentials may vary by > deployment. They can be one of: >=20 >=20 > 1) a network-wide shared symmetric key (this is the production > network key, or MasterKey) >=20 > 2) a locally significant (one-level only) 802.11AR type LDevID > certificate (which allows it to negotiate a pair-wise keys) >=20 > One of these two items is delivered by JCE to the joining node using > the 6top protocol. That is, the JCE provisions using a secure > "northbound" interface. The authentication of this interface the > subject of the Join Protocol as explained below. >=20 > The above credential are used for authentication to generate per-peer > L2, using a key exchange protocol. The choice of key exchange > protocol, and what kind of link and multicast keying needs to be done > is also provisioned by the JCE. There are a number of options for > doing this, such as: >=20 > 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] > (IMPORTANT, a good option. Uses certificates from common CA) >=20 > 2) work in 802.15.9 (uses certificates from common CA) >=20 > 3) Security Framework and Key Management Protocol Requirements for > 6TiSCH [I-D.ohba-6tisch-security] (this document provides the > phase 0 required, using the network-wide shared key) >=20 > 4) Layer-2 security aspects for the IEEE 802.15.4e MAC > [I-D.piro-6tisch-security-issues]: the MasterKey is used to > derive per-peer L2 keys >=20 > Per-peer L2 keying is critical when doing peer-2-peer schedule > negotiation over 15.4 Information Elements. Therefore a network-wide > layer-2 key is inappropriate for the self-organizing networks, and a > protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. >=20 > For networks where there is a PCE present and it will do all schedule > computation, then the only trust relationship necessary is between > the individual node and the PCE, and it MAY be acceptable to have a > network-wide L2 key derived in ways such as > [I-D.piro-6tisch-security-issues] describes in section ?. The trust > relationship between the PCE and the joining node flows from the > LDevID certificate loaded by the JCE. When the PCE and JCE are co- > located, the existing 6top/DTLS security association could be reused. >=20 > 10B.3. Join Protocol connection setup >=20 > The intermediate level goal of the join protocol is to enable a Join > Coordination Entity (JCE) to reach out to the new node, and install > the credentials detailed above. The JCE must authenticate itself to > the joining node so that the joining node will know that it has > joined the correct network, and the joining node must authenticate > itself to the JCE so that the JCE will know that this node belongs in > the network. This two way authentication occurs in the 6top/CoAP/ > DTLS session that is established between the JCE and the joining > node. >=20 > [I-D.ietf-6tisch-6top-interface] presents a way to interface to a > 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] > explains how to access that information model using CoAP. This > information model will include security attributes for the network. > The JCE would therefore reach out to the joining node and simply > provision appropriate security properties into the joining node, much > like the PCE will provision schedules. >=20 > This 6top-based secure join protocol has defined a push model for > security provisioning by the JCE. This has been done for three > reasons: >=20 > 1) 6tisch nodes already have to have a 6top CoAP server for schedule > provising >=20 > 2) this permits the JCE to manage how many nodes are trying to join > at the same time, and limit how much bandwidth/energy is used for > the join operation, and also for the JCE to prioritize the join > order for nodes. >=20 > 3) making the JCE initiate the DTLS connection significantly > simplies the certificate chains that must be exchanged as the > most constrained side (the joining node) provides it's > credentials first, and lets the less constrained JCE figure out > what kind of certificate chain will be required to authenticate > the JCE to the joining node. In EAP-TLS/802.1x situations, the > TLS channel is created in the opposite direction, and it would > have to complete in a tentative way, and then further > authorization occur in-band. >=20 > 10B.4. End to End considerations for Join Protocol >=20 > In order for a 6top/DTLS/CoAP connection to occur between the JCE and > the joining node, there needs to be end-to-end IPv6 connectivity > between those two entities. The joining node will not participate in > the route-over RPL mesh, but rather will be seen by the network as > being a 6lowpan only leaf-node. >=20 > The joining node sends traffic to the join assistant, which forwards > it using the normal RPL DODAG upwards routes, and which will reach > the JCE using regular routing. >=20 > The challenge is getting connectivity from the JCE to the joining > node, as the DODAG will have no information about this node. > Instead, the JCE will use loose-source routes to address packets > first to the Join Assistant, which will then forward to the joining > node. This has an interaction with the (strict) source routes used > by non-storing DODAGs which would be used by the 6LBR to reach the > Join Assistant. >=20 > There are some alternatives to having full end to end connectivity > which are discussed in the security considerations section. >=20 > 12.1. Security Considerations: alternatives to source routes >=20 > This goes into security-considerations section >=20 > A number of alternatives were considered for creating end to end > connectivity between the joining node and the JCE, but were rejected. >=20 > (1) IPIP tunnel between Join Assistant and JCE >=20 > (2) using straight RPL routing: the Join Assistant sends a DAO >=20 > (3) using a separate RPL DODAG for join traffic >=20 > (4) establishing a specific multi-hop 6tisch track for join traffic > for each Join Assistant >=20 > 12.1.1.1. IPIP tunnel >=20 > This mechanism requires 40 bytes overhead per packet, and may require > specific state to be created on the Join Assistant, or may open the > network up to a resource exhaustion by malicious join nodes. >=20 > This mechanism was rejected on due to byte count, because it would > require code only needed for join, and because doing it securely may > require a per-tunnel state to be maintained on the join assistant. >=20 > 12.1.1.2. join existing DODAG >=20 > This mechanism is to just have the new node join the DODAG as a leaf > node. The join assistant would issue a DAO for the new node. If a > storing DODAG was used, this would directly cost state in all parent > nodes of the Join Assistant, subjecting the lower-rank parts of the > network to significant denial of service attacks. >=20 > On a non-storing DODAG the situation is significantly better: no > state is created by the presence of the leaf node except in the 6LBR, > where available resources may be higher. >=20 > This mechanism was rejected in favour of the loose source routed > option as this the loose source routed option always works even for > storing DODAGs, and is otherwise exactly equivalent in terms of > network bandwidth cost. >=20 > 12.1.1.3. join a DODOAG for joining >=20 > One option to deal with the problem of resource consumption in the > storing DODAG case is to use a second DODAG. >=20 > This mechanism was rejected as it consumes resources in all nodes for > the second DODAG, and many implementations support on a single DODAG. > While storing DODAGs have a lighter network impact than non-storing > ones (due to the lack of source routes), the PCE can control how much > network bandwidth can be wasted by malicious join nodes using the > regular 6tisch mechanisms, and this can be tuned. A second DODAG > would be a sunk cost with no tuning possible. >=20 > 12.1.1.4. create 6tisch track to form mesh-under >=20 > This mechanism would use 6tisch tracks so that traffic from the JCE > would be switched from 6LBR to join node. A track would be required > to each join assistant. This is an optimized form of source routing. >=20 > This mechanism was not rejected, rather it was observed that it may > be applied to any mechanism that uses source routing, and is an > optimization; it has a certain cost in the form of intermediary node > state, but that this state is not created by a malicious join node, > rather it is created by the PCE. >=20 > 10B.5. Join node discovery mechanism >=20 > Continuing to work backwards, in order the JCE reach out to provision > the Joining Node, it needs to know that the new node is present. > This is done by taking advantage of the 6lowPAN Address Resolution > Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address > to also be sent up to the 6LBR for duplicate detection using the DAR/ > DAC mechanism. The 6LBR simply needs to tell the JCE about this. A > new protocol may be required for the situation where the JCE, PCE and > 6LBR are not co-located; it may be that this protocol could be simply > a DAR in some encapsulation. The details of this are currently out > of scope for the architecture, as they affect interoperability > between different vendors of JCE/6LBR/PCE rather than > interoperability between the assistance/offload infrastructure, and > the contrained nodes. Future work may specify this part. >=20 > In addition to needing to know the joining devices address from the > DAR/NS, the JCE also needs to know the joining node's IDevID. This > is to determine if the node should even get any attention. At this > point, the IDevID can be forged, it will be authenticated during the > setup of the 6top control protocol in the DTLS certificate exchange. > If the serialNumber attribute of the IDevID is less than 64 bits, > then it is possible that it could be placed into the EUI-64 option of > the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] > EARO. The JCE needs to know the joining node's serialNumber to know > if this is device that it should even attempt to provision; and if > so, it may need to retrieve an appropriate certificate chain (see > [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for > the JCE to prove it is the legitimate owner of the joining node. >=20 > Neither 802.1AR nor [RFC5280] provide any structure for the > serialNumber, except that they are positive integers of up-to 20 > octets in size (numbers up to 2^160). This specification would > require that the serialNumber encoded in the IDevID be the same as > the EUI-64 used by the device. Some consideration needs to be given > as to whether there are privacy considerations to doing this: any > observer that can see the join traffic, can also see the source MAC > address of the node as well. >=20 > Prior to being able to announce itself in a NS, the joining node > needs to find the Join Network. This is done by listening to an > extended beacon which are broadcast in designated slotframes by Join > Assistants. The Extended Beacon provides a way for the Joining Node > to synchronize itself to the overall timeslot schedule and provides > an Aloha period in which the Joining Node can send a Router > Soliticiation, and receive an appropriate Router Advertisement giving > the Joining Node a prefix and default route to which to send join > traffic. >=20 > It may be possible to eliminate a message exchange if space for a > Router Advertisement can be found as part of the Join Network > Extended Beacon. This Enhanced Beacon would be distinct to the Join > Network, and would be encrypted with the well-known Join Network key. >=20 > 10B.5.1. prefixes to use for join traffic >=20 > What prefix would the joining node for communication? There are > three options: >=20 > (1) just use link-local addresses (this may require that some > traffic between 6LBR and JCE be IPIP tunneled) >=20 > (2) use a prefix specifically for join traffic (may be easier with a > join-only DODAG) >=20 > (3) use the same prefix as the rest of the traffic (may require more > complex ACLs, and leaks information to attackers) >=20 > The simplest method is to use the link-local addresses for the 6top > connection, and the cost of an IPIP tunnel between the unconstrained > 6LBR and the JCE is not considered significant. >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Nov 12 12:15:49 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 3727C1AD1FE; Wed, 12 Nov 2014 12:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WYGB16u4om-h; Wed, 12 Nov 2014 12:15:35 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51B81A876A; Wed, 12 Nov 2014 12:12:44 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sACKCheI000376; Thu, 13 Nov 2014 05:12:43 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sACKChTl017953; Thu, 13 Nov 2014 05:12:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id FAA17952; Thu, 13 Nov 2014 05:12:43 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sACKCgc4020291; Thu, 13 Nov 2014 05:12:42 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sACKCg2H019627; Thu, 13 Nov 2014 05:12:42 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 05:12:42 +0900 From: To: , <6tisch-security@ietf.org>, <6tisch@ietf.org> Thread-Topic: [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/pjUF5yubzDvQEKSk7dYvzx485xdYHQQ Date: Wed, 12 Nov 2014 20:12:41 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> In-Reply-To: <20507.1415811045@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.124] 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/oZqs9QWRps8u1VID8oF3D-xEtWY Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 20:15:46 -0000 Michael and all, I am still in the middle of understanding how loose source routes for joini= ng nodes that have only link-local address can work. Another option that i= s not mentioned in the text below is relaying authentication at join assist= ant node. The authentication relay model is proven to work in ZigBee IP. I have a reservation on JCE-initiated TLS session as opposed to what existi= ng 802.1X/PANA with EAP-TLS do where TLS session is initiated by joining no= de. An obvious downside of JCE-initiated TLS session is that it is difficu= lt to use AAA infrastructure. Beacon security issue should be investigated more. Integrity protecting be= acons with a well-known key can allow attackers to easily launch a DoS atta= ck on already connected nodes by advertising forged ASN as attackers know t= he well-known key. Shouldn't network-specific dynamic key also be needed f= or protecting beacons for already-connected nodes? Regards, Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Thursday, November 13, 2014 1:51 AM To: 6tisch-security@ietf.org; 6tisch@ietf.org Subject: [6tisch-security] proposed security text for architecture draft This text is the architecture results of the secure (zero-touch) design tea= m. The realization that we should use loose source routes is due to Pascal. I believe this goes into a new section between 10. Centralized vs. and 11. IANA Considerations. Interspersed is some text that I think goes i= n to section 12. Security Considerations.=20 If you are interested in the history of this text, or some additional more = implementation side ideas, then I recommend reviewing the diff http://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security-6= top-03&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--sec= urity-6top-04 10B. Architectural requirements of join protocol 10B.1. Entities involves in the join process The following actors are involved: there is a new joining node. It is (radio) adjacent to the join assistant. The join assistant is part of the production network, and participates in one or more DODAGs, such that it is reachable from the 6LBR, and the JCE. 10B.2. Join Protocol deliverables This section works from the ultimate goal, and goes backwards to prerequisite actions. (Section 6 presents the protocol from beginning to end order) The ultimate goal of the join protocol is to provide a new node with a locally significant security credentials that it is able to take part in the network directly. The credentials may vary by deployment. They can be one of: 1) a network-wide shared symmetric key (this is the production network key, or MasterKey) 2) a locally significant (one-level only) 802.11AR type LDevID certificate (which allows it to negotiate a pair-wise keys) One of these two items is delivered by JCE to the joining node using the 6top protocol. That is, the JCE provisions using a secure "northbound" interface. The authentication of this interface the subject of the Join Protocol as explained below. The above credential are used for authentication to generate per-peer L2, using a key exchange protocol. The choice of key exchange protocol, and what kind of link and multicast keying needs to be done is also provisioned by the JCE. There are a number of options for doing this, such as: 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] (IMPORTANT, a good option. Uses certificates from common CA) 2) work in 802.15.9 (uses certificates from common CA) 3) Security Framework and Key Management Protocol Requirements for 6TiSCH [I-D.ohba-6tisch-security] (this document provides the phase 0 required, using the network-wide shared key) 4) Layer-2 security aspects for the IEEE 802.15.4e MAC [I-D.piro-6tisch-security-issues]: the MasterKey is used to derive per-peer L2 keys Per-peer L2 keying is critical when doing peer-2-peer schedule negotiation over 15.4 Information Elements. Therefore a network-wide layer-2 key is inappropriate for the self-organizing networks, and a protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. For networks where there is a PCE present and it will do all schedule computation, then the only trust relationship necessary is between the individual node and the PCE, and it MAY be acceptable to have a network-wide L2 key derived in ways such as [I-D.piro-6tisch-security-issues] describes in section ?. The trust relationship between the PCE and the joining node flows from the LDevID certificate loaded by the JCE. When the PCE and JCE are co- located, the existing 6top/DTLS security association could be reused. 10B.3. Join Protocol connection setup The intermediate level goal of the join protocol is to enable a Join Coordination Entity (JCE) to reach out to the new node, and install the credentials detailed above. The JCE must authenticate itself to the joining node so that the joining node will know that it has joined the correct network, and the joining node must authenticate itself to the JCE so that the JCE will know that this node belongs in the network. This two way authentication occurs in the 6top/CoAP/ DTLS session that is established between the JCE and the joining node. [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] explains how to access that information model using CoAP. This information model will include security attributes for the network. The JCE would therefore reach out to the joining node and simply provision appropriate security properties into the joining node, much like the PCE will provision schedules. This 6top-based secure join protocol has defined a push model for security provisioning by the JCE. This has been done for three reasons: 1) 6tisch nodes already have to have a 6top CoAP server for schedule provising 2) this permits the JCE to manage how many nodes are trying to join at the same time, and limit how much bandwidth/energy is used for the join operation, and also for the JCE to prioritize the join order for nodes. 3) making the JCE initiate the DTLS connection significantly simplies the certificate chains that must be exchanged as the most constrained side (the joining node) provides it's credentials first, and lets the less constrained JCE figure out what kind of certificate chain will be required to authenticate the JCE to the joining node. In EAP-TLS/802.1x situations, the TLS channel is created in the opposite direction, and it would have to complete in a tentative way, and then further authorization occur in-band. 10B.4. End to End considerations for Join Protocol In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node, there needs to be end-to-end IPv6 connectivity between those two entities. The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node. The joining node sends traffic to the join assistant, which forwards it using the normal RPL DODAG upwards routes, and which will reach the JCE using regular routing. The challenge is getting connectivity from the JCE to the joining node, as the DODAG will have no information about this node. Instead, the JCE will use loose-source routes to address packets first to the Join Assistant, which will then forward to the joining node. This has an interaction with the (strict) source routes used by non-storing DODAGs which would be used by the 6LBR to reach the Join Assistant. There are some alternatives to having full end to end connectivity which are discussed in the security considerations section. 12.1. Security Considerations: alternatives to source routes This goes into security-considerations section A number of alternatives were considered for creating end to end connectivity between the joining node and the JCE, but were rejected. (1) IPIP tunnel between Join Assistant and JCE (2) using straight RPL routing: the Join Assistant sends a DAO (3) using a separate RPL DODAG for join traffic (4) establishing a specific multi-hop 6tisch track for join traffic for each Join Assistant 12.1.1.1. IPIP tunnel This mechanism requires 40 bytes overhead per packet, and may require specific state to be created on the Join Assistant, or may open the network up to a resource exhaustion by malicious join nodes. This mechanism was rejected on due to byte count, because it would require code only needed for join, and because doing it securely may require a per-tunnel state to be maintained on the join assistant. 12.1.1.2. join existing DODAG This mechanism is to just have the new node join the DODAG as a leaf node. The join assistant would issue a DAO for the new node. If a storing DODAG was used, this would directly cost state in all parent nodes of the Join Assistant, subjecting the lower-rank parts of the network to significant denial of service attacks. On a non-storing DODAG the situation is significantly better: no state is created by the presence of the leaf node except in the 6LBR, where available resources may be higher. This mechanism was rejected in favour of the loose source routed option as this the loose source routed option always works even for storing DODAGs, and is otherwise exactly equivalent in terms of network bandwidth cost. 12.1.1.3. join a DODOAG for joining One option to deal with the problem of resource consumption in the storing DODAG case is to use a second DODAG. This mechanism was rejected as it consumes resources in all nodes for the second DODAG, and many implementations support on a single DODAG. While storing DODAGs have a lighter network impact than non-storing ones (due to the lack of source routes), the PCE can control how much network bandwidth can be wasted by malicious join nodes using the regular 6tisch mechanisms, and this can be tuned. A second DODAG would be a sunk cost with no tuning possible. 12.1.1.4. create 6tisch track to form mesh-under This mechanism would use 6tisch tracks so that traffic from the JCE would be switched from 6LBR to join node. A track would be required to each join assistant. This is an optimized form of source routing. This mechanism was not rejected, rather it was observed that it may be applied to any mechanism that uses source routing, and is an optimization; it has a certain cost in the form of intermediary node state, but that this state is not created by a malicious join node, rather it is created by the PCE. 10B.5. Join node discovery mechanism Continuing to work backwards, in order the JCE reach out to provision the Joining Node, it needs to know that the new node is present. This is done by taking advantage of the 6lowPAN Address Resolution Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address to also be sent up to the 6LBR for duplicate detection using the DAR/ DAC mechanism. The 6LBR simply needs to tell the JCE about this. A new protocol may be required for the situation where the JCE, PCE and 6LBR are not co-located; it may be that this protocol could be simply a DAR in some encapsulation. The details of this are currently out of scope for the architecture, as they affect interoperability between different vendors of JCE/6LBR/PCE rather than interoperability between the assistance/offload infrastructure, and the contrained nodes. Future work may specify this part. In addition to needing to know the joining devices address from the DAR/NS, the JCE also needs to know the joining node's IDevID. This is to determine if the node should even get any attention. At this point, the IDevID can be forged, it will be authenticated during the setup of the 6top control protocol in the DTLS certificate exchange. If the serialNumber attribute of the IDevID is less than 64 bits, then it is possible that it could be placed into the EUI-64 option of the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] EARO. The JCE needs to know the joining node's serialNumber to know if this is device that it should even attempt to provision; and if so, it may need to retrieve an appropriate certificate chain (see [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for the JCE to prove it is the legitimate owner of the joining node. Neither 802.1AR nor [RFC5280] provide any structure for the serialNumber, except that they are positive integers of up-to 20 octets in size (numbers up to 2^160). This specification would require that the serialNumber encoded in the IDevID be the same as the EUI-64 used by the device. Some consideration needs to be given as to whether there are privacy considerations to doing this: any observer that can see the join traffic, can also see the source MAC address of the node as well. Prior to being able to announce itself in a NS, the joining node needs to find the Join Network. This is done by listening to an extended beacon which are broadcast in designated slotframes by Join Assistants. The Extended Beacon provides a way for the Joining Node to synchronize itself to the overall timeslot schedule and provides an Aloha period in which the Joining Node can send a Router Soliticiation, and receive an appropriate Router Advertisement giving the Joining Node a prefix and default route to which to send join traffic. It may be possible to eliminate a message exchange if space for a Router Advertisement can be found as part of the Join Network Extended Beacon. This Enhanced Beacon would be distinct to the Join Network, and would be encrypted with the well-known Join Network key. 10B.5.1. prefixes to use for join traffic What prefix would the joining node for communication? There are three options: (1) just use link-local addresses (this may require that some traffic between 6LBR and JCE be IPIP tunneled) (2) use a prefix specifically for join traffic (may be easier with a join-only DODAG) (3) use the same prefix as the rest of the traffic (may require more complex ACLs, and leaks information to attackers) The simplest method is to use the link-local addresses for the 6top connection, and the cost of an IPIP tunnel between the unconstrained 6LBR and the JCE is not considered significant. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed Nov 12 12:17: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 1E9361A871A; Wed, 12 Nov 2014 12:17:11 -0800 (PST) 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 hqhYozCGLzLH; Wed, 12 Nov 2014 12:16:59 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3E11AD02E; Wed, 12 Nov 2014 12:14:57 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fa1so13671317pad.11 for ; Wed, 12 Nov 2014 12:14:56 -0800 (PST) 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:content-transfer-encoding; bh=ZsBiaS22ahLtjVMJZGt1AXYwIManeVd1OxxoGqCwuA8=; b=Ov4va6qRh9wyYSQAYweVoEH91D6tgEsYDBzB1cqaPHW460RayE+duAKCufDDWCLvy8 7vBZ9b6rJcK6A7CUWPjSjAI90LHnKRO+ytn252ZzJNrQdTEQD4gBz9nN0wNfyWPreX+M ZmCQMjreQX/WWssP8h25fi1n6yIeUFBzdAQNk2wGF5/j4MzE50MBHyL7hkklgZzqLNKs 2O+f5Yhf3WOOFWQNV45zacEFzr9WPwAgLAg5/TZX9eLNXYge3+ZFRjct+ysZpIL5ycc1 HC95KTR2kOYjxJbVi6yG1Q5yTqCIjdS1ZJkT6ru0ncyDF9xhI6WzRsepnDrtkD3becqj 6SIw== X-Received: by 10.70.31.2 with SMTP id w2mr22202811pdh.128.1415823296776; Wed, 12 Nov 2014 12:14:56 -0800 (PST) Received: from [192.168.51.4] ([108.174.46.22]) by mx.google.com with ESMTPSA id lm3sm23051293pab.34.2014.11.12.12.14.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 12:14:56 -0800 (PST) Message-ID: <5463BFBC.2010501@gmail.com> Date: Wed, 12 Nov 2014 15:14:52 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> References: <20507.1415811045@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/mzwz2-lsR_Oaw5d4IgYzRiUcAoI Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 20:17:11 -0000 Hi Pascal: Correction: I don't think I ever suggested the use of well-known keys (as you seemed to suggest below): (ab)using crypto with a well-known keys is a way (promoted by some, not by me) to make the mechanics of a protocol work (in terms of I/O parameters), but does not accomplish any of the semantics (in terms of delivered security properties: confidentiality, authenticity, and so on). In fact, it may cause lots of security problems, e.g., in the context of 802.15.4e, since it would allow poisoning frame counters (the ASN entry in the MAC PIB table). BTW - the text blurb (proposed security text) presumably comes from a "secure zero touch design team" effort. To my knowledge, such a design team has never been put in place. So, I am extremely puzzled here. Let us discuss during the 6TiSCH meeting tomorrow. Best regards, Rene On 11/12/2014 1:37 PM, Pascal Thubert (pthubert) wrote: > Hello Michael: > > For the initial connection to the join assistant, we said that we'd use a well-known key by default, following René's initial recommendation. At some point of time, we also discussed the possibility to override that key by configuration to allow to differentiate networks, making that key effectively a sort of ssid. > > I do not see any of this reflected below. Do I miss anything, else would you agree that we add that stuff? > > Cheers, > > Pascal > > >> -----Original Message----- >> From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of >> Michael Richardson >> Sent: mercredi 12 novembre 2014 08:51 >> To: 6tisch-security@ietf.org; 6tisch@ietf.org >> Subject: [6tisch-security] proposed security text for architecture draft >> >> >> This text is the architecture results of the secure (zero-touch) design team. >> The realization that we should use loose source routes is due to Pascal. >> >> I believe this goes into a new section between 10. Centralized vs. >> and 11. IANA Considerations. Interspersed is some text that I think goes in to >> section 12. Security Considerations. >> >> If you are interested in the history of this text, or some additional more >> implementation side ideas, then I recommend reviewing the diff >> http://www.ietf.org/rfcdiff?url1=draft-richardson-6tisch--security-6top- >> 03&difftype=--html&submit=Go%21&url2=draft-richardson-6tisch--security- >> 6top-04 >> >> >> 10B. Architectural requirements of join protocol >> >> 10B.1. Entities involves in the join process >> >> The following actors are involved: there is a new joining node. It >> is (radio) adjacent to the join assistant. The join assistant is >> part of the production network, and participates in one or more >> DODAGs, such that it is reachable from the 6LBR, and the JCE. >> >> 10B.2. Join Protocol deliverables >> >> This section works from the ultimate goal, and goes backwards to >> prerequisite actions. (Section 6 presents the protocol from >> beginning to end order) >> >> The ultimate goal of the join protocol is to provide a new node with >> a locally significant security credentials that it is able to take >> part in the network directly. The credentials may vary by >> deployment. They can be one of: >> >> >> 1) a network-wide shared symmetric key (this is the production >> network key, or MasterKey) >> >> 2) a locally significant (one-level only) 802.11AR type LDevID >> certificate (which allows it to negotiate a pair-wise keys) >> >> One of these two items is delivered by JCE to the joining node using >> the 6top protocol. That is, the JCE provisions using a secure >> "northbound" interface. The authentication of this interface the >> subject of the Join Protocol as explained below. >> >> The above credential are used for authentication to generate per-peer >> L2, using a key exchange protocol. The choice of key exchange >> protocol, and what kind of link and multicast keying needs to be done >> is also provisioned by the JCE. There are a number of options for >> doing this, such as: >> >> 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] >> (IMPORTANT, a good option. Uses certificates from common CA) >> >> 2) work in 802.15.9 (uses certificates from common CA) >> >> 3) Security Framework and Key Management Protocol Requirements for >> 6TiSCH [I-D.ohba-6tisch-security] (this document provides the >> phase 0 required, using the network-wide shared key) >> >> 4) Layer-2 security aspects for the IEEE 802.15.4e MAC >> [I-D.piro-6tisch-security-issues]: the MasterKey is used to >> derive per-peer L2 keys >> >> Per-peer L2 keying is critical when doing peer-2-peer schedule >> negotiation over 15.4 Information Elements. Therefore a network-wide >> layer-2 key is inappropriate for the self-organizing networks, and a >> protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. >> >> For networks where there is a PCE present and it will do all schedule >> computation, then the only trust relationship necessary is between >> the individual node and the PCE, and it MAY be acceptable to have a >> network-wide L2 key derived in ways such as >> [I-D.piro-6tisch-security-issues] describes in section ?. The trust >> relationship between the PCE and the joining node flows from the >> LDevID certificate loaded by the JCE. When the PCE and JCE are co- >> located, the existing 6top/DTLS security association could be reused. >> >> 10B.3. Join Protocol connection setup >> >> The intermediate level goal of the join protocol is to enable a Join >> Coordination Entity (JCE) to reach out to the new node, and install >> the credentials detailed above. The JCE must authenticate itself to >> the joining node so that the joining node will know that it has >> joined the correct network, and the joining node must authenticate >> itself to the JCE so that the JCE will know that this node belongs in >> the network. This two way authentication occurs in the 6top/CoAP/ >> DTLS session that is established between the JCE and the joining >> node. >> >> [I-D.ietf-6tisch-6top-interface] presents a way to interface to a >> 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] >> explains how to access that information model using CoAP. This >> information model will include security attributes for the network. >> The JCE would therefore reach out to the joining node and simply >> provision appropriate security properties into the joining node, much >> like the PCE will provision schedules. >> >> This 6top-based secure join protocol has defined a push model for >> security provisioning by the JCE. This has been done for three >> reasons: >> >> 1) 6tisch nodes already have to have a 6top CoAP server for schedule >> provising >> >> 2) this permits the JCE to manage how many nodes are trying to join >> at the same time, and limit how much bandwidth/energy is used for >> the join operation, and also for the JCE to prioritize the join >> order for nodes. >> >> 3) making the JCE initiate the DTLS connection significantly >> simplies the certificate chains that must be exchanged as the >> most constrained side (the joining node) provides it's >> credentials first, and lets the less constrained JCE figure out >> what kind of certificate chain will be required to authenticate >> the JCE to the joining node. In EAP-TLS/802.1x situations, the >> TLS channel is created in the opposite direction, and it would >> have to complete in a tentative way, and then further >> authorization occur in-band. >> >> 10B.4. End to End considerations for Join Protocol >> >> In order for a 6top/DTLS/CoAP connection to occur between the JCE and >> the joining node, there needs to be end-to-end IPv6 connectivity >> between those two entities. The joining node will not participate in >> the route-over RPL mesh, but rather will be seen by the network as >> being a 6lowpan only leaf-node. >> >> The joining node sends traffic to the join assistant, which forwards >> it using the normal RPL DODAG upwards routes, and which will reach >> the JCE using regular routing. >> >> The challenge is getting connectivity from the JCE to the joining >> node, as the DODAG will have no information about this node. >> Instead, the JCE will use loose-source routes to address packets >> first to the Join Assistant, which will then forward to the joining >> node. This has an interaction with the (strict) source routes used >> by non-storing DODAGs which would be used by the 6LBR to reach the >> Join Assistant. >> >> There are some alternatives to having full end to end connectivity >> which are discussed in the security considerations section. >> >> 12.1. Security Considerations: alternatives to source routes >> >> This goes into security-considerations section >> >> A number of alternatives were considered for creating end to end >> connectivity between the joining node and the JCE, but were rejected. >> >> (1) IPIP tunnel between Join Assistant and JCE >> >> (2) using straight RPL routing: the Join Assistant sends a DAO >> >> (3) using a separate RPL DODAG for join traffic >> >> (4) establishing a specific multi-hop 6tisch track for join traffic >> for each Join Assistant >> >> 12.1.1.1. IPIP tunnel >> >> This mechanism requires 40 bytes overhead per packet, and may require >> specific state to be created on the Join Assistant, or may open the >> network up to a resource exhaustion by malicious join nodes. >> >> This mechanism was rejected on due to byte count, because it would >> require code only needed for join, and because doing it securely may >> require a per-tunnel state to be maintained on the join assistant. >> >> 12.1.1.2. join existing DODAG >> >> This mechanism is to just have the new node join the DODAG as a leaf >> node. The join assistant would issue a DAO for the new node. If a >> storing DODAG was used, this would directly cost state in all parent >> nodes of the Join Assistant, subjecting the lower-rank parts of the >> network to significant denial of service attacks. >> >> On a non-storing DODAG the situation is significantly better: no >> state is created by the presence of the leaf node except in the 6LBR, >> where available resources may be higher. >> >> This mechanism was rejected in favour of the loose source routed >> option as this the loose source routed option always works even for >> storing DODAGs, and is otherwise exactly equivalent in terms of >> network bandwidth cost. >> >> 12.1.1.3. join a DODOAG for joining >> >> One option to deal with the problem of resource consumption in the >> storing DODAG case is to use a second DODAG. >> >> This mechanism was rejected as it consumes resources in all nodes for >> the second DODAG, and many implementations support on a single DODAG. >> While storing DODAGs have a lighter network impact than non-storing >> ones (due to the lack of source routes), the PCE can control how much >> network bandwidth can be wasted by malicious join nodes using the >> regular 6tisch mechanisms, and this can be tuned. A second DODAG >> would be a sunk cost with no tuning possible. >> >> 12.1.1.4. create 6tisch track to form mesh-under >> >> This mechanism would use 6tisch tracks so that traffic from the JCE >> would be switched from 6LBR to join node. A track would be required >> to each join assistant. This is an optimized form of source routing. >> >> This mechanism was not rejected, rather it was observed that it may >> be applied to any mechanism that uses source routing, and is an >> optimization; it has a certain cost in the form of intermediary node >> state, but that this state is not created by a malicious join node, >> rather it is created by the PCE. >> >> 10B.5. Join node discovery mechanism >> >> Continuing to work backwards, in order the JCE reach out to provision >> the Joining Node, it needs to know that the new node is present. >> This is done by taking advantage of the 6lowPAN Address Resolution >> Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address >> to also be sent up to the 6LBR for duplicate detection using the DAR/ >> DAC mechanism. The 6LBR simply needs to tell the JCE about this. A >> new protocol may be required for the situation where the JCE, PCE and >> 6LBR are not co-located; it may be that this protocol could be simply >> a DAR in some encapsulation. The details of this are currently out >> of scope for the architecture, as they affect interoperability >> between different vendors of JCE/6LBR/PCE rather than >> interoperability between the assistance/offload infrastructure, and >> the contrained nodes. Future work may specify this part. >> >> In addition to needing to know the joining devices address from the >> DAR/NS, the JCE also needs to know the joining node's IDevID. This >> is to determine if the node should even get any attention. At this >> point, the IDevID can be forged, it will be authenticated during the >> setup of the 6top control protocol in the DTLS certificate exchange. >> If the serialNumber attribute of the IDevID is less than 64 bits, >> then it is possible that it could be placed into the EUI-64 option of >> the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] >> EARO. The JCE needs to know the joining node's serialNumber to know >> if this is device that it should even attempt to provision; and if >> so, it may need to retrieve an appropriate certificate chain (see >> [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for >> the JCE to prove it is the legitimate owner of the joining node. >> >> Neither 802.1AR nor [RFC5280] provide any structure for the >> serialNumber, except that they are positive integers of up-to 20 >> octets in size (numbers up to 2^160). This specification would >> require that the serialNumber encoded in the IDevID be the same as >> the EUI-64 used by the device. Some consideration needs to be given >> as to whether there are privacy considerations to doing this: any >> observer that can see the join traffic, can also see the source MAC >> address of the node as well. >> >> Prior to being able to announce itself in a NS, the joining node >> needs to find the Join Network. This is done by listening to an >> extended beacon which are broadcast in designated slotframes by Join >> Assistants. The Extended Beacon provides a way for the Joining Node >> to synchronize itself to the overall timeslot schedule and provides >> an Aloha period in which the Joining Node can send a Router >> Soliticiation, and receive an appropriate Router Advertisement giving >> the Joining Node a prefix and default route to which to send join >> traffic. >> >> It may be possible to eliminate a message exchange if space for a >> Router Advertisement can be found as part of the Join Network >> Extended Beacon. This Enhanced Beacon would be distinct to the Join >> Network, and would be encrypted with the well-known Join Network key. >> >> 10B.5.1. prefixes to use for join traffic >> >> What prefix would the joining node for communication? There are >> three options: >> >> (1) just use link-local addresses (this may require that some >> traffic between 6LBR and JCE be IPIP tunneled) >> >> (2) use a prefix specifically for join traffic (may be easier with a >> join-only DODAG) >> >> (3) use the same prefix as the rest of the traffic (may require more >> complex ACLs, and leaks information to attackers) >> >> The simplest method is to use the link-local addresses for the 6top >> connection, and the cost of an IPIP tunnel between the unconstrained >> 6LBR and the JCE is not considered significant. >> >> >> >> -- >> Michael Richardson , Sandelman Software Works -= >> IPv6 IoT consulting =- >> >> > _______________________________________________ > 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 From nobody Wed Nov 12 12:53:16 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 DC4D51A88B0; Wed, 12 Nov 2014 12:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 3FF8YmvS8E-s; Wed, 12 Nov 2014 12:53:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1871A870C; Wed, 12 Nov 2014 12:53:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B78E2016A; Wed, 12 Nov 2014 15:55:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8E5D4637F4; Wed, 12 Nov 2014 15:53:09 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 771C0637F2; Wed, 12 Nov 2014 15:53:09 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: <20507.1415811045@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/7gv4GM3iEPo4DagrPs3eWX8UMB0 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 20:53:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > For the initial connection to the join assistant, we said that we'd u= se > a well-known key by default, following Ren=C3=A9's initial > recommendation. At some point of time, we also discussed the > possibility to override that key by configuration to allow to > differentiate networks, making that key effectively a sort of ssid. I'll fix the text to include these points, which I agree that we said. =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) iQEVAwUBVGPIsoCLcPvd0N1lAQKBAQf/ab2tGBvOd59bDyNpTvwej1N91sFB13Ki opCrpU6FY5ST3Ey/43RRaaF9D0KRN+Asbd4FPV5ZrFd/nc3bii94212i3J3uRd9B 0EBGE7Dqesf0pTcxi4k1gAWP2yjd2HT8Zt4WMOPezrSis8Pa2N25zAh9bSRCawBW +DVYJXFU7iv7uLR/eMSMFoiPep6Dym4Iczp5m6Lp4CD8cmBG1WanK6KSYBTKmXZU qGeiZ4XbXAIRXFmI85Zitvq2C63qpbKsJVVe8AWEgDoKM4Qf8F9kqY9fifQCQQbB h82ARhvb+hCRalXpauBhwrxxPCwyGOJEzOz5ABaYn3c+meWS8/Yg4w== =8/u6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 12 13:11: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 E0B4A1A9125; Wed, 12 Nov 2014 13:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 VE6oeeySdMVa; Wed, 12 Nov 2014 13:11:10 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B37E1AD272; Wed, 12 Nov 2014 13:11:06 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so14391630ieb.22 for ; Wed, 12 Nov 2014 13:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/DYmAem+e9reWTjTQFTk4QGm0RoNDgf68SMQRZg7FyI=; b=ZTr3FDeVo3cQCcE+nSNtnoudnCXNnyTS9AbJHC8x+LBxICaIv0RS7nYC01VpuGlpO5 T0IUUIt/x7KJKND/4VxAqpiX99JRee5fBTVHTUjJy2cQRyyIXK21ivJPKaMo6vgzP7du a4iAf6qF9PyYhcum7886B0ihdMCx7Ve1iLuxfP2Httv3D+N7w8Clyw6Ew6M4BR9ytVl3 +8c7ycZTcIJxr2EZn0v/1k2lhf5Gbf8Gq+qUH8PqINUv/FcuvCASRvgmfrYsv1RXAeW+ hqrqkzcuO7zEKdIxlu35mGHZ9OtcHXwHaOrcgg8G/jgHyyP6HLfrt5m6OilhOSzIJz4m qaAQ== MIME-Version: 1.0 X-Received: by 10.42.129.140 with SMTP id q12mr1105186ics.68.1415826665779; Wed, 12 Nov 2014 13:11:05 -0800 (PST) Received: by 10.42.246.136 with HTTP; Wed, 12 Nov 2014 13:11:05 -0800 (PST) In-Reply-To: <20507.1415811045@sandelman.ca> References: <20507.1415811045@sandelman.ca> Date: Wed, 12 Nov 2014 16:11:05 -0500 Message-ID: From: Subir Das To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf3011e0597a38980507afd5be Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/HAfWYK4jBTd9Vi37zw18a-yZlKE Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 21:11:15 -0000 --20cf3011e0597a38980507afd5be Content-Type: text/plain; charset=UTF-8 Michael, Are you suggesting to add this entire text to the architecture document? I am afraid that the text is more than architecture elements and requirements? I was not able to attend the last Tuesday's call. You are claiming that the ad hoc security team recommended this text to the WG for consideration. Is this happened during last call? I understand that you didn't get time yet to publish the minutes. -Subir On Wed, Nov 12, 2014 at 11:50 AM, Michael Richardson wrote: > > This text is the architecture results of the secure (zero-touch) design > team. > The realization that we should use loose source routes is due to Pascal. > > I believe this goes into a new section between 10. Centralized vs. > and 11. IANA Considerations. Interspersed is some text that I think goes > in to section > 12. Security Considerations. > > If you are interested in the history of this text, or some additional more > implementation > side ideas, then I recommend reviewing the diff > > http://www.ietf.org/rfcdiff?url1=draft-richardson-6tisch--security-6top-03&difftype=--html&submit=Go%21&url2=draft-richardson-6tisch--security-6top-04 > > > 10B. Architectural requirements of join protocol > > 10B.1. Entities involves in the join process > > The following actors are involved: there is a new joining node. It > is (radio) adjacent to the join assistant. The join assistant is > part of the production network, and participates in one or more > DODAGs, such that it is reachable from the 6LBR, and the JCE. > > 10B.2. Join Protocol deliverables > > This section works from the ultimate goal, and goes backwards to > prerequisite actions. (Section 6 presents the protocol from > beginning to end order) > > The ultimate goal of the join protocol is to provide a new node with > a locally significant security credentials that it is able to take > part in the network directly. The credentials may vary by > deployment. They can be one of: > > > 1) a network-wide shared symmetric key (this is the production > network key, or MasterKey) > > 2) a locally significant (one-level only) 802.11AR type LDevID > certificate (which allows it to negotiate a pair-wise keys) > > One of these two items is delivered by JCE to the joining node using > the 6top protocol. That is, the JCE provisions using a secure > "northbound" interface. The authentication of this interface the > subject of the Join Protocol as explained below. > > The above credential are used for authentication to generate per-peer > L2, using a key exchange protocol. The choice of key exchange > protocol, and what kind of link and multicast keying needs to be done > is also provisioned by the JCE. There are a number of options for > doing this, such as: > > 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] > (IMPORTANT, a good option. Uses certificates from common CA) > > 2) work in 802.15.9 (uses certificates from common CA) > > 3) Security Framework and Key Management Protocol Requirements for > 6TiSCH [I-D.ohba-6tisch-security] (this document provides the > phase 0 required, using the network-wide shared key) > > 4) Layer-2 security aspects for the IEEE 802.15.4e MAC > [I-D.piro-6tisch-security-issues]: the MasterKey is used to > derive per-peer L2 keys > > Per-peer L2 keying is critical when doing peer-2-peer schedule > negotiation over 15.4 Information Elements. Therefore a network-wide > layer-2 key is inappropriate for the self-organizing networks, and a > protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. > > For networks where there is a PCE present and it will do all schedule > computation, then the only trust relationship necessary is between > the individual node and the PCE, and it MAY be acceptable to have a > network-wide L2 key derived in ways such as > [I-D.piro-6tisch-security-issues] describes in section ?. The trust > relationship between the PCE and the joining node flows from the > LDevID certificate loaded by the JCE. When the PCE and JCE are co- > located, the existing 6top/DTLS security association could be reused. > > 10B.3. Join Protocol connection setup > > The intermediate level goal of the join protocol is to enable a Join > Coordination Entity (JCE) to reach out to the new node, and install > the credentials detailed above. The JCE must authenticate itself to > the joining node so that the joining node will know that it has > joined the correct network, and the joining node must authenticate > itself to the JCE so that the JCE will know that this node belongs in > the network. This two way authentication occurs in the 6top/CoAP/ > DTLS session that is established between the JCE and the joining > node. > > [I-D.ietf-6tisch-6top-interface] presents a way to interface to a > 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] > explains how to access that information model using CoAP. This > information model will include security attributes for the network. > The JCE would therefore reach out to the joining node and simply > provision appropriate security properties into the joining node, much > like the PCE will provision schedules. > > This 6top-based secure join protocol has defined a push model for > security provisioning by the JCE. This has been done for three > reasons: > > 1) 6tisch nodes already have to have a 6top CoAP server for schedule > provising > > 2) this permits the JCE to manage how many nodes are trying to join > at the same time, and limit how much bandwidth/energy is used for > the join operation, and also for the JCE to prioritize the join > order for nodes. > > 3) making the JCE initiate the DTLS connection significantly > simplies the certificate chains that must be exchanged as the > most constrained side (the joining node) provides it's > credentials first, and lets the less constrained JCE figure out > what kind of certificate chain will be required to authenticate > the JCE to the joining node. In EAP-TLS/802.1x situations, the > TLS channel is created in the opposite direction, and it would > have to complete in a tentative way, and then further > authorization occur in-band. > > 10B.4. End to End considerations for Join Protocol > > In order for a 6top/DTLS/CoAP connection to occur between the JCE and > the joining node, there needs to be end-to-end IPv6 connectivity > between those two entities. The joining node will not participate in > the route-over RPL mesh, but rather will be seen by the network as > being a 6lowpan only leaf-node. > > The joining node sends traffic to the join assistant, which forwards > it using the normal RPL DODAG upwards routes, and which will reach > the JCE using regular routing. > > The challenge is getting connectivity from the JCE to the joining > node, as the DODAG will have no information about this node. > Instead, the JCE will use loose-source routes to address packets > first to the Join Assistant, which will then forward to the joining > node. This has an interaction with the (strict) source routes used > by non-storing DODAGs which would be used by the 6LBR to reach the > Join Assistant. > > There are some alternatives to having full end to end connectivity > which are discussed in the security considerations section. > > 12.1. Security Considerations: alternatives to source routes > > This goes into security-considerations section > > A number of alternatives were considered for creating end to end > connectivity between the joining node and the JCE, but were rejected. > > (1) IPIP tunnel between Join Assistant and JCE > > (2) using straight RPL routing: the Join Assistant sends a DAO > > (3) using a separate RPL DODAG for join traffic > > (4) establishing a specific multi-hop 6tisch track for join traffic > for each Join Assistant > > 12.1.1.1. IPIP tunnel > > This mechanism requires 40 bytes overhead per packet, and may require > specific state to be created on the Join Assistant, or may open the > network up to a resource exhaustion by malicious join nodes. > > This mechanism was rejected on due to byte count, because it would > require code only needed for join, and because doing it securely may > require a per-tunnel state to be maintained on the join assistant. > > 12.1.1.2. join existing DODAG > > This mechanism is to just have the new node join the DODAG as a leaf > node. The join assistant would issue a DAO for the new node. If a > storing DODAG was used, this would directly cost state in all parent > nodes of the Join Assistant, subjecting the lower-rank parts of the > network to significant denial of service attacks. > > On a non-storing DODAG the situation is significantly better: no > state is created by the presence of the leaf node except in the 6LBR, > where available resources may be higher. > > This mechanism was rejected in favour of the loose source routed > option as this the loose source routed option always works even for > storing DODAGs, and is otherwise exactly equivalent in terms of > network bandwidth cost. > > 12.1.1.3. join a DODOAG for joining > > One option to deal with the problem of resource consumption in the > storing DODAG case is to use a second DODAG. > > This mechanism was rejected as it consumes resources in all nodes for > the second DODAG, and many implementations support on a single DODAG. > While storing DODAGs have a lighter network impact than non-storing > ones (due to the lack of source routes), the PCE can control how much > network bandwidth can be wasted by malicious join nodes using the > regular 6tisch mechanisms, and this can be tuned. A second DODAG > would be a sunk cost with no tuning possible. > > 12.1.1.4. create 6tisch track to form mesh-under > > This mechanism would use 6tisch tracks so that traffic from the JCE > would be switched from 6LBR to join node. A track would be required > to each join assistant. This is an optimized form of source routing. > > This mechanism was not rejected, rather it was observed that it may > be applied to any mechanism that uses source routing, and is an > optimization; it has a certain cost in the form of intermediary node > state, but that this state is not created by a malicious join node, > rather it is created by the PCE. > > 10B.5. Join node discovery mechanism > > Continuing to work backwards, in order the JCE reach out to provision > the Joining Node, it needs to know that the new node is present. > This is done by taking advantage of the 6lowPAN Address Resolution > Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address > to also be sent up to the 6LBR for duplicate detection using the DAR/ > DAC mechanism. The 6LBR simply needs to tell the JCE about this. A > new protocol may be required for the situation where the JCE, PCE and > 6LBR are not co-located; it may be that this protocol could be simply > a DAR in some encapsulation. The details of this are currently out > of scope for the architecture, as they affect interoperability > between different vendors of JCE/6LBR/PCE rather than > interoperability between the assistance/offload infrastructure, and > the contrained nodes. Future work may specify this part. > > In addition to needing to know the joining devices address from the > DAR/NS, the JCE also needs to know the joining node's IDevID. This > is to determine if the node should even get any attention. At this > point, the IDevID can be forged, it will be authenticated during the > setup of the 6top control protocol in the DTLS certificate exchange. > If the serialNumber attribute of the IDevID is less than 64 bits, > then it is possible that it could be placed into the EUI-64 option of > the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] > EARO. The JCE needs to know the joining node's serialNumber to know > if this is device that it should even attempt to provision; and if > so, it may need to retrieve an appropriate certificate chain (see > [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for > the JCE to prove it is the legitimate owner of the joining node. > > Neither 802.1AR nor [RFC5280] provide any structure for the > serialNumber, except that they are positive integers of up-to 20 > octets in size (numbers up to 2^160). This specification would > require that the serialNumber encoded in the IDevID be the same as > the EUI-64 used by the device. Some consideration needs to be given > as to whether there are privacy considerations to doing this: any > observer that can see the join traffic, can also see the source MAC > address of the node as well. > > Prior to being able to announce itself in a NS, the joining node > needs to find the Join Network. This is done by listening to an > extended beacon which are broadcast in designated slotframes by Join > Assistants. The Extended Beacon provides a way for the Joining Node > to synchronize itself to the overall timeslot schedule and provides > an Aloha period in which the Joining Node can send a Router > Soliticiation, and receive an appropriate Router Advertisement giving > the Joining Node a prefix and default route to which to send join > traffic. > > It may be possible to eliminate a message exchange if space for a > Router Advertisement can be found as part of the Join Network > Extended Beacon. This Enhanced Beacon would be distinct to the Join > Network, and would be encrypted with the well-known Join Network key. > > 10B.5.1. prefixes to use for join traffic > > What prefix would the joining node for communication? There are > three options: > > (1) just use link-local addresses (this may require that some > traffic between 6LBR and JCE be IPIP tunneled) > > (2) use a prefix specifically for join traffic (may be easier with a > join-only DODAG) > > (3) use the same prefix as the rest of the traffic (may require more > complex ACLs, and leaks information to attackers) > > The simplest method is to use the link-local addresses for the 6top > connection, and the cost of an IPIP tunnel between the unconstrained > 6LBR and the JCE is not considered significant. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --20cf3011e0597a38980507afd5be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
Are you suggesting to add this entire te= xt to the architecture document?=C2=A0 I am afraid that the text is more th= an architecture elements and requirements?=C2=A0 I was not able to attend t= he last Tuesday's call. You are claiming that the ad hoc security team = recommended this text to the WG for consideration. Is this happened during = last call? I understand that you didn't get time yet to publish the=C2= =A0 minutes.

-Subir

<= div class=3D"gmail_quote">On Wed, Nov 12, 2014 at 11:50 AM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

This text is the architecture results of the secure (zero-touch) design tea= m.
The realization that we should use loose source routes is due to Pascal.
I believe this goes into a new section between 10. Centralized vs.
and 11. IANA Considerations.=C2=A0 Interspersed is some text that I think g= oes in to section
12. Security Considerations.

If you are interested in the history of this text, or some additional more = implementation
side ideas, then I recommend reviewing the diff
=C2=A0 =C2=A0 =C2=A0http= ://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security-6top-03&am= p;difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--= security-6top-04


10B.=C2=A0 Architectural requirements of join protocol

10B.1.=C2=A0 Entities involves in the join process

=C2=A0 =C2=A0The following actors are involved: there is a new joining node= .=C2=A0 It
=C2=A0 =C2=A0is (radio) adjacent to the join assistant.=C2=A0 The join assi= stant is
=C2=A0 =C2=A0part of the production network, and participates in one or mor= e
=C2=A0 =C2=A0DODAGs, such that it is reachable from the 6LBR, and the JCE.<= br>
10B.2.=C2=A0 Join Protocol deliverables

=C2=A0 =C2=A0This section works from the ultimate goal, and goes backwards = to
=C2=A0 =C2=A0prerequisite actions.=C2=A0 (Section 6 presents the protocol f= rom
=C2=A0 =C2=A0beginning to end order)

=C2=A0 =C2=A0The ultimate goal of the join protocol is to provide a new nod= e with
=C2=A0 =C2=A0a locally significant security credentials that it is able to = take
=C2=A0 =C2=A0part in the network directly.=C2=A0 The credentials may vary b= y
=C2=A0 =C2=A0deployment.=C2=A0 They can be one of:


=C2=A0 =C2=A01)=C2=A0 a network-wide shared symmetric key (this is the prod= uction
=C2=A0 =C2=A0 =C2=A0 =C2=A0network key, or MasterKey)

=C2=A0 =C2=A02)=C2=A0 a locally significant (one-level only) 802.11AR type = LDevID
=C2=A0 =C2=A0 =C2=A0 =C2=A0certificate (which allows it to negotiate a pair= -wise keys)

=C2=A0 =C2=A0One of these two items is delivered by JCE to the joining node= using
=C2=A0 =C2=A0the 6top protocol.=C2=A0 That is, the JCE provisions using a s= ecure
=C2=A0 =C2=A0"northbound" interface.=C2=A0 The authentication of = this interface the
=C2=A0 =C2=A0subject of the Join Protocol as explained below.

=C2=A0 =C2=A0The above credential are used for authentication to generate p= er-peer
=C2=A0 =C2=A0L2, using a key exchange protocol.=C2=A0 The choice of key exc= hange
=C2=A0 =C2=A0protocol, and what kind of link and multicast keying needs to = be done
=C2=A0 =C2=A0is also provisioned by the JCE.=C2=A0 There are a number of op= tions for
=C2=A0 =C2=A0doing this, such as:

=C2=A0 =C2=A01)=C2=A0 Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-esta= blishment]
=C2=A0 =C2=A0 =C2=A0 =C2=A0(IMPORTANT, a good option.=C2=A0 Uses certificat= es from common CA)

=C2=A0 =C2=A02)=C2=A0 work in 802.15.9 (uses certificates from common CA)
=C2=A0 =C2=A03)=C2=A0 Security Framework and Key Management Protocol Requir= ements for
=C2=A0 =C2=A0 =C2=A0 =C2=A06TiSCH [I-D.ohba-6tisch-security] (this document= provides the
=C2=A0 =C2=A0 =C2=A0 =C2=A0phase 0 required, using the network-wide shared = key)

=C2=A0 =C2=A04)=C2=A0 Layer-2 security aspects for the IEEE 802.15.4e MAC =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.piro-6tisch-security-issues]: the MasterKey= is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0derive per-peer L2 keys

=C2=A0 =C2=A0Per-peer L2 keying is critical when doing peer-2-peer schedule=
=C2=A0 =C2=A0negotiation over 15.4 Information Elements.=C2=A0 Therefore a = network-wide
=C2=A0 =C2=A0layer-2 key is inappropriate for the self-organizing networks,= and a
=C2=A0 =C2=A0protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 = keys.

=C2=A0 =C2=A0For networks where there is a PCE present and it will do all s= chedule
=C2=A0 =C2=A0computation, then the only trust relationship necessary is bet= ween
=C2=A0 =C2=A0the individual node and the PCE, and it MAY be acceptable to h= ave a
=C2=A0 =C2=A0network-wide L2 key derived in ways such as
=C2=A0 =C2=A0[I-D.piro-6tisch-security-issues] describes in section ?.=C2= =A0 The trust
=C2=A0 =C2=A0relationship between the PCE and the joining node flows from t= he
=C2=A0 =C2=A0LDevID certificate loaded by the JCE.=C2=A0 When the PCE and J= CE are co-
=C2=A0 =C2=A0located, the existing 6top/DTLS security association could be = reused.

10B.3.=C2=A0 Join Protocol connection setup

=C2=A0 =C2=A0The intermediate level goal of the join protocol is to enable = a Join
=C2=A0 =C2=A0Coordination Entity (JCE) to reach out to the new node, and in= stall
=C2=A0 =C2=A0the credentials detailed above.=C2=A0 The JCE must authenticat= e itself to
=C2=A0 =C2=A0the joining node so that the joining node will know that it ha= s
=C2=A0 =C2=A0joined the correct network, and the joining node must authenti= cate
=C2=A0 =C2=A0itself to the JCE so that the JCE will know that this node bel= ongs in
=C2=A0 =C2=A0the network.=C2=A0 This two way authentication occurs in the 6= top/CoAP/
=C2=A0 =C2=A0DTLS session that is established between the JCE and the joini= ng
=C2=A0 =C2=A0node.

=C2=A0 =C2=A0[I-D.ietf-6tisch-6top-interface] presents a way to interface t= o a
=C2=A0 =C2=A06top information model (defined in YANG).=C2=A0 [I-D.ietf-6tis= ch-coap]
=C2=A0 =C2=A0explains how to access that information model using CoAP.=C2= =A0 This
=C2=A0 =C2=A0information model will include security attributes for the net= work.
=C2=A0 =C2=A0The JCE would therefore reach out to the joining node and simp= ly
=C2=A0 =C2=A0provision appropriate security properties into the joining nod= e, much
=C2=A0 =C2=A0like the PCE will provision schedules.

=C2=A0 =C2=A0This 6top-based secure join protocol has defined a push model = for
=C2=A0 =C2=A0security provisioning by the JCE.=C2=A0 This has been done for= three
=C2=A0 =C2=A0reasons:

=C2=A0 =C2=A01)=C2=A0 6tisch nodes already have to have a 6top CoAP server = for schedule
=C2=A0 =C2=A0 =C2=A0 =C2=A0provising

=C2=A0 =C2=A02)=C2=A0 this permits the JCE to manage how many nodes are try= ing to join
=C2=A0 =C2=A0 =C2=A0 =C2=A0at the same time, and limit how much bandwidth/e= nergy is used for
=C2=A0 =C2=A0 =C2=A0 =C2=A0the join operation, and also for the JCE to prio= ritize the join
=C2=A0 =C2=A0 =C2=A0 =C2=A0order for nodes.

=C2=A0 =C2=A03)=C2=A0 making the JCE initiate the DTLS connection significa= ntly
=C2=A0 =C2=A0 =C2=A0 =C2=A0simplies the certificate chains that must be exc= hanged as the
=C2=A0 =C2=A0 =C2=A0 =C2=A0most constrained side (the joining node) provide= s it's
=C2=A0 =C2=A0 =C2=A0 =C2=A0credentials first, and lets the less constrained= JCE figure out
=C2=A0 =C2=A0 =C2=A0 =C2=A0what kind of certificate chain will be required = to authenticate
=C2=A0 =C2=A0 =C2=A0 =C2=A0the JCE to the joining node.=C2=A0 In EAP-TLS/80= 2.1x situations, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS channel is created in the opposite direction= , and it would
=C2=A0 =C2=A0 =C2=A0 =C2=A0have to complete in a tentative way, and then fu= rther
=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization occur in-band.

10B.4.=C2=A0 End to End considerations for Join Protocol

=C2=A0 =C2=A0In order for a 6top/DTLS/CoAP connection to occur between the = JCE and
=C2=A0 =C2=A0the joining node, there needs to be end-to-end IPv6 connectivi= ty
=C2=A0 =C2=A0between those two entities.=C2=A0 The joining node will not pa= rticipate in
=C2=A0 =C2=A0the route-over RPL mesh, but rather will be seen by the networ= k as
=C2=A0 =C2=A0being a 6lowpan only leaf-node.

=C2=A0 =C2=A0The joining node sends traffic to the join assistant, which fo= rwards
=C2=A0 =C2=A0it using the normal RPL DODAG upwards routes, and which will r= each
=C2=A0 =C2=A0the JCE using regular routing.

=C2=A0 =C2=A0The challenge is getting connectivity from the JCE to the join= ing
=C2=A0 =C2=A0node, as the DODAG will have no information about this node. =C2=A0 =C2=A0Instead, the JCE will use loose-source routes to address packe= ts
=C2=A0 =C2=A0first to the Join Assistant, which will then forward to the jo= ining
=C2=A0 =C2=A0node.=C2=A0 This has an interaction with the (strict) source r= outes used
=C2=A0 =C2=A0by non-storing DODAGs which would be used by the 6LBR to reach= the
=C2=A0 =C2=A0Join Assistant.

=C2=A0 =C2=A0There are some alternatives to having full end to end connecti= vity
=C2=A0 =C2=A0which are discussed in the security considerations section.
12.1.=C2=A0 Security Considerations: alternatives to source routes

=C2=A0 =C2=A0This goes into security-considerations section

=C2=A0 =C2=A0A number of alternatives were considered for creating end to e= nd
=C2=A0 =C2=A0connectivity between the joining node and the JCE, but were re= jected.

=C2=A0 =C2=A0(1)=C2=A0 IPIP tunnel between Join Assistant and JCE

=C2=A0 =C2=A0(2)=C2=A0 using straight RPL routing: the Join Assistant sends= a DAO

=C2=A0 =C2=A0(3)=C2=A0 using a separate RPL DODAG for join traffic

=C2=A0 =C2=A0(4)=C2=A0 establishing a specific multi-hop 6tisch track for j= oin traffic
=C2=A0 =C2=A0 =C2=A0 for each Join Assistant

12.1.1.1.=C2=A0 IPIP tunnel

=C2=A0 =C2=A0This mechanism requires 40 bytes overhead per packet, and may = require
=C2=A0 =C2=A0specific state to be created on the Join Assistant, or may ope= n the
=C2=A0 =C2=A0network up to a resource exhaustion by malicious join nodes.
=C2=A0 =C2=A0This mechanism was rejected on due to byte count, because it w= ould
=C2=A0 =C2=A0require code only needed for join, and because doing it secure= ly may
=C2=A0 =C2=A0require a per-tunnel state to be maintained on the join assist= ant.

12.1.1.2.=C2=A0 join existing DODAG

=C2=A0 =C2=A0This mechanism is to just have the new node join the DODAG as = a leaf
=C2=A0 =C2=A0node.=C2=A0 The join assistant would issue a DAO for the new n= ode.=C2=A0 If a
=C2=A0 =C2=A0storing DODAG was used, this would directly cost state in all = parent
=C2=A0 =C2=A0nodes of the Join Assistant, subjecting the lower-rank parts o= f the
=C2=A0 =C2=A0network to significant denial of service attacks.

=C2=A0 =C2=A0On a non-storing DODAG the situation is significantly better: = no
=C2=A0 =C2=A0state is created by the presence of the leaf node except in th= e 6LBR,
=C2=A0 =C2=A0where available resources may be higher.

=C2=A0 =C2=A0This mechanism was rejected in favour of the loose source rout= ed
=C2=A0 =C2=A0option as this the loose source routed option always works eve= n for
=C2=A0 =C2=A0storing DODAGs, and is otherwise exactly equivalent in terms o= f
=C2=A0 =C2=A0network bandwidth cost.

12.1.1.3.=C2=A0 join a DODOAG for joining

=C2=A0 =C2=A0One option to deal with the problem of resource consumption in= the
=C2=A0 =C2=A0storing DODAG case is to use a second DODAG.

=C2=A0 =C2=A0This mechanism was rejected as it consumes resources in all no= des for
=C2=A0 =C2=A0the second DODAG, and many implementations support on a single= DODAG.
=C2=A0 =C2=A0While storing DODAGs have a lighter network impact than non-st= oring
=C2=A0 =C2=A0ones (due to the lack of source routes), the PCE can control h= ow much
=C2=A0 =C2=A0network bandwidth can be wasted by malicious join nodes using = the
=C2=A0 =C2=A0regular 6tisch mechanisms, and this can be tuned.=C2=A0 A seco= nd DODAG
=C2=A0 =C2=A0would be a sunk cost with no tuning possible.

12.1.1.4.=C2=A0 create 6tisch track to form mesh-under

=C2=A0 =C2=A0This mechanism would use 6tisch tracks so that traffic from th= e JCE
=C2=A0 =C2=A0would be switched from 6LBR to join node.=C2=A0 A track would = be required
=C2=A0 =C2=A0to each join assistant.=C2=A0 This is an optimized form of sou= rce routing.

=C2=A0 =C2=A0This mechanism was not rejected, rather it was observed that i= t may
=C2=A0 =C2=A0be applied to any mechanism that uses source routing, and is a= n
=C2=A0 =C2=A0optimization; it has a certain cost in the form of intermediar= y node
=C2=A0 =C2=A0state, but that this state is not created by a malicious join = node,
=C2=A0 =C2=A0rather it is created by the PCE.

10B.5.=C2=A0 Join node discovery mechanism

=C2=A0 =C2=A0Continuing to work backwards, in order the JCE reach out to pr= ovision
=C2=A0 =C2=A0the Joining Node, it needs to know that the new node is presen= t.
=C2=A0 =C2=A0This is done by taking advantage of the 6lowPAN Address Resolu= tion
=C2=A0 =C2=A0Option (ARO) (section 4.1 [RFC6775]).=C2=A0 The ARO causes the= new address
=C2=A0 =C2=A0to also be sent up to the 6LBR for duplicate detection using t= he DAR/
=C2=A0 =C2=A0DAC mechanism.=C2=A0 The 6LBR simply needs to tell the JCE abo= ut this.=C2=A0 A
=C2=A0 =C2=A0new protocol may be required for the situation where the JCE, = PCE and
=C2=A0 =C2=A06LBR are not co-located; it may be that this protocol could be= simply
=C2=A0 =C2=A0a DAR in some encapsulation.=C2=A0 The details of this are cur= rently out
=C2=A0 =C2=A0of scope for the architecture, as they affect interoperability=
=C2=A0 =C2=A0between different vendors of JCE/6LBR/PCE rather than
=C2=A0 =C2=A0interoperability between the assistance/offload infrastructure= , and
=C2=A0 =C2=A0the contrained nodes.=C2=A0 Future work may specify this part.=

=C2=A0 =C2=A0In addition to needing to know the joining devices address fro= m the
=C2=A0 =C2=A0DAR/NS, the JCE also needs to know the joining node's IDev= ID.=C2=A0 This
=C2=A0 =C2=A0is to determine if the node should even get any attention.=C2= =A0 At this
=C2=A0 =C2=A0point, the IDevID can be forged, it will be authenticated duri= ng the
=C2=A0 =C2=A0setup of the 6top control protocol in the DTLS certificate exc= hange.
=C2=A0 =C2=A0If the serialNumber attribute of the IDevID is less than 64 bi= ts,
=C2=A0 =C2=A0then it is possible that it could be placed into the EUI-64 op= tion of
=C2=A0 =C2=A0the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-req= s]
=C2=A0 =C2=A0EARO.=C2=A0 The JCE needs to know the joining node's seria= lNumber to know
=C2=A0 =C2=A0if this is device that it should even attempt to provision; an= d if
=C2=A0 =C2=A0so, it may need to retrieve an appropriate certificate chain (= see
=C2=A0 =C2=A0[I-D.richardson-6tisch-idevid-cert]) from the Factory in order= for
=C2=A0 =C2=A0the JCE to prove it is the legitimate owner of the joining nod= e.

=C2=A0 =C2=A0Neither 802.1AR nor [RFC5280] provide any structure for the =C2=A0 =C2=A0serialNumber, except that they are positive integers of up-to = 20
=C2=A0 =C2=A0octets in size (numbers up to 2^160).=C2=A0 This specification= would
=C2=A0 =C2=A0require that the serialNumber encoded in the IDevID be the sam= e as
=C2=A0 =C2=A0the EUI-64 used by the device.=C2=A0 Some consideration needs = to be given
=C2=A0 =C2=A0as to whether there are privacy considerations to doing this: = any
=C2=A0 =C2=A0observer that can see the join traffic, can also see the sourc= e MAC
=C2=A0 =C2=A0address of the node as well.

=C2=A0 =C2=A0Prior to being able to announce itself in a NS, the joining no= de
=C2=A0 =C2=A0needs to find the Join Network.=C2=A0 This is done by listenin= g to an
=C2=A0 =C2=A0extended beacon which are broadcast in designated slotframes b= y Join
=C2=A0 =C2=A0Assistants.=C2=A0 The Extended Beacon provides a way for the J= oining Node
=C2=A0 =C2=A0to synchronize itself to the overall timeslot schedule and pro= vides
=C2=A0 =C2=A0an Aloha period in which the Joining Node can send a Router =C2=A0 =C2=A0Soliticiation, and receive an appropriate Router Advertisement= giving
=C2=A0 =C2=A0the Joining Node a prefix and default route to which to send j= oin
=C2=A0 =C2=A0traffic.

=C2=A0 =C2=A0It may be possible to eliminate a message exchange if space fo= r a
=C2=A0 =C2=A0Router Advertisement can be found as part of the Join Network<= br> =C2=A0 =C2=A0Extended Beacon.=C2=A0 This Enhanced Beacon would be distinct = to the Join
=C2=A0 =C2=A0Network, and would be encrypted with the well-known Join Netwo= rk key.

10B.5.1.=C2=A0 prefixes to use for join traffic

=C2=A0 =C2=A0What prefix would the joining node for communication?=C2=A0 Th= ere are
=C2=A0 =C2=A0three options:

=C2=A0 =C2=A0(1)=C2=A0 just use link-local addresses (this may require that= some
=C2=A0 =C2=A0 =C2=A0 traffic between 6LBR and JCE be IPIP tunneled)

=C2=A0 =C2=A0(2)=C2=A0 use a prefix specifically for join traffic (may be e= asier with a
=C2=A0 =C2=A0 =C2=A0 join-only DODAG)

=C2=A0 =C2=A0(3)=C2=A0 use the same prefix as the rest of the traffic (may = require more
=C2=A0 =C2=A0 =C2=A0 complex ACLs, and leaks information to attackers)

=C2=A0 =C2=A0The simplest method is to use the link-local addresses for the= 6top
=C2=A0 =C2=A0connection, and the cost of an IPIP tunnel between the unconst= rained
=C2=A0 =C2=A06LBR and the JCE is not considered significant.



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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


--20cf3011e0597a38980507afd5be-- From nobody Wed Nov 12 15:06:21 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 9158D1A1AC4; Wed, 12 Nov 2014 15:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 Xo_TQ3r4keAy; Wed, 12 Nov 2014 15:06:15 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7011A0AFE; Wed, 12 Nov 2014 15:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17302; q=dns/txt; s=iport; t=1415833575; x=1417043175; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w3VQOGfXb+aQZkL/PGZtSavusepQxwZ4c+CXvcIONDU=; b=VycOXj1y+aoWsfcK4n6wAiUw3nzBLzTFcgey9fm5nmKz+MAkpWN53V1o Xt9llB2/t0RT+sEF1Icot7QxGHCukL3xQuj3Bd3ol+aZ5yDu4X6CNgzAq OrGXeZQVkbG2Ab91k3Dm3BELaNpvbi9j0mYVuxDBpaHs/k+zHNOnE0PlA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FACrnY1StJA2I/2dsb2JhbABVBoMOVFQFBMwvDIZ4VQKBHBYBAQEBAX2EAgEBAQQBAQE3NAQTBAIBCBEBAwEBCxQJBycLFAMGCAIEARIIAYg4CAXQSAEBAQEBAQEBAQEBAQEBAQEBAQEBAReNRgGCdhQSOAaDJ4EeBYRvjUuHG4IEhAyNfYc2ggAggVxtgQdBgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,371,1413244800"; d="scan'208";a="96074840" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 12 Nov 2014 23:06:13 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sACN6DPf012012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 23:06:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 17:06:13 -0600 From: "Pascal Thubert (pthubert)" To: "yoshihiro.ohba@toshiba.co.jp" , "mcr+ietf@sandelman.ca" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/pjUmk5D6+1FKESbWuH+B2XPFZxdYHQQgAAPehA= Date: Wed, 12 Nov 2014 23:06:12 +0000 Deferred-Delivery: Wed, 12 Nov 2014 20:28:00 +0000 Message-ID: References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.87.177] 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/UShy27OHI29w4J20bBEocg9b7k0 Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 23:06:20 -0000 I agree with Yoshi that the link local in the RH is really looking for trou= ble, and certainly an unusual operation. Normally you can only route to a link local if you 1) are directly connecte= d and 2) provide an interface ID associated to the address, which is missin= g in the RH. Yesterday we discussed an "optimistic" usage of a global address that the j= oining device would form. This requires the joining device to receive an RA. Is that unacceptable? Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > yoshihiro.ohba@toshiba.co.jp > Sent: mercredi 12 novembre 2014 12:13 > To: mcr+ietf@sandelman.ca; 6tisch-security@ietf.org; 6tisch@ietf.org > Subject: Re: [6tisch-security] proposed security text for architecture dr= aft >=20 > Michael and all, >=20 > I am still in the middle of understanding how loose source routes for joi= ning > nodes that have only link-local address can work. Another option that is= not > mentioned in the text below is relaying authentication at join assistant = node. > The authentication relay model is proven to work in ZigBee IP. >=20 > I have a reservation on JCE-initiated TLS session as opposed to what exis= ting > 802.1X/PANA with EAP-TLS do where TLS session is initiated by joining nod= e. An > obvious downside of JCE-initiated TLS session is that it is difficult to = use AAA > infrastructure. >=20 > Beacon security issue should be investigated more. Integrity protecting = beacons > with a well-known key can allow attackers to easily launch a DoS attack o= n > already connected nodes by advertising forged ASN as attackers know the w= ell- > known key. Shouldn't network-specific dynamic key also be needed for > protecting beacons for already-connected nodes? >=20 > Regards, > Yoshihiro Ohba >=20 >=20 > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Michael Richardson > Sent: Thursday, November 13, 2014 1:51 AM > To: 6tisch-security@ietf.org; 6tisch@ietf.org > Subject: [6tisch-security] proposed security text for architecture draft >=20 >=20 > This text is the architecture results of the secure (zero-touch) design t= eam. > The realization that we should use loose source routes is due to Pascal. >=20 > I believe this goes into a new section between 10. Centralized vs. > and 11. IANA Considerations. Interspersed is some text that I think goes= in to > section 12. Security Considerations. >=20 > If you are interested in the history of this text, or some additional mor= e > implementation side ideas, then I recommend reviewing the diff > http://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-6tisch--security= -6top- > 03&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-richardson-6tisch--secur= ity- > 6top-04 >=20 >=20 > 10B. Architectural requirements of join protocol >=20 > 10B.1. Entities involves in the join process >=20 > The following actors are involved: there is a new joining node. It > is (radio) adjacent to the join assistant. The join assistant is > part of the production network, and participates in one or more > DODAGs, such that it is reachable from the 6LBR, and the JCE. >=20 > 10B.2. Join Protocol deliverables >=20 > This section works from the ultimate goal, and goes backwards to > prerequisite actions. (Section 6 presents the protocol from > beginning to end order) >=20 > The ultimate goal of the join protocol is to provide a new node with > a locally significant security credentials that it is able to take > part in the network directly. The credentials may vary by > deployment. They can be one of: >=20 >=20 > 1) a network-wide shared symmetric key (this is the production > network key, or MasterKey) >=20 > 2) a locally significant (one-level only) 802.11AR type LDevID > certificate (which allows it to negotiate a pair-wise keys) >=20 > One of these two items is delivered by JCE to the joining node using > the 6top protocol. That is, the JCE provisions using a secure > "northbound" interface. The authentication of this interface the > subject of the Join Protocol as explained below. >=20 > The above credential are used for authentication to generate per-peer > L2, using a key exchange protocol. The choice of key exchange > protocol, and what kind of link and multicast keying needs to be done > is also provisioned by the JCE. There are a number of options for > doing this, such as: >=20 > 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] > (IMPORTANT, a good option. Uses certificates from common CA) >=20 > 2) work in 802.15.9 (uses certificates from common CA) >=20 > 3) Security Framework and Key Management Protocol Requirements for > 6TiSCH [I-D.ohba-6tisch-security] (this document provides the > phase 0 required, using the network-wide shared key) >=20 > 4) Layer-2 security aspects for the IEEE 802.15.4e MAC > [I-D.piro-6tisch-security-issues]: the MasterKey is used to > derive per-peer L2 keys >=20 > Per-peer L2 keying is critical when doing peer-2-peer schedule > negotiation over 15.4 Information Elements. Therefore a network-wide > layer-2 key is inappropriate for the self-organizing networks, and a > protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. >=20 > For networks where there is a PCE present and it will do all schedule > computation, then the only trust relationship necessary is between > the individual node and the PCE, and it MAY be acceptable to have a > network-wide L2 key derived in ways such as > [I-D.piro-6tisch-security-issues] describes in section ?. The trust > relationship between the PCE and the joining node flows from the > LDevID certificate loaded by the JCE. When the PCE and JCE are co- > located, the existing 6top/DTLS security association could be reused. >=20 > 10B.3. Join Protocol connection setup >=20 > The intermediate level goal of the join protocol is to enable a Join > Coordination Entity (JCE) to reach out to the new node, and install > the credentials detailed above. The JCE must authenticate itself to > the joining node so that the joining node will know that it has > joined the correct network, and the joining node must authenticate > itself to the JCE so that the JCE will know that this node belongs in > the network. This two way authentication occurs in the 6top/CoAP/ > DTLS session that is established between the JCE and the joining > node. >=20 > [I-D.ietf-6tisch-6top-interface] presents a way to interface to a > 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] > explains how to access that information model using CoAP. This > information model will include security attributes for the network. > The JCE would therefore reach out to the joining node and simply > provision appropriate security properties into the joining node, much > like the PCE will provision schedules. >=20 > This 6top-based secure join protocol has defined a push model for > security provisioning by the JCE. This has been done for three > reasons: >=20 > 1) 6tisch nodes already have to have a 6top CoAP server for schedule > provising >=20 > 2) this permits the JCE to manage how many nodes are trying to join > at the same time, and limit how much bandwidth/energy is used for > the join operation, and also for the JCE to prioritize the join > order for nodes. >=20 > 3) making the JCE initiate the DTLS connection significantly > simplies the certificate chains that must be exchanged as the > most constrained side (the joining node) provides it's > credentials first, and lets the less constrained JCE figure out > what kind of certificate chain will be required to authenticate > the JCE to the joining node. In EAP-TLS/802.1x situations, the > TLS channel is created in the opposite direction, and it would > have to complete in a tentative way, and then further > authorization occur in-band. >=20 > 10B.4. End to End considerations for Join Protocol >=20 > In order for a 6top/DTLS/CoAP connection to occur between the JCE and > the joining node, there needs to be end-to-end IPv6 connectivity > between those two entities. The joining node will not participate in > the route-over RPL mesh, but rather will be seen by the network as > being a 6lowpan only leaf-node. >=20 > The joining node sends traffic to the join assistant, which forwards > it using the normal RPL DODAG upwards routes, and which will reach > the JCE using regular routing. >=20 > The challenge is getting connectivity from the JCE to the joining > node, as the DODAG will have no information about this node. > Instead, the JCE will use loose-source routes to address packets > first to the Join Assistant, which will then forward to the joining > node. This has an interaction with the (strict) source routes used > by non-storing DODAGs which would be used by the 6LBR to reach the > Join Assistant. >=20 > There are some alternatives to having full end to end connectivity > which are discussed in the security considerations section. >=20 > 12.1. Security Considerations: alternatives to source routes >=20 > This goes into security-considerations section >=20 > A number of alternatives were considered for creating end to end > connectivity between the joining node and the JCE, but were rejected. >=20 > (1) IPIP tunnel between Join Assistant and JCE >=20 > (2) using straight RPL routing: the Join Assistant sends a DAO >=20 > (3) using a separate RPL DODAG for join traffic >=20 > (4) establishing a specific multi-hop 6tisch track for join traffic > for each Join Assistant >=20 > 12.1.1.1. IPIP tunnel >=20 > This mechanism requires 40 bytes overhead per packet, and may require > specific state to be created on the Join Assistant, or may open the > network up to a resource exhaustion by malicious join nodes. >=20 > This mechanism was rejected on due to byte count, because it would > require code only needed for join, and because doing it securely may > require a per-tunnel state to be maintained on the join assistant. >=20 > 12.1.1.2. join existing DODAG >=20 > This mechanism is to just have the new node join the DODAG as a leaf > node. The join assistant would issue a DAO for the new node. If a > storing DODAG was used, this would directly cost state in all parent > nodes of the Join Assistant, subjecting the lower-rank parts of the > network to significant denial of service attacks. >=20 > On a non-storing DODAG the situation is significantly better: no > state is created by the presence of the leaf node except in the 6LBR, > where available resources may be higher. >=20 > This mechanism was rejected in favour of the loose source routed > option as this the loose source routed option always works even for > storing DODAGs, and is otherwise exactly equivalent in terms of > network bandwidth cost. >=20 > 12.1.1.3. join a DODOAG for joining >=20 > One option to deal with the problem of resource consumption in the > storing DODAG case is to use a second DODAG. >=20 > This mechanism was rejected as it consumes resources in all nodes for > the second DODAG, and many implementations support on a single DODAG. > While storing DODAGs have a lighter network impact than non-storing > ones (due to the lack of source routes), the PCE can control how much > network bandwidth can be wasted by malicious join nodes using the > regular 6tisch mechanisms, and this can be tuned. A second DODAG > would be a sunk cost with no tuning possible. >=20 > 12.1.1.4. create 6tisch track to form mesh-under >=20 > This mechanism would use 6tisch tracks so that traffic from the JCE > would be switched from 6LBR to join node. A track would be required > to each join assistant. This is an optimized form of source routing. >=20 > This mechanism was not rejected, rather it was observed that it may > be applied to any mechanism that uses source routing, and is an > optimization; it has a certain cost in the form of intermediary node > state, but that this state is not created by a malicious join node, > rather it is created by the PCE. >=20 > 10B.5. Join node discovery mechanism >=20 > Continuing to work backwards, in order the JCE reach out to provision > the Joining Node, it needs to know that the new node is present. > This is done by taking advantage of the 6lowPAN Address Resolution > Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address > to also be sent up to the 6LBR for duplicate detection using the DAR/ > DAC mechanism. The 6LBR simply needs to tell the JCE about this. A > new protocol may be required for the situation where the JCE, PCE and > 6LBR are not co-located; it may be that this protocol could be simply > a DAR in some encapsulation. The details of this are currently out > of scope for the architecture, as they affect interoperability > between different vendors of JCE/6LBR/PCE rather than > interoperability between the assistance/offload infrastructure, and > the contrained nodes. Future work may specify this part. >=20 > In addition to needing to know the joining devices address from the > DAR/NS, the JCE also needs to know the joining node's IDevID. This > is to determine if the node should even get any attention. At this > point, the IDevID can be forged, it will be authenticated during the > setup of the 6top control protocol in the DTLS certificate exchange. > If the serialNumber attribute of the IDevID is less than 64 bits, > then it is possible that it could be placed into the EUI-64 option of > the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] > EARO. The JCE needs to know the joining node's serialNumber to know > if this is device that it should even attempt to provision; and if > so, it may need to retrieve an appropriate certificate chain (see > [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for > the JCE to prove it is the legitimate owner of the joining node. >=20 > Neither 802.1AR nor [RFC5280] provide any structure for the > serialNumber, except that they are positive integers of up-to 20 > octets in size (numbers up to 2^160). This specification would > require that the serialNumber encoded in the IDevID be the same as > the EUI-64 used by the device. Some consideration needs to be given > as to whether there are privacy considerations to doing this: any > observer that can see the join traffic, can also see the source MAC > address of the node as well. >=20 > Prior to being able to announce itself in a NS, the joining node > needs to find the Join Network. This is done by listening to an > extended beacon which are broadcast in designated slotframes by Join > Assistants. The Extended Beacon provides a way for the Joining Node > to synchronize itself to the overall timeslot schedule and provides > an Aloha period in which the Joining Node can send a Router > Soliticiation, and receive an appropriate Router Advertisement giving > the Joining Node a prefix and default route to which to send join > traffic. >=20 > It may be possible to eliminate a message exchange if space for a > Router Advertisement can be found as part of the Join Network > Extended Beacon. This Enhanced Beacon would be distinct to the Join > Network, and would be encrypted with the well-known Join Network key. >=20 > 10B.5.1. prefixes to use for join traffic >=20 > What prefix would the joining node for communication? There are > three options: >=20 > (1) just use link-local addresses (this may require that some > traffic between 6LBR and JCE be IPIP tunneled) >=20 > (2) use a prefix specifically for join traffic (may be easier with a > join-only DODAG) >=20 > (3) use the same prefix as the rest of the traffic (may require more > complex ACLs, and leaks information to attackers) >=20 > The simplest method is to use the link-local addresses for the 6top > connection, and the cost of an IPIP tunnel between the unconstrained > 6LBR and the JCE is not considered significant. >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Wed Nov 12 15:28:03 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 B14B11A1B44; Wed, 12 Nov 2014 15:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 Nx3UAbngTuL5; Wed, 12 Nov 2014 15:27:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B209A1A1B57; Wed, 12 Nov 2014 15:27:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A30920098; Wed, 12 Nov 2014 18:30:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1103A637F4; Wed, 12 Nov 2014 18:27:52 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EEDED637F2; Wed, 12 Nov 2014 18:27:52 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <5463BFBC.2010501@gmail.com> References: <20507.1415811045@sandelman.ca> <5463BFBC.2010501@gmail.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/CZ08ynONY35IcN8J91YekA8JxNM Cc: "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 23:27:57 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: > BTW - the text blurb (proposed security text) presumably comes from a > "secure zero touch design team" effort. To my knowledge, such a design > team has never been put in place. So, I am extremely puzzled here. Let > us discuss during the 6TiSCH meeting tomorrow. The "secure zero touch design team" is my attempt to consisely elucidate the mandate of the 6tisch security design team. I claim that this text is the rough consensus of the design team; I do not claim that it is endorsed by anyone other than myself, and I would welcome other approaches to solving t= he zero touch enrollment problem. I do not agree that there is any issue with the well-known beacon key. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGPs9oCLcPvd0N1lAQIyuQf9HrT3xxC1+EOr0u2ZAcKp8K2C/Z2/HuUV MuWbJAEupsDTZ5YchtNMaIz6jT1aaKtd+HDRKjoib5jvguRZROJS8rhUjC1v7Y7O qdwNZkW8eYl8BV9lnnYko7zneiy5avfytNjqbWZOZHmnLOemuvptWVqQ8Z4bFI4T ZU+YwC2VkE/tQFKxyArNoceyTOv8qSsovGqYPUOQY9rQgNB6/Ut3nxDxpsZVOCtu QT7IUaqp2sWSjvy82jTNFiG3uqqIXzs6eLihtghDLjZribKWE1c2+jS4GPo+AEtD bbahskZ1wsPvZU9iLevK/xptNMZj4bNQLp6nkwzOIV1gJtI5rIzm/g== =jLI1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 12 15:36: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 9244A1A1B68; Wed, 12 Nov 2014 15:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 pkkHdvpzaxFP; Wed, 12 Nov 2014 15:36:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ED11A1B51; Wed, 12 Nov 2014 15:36:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15EFB20098; Wed, 12 Nov 2014 18:38:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C6A18637F4; Wed, 12 Nov 2014 18:36:04 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AE3D4637F2; Wed, 12 Nov 2014 18:36:04 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@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/YCYZkwIbSetBxw6fbvI2MNAblvs Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] proposed security text for architecture draft 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: Wed, 12 Nov 2014 23:36:07 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > I am still in the middle of understanding how loose source routes for > joining nodes that have only link-local address can work. Another > option that is not mentioned in the text below is relaying > authentication at join assistant node.=20=20 Yoshihiro has correctly pointed out that in IPv6 some of the loose source route options are not as rich as we envisioned; and we need to think which exact option is appropriate. I think this is a detail, and I think that we can deal with this. > The authentication relay model > is proven to work in ZigBee IP. I can not comment directly; some contributors felt that this would not work for them. Too much single use code, too much total byte count, packets too = big. > I have a reservation on JCE-initiated TLS session as opposed to what > existing 802.1X/PANA with EAP-TLS do where TLS session is initiated by > joining node. An obvious downside of JCE-initiated TLS session is th= at > it is difficult to use AAA infrastructure. Perhaps you can more clearly say what kind of EAP methods you would propose. Username+password? SIM or AKA authentication? Kerberos/NTLM(ActiveDirecto= ry)? What else is there? The TLS methods do not count, as they are usually used just to create a secure container for a username/password, and in the situations where the certificate is relevant, the *DTLS* method proposed can use certificates in the same way.=20 > Beacon security issue should be investigated more. Integrity > protecting beacons with a well-known key can allow attackers to easily > launch a DoS attack on already connected nodes by advertising forged > ASN as attackers know the well-known key. Shouldn't network-specific > dynamic key also be needed for protecting beacons for already-connect= ed > nodes? Already connected nodes listen to beacons sent under the production key, none of this text not changes that: can you offer some edits to make that clearer. =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) iQEVAwUBVGPu4YCLcPvd0N1lAQLLmAf+KHpuVvyTwqq0gv9t9mCA/Yv2jSSGDget 06WLqALLHc2GQHOaWyNiOvjZVvbF6h53l7ZA5TAJhVIaxYkE9NCj+shY46k9upxk kgys7e13GRJrCSWmxFXNGnvZEVFuDSKqhTwWSwSkENO2bybBpg0F7o15Gen4I6J2 TpNJOvD/QOHtV3bgsekrX089b14hsjSRhtLtqXdAGnFQuuegURUVhQuqGSqD9jYE Q7XBfLSsCloPvAkKo1ou+KgJu/GhXrkvalu5QxClqH19Gl+bPqC0YE4JSR9heCTX 6qc80j6LY2Rj0y6GbmAJvZ1cftpFKmzrfXdwjP3b446T41x1yPY4/A== =eqMH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 12 15:39: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 864DC1A1B60; Wed, 12 Nov 2014 15:39:04 -0800 (PST) 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 xW4aXUgyT6mf; Wed, 12 Nov 2014 15:39:00 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54291A1B51; Wed, 12 Nov 2014 15:38:59 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so15490278wgh.40 for ; Wed, 12 Nov 2014 15:38:58 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2MJOu3iiQVp5mXodOvm3HtbrE0t3o5mB279NFiOZftw=; b=x/IAlB738Eg4WlVUAsp4uob+iL1jSe68bgB9jgK3+y3smk5N3RfnT2wUBSMRKpeN4R 9c8TZEU343m9aRislEl4mLoXRxwmZX615YJSooTrTcZ22g7jt0eM6W4sQ/Ywr7LKzfdn gVim3owgO8gdlPVPLZBTpH52VB4zQTYLqBoWF2e5jZHvvJ3ywgVsFa95MELh/2+bkwKv JZsNPXFkQQJkjSYO7sJHSBKLKEKjvYGIgfxFMdr201QViaVu5uQB9OBAlME/LOYNbs8I j2O5hG6fotjn1wzCWU0ixrm4dOIdwOjGbpdMGcEJTvLqBOZ79RcZ3TzFAN02NePQ3zLo wjZA== X-Received: by 10.180.14.165 with SMTP id q5mr9651692wic.0.1415835538543; Wed, 12 Nov 2014 15:38:58 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:dce4:e30f:2f5:5fe7? (t2001067c03700160dce4e30f02f55fe7.wireless.v6.meeting.ietf.org. [2001:67c:370:160:dce4:e30f:2f5:5fe7]) by mx.google.com with ESMTPSA id pf4sm22187703wjb.36.2014.11.12.15.38.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Nov 2014 15:38:57 -0800 (PST) Message-ID: <5463EF8B.9070605@gmail.com> Date: Wed, 12 Nov 2014 18:38:51 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson References: <20507.1415811045@sandelman.ca> <5463BFBC.2010501@gmail.com> <3490.1415834872@sandelman.ca> In-Reply-To: <3490.1415834872@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/7tlhBy-V5vOBWM0haJuhCk-s_Jo Cc: "Pascal Thubert \(pthubert\)" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: [6tisch-security] (procedural) Re: proposed security text for architecture draft 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: Wed, 12 Nov 2014 23:39:04 -0000 I am afraid using the words you used puts people on the wrong footing and is a shame. On 11/12/2014 6:27 PM, Michael Richardson wrote: > Rene Struik wrote: > > BTW - the text blurb (proposed security text) presumably comes from a > > "secure zero touch design team" effort. To my knowledge, such a design > > team has never been put in place. So, I am extremely puzzled here. Let > > us discuss during the 6TiSCH meeting tomorrow. > > The "secure zero touch design team" is my attempt to consisely elucidate the > mandate of the 6tisch security design team. I claim that this text is the > rough consensus of the design team; I do not claim that it is endorsed by > anyone other than myself, and I would welcome other approaches to solving the > zero touch enrollment problem. > > I do not agree that there is any issue with the well-known beacon key. > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Wed Nov 12 15:41:47 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 6952C1A1B5F; Wed, 12 Nov 2014 15:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 W-QJPyLdycgo; Wed, 12 Nov 2014 15:41:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE031A1B44; Wed, 12 Nov 2014 15:41:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB70920098; Wed, 12 Nov 2014 18:43:51 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 83E56637F4; Wed, 12 Nov 2014 18:41:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6BF8E637F2; Wed, 12 Nov 2014 18:41:43 -0500 (EST) From: Michael Richardson To: Subir Das In-Reply-To: References: <20507.1415811045@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/6uOOBHyR4H3UcmUhMF5lzxjvZwM Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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: Wed, 12 Nov 2014 23:41:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Subir Das wrote: > Michael, Are you suggesting to add this entire text to the architectu= re > document? I am afraid that the text is more than architecture elemen= ts > and requirements?=20=20 Yes, it could well be the case; so I am would welcome ways to clarify things so that the it fits better.=20=20 I like to think of architecture in terms of how houses are specified, designed and built... the architect does not decide how many mm thick the concrete foundation shall be (the civil engineer does that), but the architect does decide that a foundation will be required due to the height = of the house, and that the foundation shall contain a basement that can be used as a TV room; vs if it will just be a crawl space.=20 > I was not able to attend the last Tuesday's > call. You are claiming that the ad hoc security team recommended this > text to the WG for consideration. Is this happened during last call? I > understand that you didn't get time yet to publish the minutes. Sorry, did I not get to the minutes for the call on Tuesday? Oh. Damn. You are probably right... I will do that. I plead insanity due to nomcom-chair. =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) iQEVAwUBVGPwNICLcPvd0N1lAQIDjgf/fDoS3V9MuSD2yaEUg+o7lKZjFeEF5H1l Vpewa7Kpdd4w2JaqLm2XI2kjwqt9Xv2xSDhWVa9lkzhSfnKgZQ/Ku1gGpv9oWxpg aoS1nQOZqo0opDLMWVqFw2xMI6hYg6r50f6ABfS1dybQQ7Kc7jzQm/h3MApbhS78 I3ub7EmpYs4y0CZahubnWMMANZ0VGO/LrOVhJYKZDl6QT8z6pm0nJiwV70L0WJi2 GeYwn3IjWumXYu2xkErfP1H9wA2lxrJ2h3UTw/PTkxOTwRhwJZn5YoQo+pwhtR1i wa+a61Ff3DpOcbqXWCO3dCQCIRr6j3Q2M+e92WuknAgA0Lf0oD+eGw== =wjKa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 12 16:24:51 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 BEEFC1A00CA; Wed, 12 Nov 2014 16:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vVX2i_lFZ9ZW; Wed, 12 Nov 2014 16:24:37 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160C71A011D; Wed, 12 Nov 2014 16:24:13 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAD0OBMp006406; Thu, 13 Nov 2014 09:24:11 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAD0OBGV019521; Thu, 13 Nov 2014 09:24:11 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA19519; Thu, 13 Nov 2014 09:24:10 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAD0OAfc001560; Thu, 13 Nov 2014 09:24:10 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAD0OAM9021621; Thu, 13 Nov 2014 09:24:10 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 09:24:10 +0900 From: To: Thread-Topic: [6tisch] [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/tFzySavYUJZ1EKsu8a/r5YA9ZxdrsLQ Date: Thu, 13 Nov 2014 00:24:10 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> In-Reply-To: <5854.1415835364@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.37] 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/8sAbdtyogwBtZSGvJf-dM4Efzxc Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 13 Nov 2014 00:24:42 -0000 Michael, Regarding EAP method, I mentioned EAP-TLS. EAP-TLS works for both certific= ate-based authentication and pre-shared key based authentication (EAP-TLS-P= SK) without EAP tunneling method such as EAP-TTLS. In the latter case, TLS= session is typically terminated at AAA server. =20 It is unfortunate that some contributors felt that EAP-based approach does = not work for them, but there is another use case where EAP-based approach i= s definitely needed (smart meters). Having said that it would make sense t= o have two options (DTLS-based and EAP-based approaches) for joining operat= ion. Regarding beacon security, I can send clarification text. Yoshihiro Ohba -----Original Message----- From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michael Richards= on Sent: Thursday, November 13, 2014 8:36 AM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch] [6tisch-security] proposed security text for architec= ture draft wrote: > I am still in the middle of understanding how loose source routes for > joining nodes that have only link-local address can work. Another > option that is not mentioned in the text below is relaying > authentication at join assistant node. =20 Yoshihiro has correctly pointed out that in IPv6 some of the loose source r= oute options are not as rich as we envisioned; and we need to think which e= xact option is appropriate. I think this is a detail, and I think that we = can deal with this. > The authentication relay model > is proven to work in ZigBee IP. I can not comment directly; some contributors felt that this would not work= for them. Too much single use code, too much total byte count, packets too= big. > I have a reservation on JCE-initiated TLS session as opposed to what > existing 802.1X/PANA with EAP-TLS do where TLS session is initiated b= y > joining node. An obvious downside of JCE-initiated TLS session is th= at > it is difficult to use AAA infrastructure. Perhaps you can more clearly say what kind of EAP methods you would propose= . Username+password? SIM or AKA authentication? Kerberos/NTLM(ActiveDirecto= ry)? What else is there? The TLS methods do not count, as they are usually used just to create a sec= ure container for a username/password, and in the situations where the cert= ificate is relevant, the *DTLS* method proposed can use certificates in the= same way.=20 > Beacon security issue should be investigated more. Integrity > protecting beacons with a well-known key can allow attackers to easil= y > launch a DoS attack on already connected nodes by advertising forged > ASN as attackers know the well-known key. Shouldn't network-specific > dynamic key also be needed for protecting beacons for already-connect= ed > nodes? Already connected nodes listen to beacons sent under the production key, no= ne of this text not changes that: can you offer some edits to make that cle= arer. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed Nov 12 16:43: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 A91491A013B; Wed, 12 Nov 2014 16:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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, RP_MATCHES_RCVD=-0.594, 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 iVd7TWEaGrU3; Wed, 12 Nov 2014 16:43:34 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF87C1A00FF; Wed, 12 Nov 2014 16:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52984; q=dns/txt; s=iport; t=1415839414; x=1417049014; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ncJ+XzQQBrqDUB+lQ/Tz6id3DrWN39zleJJcOU679jI=; b=C1O3S9Xxi54TSmimFzU0nfQBT8S4nnXy1/maH6+iDG3RgXyuSCVuzhdT pMZdrjoHjGgvUMGTXpU6a9pu1eNLAy+TlAwdozE850R8v7l348G1+oRE+ HNoBkI2DBphHSoSolTajWogqtAucE7/l/BQwhSG7m0G2RobOHK51lYN+f c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMIAFr+Y1StJA2F/2dsb2JhbABbgkhGVFkEgwLJMgEEhn9VAhyBARYBAQEBAX2EAgEBAQQBAQEXCQpBBAcQAgEIEQEDAQELFgEGAwICAiULFAMGCAIEAQ0FCAGIOA25QJZTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41GAYJ2Ji0EBgEGgnE2gR4FhG+NS4cbggSEDI19hzaCACCBXG2BB0GBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,372,1413244800"; d="scan'208,217";a="371800488" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2014 00:43:32 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAD0hWgo024116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 00:43:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 18:43:31 -0600 From: "Pascal Thubert (pthubert)" To: Subir Das , Michael Richardson Thread-Topic: [6tisch] [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/r01gUsQo46lukuljCW640Sk55xdtfjA Date: Thu, 13 Nov 2014 00:43:31 +0000 Deferred-Delivery: Thu, 13 Nov 2014 00:43:00 +0000 Message-ID: References: <20507.1415811045@sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.87.177] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A4F742xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/OX062QsX1upF2dche0px5bEqg70 Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 13 Nov 2014 00:43:39 -0000 --_000_E045AECD98228444A58C61C200AE1BD848A4F742xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIGxvdCBvZiB0ZXh0LCBidXQgcmVhZGluZyBpdCBJIGhhdmUgdHJvdWJsZSBzaW1w bGlmeWluZyBtdWNoLiBBIGJpdCBvZiB0cmltbWluZyBtYXkgaGVscCwgYW5kIHRoaXMgd291bGQg anVzdGlmeSB0aGF0IHdlIG1haW50YWluIGFuZCBleHRlbmQgTWljaGFlbOKAmXMgZG9jIGZvciB0 aGUgbmV4dCByb3VuZC4NCldoYXQgZG8gb3RoZXJzIHRoaW5rPw0KDQpQYXNjYWwNCg0KRnJvbTog NnRpc2NoIFttYWlsdG86NnRpc2NoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdWJp ciBEYXMNClNlbnQ6IG1lcmNyZWRpIDEyIG5vdmVtYnJlIDIwMTQgMTM6MTENClRvOiBNaWNoYWVs IFJpY2hhcmRzb24NCkNjOiA2dGlzY2hAaWV0Zi5vcmc7IDZ0aXNjaC1zZWN1cml0eUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFs2dGlzY2hdIFs2dGlzY2gtc2VjdXJpdHldIHByb3Bvc2VkIHNlY3Vy aXR5IHRleHQgZm9yIGFyY2hpdGVjdHVyZSBkcmFmdA0KDQpNaWNoYWVsLA0KQXJlIHlvdSBzdWdn ZXN0aW5nIHRvIGFkZCB0aGlzIGVudGlyZSB0ZXh0IHRvIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1l bnQ/ICBJIGFtIGFmcmFpZCB0aGF0IHRoZSB0ZXh0IGlzIG1vcmUgdGhhbiBhcmNoaXRlY3R1cmUg ZWxlbWVudHMgYW5kIHJlcXVpcmVtZW50cz8gIEkgd2FzIG5vdCBhYmxlIHRvIGF0dGVuZCB0aGUg bGFzdCBUdWVzZGF5J3MgY2FsbC4gWW91IGFyZSBjbGFpbWluZyB0aGF0IHRoZSBhZCBob2Mgc2Vj dXJpdHkgdGVhbSByZWNvbW1lbmRlZCB0aGlzIHRleHQgdG8gdGhlIFdHIGZvciBjb25zaWRlcmF0 aW9uLiBJcyB0aGlzIGhhcHBlbmVkIGR1cmluZyBsYXN0IGNhbGw/IEkgdW5kZXJzdGFuZCB0aGF0 IHlvdSBkaWRuJ3QgZ2V0IHRpbWUgeWV0IHRvIHB1Ymxpc2ggdGhlICBtaW51dGVzLg0KLVN1Ymly DQoNCk9uIFdlZCwgTm92IDEyLCAyMDE0IGF0IDExOjUwIEFNLCBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj4gd3Jv dGU6DQoNClRoaXMgdGV4dCBpcyB0aGUgYXJjaGl0ZWN0dXJlIHJlc3VsdHMgb2YgdGhlIHNlY3Vy ZSAoemVyby10b3VjaCkgZGVzaWduIHRlYW0uDQpUaGUgcmVhbGl6YXRpb24gdGhhdCB3ZSBzaG91 bGQgdXNlIGxvb3NlIHNvdXJjZSByb3V0ZXMgaXMgZHVlIHRvIFBhc2NhbC4NCg0KSSBiZWxpZXZl IHRoaXMgZ29lcyBpbnRvIGEgbmV3IHNlY3Rpb24gYmV0d2VlbiAxMC4gQ2VudHJhbGl6ZWQgdnMu DQphbmQgMTEuIElBTkEgQ29uc2lkZXJhdGlvbnMuICBJbnRlcnNwZXJzZWQgaXMgc29tZSB0ZXh0 IHRoYXQgSSB0aGluayBnb2VzIGluIHRvIHNlY3Rpb24NCjEyLiBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucy4NCg0KSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRoZSBoaXN0b3J5IG9mIHRoaXMgdGV4 dCwgb3Igc29tZSBhZGRpdGlvbmFsIG1vcmUgaW1wbGVtZW50YXRpb24NCnNpZGUgaWRlYXMsIHRo ZW4gSSByZWNvbW1lbmQgcmV2aWV3aW5nIHRoZSBkaWZmDQogICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwxPWRyYWZ0LXJpY2hhcmRzb24tNnRpc2NoLS1zZWN1cml0eS02dG9wLTAz JmRpZmZ0eXBlPS0taHRtbCZzdWJtaXQ9R28lMjEmdXJsMj1kcmFmdC1yaWNoYXJkc29uLTZ0aXNj aC0tc2VjdXJpdHktNnRvcC0wNA0KDQoNCjEwQi4gIEFyY2hpdGVjdHVyYWwgcmVxdWlyZW1lbnRz IG9mIGpvaW4gcHJvdG9jb2wNCg0KMTBCLjEuICBFbnRpdGllcyBpbnZvbHZlcyBpbiB0aGUgam9p biBwcm9jZXNzDQoNCiAgIFRoZSBmb2xsb3dpbmcgYWN0b3JzIGFyZSBpbnZvbHZlZDogdGhlcmUg aXMgYSBuZXcgam9pbmluZyBub2RlLiAgSXQNCiAgIGlzIChyYWRpbykgYWRqYWNlbnQgdG8gdGhl IGpvaW4gYXNzaXN0YW50LiAgVGhlIGpvaW4gYXNzaXN0YW50IGlzDQogICBwYXJ0IG9mIHRoZSBw cm9kdWN0aW9uIG5ldHdvcmssIGFuZCBwYXJ0aWNpcGF0ZXMgaW4gb25lIG9yIG1vcmUNCiAgIERP REFHcywgc3VjaCB0aGF0IGl0IGlzIHJlYWNoYWJsZSBmcm9tIHRoZSA2TEJSLCBhbmQgdGhlIEpD RS4NCg0KMTBCLjIuICBKb2luIFByb3RvY29sIGRlbGl2ZXJhYmxlcw0KDQogICBUaGlzIHNlY3Rp b24gd29ya3MgZnJvbSB0aGUgdWx0aW1hdGUgZ29hbCwgYW5kIGdvZXMgYmFja3dhcmRzIHRvDQog ICBwcmVyZXF1aXNpdGUgYWN0aW9ucy4gIChTZWN0aW9uIDYgcHJlc2VudHMgdGhlIHByb3RvY29s IGZyb20NCiAgIGJlZ2lubmluZyB0byBlbmQgb3JkZXIpDQoNCiAgIFRoZSB1bHRpbWF0ZSBnb2Fs IG9mIHRoZSBqb2luIHByb3RvY29sIGlzIHRvIHByb3ZpZGUgYSBuZXcgbm9kZSB3aXRoDQogICBh IGxvY2FsbHkgc2lnbmlmaWNhbnQgc2VjdXJpdHkgY3JlZGVudGlhbHMgdGhhdCBpdCBpcyBhYmxl IHRvIHRha2UNCiAgIHBhcnQgaW4gdGhlIG5ldHdvcmsgZGlyZWN0bHkuICBUaGUgY3JlZGVudGlh bHMgbWF5IHZhcnkgYnkNCiAgIGRlcGxveW1lbnQuICBUaGV5IGNhbiBiZSBvbmUgb2Y6DQoNCg0K ICAgMSkgIGEgbmV0d29yay13aWRlIHNoYXJlZCBzeW1tZXRyaWMga2V5ICh0aGlzIGlzIHRoZSBw cm9kdWN0aW9uDQogICAgICAgbmV0d29yayBrZXksIG9yIE1hc3RlcktleSkNCg0KICAgMikgIGEg bG9jYWxseSBzaWduaWZpY2FudCAob25lLWxldmVsIG9ubHkpIDgwMi4xMUFSIHR5cGUgTERldklE DQogICAgICAgY2VydGlmaWNhdGUgKHdoaWNoIGFsbG93cyBpdCB0byBuZWdvdGlhdGUgYSBwYWly LXdpc2Uga2V5cykNCg0KICAgT25lIG9mIHRoZXNlIHR3byBpdGVtcyBpcyBkZWxpdmVyZWQgYnkg SkNFIHRvIHRoZSBqb2luaW5nIG5vZGUgdXNpbmcNCiAgIHRoZSA2dG9wIHByb3RvY29sLiAgVGhh dCBpcywgdGhlIEpDRSBwcm92aXNpb25zIHVzaW5nIGEgc2VjdXJlDQogICAibm9ydGhib3VuZCIg aW50ZXJmYWNlLiAgVGhlIGF1dGhlbnRpY2F0aW9uIG9mIHRoaXMgaW50ZXJmYWNlIHRoZQ0KICAg c3ViamVjdCBvZiB0aGUgSm9pbiBQcm90b2NvbCBhcyBleHBsYWluZWQgYmVsb3cuDQoNCiAgIFRo ZSBhYm92ZSBjcmVkZW50aWFsIGFyZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbiB0byBnZW5lcmF0 ZSBwZXItcGVlcg0KICAgTDIsIHVzaW5nIGEga2V5IGV4Y2hhbmdlIHByb3RvY29sLiAgVGhlIGNo b2ljZSBvZiBrZXkgZXhjaGFuZ2UNCiAgIHByb3RvY29sLCBhbmQgd2hhdCBraW5kIG9mIGxpbmsg YW5kIG11bHRpY2FzdCBrZXlpbmcgbmVlZHMgdG8gYmUgZG9uZQ0KICAgaXMgYWxzbyBwcm92aXNp b25lZCBieSB0aGUgSkNFLiAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9wdGlvbnMgZm9yDQogICBk b2luZyB0aGlzLCBzdWNoIGFzOg0KDQogICAxKSAgTWVzaCBMaW5rIEV4Y2hhbmdlIFtJLUQua2Vs c2V5LWludGFyZWEtbWVzaC1saW5rLWVzdGFibGlzaG1lbnRdDQogICAgICAgKElNUE9SVEFOVCwg YSBnb29kIG9wdGlvbi4gIFVzZXMgY2VydGlmaWNhdGVzIGZyb20gY29tbW9uIENBKQ0KDQogICAy KSAgd29yayBpbiA4MDIuMTUuOSAodXNlcyBjZXJ0aWZpY2F0ZXMgZnJvbSBjb21tb24gQ0EpDQoN CiAgIDMpICBTZWN1cml0eSBGcmFtZXdvcmsgYW5kIEtleSBNYW5hZ2VtZW50IFByb3RvY29sIFJl cXVpcmVtZW50cyBmb3INCiAgICAgICA2VGlTQ0ggW0ktRC5vaGJhLTZ0aXNjaC1zZWN1cml0eV0g KHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlDQogICAgICAgcGhhc2UgMCByZXF1aXJlZCwgdXNp bmcgdGhlIG5ldHdvcmstd2lkZSBzaGFyZWQga2V5KQ0KDQogICA0KSAgTGF5ZXItMiBzZWN1cml0 eSBhc3BlY3RzIGZvciB0aGUgSUVFRSA4MDIuMTUuNGUgTUFDDQogICAgICAgW0ktRC5waXJvLTZ0 aXNjaC1zZWN1cml0eS1pc3N1ZXNdOiB0aGUgTWFzdGVyS2V5IGlzIHVzZWQgdG8NCiAgICAgICBk ZXJpdmUgcGVyLXBlZXIgTDIga2V5cw0KDQogICBQZXItcGVlciBMMiBrZXlpbmcgaXMgY3JpdGlj YWwgd2hlbiBkb2luZyBwZWVyLTItcGVlciBzY2hlZHVsZQ0KICAgbmVnb3RpYXRpb24gb3ZlciAx NS40IEluZm9ybWF0aW9uIEVsZW1lbnRzLiAgVGhlcmVmb3JlIGEgbmV0d29yay13aWRlDQogICBs YXllci0yIGtleSBpcyBpbmFwcHJvcHJpYXRlIGZvciB0aGUgc2VsZi1vcmdhbml6aW5nIG5ldHdv cmtzLCBhbmQgYQ0KICAgcHJvdG9jb2wgKE1MRSwgODAyLjE1LjkpIFNIT1VMRCBiZSB1c2VkIHRv IGRlcml2ZSBwZXItcGVlciBMMiBrZXlzLg0KDQogICBGb3IgbmV0d29ya3Mgd2hlcmUgdGhlcmUg aXMgYSBQQ0UgcHJlc2VudCBhbmQgaXQgd2lsbCBkbyBhbGwgc2NoZWR1bGUNCiAgIGNvbXB1dGF0 aW9uLCB0aGVuIHRoZSBvbmx5IHRydXN0IHJlbGF0aW9uc2hpcCBuZWNlc3NhcnkgaXMgYmV0d2Vl bg0KICAgdGhlIGluZGl2aWR1YWwgbm9kZSBhbmQgdGhlIFBDRSwgYW5kIGl0IE1BWSBiZSBhY2Nl cHRhYmxlIHRvIGhhdmUgYQ0KICAgbmV0d29yay13aWRlIEwyIGtleSBkZXJpdmVkIGluIHdheXMg c3VjaCBhcw0KICAgW0ktRC5waXJvLTZ0aXNjaC1zZWN1cml0eS1pc3N1ZXNdIGRlc2NyaWJlcyBp biBzZWN0aW9uID8uICBUaGUgdHJ1c3QNCiAgIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBQQ0Ug YW5kIHRoZSBqb2luaW5nIG5vZGUgZmxvd3MgZnJvbSB0aGUNCiAgIExEZXZJRCBjZXJ0aWZpY2F0 ZSBsb2FkZWQgYnkgdGhlIEpDRS4gIFdoZW4gdGhlIFBDRSBhbmQgSkNFIGFyZSBjby0NCiAgIGxv Y2F0ZWQsIHRoZSBleGlzdGluZyA2dG9wL0RUTFMgc2VjdXJpdHkgYXNzb2NpYXRpb24gY291bGQg YmUgcmV1c2VkLg0KDQoxMEIuMy4gIEpvaW4gUHJvdG9jb2wgY29ubmVjdGlvbiBzZXR1cA0KDQog ICBUaGUgaW50ZXJtZWRpYXRlIGxldmVsIGdvYWwgb2YgdGhlIGpvaW4gcHJvdG9jb2wgaXMgdG8g ZW5hYmxlIGEgSm9pbg0KICAgQ29vcmRpbmF0aW9uIEVudGl0eSAoSkNFKSB0byByZWFjaCBvdXQg dG8gdGhlIG5ldyBub2RlLCBhbmQgaW5zdGFsbA0KICAgdGhlIGNyZWRlbnRpYWxzIGRldGFpbGVk IGFib3ZlLiAgVGhlIEpDRSBtdXN0IGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG8NCiAgIHRoZSBqb2lu aW5nIG5vZGUgc28gdGhhdCB0aGUgam9pbmluZyBub2RlIHdpbGwga25vdyB0aGF0IGl0IGhhcw0K ICAgam9pbmVkIHRoZSBjb3JyZWN0IG5ldHdvcmssIGFuZCB0aGUgam9pbmluZyBub2RlIG11c3Qg YXV0aGVudGljYXRlDQogICBpdHNlbGYgdG8gdGhlIEpDRSBzbyB0aGF0IHRoZSBKQ0Ugd2lsbCBr bm93IHRoYXQgdGhpcyBub2RlIGJlbG9uZ3MgaW4NCiAgIHRoZSBuZXR3b3JrLiAgVGhpcyB0d28g d2F5IGF1dGhlbnRpY2F0aW9uIG9jY3VycyBpbiB0aGUgNnRvcC9Db0FQLw0KICAgRFRMUyBzZXNz aW9uIHRoYXQgaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGUgSkNFIGFuZCB0aGUgam9pbmluZw0K ICAgbm9kZS4NCg0KICAgW0ktRC5pZXRmLTZ0aXNjaC02dG9wLWludGVyZmFjZV0gcHJlc2VudHMg YSB3YXkgdG8gaW50ZXJmYWNlIHRvIGENCiAgIDZ0b3AgaW5mb3JtYXRpb24gbW9kZWwgKGRlZmlu ZWQgaW4gWUFORykuICBbSS1ELmlldGYtNnRpc2NoLWNvYXBdDQogICBleHBsYWlucyBob3cgdG8g YWNjZXNzIHRoYXQgaW5mb3JtYXRpb24gbW9kZWwgdXNpbmcgQ29BUC4gIFRoaXMNCiAgIGluZm9y bWF0aW9uIG1vZGVsIHdpbGwgaW5jbHVkZSBzZWN1cml0eSBhdHRyaWJ1dGVzIGZvciB0aGUgbmV0 d29yay4NCiAgIFRoZSBKQ0Ugd291bGQgdGhlcmVmb3JlIHJlYWNoIG91dCB0byB0aGUgam9pbmlu ZyBub2RlIGFuZCBzaW1wbHkNCiAgIHByb3Zpc2lvbiBhcHByb3ByaWF0ZSBzZWN1cml0eSBwcm9w ZXJ0aWVzIGludG8gdGhlIGpvaW5pbmcgbm9kZSwgbXVjaA0KICAgbGlrZSB0aGUgUENFIHdpbGwg cHJvdmlzaW9uIHNjaGVkdWxlcy4NCg0KICAgVGhpcyA2dG9wLWJhc2VkIHNlY3VyZSBqb2luIHBy b3RvY29sIGhhcyBkZWZpbmVkIGEgcHVzaCBtb2RlbCBmb3INCiAgIHNlY3VyaXR5IHByb3Zpc2lv bmluZyBieSB0aGUgSkNFLiAgVGhpcyBoYXMgYmVlbiBkb25lIGZvciB0aHJlZQ0KICAgcmVhc29u czoNCg0KICAgMSkgIDZ0aXNjaCBub2RlcyBhbHJlYWR5IGhhdmUgdG8gaGF2ZSBhIDZ0b3AgQ29B UCBzZXJ2ZXIgZm9yIHNjaGVkdWxlDQogICAgICAgcHJvdmlzaW5nDQoNCiAgIDIpICB0aGlzIHBl cm1pdHMgdGhlIEpDRSB0byBtYW5hZ2UgaG93IG1hbnkgbm9kZXMgYXJlIHRyeWluZyB0byBqb2lu DQogICAgICAgYXQgdGhlIHNhbWUgdGltZSwgYW5kIGxpbWl0IGhvdyBtdWNoIGJhbmR3aWR0aC9l bmVyZ3kgaXMgdXNlZCBmb3INCiAgICAgICB0aGUgam9pbiBvcGVyYXRpb24sIGFuZCBhbHNvIGZv ciB0aGUgSkNFIHRvIHByaW9yaXRpemUgdGhlIGpvaW4NCiAgICAgICBvcmRlciBmb3Igbm9kZXMu DQoNCiAgIDMpICBtYWtpbmcgdGhlIEpDRSBpbml0aWF0ZSB0aGUgRFRMUyBjb25uZWN0aW9uIHNp Z25pZmljYW50bHkNCiAgICAgICBzaW1wbGllcyB0aGUgY2VydGlmaWNhdGUgY2hhaW5zIHRoYXQg bXVzdCBiZSBleGNoYW5nZWQgYXMgdGhlDQogICAgICAgbW9zdCBjb25zdHJhaW5lZCBzaWRlICh0 aGUgam9pbmluZyBub2RlKSBwcm92aWRlcyBpdCdzDQogICAgICAgY3JlZGVudGlhbHMgZmlyc3Qs IGFuZCBsZXRzIHRoZSBsZXNzIGNvbnN0cmFpbmVkIEpDRSBmaWd1cmUgb3V0DQogICAgICAgd2hh dCBraW5kIG9mIGNlcnRpZmljYXRlIGNoYWluIHdpbGwgYmUgcmVxdWlyZWQgdG8gYXV0aGVudGlj YXRlDQogICAgICAgdGhlIEpDRSB0byB0aGUgam9pbmluZyBub2RlLiAgSW4gRUFQLVRMUy84MDIu MXggc2l0dWF0aW9ucywgdGhlDQogICAgICAgVExTIGNoYW5uZWwgaXMgY3JlYXRlZCBpbiB0aGUg b3Bwb3NpdGUgZGlyZWN0aW9uLCBhbmQgaXQgd291bGQNCiAgICAgICBoYXZlIHRvIGNvbXBsZXRl IGluIGEgdGVudGF0aXZlIHdheSwgYW5kIHRoZW4gZnVydGhlcg0KICAgICAgIGF1dGhvcml6YXRp b24gb2NjdXIgaW4tYmFuZC4NCg0KMTBCLjQuICBFbmQgdG8gRW5kIGNvbnNpZGVyYXRpb25zIGZv ciBKb2luIFByb3RvY29sDQoNCiAgIEluIG9yZGVyIGZvciBhIDZ0b3AvRFRMUy9Db0FQIGNvbm5l Y3Rpb24gdG8gb2NjdXIgYmV0d2VlbiB0aGUgSkNFIGFuZA0KICAgdGhlIGpvaW5pbmcgbm9kZSwg dGhlcmUgbmVlZHMgdG8gYmUgZW5kLXRvLWVuZCBJUHY2IGNvbm5lY3Rpdml0eQ0KICAgYmV0d2Vl biB0aG9zZSB0d28gZW50aXRpZXMuICBUaGUgam9pbmluZyBub2RlIHdpbGwgbm90IHBhcnRpY2lw YXRlIGluDQogICB0aGUgcm91dGUtb3ZlciBSUEwgbWVzaCwgYnV0IHJhdGhlciB3aWxsIGJlIHNl ZW4gYnkgdGhlIG5ldHdvcmsgYXMNCiAgIGJlaW5nIGEgNmxvd3BhbiBvbmx5IGxlYWYtbm9kZS4N Cg0KICAgVGhlIGpvaW5pbmcgbm9kZSBzZW5kcyB0cmFmZmljIHRvIHRoZSBqb2luIGFzc2lzdGFu dCwgd2hpY2ggZm9yd2FyZHMNCiAgIGl0IHVzaW5nIHRoZSBub3JtYWwgUlBMIERPREFHIHVwd2Fy ZHMgcm91dGVzLCBhbmQgd2hpY2ggd2lsbCByZWFjaA0KICAgdGhlIEpDRSB1c2luZyByZWd1bGFy IHJvdXRpbmcuDQoNCiAgIFRoZSBjaGFsbGVuZ2UgaXMgZ2V0dGluZyBjb25uZWN0aXZpdHkgZnJv bSB0aGUgSkNFIHRvIHRoZSBqb2luaW5nDQogICBub2RlLCBhcyB0aGUgRE9EQUcgd2lsbCBoYXZl IG5vIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgbm9kZS4NCiAgIEluc3RlYWQsIHRoZSBKQ0Ugd2ls bCB1c2UgbG9vc2Utc291cmNlIHJvdXRlcyB0byBhZGRyZXNzIHBhY2tldHMNCiAgIGZpcnN0IHRv IHRoZSBKb2luIEFzc2lzdGFudCwgd2hpY2ggd2lsbCB0aGVuIGZvcndhcmQgdG8gdGhlIGpvaW5p bmcNCiAgIG5vZGUuICBUaGlzIGhhcyBhbiBpbnRlcmFjdGlvbiB3aXRoIHRoZSAoc3RyaWN0KSBz b3VyY2Ugcm91dGVzIHVzZWQNCiAgIGJ5IG5vbi1zdG9yaW5nIERPREFHcyB3aGljaCB3b3VsZCBi ZSB1c2VkIGJ5IHRoZSA2TEJSIHRvIHJlYWNoIHRoZQ0KICAgSm9pbiBBc3Npc3RhbnQuDQoNCiAg IFRoZXJlIGFyZSBzb21lIGFsdGVybmF0aXZlcyB0byBoYXZpbmcgZnVsbCBlbmQgdG8gZW5kIGNv bm5lY3Rpdml0eQ0KICAgd2hpY2ggYXJlIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbi4NCg0KMTIuMS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOiBhbHRl cm5hdGl2ZXMgdG8gc291cmNlIHJvdXRlcw0KDQogICBUaGlzIGdvZXMgaW50byBzZWN1cml0eS1j b25zaWRlcmF0aW9ucyBzZWN0aW9uDQoNCiAgIEEgbnVtYmVyIG9mIGFsdGVybmF0aXZlcyB3ZXJl IGNvbnNpZGVyZWQgZm9yIGNyZWF0aW5nIGVuZCB0byBlbmQNCiAgIGNvbm5lY3Rpdml0eSBiZXR3 ZWVuIHRoZSBqb2luaW5nIG5vZGUgYW5kIHRoZSBKQ0UsIGJ1dCB3ZXJlIHJlamVjdGVkLg0KDQog ICAoMSkgIElQSVAgdHVubmVsIGJldHdlZW4gSm9pbiBBc3Npc3RhbnQgYW5kIEpDRQ0KDQogICAo MikgIHVzaW5nIHN0cmFpZ2h0IFJQTCByb3V0aW5nOiB0aGUgSm9pbiBBc3Npc3RhbnQgc2VuZHMg YSBEQU8NCg0KICAgKDMpICB1c2luZyBhIHNlcGFyYXRlIFJQTCBET0RBRyBmb3Igam9pbiB0cmFm ZmljDQoNCiAgICg0KSAgZXN0YWJsaXNoaW5nIGEgc3BlY2lmaWMgbXVsdGktaG9wIDZ0aXNjaCB0 cmFjayBmb3Igam9pbiB0cmFmZmljDQogICAgICBmb3IgZWFjaCBKb2luIEFzc2lzdGFudA0KDQox Mi4xLjEuMS4gIElQSVAgdHVubmVsDQoNCiAgIFRoaXMgbWVjaGFuaXNtIHJlcXVpcmVzIDQwIGJ5 dGVzIG92ZXJoZWFkIHBlciBwYWNrZXQsIGFuZCBtYXkgcmVxdWlyZQ0KICAgc3BlY2lmaWMgc3Rh dGUgdG8gYmUgY3JlYXRlZCBvbiB0aGUgSm9pbiBBc3Npc3RhbnQsIG9yIG1heSBvcGVuIHRoZQ0K ICAgbmV0d29yayB1cCB0byBhIHJlc291cmNlIGV4aGF1c3Rpb24gYnkgbWFsaWNpb3VzIGpvaW4g bm9kZXMuDQoNCiAgIFRoaXMgbWVjaGFuaXNtIHdhcyByZWplY3RlZCBvbiBkdWUgdG8gYnl0ZSBj b3VudCwgYmVjYXVzZSBpdCB3b3VsZA0KICAgcmVxdWlyZSBjb2RlIG9ubHkgbmVlZGVkIGZvciBq b2luLCBhbmQgYmVjYXVzZSBkb2luZyBpdCBzZWN1cmVseSBtYXkNCiAgIHJlcXVpcmUgYSBwZXIt dHVubmVsIHN0YXRlIHRvIGJlIG1haW50YWluZWQgb24gdGhlIGpvaW4gYXNzaXN0YW50Lg0KDQox Mi4xLjEuMi4gIGpvaW4gZXhpc3RpbmcgRE9EQUcNCg0KICAgVGhpcyBtZWNoYW5pc20gaXMgdG8g anVzdCBoYXZlIHRoZSBuZXcgbm9kZSBqb2luIHRoZSBET0RBRyBhcyBhIGxlYWYNCiAgIG5vZGUu ICBUaGUgam9pbiBhc3Npc3RhbnQgd291bGQgaXNzdWUgYSBEQU8gZm9yIHRoZSBuZXcgbm9kZS4g IElmIGENCiAgIHN0b3JpbmcgRE9EQUcgd2FzIHVzZWQsIHRoaXMgd291bGQgZGlyZWN0bHkgY29z dCBzdGF0ZSBpbiBhbGwgcGFyZW50DQogICBub2RlcyBvZiB0aGUgSm9pbiBBc3Npc3RhbnQsIHN1 YmplY3RpbmcgdGhlIGxvd2VyLXJhbmsgcGFydHMgb2YgdGhlDQogICBuZXR3b3JrIHRvIHNpZ25p ZmljYW50IGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MuDQoNCiAgIE9uIGEgbm9uLXN0b3Jpbmcg RE9EQUcgdGhlIHNpdHVhdGlvbiBpcyBzaWduaWZpY2FudGx5IGJldHRlcjogbm8NCiAgIHN0YXRl IGlzIGNyZWF0ZWQgYnkgdGhlIHByZXNlbmNlIG9mIHRoZSBsZWFmIG5vZGUgZXhjZXB0IGluIHRo ZSA2TEJSLA0KICAgd2hlcmUgYXZhaWxhYmxlIHJlc291cmNlcyBtYXkgYmUgaGlnaGVyLg0KDQog ICBUaGlzIG1lY2hhbmlzbSB3YXMgcmVqZWN0ZWQgaW4gZmF2b3VyIG9mIHRoZSBsb29zZSBzb3Vy Y2Ugcm91dGVkDQogICBvcHRpb24gYXMgdGhpcyB0aGUgbG9vc2Ugc291cmNlIHJvdXRlZCBvcHRp b24gYWx3YXlzIHdvcmtzIGV2ZW4gZm9yDQogICBzdG9yaW5nIERPREFHcywgYW5kIGlzIG90aGVy d2lzZSBleGFjdGx5IGVxdWl2YWxlbnQgaW4gdGVybXMgb2YNCiAgIG5ldHdvcmsgYmFuZHdpZHRo IGNvc3QuDQoNCjEyLjEuMS4zLiAgam9pbiBhIERPRE9BRyBmb3Igam9pbmluZw0KDQogICBPbmUg b3B0aW9uIHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbSBvZiByZXNvdXJjZSBjb25zdW1wdGlvbiBp biB0aGUNCiAgIHN0b3JpbmcgRE9EQUcgY2FzZSBpcyB0byB1c2UgYSBzZWNvbmQgRE9EQUcuDQoN CiAgIFRoaXMgbWVjaGFuaXNtIHdhcyByZWplY3RlZCBhcyBpdCBjb25zdW1lcyByZXNvdXJjZXMg aW4gYWxsIG5vZGVzIGZvcg0KICAgdGhlIHNlY29uZCBET0RBRywgYW5kIG1hbnkgaW1wbGVtZW50 YXRpb25zIHN1cHBvcnQgb24gYSBzaW5nbGUgRE9EQUcuDQogICBXaGlsZSBzdG9yaW5nIERPREFH cyBoYXZlIGEgbGlnaHRlciBuZXR3b3JrIGltcGFjdCB0aGFuIG5vbi1zdG9yaW5nDQogICBvbmVz IChkdWUgdG8gdGhlIGxhY2sgb2Ygc291cmNlIHJvdXRlcyksIHRoZSBQQ0UgY2FuIGNvbnRyb2wg aG93IG11Y2gNCiAgIG5ldHdvcmsgYmFuZHdpZHRoIGNhbiBiZSB3YXN0ZWQgYnkgbWFsaWNpb3Vz IGpvaW4gbm9kZXMgdXNpbmcgdGhlDQogICByZWd1bGFyIDZ0aXNjaCBtZWNoYW5pc21zLCBhbmQg dGhpcyBjYW4gYmUgdHVuZWQuICBBIHNlY29uZCBET0RBRw0KICAgd291bGQgYmUgYSBzdW5rIGNv c3Qgd2l0aCBubyB0dW5pbmcgcG9zc2libGUuDQoNCjEyLjEuMS40LiAgY3JlYXRlIDZ0aXNjaCB0 cmFjayB0byBmb3JtIG1lc2gtdW5kZXINCg0KICAgVGhpcyBtZWNoYW5pc20gd291bGQgdXNlIDZ0 aXNjaCB0cmFja3Mgc28gdGhhdCB0cmFmZmljIGZyb20gdGhlIEpDRQ0KICAgd291bGQgYmUgc3dp dGNoZWQgZnJvbSA2TEJSIHRvIGpvaW4gbm9kZS4gIEEgdHJhY2sgd291bGQgYmUgcmVxdWlyZWQN CiAgIHRvIGVhY2ggam9pbiBhc3Npc3RhbnQuICBUaGlzIGlzIGFuIG9wdGltaXplZCBmb3JtIG9m IHNvdXJjZSByb3V0aW5nLg0KDQogICBUaGlzIG1lY2hhbmlzbSB3YXMgbm90IHJlamVjdGVkLCBy YXRoZXIgaXQgd2FzIG9ic2VydmVkIHRoYXQgaXQgbWF5DQogICBiZSBhcHBsaWVkIHRvIGFueSBt ZWNoYW5pc20gdGhhdCB1c2VzIHNvdXJjZSByb3V0aW5nLCBhbmQgaXMgYW4NCiAgIG9wdGltaXph dGlvbjsgaXQgaGFzIGEgY2VydGFpbiBjb3N0IGluIHRoZSBmb3JtIG9mIGludGVybWVkaWFyeSBu b2RlDQogICBzdGF0ZSwgYnV0IHRoYXQgdGhpcyBzdGF0ZSBpcyBub3QgY3JlYXRlZCBieSBhIG1h bGljaW91cyBqb2luIG5vZGUsDQogICByYXRoZXIgaXQgaXMgY3JlYXRlZCBieSB0aGUgUENFLg0K DQoxMEIuNS4gIEpvaW4gbm9kZSBkaXNjb3ZlcnkgbWVjaGFuaXNtDQoNCiAgIENvbnRpbnVpbmcg dG8gd29yayBiYWNrd2FyZHMsIGluIG9yZGVyIHRoZSBKQ0UgcmVhY2ggb3V0IHRvIHByb3Zpc2lv bg0KICAgdGhlIEpvaW5pbmcgTm9kZSwgaXQgbmVlZHMgdG8ga25vdyB0aGF0IHRoZSBuZXcgbm9k ZSBpcyBwcmVzZW50Lg0KICAgVGhpcyBpcyBkb25lIGJ5IHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhl IDZsb3dQQU4gQWRkcmVzcyBSZXNvbHV0aW9uDQogICBPcHRpb24gKEFSTykgKHNlY3Rpb24gNC4x IFtSRkM2Nzc1XSkuICBUaGUgQVJPIGNhdXNlcyB0aGUgbmV3IGFkZHJlc3MNCiAgIHRvIGFsc28g YmUgc2VudCB1cCB0byB0aGUgNkxCUiBmb3IgZHVwbGljYXRlIGRldGVjdGlvbiB1c2luZyB0aGUg REFSLw0KICAgREFDIG1lY2hhbmlzbS4gIFRoZSA2TEJSIHNpbXBseSBuZWVkcyB0byB0ZWxsIHRo ZSBKQ0UgYWJvdXQgdGhpcy4gIEENCiAgIG5ldyBwcm90b2NvbCBtYXkgYmUgcmVxdWlyZWQgZm9y IHRoZSBzaXR1YXRpb24gd2hlcmUgdGhlIEpDRSwgUENFIGFuZA0KICAgNkxCUiBhcmUgbm90IGNv LWxvY2F0ZWQ7IGl0IG1heSBiZSB0aGF0IHRoaXMgcHJvdG9jb2wgY291bGQgYmUgc2ltcGx5DQog ICBhIERBUiBpbiBzb21lIGVuY2Fwc3VsYXRpb24uICBUaGUgZGV0YWlscyBvZiB0aGlzIGFyZSBj dXJyZW50bHkgb3V0DQogICBvZiBzY29wZSBmb3IgdGhlIGFyY2hpdGVjdHVyZSwgYXMgdGhleSBh ZmZlY3QgaW50ZXJvcGVyYWJpbGl0eQ0KICAgYmV0d2VlbiBkaWZmZXJlbnQgdmVuZG9ycyBvZiBK Q0UvNkxCUi9QQ0UgcmF0aGVyIHRoYW4NCiAgIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUg YXNzaXN0YW5jZS9vZmZsb2FkIGluZnJhc3RydWN0dXJlLCBhbmQNCiAgIHRoZSBjb250cmFpbmVk IG5vZGVzLiAgRnV0dXJlIHdvcmsgbWF5IHNwZWNpZnkgdGhpcyBwYXJ0Lg0KDQogICBJbiBhZGRp dGlvbiB0byBuZWVkaW5nIHRvIGtub3cgdGhlIGpvaW5pbmcgZGV2aWNlcyBhZGRyZXNzIGZyb20g dGhlDQogICBEQVIvTlMsIHRoZSBKQ0UgYWxzbyBuZWVkcyB0byBrbm93IHRoZSBqb2luaW5nIG5v ZGUncyBJRGV2SUQuICBUaGlzDQogICBpcyB0byBkZXRlcm1pbmUgaWYgdGhlIG5vZGUgc2hvdWxk IGV2ZW4gZ2V0IGFueSBhdHRlbnRpb24uICBBdCB0aGlzDQogICBwb2ludCwgdGhlIElEZXZJRCBj YW4gYmUgZm9yZ2VkLCBpdCB3aWxsIGJlIGF1dGhlbnRpY2F0ZWQgZHVyaW5nIHRoZQ0KICAgc2V0 dXAgb2YgdGhlIDZ0b3AgY29udHJvbCBwcm90b2NvbCBpbiB0aGUgRFRMUyBjZXJ0aWZpY2F0ZSBl eGNoYW5nZS4NCiAgIElmIHRoZSBzZXJpYWxOdW1iZXIgYXR0cmlidXRlIG9mIHRoZSBJRGV2SUQg aXMgbGVzcyB0aGFuIDY0IGJpdHMsDQogICB0aGVuIGl0IGlzIHBvc3NpYmxlIHRoYXQgaXQgY291 bGQgYmUgcGxhY2VkIGludG8gdGhlIEVVSS02NCBvcHRpb24gb2YNCiAgIHRoZSBBUk8sIG9yIHRo ZSBPVUkgb2YgdGhlIFtJLUQudGh1YmVydC02bG8tcmZjNjc3NS11cGRhdGUtcmVxc10NCiAgIEVB Uk8uICBUaGUgSkNFIG5lZWRzIHRvIGtub3cgdGhlIGpvaW5pbmcgbm9kZSdzIHNlcmlhbE51bWJl ciB0byBrbm93DQogICBpZiB0aGlzIGlzIGRldmljZSB0aGF0IGl0IHNob3VsZCBldmVuIGF0dGVt cHQgdG8gcHJvdmlzaW9uOyBhbmQgaWYNCiAgIHNvLCBpdCBtYXkgbmVlZCB0byByZXRyaWV2ZSBh biBhcHByb3ByaWF0ZSBjZXJ0aWZpY2F0ZSBjaGFpbiAoc2VlDQogICBbSS1ELnJpY2hhcmRzb24t NnRpc2NoLWlkZXZpZC1jZXJ0XSkgZnJvbSB0aGUgRmFjdG9yeSBpbiBvcmRlciBmb3INCiAgIHRo ZSBKQ0UgdG8gcHJvdmUgaXQgaXMgdGhlIGxlZ2l0aW1hdGUgb3duZXIgb2YgdGhlIGpvaW5pbmcg bm9kZS4NCg0KICAgTmVpdGhlciA4MDIuMUFSIG5vciBbUkZDNTI4MF0gcHJvdmlkZSBhbnkgc3Ry dWN0dXJlIGZvciB0aGUNCiAgIHNlcmlhbE51bWJlciwgZXhjZXB0IHRoYXQgdGhleSBhcmUgcG9z aXRpdmUgaW50ZWdlcnMgb2YgdXAtdG8gMjANCiAgIG9jdGV0cyBpbiBzaXplIChudW1iZXJzIHVw IHRvIDJeMTYwKS4gIFRoaXMgc3BlY2lmaWNhdGlvbiB3b3VsZA0KICAgcmVxdWlyZSB0aGF0IHRo ZSBzZXJpYWxOdW1iZXIgZW5jb2RlZCBpbiB0aGUgSURldklEIGJlIHRoZSBzYW1lIGFzDQogICB0 aGUgRVVJLTY0IHVzZWQgYnkgdGhlIGRldmljZS4gIFNvbWUgY29uc2lkZXJhdGlvbiBuZWVkcyB0 byBiZSBnaXZlbg0KICAgYXMgdG8gd2hldGhlciB0aGVyZSBhcmUgcHJpdmFjeSBjb25zaWRlcmF0 aW9ucyB0byBkb2luZyB0aGlzOiBhbnkNCiAgIG9ic2VydmVyIHRoYXQgY2FuIHNlZSB0aGUgam9p biB0cmFmZmljLCBjYW4gYWxzbyBzZWUgdGhlIHNvdXJjZSBNQUMNCiAgIGFkZHJlc3Mgb2YgdGhl IG5vZGUgYXMgd2VsbC4NCg0KICAgUHJpb3IgdG8gYmVpbmcgYWJsZSB0byBhbm5vdW5jZSBpdHNl bGYgaW4gYSBOUywgdGhlIGpvaW5pbmcgbm9kZQ0KICAgbmVlZHMgdG8gZmluZCB0aGUgSm9pbiBO ZXR3b3JrLiAgVGhpcyBpcyBkb25lIGJ5IGxpc3RlbmluZyB0byBhbg0KICAgZXh0ZW5kZWQgYmVh Y29uIHdoaWNoIGFyZSBicm9hZGNhc3QgaW4gZGVzaWduYXRlZCBzbG90ZnJhbWVzIGJ5IEpvaW4N CiAgIEFzc2lzdGFudHMuICBUaGUgRXh0ZW5kZWQgQmVhY29uIHByb3ZpZGVzIGEgd2F5IGZvciB0 aGUgSm9pbmluZyBOb2RlDQogICB0byBzeW5jaHJvbml6ZSBpdHNlbGYgdG8gdGhlIG92ZXJhbGwg dGltZXNsb3Qgc2NoZWR1bGUgYW5kIHByb3ZpZGVzDQogICBhbiBBbG9oYSBwZXJpb2QgaW4gd2hp Y2ggdGhlIEpvaW5pbmcgTm9kZSBjYW4gc2VuZCBhIFJvdXRlcg0KICAgU29saXRpY2lhdGlvbiwg YW5kIHJlY2VpdmUgYW4gYXBwcm9wcmlhdGUgUm91dGVyIEFkdmVydGlzZW1lbnQgZ2l2aW5nDQog ICB0aGUgSm9pbmluZyBOb2RlIGEgcHJlZml4IGFuZCBkZWZhdWx0IHJvdXRlIHRvIHdoaWNoIHRv IHNlbmQgam9pbg0KICAgdHJhZmZpYy4NCg0KICAgSXQgbWF5IGJlIHBvc3NpYmxlIHRvIGVsaW1p bmF0ZSBhIG1lc3NhZ2UgZXhjaGFuZ2UgaWYgc3BhY2UgZm9yIGENCiAgIFJvdXRlciBBZHZlcnRp c2VtZW50IGNhbiBiZSBmb3VuZCBhcyBwYXJ0IG9mIHRoZSBKb2luIE5ldHdvcmsNCiAgIEV4dGVu ZGVkIEJlYWNvbi4gIFRoaXMgRW5oYW5jZWQgQmVhY29uIHdvdWxkIGJlIGRpc3RpbmN0IHRvIHRo ZSBKb2luDQogICBOZXR3b3JrLCBhbmQgd291bGQgYmUgZW5jcnlwdGVkIHdpdGggdGhlIHdlbGwt a25vd24gSm9pbiBOZXR3b3JrIGtleS4NCg0KMTBCLjUuMS4gIHByZWZpeGVzIHRvIHVzZSBmb3Ig am9pbiB0cmFmZmljDQoNCiAgIFdoYXQgcHJlZml4IHdvdWxkIHRoZSBqb2luaW5nIG5vZGUgZm9y IGNvbW11bmljYXRpb24/ICBUaGVyZSBhcmUNCiAgIHRocmVlIG9wdGlvbnM6DQoNCiAgICgxKSAg anVzdCB1c2UgbGluay1sb2NhbCBhZGRyZXNzZXMgKHRoaXMgbWF5IHJlcXVpcmUgdGhhdCBzb21l DQogICAgICB0cmFmZmljIGJldHdlZW4gNkxCUiBhbmQgSkNFIGJlIElQSVAgdHVubmVsZWQpDQoN CiAgICgyKSAgdXNlIGEgcHJlZml4IHNwZWNpZmljYWxseSBmb3Igam9pbiB0cmFmZmljIChtYXkg YmUgZWFzaWVyIHdpdGggYQ0KICAgICAgam9pbi1vbmx5IERPREFHKQ0KDQogICAoMykgIHVzZSB0 aGUgc2FtZSBwcmVmaXggYXMgdGhlIHJlc3Qgb2YgdGhlIHRyYWZmaWMgKG1heSByZXF1aXJlIG1v cmUNCiAgICAgIGNvbXBsZXggQUNMcywgYW5kIGxlYWtzIGluZm9ybWF0aW9uIHRvIGF0dGFja2Vy cykNCg0KICAgVGhlIHNpbXBsZXN0IG1ldGhvZCBpcyB0byB1c2UgdGhlIGxpbmstbG9jYWwgYWRk cmVzc2VzIGZvciB0aGUgNnRvcA0KICAgY29ubmVjdGlvbiwgYW5kIHRoZSBjb3N0IG9mIGFuIElQ SVAgdHVubmVsIGJldHdlZW4gdGhlIHVuY29uc3RyYWluZWQNCiAgIDZMQlIgYW5kIHRoZSBKQ0Ug aXMgbm90IGNvbnNpZGVyZWQgc2lnbmlmaWNhbnQuDQoNCg0KDQotLQ0KTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNh Pj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0N Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CjZ0aXNjaC1zZWN1cml0eSBtYWlsaW5nIGxpc3QNCjZ0aXNjaC1zZWN1cml0eUBpZXRmLm9yZzxt YWlsdG86NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby82dGlzY2gtc2VjdXJpdHkNCg0K --_000_E045AECD98228444A58C61C200AE1BD848A4F742xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIGxvdCBvZiB0ZXh0 LCBidXQgcmVhZGluZyBpdCBJIGhhdmUgdHJvdWJsZSBzaW1wbGlmeWluZyBtdWNoLiBBIGJpdCBv ZiB0cmltbWluZyBtYXkgaGVscCwgYW5kIHRoaXMgd291bGQganVzdGlmeSB0aGF0IHdlIG1haW50 YWluIGFuZCBleHRlbmQgTWljaGFlbOKAmXMNCiBkb2MgZm9yIHRoZSBuZXh0IHJvdW5kLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGRvIG90aGVycyB0aGluaz88L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA2 dGlzY2ggW21haWx0bzo2dGlzY2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+U3ViaXIgRGFzPGJyPg0KPGI+U2VudDo8L2I+IG1lcmNyZWRpIDEyIG5vdmVtYnJlIDIwMTQg MTM6MTE8YnI+DQo8Yj5Ubzo8L2I+IE1pY2hhZWwgUmljaGFyZHNvbjxicj4NCjxiPkNjOjwvYj4g NnRpc2NoQGlldGYub3JnOyA2dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFs2dGlzY2hdIFs2dGlzY2gtc2VjdXJpdHldIHByb3Bvc2VkIHNlY3VyaXR5IHRl eHQgZm9yIGFyY2hpdGVjdHVyZSBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5NaWNoYWVsLCA8YnI+DQpBcmUgeW91IHN1Z2dlc3RpbmcgdG8gYWRkIHRoaXMgZW50aXJlIHRl eHQgdG8gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudD8mbmJzcDsgSSBhbSBhZnJhaWQgdGhhdCB0 aGUgdGV4dCBpcyBtb3JlIHRoYW4gYXJjaGl0ZWN0dXJlIGVsZW1lbnRzIGFuZCByZXF1aXJlbWVu dHM/Jm5ic3A7IEkgd2FzIG5vdCBhYmxlIHRvIGF0dGVuZCB0aGUgbGFzdCBUdWVzZGF5J3MgY2Fs bC4gWW91IGFyZSBjbGFpbWluZyB0aGF0IHRoZSBhZCBob2Mgc2VjdXJpdHkgdGVhbSByZWNvbW1l bmRlZA0KIHRoaXMgdGV4dCB0byB0aGUgV0cgZm9yIGNvbnNpZGVyYXRpb24uIElzIHRoaXMgaGFw cGVuZWQgZHVyaW5nIGxhc3QgY2FsbD8gSSB1bmRlcnN0YW5kIHRoYXQgeW91IGRpZG4ndCBnZXQg dGltZSB5ZXQgdG8gcHVibGlzaCB0aGUmbmJzcDsgbWludXRlcy4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tU3ViaXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92IDEyLCAyMDE0IGF0IDExOjUwIEFN LCBNaWNoYWVsIFJpY2hhcmRzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptY3ImIzQzO2lldGZAc2Fu ZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpUaGlzIHRleHQgaXMgdGhlIGFyY2hpdGVjdHVyZSBy ZXN1bHRzIG9mIHRoZSBzZWN1cmUgKHplcm8tdG91Y2gpIGRlc2lnbiB0ZWFtLjxicj4NClRoZSBy ZWFsaXphdGlvbiB0aGF0IHdlIHNob3VsZCB1c2UgbG9vc2Ugc291cmNlIHJvdXRlcyBpcyBkdWUg dG8gUGFzY2FsLjxicj4NCjxicj4NCkkgYmVsaWV2ZSB0aGlzIGdvZXMgaW50byBhIG5ldyBzZWN0 aW9uIGJldHdlZW4gMTAuIENlbnRyYWxpemVkIHZzLjxicj4NCmFuZCAxMS4gSUFOQSBDb25zaWRl cmF0aW9ucy4mbmJzcDsgSW50ZXJzcGVyc2VkIGlzIHNvbWUgdGV4dCB0aGF0IEkgdGhpbmsgZ29l cyBpbiB0byBzZWN0aW9uPGJyPg0KMTIuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLjxicj4NCjxi cj4NCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGUgaGlzdG9yeSBvZiB0aGlzIHRleHQsIG9y IHNvbWUgYWRkaXRpb25hbCBtb3JlIGltcGxlbWVudGF0aW9uPGJyPg0Kc2lkZSBpZGVhcywgdGhl biBJIHJlY29tbWVuZCByZXZpZXdpbmcgdGhlIGRpZmY8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LXJpY2hhcmRz b24tNnRpc2NoLS1zZWN1cml0eS02dG9wLTAzJmFtcDtkaWZmdHlwZT0tLWh0bWwmYW1wO3N1Ym1p dD1HbyUyMSZhbXA7dXJsMj1kcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC0tc2VjdXJpdHktNnRvcC0w NCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0 LXJpY2hhcmRzb24tNnRpc2NoLS1zZWN1cml0eS02dG9wLTAzJmFtcDtkaWZmdHlwZT0tLWh0bWwm YW1wO3N1Ym1pdD1HbyUyMSZhbXA7dXJsMj1kcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC0tc2VjdXJp dHktNnRvcC0wNDwvYT48YnI+DQo8YnI+DQo8YnI+DQoxMEIuJm5ic3A7IEFyY2hpdGVjdHVyYWwg cmVxdWlyZW1lbnRzIG9mIGpvaW4gcHJvdG9jb2w8YnI+DQo8YnI+DQoxMEIuMS4mbmJzcDsgRW50 aXRpZXMgaW52b2x2ZXMgaW4gdGhlIGpvaW4gcHJvY2Vzczxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtUaGUgZm9sbG93aW5nIGFjdG9ycyBhcmUgaW52b2x2ZWQ6IHRoZXJlIGlzIGEgbmV3IGpvaW5p bmcgbm9kZS4mbmJzcDsgSXQ8YnI+DQombmJzcDsgJm5ic3A7aXMgKHJhZGlvKSBhZGphY2VudCB0 byB0aGUgam9pbiBhc3Npc3RhbnQuJm5ic3A7IFRoZSBqb2luIGFzc2lzdGFudCBpczxicj4NCiZu YnNwOyAmbmJzcDtwYXJ0IG9mIHRoZSBwcm9kdWN0aW9uIG5ldHdvcmssIGFuZCBwYXJ0aWNpcGF0 ZXMgaW4gb25lIG9yIG1vcmU8YnI+DQombmJzcDsgJm5ic3A7RE9EQUdzLCBzdWNoIHRoYXQgaXQg aXMgcmVhY2hhYmxlIGZyb20gdGhlIDZMQlIsIGFuZCB0aGUgSkNFLjxicj4NCjxicj4NCjEwQi4y LiZuYnNwOyBKb2luIFByb3RvY29sIGRlbGl2ZXJhYmxlczxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtUaGlzIHNlY3Rpb24gd29ya3MgZnJvbSB0aGUgdWx0aW1hdGUgZ29hbCwgYW5kIGdvZXMgYmFj a3dhcmRzIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3ByZXJlcXVpc2l0ZSBhY3Rpb25zLiZuYnNwOyAo U2VjdGlvbiA2IHByZXNlbnRzIHRoZSBwcm90b2NvbCBmcm9tPGJyPg0KJm5ic3A7ICZuYnNwO2Jl Z2lubmluZyB0byBlbmQgb3JkZXIpPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSB1bHRpbWF0 ZSBnb2FsIG9mIHRoZSBqb2luIHByb3RvY29sIGlzIHRvIHByb3ZpZGUgYSBuZXcgbm9kZSB3aXRo PGJyPg0KJm5ic3A7ICZuYnNwO2EgbG9jYWxseSBzaWduaWZpY2FudCBzZWN1cml0eSBjcmVkZW50 aWFscyB0aGF0IGl0IGlzIGFibGUgdG8gdGFrZTxicj4NCiZuYnNwOyAmbmJzcDtwYXJ0IGluIHRo ZSBuZXR3b3JrIGRpcmVjdGx5LiZuYnNwOyBUaGUgY3JlZGVudGlhbHMgbWF5IHZhcnkgYnk8YnI+ DQombmJzcDsgJm5ic3A7ZGVwbG95bWVudC4mbmJzcDsgVGhleSBjYW4gYmUgb25lIG9mOjxicj4N Cjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsxKSZuYnNwOyBhIG5ldHdvcmstd2lkZSBzaGFyZWQg c3ltbWV0cmljIGtleSAodGhpcyBpcyB0aGUgcHJvZHVjdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO25ldHdvcmsga2V5LCBvciBNYXN0ZXJLZXkpPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOzIpJm5ic3A7IGEgbG9jYWxseSBzaWduaWZpY2FudCAob25lLWxldmVsIG9ubHkpIDgw Mi4xMUFSIHR5cGUgTERldklEPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2VydGlm aWNhdGUgKHdoaWNoIGFsbG93cyBpdCB0byBuZWdvdGlhdGUgYSBwYWlyLXdpc2Uga2V5cyk8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7T25lIG9mIHRoZXNlIHR3byBpdGVtcyBpcyBkZWxpdmVyZWQg YnkgSkNFIHRvIHRoZSBqb2luaW5nIG5vZGUgdXNpbmc8YnI+DQombmJzcDsgJm5ic3A7dGhlIDZ0 b3AgcHJvdG9jb2wuJm5ic3A7IFRoYXQgaXMsIHRoZSBKQ0UgcHJvdmlzaW9ucyB1c2luZyBhIHNl Y3VyZTxicj4NCiZuYnNwOyAmbmJzcDsmcXVvdDtub3J0aGJvdW5kJnF1b3Q7IGludGVyZmFjZS4m bmJzcDsgVGhlIGF1dGhlbnRpY2F0aW9uIG9mIHRoaXMgaW50ZXJmYWNlIHRoZTxicj4NCiZuYnNw OyAmbmJzcDtzdWJqZWN0IG9mIHRoZSBKb2luIFByb3RvY29sIGFzIGV4cGxhaW5lZCBiZWxvdy48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIGFib3ZlIGNyZWRlbnRpYWwgYXJlIHVzZWQgZm9y IGF1dGhlbnRpY2F0aW9uIHRvIGdlbmVyYXRlIHBlci1wZWVyPGJyPg0KJm5ic3A7ICZuYnNwO0wy LCB1c2luZyBhIGtleSBleGNoYW5nZSBwcm90b2NvbC4mbmJzcDsgVGhlIGNob2ljZSBvZiBrZXkg ZXhjaGFuZ2U8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wsIGFuZCB3aGF0IGtpbmQgb2YgbGlu ayBhbmQgbXVsdGljYXN0IGtleWluZyBuZWVkcyB0byBiZSBkb25lPGJyPg0KJm5ic3A7ICZuYnNw O2lzIGFsc28gcHJvdmlzaW9uZWQgYnkgdGhlIEpDRS4mbmJzcDsgVGhlcmUgYXJlIGEgbnVtYmVy IG9mIG9wdGlvbnMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO2RvaW5nIHRoaXMsIHN1Y2ggYXM6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOzEpJm5ic3A7IE1lc2ggTGluayBFeGNoYW5nZSBbSS1ELmtl bHNleS1pbnRhcmVhLW1lc2gtbGluay1lc3RhYmxpc2htZW50XTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyhJTVBPUlRBTlQsIGEgZ29vZCBvcHRpb24uJm5ic3A7IFVzZXMgY2VydGlm aWNhdGVzIGZyb20gY29tbW9uIENBKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsyKSZuYnNwOyB3 b3JrIGluIDgwMi4xNS45ICh1c2VzIGNlcnRpZmljYXRlcyBmcm9tIGNvbW1vbiBDQSk8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7MykmbmJzcDsgU2VjdXJpdHkgRnJhbWV3b3JrIGFuZCBLZXkgTWFu YWdlbWVudCBQcm90b2NvbCBSZXF1aXJlbWVudHMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7NlRpU0NIIFtJLUQub2hiYS02dGlzY2gtc2VjdXJpdHldICh0aGlzIGRvY3VtZW50 IHByb3ZpZGVzIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BoYXNlIDAgcmVx dWlyZWQsIHVzaW5nIHRoZSBuZXR3b3JrLXdpZGUgc2hhcmVkIGtleSk8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7NCkmbmJzcDsgTGF5ZXItMiBzZWN1cml0eSBhc3BlY3RzIGZvciB0aGUgSUVFRSA4 MDIuMTUuNGUgTUFDPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0ktRC5waXJvLTZ0 aXNjaC1zZWN1cml0eS1pc3N1ZXNdOiB0aGUgTWFzdGVyS2V5IGlzIHVzZWQgdG88YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXJpdmUgcGVyLXBlZXIgTDIga2V5czxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDtQZXItcGVlciBMMiBrZXlpbmcgaXMgY3JpdGljYWwgd2hlbiBkb2luZyBw ZWVyLTItcGVlciBzY2hlZHVsZTxicj4NCiZuYnNwOyAmbmJzcDtuZWdvdGlhdGlvbiBvdmVyIDE1 LjQgSW5mb3JtYXRpb24gRWxlbWVudHMuJm5ic3A7IFRoZXJlZm9yZSBhIG5ldHdvcmstd2lkZTxi cj4NCiZuYnNwOyAmbmJzcDtsYXllci0yIGtleSBpcyBpbmFwcHJvcHJpYXRlIGZvciB0aGUgc2Vs Zi1vcmdhbml6aW5nIG5ldHdvcmtzLCBhbmQgYTxicj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbCAo TUxFLCA4MDIuMTUuOSkgU0hPVUxEIGJlIHVzZWQgdG8gZGVyaXZlIHBlci1wZWVyIEwyIGtleXMu PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0ZvciBuZXR3b3JrcyB3aGVyZSB0aGVyZSBpcyBhIFBD RSBwcmVzZW50IGFuZCBpdCB3aWxsIGRvIGFsbCBzY2hlZHVsZTxicj4NCiZuYnNwOyAmbmJzcDtj b21wdXRhdGlvbiwgdGhlbiB0aGUgb25seSB0cnVzdCByZWxhdGlvbnNoaXAgbmVjZXNzYXJ5IGlz IGJldHdlZW48YnI+DQombmJzcDsgJm5ic3A7dGhlIGluZGl2aWR1YWwgbm9kZSBhbmQgdGhlIFBD RSwgYW5kIGl0IE1BWSBiZSBhY2NlcHRhYmxlIHRvIGhhdmUgYTxicj4NCiZuYnNwOyAmbmJzcDtu ZXR3b3JrLXdpZGUgTDIga2V5IGRlcml2ZWQgaW4gd2F5cyBzdWNoIGFzPGJyPg0KJm5ic3A7ICZu YnNwO1tJLUQucGlyby02dGlzY2gtc2VjdXJpdHktaXNzdWVzXSBkZXNjcmliZXMgaW4gc2VjdGlv biA/LiZuYnNwOyBUaGUgdHJ1c3Q8YnI+DQombmJzcDsgJm5ic3A7cmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIFBDRSBhbmQgdGhlIGpvaW5pbmcgbm9kZSBmbG93cyBmcm9tIHRoZTxicj4NCiZuYnNw OyAmbmJzcDtMRGV2SUQgY2VydGlmaWNhdGUgbG9hZGVkIGJ5IHRoZSBKQ0UuJm5ic3A7IFdoZW4g dGhlIFBDRSBhbmQgSkNFIGFyZSBjby08YnI+DQombmJzcDsgJm5ic3A7bG9jYXRlZCwgdGhlIGV4 aXN0aW5nIDZ0b3AvRFRMUyBzZWN1cml0eSBhc3NvY2lhdGlvbiBjb3VsZCBiZSByZXVzZWQuPGJy Pg0KPGJyPg0KMTBCLjMuJm5ic3A7IEpvaW4gUHJvdG9jb2wgY29ubmVjdGlvbiBzZXR1cDxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgaW50ZXJtZWRpYXRlIGxldmVsIGdvYWwgb2YgdGhlIGpv aW4gcHJvdG9jb2wgaXMgdG8gZW5hYmxlIGEgSm9pbjxicj4NCiZuYnNwOyAmbmJzcDtDb29yZGlu YXRpb24gRW50aXR5IChKQ0UpIHRvIHJlYWNoIG91dCB0byB0aGUgbmV3IG5vZGUsIGFuZCBpbnN0 YWxsPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBjcmVkZW50aWFscyBkZXRhaWxlZCBhYm92ZS4mbmJz cDsgVGhlIEpDRSBtdXN0IGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG88YnI+DQombmJzcDsgJm5ic3A7 dGhlIGpvaW5pbmcgbm9kZSBzbyB0aGF0IHRoZSBqb2luaW5nIG5vZGUgd2lsbCBrbm93IHRoYXQg aXQgaGFzPGJyPg0KJm5ic3A7ICZuYnNwO2pvaW5lZCB0aGUgY29ycmVjdCBuZXR3b3JrLCBhbmQg dGhlIGpvaW5pbmcgbm9kZSBtdXN0IGF1dGhlbnRpY2F0ZTxicj4NCiZuYnNwOyAmbmJzcDtpdHNl bGYgdG8gdGhlIEpDRSBzbyB0aGF0IHRoZSBKQ0Ugd2lsbCBrbm93IHRoYXQgdGhpcyBub2RlIGJl bG9uZ3MgaW48YnI+DQombmJzcDsgJm5ic3A7dGhlIG5ldHdvcmsuJm5ic3A7IFRoaXMgdHdvIHdh eSBhdXRoZW50aWNhdGlvbiBvY2N1cnMgaW4gdGhlIDZ0b3AvQ29BUC88YnI+DQombmJzcDsgJm5i c3A7RFRMUyBzZXNzaW9uIHRoYXQgaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGUgSkNFIGFuZCB0 aGUgam9pbmluZzxicj4NCiZuYnNwOyAmbmJzcDtub2RlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtbSS1ELmlldGYtNnRpc2NoLTZ0b3AtaW50ZXJmYWNlXSBwcmVzZW50cyBhIHdheSB0byBpbnRl cmZhY2UgdG8gYTxicj4NCiZuYnNwOyAmbmJzcDs2dG9wIGluZm9ybWF0aW9uIG1vZGVsIChkZWZp bmVkIGluIFlBTkcpLiZuYnNwOyBbSS1ELmlldGYtNnRpc2NoLWNvYXBdPGJyPg0KJm5ic3A7ICZu YnNwO2V4cGxhaW5zIGhvdyB0byBhY2Nlc3MgdGhhdCBpbmZvcm1hdGlvbiBtb2RlbCB1c2luZyBD b0FQLiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO2luZm9ybWF0aW9uIG1vZGVsIHdpbGwg aW5jbHVkZSBzZWN1cml0eSBhdHRyaWJ1dGVzIGZvciB0aGUgbmV0d29yay48YnI+DQombmJzcDsg Jm5ic3A7VGhlIEpDRSB3b3VsZCB0aGVyZWZvcmUgcmVhY2ggb3V0IHRvIHRoZSBqb2luaW5nIG5v ZGUgYW5kIHNpbXBseTxicj4NCiZuYnNwOyAmbmJzcDtwcm92aXNpb24gYXBwcm9wcmlhdGUgc2Vj dXJpdHkgcHJvcGVydGllcyBpbnRvIHRoZSBqb2luaW5nIG5vZGUsIG11Y2g8YnI+DQombmJzcDsg Jm5ic3A7bGlrZSB0aGUgUENFIHdpbGwgcHJvdmlzaW9uIHNjaGVkdWxlcy48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7VGhpcyA2dG9wLWJhc2VkIHNlY3VyZSBqb2luIHByb3RvY29sIGhhcyBkZWZp bmVkIGEgcHVzaCBtb2RlbCBmb3I8YnI+DQombmJzcDsgJm5ic3A7c2VjdXJpdHkgcHJvdmlzaW9u aW5nIGJ5IHRoZSBKQ0UuJm5ic3A7IFRoaXMgaGFzIGJlZW4gZG9uZSBmb3IgdGhyZWU8YnI+DQom bmJzcDsgJm5ic3A7cmVhc29uczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7MSkmbmJzcDsgNnRp c2NoIG5vZGVzIGFscmVhZHkgaGF2ZSB0byBoYXZlIGEgNnRvcCBDb0FQIHNlcnZlciBmb3Igc2No ZWR1bGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwcm92aXNpbmc8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7MikmbmJzcDsgdGhpcyBwZXJtaXRzIHRoZSBKQ0UgdG8gbWFuYWdlIGhv dyBtYW55IG5vZGVzIGFyZSB0cnlpbmcgdG8gam9pbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2F0IHRoZSBzYW1lIHRpbWUsIGFuZCBsaW1pdCBob3cgbXVjaCBiYW5kd2lkdGgvZW5l cmd5IGlzIHVzZWQgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIGpvaW4g b3BlcmF0aW9uLCBhbmQgYWxzbyBmb3IgdGhlIEpDRSB0byBwcmlvcml0aXplIHRoZSBqb2luPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3JkZXIgZm9yIG5vZGVzLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDszKSZuYnNwOyBtYWtpbmcgdGhlIEpDRSBpbml0aWF0ZSB0aGUgRFRMUyBj b25uZWN0aW9uIHNpZ25pZmljYW50bHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtz aW1wbGllcyB0aGUgY2VydGlmaWNhdGUgY2hhaW5zIHRoYXQgbXVzdCBiZSBleGNoYW5nZWQgYXMg dGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9zdCBjb25zdHJhaW5lZCBzaWRl ICh0aGUgam9pbmluZyBub2RlKSBwcm92aWRlcyBpdCdzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y3JlZGVudGlhbHMgZmlyc3QsIGFuZCBsZXRzIHRoZSBsZXNzIGNvbnN0cmFpbmVk IEpDRSBmaWd1cmUgb3V0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hhdCBraW5k IG9mIGNlcnRpZmljYXRlIGNoYWluIHdpbGwgYmUgcmVxdWlyZWQgdG8gYXV0aGVudGljYXRlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIEpDRSB0byB0aGUgam9pbmluZyBub2Rl LiZuYnNwOyBJbiBFQVAtVExTLzgwMi4xeCBzaXR1YXRpb25zLCB0aGU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtUTFMgY2hhbm5lbCBpcyBjcmVhdGVkIGluIHRoZSBvcHBvc2l0ZSBk aXJlY3Rpb24sIGFuZCBpdCB3b3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hh dmUgdG8gY29tcGxldGUgaW4gYSB0ZW50YXRpdmUgd2F5LCBhbmQgdGhlbiBmdXJ0aGVyPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXV0aG9yaXphdGlvbiBvY2N1ciBpbi1iYW5kLjxi cj4NCjxicj4NCjEwQi40LiZuYnNwOyBFbmQgdG8gRW5kIGNvbnNpZGVyYXRpb25zIGZvciBKb2lu IFByb3RvY29sPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0luIG9yZGVyIGZvciBhIDZ0b3AvRFRM Uy9Db0FQIGNvbm5lY3Rpb24gdG8gb2NjdXIgYmV0d2VlbiB0aGUgSkNFIGFuZDxicj4NCiZuYnNw OyAmbmJzcDt0aGUgam9pbmluZyBub2RlLCB0aGVyZSBuZWVkcyB0byBiZSBlbmQtdG8tZW5kIElQ djYgY29ubmVjdGl2aXR5PGJyPg0KJm5ic3A7ICZuYnNwO2JldHdlZW4gdGhvc2UgdHdvIGVudGl0 aWVzLiZuYnNwOyBUaGUgam9pbmluZyBub2RlIHdpbGwgbm90IHBhcnRpY2lwYXRlIGluPGJyPg0K Jm5ic3A7ICZuYnNwO3RoZSByb3V0ZS1vdmVyIFJQTCBtZXNoLCBidXQgcmF0aGVyIHdpbGwgYmUg c2VlbiBieSB0aGUgbmV0d29yayBhczxicj4NCiZuYnNwOyAmbmJzcDtiZWluZyBhIDZsb3dwYW4g b25seSBsZWFmLW5vZGUuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBqb2luaW5nIG5vZGUg c2VuZHMgdHJhZmZpYyB0byB0aGUgam9pbiBhc3Npc3RhbnQsIHdoaWNoIGZvcndhcmRzPGJyPg0K Jm5ic3A7ICZuYnNwO2l0IHVzaW5nIHRoZSBub3JtYWwgUlBMIERPREFHIHVwd2FyZHMgcm91dGVz LCBhbmQgd2hpY2ggd2lsbCByZWFjaDxicj4NCiZuYnNwOyAmbmJzcDt0aGUgSkNFIHVzaW5nIHJl Z3VsYXIgcm91dGluZy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIGNoYWxsZW5nZSBpcyBn ZXR0aW5nIGNvbm5lY3Rpdml0eSBmcm9tIHRoZSBKQ0UgdG8gdGhlIGpvaW5pbmc8YnI+DQombmJz cDsgJm5ic3A7bm9kZSwgYXMgdGhlIERPREFHIHdpbGwgaGF2ZSBubyBpbmZvcm1hdGlvbiBhYm91 dCB0aGlzIG5vZGUuPGJyPg0KJm5ic3A7ICZuYnNwO0luc3RlYWQsIHRoZSBKQ0Ugd2lsbCB1c2Ug bG9vc2Utc291cmNlIHJvdXRlcyB0byBhZGRyZXNzIHBhY2tldHM8YnI+DQombmJzcDsgJm5ic3A7 Zmlyc3QgdG8gdGhlIEpvaW4gQXNzaXN0YW50LCB3aGljaCB3aWxsIHRoZW4gZm9yd2FyZCB0byB0 aGUgam9pbmluZzxicj4NCiZuYnNwOyAmbmJzcDtub2RlLiZuYnNwOyBUaGlzIGhhcyBhbiBpbnRl cmFjdGlvbiB3aXRoIHRoZSAoc3RyaWN0KSBzb3VyY2Ugcm91dGVzIHVzZWQ8YnI+DQombmJzcDsg Jm5ic3A7Ynkgbm9uLXN0b3JpbmcgRE9EQUdzIHdoaWNoIHdvdWxkIGJlIHVzZWQgYnkgdGhlIDZM QlIgdG8gcmVhY2ggdGhlPGJyPg0KJm5ic3A7ICZuYnNwO0pvaW4gQXNzaXN0YW50Ljxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDtUaGVyZSBhcmUgc29tZSBhbHRlcm5hdGl2ZXMgdG8gaGF2aW5nIGZ1 bGwgZW5kIHRvIGVuZCBjb25uZWN0aXZpdHk8YnI+DQombmJzcDsgJm5ic3A7d2hpY2ggYXJlIGRp c2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi48YnI+DQo8YnI+ DQoxMi4xLiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczogYWx0ZXJuYXRpdmVzIHRvIHNv dXJjZSByb3V0ZXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBnb2VzIGludG8gc2VjdXJp dHktY29uc2lkZXJhdGlvbnMgc2VjdGlvbjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtBIG51bWJl ciBvZiBhbHRlcm5hdGl2ZXMgd2VyZSBjb25zaWRlcmVkIGZvciBjcmVhdGluZyBlbmQgdG8gZW5k PGJyPg0KJm5ic3A7ICZuYnNwO2Nvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZSBqb2luaW5nIG5vZGUg YW5kIHRoZSBKQ0UsIGJ1dCB3ZXJlIHJlamVjdGVkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDso MSkmbmJzcDsgSVBJUCB0dW5uZWwgYmV0d2VlbiBKb2luIEFzc2lzdGFudCBhbmQgSkNFPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOygyKSZuYnNwOyB1c2luZyBzdHJhaWdodCBSUEwgcm91dGluZzog dGhlIEpvaW4gQXNzaXN0YW50IHNlbmRzIGEgREFPPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOygz KSZuYnNwOyB1c2luZyBhIHNlcGFyYXRlIFJQTCBET0RBRyBmb3Igam9pbiB0cmFmZmljPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyg0KSZuYnNwOyBlc3RhYmxpc2hpbmcgYSBzcGVjaWZpYyBtdWx0 aS1ob3AgNnRpc2NoIHRyYWNrIGZvciBqb2luIHRyYWZmaWM8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBmb3IgZWFjaCBKb2luIEFzc2lzdGFudDxicj4NCjxicj4NCjEyLjEuMS4xLiZuYnNwOyBJ UElQIHR1bm5lbDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIG1lY2hhbmlzbSByZXF1aXJl cyA0MCBieXRlcyBvdmVyaGVhZCBwZXIgcGFja2V0LCBhbmQgbWF5IHJlcXVpcmU8YnI+DQombmJz cDsgJm5ic3A7c3BlY2lmaWMgc3RhdGUgdG8gYmUgY3JlYXRlZCBvbiB0aGUgSm9pbiBBc3Npc3Rh bnQsIG9yIG1heSBvcGVuIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIHVwIHRvIGEgcmVz b3VyY2UgZXhoYXVzdGlvbiBieSBtYWxpY2lvdXMgam9pbiBub2Rlcy48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7VGhpcyBtZWNoYW5pc20gd2FzIHJlamVjdGVkIG9uIGR1ZSB0byBieXRlIGNvdW50 LCBiZWNhdXNlIGl0IHdvdWxkPGJyPg0KJm5ic3A7ICZuYnNwO3JlcXVpcmUgY29kZSBvbmx5IG5l ZWRlZCBmb3Igam9pbiwgYW5kIGJlY2F1c2UgZG9pbmcgaXQgc2VjdXJlbHkgbWF5PGJyPg0KJm5i c3A7ICZuYnNwO3JlcXVpcmUgYSBwZXItdHVubmVsIHN0YXRlIHRvIGJlIG1haW50YWluZWQgb24g dGhlIGpvaW4gYXNzaXN0YW50Ljxicj4NCjxicj4NCjEyLjEuMS4yLiZuYnNwOyBqb2luIGV4aXN0 aW5nIERPREFHPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgbWVjaGFuaXNtIGlzIHRvIGp1 c3QgaGF2ZSB0aGUgbmV3IG5vZGUgam9pbiB0aGUgRE9EQUcgYXMgYSBsZWFmPGJyPg0KJm5ic3A7 ICZuYnNwO25vZGUuJm5ic3A7IFRoZSBqb2luIGFzc2lzdGFudCB3b3VsZCBpc3N1ZSBhIERBTyBm b3IgdGhlIG5ldyBub2RlLiZuYnNwOyBJZiBhPGJyPg0KJm5ic3A7ICZuYnNwO3N0b3JpbmcgRE9E QUcgd2FzIHVzZWQsIHRoaXMgd291bGQgZGlyZWN0bHkgY29zdCBzdGF0ZSBpbiBhbGwgcGFyZW50 PGJyPg0KJm5ic3A7ICZuYnNwO25vZGVzIG9mIHRoZSBKb2luIEFzc2lzdGFudCwgc3ViamVjdGlu ZyB0aGUgbG93ZXItcmFuayBwYXJ0cyBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7bmV0d29yayB0 byBzaWduaWZpY2FudCBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzLjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDtPbiBhIG5vbi1zdG9yaW5nIERPREFHIHRoZSBzaXR1YXRpb24gaXMgc2lnbmlmaWNh bnRseSBiZXR0ZXI6IG5vPGJyPg0KJm5ic3A7ICZuYnNwO3N0YXRlIGlzIGNyZWF0ZWQgYnkgdGhl IHByZXNlbmNlIG9mIHRoZSBsZWFmIG5vZGUgZXhjZXB0IGluIHRoZSA2TEJSLDxicj4NCiZuYnNw OyAmbmJzcDt3aGVyZSBhdmFpbGFibGUgcmVzb3VyY2VzIG1heSBiZSBoaWdoZXIuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwO1RoaXMgbWVjaGFuaXNtIHdhcyByZWplY3RlZCBpbiBmYXZvdXIgb2Yg dGhlIGxvb3NlIHNvdXJjZSByb3V0ZWQ8YnI+DQombmJzcDsgJm5ic3A7b3B0aW9uIGFzIHRoaXMg dGhlIGxvb3NlIHNvdXJjZSByb3V0ZWQgb3B0aW9uIGFsd2F5cyB3b3JrcyBldmVuIGZvcjxicj4N CiZuYnNwOyAmbmJzcDtzdG9yaW5nIERPREFHcywgYW5kIGlzIG90aGVyd2lzZSBleGFjdGx5IGVx dWl2YWxlbnQgaW4gdGVybXMgb2Y8YnI+DQombmJzcDsgJm5ic3A7bmV0d29yayBiYW5kd2lkdGgg Y29zdC48YnI+DQo8YnI+DQoxMi4xLjEuMy4mbmJzcDsgam9pbiBhIERPRE9BRyBmb3Igam9pbmlu Zzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtPbmUgb3B0aW9uIHRvIGRlYWwgd2l0aCB0aGUgcHJv YmxlbSBvZiByZXNvdXJjZSBjb25zdW1wdGlvbiBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7c3Rv cmluZyBET0RBRyBjYXNlIGlzIHRvIHVzZSBhIHNlY29uZCBET0RBRy48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7VGhpcyBtZWNoYW5pc20gd2FzIHJlamVjdGVkIGFzIGl0IGNvbnN1bWVzIHJlc291 cmNlcyBpbiBhbGwgbm9kZXMgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBzZWNvbmQgRE9EQUcs IGFuZCBtYW55IGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IG9uIGEgc2luZ2xlIERPREFHLjxicj4N CiZuYnNwOyAmbmJzcDtXaGlsZSBzdG9yaW5nIERPREFHcyBoYXZlIGEgbGlnaHRlciBuZXR3b3Jr IGltcGFjdCB0aGFuIG5vbi1zdG9yaW5nPGJyPg0KJm5ic3A7ICZuYnNwO29uZXMgKGR1ZSB0byB0 aGUgbGFjayBvZiBzb3VyY2Ugcm91dGVzKSwgdGhlIFBDRSBjYW4gY29udHJvbCBob3cgbXVjaDxi cj4NCiZuYnNwOyAmbmJzcDtuZXR3b3JrIGJhbmR3aWR0aCBjYW4gYmUgd2FzdGVkIGJ5IG1hbGlj aW91cyBqb2luIG5vZGVzIHVzaW5nIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtyZWd1bGFyIDZ0aXNj aCBtZWNoYW5pc21zLCBhbmQgdGhpcyBjYW4gYmUgdHVuZWQuJm5ic3A7IEEgc2Vjb25kIERPREFH PGJyPg0KJm5ic3A7ICZuYnNwO3dvdWxkIGJlIGEgc3VuayBjb3N0IHdpdGggbm8gdHVuaW5nIHBv c3NpYmxlLjxicj4NCjxicj4NCjEyLjEuMS40LiZuYnNwOyBjcmVhdGUgNnRpc2NoIHRyYWNrIHRv IGZvcm0gbWVzaC11bmRlcjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIG1lY2hhbmlzbSB3 b3VsZCB1c2UgNnRpc2NoIHRyYWNrcyBzbyB0aGF0IHRyYWZmaWMgZnJvbSB0aGUgSkNFPGJyPg0K Jm5ic3A7ICZuYnNwO3dvdWxkIGJlIHN3aXRjaGVkIGZyb20gNkxCUiB0byBqb2luIG5vZGUuJm5i c3A7IEEgdHJhY2sgd291bGQgYmUgcmVxdWlyZWQ8YnI+DQombmJzcDsgJm5ic3A7dG8gZWFjaCBq b2luIGFzc2lzdGFudC4mbmJzcDsgVGhpcyBpcyBhbiBvcHRpbWl6ZWQgZm9ybSBvZiBzb3VyY2Ug cm91dGluZy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBtZWNoYW5pc20gd2FzIG5vdCBy ZWplY3RlZCwgcmF0aGVyIGl0IHdhcyBvYnNlcnZlZCB0aGF0IGl0IG1heTxicj4NCiZuYnNwOyAm bmJzcDtiZSBhcHBsaWVkIHRvIGFueSBtZWNoYW5pc20gdGhhdCB1c2VzIHNvdXJjZSByb3V0aW5n LCBhbmQgaXMgYW48YnI+DQombmJzcDsgJm5ic3A7b3B0aW1pemF0aW9uOyBpdCBoYXMgYSBjZXJ0 YWluIGNvc3QgaW4gdGhlIGZvcm0gb2YgaW50ZXJtZWRpYXJ5IG5vZGU8YnI+DQombmJzcDsgJm5i c3A7c3RhdGUsIGJ1dCB0aGF0IHRoaXMgc3RhdGUgaXMgbm90IGNyZWF0ZWQgYnkgYSBtYWxpY2lv dXMgam9pbiBub2RlLDxicj4NCiZuYnNwOyAmbmJzcDtyYXRoZXIgaXQgaXMgY3JlYXRlZCBieSB0 aGUgUENFLjxicj4NCjxicj4NCjEwQi41LiZuYnNwOyBKb2luIG5vZGUgZGlzY292ZXJ5IG1lY2hh bmlzbTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtDb250aW51aW5nIHRvIHdvcmsgYmFja3dhcmRz LCBpbiBvcmRlciB0aGUgSkNFIHJlYWNoIG91dCB0byBwcm92aXNpb248YnI+DQombmJzcDsgJm5i c3A7dGhlIEpvaW5pbmcgTm9kZSwgaXQgbmVlZHMgdG8ga25vdyB0aGF0IHRoZSBuZXcgbm9kZSBp cyBwcmVzZW50Ljxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGlzIGRvbmUgYnkgdGFraW5nIGFkdmFu dGFnZSBvZiB0aGUgNmxvd1BBTiBBZGRyZXNzIFJlc29sdXRpb248YnI+DQombmJzcDsgJm5ic3A7 T3B0aW9uIChBUk8pIChzZWN0aW9uIDQuMSBbUkZDNjc3NV0pLiZuYnNwOyBUaGUgQVJPIGNhdXNl cyB0aGUgbmV3IGFkZHJlc3M8YnI+DQombmJzcDsgJm5ic3A7dG8gYWxzbyBiZSBzZW50IHVwIHRv IHRoZSA2TEJSIGZvciBkdXBsaWNhdGUgZGV0ZWN0aW9uIHVzaW5nIHRoZSBEQVIvPGJyPg0KJm5i c3A7ICZuYnNwO0RBQyBtZWNoYW5pc20uJm5ic3A7IFRoZSA2TEJSIHNpbXBseSBuZWVkcyB0byB0 ZWxsIHRoZSBKQ0UgYWJvdXQgdGhpcy4mbmJzcDsgQTxicj4NCiZuYnNwOyAmbmJzcDtuZXcgcHJv dG9jb2wgbWF5IGJlIHJlcXVpcmVkIGZvciB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBKQ0UsIFBD RSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7NkxCUiBhcmUgbm90IGNvLWxvY2F0ZWQ7IGl0IG1heSBi ZSB0aGF0IHRoaXMgcHJvdG9jb2wgY291bGQgYmUgc2ltcGx5PGJyPg0KJm5ic3A7ICZuYnNwO2Eg REFSIGluIHNvbWUgZW5jYXBzdWxhdGlvbi4mbmJzcDsgVGhlIGRldGFpbHMgb2YgdGhpcyBhcmUg Y3VycmVudGx5IG91dDxicj4NCiZuYnNwOyAmbmJzcDtvZiBzY29wZSBmb3IgdGhlIGFyY2hpdGVj dHVyZSwgYXMgdGhleSBhZmZlY3QgaW50ZXJvcGVyYWJpbGl0eTxicj4NCiZuYnNwOyAmbmJzcDti ZXR3ZWVuIGRpZmZlcmVudCB2ZW5kb3JzIG9mIEpDRS82TEJSL1BDRSByYXRoZXIgdGhhbjxicj4N CiZuYnNwOyAmbmJzcDtpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gdGhlIGFzc2lzdGFuY2Uvb2Zm bG9hZCBpbmZyYXN0cnVjdHVyZSwgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBjb250cmFpbmVk IG5vZGVzLiZuYnNwOyBGdXR1cmUgd29yayBtYXkgc3BlY2lmeSB0aGlzIHBhcnQuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwO0luIGFkZGl0aW9uIHRvIG5lZWRpbmcgdG8ga25vdyB0aGUgam9pbmlu ZyBkZXZpY2VzIGFkZHJlc3MgZnJvbSB0aGU8YnI+DQombmJzcDsgJm5ic3A7REFSL05TLCB0aGUg SkNFIGFsc28gbmVlZHMgdG8ga25vdyB0aGUgam9pbmluZyBub2RlJ3MgSURldklELiZuYnNwOyBU aGlzPGJyPg0KJm5ic3A7ICZuYnNwO2lzIHRvIGRldGVybWluZSBpZiB0aGUgbm9kZSBzaG91bGQg ZXZlbiBnZXQgYW55IGF0dGVudGlvbi4mbmJzcDsgQXQgdGhpczxicj4NCiZuYnNwOyAmbmJzcDtw b2ludCwgdGhlIElEZXZJRCBjYW4gYmUgZm9yZ2VkLCBpdCB3aWxsIGJlIGF1dGhlbnRpY2F0ZWQg ZHVyaW5nIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtzZXR1cCBvZiB0aGUgNnRvcCBjb250cm9sIHBy b3RvY29sIGluIHRoZSBEVExTIGNlcnRpZmljYXRlIGV4Y2hhbmdlLjxicj4NCiZuYnNwOyAmbmJz cDtJZiB0aGUgc2VyaWFsTnVtYmVyIGF0dHJpYnV0ZSBvZiB0aGUgSURldklEIGlzIGxlc3MgdGhh biA2NCBiaXRzLDxicj4NCiZuYnNwOyAmbmJzcDt0aGVuIGl0IGlzIHBvc3NpYmxlIHRoYXQgaXQg Y291bGQgYmUgcGxhY2VkIGludG8gdGhlIEVVSS02NCBvcHRpb24gb2Y8YnI+DQombmJzcDsgJm5i c3A7dGhlIEFSTywgb3IgdGhlIE9VSSBvZiB0aGUgW0ktRC50aHViZXJ0LTZsby1yZmM2Nzc1LXVw ZGF0ZS1yZXFzXTxicj4NCiZuYnNwOyAmbmJzcDtFQVJPLiZuYnNwOyBUaGUgSkNFIG5lZWRzIHRv IGtub3cgdGhlIGpvaW5pbmcgbm9kZSdzIHNlcmlhbE51bWJlciB0byBrbm93PGJyPg0KJm5ic3A7 ICZuYnNwO2lmIHRoaXMgaXMgZGV2aWNlIHRoYXQgaXQgc2hvdWxkIGV2ZW4gYXR0ZW1wdCB0byBw cm92aXNpb247IGFuZCBpZjxicj4NCiZuYnNwOyAmbmJzcDtzbywgaXQgbWF5IG5lZWQgdG8gcmV0 cmlldmUgYW4gYXBwcm9wcmlhdGUgY2VydGlmaWNhdGUgY2hhaW4gKHNlZTxicj4NCiZuYnNwOyAm bmJzcDtbSS1ELnJpY2hhcmRzb24tNnRpc2NoLWlkZXZpZC1jZXJ0XSkgZnJvbSB0aGUgRmFjdG9y eSBpbiBvcmRlciBmb3I8YnI+DQombmJzcDsgJm5ic3A7dGhlIEpDRSB0byBwcm92ZSBpdCBpcyB0 aGUgbGVnaXRpbWF0ZSBvd25lciBvZiB0aGUgam9pbmluZyBub2RlLjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDtOZWl0aGVyIDgwMi4xQVIgbm9yIFtSRkM1MjgwXSBwcm92aWRlIGFueSBzdHJ1Y3R1 cmUgZm9yIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtzZXJpYWxOdW1iZXIsIGV4Y2VwdCB0aGF0IHRo ZXkgYXJlIHBvc2l0aXZlIGludGVnZXJzIG9mIHVwLXRvIDIwPGJyPg0KJm5ic3A7ICZuYnNwO29j dGV0cyBpbiBzaXplIChudW1iZXJzIHVwIHRvIDJeMTYwKS4mbmJzcDsgVGhpcyBzcGVjaWZpY2F0 aW9uIHdvdWxkPGJyPg0KJm5ic3A7ICZuYnNwO3JlcXVpcmUgdGhhdCB0aGUgc2VyaWFsTnVtYmVy IGVuY29kZWQgaW4gdGhlIElEZXZJRCBiZSB0aGUgc2FtZSBhczxicj4NCiZuYnNwOyAmbmJzcDt0 aGUgRVVJLTY0IHVzZWQgYnkgdGhlIGRldmljZS4mbmJzcDsgU29tZSBjb25zaWRlcmF0aW9uIG5l ZWRzIHRvIGJlIGdpdmVuPGJyPg0KJm5ic3A7ICZuYnNwO2FzIHRvIHdoZXRoZXIgdGhlcmUgYXJl IHByaXZhY3kgY29uc2lkZXJhdGlvbnMgdG8gZG9pbmcgdGhpczogYW55PGJyPg0KJm5ic3A7ICZu YnNwO29ic2VydmVyIHRoYXQgY2FuIHNlZSB0aGUgam9pbiB0cmFmZmljLCBjYW4gYWxzbyBzZWUg dGhlIHNvdXJjZSBNQUM8YnI+DQombmJzcDsgJm5ic3A7YWRkcmVzcyBvZiB0aGUgbm9kZSBhcyB3 ZWxsLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtQcmlvciB0byBiZWluZyBhYmxlIHRvIGFubm91 bmNlIGl0c2VsZiBpbiBhIE5TLCB0aGUgam9pbmluZyBub2RlPGJyPg0KJm5ic3A7ICZuYnNwO25l ZWRzIHRvIGZpbmQgdGhlIEpvaW4gTmV0d29yay4mbmJzcDsgVGhpcyBpcyBkb25lIGJ5IGxpc3Rl bmluZyB0byBhbjxicj4NCiZuYnNwOyAmbmJzcDtleHRlbmRlZCBiZWFjb24gd2hpY2ggYXJlIGJy b2FkY2FzdCBpbiBkZXNpZ25hdGVkIHNsb3RmcmFtZXMgYnkgSm9pbjxicj4NCiZuYnNwOyAmbmJz cDtBc3Npc3RhbnRzLiZuYnNwOyBUaGUgRXh0ZW5kZWQgQmVhY29uIHByb3ZpZGVzIGEgd2F5IGZv ciB0aGUgSm9pbmluZyBOb2RlPGJyPg0KJm5ic3A7ICZuYnNwO3RvIHN5bmNocm9uaXplIGl0c2Vs ZiB0byB0aGUgb3ZlcmFsbCB0aW1lc2xvdCBzY2hlZHVsZSBhbmQgcHJvdmlkZXM8YnI+DQombmJz cDsgJm5ic3A7YW4gQWxvaGEgcGVyaW9kIGluIHdoaWNoIHRoZSBKb2luaW5nIE5vZGUgY2FuIHNl bmQgYSBSb3V0ZXI8YnI+DQombmJzcDsgJm5ic3A7U29saXRpY2lhdGlvbiwgYW5kIHJlY2VpdmUg YW4gYXBwcm9wcmlhdGUgUm91dGVyIEFkdmVydGlzZW1lbnQgZ2l2aW5nPGJyPg0KJm5ic3A7ICZu YnNwO3RoZSBKb2luaW5nIE5vZGUgYSBwcmVmaXggYW5kIGRlZmF1bHQgcm91dGUgdG8gd2hpY2gg dG8gc2VuZCBqb2luPGJyPg0KJm5ic3A7ICZuYnNwO3RyYWZmaWMuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwO0l0IG1heSBiZSBwb3NzaWJsZSB0byBlbGltaW5hdGUgYSBtZXNzYWdlIGV4Y2hhbmdl IGlmIHNwYWNlIGZvciBhPGJyPg0KJm5ic3A7ICZuYnNwO1JvdXRlciBBZHZlcnRpc2VtZW50IGNh biBiZSBmb3VuZCBhcyBwYXJ0IG9mIHRoZSBKb2luIE5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7 RXh0ZW5kZWQgQmVhY29uLiZuYnNwOyBUaGlzIEVuaGFuY2VkIEJlYWNvbiB3b3VsZCBiZSBkaXN0 aW5jdCB0byB0aGUgSm9pbjxicj4NCiZuYnNwOyAmbmJzcDtOZXR3b3JrLCBhbmQgd291bGQgYmUg ZW5jcnlwdGVkIHdpdGggdGhlIHdlbGwta25vd24gSm9pbiBOZXR3b3JrIGtleS48YnI+DQo8YnI+ DQoxMEIuNS4xLiZuYnNwOyBwcmVmaXhlcyB0byB1c2UgZm9yIGpvaW4gdHJhZmZpYzxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDtXaGF0IHByZWZpeCB3b3VsZCB0aGUgam9pbmluZyBub2RlIGZvciBj b21tdW5pY2F0aW9uPyZuYnNwOyBUaGVyZSBhcmU8YnI+DQombmJzcDsgJm5ic3A7dGhyZWUgb3B0 aW9uczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KDEpJm5ic3A7IGp1c3QgdXNlIGxpbmstbG9j YWwgYWRkcmVzc2VzICh0aGlzIG1heSByZXF1aXJlIHRoYXQgc29tZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHRyYWZmaWMgYmV0d2VlbiA2TEJSIGFuZCBKQ0UgYmUgSVBJUCB0dW5uZWxlZCk8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KDIpJm5ic3A7IHVzZSBhIHByZWZpeCBzcGVjaWZpY2Fs bHkgZm9yIGpvaW4gdHJhZmZpYyAobWF5IGJlIGVhc2llciB3aXRoIGE8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBqb2luLW9ubHkgRE9EQUcpPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOygzKSZu YnNwOyB1c2UgdGhlIHNhbWUgcHJlZml4IGFzIHRoZSByZXN0IG9mIHRoZSB0cmFmZmljIChtYXkg cmVxdWlyZSBtb3JlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29tcGxleCBBQ0xzLCBhbmQg bGVha3MgaW5mb3JtYXRpb24gdG8gYXR0YWNrZXJzKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtU aGUgc2ltcGxlc3QgbWV0aG9kIGlzIHRvIHVzZSB0aGUgbGluay1sb2NhbCBhZGRyZXNzZXMgZm9y IHRoZSA2dG9wPGJyPg0KJm5ic3A7ICZuYnNwO2Nvbm5lY3Rpb24sIGFuZCB0aGUgY29zdCBvZiBh biBJUElQIHR1bm5lbCBiZXR3ZWVuIHRoZSB1bmNvbnN0cmFpbmVkPGJyPg0KJm5ic3A7ICZuYnNw OzZMQlIgYW5kIHRoZSBKQ0UgaXMgbm90IGNvbnNpZGVyZWQgc2lnbmlmaWNhbnQuPGJyPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPk1pY2hhZWwgUmljaGFy ZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciUyQklFVEZAc2FuZGVsbWFuLmNhIj5tY3ImIzQz O0lFVEZAc2FuZGVsbWFuLmNhPC9hPiZndDssIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrczwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4mbmJzcDstPSBJUHY2IElvVCBjb25zdWx0aW5n ID0tPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjZ0aXNjaC1zZWN1cml0 eSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86NnRpc2NoLXNlY3VyaXR5QGlldGYu b3JnIj42dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gtc2VjdXJpdHkiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaC1zZWN1cml0 eTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_E045AECD98228444A58C61C200AE1BD848A4F742xmbrcdx01ciscoc_-- From nobody Thu Nov 13 17:43:11 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 EC7871A00ED; Thu, 13 Nov 2014 17:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 v-DVGeqV_eiw; Thu, 13 Nov 2014 17:43:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4CD1A00D0; Thu, 13 Nov 2014 17:43:00 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1DAE320098; Thu, 13 Nov 2014 20:45:11 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 17DE6637F4; Thu, 13 Nov 2014 20:42:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F3945637EA; Thu, 13 Nov 2014 20:42:58 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" In-Reply-To: References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@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/NZFjKIJPNvxY7oVNav839nzC1vM Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "yoshihiro.ohba@toshiba.co.jp" Subject: Re: [6tisch-security] proposed security text for architecture draft 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, 14 Nov 2014 01:43:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > an interface ID associated to the address, which is missing in the RH. > Yesterday we discussed an "optimistic" usage of a global address that > the joining device would form. This requires the joining device to > receive an RA. Is that unacceptable? Yes, because the RA is always sent. An open question was: could we find a way to hide the RA in the Enhanced Beacon, which reduces a packet on the wire. =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) iQEVAwUBVGVeIICLcPvd0N1lAQJ/Nwf+NOjnlA7C17WPYE6nxaBo1Jy2xX83eZC+ urqsoCQrkMm//I6qqmBqfGXszsW07hwyCS10hG9hlWPwpxqhet/2rc8sL8dnh33o UyQbkkGkIwoJUZUbpuJ/ILbgkCmdgtgZ9sbwp/vddaxq24cZNJaZXKgELYgep1mU NObilHtryVp/Bv0p9c5hE3eujs+nznKCQ6Z3R3cTVIabpeid7O0qJwc2egIdeNKY iW7zeW/HdZ5eLj19CJZNsj2OHsMTg5L4mYXtCW79EalKddPswBlnPwR+vsbXP1Zt TCPWka9kwFKmDfZX4rwMVvBU7zLFY+wJVUGfq+vAmztIzJmDNEokYQ== =n4Ei -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 13 17:44:30 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 DF0DA1A00B2; Thu, 13 Nov 2014 17:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 zS25_FyCYxMW; Thu, 13 Nov 2014 17:44:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A6D1A00A8; Thu, 13 Nov 2014 17:44:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7791E20098; Thu, 13 Nov 2014 20:46:35 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 73241637F4; Thu, 13 Nov 2014 20:44:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 61829637EA; Thu, 13 Nov 2014 20:44:23 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@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/e0Wx3BFxWbjIw-PptVGhVIuZlXA Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 01:44:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > It is unfortunate that some contributors felt that EAP-based approach > does not work for them, but there is another use case where EAP-based > approach is definitely needed (smart meters). Having said that it > would make sense to have two options (DTLS-based and EAP-based > approaches) for joining operation. 1) Can you explain why smart meters have to use EAP methods? 2) can someone explain why smart meters are in scope for this WG? I thought it was mostly industrial applications. =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) iQEVAwUBVGVedICLcPvd0N1lAQINrggAiAUtlXIvSooorrY5806WoyT75/uhZssc NthG27l8/LcKwL4efvn1huCP8Ua0XavfFL5bUVneelSpuHFILv8IldI4row1dH7v QpeTJZrJ57a06MJnQ+j51pjSm7wuonoMuOcL5BzZOCu91ZX1tLmIAt+vPBDzhP/X HkR916PHVjY5agVzVB5DyTa/+wpRz5qBZ3/bp3kroG9v1YC6iPzC2qDROP2bs367 7jSapYLZFmP9UiYn/EdvgLXZG9iVQbVrw0JALWg2rAWeuw9bzCiBiBe66ZytSWXV 4ZpWwNeJQ4sleBOhY2zcYRSisiqBLflHGzfVr6gwUlvaOlsaZ5SvJA== =pzur -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 13 17:50:06 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 5C6831A017E; Thu, 13 Nov 2014 17:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 0aqP63CPmKVo; Thu, 13 Nov 2014 17:50:01 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9E01A015F; Thu, 13 Nov 2014 17:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=854; q=dns/txt; s=iport; t=1415929802; x=1417139402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OXNWw/5l93ahLFEZGGG+d7CoLpZ1qAaqcprbf32M0tw=; b=mZcs3Xgy/G+puWYgxZPANAnwl7KOX9cW9iKbDdxRIMBuakaHOuk8w8I7 vIQtg5VFhuIOVHioSTFh+lH83kU0qRgyNfQ8zOnVb0SzE83M3XObQgbjy PuwLgEZD4WuBHyn+wjO7T4qC2Exap06sYWo3sFJTvuNah60S9dJ4PnkJ8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGBfZVStJV2S/2dsb2JhbABbgw6BLdRJAoEhFgEBAQEBfYQCAQEBAwF5BQsCAQgSBi4yFw4CBAENBYg4CdBwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41GAYMaMweDLYEeAQSLTYRJgiSLd5ZnghCBbG2CSwEBAQ X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="96491428" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 14 Nov 2014 01:49:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAE1njxS004178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 01:49:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 19:49:45 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , Pat Kinney Thread-Topic: [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/6xVTHjXM0FJ6E6z0WAXP4mkhpxfWy4i Date: Fri, 14 Nov 2014 01:49:44 +0000 Message-ID: <62CCF286-3362-4E5A-ACB1-8BDAA4184CEA@cisco.com> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> , <11870.1415929378@sandelman.ca> In-Reply-To: <11870.1415929378@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/Voe86Cka4OWjXn4wCp-v1e3IZNU Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "yoshihiro.ohba@toshiba.co.jp" Subject: Re: [6tisch-security] proposed security text for architecture draft 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, 14 Nov 2014 01:50:03 -0000 CC ing Pat Pat, would you confirm whether we can we piggy back an IPv6 RA with an EB? Thanks a bunch! Pascal > Le 13 nov. 2014 =E0 15:43, Michael Richardson a = =E9crit : >=20 >=20 > Pascal Thubert (pthubert) wrote: >> an interface ID associated to the address, which is missing in the RH. >> Yesterday we discussed an "optimistic" usage of a global address that >> the joining device would form. This requires the joining device to >> receive an RA. Is that unacceptable? >=20 > Yes, because the RA is always sent. >=20 > An open question was: could we find a way to hide the RA in the Enhanced > Beacon, which reduces a packet on the wire. >=20 > --=20 > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Thu Nov 13 19:07: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 30E251A1B28; Thu, 13 Nov 2014 19:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 ibZggq06dLHH; Thu, 13 Nov 2014 19:07:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8064B1A1B8B; Thu, 13 Nov 2014 19:07:17 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8470020098; Thu, 13 Nov 2014 22:09:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4C298637F4; Thu, 13 Nov 2014 22:07:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 363CA637EA; Thu, 13 Nov 2014 22:07:16 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@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/uag6a6VCrcDXNXcGuOY8HrBUJL4 Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 03:07:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {Please note that I am very familiar with EAP mechanisms, and I wrote EAP-S= IM for Freeradius a decade ago, when the document was going through many chan= ges} wrote: > Regarding EAP method, I mentioned EAP-TLS. EAP-TLS works for both > certificate-based authentication and pre-shared key based > authentication (EAP-TLS-PSK) without EAP tunneling method such as > EAP-TTLS. In the latter case, TLS session is typically terminated at > AAA server. But, since the EAP-TLS session terminates at the the AAA server, all of the communications that we want to do (the 6top data), would have to come from the AAA server.=20=20=20 That means installing all of 6top/DTLS/CoAP code into the radius server.=20= =20 (That's because the EAP-TLS is between AAA(radius) server and joining node) Is that really what you want to do? What other things would the AAA server provide to the joining node? Are you thinking about various kinds of group policies, etc? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGVx4ICLcPvd0N1lAQKLagf/cuwTft60kFAJQd7+pxW1H4Y69/bEcGpQ WbdWviMaUdTiaZRZJTJ03ftBekdg2YG9o48FFVWZKqNv9eupjMvvS/nfyIr3HjqD lpb5hiOIuNaKZlGHoTMQ7IUDY6k61rRbhl2pWXQdYCQYsVMRBT77vm/FsDtLI+ig 2r0wxrw/4tRa8ThVqVBNTrcGB2cQcUtblhisov9JXRQPuZCNXgSgOLfp9v9QnatT hKD/QJ/gHjI6uLVkdF7opL1IyWHeGy765WoPOiYHtq6fjoz4giaW4fDz0FkpbyCd yD60tzrjD1XqaEy/Q6FZ9gP/PBr+ZoOqSoGo6YVl+7CDVf13iYLa6Q== =bwSC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 13 19:14:09 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 325461A1BEC; Thu, 13 Nov 2014 19:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 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, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bjkAGRblPQTR; Thu, 13 Nov 2014 19:14:02 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88FE1A1BA3; Thu, 13 Nov 2014 19:14:01 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sAE3Dxro005434; Fri, 14 Nov 2014 12:13:59 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sAE3DxXK013671; Fri, 14 Nov 2014 12:13:59 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id NAA13667; Fri, 14 Nov 2014 12:13:59 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sAE3Dw75025563; Fri, 14 Nov 2014 12:13:59 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAE3DwOj005135; Fri, 14 Nov 2014 12:13:58 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 12:13:58 +0900 From: To: Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/6yKOb3Y6xRimEizs5+EnBgFs5xfaUvg Date: Fri, 14 Nov 2014 03:13:57 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A9867@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <12175.1415929463@sandelman.ca> In-Reply-To: <12175.1415929463@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.133] 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/vNT7JJNUqDin1EPXW5VfNDoRqXg Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 03:14:06 -0000 I mentioned EAP because it does not require to change AAA infrastructure to= interwork with, and AAA is needed where a huge number of nodes have to be = managed. In smart meter use case, the number can be tens of millions of sm= art meters with hundreds of thousands of PCE for a single utility company. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Friday, November 14, 2014 10:44 AM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architec= ture draft wrote: > It is unfortunate that some contributors felt that EAP-based approach > does not work for them, but there is another use case where EAP-based > approach is definitely needed (smart meters). Having said that it > would make sense to have two options (DTLS-based and EAP-based > approaches) for joining operation. 1) Can you explain why smart meters have to use EAP methods? 2) can someone explain why smart meters are in scope for this WG? I thought it was mostly industrial applications. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Nov 13 19:26:38 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 C25EC1A1BA3; Thu, 13 Nov 2014 19:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 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, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 eVZI4LDJ8UoZ; Thu, 13 Nov 2014 19:26:30 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2610A1A03A5; Thu, 13 Nov 2014 19:26:29 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sAE3QSWK010464; Fri, 14 Nov 2014 12:26:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sAE3QRCX023667; Fri, 14 Nov 2014 12:26:27 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id NAA23659; Fri, 14 Nov 2014 12:26:27 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sAE3QQDQ001461; Fri, 14 Nov 2014 12:26:26 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAE3QPXj004196; Fri, 14 Nov 2014 12:26:25 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 12:26:25 +0900 From: To: Thread-Topic: [6tisch] [6tisch-security] proposed security text for architecture draft Thread-Index: AQHP/7ggnmszuPai2ke5o8rzw2udIpxfct+A Date: Fri, 14 Nov 2014 03:26:24 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> In-Reply-To: <29465.1415934436@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.133] 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/gHzAt-IIJ_5qTriiWZo80TnEkvk Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 03:26:34 -0000 Michael, Use of EAP-TLS and terminating TLS session at AAA server does not mean that= all parameters have to be coming from AAA server. Especially when PANA is= used, PAA can be co-located with JCE and provide 6top data over a secure P= ANA SA. Actually this model applies to any EAP method. Also, use of PANA with relay function neither requires a routable solution = such as loose source routing to convey authentication message between JCE a= nd JN nor requires a per-JN state on JA. Regards, Yoshihiro Ohba -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Richa= rdson Sent: Friday, November 14, 2014 12:07 PM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch] [6tisch-security] proposed security text for architec= ture draft {Please note that I am very familiar with EAP mechanisms, and I wrote EAP-S= IM for Freeradius a decade ago, when the document was going through many c= hanges} wrote: > Regarding EAP method, I mentioned EAP-TLS. EAP-TLS works for both > certificate-based authentication and pre-shared key based > authentication (EAP-TLS-PSK) without EAP tunneling method such as > EAP-TTLS. In the latter case, TLS session is typically terminated at > AAA server. But, since the EAP-TLS session terminates at the the AAA server, all of the= communications that we want to do (the 6top data), would have to come from the AAA server. =20 That means installing all of 6top/DTLS/CoAP code into the radius server. =20 (That's because the EAP-TLS is between AAA(radius) server and joining node)= Is that really what you want to do? What other things would the AAA server provide to the joining node? Are you thinking about various kinds of group policies, etc? --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Thu Nov 13 22:12:06 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 B98921A0144; Thu, 13 Nov 2014 22:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 YcwelnEDHS0S; Thu, 13 Nov 2014 22:11:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C951A6F98; Thu, 13 Nov 2014 22:11:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C076620098; Fri, 14 Nov 2014 01:14:10 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A1962637F4; Fri, 14 Nov 2014 01:11:55 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A384637F2; Fri, 14 Nov 2014 01:11:55 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@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/qYg8OBUqBgZS6GEoxPBBJnE0OEo Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 06:12:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > Use of EAP-TLS and terminating TLS session at AAA server does not mean > that all parameters have to be coming from AAA server. Especially wh= en > PANA is used, PAA can be co-located with JCE and provide 6top data ov= er > a secure PANA SA. Actually this model applies to any EAP method. So, we would be creating a masterkey with EAP-TLS, and then we would use PA= NA as a transport for CoAP? I understand why we want to use EAP when we have devices with humans at the far end;=20 1) it means the pieces in the middle do not need to know anything about the kind of authentication will be done 2) we can deploy new forms of authentication (such as challenge response methods, and things like EAP-SIM or EAP-AKA) without changes to the midd= le machines. 3) we can proxy things all the way back to the users home service, which is= =20 how GSM roaming works these days. I'm unaware that industrial/deterministic uses of 15.4 have requirements for ths kind of thing. I seem to recall a conversation about whether or not including a SIM card into nodes would work from a power, size, and cost poi= nt of view. Having a replaceable SIM card would definitely be a really easy w= ay to imprint new devices. If someone can do that, then we really don't need any of this...=20 =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) iQEVAwUBVGWdKICLcPvd0N1lAQLrLQf+LaElM4ilIQo9QkfiJ69ytYAUND8ZjhgU YjFNzEevqDu/4fNtH6Iq4xT4LdjO4evaklMr/QnHCZ+swm085l61cKa/cE16ybDq EMpI6GS6jRcIlk5Mvab1QkcuZfGa4iNdk1Bek3P0xlOpoQYaqdne09RR+k+yJOYd aq5sgnA8+cZLX1/E6f2nol7T9ckvLW4sQsVu1qiTmBMXXBdP97Z2ehCe43ZGfJy2 qXr8PJS4td6m3/G9w8QRI/bJK54ZNOIUFeVqdb4Yx+DKdgQAj8bicUXtwu0+DPNG dyBnjXrL2tu2QUiknt3cZ08a4FV+1195BTN+rVSlHpl3bKCAcvmr2w== =dESz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 13 22:20:51 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 440001A7021; Thu, 13 Nov 2014 22:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 UHUJkFhpi8oo; Thu, 13 Nov 2014 22:20:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9DD1A0144; Thu, 13 Nov 2014 22:20:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1A2520098; Fri, 14 Nov 2014 01:22:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E41A8637F4; Fri, 14 Nov 2014 01:20:41 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CD5F7637F2; Fri, 14 Nov 2014 01:20:41 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9867@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <12175.1415929463@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9867@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/ese9Yn0lSYPMmZkoXlXmPGMsjbA Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 06:20:44 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > I mentioned EAP because it does not require to change AAA > infrastructure to interwork with, and AAA is needed where a huge numb= er > of nodes have to be managed. In smart meter use case, the number can > be tens of millions of smart meters with hundreds of thousands of PCE > for a single utility company. I agree with your concern about the need for a scalable backend when there are millions of smart meters. Can you tell me a bit about the legacy AAA infrastructure whose existence=20 you want to leverage: I'm all for resuing existing, fully paid-up infrastru= cture. What does it do now (before smart meters are installed).=20=20 Will this AAA infrastructure already have the capacity for these tens of millions of smart meters? If an interface to an AAA infrastructure was desired, I would add that as a northbound interface on the JCE. For millions of smart meters, I would imagine deploying JCEs for groups of maybe ~10^3 to ~10^5 meters, and the t= he JCE would speak radius to the AAA. It would use the joining node's IDevID to discovery the right policy for this meter. It could also take this from LDA= P, From=20a RESTful interface, or via database interface directly.=20=20 It doesn't really matter... I don't think meters need roaming support, but maybe there is a use case I don't know about. Also, I do not claim that any of the 6tisch industrial zero-touch system is appropriate for non-industrial uses. It probably a non-starter in the home that lacks any kind of professional manager, and also lacks someone to run the authorization authority. =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) iQEVAwUBVGWfNoCLcPvd0N1lAQJq9Af/bzAPmAhkIIvR8CRuOYu19VVdBR8Czmi4 L+NDKKNzPJR00CAieKIJCicqsWFep8KdJFs/PY8kjqoMMtVmfgsFHRk3xMrO+C+f /HpoN+0uHHop3RrH5E9eVdjaPBqQob/q7Z/gq75d63qxjj47dCUkSzYyYLJl4gQT 0+n33WL+jy6AMr/Q1e2vXpbmC6hiTvG5grokT+25PLvzn+CCRct3lp5vBCR5UmKy BDg8gSW+oMsMPy7kfokmUflL+L79y19fnRf09DYgQT7wn2cpR/9i4e7AJlqNvQtr OERGEOb4MMVSV09bCUf9UV/V/kgyCimXfpILbgC1lWeKEFCxLswHEA== =zzIj -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 14 01:50:29 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 073451A87E0; Fri, 14 Nov 2014 01:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 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, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2iapF6vTmUZ9; Fri, 14 Nov 2014 01:50:22 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6821A87EE; Fri, 14 Nov 2014 01:50:16 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sAE9oEMv026339; Fri, 14 Nov 2014 18:50:14 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sAE9oECV023272; Fri, 14 Nov 2014 18:50:14 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA23266; Fri, 14 Nov 2014 18:50:13 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sAE9oDo8013530; Fri, 14 Nov 2014 18:50:13 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id sAE9oDRb027292; Fri, 14 Nov 2014 18:50:13 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 18:50:12 +0900 From: To: Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0Ixw Date: Fri, 14 Nov 2014 09:50:11 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> In-Reply-To: <2187.1415945515@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.165] 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/5iQFzgkziNYykbYxtb9A4lOAY4g Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 09:50:25 -0000 Here is main PANA use: 1. Creating a PANA SA (based on EAP MSK) between JCE and JN where JCE is PA= A, JN is PaC, and JA is PANA relay. (PANA relay is a stateless relay as described in RFC 6345, and no need for = loose source routing or ULA allocation.) 2. Using the SA to securely distribute locally significant credentials such= as a 802.11AR LDevID certificate or a network-wide shared symmetric key, a= nd I am not in favor of the latter though :)=20 For 1), existing RADIUS servers can be used if EAP server is a physically s= eparated from PCE box where scalability is needed. EAP-based approach can = also support roaming cases where electric vehicles are authenticated via sm= art meters. For 2) we can define new PANA attributes to carry RFC 4210 CertRequest and = CertResponse defined by PKIX for distributing 802.11AR LDevID certificate. I did not think to use PANA to carry CoAP messages. I think DTLS should be = used for protecting CoAP for 6top as being discussed. The DTLS session for= CoAP can be established, e.g., by using the locally significant credential= s distributed in 2). Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would make = 6tisch more attractive to cover certain business scenarios. Please note that I do not disagree with DTLS-based approach for more resour= ce constrained device (although more work seems to be needed to carry DTLS = message between JCE and JN via JA), but we should support multiple options = if one solution is difficult to cover all cases. =20 Best Regards, Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Friday, November 14, 2014 3:12 PM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architec= ture draft wrote: > Use of EAP-TLS and terminating TLS session at AAA server does not mea= n > that all parameters have to be coming from AAA server. Especially wh= en > PANA is used, PAA can be co-located with JCE and provide 6top data ov= er > a secure PANA SA. Actually this model applies to any EAP method. So, we would be creating a masterkey with EAP-TLS, and then we would use PA= NA as a transport for CoAP? I understand why we want to use EAP when we have devices with humans at the= far end; 1) it means the pieces in the middle do not need to know anything about the kind of authentication will be done 2) we can deploy new forms of authentication (such as challenge response methods, and things like EAP-SIM or EAP-AKA) without changes to the midd= le machines. 3) we can proxy things all the way back to the users home service, which is= =20 how GSM roaming works these days. I'm unaware that industrial/deterministic uses of 15.4 have requirements fo= r ths kind of thing. I seem to recall a conversation about whether or not = including a SIM card into nodes would work from a power, size, and cost poi= nt of view. Having a replaceable SIM card would definitely be a really eas= y way to imprint new devices. If someone can do that, then we really don't= need any of this...=20 -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Nov 14 09:51:50 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 F320F1A1B47; Fri, 14 Nov 2014 09:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 MjceWRREoTQT; Fri, 14 Nov 2014 09:51:45 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B751A1B12; Fri, 14 Nov 2014 09:51:45 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id tp5so18546914ieb.15 for ; Fri, 14 Nov 2014 09:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KO4WlMvGKSzKjkePEXYxJNt94esDU1Cftv+v+zVZL/E=; b=zsZU40MXnBzDv6S2rVCHnYGMyDu9y0fuoQ7ehMnUa3TBAmSQrNRDe+fZb0GHWjZ8dd JOx+/qnlm9p/RHB8KqOfw8W6RHZIDxksem3K8CJbaIKQHFrpx8C4p/pstSWJbBunC5HL RCHbvxlFFisstCvsQr+0gjL6KpvBYyPznlgY40BEAYmDjCRKxlLacCk8H9SKKtXyX/wF RtF5LL3NMsGcDSmsj6jEpWNf44uaQ3bkgwVWYqVfhUB/WwnhmiwiqF3C+2fYnCsGMbj6 xZuYmgvnZW85L5c5kVKLWOSCu0fam6XNtsmFq87mfTxSKsTFp3nsInOzmsM/U+JdOQfL Gfeg== MIME-Version: 1.0 X-Received: by 10.107.165.19 with SMTP id o19mr11772250ioe.1.1415987504820; Fri, 14 Nov 2014 09:51:44 -0800 (PST) Received: by 10.42.246.136 with HTTP; Fri, 14 Nov 2014 09:51:44 -0800 (PST) In-Reply-To: <12175.1415929463@sandelman.ca> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <12175.1415929463@sandelman.ca> Date: Fri, 14 Nov 2014 12:51:44 -0500 Message-ID: From: Subir Das To: Michael Richardson Content-Type: multipart/alternative; boundary=001a1141f1d23b44c50507d54803 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/UBaqYiwIrBn9FlIR5cUUBVo-Wn0 Cc: 6tisch@ietf.org, 6tisch-security@ietf.org, "yoshihiro.ohba@toshiba.co.jp" Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 17:51:47 -0000 --001a1141f1d23b44c50507d54803 Content-Type: text/plain; charset=UTF-8 1) Can you explain why smart meters have to use EAP methods? It does not have to use but the reality is Advanced Metering Networks is using EAP today. 2) can someone explain why smart meters are in scope for this WG? I can mention one use case: Zigbee NAN is using TSCH as one of the MACs and then IPv6... On Thu, Nov 13, 2014 at 8:44 PM, Michael Richardson wrote: > > wrote: > > It is unfortunate that some contributors felt that EAP-based approach > > does not work for them, but there is another use case where EAP-based > > approach is definitely needed (smart meters). Having said that it > > would make sense to have two options (DTLS-based and EAP-based > > approaches) for joining operation. > > 1) Can you explain why smart meters have to use EAP methods? > 2) can someone explain why smart meters are in scope for this WG? > > I thought it was mostly industrial applications. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --001a1141f1d23b44c50507d54803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1) Can you explain why smart meters have to use EAP m= ethods?

=C2=A0=C2=A0 It does not have to use but th= e reality is Advanced Metering Networks is using EAP today.

2) can someone explain why smart meters are in scope for this WG?

=C2=A0=C2=A0=C2=A0 I can mention one use case: Zigbee NAN=C2=A0 is= using TSCH as one of the MACs and then IPv6...

On Thu, Nov 13, = 2014 at 8:44 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

<yoshihiro.ohba@toshiba.= co.jp> wrote:
=C2=A0 =C2=A0 > It is unfortunate that some contributors felt that EAP-b= ased approach
=C2=A0 =C2=A0 > does not work for them, but there is another use case wh= ere EAP-based
=C2=A0 =C2=A0 > approach is definitely needed (smart meters).=C2=A0 Havi= ng said that it
=C2=A0 =C2=A0 > would make sense to have two options (DTLS-based and EAP= -based
=C2=A0 =C2=A0 > approaches) for joining operation.

1) Can you explain why smart meters have to use EAP methods?
2) can someone explain why smart meters are in scope for this WG?

I thought it was mostly industrial applications.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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


--001a1141f1d23b44c50507d54803-- From nobody Fri Nov 14 10:25: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 6E2761A6F7F; Fri, 14 Nov 2014 10:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.645 X-Spam-Level: X-Spam-Status: No, score=-12.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 PI1-x_cKX_sV; Fri, 14 Nov 2014 10:25:12 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142B11A6F68; Fri, 14 Nov 2014 10:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5970; q=dns/txt; s=iport; t=1415989512; x=1417199112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FwWQ8EwqDuZobD7OWyji0Qjef32bx+R/twZNUigkh3E=; b=Ss/Iej/BghzDnRmiOx/RSiXeIkHku8CgRD9SJvxrw9LG2JkNRfJXvbau wPmOnPaR9is748dDI4VVCnVCh2sAk4CURrW0W1UIqFgy0xA95aSPso0Vr EGqueFVa44Q9f1xBnOCNFbnwLxwm61c8v2nMElyxj6fguAFOD+XsdF7fk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0IAJ1HZlStJV2b/2dsb2JhbABRCoMOVVmDBsl1CoZ5VQIcgQAWAQEBAQFyC4QCAQEBAwEBAQEJKDMHCwwEAgEGAhEBAwEBAQQjBQICJQsUAwYIAgQOBRuIHQkNnmKcawiWMQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSmMJAGCeA5OBwaCbTqBHgEEkkeMBYE0g1SNaIQKghCBbG2CSwEBAQ X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="96722975" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 14 Nov 2014 18:25:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAEIPBbE030957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 18:25:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 12:25:10 -0600 From: "Pascal Thubert (pthubert)" To: "yoshihiro.ohba@toshiba.co.jp" Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0IxwgACgdYU= Date: Fri, 14 Nov 2014 18:25:09 +0000 Message-ID: <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Ltn9B8bi444-7iNONtXGqXczEWs Cc: "mcr+ietf@sandelman.ca" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 18:25:17 -0000 SGVsbG8gWW9zaGk6DQoNClBsZWFzZSBzZWUgYmVsb3cgYW5kIG1hbnkgdGhhbmtzIGZvciBhbGwg dGhpcyANCg0KUGFzY2FsDQo+IExlIDEzIG5vdi4gMjAxNCCopCAyMzo1MCwgInlvc2hpaGlyby5v aGJhQHRvc2hpYmEuY28uanAiIDx5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPiBhIKimY3Jp dCA6DQo+IA0KPiBIZXJlIGlzIG1haW4gUEFOQSB1c2U6DQo+IA0KPiAxLiBDcmVhdGluZyBhIFBB TkEgU0EgKGJhc2VkIG9uIEVBUCBNU0spIGJldHdlZW4gSkNFIGFuZCBKTiB3aGVyZSBKQ0UgaXMg UEFBLCBKTiBpcyBQYUMsIGFuZCBKQSBpcyBQQU5BIHJlbGF5Lg0KPiAoUEFOQSByZWxheSBpcyBh IHN0YXRlbGVzcyByZWxheSBhcyBkZXNjcmliZWQgaW4gUkZDIDYzNDUsIGFuZCBubyBuZWVkIGZv ciBsb29zZSBzb3VyY2Ugcm91dGluZyBvciBVTEEgYWxsb2NhdGlvbi4pDQoNCk9uIHRoaXMgSSBy ZXNwZWN0ZnVsbHkgZGlzYWdyZWUuDQoNClRoZSBJUCBhZGRyZXNzIG9mIHRoZSBQYUMgaXMgbm90 IHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gaWRlbnRpZnkgdGhlIGpvaW4gYnVuZGxlIHNob3Vs ZCB0aGVyZSBiZSBtb3JlIHRoYW4gb25lLg0KDQpUaGlzIGlzIHdoeSBSSCB1c3VhbGx5IGNhcnJp ZXMgVUxBIG9yIGdsb2JhbCBhZGRyZXNzZXMsIHdpdGggdGhlIGludGVudGlvbiB0aGF0IHRoZSBw cmVmaXggaW5kaWNhdGVzIHRoZSBuZXh0IGludGVyZmFjZSAtIHRvIHlvdXIgZWFybGllciBwb2lu dC4NCg0KQnV0IHRoZW4gaW4gYSBNTCBzdWJuZXR3b3JrIHRoaXMgaXMgbm8gaGVscCB3aGF0c29l dmVyIHNpbmNlIG11bHRpcGxlIGludGVyZmFjZXMgbWF5IGJlIG9uIGEgc2FtZSBzdWJuZXQuDQoN ClRoaXMgaXMgd2hlcmUgdGhlIFVMQSBjb21lcyBpbnRvIHBsYXk7IGhpZGluZyB0aGUgbmV0d29y ayBJRCBmcm9tIHVudHJ1c3RlZCBsdXJrZXJzIGFuZCB5ZXQgcHJvdmlkaW5nIGFuIHVuZXF1aXZv Y2FsIGJ1bmRsZSBJRC4NCg0KTWFrZXMgc2Vuc2U/DQoNClBhc2NhbA0KDQo+IA0KPiAyLiBVc2lu ZyB0aGUgU0EgdG8gc2VjdXJlbHkgZGlzdHJpYnV0ZSBsb2NhbGx5IHNpZ25pZmljYW50IGNyZWRl bnRpYWxzIHN1Y2ggYXMgYSA4MDIuMTFBUiBMRGV2SUQgY2VydGlmaWNhdGUgb3IgYSBuZXR3b3Jr LXdpZGUgc2hhcmVkIHN5bW1ldHJpYyBrZXksIGFuZCBJIGFtIG5vdCBpbiBmYXZvciBvZiB0aGUg bGF0dGVyIHRob3VnaCA6KSANCj4gDQo+IEZvciAxKSwgZXhpc3RpbmcgUkFESVVTIHNlcnZlcnMg Y2FuIGJlIHVzZWQgaWYgRUFQIHNlcnZlciBpcyBhIHBoeXNpY2FsbHkgc2VwYXJhdGVkIGZyb20g UENFIGJveCB3aGVyZSBzY2FsYWJpbGl0eSBpcyBuZWVkZWQuICBFQVAtYmFzZWQgYXBwcm9hY2gg Y2FuIGFsc28gc3VwcG9ydCByb2FtaW5nIGNhc2VzIHdoZXJlIGVsZWN0cmljIHZlaGljbGVzIGFy ZSBhdXRoZW50aWNhdGVkIHZpYSBzbWFydCBtZXRlcnMuDQo+IA0KPiBGb3IgMikgd2UgY2FuIGRl ZmluZSBuZXcgUEFOQSBhdHRyaWJ1dGVzIHRvIGNhcnJ5IFJGQyA0MjEwIENlcnRSZXF1ZXN0IGFu ZCBDZXJ0UmVzcG9uc2UgZGVmaW5lZCBieSBQS0lYIGZvciBkaXN0cmlidXRpbmcgODAyLjExQVIg TERldklEIGNlcnRpZmljYXRlLg0KPiANCj4gSSBkaWQgbm90IHRoaW5rIHRvIHVzZSBQQU5BIHRv IGNhcnJ5IENvQVAgbWVzc2FnZXMuIEkgdGhpbmsgRFRMUyBzaG91bGQgYmUgdXNlZCBmb3IgcHJv dGVjdGluZyBDb0FQIGZvciA2dG9wIGFzIGJlaW5nIGRpc2N1c3NlZC4gIFRoZSBEVExTIHNlc3Np b24gZm9yIENvQVAgY2FuIGJlIGVzdGFibGlzaGVkLCBlLmcuLCBieSB1c2luZyB0aGUgbG9jYWxs eSBzaWduaWZpY2FudCBjcmVkZW50aWFscyBkaXN0cmlidXRlZCBpbiAyKS4NCj4gDQo+IFN1cHBv cnQgZm9yIFVJTSBjYXJkICh2aWEgRUFQLVNJTSwgRUFQLUFLQSBvciBhIG5ldyBFQVAgbWV0aG9k KSB3b3VsZCBtYWtlIDZ0aXNjaCBtb3JlIGF0dHJhY3RpdmUgdG8gY292ZXIgIGNlcnRhaW4gYnVz aW5lc3Mgc2NlbmFyaW9zLg0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBJIGRvIG5vdCBkaXNhZ3Jl ZSB3aXRoIERUTFMtYmFzZWQgYXBwcm9hY2ggZm9yIG1vcmUgcmVzb3VyY2UgY29uc3RyYWluZWQg ZGV2aWNlIChhbHRob3VnaCBtb3JlIHdvcmsgc2VlbXMgdG8gYmUgbmVlZGVkIHRvIGNhcnJ5IERU TFMgbWVzc2FnZSBiZXR3ZWVuIEpDRSBhbmQgSk4gdmlhIEpBKSwgYnV0IHdlIHNob3VsZCBzdXBw b3J0IG11bHRpcGxlIG9wdGlvbnMgaWYgb25lIHNvbHV0aW9uIGlzIGRpZmZpY3VsdCB0byBjb3Zl ciBhbGwgY2FzZXMuICANCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gWW9zaGloaXJvIE9oYmENCj4g DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiA2dGlzY2gtc2VjdXJp dHkgW21haWx0bzo2dGlzY2gtc2VjdXJpdHktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1pY2hhZWwgUmljaGFyZHNvbg0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE0LCAyMDE0IDM6 MTIgUE0NCj4gVG86IG9oYmEgeW9zaGloaXJvKLTziPYgwXjR8yCh8KPSo8Sjw6H1o86j06PMKQ0K PiBDYzogNnRpc2NoQGlldGYub3JnOyA2dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFs2dGlzY2gtc2VjdXJpdHldIFs2dGlzY2hdIHByb3Bvc2VkIHNlY3VyaXR5IHRleHQg Zm9yIGFyY2hpdGVjdHVyZSBkcmFmdA0KPiANCj4gDQo+IDx5b3NoaWhpcm8ub2hiYUB0b3NoaWJh LmNvLmpwPiB3cm90ZToNCj4+IFVzZSBvZiBFQVAtVExTIGFuZCB0ZXJtaW5hdGluZyBUTFMgc2Vz c2lvbiBhdCBBQUEgc2VydmVyIGRvZXMgbm90IG1lYW4NCj4+IHRoYXQgYWxsIHBhcmFtZXRlcnMg aGF2ZSB0byBiZSBjb21pbmcgZnJvbSBBQUEgc2VydmVyLiAgRXNwZWNpYWxseSB3aGVuDQo+PiBQ QU5BIGlzIHVzZWQsIFBBQSBjYW4gYmUgY28tbG9jYXRlZCB3aXRoIEpDRSBhbmQgcHJvdmlkZSA2 dG9wIGRhdGEgb3Zlcg0KPj4gYSBzZWN1cmUgUEFOQSBTQS4gIEFjdHVhbGx5IHRoaXMgbW9kZWwg YXBwbGllcyB0byBhbnkgRUFQIG1ldGhvZC4NCj4gDQo+IFNvLCB3ZSB3b3VsZCBiZSBjcmVhdGlu ZyBhIG1hc3RlcmtleSB3aXRoIEVBUC1UTFMsIGFuZCB0aGVuIHdlIHdvdWxkIHVzZSBQQU5BIGFz IGEgdHJhbnNwb3J0IGZvciBDb0FQPw0KPiANCj4gSSB1bmRlcnN0YW5kIHdoeSB3ZSB3YW50IHRv IHVzZSBFQVAgd2hlbiB3ZSBoYXZlIGRldmljZXMgd2l0aCBodW1hbnMgYXQgdGhlIGZhciBlbmQ7 DQo+IDEpIGl0IG1lYW5zIHRoZSBwaWVjZXMgaW4gdGhlIG1pZGRsZSBkbyBub3QgbmVlZCB0byBr bm93IGFueXRoaW5nIGFib3V0IHRoZQ0KPiAgIGtpbmQgb2YgYXV0aGVudGljYXRpb24gd2lsbCBi ZSBkb25lDQo+IA0KPiAyKSB3ZSBjYW4gZGVwbG95IG5ldyBmb3JtcyBvZiBhdXRoZW50aWNhdGlv biAoc3VjaCBhcyBjaGFsbGVuZ2UgcmVzcG9uc2UNCj4gICBtZXRob2RzLCBhbmQgdGhpbmdzIGxp a2UgRUFQLVNJTSBvciBFQVAtQUtBKSB3aXRob3V0IGNoYW5nZXMgdG8gdGhlIG1pZGRsZQ0KPiAg IG1hY2hpbmVzLg0KPiANCj4gMykgd2UgY2FuIHByb3h5IHRoaW5ncyBhbGwgdGhlIHdheSBiYWNr IHRvIHRoZSB1c2VycyBob21lIHNlcnZpY2UsIHdoaWNoIGlzIA0KPiAgIGhvdyBHU00gcm9hbWlu ZyB3b3JrcyB0aGVzZSBkYXlzLg0KPiANCj4gSSdtIHVuYXdhcmUgdGhhdCBpbmR1c3RyaWFsL2Rl dGVybWluaXN0aWMgdXNlcyBvZiAxNS40IGhhdmUgcmVxdWlyZW1lbnRzIGZvciB0aHMga2luZCBv ZiB0aGluZy4gIEkgc2VlbSB0byByZWNhbGwgYSBjb252ZXJzYXRpb24gYWJvdXQgd2hldGhlciBv ciBub3QgaW5jbHVkaW5nIGEgU0lNIGNhcmQgaW50byBub2RlcyB3b3VsZCB3b3JrIGZyb20gYSBw b3dlciwgc2l6ZSwgYW5kIGNvc3QgcG9pbnQgb2Ygdmlldy4gIEhhdmluZyBhIHJlcGxhY2VhYmxl IFNJTSBjYXJkIHdvdWxkIGRlZmluaXRlbHkgYmUgYSByZWFsbHkgZWFzeSB3YXkgdG8gaW1wcmlu dCBuZXcgZGV2aWNlcy4gIElmIHNvbWVvbmUgY2FuIGRvIHRoYXQsIHRoZW4gd2UgcmVhbGx5IGRv bid0IG5lZWQgYW55IG9mIHRoaXMuLi4gDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAgLT0gSVB2 NiBJb1QgY29uc3VsdGluZyA9LQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA2dGlzY2gtc2VjdXJpdHkgbWFpbGluZyBsaXN0 DQo+IDZ0aXNjaC1zZWN1cml0eUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZ0aXNjaC1zZWN1cml0eQ0K From nobody Fri Nov 14 12:00: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 8BFBF1A9043; Fri, 14 Nov 2014 12:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 no0Tptt3RiGg; Fri, 14 Nov 2014 12:00:02 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07431A9099; Fri, 14 Nov 2014 12:00:00 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAEJxt6h026879; Sat, 15 Nov 2014 04:59:55 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAEJxt2j018461; Sat, 15 Nov 2014 04:59:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id EAA18460; Sat, 15 Nov 2014 04:59:55 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAEJxssO004998; Sat, 15 Nov 2014 04:59:55 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAEJxsFH024357; Sat, 15 Nov 2014 04:59:54 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.194]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 04:59:54 +0900 From: To: Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0IxwgACgdYWAABePkA== Date: Fri, 14 Nov 2014 19:59:54 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> In-Reply-To: <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.234] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/vyGzB_FxVdu9eFXD9E0kK41DRDw Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 20:00:07 -0000 SGkgUGFzY2FsLA0KDQpDYW4geW91IHBsZWFzZSBleHBsYWluIGEgdXNlIGNhc2Ugd2hlcmUgYSBK QSBoYXMgbXVsdGlwbGUgTExOIGludGVyZmFjZXMgYXMgSSBjb3VsZCBmaW5kIGl0IGluIGRyYWZ0 LWlldGYtNnRpc2NoLWFyY2hpdGVjdHVyZT8NCg0KSWYgbXVsdGlwbGUgTExOIGludGVyZmFjZXMg bmVlZCB0byBiZSBzdXBwb3J0ZWQsIHRoZW4gSSBhZ3JlZSB0aGF0IGxpbmstbG9jYWwgYWRkcmVz cyBzb2xlbHkgZG9lcyBub3Qgd29yayBmb3IgYSBKTiB0byBjb21tdW5pY2F0ZSB3aXRoIGEgSkNF IHZpYSBhIEpBIHVzaW5nIGEgcmVsYXkgb3IgYSBSSCBvciB3aGF0c29ldmVyLg0KDQpZb3NoaWhp cm8gT2hiYQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhc2NhbCBU aHViZXJ0IChwdGh1YmVydCkgW21haWx0bzpwdGh1YmVydEBjaXNjby5jb21dIA0KU2VudDogU2F0 dXJkYXksIE5vdmVtYmVyIDE1LCAyMDE0IDM6MjUgQU0NClRvOiBvaGJhIHlvc2hpaGlybyi084j2 IMF40fMgofCj0qPEo8Oh9aPOo9OjzCkNCkNjOiBtY3IraWV0ZkBzYW5kZWxtYW4uY2E7IDZ0aXNj aEBpZXRmLm9yZzsgNnRpc2NoLXNlY3VyaXR5QGlldGYub3JnDQpTdWJqZWN0OiBSZTogWzZ0aXNj aC1zZWN1cml0eV0gWzZ0aXNjaF0gcHJvcG9zZWQgc2VjdXJpdHkgdGV4dCBmb3IgYXJjaGl0ZWN0 dXJlIGRyYWZ0DQoNCkhlbGxvIFlvc2hpOg0KDQpQbGVhc2Ugc2VlIGJlbG93IGFuZCBtYW55IHRo YW5rcyBmb3IgYWxsIHRoaXMgDQoNClBhc2NhbA0KPiBMZSAxMyBub3YuIDIwMTQgqKQgMjM6NTAs ICJ5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwIiA8eW9zaGloaXJvLm9oYmFAdG9zaGliYS5j by5qcD4gYSCopmNyaXQgOg0KPiANCj4gSGVyZSBpcyBtYWluIFBBTkEgdXNlOg0KPiANCj4gMS4g Q3JlYXRpbmcgYSBQQU5BIFNBIChiYXNlZCBvbiBFQVAgTVNLKSBiZXR3ZWVuIEpDRSBhbmQgSk4g d2hlcmUgSkNFIGlzIFBBQSwgSk4gaXMgUGFDLCBhbmQgSkEgaXMgUEFOQSByZWxheS4NCj4gKFBB TkEgcmVsYXkgaXMgYSBzdGF0ZWxlc3MgcmVsYXkgYXMgZGVzY3JpYmVkIGluIFJGQyA2MzQ1LCBh bmQgbm8gbmVlZCANCj4gZm9yIGxvb3NlIHNvdXJjZSByb3V0aW5nIG9yIFVMQSBhbGxvY2F0aW9u LikNCg0KT24gdGhpcyBJIHJlc3BlY3RmdWxseSBkaXNhZ3JlZS4NCg0KVGhlIElQIGFkZHJlc3Mg b2YgdGhlIFBhQyBpcyBub3Qgc3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byBpZGVudGlmeSB0aGUg am9pbiBidW5kbGUgc2hvdWxkIHRoZXJlIGJlIG1vcmUgdGhhbiBvbmUuDQoNClRoaXMgaXMgd2h5 IFJIIHVzdWFsbHkgY2FycmllcyBVTEEgb3IgZ2xvYmFsIGFkZHJlc3Nlcywgd2l0aCB0aGUgaW50 ZW50aW9uIHRoYXQgdGhlIHByZWZpeCBpbmRpY2F0ZXMgdGhlIG5leHQgaW50ZXJmYWNlIC0gdG8g eW91ciBlYXJsaWVyIHBvaW50Lg0KDQpCdXQgdGhlbiBpbiBhIE1MIHN1Ym5ldHdvcmsgdGhpcyBp cyBubyBoZWxwIHdoYXRzb2V2ZXIgc2luY2UgbXVsdGlwbGUgaW50ZXJmYWNlcyBtYXkgYmUgb24g YSBzYW1lIHN1Ym5ldC4NCg0KVGhpcyBpcyB3aGVyZSB0aGUgVUxBIGNvbWVzIGludG8gcGxheTsg aGlkaW5nIHRoZSBuZXR3b3JrIElEIGZyb20gdW50cnVzdGVkIGx1cmtlcnMgYW5kIHlldCBwcm92 aWRpbmcgYW4gdW5lcXVpdm9jYWwgYnVuZGxlIElELg0KDQpNYWtlcyBzZW5zZT8NCg0KUGFzY2Fs DQoNCj4gDQo+IDIuIFVzaW5nIHRoZSBTQSB0byBzZWN1cmVseSBkaXN0cmlidXRlIGxvY2FsbHkg c2lnbmlmaWNhbnQgY3JlZGVudGlhbHMgDQo+IHN1Y2ggYXMgYSA4MDIuMTFBUiBMRGV2SUQgY2Vy dGlmaWNhdGUgb3IgYSBuZXR3b3JrLXdpZGUgc2hhcmVkIA0KPiBzeW1tZXRyaWMga2V5LCBhbmQg SSBhbSBub3QgaW4gZmF2b3Igb2YgdGhlIGxhdHRlciB0aG91Z2ggOikNCj4gDQo+IEZvciAxKSwg ZXhpc3RpbmcgUkFESVVTIHNlcnZlcnMgY2FuIGJlIHVzZWQgaWYgRUFQIHNlcnZlciBpcyBhIHBo eXNpY2FsbHkgc2VwYXJhdGVkIGZyb20gUENFIGJveCB3aGVyZSBzY2FsYWJpbGl0eSBpcyBuZWVk ZWQuICBFQVAtYmFzZWQgYXBwcm9hY2ggY2FuIGFsc28gc3VwcG9ydCByb2FtaW5nIGNhc2VzIHdo ZXJlIGVsZWN0cmljIHZlaGljbGVzIGFyZSBhdXRoZW50aWNhdGVkIHZpYSBzbWFydCBtZXRlcnMu DQo+IA0KPiBGb3IgMikgd2UgY2FuIGRlZmluZSBuZXcgUEFOQSBhdHRyaWJ1dGVzIHRvIGNhcnJ5 IFJGQyA0MjEwIENlcnRSZXF1ZXN0IGFuZCBDZXJ0UmVzcG9uc2UgZGVmaW5lZCBieSBQS0lYIGZv ciBkaXN0cmlidXRpbmcgODAyLjExQVIgTERldklEIGNlcnRpZmljYXRlLg0KPiANCj4gSSBkaWQg bm90IHRoaW5rIHRvIHVzZSBQQU5BIHRvIGNhcnJ5IENvQVAgbWVzc2FnZXMuIEkgdGhpbmsgRFRM UyBzaG91bGQgYmUgdXNlZCBmb3IgcHJvdGVjdGluZyBDb0FQIGZvciA2dG9wIGFzIGJlaW5nIGRp c2N1c3NlZC4gIFRoZSBEVExTIHNlc3Npb24gZm9yIENvQVAgY2FuIGJlIGVzdGFibGlzaGVkLCBl LmcuLCBieSB1c2luZyB0aGUgbG9jYWxseSBzaWduaWZpY2FudCBjcmVkZW50aWFscyBkaXN0cmli dXRlZCBpbiAyKS4NCj4gDQo+IFN1cHBvcnQgZm9yIFVJTSBjYXJkICh2aWEgRUFQLVNJTSwgRUFQ LUFLQSBvciBhIG5ldyBFQVAgbWV0aG9kKSB3b3VsZCBtYWtlIDZ0aXNjaCBtb3JlIGF0dHJhY3Rp dmUgdG8gY292ZXIgIGNlcnRhaW4gYnVzaW5lc3Mgc2NlbmFyaW9zLg0KPiANCj4gUGxlYXNlIG5v dGUgdGhhdCBJIGRvIG5vdCBkaXNhZ3JlZSB3aXRoIERUTFMtYmFzZWQgYXBwcm9hY2ggZm9yIG1v cmUgcmVzb3VyY2UgY29uc3RyYWluZWQgZGV2aWNlIChhbHRob3VnaCBtb3JlIHdvcmsgc2VlbXMg dG8gYmUgbmVlZGVkIHRvIGNhcnJ5IERUTFMgbWVzc2FnZSBiZXR3ZWVuIEpDRSBhbmQgSk4gdmlh IEpBKSwgYnV0IHdlIHNob3VsZCBzdXBwb3J0IG11bHRpcGxlIG9wdGlvbnMgaWYgb25lIHNvbHV0 aW9uIGlzIGRpZmZpY3VsdCB0byBjb3ZlciBhbGwgY2FzZXMuICANCj4gDQo+IEJlc3QgUmVnYXJk cywNCj4gWW9zaGloaXJvIE9oYmENCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiA2dGlzY2gtc2VjdXJpdHkgW21haWx0bzo2dGlzY2gtc2VjdXJpdHktYm91bmNl c0BpZXRmLm9yZ10gT24gDQo+IEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NCj4gU2VudDog RnJpZGF5LCBOb3ZlbWJlciAxNCwgMjAxNCAzOjEyIFBNDQo+IFRvOiBvaGJhIHlvc2hpaGlybyi0 84j2IMF40fMgofCj0qPEo8Oh9aPOo9OjzCkNCj4gQ2M6IDZ0aXNjaEBpZXRmLm9yZzsgNnRpc2No LXNlY3VyaXR5QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbNnRpc2NoLXNlY3VyaXR5XSBbNnRp c2NoXSBwcm9wb3NlZCBzZWN1cml0eSB0ZXh0IGZvciANCj4gYXJjaGl0ZWN0dXJlIGRyYWZ0DQo+ IA0KPiANCj4gPHlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA+IHdyb3RlOg0KPj4gVXNlIG9m IEVBUC1UTFMgYW5kIHRlcm1pbmF0aW5nIFRMUyBzZXNzaW9uIGF0IEFBQSBzZXJ2ZXIgZG9lcyBu b3QgDQo+PiBtZWFuIHRoYXQgYWxsIHBhcmFtZXRlcnMgaGF2ZSB0byBiZSBjb21pbmcgZnJvbSBB QUEgc2VydmVyLiAgDQo+PiBFc3BlY2lhbGx5IHdoZW4gUEFOQSBpcyB1c2VkLCBQQUEgY2FuIGJl IGNvLWxvY2F0ZWQgd2l0aCBKQ0UgYW5kIA0KPj4gcHJvdmlkZSA2dG9wIGRhdGEgb3ZlciBhIHNl Y3VyZSBQQU5BIFNBLiAgQWN0dWFsbHkgdGhpcyBtb2RlbCBhcHBsaWVzIHRvIGFueSBFQVAgbWV0 aG9kLg0KPiANCj4gU28sIHdlIHdvdWxkIGJlIGNyZWF0aW5nIGEgbWFzdGVya2V5IHdpdGggRUFQ LVRMUywgYW5kIHRoZW4gd2Ugd291bGQgdXNlIFBBTkEgYXMgYSB0cmFuc3BvcnQgZm9yIENvQVA/ DQo+IA0KPiBJIHVuZGVyc3RhbmQgd2h5IHdlIHdhbnQgdG8gdXNlIEVBUCB3aGVuIHdlIGhhdmUg ZGV2aWNlcyB3aXRoIGh1bWFucyANCj4gYXQgdGhlIGZhciBlbmQ7DQo+IDEpIGl0IG1lYW5zIHRo ZSBwaWVjZXMgaW4gdGhlIG1pZGRsZSBkbyBub3QgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0 IHRoZQ0KPiAgIGtpbmQgb2YgYXV0aGVudGljYXRpb24gd2lsbCBiZSBkb25lDQo+IA0KPiAyKSB3 ZSBjYW4gZGVwbG95IG5ldyBmb3JtcyBvZiBhdXRoZW50aWNhdGlvbiAoc3VjaCBhcyBjaGFsbGVu Z2UgcmVzcG9uc2UNCj4gICBtZXRob2RzLCBhbmQgdGhpbmdzIGxpa2UgRUFQLVNJTSBvciBFQVAt QUtBKSB3aXRob3V0IGNoYW5nZXMgdG8gdGhlIG1pZGRsZQ0KPiAgIG1hY2hpbmVzLg0KPiANCj4g Mykgd2UgY2FuIHByb3h5IHRoaW5ncyBhbGwgdGhlIHdheSBiYWNrIHRvIHRoZSB1c2VycyBob21l IHNlcnZpY2UsIHdoaWNoIGlzIA0KPiAgIGhvdyBHU00gcm9hbWluZyB3b3JrcyB0aGVzZSBkYXlz Lg0KPiANCj4gSSdtIHVuYXdhcmUgdGhhdCBpbmR1c3RyaWFsL2RldGVybWluaXN0aWMgdXNlcyBv ZiAxNS40IGhhdmUgcmVxdWlyZW1lbnRzIGZvciB0aHMga2luZCBvZiB0aGluZy4gIEkgc2VlbSB0 byByZWNhbGwgYSBjb252ZXJzYXRpb24gYWJvdXQgd2hldGhlciBvciBub3QgaW5jbHVkaW5nIGEg U0lNIGNhcmQgaW50byBub2RlcyB3b3VsZCB3b3JrIGZyb20gYSBwb3dlciwgc2l6ZSwgYW5kIGNv c3QgcG9pbnQgb2Ygdmlldy4gIEhhdmluZyBhIHJlcGxhY2VhYmxlIFNJTSBjYXJkIHdvdWxkIGRl ZmluaXRlbHkgYmUgYSByZWFsbHkgZWFzeSB3YXkgdG8gaW1wcmludCBuZXcgZGV2aWNlcy4gIElm IHNvbWVvbmUgY2FuIGRvIHRoYXQsIHRoZW4gd2UgcmVhbGx5IGRvbid0IG5lZWQgYW55IG9mIHRo aXMuLi4gDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1h bi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyAgDQo+IC09IElQdjYgSW9UIGNvbnN1bHRp bmcgPS0NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gNnRpc2NoLXNlY3VyaXR5IG1haWxpbmcgbGlzdA0KPiA2dGlzY2gtc2Vj dXJpdHlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82 dGlzY2gtc2VjdXJpdHkNCg== From nobody Fri Nov 14 16:40:38 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 98C111A890A; Fri, 14 Nov 2014 03:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 yR0UE9ULtljw; Fri, 14 Nov 2014 03:31:36 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 7154B1A878C; Fri, 14 Nov 2014 03:31:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id ED92ECC88; Fri, 14 Nov 2014 12:31:33 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gorap-zEVJrJ; Fri, 14 Nov 2014 12:31:33 +0100 (CET) Received: from [192.168.1.42] (18.Red-81-39-160.dynamicIP.rima-tde.net [81.39.160.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id 518F4A69; Fri, 14 Nov 2014 12:31:29 +0100 (CET) Content-Type: text/plain; charset=iso-2022-jp-2 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rafa Marin Lopez In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> Date: Fri, 14 Nov 2014 12:31:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> To: yoshihiro.ohba@toshiba.co.jp X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/yFd-LMDRIeB2Ut6iaw5TkCtKlZ4 X-Mailman-Approved-At: Fri, 14 Nov 2014 16:40:37 -0800 Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org, Rafa Marin Lopez Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 14 Nov 2014 11:31:39 -0000 Hi Yoshi: I think this is a reasonable architecture for security, which would = cover several important use cases in my opinion. Some comments inline... El 14/11/2014, a las 10:50, = escribi=1B.A=1BNs: > Here is main PANA use: >=20 > 1. Creating a PANA SA (based on EAP MSK) between JCE and JN where JCE = is PAA, JN is PaC, and JA is PANA relay. > (PANA relay is a stateless relay as described in RFC 6345, and no need = for loose source routing or ULA allocation.) >=20 > 2. Using the SA to securely distribute locally significant credentials = such as a 802.11AR LDevID certificate or a network-wide shared symmetric = key, and I am not in favor of the latter though :)=20 >=20 > For 1), existing RADIUS servers can be used if EAP server is a = physically separated from PCE box where scalability is needed. = EAP-based approach can also support roaming cases where electric = vehicles are authenticated via smart meters. Not only RADIUS but also Diameter which is, by the way, widely used to = support many users in 3G,4G networks. >=20 > For 2) we can define new PANA attributes to carry RFC 4210 CertRequest = and CertResponse defined by PKIX for distributing 802.11AR LDevID = certificate. +1=20 >=20 > I did not think to use PANA to carry CoAP messages. I think DTLS = should be used for protecting CoAP for 6top as being discussed. The = DTLS session for CoAP can be established, e.g., by using the locally = significant credentials distributed in 2). Perhaps for very small deployments a pre-installed PSK could be used for = DTLS (as happens with WPA2-PSK) but certainly it is not scalable. >=20 > Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would = make 6tisch more attractive to cover certain business scenarios. This is related with my comment about 3g,4g networks. >=20 > Please note that I do not disagree with DTLS-based approach for more = resource constrained device (although more work seems to be needed to = carry DTLS message between JCE and JN via JA), but we should support = multiple options if one solution is difficult to cover all cases. +1 Best Regards. > =20 >=20 > Best Regards, > Yoshihiro Ohba >=20 >=20 > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On = Behalf Of Michael Richardson > Sent: Friday, November 14, 2014 3:12 PM > To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B = =1B$B!{#R#D#C""#N#S#L=1B(B) > Cc: 6tisch@ietf.org; 6tisch-security@ietf.org > Subject: Re: [6tisch-security] [6tisch] proposed security text for = architecture draft >=20 >=20 > wrote: >> Use of EAP-TLS and terminating TLS session at AAA server does not = mean >> that all parameters have to be coming from AAA server. Especially = when >> PANA is used, PAA can be co-located with JCE and provide 6top data = over >> a secure PANA SA. Actually this model applies to any EAP method. >=20 > So, we would be creating a masterkey with EAP-TLS, and then we would = use PANA as a transport for CoAP? >=20 > I understand why we want to use EAP when we have devices with humans = at the far end; > 1) it means the pieces in the middle do not need to know anything = about the > kind of authentication will be done >=20 > 2) we can deploy new forms of authentication (such as challenge = response > methods, and things like EAP-SIM or EAP-AKA) without changes to the = middle > machines. >=20 > 3) we can proxy things all the way back to the users home service, = which is=20 > how GSM roaming works these days. >=20 > I'm unaware that industrial/deterministic uses of 15.4 have = requirements for ths kind of thing. I seem to recall a conversation = about whether or not including a SIM card into nodes would work from a = power, size, and cost point of view. Having a replaceable SIM card = would definitely be a really easy way to imprint new devices. If = someone can do that, then we really don't need any of this...=20 >=20 > -- > Michael Richardson , Sandelman Software Works = -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sat Nov 15 20:13: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 A5E8D1A0A6A; Sat, 15 Nov 2014 20:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 hkO_gUKREKQ2; Sat, 15 Nov 2014 20:13:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308A51A079A; Sat, 15 Nov 2014 20:13:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CDDE520012; Sat, 15 Nov 2014 23:15:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 53379637F4; Sat, 15 Nov 2014 23:13:09 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3379F637EA; Sat, 15 Nov 2014 23:13:09 -0500 (EST) From: Michael Richardson To: 6tisch@ietf.org, 6tisch-security@ietf.org In-Reply-To: References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@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/x0jGWGdjtPVSBkpxnVL2uwTPX2E Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 16 Nov 2014 04:13:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable > For 2) we can define new PANA attributes to carry RFC 4210 CertRequest > and CertResponse defined by PKIX for distributing 802.11AR LDevID > certificate. =20=20=20=20 The EAP-TLS security is between joining node (supplicant) and radius/diamet= er server (authentication server).=20=20 The PANA is between the authenticator and the joining node (supplicant).=20 The PANA has no security attached.=20=20=20 How can the supplicant know that the CertResponse it is getting is legitima= te? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGgkUYCLcPvd0N1lAQLtTQf/QpgCQSRssQcM1bbDC584Wr9OC6OOpcvI 7OZD/LAq3PDCvMRZS0ymZDseXYUMTL9C0sgkDoFIxkFPGwRJQw38SPOQ/wAnEypc dSoN7ZzqT+k3DUN7rhXruK0C6jDdSBueU9OqLXMYiOBPVGFoQX/CmrIxG7EfGA0p fzwK9/U1maW5FLl7FyI3594x2+uu/7xySu+PMwsA5oTEe2gMGLK8ZmvR4ImmjRJJ 4Ukz+2e5Gv4DEMk4FrZSZwgjUHgQ/u31y3Pc4dO7OmfXf4RcwDrpm9OgfL3zwtXt 5XI2tCJN5cBPCTFteBgMqmLKGdoVXs5LTT8+yK0RaNOCGtMZchTMyw== =p1NK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 15 20:15: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 CF1761A0A6A; Sat, 15 Nov 2014 20:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 H9IuWjreCOOE; Sat, 15 Nov 2014 20:15:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B1A1A079A; Sat, 15 Nov 2014 20:15:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AD88820012; Sat, 15 Nov 2014 23:17:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4FCA9637F4; Sat, 15 Nov 2014 23:15:23 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3117C637EA; Sat, 15 Nov 2014 23:15:23 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@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/PONCMUi8wlfbc7-kqBF8x4EG9fw Cc: pthubert@cisco.com, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 16 Nov 2014 04:15:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > Can you please explain a use case where a JA has multiple LLN > interfaces as I could find it in draft-ietf-6tisch-architecture? Any device with more than one radio. Any device with a radio and an ethernet. Technically, any device with a loopback device configured... =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) iQEVAwUBVGgk14CLcPvd0N1lAQKTNwf/RQlCqaNqF8UIbcYmIb3Xr3vx/BM2LJuR g3E25izR6v0om66CElyqyqfOOsQ0baocBB3FCKxKkMGVBdxodZMln2951oaCWRU+ ALzKHS1sXsBNnhK1rHy65uLk67VkA6CRMQGIQdL6ryh1QvkeVKuP3SubYCDsCqqj Bqd+HjujRjiDunmkYpyurLowRoMKJXmrpRc4hUQLCjpNylwRtwjIowtSK1kJE6un CsmBqFvDDRrMASqoJ2o7lZLaT/H3BMLRtjQr1fqxsrAQRpT4S99hclAVGpgFlZH5 FTyFjsFoHrwOznLrLeG9z9gcsAAJK0IerjHaimYlz+2FMspOPiu0Tw== =WkIO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 15 20:23: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 260931A01A9; Sat, 15 Nov 2014 20:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 eU1zaBGYY8wn; Sat, 15 Nov 2014 20:23:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058831A00E2; Sat, 15 Nov 2014 20:23:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 93C1E20012; Sat, 15 Nov 2014 23:25:34 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 15142637F4; Sat, 15 Nov 2014 23:23:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E8FAF637EA; Sat, 15 Nov 2014 23:23:14 -0500 (EST) From: Michael Richardson To: Subir Das In-Reply-To: References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <12175.1415929463@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/XzlGMMR45RETZula4flYX-8CbXo Cc: 6tisch@ietf.org, 6tisch-security@ietf.org, "yoshihiro.ohba@toshiba.co.jp" Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 16 Nov 2014 04:23:18 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Subir Das wrote: > 1) Can you explain why smart meters have to use EAP methods? > It does not have to use but the reality is Advanced Metering > Networks is using EAP today. Can you tell me how they are using EAP today (what method). What is their authentication? What happens after EAP? Is there any kind of provisioning occuring? How large is the EAP-TLS code? How many packets does the EAP method take? How long? Are these electrical meters, or water or gas? Battery or line powered? The water meters in my neighbourhood are definitely not zero-touch, and=20 the batteries can't even be replaced; the system is a pre-IP Itron system, with the street lights being routers (I'm told).=20 The electrical (we call it "hydro", which is really confusing to non-Canadians) meters are Elster, also pre-IP, and apparently not encrypted at all. see: . Sure am glad they are field upgradable. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGgmr4CLcPvd0N1lAQIA8gf6AsAfs3sWhz/2VfBVR3yQqRMeOCIbDrLD Y1y8bGjXCBfU7mzLvNaG8drbGkunQqHePmB6OIgNiUhDoO42I6cD7JwDLk3u12LY hUoMEQRoBYdTRiR2LJN4DP8QNXA65OVncm7ORuXUQ7pNK+JKvqhSjEnLH9QBdXKg Oc76lUD2Bf0Pm1A5Vo0i5fcqJcbj/HPF6bW0Zjk0grIvBDzd8T9Tiwqm2IDsTp6g 7xngC060E8ush0Yfnena5sH2EwCMQuD0GKIFBwvINJzgjZ7BtqJyZ74uJskru4pL t97Rt6twgRSYoqY2fok0VZaXXb2piE0Y2BSfGDqSKeYbCNtuNKLerw== =k6gS -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 16 15:21:38 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 777971A1C04; Sun, 16 Nov 2014 15:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aJC4wUYLWvd9; Sun, 16 Nov 2014 15:21:14 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF5F1A1C02; Sun, 16 Nov 2014 15:21:14 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAGNL6U4019115; Mon, 17 Nov 2014 08:21:06 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAGNL6vm000300; Mon, 17 Nov 2014 08:21:06 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA00297; Mon, 17 Nov 2014 08:21:06 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAGNL5DM023819; Mon, 17 Nov 2014 08:21:05 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAGNL5d8023203; Mon, 17 Nov 2014 08:21:05 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.146]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 08:21:05 +0900 From: To: Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0IxwgACgdYWAABePkIABiM6AgAHRfJA= Date: Sun, 16 Nov 2014 23:21:05 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272B22DF@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local> <8608.1416111323@sandelman.ca> In-Reply-To: <8608.1416111323@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.218] 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/98sIjZ5vmAdBVcR5DZWa0hMRDLI Cc: pthubert@cisco.com, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 16 Nov 2014 23:21:17 -0000 I am not sure if Ethernet and loopback should be considered as LLN interfac= e where mesh routing is needed. Let's focus on a case with multiple LLN ra= dio interfaces (though such a case seems not very common). Is a distinct routable IP address allocated to each of the multiple LLN rad= io interfaces on a JA? If so, relay can still work even if there are multi= ple JNs having the same link-local address accessing via different LLN radi= o interfaces. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Sunday, November 16, 2014 1:15 PM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: pthubert@cisco.com; 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architec= ture draft wrote: > Can you please explain a use case where a JA has multiple LLN > interfaces as I could find it in draft-ietf-6tisch-architecture? Any device with more than one radio. Any device with a radio and an ethernet. Technically, any device with a loopback device configured... -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sun Nov 16 15:37: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 D11911A1C00; Sun, 16 Nov 2014 15:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 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, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 p98dSrRDVZMq; Sun, 16 Nov 2014 15:36:58 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACEE1A00F0; Sun, 16 Nov 2014 15:36:57 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sAGNatTe009652; Mon, 17 Nov 2014 08:36:55 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sAGNatnj020161; Mon, 17 Nov 2014 08:36:55 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA20156; Mon, 17 Nov 2014 08:36:55 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sAGNatmu026760; Mon, 17 Nov 2014 08:36:55 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAGNasVY004475; Mon, 17 Nov 2014 08:36:54 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.146]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 08:36:54 +0900 From: To: , <6tisch@ietf.org>, <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHQAVMgkoi1cepLG0+Y55kDTOfXCZxj5X1A Date: Sun, 16 Nov 2014 23:36:54 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <8156.1416111189@sandelman.ca> In-Reply-To: <8156.1416111189@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.218] 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/UTpZ0ol_HxaDTeDjKhxlQ8AgAic Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 16 Nov 2014 23:37:01 -0000 An issued certificate in a CertResponse is signed by a CA trusted by JN, an= d the CertResponse is protected by the PANA SA. The PANA SA is derived from an EAP MSK which is established between EAP pee= r and EAP server and is transported by EAP server to authenticator, and the= refore the PANA SA is attached to the EAP method security. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Sunday, November 16, 2014 1:13 PM To: 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architec= ture draft > For 2) we can define new PANA attributes to carry RFC 4210 CertReques= t > and CertResponse defined by PKIX for distributing 802.11AR LDevID > certificate. =20 The EAP-TLS security is between joining node (supplicant) and radius/diamet= er server (authentication server). =20 The PANA is between the authenticator and the joining node (supplicant).=20 The PANA has no security attached. =20 How can the supplicant know that the CertResponse it is getting is legitima= te? --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Mon Nov 17 01:27:47 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 ED2221A1A43; Mon, 17 Nov 2014 01:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.195 X-Spam-Level: X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, 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 ON5k-kmOqZVD; Mon, 17 Nov 2014 01:27:42 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 84D3D1A1A42; Mon, 17 Nov 2014 01:27:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 56C4848E7B; Mon, 17 Nov 2014 10:27:37 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id skl6MqfezCA4; Mon, 17 Nov 2014 10:27:37 +0100 (CET) Received: from inf-205-157.inf.um.es (inf-205-157.inf.um.es [155.54.205.157]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 9549F48C12; Mon, 17 Nov 2014 10:27:32 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rafa Marin Lopez In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local> Date: Mon, 17 Nov 2014 10:27:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62FBEB5B-56E2-438A-968C-0C014D81F720@um.es> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <8156.1416111189@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local> To: yoshihiro.ohba@toshiba.co.jp X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/lKUbrip9AhseEDGO_9-QMoHZJ9A Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org, Rafa Marin Lopez Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 17 Nov 2014 09:27:45 -0000 Regarding issuing a certificate, we have discussed internally here at = UMU that the PAA could certify a public key, which is sent by the PaC/JN = through the PANA SA built after a successful PANA authentication (e.g. = a PNR/PNA exchange could be used for that). In this sense, there is no = need for a global CA. Best Regards. El 17/11/2014, a las 00:36, yoshihiro.ohba@toshiba.co.jp escribi=F3: > An issued certificate in a CertResponse is signed by a CA trusted by = JN, and the CertResponse is protected by the PANA SA. >=20 > The PANA SA is derived from an EAP MSK which is established between = EAP peer and EAP server and is transported by EAP server to = authenticator, and therefore the PANA SA is attached to the EAP method = security. >=20 > Yoshihiro Ohba >=20 >=20 > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On = Behalf Of Michael Richardson > Sent: Sunday, November 16, 2014 1:13 PM > To: 6tisch@ietf.org; 6tisch-security@ietf.org > Subject: Re: [6tisch-security] [6tisch] proposed security text for = architecture draft >=20 >=20 >> For 2) we can define new PANA attributes to carry RFC 4210 = CertRequest >> and CertResponse defined by PKIX for distributing 802.11AR LDevID >> certificate. >=20 > The EAP-TLS security is between joining node (supplicant) and = radius/diameter server (authentication server). =20 >=20 > The PANA is between the authenticator and the joining node = (supplicant).=20 > The PANA has no security attached. =20 >=20 > How can the supplicant know that the CertResponse it is getting is = legitimate? >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Nov 17 11:48:40 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 822871A8976; Mon, 17 Nov 2014 11:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 oGsI5hxlOtRu; Mon, 17 Nov 2014 11:48:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643571A0AFE; Mon, 17 Nov 2014 11:48:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6086F20012; Mon, 17 Nov 2014 14:50:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 459F7637F5; Mon, 17 Nov 2014 14:48:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 33EF463745; Mon, 17 Nov 2014 14:48:30 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@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/fXdYIuk8ARBio6g-oJJFWhkWHM0 Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 17 Nov 2014 19:48:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > For 1), existing RADIUS servers can be used if EAP server is a > physically separated from PCE box where scalability is needed. > EAP-based approach can also support roaming cases where electric > vehicles are authenticated via smart meters. I don't understand this: we are not looking for distributed authenetication, we are looking for centralized authorization. > Support for UIM card (via EAP-SIM, EAP-AKA or a new EAP method) would > make 6tisch more attractive to cover certain business scenarios. really? WG chairs can you tell me if requiring UIM cards is an option. If so, there is no join problem; it's already solved and Yoshihiro is right: use EAP-SIM, followed by 6top authenticated with the EAP-SIM created MasterKey.=20 > Please note that I do not disagree with DTLS-based approach for more > resource constrained device (although more work seems to be needed to That's the only nodes which are in scope. I don't want to boil the ocean here! =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) iQEVAwUBVGpRC4CLcPvd0N1lAQKECQgAoQUJ/AYCfwK5sU5MJbXUf2qHqc4uTFTf w3tb0H6nsERSvr/Di1D9MQQ5dvLWeHItjSjv4V2+OXBLjUOcMjncrQYgiypN6YTS WwgNuWhcMDPDKaGBc1PgaGuUWW1Ku8m7/MVxHzG6t1iSo8yKgUEevz6Nk6Qp1Npw d6SnxGdYLjEy39Q73hGRpC70k0islNjIsXsqHlim99ra4T7ZU6Ck4HdFTfK0LEsv RBJOV7iQYzPAtXzbMr8Jt3TFBprt5mmgnY+krGNEqkmmgEC795r4XT+NK+G4/EI7 JVp3fALCZ0ZhQRQWC7uHGQ8l4BhDi5p4ktWgru3c1paU98ekxwPAzw== =IS81 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 17 15:05: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 527EC1ACE6A; Mon, 17 Nov 2014 15:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 t_BWusNly0R4; Mon, 17 Nov 2014 15:05:36 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29901ACE6F; Mon, 17 Nov 2014 15:05:35 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAHN5X8V023403; Tue, 18 Nov 2014 08:05:33 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAHN5XL9023961; Tue, 18 Nov 2014 08:05:33 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA23955; Tue, 18 Nov 2014 08:05:33 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAHN5WE3004730; Tue, 18 Nov 2014 08:05:32 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAHN5WhB006514; Tue, 18 Nov 2014 08:05:32 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.146]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 08:05:32 +0900 From: To: Thread-Topic: [6tisch] [6tisch-security] proposed security text for architecture draft Thread-Index: AQHQAkjCvyAiHV0apUCIUz0dSKSlpJxlcDyw Date: Mon, 17 Nov 2014 23:05:32 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272B8755@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <8156.1416111189@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local> <62FBEB5B-56E2-438A-968C-0C014D81F720@um.es> In-Reply-To: <62FBEB5B-56E2-438A-968C-0C014D81F720@um.es> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.218] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/GwFutFHabrbp3GbwrbC89CjnHqg Cc: mcr+ietf@sandelman.ca, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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, 17 Nov 2014 23:05:39 -0000 VGhhdCB3b3VsZCBiZSBhIGdvb2QgbW9kZWwgZm9yIGlzc3VpbmcgODAyLjFBUiBMRGV2SUQgY2Vy dGlmaWNhdGVzLg0KDQpUaGFua3MsDQpZb3NoaWhpcm8gT2hiYQ0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBSYWZhIE1hcmluIExvcGV6IFttYWlsdG86cmFmYUB1bS5lc10g DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE3LCAyMDE0IDY6MjggUE0NClRvOiBvaGJhIHlvc2hp aGlybyi084j2IMF40fMgofCj0qPEo8Oh9aPOo9OjzCkNCkNjOiBSYWZhIE1hcmluIExvcGV6OyBt Y3IraWV0ZkBzYW5kZWxtYW4uY2E7IDZ0aXNjaEBpZXRmLm9yZzsgNnRpc2NoLXNlY3VyaXR5QGll dGYub3JnDQpTdWJqZWN0OiBSZTogWzZ0aXNjaF0gWzZ0aXNjaC1zZWN1cml0eV0gcHJvcG9zZWQg c2VjdXJpdHkgdGV4dCBmb3IgYXJjaGl0ZWN0dXJlIGRyYWZ0DQoNClJlZ2FyZGluZyBpc3N1aW5n IGEgY2VydGlmaWNhdGUsIHdlIGhhdmUgZGlzY3Vzc2VkIGludGVybmFsbHkgaGVyZSBhdCBVTVUg dGhhdCB0aGUgUEFBIGNvdWxkIGNlcnRpZnkgYSBwdWJsaWMga2V5LCB3aGljaCBpcyBzZW50IGJ5 IHRoZSBQYUMvSk4gdGhyb3VnaCB0aGUgUEFOQSBTQSBidWlsdCBhZnRlciBhIHN1Y2Nlc3NmdWwg UEFOQSBhdXRoZW50aWNhdGlvbiAgKGUuZy4gYSBQTlIvUE5BIGV4Y2hhbmdlIGNvdWxkIGJlIHVz ZWQgZm9yIHRoYXQpLiBJbiB0aGlzIHNlbnNlLCB0aGVyZSBpcyBubyBuZWVkIGZvciBhIGdsb2Jh bCBDQS4NCg0KQmVzdCBSZWdhcmRzLg0KDQpFbCAxNy8xMS8yMDE0LCBhIGxhcyAwMDozNiwgeW9z aGloaXJvLm9oYmFAdG9zaGliYS5jby5qcCBlc2NyaWJpqK46DQoNCj4gQW4gaXNzdWVkIGNlcnRp ZmljYXRlIGluIGEgQ2VydFJlc3BvbnNlIGlzIHNpZ25lZCBieSBhIENBIHRydXN0ZWQgYnkgSk4s IGFuZCB0aGUgQ2VydFJlc3BvbnNlIGlzIHByb3RlY3RlZCBieSB0aGUgUEFOQSBTQS4NCj4gDQo+ IFRoZSBQQU5BIFNBIGlzIGRlcml2ZWQgZnJvbSBhbiBFQVAgTVNLIHdoaWNoIGlzIGVzdGFibGlz aGVkIGJldHdlZW4gRUFQIHBlZXIgYW5kIEVBUCBzZXJ2ZXIgYW5kIGlzIHRyYW5zcG9ydGVkIGJ5 IEVBUCBzZXJ2ZXIgdG8gYXV0aGVudGljYXRvciwgYW5kIHRoZXJlZm9yZSB0aGUgUEFOQSBTQSBp cyBhdHRhY2hlZCB0byB0aGUgRUFQIG1ldGhvZCBzZWN1cml0eS4NCj4gDQo+IFlvc2hpaGlybyBP aGJhDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogNnRpc2No LXNlY3VyaXR5IFttYWlsdG86NnRpc2NoLXNlY3VyaXR5LWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K PiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIg MTYsIDIwMTQgMToxMyBQTQ0KPiBUbzogNnRpc2NoQGlldGYub3JnOyA2dGlzY2gtc2VjdXJpdHlA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFs2dGlzY2gtc2VjdXJpdHldIFs2dGlzY2hdIHByb3Bv c2VkIHNlY3VyaXR5IHRleHQgZm9yIA0KPiBhcmNoaXRlY3R1cmUgZHJhZnQNCj4gDQo+IA0KPj4g Rm9yIDIpIHdlIGNhbiBkZWZpbmUgbmV3IFBBTkEgYXR0cmlidXRlcyB0byBjYXJyeSBSRkMgNDIx MCANCj4+IENlcnRSZXF1ZXN0IGFuZCBDZXJ0UmVzcG9uc2UgZGVmaW5lZCBieSBQS0lYIGZvciBk aXN0cmlidXRpbmcgDQo+PiA4MDIuMTFBUiBMRGV2SUQgY2VydGlmaWNhdGUuDQo+IA0KPiBUaGUg RUFQLVRMUyBzZWN1cml0eSBpcyBiZXR3ZWVuIGpvaW5pbmcgbm9kZSAoc3VwcGxpY2FudCkgYW5k IHJhZGl1cy9kaWFtZXRlciBzZXJ2ZXIgKGF1dGhlbnRpY2F0aW9uIHNlcnZlcikuICANCj4gDQo+ IFRoZSBQQU5BIGlzIGJldHdlZW4gdGhlIGF1dGhlbnRpY2F0b3IgYW5kIHRoZSBqb2luaW5nIG5v ZGUgKHN1cHBsaWNhbnQpLiANCj4gVGhlIFBBTkEgaGFzIG5vIHNlY3VyaXR5IGF0dGFjaGVkLiAg IA0KPiANCj4gSG93IGNhbiB0aGUgc3VwcGxpY2FudCBrbm93IHRoYXQgdGhlIENlcnRSZXNwb25z ZSBpdCBpcyBnZXR0aW5nIGlzIGxlZ2l0aW1hdGU/DQo+IA0KPiAtLSANCj4gXSAgICAgICAgICAg ICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBu ZXR3b3JrcyBbIA0KPiBdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUg V29ya3MgICAgICAgIHwgbmV0d29yayBhcmNoaXRlY3QgIFsgDQo+IF0gICAgIG1jckBzYW5kZWxt YW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMg ICAgWyANCj4gCQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gNnRpc2NoIG1haWxpbmcgbGlzdA0KPiA2dGlzY2hAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUmFmYWVsIE1hcmlu IExvcGV6LCBQaEQNCkRlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVl cmluZyAoRElJQykgRmFjdWx0eSBvZiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVy Y2lhDQozMDEwMCBNdXJjaWEgLSBTcGFpbg0KVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4 ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KDQo= From nobody Mon Nov 17 20: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 7ADDD1AD0C9; Mon, 17 Nov 2014 20:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 4nf_M6C_kpVL; Mon, 17 Nov 2014 20:23:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7FA1AD05C; Mon, 17 Nov 2014 20:23:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A32C2009E; Mon, 17 Nov 2014 23:26:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1B564637F5; Mon, 17 Nov 2014 23:23:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 03BC7637EA; Mon, 17 Nov 2014 23:23:58 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272B22DF@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local> <8608.1416111323@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B22DF@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/T-R6KuuGccHYq4x1wcYWkw6JemM Cc: pthubert@cisco.com, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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: Tue, 18 Nov 2014 04:24:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > I am not sure if Ethernet and loopback should be considered as LLN > interface where mesh routing is needed. Let's focus on a case with > multiple LLN radio interfaces (though such a case seems not very > common).=20 Take two constrained devices with a generous power supply, wire ethernet between them so that the "signal" can get through that metal door/wall.=20 That's the whole point of doing this all at layer 3. > Is a distinct routable IP address allocated to each of the multiple L= LN > radio interfaces on a JA? If so, relay can still work even if there > are multiple JNs having the same link-local address accessing via > different LLN radio interfaces.=20 Assuming that your source route references the correct outgoing link-local address, I agree; I think we can make it work. It might be not to spec, but maybe running code should trump the spec. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGrJ1ICLcPvd0N1lAQL1fgf/fZl8EMS0syAVeNsfQJC9VUaDuzwOEzh+ ovKELxse6BA+CL29ow+4NvioPWItH+1hdd55+YQB81wD1ODuhXyFXjF23gDLwmht yFSDLpRaXUxWJtT0sOpRWayqy0o/mUR+HYNRUJ8nq6XYZQInWNf1yT0RkYZAGPxU fMPoJVNgHY0hwJ+038raMsOl+MBUVJzRNeAeI94Jeg//PfWqpyoot5nOTUyjbhVr 6FN3gA83ytr/wsjhSFKMH7KeihUie+5hgX8aPp283uwa+x/giLuYRryUBcGqmSoQ 4fx37AlcvPJdmfVnJnDQb5/ZYqQNserwwoGb0tuJ4poxSKq0Uyc+Ww== =kLdM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 17 20:26: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 C6BA31AD05C; Mon, 17 Nov 2014 20:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 RBaaUKfHsYyL; Mon, 17 Nov 2014 20:26:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E91E1AD0C9; Mon, 17 Nov 2014 20:26:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 25BB62009E; Mon, 17 Nov 2014 23:28:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C5A78637F5; Mon, 17 Nov 2014 23:26:04 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AE081637EA; Mon, 17 Nov 2014 23:26:04 -0500 (EST) From: Michael Richardson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B272B3300@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <8156.1416111189@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B3300@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/wxM-heBWhnwXpnNF1knaIUVpEYY Cc: 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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: Tue, 18 Nov 2014 04:26:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: > The PANA SA is derived from an EAP MSK which is established between E= AP > peer and EAP server and is transported by EAP server to authenticator, > and therefore the PANA SA is attached to the EAP method security.=20 I was unaware that the PANA channel was secured by MSK. So it links the Join Assistant to the Joining Node. I think I'd like a diagram of what you envision. =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) iQEVAwUBVGrKWYCLcPvd0N1lAQKY3gf/cyeVg11Zo9z0qXTotD3rNmsvTqL/ZCh5 3BKJCHx841gFjYn1hKmCgCvXIN6I0A8ba3tEGZvGn6EtA8T23nPshQmfTJLAJK5M TElta4++8D4g7WV89V/am+vUSn8NWLejsdx+/0HvqRYeCsuaW5L9p3o068vvZxWl uk3mXF8UizCMjPPcsZhu7cWzM1NikoFSRSbBQwdv/UP5MyEHmxE7IiT6V/BcSywj G1+TFjWOlJXSTwBaTvzQxXtkvtTXqdoqW8ufESkqPGIqXkL6kLPolnUWPX22so/h At2PXE4rGwMfwQkdPiZWZ010MMkN0KHi+aP0fsdQ0tg+sHs2Pc+xyA== =KBRo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 17 21:27:32 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 F14531ACD56 for <6tisch-security@ietfa.amsl.com>; Mon, 17 Nov 2014 21:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.997, RP_MATCHES_RCVD=-0.594, 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 V3FO7dqVpXLd for <6tisch-security@ietfa.amsl.com>; Mon, 17 Nov 2014 21:27:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FB31A00C0 for <6tisch-security@ietf.org>; Mon, 17 Nov 2014 21:27:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DA0D82002A for <6tisch-security@ietf.org>; Tue, 18 Nov 2014 00:29:56 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6573C637F5; Tue, 18 Nov 2014 00:27:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B6C7637EA for <6tisch-security@ietf.org>; Tue, 18 Nov 2014 00:27:30 -0500 (EST) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> X-Attribution: mcr 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/0LbP3wAdCtgi7G44BhGc-zcOtjo Subject: [6tisch-security] no meeting on Nov. 18 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: Tue, 18 Nov 2014 05:27:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I am travelling, and also many people are on vacation. We will resume on Nov. 25. =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) iQEVAwUBVGrYvoCLcPvd0N1lAQLruAf/XaJGszjj7TU7k+7PO/OgJrCtjj2ahL0B DhnUf2r/kNk2XGJZ6IEQNJ4izac5GBEt6Cmgo5vmaZE13ESb+YOL8+nkec1F3fde w+TC/4riZh4mWCxBT0HdcNSYvlufXlmV7/qvWCz52iszjVIaqhqt1pEiq3dok6jf IXRto8kIhpEGYubwDj3F5U7ay+Iq3pVn6E3Rd4yKUiu/KhuGnINo86RVGj53Ph1i JqJIf9xWvh1abcKtnahKJGlGZsOSli83JaK96eesWoPA9zB7SjjVPHs1QTpo/LMy 4ZDIPHzGKAPUafvDVNMDO0+0KpgRMUfGDyf+41UGCh1DafYNON0mLA== =gLfW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 17 23:08: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 96A671A014E; Mon, 17 Nov 2014 23:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UnBgjcEk9pBu; Mon, 17 Nov 2014 23:08:05 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3BB1AD35E; Mon, 17 Nov 2014 23:08:04 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAI77v6w000264; Tue, 18 Nov 2014 16:07:57 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAI77uYO001918; Tue, 18 Nov 2014 16:07:56 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA01914; Tue, 18 Nov 2014 16:07:56 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAI77u9b027279; Tue, 18 Nov 2014 16:07:56 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sAI77tkc026364; Tue, 18 Nov 2014 16:07:55 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.146]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 16:07:56 +0900 From: To: Thread-Topic: [6tisch-security] [6tisch] proposed security text for architecture draft Thread-Index: AQHP/9Hsmv4jLXPqmkGCw6POgAr77Jxf0IxwgACgdYWAABePkIABiM6AgAHRfJCAAVWTAIAAxDIw Date: Tue, 18 Nov 2014 07:07:55 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B272B89D9@TGXML210.toshiba.local> References: <20507.1415811045@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A8EFA@TGXML210.toshiba.local> <5854.1415835364@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A9108@TGXML210.toshiba.local> <29465.1415934436@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272A988F@TGXML210.toshiba.local> <2187.1415945515@sandelman.ca>, <674F70E5F2BE564CB06B6901FD3DD78B272A9AFF@TGXML210.toshiba.local> <976D1F6A-3A48-4BBB-8297-58071788A04E@cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B272A9CEA@TGXML210.toshiba.local> <8608.1416111323@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B272B22DF@TGXML210.toshiba.local> <10985.1416284638@sandelman.ca> In-Reply-To: <10985.1416284638@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.218] 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/OR6zXjVUbkwtDVVIVdnRiZuDvfE Cc: pthubert@cisco.com, 6tisch@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architecture draft 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: Tue, 18 Nov 2014 07:08:09 -0000 -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Tuesday, November 18, 2014 1:24 PM To: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ) Cc: pthubert@cisco.com; 6tisch@ietf.org; 6tisch-security@ietf.org Subject: Re: [6tisch-security] [6tisch] proposed security text for architec= ture draft wrote: > I am not sure if Ethernet and loopback should be considered as LLN > interface where mesh routing is needed. Let's focus on a case with > multiple LLN radio interfaces (though such a case seems not very > common).=20 Take two constrained devices with a generous power supply, wire ethernet be= tween them so that the "signal" can get through that metal door/wall.=20 That's the whole point of doing this all at layer 3. [YO] OK. > Is a distinct routable IP address allocated to each of the multiple L= LN > radio interfaces on a JA? If so, relay can still work even if there > are multiple JNs having the same link-local address accessing via > different LLN radio interfaces.=20 Assuming that your source route references the correct outgoing link-local = address, I agree; I think we can make it work. It might be not to spec, but= maybe running code should trump the spec. [YO] Yes, that's what I meant. Thanks, Yoshihiro Ohba --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Tue Nov 18 06:44: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 857391A19F9 for <6tisch-security@ietfa.amsl.com>; Tue, 18 Nov 2014 06:44:41 -0800 (PST) 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 7mI95k3vHKxf for <6tisch-security@ietfa.amsl.com>; Tue, 18 Nov 2014 06:44:39 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B1A1A19FC for <6tisch-security@ietf.org>; Tue, 18 Nov 2014 06:44:39 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so2157060ier.13 for <6tisch-security@ietf.org>; Tue, 18 Nov 2014 06:44:38 -0800 (PST) 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=CmilsZ+zvrcAcifNiB9XOya76zhotGLvfsGiiIkrpoQ=; b=DwzugND23LP5VciVu65IBw0ECDWXig2sGzr37DVcsAGWQdkeyL3ikZnMFBf8tv0RJT scz7B4wZHl6mHg3JyswYo1zM39DRf/zHUm81qwfShigvtmL+WEERLSEPcj6S5wOqZzC/ rPDgqFMfT+oSM+tBrCVA9dMemzqI+nAuvqwEiDMswAevzTOLjMwtanvLFcP0gio5SkUj v1tnc7/c30qbz6TNwBm2niLEMyseeT/k55J2jP9e/ejQ1hVUzfWmpUiEigu/Bt2FELgE xJVHW5mSX/4Vp+PjfKmGHtx88k7DMFZWGMeVkx9cSnPwPtCPP0Drodx86YusT5pN239t 7d9A== X-Received: by 10.43.90.198 with SMTP id bj6mr34461276icc.4.1416321878541; Tue, 18 Nov 2014 06:44:38 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id ig10sm7757601igb.18.2014.11.18.06.44.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Nov 2014 06:44:38 -0800 (PST) Message-ID: <546B5B54.7010203@gmail.com> Date: Tue, 18 Nov 2014 09:44:36 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson , tisch-security <6tisch-security@ietf.org> References: <11504.1416288450@sandelman.ca> In-Reply-To: <11504.1416288450@sandelman.ca> Content-Type: multipart/alternative; boundary="------------030306070606030000090109" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/D2cB6jfiGIqLRlR4XxydWEaQVL4 Subject: Re: [6tisch-security] no meeting on Nov. 18 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: Tue, 18 Nov 2014 14:44:41 -0000 This is a multi-part message in MIME format. --------------030306070606030000090109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Michael: Next week is Thanksgiving week in the USA, which we should respect. This aside, we should discuss next steps of 6TiSCH security work (including agenda setting). Personally, I think past calls have not worked well and I am not alone in this assessment. Sadly, there was no time allocated for this on the IETF-91 agenda. I think this was a grave mistake. (Normally, face-to-face meetings are primarily for things that are hard to discuss via email alone.) Best regards, Rene On 11/18/2014 12:27 AM, Michael Richardson wrote: > I am travelling, and also many people are on vacation. > We will resume on Nov. 25. > > > > _______________________________________________ > 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 --------------030306070606030000090109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Hi Michael:

Next week is Thanksgiving week in the USA, which we should respect.

This aside, we should discuss next steps of 6TiSCH security work (including agenda setting). Personally, I think past calls have not worked well and I am not alone in this assessment.

Sadly, there was no time allocated for this on the IETF-91 agenda. I think this was a grave mistake. (Normally, face-to-face meetings are primarily for things that are hard to discuss via email alone.)

Best regards, Rene

On 11/18/2014 12:27 AM, Michael Richardson wrote:
I am travelling, and also many people are on vacation.
We will resume on Nov. 25.




_______________________________________________
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
--------------030306070606030000090109-- From nobody Thu Nov 20 14:30: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 D31BB1A88AF for <6tisch-security@ietfa.amsl.com>; Thu, 20 Nov 2014 14:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 95DFSAlJXc-K for <6tisch-security@ietfa.amsl.com>; Thu, 20 Nov 2014 14:30:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EBB1A888B for <6tisch-security@ietf.org>; Thu, 20 Nov 2014 14:30:03 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D965520098 for <6tisch-security@ietf.org>; Thu, 20 Nov 2014 17:32:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E5AD1637F5; Thu, 20 Nov 2014 17:30:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C9CD663745 for <6tisch-security@ietf.org>; Thu, 20 Nov 2014 17:30:01 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: References: 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/XHL_gvZ0QKhXFT-I_Khv0awI7pw Subject: [6tisch-security] minutes of the 2014-11-04 6TiSCH 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 Nov 2014 22:30:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Attending: - Thomas - Michael - Jonathan - Kris - Pascal In this call we returned to getting section 3 ready for proposing=20 as part of the 6tisch architecture. This resulted in the post at: http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html These minutes describe how we got to this text. We returned to the question: * how do we get communication between the joining node and the JCE? * IP-IP tunnel between join assistant and JCE * use pre-existing DODAG, DAO sent up to parent and DODAG root, informi= ng existence * second DODAG. non-storing=20 * (not exclusive) 6TiSCH track for join traffic We discussed the last item for awhile in the context of Deterministic Ethernet and other 6tisch track allocations. We discussed how we could use the track and QoS features to either protect the network from DDoS from joining nodes, or alternatively, lower the time for a network to form by allocating more bandwidth. We came back to the question: "does the JCE have connectivity to joining node?" (and how) After much discussion we came to the conclusion in the 2014-11-04 discussion that we would use the existinng DODAG, even if it was a storing DODAG. * MR: part of goal is to prevent DoS. If we agree that in general in a 6TiSCH network, we can replace networks with 6TiSCH tracks, that's a possibilty. We can add QoS on those tracks. Maybe we don't need to th= ink too hard about option 4.=20 Near the end of the discussion a new option was proposed, which is to not have the joining node join the DODAG (the Join Assistant would send a DAO on behalf of the joining node), but rather for the JCE to use loose source routing to reach the Joining Node. The JCE would send via the Join Assistant, and it would get that address from the DAR message that the 6LBR would share.=20 At the end of this meeting, mcr took the action to update the document, whi= ch was included in the text pointed to above. Just prior to the 6tisch meeting, it was pointed out that the we couldn't, according to specification, put link local addresses into the RH2, because their link scope would be unclear. We are investigating what other options we have, because the resulting system has very little state per joining nod= e. =3D=3D=3D=3D =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) iQEVAwUBVG5rZoCLcPvd0N1lAQKJKQf+K7XhcdbkYRNh8kg1QofWTIzWg3hqT0YM j7uY5+dbDYxJ58Cs10rJ15KZ5olH20pATnUx91h6/JNWZHbSIhk0KFnhJ1br8fy/ Uq0MesuhicPS9YnSpaUlNdio2cEb0U7uwCtqS0mEXO3eIWyQ/KuoZR/nwSE2pkSM rm94cF/ydZ4pqXVLNmVDubRK7PGw/Fo6aIw2Fx6y8EVpbU9TBGz7mjp9e+Wc8Sb/ uChlgtuJdVLtfWOvldN8nAKAPpr+4tIoFynhtYPKvhbxjqJMZHPjSTs9TmHKdHgc T3oRJdf4wSP7O47pHCp9rvvgUn95hzLRBSKvGDF7Se2lClnOD/gtpA== =zk8S -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 20 22:42: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 BE8EC1A0076 for <6tisch-security@ietfa.amsl.com>; Thu, 20 Nov 2014 22:42:12 -0800 (PST) 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 soFQekSk-Z7w for <6tisch-security@ietfa.amsl.com>; Thu, 20 Nov 2014 22:42:11 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4091AD10A for <6tisch-security@ietf.org>; Thu, 20 Nov 2014 22:42:10 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lj1so4196040pab.18 for <6tisch-security@ietf.org>; Thu, 20 Nov 2014 22:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=w+GMdoENr+u+xxeuctEGv3mcKLRmcqASqoHwNTXyzUM=; b=XUviFbBC6+CbPaFYji8PoJR5zgliAOBsfGPKN+a4ThCxCQrLGNOn9P5pWVRpXISlZN b1qGj86cPbGPDJeA2mORyWnVxRFFr4jiwOiPZh7G7Ta7Js8YR7k+WVXr7OSTp5A85kWE xptAQ4ouQ/tRXf9P6YvqBQs4eTT90YWDjQ1IyxDRdV64zsi5HMSvK27xuRFqdOLEGgr9 eKCiqyjur9SzXiBZBBmNOTYelWpJc7koRBy+cLhuTFg3fgFKdmXMGux4rg6CPJA93Apb yKI95jTtQkeBXN+KP5qXzvuZ0VGt6gzp7ZRzVeRV9+AJME/hMtFAKb7zieQylhmGuukc yMcw== X-Received: by 10.68.101.131 with SMTP id fg3mr3936628pbb.130.1416552130143; Thu, 20 Nov 2014 22:42:10 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.161.72 with HTTP; Thu, 20 Nov 2014 22:41:49 -0800 (PST) In-Reply-To: <546B5B54.7010203@gmail.com> References: <11504.1416288450@sandelman.ca> <546B5B54.7010203@gmail.com> From: Thomas Watteyne Date: Thu, 20 Nov 2014 22:41:49 -0800 X-Google-Sender-Auth: GXVkHPMHwj2UVsWlDf54ggXvhik Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=047d7b86f6f085ebd1050858be50 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/dFx0EIenC6HVwscn7qMJKrIqSqA Cc: Michael Richardson , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] no meeting on Nov. 18 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, 21 Nov 2014 06:42:13 -0000 --047d7b86f6f085ebd1050858be50 Content-Type: text/plain; charset=UTF-8 Rene, While, same as you, I would have loved even more time to discuss security, I believe we have spent close to an hour doing so, first with lots of questions and discussions, then with the presentation of the drafts. What alternative format are you proposing for the security work? Thomas On Tue, Nov 18, 2014 at 6:44 AM, Rene Struik wrote: > Hi Michael: > > Next week is Thanksgiving week in the USA, which we should respect. > > This aside, we should discuss next steps of 6TiSCH security work > (including agenda setting). Personally, I think past calls have not worked > well and I am not alone in this assessment. > > Sadly, there was no time allocated for this on the IETF-91 agenda. I think > this was a grave mistake. (Normally, face-to-face meetings are primarily > for things that are hard to discuss via email alone.) > > Best regards, Rene > > On 11/18/2014 12:27 AM, Michael Richardson wrote: > > I am travelling, and also many people are on vacation. > We will resume on Nov. 25. > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/mailman/listinfo/6tisch-security > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7b86f6f085ebd1050858be50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rene,

While, same as you, I would have = loved even more time to discuss security, I believe we have spent close to = an hour doing so, first with lots of questions and discussions, then with t= he presentation of the drafts.

What alternative fo= rmat are you proposing for the security work?

Thom= as

On = Tue, Nov 18, 2014 at 6:44 AM, Rene Struik <rstruik.ext@gmail.com&g= t; wrote:
=20 =20 =20
Hi Michael:

Next week is Thanksgiving week in the USA, which we should respect.

This aside, we should discuss next steps of 6TiSCH security work (including agenda setting). Personally, I think past calls have not worked well and I am not alone in this assessment.

Sadly, there was no time allocated for this on the IETF-91 agenda. I think this was a grave mistake. (Normally, face-to-face meetings are primarily for things that are hard to discuss via email alone.)

Best regards, Rene

On 11/18/2014 12:27 AM, Michael Richardson wrote:
I am travelling, and also many people are on vacation.
We will resume on Nov. 25.




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



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=

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


--047d7b86f6f085ebd1050858be50-- From nobody Thu Nov 20 22:52: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 E482C1AD10A; Thu, 20 Nov 2014 22:52:10 -0800 (PST) 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 Q25F-U6IdMnB; Thu, 20 Nov 2014 22:52:08 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B741AD0F0; Thu, 20 Nov 2014 22:52:08 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id kx10so4241786pab.30 for ; Thu, 20 Nov 2014 22:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7+fSjpN0gdh08dlBMrUTSiZmjyQBeO1LFZvcJMk62jo=; b=0dOG3Kq1E677Xs3Gd1V107R02yy3bHWsHA1hOW1uo/Tgpj4cP3Vtkl7b98DI9KsRpf WTot1/zY2wCoPnqlobsQ14JxjxWcHc4ABlroILkOqHLjKM01Cvp1GqNtFkbqLi/C4WbJ 0kz/KeVcot+qBHS44mFjyNpivqcqp/zTcoSGuqn5U/f1QrHE2lZhNh2bSSdCpLr18ADv bIELbrDu8QXbBodNUSHjLsIc3VR1zyi77HQYNNbF60OGUrpmya89ngmS58JL+r3+tIk8 gZqvaGswci2O/8rLC5uz7XWQrdZzTlze1tZ5CwhLA+FWF+OGdlMNg3Lb7TJrdF5fyRXf brtg== X-Received: by 10.68.101.131 with SMTP id fg3mr3994507pbb.130.1416552727778; Thu, 20 Nov 2014 22:52:07 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.161.72 with HTTP; Thu, 20 Nov 2014 22:51:47 -0800 (PST) In-Reply-To: <316.1416522601@sandelman.ca> References: <316.1416522601@sandelman.ca> From: Thomas Watteyne Date: Thu, 20 Nov 2014 22:51:47 -0800 X-Google-Sender-Auth: 3kgKF4bJsSNbnyRjOrB_VeL1Xkg Message-ID: To: Michael Richardson , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b86f6f0251e92050858e243 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/1BrofeqI5hs8HnmGgCo5fv3-Kxg Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] minutes of the 2014-11-04 6TiSCH 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: Fri, 21 Nov 2014 06:52:11 -0000 --047d7b86f6f0251e92050858e243 Content-Type: text/plain; charset=UTF-8 Michael, [adding 6TiSCH ML] I have archived those minutes at https://bitbucket.org/6tisch/meetings/wiki/141104_webex_security for completeness. In the process, I made the changes below, please let me know if that doesn't work for you: OLD: - Thomas - Michael - Jonathan - Kris - Pascal NEW: - Thomas Watteyne - Michael Richardson - Jonathan Simon - Kris Pister - Pascal Thubert OLD: Just prior to the 6tisch meeting, NEW: Just prior to the 6tisch WG meeting at IETF91, Thomas On Thu, Nov 20, 2014 at 2:30 PM, Michael Richardson wrote: > > Attending: > - Thomas > - Michael > - Jonathan > - Kris > - Pascal > > In this call we returned to getting section 3 ready for proposing > as part of the 6tisch architecture. This resulted in the post at: > http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html > > These minutes describe how we got to this text. > > We returned to the question: > * how do we get communication between the joining node and the JCE? > * IP-IP tunnel between join assistant and JCE > * use pre-existing DODAG, DAO sent up to parent and DODAG root, > informing existence > * second DODAG. non-storing > * (not exclusive) 6TiSCH track for join traffic > > We discussed the last item for awhile in the context of Deterministic > Ethernet and other 6tisch track allocations. We discussed how we could > use > the track and QoS features to either protect the network from DDoS from > joining nodes, or alternatively, lower the time for a network to form by > allocating more bandwidth. > > We came back to the question: > "does the JCE have connectivity to joining node?" (and how) > > After much discussion we came to the conclusion in the 2014-11-04 > discussion > that we would use the existinng DODAG, even if it was a storing DODAG. > > * MR: part of goal is to prevent DoS. If we agree that in general in a > 6TiSCH network, we can replace networks with 6TiSCH tracks, that's a > possibilty. We can add QoS on those tracks. Maybe we don't need to > think > too hard about option 4. > > Near the end of the discussion a new option was proposed, which is to not > have the joining node join the DODAG (the Join Assistant would send a DAO > on > behalf of the joining node), but rather for the JCE to use loose source > routing to reach the Joining Node. The JCE would send via the Join > Assistant, and it would get that address from the DAR message that the 6LBR > would share. > > At the end of this meeting, mcr took the action to update the document, > which > was included in the text pointed to above. > > Just prior to the 6tisch meeting, it was pointed out that the we couldn't, > according to specification, put link local addresses into the RH2, because > their link scope would be unclear. We are investigating what other options > we have, because the resulting system has very little state per joining > node. > > ==== > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7b86f6f0251e92050858e243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

[adding 6TiSCH ML]
<= br>
I have archived those minutes at=C2=A0https://bitbucket.org= /6tisch/meetings/wiki/141104_webex_security for completeness.

In the process, I made the changes below, please let me kno= w if that doesn't work for you:

OLD:
=C2=A0- Thomas=
=C2=A0- Michael=C2=A0- Jonathan
=C2=A0- Kris
=C2=A0- Pascal
NEW:
= =C2=A0- Thomas Watteyne
=C2=A0- Michael Richardson
=C2= =A0- Jonathan Simon
=C2=A0- Kris Pister
=C2=A0- Pascal = Thubert

OLD:
Just prior to the 6tisch meeting,
NEW:
Just prior to the 6tisch WG= meeting at IETF91,

Thomas

On Thu, Nov 20, 2014 at 2:30 PM, Michael R= ichardson <mcr+ietf@sandelman.ca> wrote:

Attending:
=C2=A0- Thomas
=C2=A0- Michael
=C2=A0- Jonathan
=C2=A0- Kris
=C2=A0- Pascal

In this call we returned to getting section 3 ready for proposing
as part of the 6tisch architecture.=C2=A0 This resulted in the post at:
=C2=A0 =C2=A0http://www.ietf.org/mail-archive/web/6tis= ch/current/msg02690.html

These minutes describe how we got to this text.

We returned to the question:
=C2=A0 * how do we get communication between the joining node and the JCE?<= br> =C2=A0 =C2=A0 * IP-IP tunnel between join assistant and JCE
=C2=A0 =C2=A0 * use pre-existing DODAG, DAO sent up to parent and DODAG roo= t, informing existence
=C2=A0 =C2=A0 * second DODAG. non-storing
=C2=A0 =C2=A0 * (not exclusive) 6TiSCH track for join traffic

We discussed the last item for awhile in the context of Deterministic
Ethernet and other 6tisch track allocations.=C2=A0 =C2=A0We discussed how w= e could use
the track and QoS features to either protect the network from DDoS from
joining nodes, or alternatively, lower the time for a network to form by allocating more bandwidth.

We came back to the question:
=C2=A0 =C2=A0"does the JCE have connectivity to joining node?" (a= nd how)

After much discussion we came to the conclusion in the 2014-11-04 discussio= n
that we would use the existinng DODAG, even if it was a storing DODAG.

=C2=A0 * MR: part of goal is to prevent DoS. If we agree that in general in= a
=C2=A0 =C2=A0 =C2=A0 6TiSCH network, we can replace networks with 6TiSCH tr= acks, that's a
=C2=A0 =C2=A0 =C2=A0 possibilty. We can add QoS on those tracks. Maybe we d= on't need to think
=C2=A0 =C2=A0 =C2=A0 too hard about option 4.

Near the end of the discussion a new option was proposed, which is to not have the joining node join the DODAG (the Join Assistant would send a DAO o= n
behalf of the joining node), but rather for the JCE to use loose source
routing to reach the Joining Node.=C2=A0 The JCE would send via the Join Assistant, and it would get that address from the DAR message that the 6LBR=
would share.

At the end of this meeting, mcr took the action to update the document, whi= ch
was included in the text pointed to above.

Just prior to the 6tisch meeting, it was pointed out that the we couldn'= ;t,
according to specification, put link local addresses into the RH2, because<= br> their link scope would be unclear.=C2=A0 We are investigating what other op= tions
we have, because the resulting system has very little state per joining nod= e.

=3D=3D=3D=3D



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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


--047d7b86f6f0251e92050858e243-- From nobody Fri Nov 21 06:09:34 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 AB31A1A19ED for <6tisch-security@ietfa.amsl.com>; Fri, 21 Nov 2014 06:09:32 -0800 (PST) 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 wnKeXtKPVO5o for <6tisch-security@ietfa.amsl.com>; Fri, 21 Nov 2014 06:09:28 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B651AD439 for <6tisch-security@ietf.org>; Fri, 21 Nov 2014 06:09:28 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so6646310igb.1 for <6tisch-security@ietf.org>; Fri, 21 Nov 2014 06:09:27 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type; bh=ATvYs5fmPq636BAaGV+3UxViDvr+7219gF/S/gHNOe4=; b=scAZvRVzg4pN8I5OA1/70reTuS1GblCTAdmzF2aCaejGQQFy9pErq+200C/7LGA0Wl OunNwqvfN0AJPWOP93lIHhCufYTK9WLDtwmQEY2NopUqcPYwZre2VXaZ7CFN68fnVo2d svq9tyAHDv/C1oSgnBh8JkVoYJYM7aB4E+hVn6hNCddfqnXoT0ESVBVsN+GkvrA9/Ak5 u+/hP8sMyztDOe87IdIR7j2l+SfY6GohoQv4uEe7CiBhH/kJyFCYw/T4TgcLsPq3K4dK +F1ScKfh20NfolFuofqZyM9vFNY6taW9buDFBOki7RCIHqIDxtKmowE/nw38u7eBeflX l52Q== X-Received: by 10.50.79.167 with SMTP id k7mr15544047igx.16.1416578967024; Fri, 21 Nov 2014 06:09:27 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id b77sm2948748ioe.35.2014.11.21.06.09.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Nov 2014 06:09:26 -0800 (PST) Message-ID: <546F4791.2040008@gmail.com> Date: Fri, 21 Nov 2014 09:09:21 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Thomas Watteyne References: <11504.1416288450@sandelman.ca> <546B5B54.7010203@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010905080502010002060006" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/JuKGLcT-izwX27YtbkHMVVRsUr0 Cc: Michael Richardson , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] no meeting on Nov. 18 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, 21 Nov 2014 14:09:33 -0000 This is a multi-part message in MIME format. --------------010905080502010002060006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Thomas: Face to face meetings should be spent on items that do require face-to-face time, such as that on joining, which had 2 x 10 minutes slated for the end of the meeting. We did have lots of infomercials for 802.15.9kmp, etc., and other non-systematic discussion, that consumed bandwidth and that, frankly, were time wasters. Together with the presentation on ETSI (which could have been a webcast, since purely informational), this could have freed up more than 45 minutes. {Even with those subslots, we would have had more time, if the allocated timeslots would have been adhered to (a good example of TSTH (Time Slotted Topic Hopping)...)} It would help if people would realize more that participation in meetings is expensive, both in time and in budget, so it is imperative to make good use of this. On your question: we can discuss offline. I will contact you on Monday. Best regards, Rene On 11/21/2014 1:41 AM, Thomas Watteyne wrote: > Rene, > > While, same as you, I would have loved even more time to discuss > security, I believe we have spent close to an hour doing so, first > with lots of questions and discussions, then with the presentation of > the drafts. > > What alternative format are you proposing for the security work? > > Thomas > > On Tue, Nov 18, 2014 at 6:44 AM, Rene Struik > wrote: > > Hi Michael: > > Next week is Thanksgiving week in the USA, which we should respect. > > This aside, we should discuss next steps of 6TiSCH security work > (including agenda setting). Personally, I think past calls have > not worked well and I am not alone in this assessment. > > Sadly, there was no time allocated for this on the IETF-91 agenda. > I think this was a grave mistake. (Normally, face-to-face meetings > are primarily for things that are hard to discuss via email alone.) > > Best regards, Rene > > On 11/18/2014 12:27 AM, Michael Richardson wrote: >> I am travelling, and also many people are on vacation. >> We will resume on Nov. 25. >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 --------------010905080502010002060006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Thomas:

Face to face meetings should be spent on items that do require face-to-face time, such as that on joining, which had 2 x 10 minutes slated for the end of the meeting.

We did have lots of infomercials for 802.15.9kmp, etc., and other non-systematic discussion, that consumed bandwidth and that, frankly, were time wasters.  Together with the presentation on ETSI (which could have been a webcast, since purely informational), this could have freed up more than 45 minutes. {Even with those subslots, we would have had more time, if the allocated timeslots would have been adhered to (a good example of TSTH (Time Slotted Topic Hopping)...)}

It would help if people would realize more that participation in meetings is expensive, both in time and in budget, so it is imperative to make good use of this.

On your question: we can discuss offline. I will contact you on Monday.

Best regards, Rene

On 11/21/2014 1:41 AM, Thomas Watteyne wrote:
Rene,

While, same as you, I would have loved even more time to discuss security, I believe we have spent close to an hour doing so, first with lots of questions and discussions, then with the presentation of the drafts.

What alternative format are you proposing for the security work?

Thomas

On Tue, Nov 18, 2014 at 6:44 AM, Rene Struik <rstruik.ext@gmail.com> wrote:
Hi Michael:

Next week is Thanksgiving week in the USA, which we should respect.

This aside, we should discuss next steps of 6TiSCH security work (including agenda setting). Personally, I think past calls have not worked well and I am not alone in this assessment.

Sadly, there was no time allocated for this on the IETF-91 agenda. I think this was a grave mistake. (Normally, face-to-face meetings are primarily for things that are hard to discuss via email alone.)

Best regards, Rene

On 11/18/2014 12:27 AM, Michael Richardson wrote:
I am travelling, and also many people are on vacation.
We will resume on Nov. 25.




_______________________________________________
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

_______________________________________________
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
--------------010905080502010002060006-- From nobody Sun Nov 23 18:43:57 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 1BB4E1A1B3C for <6tisch-security@ietfa.amsl.com>; Sun, 23 Nov 2014 18:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TUesCqYw9Sbc for <6tisch-security@ietfa.amsl.com>; Sun, 23 Nov 2014 18:43:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBED1A1A52 for <6tisch-security@ietf.org>; Sun, 23 Nov 2014 18:43:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A28E20012 for <6tisch-security@ietf.org>; Sun, 23 Nov 2014 21:46:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 37C50637F5; Sun, 23 Nov 2014 21:43:52 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1E9B063745 for <6tisch-security@ietf.org>; Sun, 23 Nov 2014 21:43:52 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr 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/ibSCwS-IBZ-iBUJFX-5lsSzJDpo Subject: [6tisch-security] calls 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 Nov 2014 02:43:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable We will not have a 6tisch-security call this week either. But, if you want to spend the hour making suggestions to improve please go = ahead! =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) iQEVAwUBVHKbZYCLcPvd0N1lAQJQSAf+O1QSnbdRZVU6KJHvhNd5e2iGtDWlnEVy 2IyFMKiag9rI7eG42vSVDQ/weoxa6d/5dFeHyXJp1mZnbl/0zkR8bPw/1clJfW72 rkMFd/Z3tf01l6iuwNH+t82+wDgrcx7/bZZU0hid6jbq0rS+V3QKK79afJipTa64 ps6dDFAZ9a7XtWdM2T1hd+1qPHCYM+izto/VtqSmmwxnG+iX9P+LD0lzDpxwoqq8 iVQ/L66RzFiY2oI4qGgMDKel6s+cnyLoQi4c5/XAjL4y09tYqNVyzERMslspbRLj rqE96+HB9KwncoMm6kdvjY3fy6/uguomGfmuItcgvLSTKqyje4sJzg== =Zh3+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 24 01:31: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 D00121A1EED for <6tisch-security@ietfa.amsl.com>; Mon, 24 Nov 2014 01:31:16 -0800 (PST) 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, FUZZY_CPILL=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 GVhH8h3Emk1K for <6tisch-security@ietfa.amsl.com>; Mon, 24 Nov 2014 01:31:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33391A1EEB for <6tisch-security@ietf.org>; Mon, 24 Nov 2014 01:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4351; q=dns/txt; s=iport; t=1416821475; x=1418031075; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=o5ehvmwcwPkgL1P78frmfVNXt/NpyHyxobA5+HoBkSk=; b=XbFQuvQKIYVJReFRSWRrHUo0Fn9mMi0sB7tnGe8mmS7e3lQPivZiMgDP N520xeOZeQXmasV0B5jX9y8YGNn1A2PX84Qx9RIdoGm0e7K2yGwHfpkIs jDscZnwaqwvsaTag8N6Yn02GfEuxN4g9DWvEw9WeLZx+/BItWjx6yERsZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAHf5clStJV2Q/2dsb2JhbABSCYMOgS4EyFyJIwKBHRYBAQEBAX2EAgEBAQSBBQYBGQEDAQEBCh05FAMGCQEECgkIE4gmqQ+lIAEBAQEBAQEBAQEBAQEBAQEBARqQMCo+gymBHwWSaKMzggQegVt4gUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,447,1413244800"; d="scan'208";a="374758315" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 24 Nov 2014 09:31:13 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sAO9VCxY014890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch-security@ietf.org>; Mon, 24 Nov 2014 09:31:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 03:31:12 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: On peer-to-peer authentication ... Thread-Index: AdAHyUd934HMo8eSQZOoASimjTBKjA== Date: Mon, 24 Nov 2014 09:31:11 +0000 Deferred-Delivery: Mon, 24 Nov 2014 09:31:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/WS27aq2Vh9x0iMCPGDv4tx0DjUE Subject: [6tisch-security] On peer-to-peer authentication ... 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 Nov 2014 09:31:17 -0000 Cheers, Pascal -----Original Message----- From: Paul Lambert [mailto:paul@MARVELL.COM]=20 Sent: vendredi 21 novembre 2014 22:28 To: STDS-802-PRIVACY@LISTSERV.IEEE.ORG Subject: Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol On 11/6/14, 11:57 AM, "Robert Moskowitz" wrote: >On 11/06/2014 01:03 PM, Christian Huitema wrote: >>> Every participating device has a MAC entity Identity consisting of=20 >>>the public key of a ECDH keypair. A hash of this key into a 128 bit=20 >>>value is the MAC entity Identifier, much like the HIT in HIP. A hash=20 >>>with a nonce will be used to create the actual MACaddr used by the devic= e. >>>For privacy purposes, the ECDH keypair are ephemeral, a device can=20 >>>precompute a number of these and have them ready to use at will. For=20 >>>collision avoidance a device must be ready to use a different=20 >>>Identity or nonce to present a different MACaddr. >> Curious how that meshes with 802.1x/EAP, or with WPA2. Did you=20 >>research that? > >There is a high degree of commonality in these protocols. In part as=20 >there are only a few ways to do them right. Plus a few of us have=20 >worked on more than one. Lots of cross knowledge transfer. I=B9d disagree a little =D0 first the above key exchange is not quite right= , I=B9d suggest a blinded more static key usage (per EMV specification, plu= s a MAC blinding nonce). 802.1x/EAP is problem in the 802.11 security architecture. Doing good peer= -to-peer authentication is not well modeled hy the client/AP/AAA three-way = model of 802.1x and EAP. It would be much better to use pre-association frames for a key exchange. For new P2P authentication, there are multiple options: - action frames (my preference) - probe req/rsp (easy, but include legacy cruft and not efficient) - authenticate and/or associate frames - above per 802.11ai (existing, but rigidly in it=B9s own model of connect= ivity and may not map well to MAC address change requirements) WPA2 is in several parts =D0 the 802.1x setup is an issue (IMO) per above, = but is not necessary and easily left out. The WPA2 4-way handshake steps a= re required to get nonces for the CCM/GCM Tk. However, the YK could be more= directly estblished by a stream-lined authentication exchange (e.g. 802.11ai). Finally, the broadcast Group Key is shared during the 4-way exc= hange. This is a longer discussion =D0 since broadcast keys in a P2P envir= onment need to be device unique. Paul > >> >>> At linkup time, a device will listen for these broadcasts, use the=20 >>>public key therein along with its Identity key and a nonce to=20 >>>construct a shared secret. This secret will be used to MIC a packet=20 >>>to the mediator that will contain the devices: MACaddr, Nonce,=20 >>>Identifier, and Identity. If this is a new MACaddr for the mediator=20 >>>it would reply with an ACCEPT MICed message. If there is a=20 >>>collision, it will REJECT, causing the device to select a new MACaddr an= d try again. >> What if there is no link-up time, as in for example Wi-Fi probes?=20 >>When scanning for available networks, Wi-Fi devices send probe packets=20 >>to elicit responses from any access point that would be present. These=20 >>packets are sent infrequently, maybe every few minutes, while the=20 >>device is not connected to any network and is in fact moving between netw= orks. >>Uniqueness in one of these networks is not a guarantee of uniqueness=20 >>in the next one. > >First not only is there no reason to care what MACaddr is used for=20 >PROBES, Apple already uses a random one to not leak tackable=20 >information about the devices. Use ANY MACaddr you want. Could be a=20 >problem if there is a collision with an address that is already used and s= ecured. >> This scanning traffic is a well known target of tracking systems. >>Protecting it is a high priority. That's the first application of=20 >>randomized MAC addresses. And for that application, the simplest=20 >>solution is statistical uniqueness through large enough random numbers. > >If the address is only used for PROBES, just dream one up (local scope=20 >of course) and use it. This need not be the one you plan on actually=20 >using for the ASSOCIATION. From nobody Thu Nov 27 16:45: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 9BA591A0379 for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 16:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RsqS3KMbR-hW for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 16:45:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF251A0377 for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 16:45:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F2E02009E for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 19:48:04 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B9675637F6; Thu, 27 Nov 2014 19:45:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A07F763740 for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 19:45:03 -0500 (EST) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <316.1416522601@sandelman.ca> References: <316.1416522601@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/uX1mBDCYL1VkpcmAUCqaJE3NsOA Subject: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 00:45:07 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable We will meet on the next three Tuesdays:=20 2014-12-02,2014-12-09,2014-12-16. at 11am. I have left the webex recurrance until end of January, but we will not meet 2014-12-23, 2014-12-30. We will likely meet on 2015-01-06,2015-01= -13. [if you want to be on my calendar invite, unicast me] Here is the webex info: Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm1aa12258a83109b4ae291fb0c2bd92d= 6=20 The topic for next week is about the suggested text which was suggested two weeks ago. It's not perfect yet, and we need perhaps to clarify some thing= s. There is an existing thread about some of the technical assumptions, which I will list here: - join network encrypted or not, and related issues - authentication and authorization mechanisms - 6top/YANG specifics - document structural issues (where does the rest of the protocol go) The SecDir secretary, Tero Kivinen has assigned two people to do an early review of this join protocol; he assigned himself and Hilarie Orman. At some point, we may want to have them join our call; I leave the timing up to them.=20=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHfFi4CLcPvd0N1lAQI3iAf/Ze0D0UCHG87nVM7NEkMRAzMwFTHdGduD bazPaNdgdDNyRwZfwYoBd/O2ghx/xovCCq0/KXvYWQL6cnhZWUJOffdEnmU0+xRg VetY9LyiMqrqYPQt0WN09Q+QGoOdjJDOYF61/Z/sjfWfz/A0nOikG0XbLFlcUf9L UIYZxy5QszVd7bgShwKnoLATOlkncwR/HbwVVE/mxGNe1oyYgcsCDOpKZUrvYtf+ aTRjxZ7k+nS0OxXsozxGmXd+MI9Mipa3bCdGbEEl8JhmVD2Kwtm4h4MWHk5tGtla A4lu69faAxsDSYwKTECu2zbghS7QUt+hERLaYn9gSYJsDJcPjq099g== =dt4k -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 27 17:59: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 CD7531A03A4 for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 17:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 hRiWvEH5QPtn for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 17:59:09 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7FF1A03A2 for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 17:59:08 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sAS1x4cQ018731; Fri, 28 Nov 2014 10:59:04 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sAS1x4Nb024957; Fri, 28 Nov 2014 10:59:04 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id LAA24940; Fri, 28 Nov 2014 10:59:03 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sAS1x36D010543; Fri, 28 Nov 2014 10:59:03 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id sAS1x3Ww011287; Fri, 28 Nov 2014 10:59:03 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 10:59:03 +0900 From: To: , <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] agenda for upcoming 6tisch security calls Thread-Index: AQHQCqSS/qUvkGV4rEaiMJJFLn3Xe5x1Rg9Q Date: Fri, 28 Nov 2014 01:59:02 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0498B@TGXML210.toshiba.local> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> In-Reply-To: <16128.1417135503@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.148] 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/k9B877_v0RVxj9KFBl5BJR8fO6s Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 01:59:12 -0000 In which time zone is 11am? If it is 11am PST or EST, it is too inconvenie= nt for Asian members to join. Maybe what I can do is read minutes after the calls and send my comments / = opinions over email. Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Friday, November 28, 2014 9:45 AM To: 6tisch-security@ietf.org Subject: [6tisch-security] agenda for upcoming 6tisch security calls We will meet on the next three Tuesdays:=20 2014-12-02,2014-12-09,2014-12-16. at 11am. I have left the webex recurrance until end of January, but we wil= l not meet 2014-12-23, 2014-12-30. We will likely meet on 2015-01-06,2015-= 01-13. [if you want to be on my calendar invite, unicast me] Here is the webex info: Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118= Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm1aa12258a83109b4ae291fb0c2bd92d= 6=20 The topic for next week is about the suggested text which was suggested two= weeks ago. It's not perfect yet, and we need perhaps to clarify some thin= gs. There is an existing thread about some of the technical assumptions, which = I will list here: - join network encrypted or not, and related issues - authentication and authorization mechanisms - 6top/YANG specifics - document structural issues (where does the rest of the protocol go) The SecDir secretary, Tero Kivinen has assigned two people to do an early r= eview of this join protocol; he assigned himself and Hilarie Orman. At some point, we may want to have them join our call; I leave the timing u= p to them. =20 --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Thu Nov 27 18:42:13 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 9D53C1A03A7 for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 18:42:11 -0800 (PST) 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 ssPUXYpqRPSN for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 18:42:09 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA8D1A06E9 for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 18:42:09 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id rl12so5358648iec.33 for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 18:42:08 -0800 (PST) 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:content-transfer-encoding; bh=Uy7Vv/Z0Wuk+ffVWrIc5CD5JNbCngJ3SKuxlFrVOKxQ=; b=QZ9pgqOkHzagtTJrwjTabhHZIR1C79AdM7h/tckQikReg4M/1PoeooCX+RHlXO3Lhk ZEx9/PXguhgOPnSiA5o/rmZLbXjbJ4e8uRvNsUX+Bj4lCbvcRgJUIoCiFUt9rM9+UeNh CsGC8eWR8vpewTVicCrcSW3XR7c7p62T5vJNgEXdpM3I+hWhVLTsAEavgsUQaVOtiA5t iS1YG07i41peARX6UZflkHSl1GmJ2CS0fl2ANVmvl7CQURAgIfpBGi2BFdChJ1/d5KAf cuaKxrmVBvwvrMPJZw4XufXpjJtz90o0Sn2+se06rD+d2WfeMSWYDZlvSnibZpSHiX/x GF1Q== X-Received: by 10.107.11.88 with SMTP id v85mr36883779ioi.46.1417142528608; Thu, 27 Nov 2014 18:42:08 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id g70sm4419613ioe.18.2014.11.27.18.42.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 18:42:08 -0800 (PST) Message-ID: <5477E0FC.7090902@gmail.com> Date: Thu, 27 Nov 2014 21:42:04 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp, mcr+ietf@sandelman.ca, 6tisch-security@ietf.org References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B29D0498B@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D0498B@TGXML210.toshiba.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/F6qgGhfYxNawD6qmr94p0tnn2pw Subject: [6tisch-security] (different time to accommodate everyone; agenda point) Re: agenda for upcoming 6tisch security calls 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 Nov 2014 02:42:11 -0000 Dear colleagues: Why not having the call at a time that does tries and accommodate everyone's time zone to the largest degree possible? I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should allow people to have their private time in the 12am-6am time window. {Other groups do a much better job at this...} I would like to present in more detail the security architecture I described at IETF-91. First, though, I would like us to agree on security objectives (as were on my slides in Honolulu). All to be discussed on the call (I do respect peoples' important holidays in the year). Best regards, Rene On 11/27/2014 8:59 PM, yoshihiro.ohba@toshiba.co.jp wrote: > In which time zone is 11am? If it is 11am PST or EST, it is too inconvenient for Asian members to join. > Maybe what I can do is read minutes after the calls and send my comments / opinions over email. > > Yoshihiro Ohba > > > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Friday, November 28, 2014 9:45 AM > To: 6tisch-security@ietf.org > Subject: [6tisch-security] agenda for upcoming 6tisch security calls > > > We will meet on the next three Tuesdays: > 2014-12-02,2014-12-09,2014-12-16. > at 11am. I have left the webex recurrance until end of January, but we will not meet 2014-12-23, 2014-12-30. We will likely meet on 2015-01-06,2015-01-13. > [if you want to be on my calendar invite, unicast me] > > Here is the webex info: > Meeting number: 641 709 118 > Meeting password: joinjoin > Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 > > The topic for next week is about the suggested text which was suggested two weeks ago. It's not perfect yet, and we need perhaps to clarify some things. > There is an existing thread about some of the technical assumptions, which I will list here: > - join network encrypted or not, and related issues > - authentication and authorization mechanisms > - 6top/YANG specifics > - document structural issues (where does the rest of the protocol go) > > The SecDir secretary, Tero Kivinen has assigned two people to do an early review of this join protocol; he assigned himself and Hilarie Orman. > At some point, we may want to have them join our call; I leave the timing up to them. > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Nov 28 05:24:03 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 6A0DF1A1AFB for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 05:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 cmWxHcz4AviA for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 05:24:01 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAB11A1B4E for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 05:24:00 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so6034922ier.14 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 05:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8F7y1V4ngBOEJg2zXIqTSb8zwwj0KB29Aqs0nqU9dVw=; b=F+6EdrbU7hdSu0D3S9WcYrmzM5jVcNyR0n4siN7BTUmv6bBsz7YtHW+9ZZEhcBmAJc dBa5jrvj+diFbUwBKNRP0w5QQYPsSZRw5azhbWVQR3SJBc2Dq/6+Uv2V9d3nn7xkNp8e f5DZZVo3Z6o0nUobHeJtq9u+g3pBSlfv/zcB+ERbOOHzG2mBB76TQUfxPCR2nN7FNYSm 1MuLvxBKSV5injQ8eVHulJE9hfGxwkKhlxUsNJwFbJruo4MM2I+QYCpVpptKL6ZQXSNJ f8Lgyv788nLbs8FWYKJiFUZ/FD+BqXBe3o2f59OdU7HSuur3rq9O0JxBq07ruCg0C2JZ Q+Sg== MIME-Version: 1.0 X-Received: by 10.50.3.67 with SMTP id a3mr32626888iga.42.1417181039582; Fri, 28 Nov 2014 05:23:59 -0800 (PST) Received: by 10.42.246.136 with HTTP; Fri, 28 Nov 2014 05:23:59 -0800 (PST) In-Reply-To: <16128.1417135503@sandelman.ca> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> Date: Fri, 28 Nov 2014 08:23:59 -0500 Message-ID: From: Subir Das To: Michael Richardson Content-Type: multipart/alternative; boundary=089e013cbd5e7264f70508eb2cb8 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/nePtPNzCz3ousk-0ICaSAVaabHo Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 13:24:02 -0000 --089e013cbd5e7264f70508eb2cb8 Content-Type: text/plain; charset=UTF-8 Thanks for arranging the calls. It would be good to accommodate Asian time zone for broader participation. I would suggest choosing a time that is more or less convenient for everyone. One other option could be cycle the time so that everyone gets their favorite time zone. I understand that it is difficult to match with three continent's time zone but it is possible. -Subir On Thu, Nov 27, 2014 at 7:45 PM, Michael Richardson wrote: > > We will meet on the next three Tuesdays: > 2014-12-02,2014-12-09,2014-12-16. > at 11am. I have left the webex recurrance until end of January, but we > will > not meet 2014-12-23, 2014-12-30. We will likely meet on > 2015-01-06,2015-01-13. > [if you want to be on my calendar invite, unicast me] > > Here is the webex info: > Meeting number: 641 709 118 > Meeting password: joinjoin > Audio connection: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 641 709 118 > Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 > > The topic for next week is about the suggested text which was suggested two > weeks ago. It's not perfect yet, and we need perhaps to clarify some > things. > There is an existing thread about some of the technical assumptions, which > I will list here: > - join network encrypted or not, and related issues > - authentication and authorization mechanisms > - 6top/YANG specifics > - document structural issues (where does the rest of the protocol go) > > The SecDir secretary, Tero Kivinen has assigned two people to do an early > review of this join protocol; he assigned himself and Hilarie Orman. > At some point, we may want to have them join our call; I leave the timing > up > to them. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --089e013cbd5e7264f70508eb2cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for arranging the calls. It would be good to a= ccommodate Asian time zone for broader participation. I would suggest choos= ing a time that is more or less convenient for everyone. One other option c= ould be cycle the time so that everyone gets their favorite time zone.=C2= =A0 I understand that it is difficult to match with three continent's t= ime zone=C2=A0 but it is possible.=C2=A0

-Subir

On Thu, Nov 27, 2014= at 7:45 PM, Michael Richardson <mcr+ietf@sandelman.ca> = wrote:

We will meet on the next three Tuesdays:
=C2=A0 =C2=A02014-12-02,2014-12-09,2014-12-16.
at 11am.=C2=A0 I have left the webex recurrance until end of January, but w= e will
not meet 2014-12-23, 2014-12-30.=C2=A0 We will likely meet on 2015-01-06,20= 15-01-13.
[if you want to be on my calendar invite, unicast me]

Here is the webex info:
=C2=A0 Meeting number: 641 709 118
=C2=A0 Meeting password: joinjoin
=C2=A0 Audio connection:
=C2=A0 =C2=A0 1-877-668-4493 Call-in toll free number (US/Canada)
=C2=A0 =C2=A0 1-650-479-3208 Call-in toll number (US/Canada)
Access code: 641 709 118
Meeting link:
=C2=A0 https://ietf.webex.com/ietf/j.php?MTID= =3Dm1aa12258a83109b4ae291fb0c2bd92d6

The topic for next week is about the suggested text which was suggested two=
weeks ago.=C2=A0 It's not perfect yet, and we need perhaps to clarify s= ome things.
There is an existing thread about some of the technical assumptions, which<= br> I will list here:
=C2=A0 - join network encrypted or not, and related issues
=C2=A0 - authentication and authorization mechanisms
=C2=A0 - 6top/YANG specifics
=C2=A0 - document structural issues (where does the rest of the protocol go= )

The SecDir secretary, Tero Kivinen has assigned two people to do an early review of this join protocol; he assigned himself and Hilarie Orman.
At some point, we may want to have them join our call; I leave the timing u= p
to them.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.= sandelman.ca/=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2= =A0 =C2=A0 [



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


--089e013cbd5e7264f70508eb2cb8-- From nobody Fri Nov 28 07:32: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 9CF871A0052 for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r8GQ765ZWzhf for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:32:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8CF1A0073 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 07:32:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82CAE2009E for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 10:35:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B2060637F5; Fri, 28 Nov 2014 10:32:39 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9E82463740 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 10:32:39 -0500 (EST) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <16128.1417135503@sandelman.ca> References: <316.1416522601@sandelman.ca> <16128.1417135503@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/XpZDkH7sUg0dokjLjGAl7_k-VCI Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 15:32:42 -0000 Michael Richardson wrote: > We will meet on the next three Tuesdays: > 2014-12-02,2014-12-09,2014-12-16. > at 11am. I have left the webex recurrance until end of January, but we will > not meet 2014-12-23, 2014-12-30. We will likely meet on 2015-01-06,2015-01-13. Sorry, it's 11am Eastern. That's 8am Pacific, 11pm Beijing. From nobody Fri Nov 28 07:38:11 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 4FEA81A006C for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 rr6hjBRtb0FK for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:38:07 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828651A0052 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 07:38:07 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sASFc5Zw006984; Sat, 29 Nov 2014 00:38:05 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sASFc55m016275; Sat, 29 Nov 2014 00:38:05 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA16274; Sat, 29 Nov 2014 00:38:05 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sASFc4kx010153; Sat, 29 Nov 2014 00:38:04 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id sASFc4dF019398; Sat, 29 Nov 2014 00:38:04 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Sat, 29 Nov 2014 00:38:04 +0900 From: To: , <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] agenda for upcoming 6tisch security calls Thread-Index: AQHQCqSS/qUvkGV4rEaiMJJFLn3Xe5x1lOyAgACXmXA= Date: Fri, 28 Nov 2014 15:38:03 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D04D33@TGXML210.toshiba.local> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <328.1417188759@sandelman.ca> In-Reply-To: <328.1417188759@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.117] 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/kYDRwDDOIGe8jX4MiQpuElxt5Ys Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 15:38:10 -0000 11am Eastern is actually 0am Beijing and 1am Tokyo next day (it's not Dayli= ght Saving time now). Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Saturday, November 29, 2014 12:33 AM To: 6tisch-security@ietf.org Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls Michael Richardson wrote: > We will meet on the next three Tuesdays:=20 > 2014-12-02,2014-12-09,2014-12-16. > at 11am. I have left the webex recurrance until end of January, but = we will > not meet 2014-12-23, 2014-12-30. We will likely meet on 2015-01-06,2= 015-01-13. Sorry, it's 11am Eastern. That's 8am Pacific, 11pm Beijing. _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Fri Nov 28 07:39:34 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 721D51A006C for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MJtpZ_L0cUHx for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:39:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036901A0052 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 07:39:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CECA82009E; Fri, 28 Nov 2014 10:42:32 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 01F4F637F5; Fri, 28 Nov 2014 10:39:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E436E63740; Fri, 28 Nov 2014 10:39:29 -0500 (EST) From: Michael Richardson To: Subir Das In-Reply-To: References: <316.1416522601@sandelman.ca> <16128.1417135503@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/9ux1IQSJjurvDY_b231hwExgtw0 Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls 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 Nov 2014 15:39:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Subir Das wrote: > Thanks for arranging the calls. It would be good to accommodate Asian= time > zone for broader participation. I would suggest choosing a time that = is I'm happy to do this at another time; the original choice of 11am Eastern w= as to accomodate Pacific Time Zone People who couldn't meet before 8am.=20=20 From=20long experience, our choices essentially are at 15:00 UTC or 03:00 U= TC. 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing or 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing I am also happy to alternate. Shall I put up a doodle poll? =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) iQEVAwUBVHiXL4CLcPvd0N1lAQLzwQgAnOe1h2uTNrKmDr28Ub1ai1Gy2G6vaLqx wafoM4oyxJohfz4d7NADVvi5uXyXViNyL/qak7Fo/xwA5YsYph8mvNwWPiwR03Fn 6EvAAnO9V3wAjFMJW75SPmqrYOCbTTjqLIdgsB7gMr3d8loffW94a511sKBOeZ1L 52NQ64sMGDBMt4akIXRHz1jnk1eblGJgAd2kRQ/EoFD7LqnjUkRNbQBZKyrR4Aij rgCkKoNqWTL2zYbNUqrWF/433LgW5fasTubvpAZ1c+qHmy3hk7OUTOUrjGcPqIEj GGxEi/ZPnL8aO8lOIG98IYZvrmPhPboqyGAIKPzukGoWGv1kfgb99A== =u1lo -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 28 07:40: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 B77481A0052 for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DFT5qCNck2II for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 07:40:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0076E1A006C for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 07:40:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 136772009E; Fri, 28 Nov 2014 10:43:53 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 464C9637F5; Fri, 28 Nov 2014 10:40:50 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 305AF637EA; Fri, 28 Nov 2014 10:40:50 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <5477E0FC.7090902@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B29D0498B@TGXML210.toshiba.local> <5477E0FC.7090902@gmail.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/mDxvpy9xpn96I17C2y9xgIAlsVQ Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (different time to accommodate everyone; agenda point) Re: agenda for upcoming 6tisch security calls 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 Nov 2014 15:40:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: > First, though, I would like us to agree on security objectives (as we= re on my > slides in Honolulu). You are most welcome to send text that we can comment on. =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) iQEVAwUBVHiXf4CLcPvd0N1lAQItcQf+OSwfwIU+s/0CmviXpbntk99XpW8FaNd0 XbVlV5DurpOVIcAzX56P9/+Ryti2Nh25m+4md5B0Jm4I/mmDRburiyZNL38jShm5 Dsbe53wQVhhy4pxr/jMlps36MrYseON2Mv76KsIQg4iZFrUjvpaMSK+KsJoVGQB9 3tQwsZ31aWvGoOsEwuchvguSetC8/x8XgmBzYhMPGeABtwSIidZ0osdPxIh7gSKm TPH3ASzwaeJqVnz8OJYzjOfRqebST1JwMPs/mJdXPEnaz9dI6BrCyX55qy86N41g pCSam5dvf+Zik3WGy1w3Opgfm3tlc0VH9lKIs7AmS9qyA+TIlNhPYQ== =GTDJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 28 08:02:22 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 210731A00A2 for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 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, MALFORMED_FREEMAIL=2.899, MISSING_HEADERS=1.021, 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 J1Di7AYB2Kyf for <6tisch-security@ietfa.amsl.com>; Fri, 28 Nov 2014 08:02:19 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA1F1A0121 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 08:02:18 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x19so1146691ier.20 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 08:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=QuTWccheQ2UVitfyoLA7Pk1rBGLCbSgX+oI4CnGJ8Mo=; b=bHlDHF3vGQIvlkOXd/gS1t7aGDosWk5ADsBs87l6ZXkRCUbWOjgyw+wtYQIpbhIO4+ p6h0KLTa1xLOnd6cFzavUuihO9eqKBeezqKMEWjzTyH+q/O9zXWPn7RHU7W4D80IENi3 kEvBqd+sVhxlnLNzQIblniyFObVv3zYWpujVWaPHqlkBhYmas/Ib6q1W2H5Z7tiaNdHg BKeE15ZRTYhbxH/FrWO6uIBSxEqSkDAwU/CRFLkeL6Zl81HqjBot4KlGQtXBm5JjpmJx IfL4tUlfdERVA5ZImi43I2shQgQes/axVpLK8Ne3xC7Y6UJVPX8EOqq7DM/SBq7LJls8 luVA== X-Received: by 10.42.175.3 with SMTP id ay3mr43265900icb.45.1417190537662; Fri, 28 Nov 2014 08:02:17 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id qj3sm5751551igc.17.2014.11.28.08.02.17 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Nov 2014 08:02:17 -0800 (PST) Message-ID: <54789C85.1080505@gmail.com> Date: Fri, 28 Nov 2014 11:02:13 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: 6tisch-security@ietf.org References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> In-Reply-To: <1758.1417189169@sandelman.ca> Content-Type: multipart/alternative; boundary="------------040909030208050604020601" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/NuBE0Z1BGSafO1XoxYfHachKW8Q Subject: [6tisch-security] invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan 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 Nov 2014 16:02:21 -0000 This is a multi-part message in MIME format. --------------040909030208050604020601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues: I have set up a conf call for Tuesday December 2, 2014 at a time that tries and accommodate people in different time zones to the largest extent possible, without trying to discriminate against various parts of the world. Please see dial-in information below. Agenda to follow Monday around noon. Looking forward to a collaborative meeting, in good spirit. Best regards, Rene == 1.Please join my meeting. https://global.gotomeeting.com/join/594299061 2.Use your microphone and speakers (VoIP) - a headset is recommended.Or, call in using your telephone. Dial +1 (647) 497-9351 Access Code: 594-299-061 Audio PIN: Shown after joining the meeting Meeting Password: collaborate Meeting ID: 594-299-061 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting app. [excerpt email as of Thu November 27, 2014, 9.42pm EST] I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should allow people to have their private time in the 12am-6am time window. {Other groups do a much better job at this...} On 11/28/2014 10:39 AM, Michael Richardson wrote: > Subir Das wrote: > > Thanks for arranging the calls. It would be good to accommodate Asian time > > zone for broader participation. I would suggest choosing a time that is > > I'm happy to do this at another time; the original choice of 11am Eastern was > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > or > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > I am also happy to alternate. > Shall I put up a doodle poll? > > > > _______________________________________________ > 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 --------------040909030208050604020601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dear colleagues:


I have set up a conf call for Tuesday December 2, 2014 at a time that tries and accommodate people in different time zones to the largest extent possible, without trying to discriminate against various parts of the world.


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

==


1.  Please join my meeting.

https://global.gotomeeting.com/join/594299061

 

2.  Use your microphone and speakers (VoIP) - a headset is recommended.  Or, call in using your telephone.

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

Not at your computer? Click the link to join this meeting from your iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting app.




[excerpt email as of Thu November 27, 2014, 9.42pm EST]
I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should allow people to have their private time in the 12am-6am time window. {Other groups do a much better job at this...}


On 11/28/2014 10:39 AM, Michael Richardson wrote:
Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate Asian time
    > zone for broader participation. I would suggest choosing a time that is

I'm happy to do this at another time; the original choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.  

>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing

I am also happy to alternate.
Shall I put up a doodle poll?




_______________________________________________
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
--------------040909030208050604020601-- From nobody Sat Nov 29 07:14:47 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 DC95D1A1A66 for <6tisch-security@ietfa.amsl.com>; Sat, 29 Nov 2014 07:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 qfzhV2wO_ygD for <6tisch-security@ietfa.amsl.com>; Sat, 29 Nov 2014 07:14:44 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AE21A1A57 for <6tisch-security@ietf.org>; Sat, 29 Nov 2014 07:14:43 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so8199954pdb.32 for <6tisch-security@ietf.org>; Sat, 29 Nov 2014 07:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=spNOc6J9NpB6KZhJpeeKuM/xFdiCaclMsjSm7bX6uaE=; b=l2NQNZLH+nVRybTKrXtj3DsXDmiutOiQBrWGHjkuunnXahDL10ooxw9s8J7H9JRjLg pA7+yXYLSOFr1rzHPrYGwi+jQK5tRD6pQzxARkCfVyuClH0cM1Gxm5kwDslLsoMWtHnm k03bqwlQIOIJS6EBJDgeRtLgO8gz2Jl1/UurNahbqCtxdShzZAt8IOnZsm+X8BmJohh+ gVLqLJllk1Cs1ZZBqG5YaQufFO8A6PvXBR0MSeEF/aF29ZT2/pYKGl4y8SyOK/2ipmQi kyHR8xvaspNWx29Dd3GZgmAHYdZuK9f9OaT/z+qf+8awN1F2rSsYAMl1Pya/kayVk3Od GroA== X-Received: by 10.70.45.72 with SMTP id k8mr84407094pdm.146.1417274083029; Sat, 29 Nov 2014 07:14:43 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.150.69 with HTTP; Sat, 29 Nov 2014 07:14:22 -0800 (PST) In-Reply-To: <54789C85.1080505@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> From: Thomas Watteyne Date: Sat, 29 Nov 2014 07:14:22 -0800 X-Google-Sender-Auth: C0u33N07BDH6u1COztZyASXPFXU Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=089e0111dd5244b92b050900d608 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/CJqwwf_BXsGjy4xnCFw6ignAxqo Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan 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: Sat, 29 Nov 2014 15:14:46 -0000 --089e0111dd5244b92b050900d608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rene, Michael, I'm totally confused now. There are 2 call-in details out for December 2: - http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00279.htm= l at 7am PST, from Michael, proposing to discuss the text submitted to secdir - http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00287.htm= l at 6am PST, from Rene, "agenda to follow Monday around noon" I assume those e-mails crossed one another. I'll let *Jonathan* and *Kris* comment on their availability at 6am PST. Thomas On Fri, Nov 28, 2014 at 8:02 AM, Rene Struik wrote: > Dear colleagues: > > > I have set up a conf call for Tuesday December 2, 2014 at a time that > tries and accommodate people in different time zones to the largest exten= t > possible, without trying to discriminate against various parts of the wor= ld. > > > Please see dial-in information below. > > > Agenda to follow Monday around noon. > > > Looking forward to a collaborative meeting, in good spirit. > > > Best regards, Rene > > =3D=3D > > > 1. Please join my meeting. > > https://global.gotomeeting.com/join/594299061 > > > > 2. Use your microphone and speakers (VoIP) - a headset is recommended. = Or, > call in using your telephone. > > > > Dial +1 (647) 497-9351 > > Access Code: 594-299-061 > > Audio PIN: Shown after joining the meeting > > > > Meeting Password: collaborate > > Meeting ID: 594-299-061 > > > > GoToMeeting=C2=AE > > Online Meetings Made Easy=C2=AE > > > > Not at your computer? Click the link to join this meeting from your > iPhone=C2=AE, iPad=C2=AE, Android=C2=AE or Windows Phone=C2=AE device via= the GoToMeeting app. > > > > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This should a= llow > people to have their private time in the 12am-6am time window. {Other > groups do a much better job at this...} > > > On 11/28/2014 10:39 AM, Michael Richardson wrote: > > Subir Das wrote: > > Thanks for arranging the calls. It would be good to accommodate Asi= an time > > zone for broader participation. I would suggest choosing a time tha= t is > > I'm happy to do this at another time; the original choice of 11am Eastern= was > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > >From long experience, our choices essentially are at 15:00 UTC or 03:00 = UTC. > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > or > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > I am also happy to alternate. > Shall I put up a doodle poll? > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/= mailman/listinfo/6tisch-security > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --089e0111dd5244b92b050900d608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rene, Michael,

I'm totally confused= now.

There are 2 call-in details out for December= 2:
- http://www.ietf.org/mail-arch= ive/web/6tisch-security/current/msg00279.html at 7am PST, from Michael,= proposing to discuss the text submitted to secdir
-=C2=A0http://www.ietf.org/mail-archive/web/6tisch-security= /current/msg00287.html at 6am PST, from Rene, "agenda to follow Mo= nday around noon"

I assume those e-mails cros= sed one another.

I'll let Jonathan = and Kris=C2=A0comment on their availability at 6am PST.
Thomas

On Fri, Nov 28, 2014 at 8:02 AM, Rene Struik <rstruik.ex= t@gmail.com> wrote:
=20 =20 =20
=20

Dear colleagues:


I have set up a conf call for Tuesday December 2, 2014 at a time that tries and accommodate people in different time zones to the largest extent possible, without trying to discriminate against various parts of the world.


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

=3D=3D


1.= =C2=A0 Please join my meeting.

https://g= lobal.gotomeeting.com/join/594299061

=C2= =A0

2.= =C2=A0 Use your microphone and speakers (VoIP) - a headset is recommended.=C2=A0 Or, call in using your telephone.

=C2= =A0

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

=C2= =A0

Meeting Password: collaborate

Meeting ID: 594-299-061

=C2= =A0

GoToMeetin= g=C2=AE

Online Meetings Made Easy=C2=AE

=C2= =A0

Not at your computer? Click the link to join this meeting from your iPhone=C2=AE, iPad=C2=AE, Android=C2=AE or Windows Phone=C2=AE de= vice via the GoToMeeting app.

=20 =20 =20 =20 =20 =20 =20


[excerpt email as of Thu November 27, 2014, 9.42pm EST]
I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This shou= ld allow people to have their private time in the 12am-6am time window. {Other groups do a much better job at this...}


On 11/28/2014 10:39 AM, Michael Richardson wrote:
Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate As=
ian time
    > zone for broader participation. I would suggest choosing a time th=
at is

I'm happy to do this at another time; the original choice of 11am Easte=
rn was
to accomodate Pacific Time Zone People who couldn't meet before 8am. =
=20

>From long experience, our choices essentially are at 15:00 UTC or 03:00=
 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing

I am also happy to alternate.
Shall I put up a doodle poll?




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



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=

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


--089e0111dd5244b92b050900d608-- From nobody Sat Nov 29 08:22:45 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 312B51A033A for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 16:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 MxKDH7IK5gFc for <6tisch-security@ietfa.amsl.com>; Thu, 27 Nov 2014 16:22:33 -0800 (PST) Received: from sjmda14.webex.com (sjmda14.webex.com [64.68.124.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5581D1A026F for <6tisch-security@ietf.org>; Thu, 27 Nov 2014 16:22:33 -0800 (PST) Received: from jva2tc114.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda14.webex.com (Postfix) with ESMTP id CCCA7801D4 for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 00:22:32 +0000 (GMT) Received: from jva2tc114.webex.com (localhost [127.0.0.1]) by jva2tc114.webex.com (Postfix) with ESMTP id 7BEF115F54A for <6tisch-security@ietf.org>; Fri, 28 Nov 2014 00:22:32 +0000 (GMT) Date: Fri, 28 Nov 2014 00:22:32 +0000 (GMT) From: Michael Richardson To: 6tisch-security@ietf.org Message-ID: <1371112680.57528.1417134152494.JavaMail.nobody@jva2tc114.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_57526_789626480.1417134152493" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/gYWY1c-OvPMAK_48Q50TzV4QlVQ X-Mailman-Approved-At: Sat, 29 Nov 2014 08:22:43 -0800 Subject: [6tisch-security] WebEx meeting invitation: 6tisch security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca 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 Nov 2014 00:22:35 -0000 ------=_Part_57526_789626480.1417134152493 Content-Type: multipart/Alternative; boundary="----=_Part_57527_1950794547.1417134152493" ------=_Part_57527_1950794547.1417134152493 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKCjZ0aXNjaCBzZWN1cml0eQpFdmVyeSBUdWVzZGF5LCBmcm9tIFR1ZXNkYXks IERlY2VtYmVyIDIsIDIwMTQsIHRvIFR1ZXNkYXksIEphbnVhcnkgMjAsIDIwMTUKMTE6MDAgYW0g IHwgIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkgIHwgIDEgaHIK CgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bTQ5NTQ4YmYxMzFhZTM5ZjY0Mzk1MDBiMGQyNWI4NWM5Ck1lZXRpbmcgbnVtYmVyOiA2NDEg NzA5IDExOApNZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pbgoKDQpKT0lOIEJZIFBIT05FDQoxLTg3 Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3 OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0MSA3 MDkgMTE4CgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4 LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0 byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t ZGQ4ZTE5MWM4Yzc1YjE4ZmM3NjIwMWU3ZDU2YWZiODMNCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRp bmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMK CgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uCg== ------=_Part_57527_1950794547.1417134152493 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPjZ0aXNjaCBzZWN1cml0eTwvYj4KCQkJCQkJCQk8L3RkPgoJCQkJ CQkJPC90cj4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPkV2ZXJ5 IFR1ZXNkYXksIGZyb20gVHVlc2RheSwgRGVjZW1iZXIgMiwgMjAxNCwgdG8gVHVlc2RheSwgSmFu dWFyeSAyMCwgMjAxNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxl PSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+MTE6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7RWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKSZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsxIGhyCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFi bGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9Indp ZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQg c3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNDk1NDhiZjEzMWFlMzlmNjQz OTUwMGIwZDI1Yjg1YzkiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9u dC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1lZXRp bmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFu dCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFk ZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQkJPHRkPjY0MSA3MDkgMTE4CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIHBh c3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPmpvaW5qb2luPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQg c3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0 ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwt aW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBj b2RlOiZuYnNwOzY0MSA3MDkgMTE4PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk PjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAw QUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJs ZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9 ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tZGQ4ZTE5MWM4Yzc1YjE4ZmM3NjIwMWU3ZDU2YWZiODMiIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVl dGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250 LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAg Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAg ICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRh YmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4 Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJ CQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90 cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_57527_1950794547.1417134152493-- ------=_Part_57526_789626480.1417134152493 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEyMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEyMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnCk9SR0FO SVpFUjtDTj0iTWljaGFlbCBSaWNoYXJkc29uIjpNQUlMVE86bWNyK25vbWNvbUBzYW5kZWxtYW4u Y2EKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjAyVDExMDAwMApEVEVORDtUWklE PSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjAyVDEyMDAwMApSUlVMRTpGUkVRPVdFRUtMWTtJTlRFUlZB TD0xO0JZREFZPVRVO0NPVU5UPTgKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MQpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4wNDU2 NjgwLTMxMjA3MzU1Ny1TVT1pZXRmCkRUU1RBTVA6MjAxNDEyMDJUMTYwMDAwWgpERVNDUklQVElP TjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW00OTU0OGJmMTMxYWUzOWY2NDM5NTAwYjBkMjViODVjOVxuTWVldGluZyBudW1i ZXI6IDY0MSA3MDkgMTE4XG5NZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pblxuXG5cbkpPSU4gQlkg UEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRh KSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2Vz cyBjb2RlOiA2NDEgNzA5IDExOFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxu aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5c bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10 ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJ WkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tNDk1NDhiZjEzMWFlMzlmNjQzOTUwMGIwZDI1Yjg1YzkiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJ CTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj42NDEgNzA5IDExODwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPmpvaW5qb2luPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJS PjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2 OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEp PC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MSA3MDkgMTE4PC9GT05UPiZuYnNw OyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0 aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9s bC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+ PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNw OzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFO VCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRp byBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVj b3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpv aW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48 L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOjZ0aXNjaCBzZWN1cml0eQpQUklPUklUWTo1CkNMQVNTOlBV QkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQxME0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJ T046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_57526_789626480.1417134152493--