From nobody Mon Mar 6 09:14:04 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66158129626 for <6tisch-security@ietfa.amsl.com>; Mon, 6 Mar 2017 09:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WpsoAVYfGdUH for <6tisch-security@ietfa.amsl.com>; Mon, 6 Mar 2017 09:14:01 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A434112957F for <6tisch-security@ietf.org>; Mon, 6 Mar 2017 09:14:00 -0800 (PST) X-AuditID: c1b4fb3a-29b639800000484c-1c-58bd98d63b07 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 1A.0C.18508.6D89DB85; Mon, 6 Mar 2017 18:13:59 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.200]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Mon, 6 Mar 2017 18:13:38 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Michael Richardson Thread-Topic: [6tisch-security] slides you presented Thread-Index: AQHSjNhj/O61zu/6fEqs5XyYLuNd26F2NsWAgAHjUYCAACGUAIACRdeAgA2e0gA= Date: Mon, 6 Mar 2017 17:13:38 +0000 Message-ID: References: <3614.1487943075@obiwan.sandelman.ca> <27787.1488075235@obiwan.sandelman.ca> In-Reply-To: <27787.1488075235@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <9D21C65C0C6B734E8E5DE461360C8367@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7h+71GXsjDKZvZ7RoXrmI3eLR/lVs Fj2H+tkdmD2WLPnJ5NEyZw+zx4mG7ewBzFFcNimpOZllqUX6dglcGfPuNbMVLBGu+NH/ibWB 8YlQFyMnh4SAicSifU2sXYxcHEIC6xglFp1/wALhLGaU6Nj7mBWkik3AReJBwyMmEFtEQE9i +ZFnjCA2s0CZxLeG5WBxYQFjiWu/FwHVcwDVmEi8fakDUe4n8XfVEhYQm0VAReLouetg5bwC FhKfZxxghtj1nFFiwfpzYAlOoDlrJk0BsxkFxCS+n1rDBLFLXOLWk/lMEFcLSCzZc54ZwhaV ePn4H9idoiC3PV8DFVeU2Hm2nRnkHmYBTYn1u/QhxlhLXDz3lRnCVpSY0v2QHeIeQYmTM5+w TGAUn4Vk2yyE7llIumch6Z6FpHsBI+sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMAIPLjl t9UOxoPPHQ8xCnAwKvHwFlTujRBiTSwrrsw9xCjBwawkwhvcABTiTUmsrEotyo8vKs1JLT7E KM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qB0S3w/4nitoWXH01/4KJ35HuZUEX5VR/r DtUDXZkGbPviNP9MeJAVJcct/bZJ5fmiyelrH72/lcKz0FL0gk/G1dk25cc0BF0ef4zrvbTb kPsiq9ja7r9ne5ZulBa0OcTFq7o4xPXnftP2zC3cS57InC5qEg063tkWsmAei6VZrM+iRVMk 5yxpU2Ipzkg01GIuKk4EANSbKmK8AgAA Archived-At: Cc: "consultancy@vanderstok.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] slides you presented X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 17:14:02 -0000 SGkgTWljaGFlbCwNCg0KWW91IGFza2VkIGhvdyB0byBkZWZpbmUga2V5IGlkZW50aWZpZXJzIGZv ciB0aGUgbXVsdGlwbGUga2V5cyBkZXJpdmVkIHdpdGgNCkVESE9DLg0KDQpGaXJzdCBvZiBhbGws IGl0IGlzIG5vdCBjbGVhciB0aGF0IGl0IGlzIG5lZWRlZCBpbiB0aGlzIGNhc2UuIElmIHlvdQ0K ZGVyaXZlIE9TQ09BUCBrZXlzIGZvciB1c2Ugd2hlbiBwcm90ZWN0aW5nIGNvbW11bmljYXRpb24g YmV0d2VlbiBvbmUNCmRldmljZSBhbmQgaXRzIG1hbmFnZW1lbnQgZGV2aWNlLCB0aGVuIHRob3Nl IGtleXMgY291bGQgYmUgdXNlZCBmb3INCmFjY2Vzc2luZyBtdWx0aXBsZSByZXNvdXJjZXMgYW5k IHJldmVyc2luZyByb2xlcyBvZiBjbGllbnQgYW5kIHNlcnZlci4NCg0KSW4gdGhlIGN1cnJlbnQg dmVyc2lvbiBvZiBFREhPQyBlYWNoIHBhcnR5IGNhbiBkZWZpbmUgaXRzIG93biBpZGVudGlmaWVy DQpmb3Igb25lIGRlcml2ZWQga2V5LCBlbmFibGluZyBsb2NhbCB1bmlxdWVuZXNzIHdpdGhvdXQg d2FzdGluZyBieXRlcyB3aXRoDQpsYXJnZSBpZGVudGlmaWVycy4NCg0KDQpJZiB5b3Ugd2FudCB0 byBndWFyYW50ZWUgZ2xvYmFsIHVuaXF1ZW5lc3MgZm9yIG11bHRpcGxlIGlkZW50aWZpZXJzLCBv bmUNCndheSBpcyB0byBkZXJpdmUgbGFyZ2UgcHNldWRvcmFuZG9tIG51bWJlcnMgdXNpbmcgdGhl IHNhbWUga2V5IGRlcml2YXRpb24NCmFuZCBzcGVjaWFsIGxhYmVscy4gIEhvdyB0byBnZW5lcmF0 ZSBsb2NhbGx5IHVuaXF1ZSBzbWFsbCBrZXkgaWRlbnRpZmllcnMNCmZvciBtdWx0aXBsZSBrZXlz IGlzIGN1cnJlbnRseSBub3QgaW4gc2NvcGUgb2YgRURIT0MsIGFuZCBpbiBnZW5lcmFsDQpkZXBl bmRzIG9uIHRoZSBhcHBsaWNhdGlvbiBhbmQgaG93IHRoZSBsb2NhbGx5IGdlbmVyYXRlZCBpZGVu dGlmaWVycyBhcmUNCmtlcHQgdW5pcXVlLg0KT25lIGFwcGxpY2F0aW9uIGNvdWxkIGUuZy4gb3Jk ZXIgYW5kIGtlZXAgdHJhY2sgb2Yga2V5IGlkZW50aWZpZXJzIGFuZA0KYWxsb2NhdGUgZGVyaXZl ZCBrZXlzIHNlcXVlbnRpYWxseS4NCg0KSG9wZSB0aGF0IGhlbHBzLg0KDQpHw7ZyYW4NCg0KDQpP biAyMDE3LTAyLTI2IDAzOjEzLCAiTWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2lldGZAc2FuZGVs bWFuLmNhPiB3cm90ZToNCg0KPg0KPkfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJp Y3Nzb24uY29tPiB3cm90ZToNCj4gICAgPiBTZWN0aW9uIDMuMiBkZXNjcmliZXMgdGhlIGtleSBk ZXJpdmF0aW9uIGFuZCBhbGxvd3MgdGhlIGRlZmluaXRpb24NCj5vZiBhbg0KPiAgICA+IGFwcGxp Y2F0aW9uIHNwZWNpZmljIGxhYmVsIChieXRlIHN0cmluZykgd2hpY2ggaXMgdXNlZCB0byBkZXJp dmUgYW4NCj4gICAgPiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBrZXkgZnJvbSB0aGUga2V5IGVzdGFi bGlzaGVkIHRocm91Z2ggdGhlIHJ1bg0KPm9mIEVESE9DLg0KPg0KPiAgICA+IEhvdyB0aGlzIGlz IHVzZWQgdG8gZGVyaXZlIHRoZSBPU0NPQVAgbWFzdGVyIHNlY3JldC9zYWx0IHlvdSBmaW5kIGlu DQo+ICAgID4gYXBwZW5kaXggQi4yLg0KPg0KPmh0dHBzOi8vYml0YnVja2V0Lm9yZy9tY3IzMTQv ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS9jb21taXRzLzE1DQo+Mzg3MDkxOTc3 ZDQwODEwM2NkNzJmMTJmNzAwOGE1MDQ4M2ZjNDANCj4NCj4tLQ0KPk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQo+IC09 IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4NCj4NCj4NCg0K From nobody Tue Mar 7 09:45:34 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366721295BF for <6tisch-security@ietfa.amsl.com>; Tue, 7 Mar 2017 09:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4h-Thl-POuNz for <6tisch-security@ietfa.amsl.com>; Tue, 7 Mar 2017 09:45:32 -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 F1AFC129527 for <6tisch-security@ietf.org>; Tue, 7 Mar 2017 09:45:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C7E5C203CA; Tue, 7 Mar 2017 13:08:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A2273636BB; Tue, 7 Mar 2017 12:45:30 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FB=3FR8O2cmFuIFNlbGFuZGVy=3F=3D?= In-Reply-To: References: <3614.1487943075@obiwan.sandelman.ca> <27787.1488075235@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: "consultancy@vanderstok.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] slides you presented X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 17:45:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable G=C3=B6ran Selander wrote: > You asked how to define key identifiers for the multiple keys derived= with > EDHOC. > First of all, it is not clear that it is needed in this case. If you > derive OSCOAP keys for use when protecting communication between one > device and its management device, then those keys could be used for > accessing multiple resources and reversing roles of client and server. We do not have to derive new keys, it is true. My thought is that doing this is cleaner cryptographically, and also isolat= es one set of keys in one application to another. I suggest this as a way to most clearly seperate the 6tisch-minimal-security bootstrap process from the 6tisch-minimal-rekey process. I don't think it's essential. > In the current version of EDHOC each party can define its own identif= ier > for one derived key, enabling local uniqueness without wasting bytes = with > large identifiers. Agreed. > If you want to guarantee global uniqueness for multiple identifiers, = one > way is to derive large pseudorandom numbers using the same key deriva= tion > and special labels. How to generate locally unique small key identif= iers > for multiple keys is currently not in scope of EDHOC, and in general > depends on the application and how the locally generated identifiers = are > kept unique. > One application could e.g. order and keep track of key identifiers and > allocate derived keys sequentially. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli+8boACgkQgItw+93Q 3WUU7Af9EGjNnSIHPOUo4k8G+ynYaobEgqty1B6/I8m8nzLLnDotBCffvgNTMJHv sBdxX5NVV8wxKCA5eb0Ak6vvCFCyDPR8v/4r0YttlBI7S+bl3rNWe6nmWMTmoM+o Cm3lqEc7HnxjQkUOZ7hHWGl8NfTVeOxPRWgj69NoqnwjD4MxIrg2w0DXrCFY5Qfs Ng3+rlNBdVQhc1k7+eb2Kj06QEwNqGg3PSQNWca1XzNFyOo8Xu+00sEHRoM/aWPw z6ldebt3iVVA5Yjpg3c07ojWRT4q9gEYindUXEaklMrOEUqEPwl5G/wt0xqk56SX jYJHIubktCtoEKA4K+ycNFaFZ3t9+w== =t57W -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 18:25:00 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF17A1294C9 for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 18:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3Dnj52F3ekAJ for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 18:24:57 -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 6F3B71294C4 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 18:24:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F1864200A3 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 18:09:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 44F776381A for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 17:46:36 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: [6tisch-security] some proposed changes to 6tisch-minimal-security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:24:59 -0000 --=-=-= Content-Type: text/plain This makes it clear how the pledge should process the EB: https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/78b8e6455dc9500c7c0de43960f282ccb9529d24 +A pledge which receives only Enhanced Beacons containing Network ID extensions +{{I-D.richardson-6tisch-join-enhanced-beacon}} with the initiate bit cleared, SHOULD NOT +proceed with this protocol on that network. The pledge SHOULD consider that it +is in a network which manages join traffic, it SHOULD switch to {{I-D.ietf-6tisch-dtsecurity-secure-join}}. This makes it clearer that certificates do not necessarily mean that it is a zero-touch case: if they are locally relevant, then it's just a rejoin after a long sleep. https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/e283fd274ab2d4ee8e0d1a3467f27d4d1dc3963f REQUIRED for RPKs and certificates. + +When using certificates, the process continues as described in {{I-D.selander-ace-cose-ecdhe}}, +but MAY result in no network key being returned. In that case, the pledge enters a +provisional situation where it provides access to an enrollment mechanism described in +{{I-D.ietf-6tisch-dtsecurity-secure-join}}. + +If using a locally relevant certificate, the pledge will be able to validate the +certificate of the JRC via a local trust anchor. In that case, the JRC will +return networks keys as in the PSK case. This would typically be the case for +a device which has slept so long that it no longer has valid network keys and must go through +a partial join process again. This makes it clearer that the mechanism is not limited to AES-CCM, but that negotiation could occur via EDHOC: https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/627b2bff648ccb9ec47c59d0cd8d710d9b64742b +The join request is typically authenticated/encrypted end-to-end using AES-CCM-16-64-128 +algorithm from {{I-D.ietf-cose-msg}} and a key derived from the shared secret from step 3. +This is described in detail in {{I-D.selander-ace-cose-ecdhe}}, which also provides for algorithm agility. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljB20oACgkQgItw+93Q 3WUWTQgAj6IDMU6FJuRE9qJYO9ilEkUixDbIxClwk9kLAlATd2TCAPsCq9QAXx0V KmkamkCoxOcJmRK7GKQg9WHdYib2c3FOlp6Mehhe0geqnHDfdWOuR+bLqrlABr6j 4QNiN1I61CbQucO3v1syDeoOrtZoMubCr6RpbqeuUhFFDfsj+S5jt7t830l/IFVQ CV/UubjPsSiNsao1LQT7fQUkFM2Jhs4/FmceK1Uk8oSpG2lgEP9lRHnKhLL74Agd 8AcmghBl30Ov1kPM4arzUQrm9qOcheDZpbimpKFEke1Kq786Zk2IWr/b4q2BCm3r mmBYLSGreUhteNNo2BjuZM6gPkGHQw== =MTMZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 19:04:54 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5A12953C for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 19:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jnSNiSQ-TJo9 for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 19:04: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 C5565129530 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 19:04:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A22BE1FD; Thu, 9 Mar 2017 19:58:23 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 511FF6381A; Thu, 9 Mar 2017 19:35:36 -0500 (EST) From: Michael Richardson to: 6tisch-security@ietf.org In-Reply-To: <7579.1488907684@obiwan.sandelman.ca> References: <7579.1488907684@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: =?us-ascii?Q?=3D=3Fus-ascii=3FQ=3F=3D3D=3D3Futf-8=3D3FB=3D3FTWFsacWhYS?= =?us-ascii?Q?BWdcSNaW5pxIc=3D3D=3D3F=3D3D=3F=3D?= , =?us-ascii?Q?=3D=3Fus-ascii=3FQ=3F=3D3D=3D3Futf-8=3D3FB=3D3FR8O2cmFuIF?= =?us-ascii?Q?NlbGFuZGVy=3D3F=3D3D=3F=3D?= , Shahid Raza Subject: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:04:53 -0000 <#secure method=pgpmime mode=sign> reply set to list. Goran and co have produced a version/profile of EDHOC for use with the zero-touch join process. It is presently at: https://ericssonresearch.github.io/EALS/ [Annoyingly, not posted as draft-selander-ace-eals-00 yet.] I had previously written privately that in trying to merge 6tisch-minimal and zero-touch secure join that I am now considering a compromise where the zero-touch process would simply start with the 6tisch-minimal EDHOC transaction. This is described in draft-ietf-6tisch-dtsecurity-secure-join-01. In order for the pledge to be passive, and the JRC to manage the bulk (certificates and vouchers take a dozen fraglets, sadly), I would like the zero-touch process to be driven by the JRC. In draft-ietf-6tisch-dtsecurity-secure-join-00, I had suggested that the security protocol be initiated from the JRC. The JRC would become aware of the pledge through a combination of the pledge doing a DAD process, and the Join Proxy running a query to the JRC. In -00 that query was implemented in GRASP, but that could be replaced with some other query/response protocol, built upon CoAP if desired. This was described in https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#section-2.2.4 This was removed in -01: in -01 the "notification" of the JRC of the new pledge is when the pledge performs the EDHOC process which is common to zero-touch and one-touch. But, EALS suggests something slightly different again. Figure 5, reproduced below from: https://ericssonresearch.github.io/EALS/#rfc.section.3.2 EALS EALS client server | | | MESSAGE TO BE DETERMINED | +--------------------------------------->| | | | EDHOC message_1 | |<---------------------------------------+ | | | EDHOC message_2 | +--------------------------------------->| Third party | | < - - - - - - - - > | EDHOC message_3 (EXT_3 = Authz info) | authorization |<---------------------------------------+ | | EALS also proposes to move the voucher nonce and ownership voucher into the protocol itself, eliminating the provisional state, and ownership voucher. This moves the entire exchange control back to the JRC. No CoMI interface would be needed for communicating the voucher. EALS suggests that the enrollment occur over CoAP, driven by the pledge. The initial network key(s) can be returned by the EALS server just as in the 6tisch-minimal-security case, so the pledge will be full on the network when it performs certificate enrollment. It is much closer to https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Thu Mar 9 19:24:54 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE88912957F for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 19:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 A9No3PxgxSSz for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 19:24:51 -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 6DCCD129519 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 19:24:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8684320564 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 19:11:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A22B76381A for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 18:49:12 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: [6tisch-security] address to use for Join Proxy X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 03:24:53 -0000 --=-=-= Content-Type: text/plain One of the constraints about using the IPIP proxy method is that the Join Proxy has to advertise/coordinate the same IP address. That is, the JRC needs to have a LL address configured which the Join Proxy advertises as the target. This is so that the UDP/TCP state is correct. One possible way to deal with this is to use a well-known anycast LL address. It looks easy to ask IANA to allocate one. https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/bf3646fa7555dcb620fa8e9e153d9850ec5e75d6 +A pledge finds the layer-2 address of the Join Proxy by looking at the +EUI64 source address of enhanced beacons it has received that have the +Network ID extension, and have the Join Proxy bit set. +The Layer-3 address is the anycast address TBD1. + +The pledge need not do ND for the Join Proxy (which requires an expensive multicast), +but rather can form the layer-2 address directly from the EUI-64 that was seen. + +The pledge uses it's link-local address when speaking to the JRC via the Join Proxy. + https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/af518a119d81ef52d217088ad16d6c91183c3874 +This document allocates the address TBD1 from the +Internet Protocol Version 6 (IPv6) Anycast Addresses registry. + +https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljB6fUACgkQgItw+93Q 3WUz9wf/cLyL+v7dKSBvQO7cF9IlUWsXTU0iZINRxYhAgTLy/+3wlhmO+vpiBiwJ L6m47THN3ixmv7sra/ZbtWAd3py76WZW4cGYuLlCahA4t72cn+xudWEyAMq+JQCG M0cIciqgvRwgoMv0LGsRcQ08wgCt6UEEIcZ07+WVFuIrWQQxih1WYnJ+PvGjNw8/ DZjrITtB+LqOrOTNjO2ha8SrXAVqfkgSuMBZOaG8Nc0pjQWClfkja5U1KZb0loUj G64iyi6ZQMVAOLZDM1ScE8npupK8OtS3Q0d+565B/swYr03xqvZGe5/SZaO3XS69 QB6Z3YZRTZwoYa9cDTVjE1Xfc1hspw== =XCi3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 21:08:01 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FEB129469 for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 21:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0qrdVNmbD1c2 for <6tisch-security@ietfa.amsl.com>; Thu, 9 Mar 2017 21:07:57 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F25E1288B8 for <6tisch-security@ietf.org>; Thu, 9 Mar 2017 21:07:57 -0800 (PST) X-AuditID: c1b4fb3a-ea7ff7000000484c-7f-58c234a9c9e5 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id AD.6F.18508.9A432C85; Fri, 10 Mar 2017 06:07:56 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 06:07:53 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: EALS and how to go from 6tisch-minimal-security to zero-touch enrollment Thread-Index: AQHSmTY/aARWPGYP1kiGOVpVTtU2C6GNhhyA Date: Fri, 10 Mar 2017 05:07:52 +0000 Message-ID: References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> In-Reply-To: <14442.1489106136@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <173246F8ED0EEE4FB9694891BF800CA1@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7k+4ak0MRBk/uM1o0r1zEbrHz/GUm i6eNt5kdmD2WLPnJ5DHpxSEWj6VNm5kCmKO4bFJSczLLUov07RK4Mq7/1S/Yp14xe3YjWwPj HrUuRg4OCQETiReHs7oYuTiEBNYxSrzfP4MFwlnMKDHv+XPWLkZODjYBF4kHDY+YQGwRAUuJ 7av/sYHYzALpEm2L+8FqhAXCJe4+/MYKMlREIEJi0mFZiHIjiXMHrjOD2CwCqhKH990HK+cV sJBYe3g+E8SudkaJpfNOgCU4BYwlur4eYASxGQXEJL6fWsMEsUtc4taT+WC2hICAxJI955kh bFGJl4//gfWKCuhJLH++BiquJNG45AnYPcwCmhLrd+lDjLGW2DP5A9T5ihJTuh+yQ9wjKHFy 5hOWCYzis5Bsm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERh9 B7f8ttrBePC54yFGAQ5GJR7eD7kHI4RYE8uKK3MPMUpwMCuJ8JbqHYoQ4k1JrKxKLcqPLyrN SS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgXE9+/XarJ0ZNbVxIc+atV+znfti yZ3A5xWp7tccuq8ttsdGdF/0qfI70z8GtLT9rldbHPwqMF9Q6wxf7Y8z+3wiwhwchDyYPitN zl2w6u3GIzIsmq9nrWYrKNumNFEl/z+b7PFnq9j/3Z1xXLuPz6mM/b/D25tuKef2OGmxzPZJ Pn5ud7mprxJLcUaioRZzUXEiAMFlvJu6AgAA Archived-At: Cc: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , Shahid Raza Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 05:08:00 -0000 DQoNCk9uIDIwMTctMDMtMTAgMDE6MzUsICJNaWNoYWVsIFJpY2hhcmRzb24iIDxtY3IraWV0ZkBz YW5kZWxtYW4uY2E+IHdyb3RlOg0KDQo+DQo+PCNzZWN1cmUgbWV0aG9kPXBncG1pbWUgbW9kZT1z aWduPg0KPg0KPnJlcGx5IHNldCB0byBsaXN0Lg0KPg0KPkdvcmFuIGFuZCBjbyBoYXZlIHByb2R1 Y2VkIGEgdmVyc2lvbi9wcm9maWxlIG9mIEVESE9DIGZvciB1c2Ugd2l0aCB0aGUNCj56ZXJvLXRv dWNoIGpvaW4gcHJvY2Vzcy4gIEl0IGlzIHByZXNlbnRseSBhdDoNCj4gICAgICAgICAgIGh0dHBz Oi8vZXJpY3Nzb25yZXNlYXJjaC5naXRodWIuaW8vRUFMUy8NCj4gICAgW0Fubm95aW5nbHksIG5v dCBwb3N0ZWQgYXMgZHJhZnQtc2VsYW5kZXItYWNlLWVhbHMtMDAgeWV0Ll0NCg0KOi0pDQoNClNv IG5vdyB3ZSBhbGwga25vdyBvbmUgc291cmNlIG9mIE1pY2hhZWzigJlzIHJlY2VudCB0aHJlYWQg b24gaWV0Zi5vcmcuDQpUaGFua3MgZm9yIHByZXNlbnRpbmcgdGhlIGNvbnRlbnQgdG8gNnRpc2No IHNlY3VyaXR5LiBPbmUgY29tbWVudCBpbmxpbmUuDQoNCj4NCj5JIGhhZCBwcmV2aW91c2x5IHdy aXR0ZW4gcHJpdmF0ZWx5IHRoYXQgaW4gdHJ5aW5nIHRvIG1lcmdlIDZ0aXNjaC1taW5pbWFsDQo+ YW5kDQo+emVyby10b3VjaCBzZWN1cmUgam9pbiB0aGF0IEkgYW0gbm93IGNvbnNpZGVyaW5nIGEg Y29tcHJvbWlzZSB3aGVyZSB0aGUNCj56ZXJvLXRvdWNoIHByb2Nlc3Mgd291bGQgc2ltcGx5IHN0 YXJ0IHdpdGggdGhlIDZ0aXNjaC1taW5pbWFsIEVESE9DDQo+dHJhbnNhY3Rpb24uICBUaGlzIGlz IGRlc2NyaWJlZCBpbg0KPmRyYWZ0LWlldGYtNnRpc2NoLWR0c2VjdXJpdHktc2VjdXJlLWpvaW4t MDEuDQo+DQo+SW4gb3JkZXIgZm9yIHRoZSBwbGVkZ2UgdG8gYmUgcGFzc2l2ZSwgYW5kIHRoZSBK UkMgdG8gbWFuYWdlIHRoZSBidWxrDQo+KGNlcnRpZmljYXRlcyBhbmQgdm91Y2hlcnMgdGFrZSBh IGRvemVuIGZyYWdsZXRzLCBzYWRseSksIEkgd291bGQgbGlrZQ0KPnRoZSB6ZXJvLXRvdWNoIHBy b2Nlc3MgdG8gYmUgZHJpdmVuIGJ5IHRoZSBKUkMuDQo+DQo+SW4gZHJhZnQtaWV0Zi02dGlzY2gt ZHRzZWN1cml0eS1zZWN1cmUtam9pbi0wMCwgSSBoYWQgc3VnZ2VzdGVkIHRoYXQgdGhlDQo+c2Vj dXJpdHkgcHJvdG9jb2wgYmUgaW5pdGlhdGVkIGZyb20gdGhlIEpSQy4gVGhlIEpSQyB3b3VsZCBi ZWNvbWUgYXdhcmUgb2YNCj50aGUgcGxlZGdlIHRocm91Z2ggYSBjb21iaW5hdGlvbiBvZiB0aGUg cGxlZGdlIGRvaW5nIGEgREFEIHByb2Nlc3MsIGFuZA0KPnRoZSBKb2luIFByb3h5IHJ1bm5pbmcg YSBxdWVyeSB0byB0aGUgSlJDLiAgSW4gLTAwIHRoYXQgcXVlcnkgd2FzDQo+aW1wbGVtZW50ZWQg aW4gR1JBU1AsIGJ1dCB0aGF0IGNvdWxkIGJlIHJlcGxhY2VkIHdpdGggc29tZSBvdGhlcg0KPnF1 ZXJ5L3Jlc3BvbnNlIHByb3RvY29sLCBidWlsdCB1cG9uIENvQVAgaWYgZGVzaXJlZC4gIFRoaXMg d2FzIGRlc2NyaWJlZA0KPmluDQo+ICAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLTZ0aXNjaC1kdHNlY3VyaXR5LXNlY3VyZS1qb2luLTAwI3NlDQo+Y3Rpb24tMi4y LjQNCj4NCj5UaGlzIHdhcyByZW1vdmVkIGluIC0wMTogaW4gLTAxIHRoZSAibm90aWZpY2F0aW9u IiBvZiB0aGUgSlJDIG9mIHRoZSBuZXcNCj5wbGVkZ2UgaXMgd2hlbiB0aGUgcGxlZGdlIHBlcmZv cm1zIHRoZSBFREhPQyBwcm9jZXNzIHdoaWNoIGlzIGNvbW1vbiB0bw0KPnplcm8tdG91Y2ggYW5k IG9uZS10b3VjaC4NCj4NCj5CdXQsIEVBTFMgc3VnZ2VzdHMgc29tZXRoaW5nIHNsaWdodGx5IGRp ZmZlcmVudCBhZ2Fpbi4NCj4NCj5GaWd1cmUgNSwgcmVwcm9kdWNlZCBiZWxvdyBmcm9tOg0KPiAg ICAgICBodHRwczovL2VyaWNzc29ucmVzZWFyY2guZ2l0aHViLmlvL0VBTFMvI3JmYy5zZWN0aW9u LjMuMg0KPg0KPiBFQUxTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVBTFMN Cj5jbGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlcg0KPg0KPiAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICB8ICAgICAgTUVT U0FHRSBUTyBCRSBERVRFUk1JTkVEICAgICAgICAgIHwNCj4gICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQo+ICB8ICAgICAgICAgICAgIEVESE9DIG1lc3NhZ2VfMSAgICAgICAgICAg IHwNCj4gIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICB8ICAgICAgICAgICAg RURIT0MgbWVzc2FnZV8yICAgICAgICAgICAgIHwNCj4gICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0+fCAgICBUaGlyZCBwYXJ0eQ0KPiAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IDwgLSAtIC0gLSAtIC0gLSAtID4NCj4gIHwgIEVESE9D IG1lc3NhZ2VfMyAoRVhUXzMgPSBBdXRoeiBpbmZvKSAgfCAgICBhdXRob3JpemF0aW9uDQo+ICB8 PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPg0KPg0KPkVBTFMgYWxzbyBwcm9wb3Nl cyB0byBtb3ZlIHRoZSB2b3VjaGVyIG5vbmNlIGFuZCBvd25lcnNoaXAgdm91Y2hlciBpbnRvDQo+ dGhlDQo+cHJvdG9jb2wgaXRzZWxmLCBlbGltaW5hdGluZyB0aGUgcHJvdmlzaW9uYWwgc3RhdGUs IGFuZCBvd25lcnNoaXAgdm91Y2hlci4NCj4NCj5UaGlzIG1vdmVzIHRoZSBlbnRpcmUgZXhjaGFu Z2UgY29udHJvbCBiYWNrIHRvIHRoZSBKUkMuDQo+Tm8gQ29NSSBpbnRlcmZhY2Ugd291bGQgYmUg bmVlZGVkIGZvciBjb21tdW5pY2F0aW5nIHRoZSB2b3VjaGVyLg0KPg0KPkVBTFMgc3VnZ2VzdHMg dGhhdCB0aGUgZW5yb2xsbWVudCBvY2N1ciBvdmVyIENvQVAsIGRyaXZlbiBieSB0aGUgcGxlZGdl Lg0KDQpBY3R1YWxseSwgd2UgbWVudGlvbiB0aGF0IHRoZSBFREhPQyBwcm90b2NvbCBtYXkgYmUg cmV2ZXJzZWQsIGFuZCBpdCBtYXkNCmJlIGRyaXZlbiBieSB0aGUgSlJDLCBidXQgZmlyc3QgYXV0 aGVudGljYXRpbmcgdGhlIHBsZWRnZSBlbmFibGVzIHRoZQ0KYXV0aG9yaXphdGlvbiBzdGVwIHRv IGNvbWUgZWFybGllci4NCg0KR8O2cmFuDQoNCg0KPlRoZSBpbml0aWFsIG5ldHdvcmsga2V5KHMp IGNhbiBiZSByZXR1cm5lZCBieSB0aGUgRUFMUyBzZXJ2ZXIganVzdCBhcyBpbg0KPnRoZQ0KPjZ0 aXNjaC1taW5pbWFsLXNlY3VyaXR5IGNhc2UsIHNvIHRoZSBwbGVkZ2Ugd2lsbCBiZSBmdWxsIG9u IHRoZSBuZXR3b3JrDQo+d2hlbg0KPml0IHBlcmZvcm1zIGNlcnRpZmljYXRlIGVucm9sbG1lbnQu DQo+SXQgaXMgbXVjaCBjbG9zZXIgdG8NCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC12YW5kZXJzdG9rLWFjZS1jb2FwLWVzdC8NCj4NCj4NCj4NCj4tLQ0KPk1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdv cmtzDQo+IC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCj4NCj4NCj4NCg0K From nobody Fri Mar 10 02:36:41 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAE129431 for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 02:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=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 SQISsJYCQvUD for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 02:36:38 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D7B129871 for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 02:29:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.36,140,1486422000"; d="scan'208,217";a="216278885" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 11:28:59 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_D92F146C-C71D-4158-95AB-BD7FA7969DFF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <14442.1489106136@obiwan.sandelman.ca> Date: Fri, 10 Mar 2017 11:28:59 +0100 Message-Id: <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> To: 6tisch-security@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , Shahid Raza Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 10:36:39 -0000 --Apple-Mail=_D92F146C-C71D-4158-95AB-BD7FA7969DFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, Note that the bitbucket version of minimal-security now implements your = idea of JRC-initiated security handshake in case asymmetric keys are = used. The discovery of the pledge is triggered by a =E2=80=9CDiscovery = Message=E2=80=9D that maps to CoAP and is sent from the pledge to the = JRC. Upon reception of the Discovery Message, JRC can respond with an = optional ack and some time later with a prolonged response that = initiates the EDHOC handshake. It can also immediately respond with the = initiated EDHOC handshake. I think this is a fine compromise between all = the subtle versions that have been discussed so far. Let me know what do = you think. In case of PSKs, everything stays the same and we have a single join = request/join response exchange. Mali=C5=A1a > On 10 Mar 2017, at 01:35, Michael Richardson = wrote: >=20 > In draft-ietf-6tisch-dtsecurity-secure-join-00, I had suggested that = the > security protocol be initiated from the JRC. The JRC would become = aware of > the pledge through a combination of the pledge doing a DAD process, = and > the Join Proxy running a query to the JRC. In -00 that query was > implemented in GRASP, but that could be replaced with some other > query/response protocol, built upon CoAP if desired. This was = described > in > = https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-00#se= ction-2.2.4 = >=20 > This was removed in -01: in -01 the "notification" of the JRC of the = new > pledge is when the pledge performs the EDHOC process which is common = to > zero-touch and one-touch. >=20 > But, EALS suggests something slightly different again. >=20 > Figure 5, reproduced below from: > https://ericssonresearch.github.io/EALS/#rfc.section.3.2 = >=20 > EALS EALS > client server >=20 > | | > | MESSAGE TO BE DETERMINED | > +--------------------------------------->| > | | > | EDHOC message_1 | > |<---------------------------------------+ > | | > | EDHOC message_2 | > +--------------------------------------->| Third party > | | < - - - - - - - - > > | EDHOC message_3 (EXT_3 =3D Authz info) | authorization > |<---------------------------------------+ > | | >=20 --Apple-Mail=_D92F146C-C71D-4158-95AB-BD7FA7969DFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Michael,

Note that the bitbucket version of minimal-security now = implements your idea of JRC-initiated security handshake in case = asymmetric keys are used. The discovery of the pledge is triggered by a = =E2=80=9CDiscovery Message=E2=80=9D that maps to CoAP and is sent from = the pledge to the JRC. Upon reception of the Discovery Message, JRC can = respond with an optional ack and some time later with a prolonged = response that initiates the EDHOC handshake. It can also immediately = respond with the initiated EDHOC handshake. I think this is a fine = compromise between all the subtle versions that have been discussed so = far. Let me know what do you think.

In case of PSKs, everything stays the = same and we have a single join request/join response exchange.

Mali=C5=A1a

On 10 Mar 2017, at 01:35, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

In draft-ietf-6tisch-dtsecurity-secure-join-00, = I had suggested that the
security protocol be initiated from the = JRC. The JRC would become aware of
the pledge through a combination of the = pledge doing a DAD process, and
the Join Proxy running a query to the = JRC.  In -00 that query was
implemented in GRASP, but that could be = replaced with some other
query/response protocol, built upon CoAP = if desired.  This was described
in
   https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure= -join-00#section-2.2.4

This was removed in -01: in -01 the = "notification" of the JRC of the new
pledge is when the pledge performs the = EDHOC process which is common to
zero-touch and one-touch.

But, EALS suggests something slightly = different again.

Figure 5, = reproduced below from:
      https://ericssonresearch.github.io/EALS/#rfc.section.3.2
EALS =             &n= bsp;           &nbs= p;           EALS
client =             &n= bsp;           &nbs= p;         server

 | =             &n= bsp;           &nbs= p;            =   |
 |      MESSAGE TO = BE DETERMINED =          |
 +--------------------------------------->|
 | =             &n= bsp;           &nbs= p;            =   |
 | =             ED= HOC message_1 =            |=
 |<---------------------------------------+
 | =             &n= bsp;           &nbs= p;            =   |
 | =            EDHOC = message_2 =             |<= /span>
 +--------------------------------------->| =    Third party
 | =             &n= bsp;           &nbs= p;            =   | < - - - - - - - - >
 |  EDHOC message_3 (EXT_3 =3D = Authz info)  |    authorization
 |<---------------------------------------+
 | =             &n= bsp;           &nbs= p;            =   |


= --Apple-Mail=_D92F146C-C71D-4158-95AB-BD7FA7969DFF-- From nobody Fri Mar 10 04:11:17 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9321112950A for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 04:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 GCSGhlVtdmZi for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 04:11:13 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28031298A9 for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 04:11:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.36,140,1486422000"; d="scan'208";a="216292422" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 13:10:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <23046.1489099596@obiwan.sandelman.ca> Date: Fri, 10 Mar 2017 13:10:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3057E0C5-157D-441B-8E76-6DB1E6D024B1@inria.fr> References: <23046.1489099596@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] some proposed changes to 6tisch-minimal-security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 12:11:15 -0000 > On 09 Mar 2017, at 23:46, Michael Richardson = wrote: >=20 >=20 > This makes it clear how the pledge should process the EB: >=20 > = https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/78= b8e6455dc9500c7c0de43960f282ccb9529d24 >=20 > +A pledge which receives only Enhanced Beacons containing Network ID = extensions > +{{I-D.richardson-6tisch-join-enhanced-beacon}} with the initiate bit = cleared, SHOULD NOT > +proceed with this protocol on that network. The pledge SHOULD = consider that it > +is in a network which manages join traffic, it SHOULD switch to = {{I-D.ietf-6tisch-dtsecurity-secure-join}}. Sounds good. What happens in the case when the EB does not contain = Network ID extensions. Should we just default to minimal? > This makes it clearer that certificates do not necessarily mean that = it is a > zero-touch case: if they are locally relevant, then it's just a rejoin = after a long sleep. >=20 > = https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/e2= 83fd274ab2d4ee8e0d1a3467f27d4d1dc3963f >=20 > REQUIRED for RPKs and certificates. > + > +When using certificates, the process continues as described in = {{I-D.selander-ace-cose-ecdhe}}, > +but MAY result in no network key being returned. In that case, the = pledge enters a > +provisional situation where it provides access to an enrollment = mechanism described in > +{{I-D.ietf-6tisch-dtsecurity-secure-join}}. > + > +If using a locally relevant certificate, the pledge will be able to = validate the > +certificate of the JRC via a local trust anchor. In that case, the = JRC will > +return networks keys as in the PSK case. This would typically be the = case for > +a device which has slept so long that it no longer has valid network = keys and must go through > +a partial join process again. I am confused here. A node that sleeps so long that it no longer has = valid network keys can just repeat the Simple Join Protocol, i.e. the = join request/response exchange. It does not need to perform a new EDHOC = handshake because we can assume that the session key with JRC is still = valid, no?=20 > This makes it clearer that the mechanism is not limited to AES-CCM, = but that > negotiation could occur via EDHOC: >=20 > = https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/62= 7b2bff648ccb9ec47c59d0cd8d710d9b64742b >=20 > +The join request is typically authenticated/encrypted end-to-end = using AES-CCM-16-64-128 > +algorithm from {{I-D.ietf-cose-msg}} and a key derived from > the shared secret from step 3. > +This is described in detail in {{I-D.selander-ace-cose-ecdhe}}, which = also provides for algorithm agility. Good catch for crypto agility. Will you make a pull request with these = changes so that I can integrate them before publishing -02?=20 Mali=C5=A1a From nobody Fri Mar 10 07:33:14 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D123129639; Fri, 10 Mar 2017 07:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 R5qGmbuHMLVN; Fri, 10 Mar 2017 07:32: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 9D09E12964B; Fri, 10 Mar 2017 07:32:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 81EDCE207; Fri, 10 Mar 2017 10:55:43 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AA086381A; Fri, 10 Mar 2017 10:32:54 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" In-Reply-To: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" Subject: Re: [6tisch-security] [Anima-bootstrap] [Ace] EST over CoAP in ACE wg X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org, anima-bootstrap@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:33:01 -0000 --=-=-= Content-Type: text/plain {to reply to an old email with some valid questions, and some questions of my own. I am also clipping the reply-To} Panos Kampanakis (pkampana) wrote: > I am curious about your workflow in > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You > are envisioning for the JCE to initiate the bootstrapping to the > pledge, but wouldn't that better be defined in the > anima-bootstrapping-keyinfra doc? Constrained bootstrap is not really in scope for ANIMA. The general constrained bootstrap situation is too big, but 6tisch constrains the possible solution space, which is why we feel that we can make progress there. So, I want to accomodate constrained bootstrap in anima-bootstrap, but not define it. > About 'simple system that can be used with PSKs as authentication', I > was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth > with PSK/RPK/Cert? Anything more detail about these usecases? This is being proposed as 6tisch-minimal-security, and it uses OSCOAP and EDHOC. > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert > since the pledge did not generate it by himself. EST defines CMS for > this message. PKCS12 could suffice here as well with the challenge if > the passphrase provisioning being the problem. I'm not sure I understand this. Why do you say that the pledge did not generate it by himself? I"m assuming that it did so at manufacturing time, and that an IDevID certificate was bound to the public part of the key. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljCxyMACgkQgItw+93Q 3WXhWwf/UL6gJbmBQNTQWDcOpV94AhybwzKFHvwf16x6SpTkCZaankGezId9jSic sdjLlKoU1j2YTFW2Iyf/JkV1V5cxSrzXIZFdbFAgt5Zh5XapRO4JzRz3A4u09nwc yDwRAgncVutxQOM+7M0rI/5AiJ+UoqvP0tnaB7w9KAmy1o0JEskwl8zctq1RFw0S eglLq7tgbU096kmW/BMvDwK0bq0csq/nKoR+CjMGITGFr/8Dvsl1sAj8JoclfT9f 9n952+sqgoERhd76yK694LFCG+luYq3Y8crwVli/ldjHEK4zDV/M/PBBZpGhLAYL bvasuIKq1UHCRs44itQ9lX9l6NHjVQ== =QofY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 08:39:46 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A840129439 for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 08:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aSq1SNm1B2zW for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 08:39:43 -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 2A84D128B38 for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 08:39:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CC6EE20F; Fri, 10 Mar 2017 12:02:31 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C77BF6381A; Fri, 10 Mar 2017 11:39:41 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= In-Reply-To: <3057E0C5-157D-441B-8E76-6DB1E6D024B1@inria.fr> References: <23046.1489099596@obiwan.sandelman.ca> <3057E0C5-157D-441B-8E76-6DB1E6D024B1@inria.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] some proposed changes to 6tisch-minimal-security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:39:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: >> +A pledge which receives only Enhanced Beacons containing Network ID >> extensions +{{I-D.richardson-6tisch-join-enhanced-beacon}} with the >> initiate bit cleared, SHOULD NOT +proceed with this protocol on that >> network. The pledge SHOULD consider that it +is in a network which >> manages join traffic, it SHOULD switch to >> {{I-D.ietf-6tisch-dtsecurity-secure-join}}. > Sounds good. What happens in the case when the EB does not contain > Network ID extensions. Should we just default to minimal? If it doesn't have that ID, then there probably isn't a Join Proxy available on that network. As minimal-security does not have another way to find the Join Proxy, a pledge should ignore that EB. >> +{{I-D.ietf-6tisch-dtsecurity-secure-join}}. + +If using a locally >> relevant certificate, the pledge will be able to validate the >> +certificate of the JRC via a local trust anchor. In that case, the >> JRC will +return networks keys as in the PSK case. This would >> typically be the case for +a device which has slept so long that it = no >> longer has valid network keys and must go through +a partial join >> process again. > I am confused here. A node that sleeps so long that it no longer has > valid network keys can just repeat the Simple Join Protocol, i.e. the > join request/response exchange. It does not need to perform a new EDH= OC > handshake because we can assume that the session key with JRC is still > valid, no? It could try such a thing, yes, I agree. It might also have moved enough that it can no longer speak to the same JRC. The JRC might have restarted, etc. The point is that if you have locally verifiable certificates, then you can use them. I don't know how OSCOAP is going to securely signal when the secrets are no longer available. >> This makes it clearer that the mechanism is not limited to AES-CCM, >> but that negotiation could occur via EDHOC: >> >> https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/comm= its/627b2bff648ccb9ec47c59d0cd8d710d9b64742b >> >> +The join request is typically authenticated/encrypted end-to-end >> using AES-CCM-16-64-128 +algorithm from {{I-D.ietf-cose-msg}} and a >> key derived from the shared secret from step 3. +This is described = in >> detail in {{I-D.selander-ace-cose-ecdhe}}, which also provides for >> algorithm agility. > Good catch for crypto agility. Will you make a pull request with these > changes so that I can integrate them before publishing -02? done. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljC1s0ACgkQgItw+93Q 3WUdhAgAnpbDKb7F7IVgJRJCm4StW/+o+EkpNZe1nMyJHQ7fP1zw0WjbTKLhv5NQ 8IlxDOFMGSc55tKiQLXNr9U5lWHJHGWDX/vrRgaucYkBzqhe8UEBnEFyUQx75IG4 jT3kXjk2/tIYD1B0tMjOd1QbM0gCDdhoZLFrye9Vwxm0L5bVZLyTqBfM5E7q2dqL wgKe8Y68WwnU9qyfFFx5aYBJaPoIy5Ky3sqCfOTuwNdjCUvi+54OGMwvWYCubVfJ LIq/6RbW+ETHuYIgwTM8srcZpS/2ya2dUWOP2SNZ86owe8uhp+9jzQHxfx3SeH0/ uqFzzWGRJkd6sOqFC7MOLxTNObr9hg== =3ndn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 10:59:58 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687661296D7 for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 10:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zpetxzb4pB4k for <6tisch-security@ietfa.amsl.com>; Fri, 10 Mar 2017 10:59:55 -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 230081296CD for <6tisch-security@ietf.org>; Fri, 10 Mar 2017 10:59:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 118E8E22E; Fri, 10 Mar 2017 14:22:43 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 662B46381A; Fri, 10 Mar 2017 13:59:53 -0500 (EST) From: Michael Richardson To: "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= , =?us-ascii?Q?=3D=3Futf-8=3FB=3FR8O2cmFuIFNlbGFuZGVy=3F=3D?= , Shahid Raza Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 18:59:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable G=C3=B6ran Selander wrote: >> In order for the pledge to be passive, and the JRC to manage the bulk >> (certificates and vouchers take a dozen fraglets, sadly), I would li= ke >> the zero-touch process to be driven by the JRC. ... >> EALS also proposes to move the voucher nonce and ownership voucher >> into the protocol itself, eliminating the provisional state, and >> ownership voucher. >> >> This moves the entire exchange control back to the JRC. No CoMI >> interface would be needed for communicating the voucher. >> >> EALS suggests that the enrollment occur over CoAP, driven by the >> pledge. > Actually, we mention that the EDHOC protocol may be reversed, and it > may be driven by the JRC, but first authenticating the pledge enables > the authorization step to come earlier. Yes, EDHOC is reversed, and so the JRC can control when each pledge enrolls. The JRC would not initiate a message_1 until it is ready for that pledge to enroll. Once it has received message_2, the JRC will know securely exactly who is trying to connect, and if it still has concerns, or there just isn't network bandwidth yet, it could delay sending message_3 until it is ready. What we need to do is figure out is how the JRC inserted delays might affect retransmission timers. I think that the messages are all CoAP transactions initiated from the EDHOC initiator. Actually, that brings up a question: > +--------------------------------------->| Third party > | | < - - - - - - - - > > | EDHOC message_3 (EXT_3 =3D Authz info) | authorization > |<---------------------------------------+ how does the initatior know that message_3 arrived okay? I seem to be missing an ACK for this message. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljC96gACgkQgItw+93Q 3WWmYAgAn6Esmk3+kOTLpjOFoZw2gPNY1uh4SO1sY/jYNhHKEu3mR2nMdjh9d4g4 E5p6lTxfY2D5hT5F7coEyyK3qsc5uNEeFaE94EVn0/TFAEjIV1H4EIP9fWUdyr4i xrIi3lxqGdMYz8rwRXJ8QCsaGZaVr85gD39hGIBr4nY3wTub/XqA2tddcmhXaLYV CYDf9C5vsfrr+I3t66ILRxnj5etM6FYxMyWp2m0Q8Vfx/wskKJ9bCNp9NENrvIML sZtsP9beO23PUWZyMO35Il45u6MHRmVKQQUl0mdp8VA4IKCzRc2oSZ7JvMEHu7NJ TPOdnpm+Z6f4TJTVDIKQECXiQlKmYg== =fCkD -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 11 13:06:20 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207301294C3 for <6tisch-security@ietfa.amsl.com>; Sat, 11 Mar 2017 13:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 etGv9gMrD5zf for <6tisch-security@ietfa.amsl.com>; Sat, 11 Mar 2017 13:06:17 -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 180461295C4 for <6tisch-security@ietf.org>; Sat, 11 Mar 2017 13:06:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7DF2BE216; Sat, 11 Mar 2017 16:29:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0FA9F6381A; Sat, 11 Mar 2017 16:06:16 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= In-Reply-To: <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FG=3DC3=3DB6ran=5FSelander=3F=3D?= , Shahid Raza , 6tisch-security@ietf.org Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 21:06:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > Note that the bitbucket version of minimal-security now implements yo= ur > idea of JRC-initiated security handshake in case asymmetric keys are > used. The discovery of the pledge is triggered by a =E2=80=9CDiscover= y Message=E2=80=9D > that maps to CoAP and is sent from the pledge to the JRC. Upon I will read it now. I have rebased my other changes, and updated the pull request. Let's post! =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljEZsUACgkQgItw+93Q 3WW/uwgAnEuCi7bEqPSL/rNMEgFcEdmFY+2q4ziQDnMA2RB5wmvsl5uyp2khfn53 ssg0U0gz7YW7PlURtM6/BFT9vvUeSAxWDQ8MF7YavfhTNVmXZSTDfxqwN9Q53v5Z nbs90jmoXhp+vlPV9VyhF7Bb+gVoDeb3DiED2Uqc097+VOFNpODEXpamqBTedp52 sKs0r7Owik0Rc6OIujMYztfThwSp3RaJpy9wslbCUzxd8L49KJSfKZUuRvEN3rXi QOc9gpdvyB48fv0tajn5ldeVgq1fmBbiFug+mS3cKZIhQC3cukSNk7/Ao7wpEP8J 2kSrQo8xtks6V1h/GA6rLPhRbBmXFg== =2Lbt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 11 13:39:55 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF01295D8 for <6tisch-security@ietfa.amsl.com>; Sat, 11 Mar 2017 13:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 FrhIZcvHEik6 for <6tisch-security@ietfa.amsl.com>; Sat, 11 Mar 2017 13:39:53 -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 842341293E1 for <6tisch-security@ietf.org>; Sat, 11 Mar 2017 13:39:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8E67E20D; Sat, 11 Mar 2017 17:02:44 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2EAE06381A; Sat, 11 Mar 2017 16:39:51 -0500 (EST) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= In-Reply-To: <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Cc: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FG=3DC3=3DB6ran=5FSelander=3F=3D?= , Shahid Raza , 6tisch-security@ietf.org Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 21:39:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > Note that the bitbucket version of minimal-security now implements yo= ur > idea of JRC-initiated security handshake in case asymmetric keys are > used. The discovery of the pledge is triggered by a =E2=80=9CDiscover= y Message=E2=80=9D > that maps to CoAP and is sent from the pledge to the JRC. Upon I have read now: It's in section Security Handshake, right? Your description is too simple, and I don't think it makes any sense to put it here. I think it should simply refer to dtsecurity-secure-join. As for the Discovery Message, this seems reasonable. Is this process optional, or is it caused by the init bit in the EB being clear? It needs to have a mandatory reply so that the pledge knows that it has succeeded in reaching the JRC. A reply from the JRC might also need to indicate that the pledge should proceed to initiate? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljEbqQACgkQgItw+93Q 3WW4qggAr20cb10Oa0p6CD/vUjQmdRuAfBRHPl4KkClXGvbqy68Dpufmkq0/fDfW GxcXovekIIOz8hl9dhiEmbyAyg3PWP0sfUSeHZJ1EW6sHkEneQEjFUq5fb7+Aqln HcV9azvulI6+GXwryW3tHXHvZj9YzZdorBQTt2BKxT2OJccJwd5Ip1WR+ITm1pG4 ELHu9zof0tVHccTbItxr33KWkYkHZHVMzTO6wvz+lozGYWjDL7FZDBT4165vz62V xiAbNnsiJ0AtO1LdB8tVxqyEDhh0J219JkyKwvAfuqzwQaOzOnBzJksyBxSRgODb W7l0m5vw8yAXKhUQYGlC01IVd0O1mQ== =gsAh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 13 12:57:20 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE68129AE7 for <6tisch-security@ietfa.amsl.com>; Mon, 13 Mar 2017 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0ts3sEsvGW0j for <6tisch-security@ietfa.amsl.com>; Mon, 13 Mar 2017 12:57:05 -0700 (PDT) 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 6304E129406 for <6tisch-security@ietf.org>; Mon, 13 Mar 2017 12:57:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D9CD120548 for <6tisch-security@ietf.org>; Mon, 13 Mar 2017 16:20:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A493D6381A for <6tisch-security@ietf.org>; Mon, 13 Mar 2017 15:57:03 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Mar 2017 15:57:03 -0400 Message-ID: <15786.1489435023@obiwan.sandelman.ca> Archived-At: Subject: [6tisch-security] cancel meeting 2017-03-14 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 19:57:07 -0000 The NA time zone change means that there are conflicts, and some people ar= e unavailable, so cancelling the 6tisch-security meeting seems like the best= choice. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | network architec= t [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Mon Mar 20 06:13:42 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD5131475 for <6tisch-security@ietfa.amsl.com>; Mon, 20 Mar 2017 06:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 whK94z5B_HaJ for <6tisch-security@ietfa.amsl.com>; Mon, 20 Mar 2017 06:13:38 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67374126FDC for <6tisch-security@ietf.org>; Mon, 20 Mar 2017 06:13:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,194,1486422000"; d="scan'208,217";a="217367237" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2017 14:13:34 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C0CD106-B1F0-4F30-BA50-E1A081B7CEDF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <19411.1489268391@obiwan.sandelman.ca> Date: Mon, 20 Mar 2017 14:13:33 +0100 Cc: 6tisch Security <6tisch-security@ietf.org> Message-Id: <7E6CC32A-020E-4437-8972-1FD40991D198@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> <19411.1489268391@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 13:13:40 -0000 --Apple-Mail=_4C0CD106-B1F0-4F30-BA50-E1A081B7CEDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Mar 2017, at 22:39, Michael Richardson = wrote: >=20 > Your description is too simple, and I don't think it makes any sense = to put > it here. I think it should simply refer to dtsecurity-secure-join. I think that we definitely need to expand somewhere on the security = handshake in minimal-security document, it is a matter of preference = where the section should exactly go. The overview sections only show the = security handshake as a single transaction between JRC and the pledge. = I=E2=80=99ve put the expanded security handshake in the current place in = order to precede the simple join protocol section that similarly expands = on the join request/response exchange. What part do you find too simple? = The paragraph on special certificate being issued to JRC? If so, what = text do you propose to replace that? > As for the Discovery Message, this seems reasonable. > Is this process optional, or is it caused by the init bit in the EB = being > clear? To my understanding, init bit is there to differentiate between the = minimal-security and NS DAD dtsecurity-secure-join processes. Ideally, I = think it would be great if we could converge on the initiation process = between the two documents with the Discovery Message, therefore removing = the need for the init bit. In minimal-security, Discovery Message is = mandatory *when* performing the security handshake. The security = handshake, however, is optional and is performed in case the pledge was = provisioned with asymmetric keys. The decision what message to send = first, i.e. the Discovery Message or the Join Request, is internal to = the pledge and depends on the credential it has been provisioned with.=20= > It needs to have a mandatory reply so that the pledge knows that it = has > succeeded in reaching the JRC. =20 The reply to the Discovery Message is either an empty CoAP ACK signaling = to the pledge it has reached the JRC but needs to wait, or an immediate = response from JRC initiating the EDHOC handshake. Either way, pledge = knows it has succeeded in reaching JRC. Which response JRC opts for = could be dependent on how many pledges are currently enrolling. > A reply from the JRC might also need to > indicate that the pledge should proceed to initiate? I don=E2=80=99t understand, could you elaborate? --Apple-Mail=_4C0CD106-B1F0-4F30-BA50-E1A081B7CEDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Mar 2017, at 22:39, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Your description is too simple, and I don't = think it makes any sense to put
it here. I think it should simply refer = to dtsecurity-secure-join.

I think = that we definitely need to expand somewhere on the security handshake in = minimal-security document, it is a matter of preference where the = section should exactly go. The overview sections only show the security = handshake as a single transaction between JRC and the pledge. I=E2=80=99ve= put the expanded security handshake in the current place in order to = precede the simple join protocol section that similarly expands on the = join request/response exchange. What part do you find too simple? The = paragraph on special certificate being issued to JRC? If so, what text = do you propose to replace that?

As for the = Discovery Message, this seems reasonable.
Is this process optional, or is it caused = by the init bit in the EB being
clear?

To my = understanding, init bit is there to differentiate between the = minimal-security and NS DAD dtsecurity-secure-join processes. Ideally, I = think it would be great if we could converge on the initiation process = between the two documents with the Discovery Message, therefore removing = the need for the init bit. In minimal-security, Discovery Message is = mandatory *when* performing the security handshake. The security = handshake, however, is optional and is performed in case the pledge was = provisioned with asymmetric keys. The decision what message to send = first, i.e. the Discovery Message or the Join Request, is internal to = the pledge and depends on the credential it has been provisioned = with. 

It needs to have a mandatory reply so = that the pledge knows that it has
succeeded in reaching the JRC. =  

The reply = to the Discovery Message is either an empty CoAP ACK signaling to the = pledge it has reached the JRC but needs to wait, or an immediate = response from JRC initiating the EDHOC handshake. Either way, pledge = knows it has succeeded in reaching JRC. Which response JRC opts for = could be dependent on how many pledges are currently enrolling.

A reply from the JRC might also need = to
indicate that the pledge should proceed to = initiate?

I don=E2=80=99t = understand, could you elaborate?

= --Apple-Mail=_4C0CD106-B1F0-4F30-BA50-E1A081B7CEDF-- From nobody Mon Mar 20 14:26:59 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0085128BE1 for <6tisch-security@ietfa.amsl.com>; Mon, 20 Mar 2017 14:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l9PeCIsN80ve for <6tisch-security@ietfa.amsl.com>; Mon, 20 Mar 2017 14:26:56 -0700 (PDT) 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 07BE41293F8 for <6tisch-security@ietf.org>; Mon, 20 Mar 2017 14:26:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C5B5E033; Mon, 20 Mar 2017 17:50:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9B044636BB; Mon, 20 Mar 2017 17:26:54 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= cc: 6tisch Security <6tisch-security@ietf.org> In-Reply-To: <7E6CC32A-020E-4437-8972-1FD40991D198@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> <19411.1489268391@obiwan.sandelman.ca> <7E6CC32A-020E-4437-8972-1FD40991D198@inria.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 21:26:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: mcr> Your description is too simple, and I don't think it makes any mcr> sense to put it here. I think it should simply refer to mcr> dtsecurity-secure-join. > I think that we definitely need to expand somewhere on the security > handshake in minimal-security document, it is a matter of preference > where the section should exactly go. The overview sections only show > the security handshake as a single transaction between JRC and the > pledge. okay. > I=E2=80=99ve put the expanded security handshake in the current place > in order to precede the simple join protocol section that similarly > expands on the join request/response exchange. What part do you find > too simple? The paragraph on special certificate being issued to JRC? > If so, what text do you propose to replace that? Yes, that's the text: it is too vague to be useful, but expanding it in that document is wrong. mcr> As for the Discovery Message, this seems reasonable. Is this mcr> process optional, or is it caused by the init bit in the EB being mcr> clear? > To my understanding, init bit is there to differentiate between the > minimal-security and NS DAD dtsecurity-secure-join processes. Yes, but I think the distinction could be more subtle. There could be more possibilities resulting from hybridizing the two ideas. We have a number of different possibilities, and I don't think people have had a chance to fully consider the possibilities. I'm trying to capture this into slides for next week. > Ideally, > I think it would be great if we could converge on the initiation > process between the two documents with the Discovery Message, therefo= re > removing the need for the init bit. > In minimal-security, Discovery > Message is mandatory *when* performing the security handshake. The > security handshake, however, is optional and is performed in case the > pledge was provisioned with asymmetric keys. The decision what message > to send first, i.e. the Discovery Message or the Join Request, is > internal to the pledge and depends on the credential it has been > provisioned with. Agreed. > It needs to have a mandatory reply so that the pledge knows that = it > has succeeded in reaching the JRC. Agreed. > The reply to the Discovery Message is either an empty CoAP ACK > signaling to the pledge it has reached the JRC but needs to wait, or = an > immediate response from JRC initiating the EDHOC handshake. Either wa= y, > pledge knows it has succeeded in reaching JRC. Which response JRC opts > for could be dependent on how many pledges are currently enrolling. I had the same thought: if we always send message_1 of minimal-security, and we have some way to get an ACK that isn't message_2, but that tells the pledge that it can stop sending, then that accomplishes the goal of the init bit, and communicates the existence of the pledge to the JRC. I think that I said this in another email, but perhaps it was wrapped into the EALS discussion... mcr> A reply from the JRC might also need to indicate that the pled= ge mcr> should proceed to initiate? > I don=E2=80=99t understand, could you elaborate? I think you got it above :-) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljQSR4ACgkQgItw+93Q 3WVC4Af+Oo7JL5XUl1oVGCr1/XqVdvbMBEK519n8WH5zgt+PTGO3kl5FS33+vYjR NuQqbImMjOrosQoAS8XaQVYXU718iiCFH2feMYzJaw9Z5yTKbGs8KsU3JoiCftiJ Sdi0m1maF0nZJR5o4LrvVjsVHHrY9uTP5Db7JMnA3TITgqCe178IveklCDxuQA/d IhG8nd0VAmtBWXETSPvX3dOnGGtUQsXNP4DVmTzclmyDMykoo9mof799opguI+k6 ch3hVPYjywfT9myXuYOMfAAMlREgejXQHnlYNKpa2/Jv4woFgasD90F1ncS5SM3y jgH1B3iYcaujeo8c1TE8gLtuzM4EBg== =avkR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 21 06:41:20 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C0B1298BF for <6tisch-security@ietfa.amsl.com>; Tue, 21 Mar 2017 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 UAWhdKYVreIg for <6tisch-security@ietfa.amsl.com>; Tue, 21 Mar 2017 06:41:14 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B753E129873 for <6tisch-security@ietf.org>; Tue, 21 Mar 2017 06:41:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,198,1486422000"; d="scan'208,217";a="217519456" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2017 14:41:11 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5E1A9FB-58F2-442A-A9FA-D81A994CCA2D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <18795.1490045214@obiwan.sandelman.ca> Date: Tue, 21 Mar 2017 14:41:11 +0100 Cc: 6tisch Security <6tisch-security@ietf.org> Message-Id: <83C74693-26B4-47B6-B6F5-2186B3863A70@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> <19411.1489268391@obiwan.sandelman.ca> <7E6CC32A-020E-4437-8972-1FD40991D198@inria.fr> <18795.1490045214@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 13:41:16 -0000 --Apple-Mail=_D5E1A9FB-58F2-442A-A9FA-D81A994CCA2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Do you mean pledge-initiated message_1 (pledge being the party U)? What = you describe can be done with the same mechanism as currently done in = minimal-security and the Discovery Message =E2=80=94 empty CoAP ACK. One = issue there is that identity of U is not sent until message_3. We could = piggyback the identity of U in EXT_1 but that would break identity = protection of Sigma-I though. > On 20 Mar 2017, at 22:26, Michael Richardson = wrote: >=20 > I had the same thought: if we always send message_1 of = minimal-security, > and we have some way to get an ACK that isn't message_2, but that = tells the > pledge that it can stop sending, then that accomplishes the goal of = the init > bit, and communicates the existence of the pledge to the JRC. --Apple-Mail=_D5E1A9FB-58F2-442A-A9FA-D81A994CCA2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Do you mean pledge-initiated message_1 (pledge being the = party U)? What you describe can be done with the same mechanism as = currently done in minimal-security and the Discovery Message =E2=80=94 = empty CoAP ACK. One issue there is that identity of U is not sent until = message_3. We could piggyback the identity of U in EXT_1 but that would = break identity protection of Sigma-I though.

On = 20 Mar 2017, at 22:26, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I had the same thought: if we always send = message_1 of minimal-security,
and we have some way to get an ACK that = isn't message_2, but that tells the
pledge that it can stop sending, then = that accomplishes the goal of the init
bit, and communicates the existence of = the pledge to the JRC.

= --Apple-Mail=_D5E1A9FB-58F2-442A-A9FA-D81A994CCA2D-- From nobody Tue Mar 21 07:40:18 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05D012995F for <6tisch-security@ietfa.amsl.com>; Tue, 21 Mar 2017 07:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mV_OM9GVnwi3 for <6tisch-security@ietfa.amsl.com>; Tue, 21 Mar 2017 07:40:15 -0700 (PDT) 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 C2FEF12996E for <6tisch-security@ietf.org>; Tue, 21 Mar 2017 07:40:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EE1020183; Tue, 21 Mar 2017 11:03:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6B575636BB; Tue, 21 Mar 2017 10:40:05 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= cc: 6tisch Security <6tisch-security@ietf.org> In-Reply-To: <83C74693-26B4-47B6-B6F5-2186B3863A70@inria.fr> References: <7579.1488907684@obiwan.sandelman.ca> <14442.1489106136@obiwan.sandelman.ca> <07EC7DD8-F0B2-4CFB-A402-1CBB50729CE1@inria.fr> <19411.1489268391@obiwan.sandelman.ca> <7E6CC32A-020E-4437-8972-1FD40991D198@inria.fr> <18795.1490045214@obiwan.sandelman.ca> <83C74693-26B4-47B6-B6F5-2186B3863A70@inria.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 14:40:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mali=C5=A1a Vu=C4=8Dini=C4=87 wrote: > Do you mean pledge-initiated message_1 (pledge being the party U)? > What you describe can be done with the same mechanism as currently do= ne > in minimal-security and the Discovery Message =E2=80=94 empty CoAP AC= K. Yes, I was thinking of this exactly. I was thinking that CoAP ACK, with a unique code. > One > issue there is that identity of U is not sent until message_3. We cou= ld > piggyback the identity of U in EXT_1 but that would break identity > protection of Sigma-I though. Yes, I was also thinking that this is a concern. The identity could be subtly masked in a variety of ways. If we do this, then we combine the notification by pledge with the first message, and eliminate the need for the "init" bit. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljRO0UACgkQgItw+93Q 3WVgVggAi1b3eCfntlJMx382RCVoDI1XXXkkAvgp2DblnWyW1qnsxxC3nWJ6HAsu I7WnosWynMfBONmjpi6KgRm16vR6pZUIQcoIKZyPgthoTi3ExB0RLBfC06Iib3+b mZTmgnltxoiaItIX37Qp1uKUo7AMjTaS+vYjtUp5ioJA6IfuoWCPTWcS79qJzlKo YM3fYEOiKNVx68VRRvtfK8dXiSDqQKhyfiLLN+0P5CFaREb3dT7ab4ER72U3F80K kcN7lz7uSdn+LCiwxJobvqkRPaFokEVRJZqPsV0W0fH3n6mEzXnJE1thZtdK3Kfe DopEhKtmRmQQWPEXcuqPvY6sDGQLbQ== =IPuL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 28 08:16:34 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F93128B88; Tue, 28 Mar 2017 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 xbchvcsHQueb; Tue, 28 Mar 2017 08:16:31 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8071D1289C3; Tue, 28 Mar 2017 08:16:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,236,1486422000"; d="scan'208,217";a="266587654" Received: from mail-vk0-f45.google.com ([209.85.213.45]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Mar 2017 17:16:28 +0200 Received: by mail-vk0-f45.google.com with SMTP id r69so91824403vke.2; Tue, 28 Mar 2017 08:16:28 -0700 (PDT) X-Gm-Message-State: AFeK/H2UEZLQMhVbQsoJc+AMUYUj7XGzC2hv5oo3v6hVn9mh7FVly7koBNv8MuPAwZV6n02F+EdccoBabodAOw== X-Received: by 10.31.73.6 with SMTP id w6mr6369016vka.137.1490714187087; Tue, 28 Mar 2017 08:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.194.149 with HTTP; Tue, 28 Mar 2017 08:16:06 -0700 (PDT) From: Thomas Watteyne Date: Tue, 28 Mar 2017 17:16:06 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=001a114db10a954ac8054bcbf154 Archived-At: Subject: [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 15:16:33 -0000 --001a114db10a954ac8054bcbf154 Content-Type: text/plain; charset=UTF-8 Michael, We just discussed IP-IP-IP versus CoAP at the 6TiSCH WG meeting. I stated that: - with IP-IP-IP, all nodes in the network would need to know at least the global and link-local IPv6 addresses of the JRC, as well as the IPv6 address of the LBR. - With the CoAP proxy option, we could use (well-known?) 6LoWPAN contexts and hostnames to avoid that. You stated that my statement 1 was not correct. Could we draw up an example with all the addresses in the IP-IP-IP case, and what exactly the Pledge and Join Proxy need to know before being able to join? Thanks, Thomas --001a114db10a954ac8054bcbf154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,

We just discussed IP-IP-IP ver= sus CoAP at the 6TiSCH WG meeting.

I stated that:<= /div>
- with IP-IP-IP, all nodes in the network would need to know at l= east the global and link-local IPv6 addresses of the JRC, as well as the IP= v6 address of the LBR.
- With the CoAP proxy option, we could use= (well-known?) 6LoWPAN contexts and hostnames to avoid that.

=
You stated that my statement 1 was not correct. Could we draw up= an example with all the addresses in the IP-IP-IP case, and what exactly t= he Pledge and Join Proxy need to know before being able to join?
=
Thanks,
Thomas
--001a114db10a954ac8054bcbf154-- From nobody Tue Mar 28 09:15:53 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935712953A; Tue, 28 Mar 2017 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 YXbcaOw8BvDx; Tue, 28 Mar 2017 09:15:49 -0700 (PDT) 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 D010712965B; Tue, 28 Mar 2017 09:15:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E7860200A3; Tue, 28 Mar 2017 12:39:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 611D2636E0; Tue, 28 Mar 2017 12:15:42 -0400 (EDT) From: Michael Richardson reply-To: "6tisch\@ietf.org" <6tisch@ietf.org> To: "6tisch\@ietf.org" <6tisch@ietf.org>, "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 16:15:51 -0000 --=-=-= Content-Type: text/plain Thomas Watteyne wrote: > - with IP-IP-IP, all nodes in the network would need to know at least > the global and link-local IPv6 addresses of the JRC, as well as the > IPv6 address of the LBR. You write "all-nodes", but can we agree that it's only the Join Proxy? The Join Proxy needs to know an address to which to forward the join traffic, regardless of whether or not it is IPIP(IP) or CoAP. I don't see how it matters what which. The JP has to know that address. That address could be an IPv6 anycast address; it could be provisioned via some other mechanism. In the IPIP case, the pledge should ideally send to an address which the JRC recognizes are local. Any IPv6 LL-anycast address would work well for this. That can also be done in the CoAP proxy method as well. > - With the CoAP proxy option, we could use (well-known?) 6LoWPAN > contexts and hostnames to avoid that. I agree that using a 6lo context would be a good idea here. It seems that it can also be used with either method. I will write some examples today and post. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljajC4ACgkQgItw+93Q 3WVw3Af/WsM4ocOPktjV2PaAV2KePotBmzIizKSJkqF+4L5xxzGx31cwt3IqTEmx wTsaiI6KuaFeFIRTXmJeZJSbXViCGL6ehz3GUOUx1eBfDPen0spS86F8l6YuNE7H 5Mzr2DvE2wN+TaowzDL4LFDxXawI5S9p081QAmxxlbBcSORHWXu74Dzp2TNd2nad RqrUGI/uh3cpBLApLZqx0zybtprkvpYxJ9RikCyYUdM8KRY8Gf6B1YnI5XWvLoUq xxxUluoVftm4yEOT0hRHs/nAoOGqZZiEyVlK+jsZ1aYIZpMOdO3lxYvJB32BSXcr shN3jDa+/JiEK+4q0/8jr6rym5UTqQ== =EioJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 15:02:27 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C60126C23 for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 15:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZrtG3Ual1Z7o for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 15:02:24 -0700 (PDT) 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 8A885129622 for <6tisch-security@ietf.org>; Wed, 29 Mar 2017 15:02:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A2561203B0 for <6tisch-security@ietf.org>; Wed, 29 Mar 2017 18:26:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C58FA636E0 for <6tisch-security@ietf.org>; Wed, 29 Mar 2017 18:02:23 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: [6tisch-security] [Ace] HKDF useage in ace-cose-ecdhe-05 (fwd) Dan Harkins: [Ace] HKDF useage in ace-cose-ecdhe-05 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 22:02:26 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain At least, for the archival and consideration of anyone who wasn't in ACE. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=66 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Wed, 29 Mar 2017 17:56:44 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Wed, 29 Mar 2017 18:19:23 -0400 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id 618DA203B0 for ; Wed, 29 Mar 2017 18:19:23 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2TLtQqI003657 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Mar 2017 17:55:27 -0400 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF1126DDF; Wed, 29 Mar 2017 14:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1490824526; bh=upSENdPpAMYbYyIxmafEm/jgGr9wjoIi93owg55WXuc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=M2MY0p7Rp3leasQZkmhWDCWbbv2Yab7INiqFgMsGX84nPJQOQ5eMfJfyy5m/cmkwk Vrt8DQsNE1QNBQA/jIpQGcX969WhGAASw9KE42SCmDNtDiWJCJtAgWl04L5hPO1i2N SvyZi/mEDsloEzi2aH+UheMdoItDOfXteBbBV9TM= X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A540E12960D for ; Wed, 29 Mar 2017 14:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: 0.00 () [Hold at 5.10] HEADER_FROM_DIFFERENT_DOMAINS:0.001,SPF(pass:0),DKIM(pass:0) X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IkIYGCQTB0ch for ; Wed, 29 Mar 2017 14:55:23 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA20126DDF for ; Wed, 29 Mar 2017 14:55:23 -0700 (PDT) Received: from dhcp-8f5c.meeting.ietf.org (dhcp-8f5c.meeting.ietf.org [31.133.143.92]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 16CB61E011A for ; Wed, 29 Mar 2017 14:55:23 -0700 (PDT) To: ace@ietf.org From: Dan Harkins Message-ID: <9a28d26f-9069-7306-405d-eb7d945c03f0@lounge.org> Date: Wed, 29 Mar 2017 14:55:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Archived-At: Subject: [Ace] HKDF useage in ace-cose-ecdhe-05 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ace-bounces@ietf.org Sender: "Ace" X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-CanIt-Geo: ip=4.31.198.44; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gT1VTqwH - af7340d259fc - 20170329 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?c=f&i=0gT1VTqwH&m=af7340d259fc&rlm=sandelman-ca&t=20170329 X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?c=n&i=0gT1VTqwH&m=af7340d259fc&rlm=sandelman-ca&t=20170329 X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?c=p&i=0gT1VTqwH&m=af7340d259fc&rlm=sandelman-ca&t=20170329 X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?c=s&i=0gT1VTqwH&m=af7340d259fc&rlm=sandelman-ca&t=20170329 X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: pass (colo19.roaringpenguin.com: domain of ace-bounces@ietf.org designates 4.31.198.44 as permitted sender) receiver=colo19.roaringpenguin.com; client-ip=4.31.198.44; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) Hello, I want to expand on my comments I made at the mic on Monday regarding key derivation with symmetric key authentication in draft-selander-ace- cose-ecdhe-05. When doing authentication with symmetric keys message 1 is encrypted using K_1 and K_1 is generated by passing (as far as I can tell, and I did admit at the mic that it's a little fuzzy) the PSK as salt and an empty key to HKDF. This poses some problems I think. - The only source of entropy in K_1 is the PSK and this makes the protocol susceptible to a passive dictionary attack[1] that would, otherwise, not be possible. - It seems somewhat unhygienic, from a crypto point of view, to pass a NULL key to a key derivation function. - Use of the PSK in messages 2 and 3 authenticate the particular key used in the AEAD and decryption/verification provides authentication of the sender to the receiver. But for message 1 is different. There is no benefit to the key exchange provided by encryption of message 1. The sole benefit of encrypting in message 1 seems to be that EXT_1 gets encrypted. But EXT_1 in the asymmetric case is not encrypted so there doesn't really seem there can be much that needs protection; seems like this is more of an opportunistic thing. That being the case, there is little upside and considerable downside to generating K_1 and encrypting a portion of message 1. I recommend that being removed from the draft. regards, Dan. [1] a dictionary attack is defined as one where the attacker gains an advantage from computation as opposed to interaction. The size of the dictionary (e.g. all numbers between 0 and 2^256) only affects the probability of success of the attack not whether it is a dictionary attack or not. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcLu8ACgkQgItw+93Q 3WWG5Qf/ZLDPzFCtM02kub/OY/hTSaWuurBMtXJdGh1dM6P/t4p8dd/QtSiNOhjZ flooSNWG78fue96fCAI/ycuJjPw3J6DLZ6UqT8GmiAahfZ4YZLQbDMuaH7OpKq5f GKWYL8Q5giuj5UXMHlby3DuLgRd6irKk1otEa1qOvlX/oTc4YOHX/BFKPaUsrMX9 ds6H6q5AA9N9WyOrUgOthma3111wTkZG2J0D2/Pwoyi7FXOO3hru2iDAWv0hchk6 OQDKbWqSEIrHNUBT3uVj+57A3zvJib4Mzs/HR32HEtOiJE7g+C6w11L29/bTg0nG JKjJproDHcB7iDKhmHH1LIphJ0y7WA== =t11i -----END PGP SIGNATURE----- --==-=-=-- From nobody Wed Mar 29 23:41:09 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CF5128768 for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 23:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 As6bscseG2Ty for <6tisch-security@ietfa.amsl.com>; Wed, 29 Mar 2017 23:41:05 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437751293E1 for <6tisch-security@ietf.org>; Wed, 29 Mar 2017 23:41:05 -0700 (PDT) X-AuditID: c1b4fb30-7db199800000628e-87-58dca87f0015 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id EC.1F.25230.F78ACD85; Thu, 30 Mar 2017 08:41:03 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 08:41:01 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: 6tisch-security <6tisch-security@ietf.org>, Michael Richardson CC: John Mattsson , Francesca Palombini , Jim Schaad Thread-Topic: [Ace] HKDF useage in ace-cose-ecdhe-05 Thread-Index: AQHSqNcu88JAA4nRTU2MR4Jb7lLaT6Gsd1MAgAAC0wA= Date: Thu, 30 Mar 2017 06:41:01 +0000 Message-ID: References: <9a28d26f-9069-7306-405d-eb7d945c03f0@lounge.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <7A9E865D0441F64BB7F1B6E9FA0B1DEA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7pW79ijsRBtv+iVs0r1zEbrF6+nc2 i55D/ewOzB4b50xn81iy5CeTR8ucPcwBzFFcNimpOZllqUX6dglcGa+/z2AteKVRMffPItYG xifqXYycHBICJhJ7tn1nBLGFBNYzSlz4EdLFyAVkL2GU+Pn+FhtIgk3AReJBwyMmEFtEIEai 8WwDC0gRs0Avo0TP6j9gCWEBY4lNi1+yQhSZSNxf/owRwraSuP/9PHMXIwcHi4CqxKOdgSBh XgELiYtfdkAtzpHY+24XI0gJp4ClRNuxSJAwo4CYxPdTa8CmMwuIS9x6Mp8J4mYBiSV7QCaC 2KISLx//A9sqKqAnsfz5Gqi4ksSi25+ZQEYyC2hKrN+lDzHGWmLLxudsELaixJTuh+wQ1whK nJz5hGUCo/gsJNtmIXTPQtI9C0n3LCTdCxhZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIE Rt/BLb8NdjC+fO54iFGAg1GJh/fB3tsRQqyJZcWVuYcYJTiYlUR47RbfiRDiTUmsrEotyo8v Ks1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qB0eWWfXVZ0l716vuf57w5qL7M MbXzgGQNt7DePvXPJXE+L/5POBERbueY19cnPOlYzLyHibM8IyNPXFvI2Jwd9nPu31eC96UV E551LI+1XC5uO/3EpCLjo4aRSh7iPJaWa09n53x7aN/ywOSwlMccq3v3tO+zTDrulb1ELE87 d+2hhRVT618zKbEUZyQaajEXFScCAIoa6Ye6AgAA Archived-At: Subject: [6tisch-security] FW: [Ace] HKDF useage in ace-cose-ecdhe-05 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 06:41:08 -0000 SGkgTWljaGFlbCwgDQoNClRoYW5rcyBmb3IgZm9yd2FyZGluZywgcGxlYXNlIHNlZSBteSBhbnN3 ZXIgaW4gdGhlIGVtYWlsIGluY2x1ZGVkIGJlbG93Lg0KDQpIZXJl4oCZcyBhIHF1ZXN0aW9uIGZv ciA2dGlzY2gtc2VjdXJpdHk6DQoNCi0gRG8geW91IHNlZSBhbnkgdmFsdWUgaW4gZW5jcnlwdGlu ZyBFREhPQyBtZXNzYWdlXzEgaW4gdGhlIHN5bW1ldHJpYw0KKFBTSykgY2FzZT8gVGhhdCB3b3Vs ZCBhbGxvdyB0aGUgYXBwbGljYXRpb24gdG8gcGFzcyBlbmNyeXB0ZWQgYW5kDQppbnRlZ3JpdHkg cHJvdGVjdGVkIGluZm9ybWF0aW9uIGluIHRoZSBleHRlbnNpb24gZmllbGQgKEVYVF8xKSBhbHJl YWR5IGluDQp0aGUgZmlyc3QgbWVzc2FnZS4NCg0KKEZvciB0aGUgYXN5bW1ldHJpYyB2ZXJzaW9u IHRoaXMgaXMgbm90IHBvc3NpYmxlLCBzaW5jZSB0aGVyZSBpcyBubyBzaGFyZWQNCmtleSBhdCB0 aGUgdGltZSBvZiBzZW5kaW5nIG1lc3NhZ2VfMSkNCg0KR8O2cmFuDQoNCg0KT24gMjAxNy0wMy0z MCAwODozMCwgIkFjZSBvbiBiZWhhbGYgb2YgR8O2cmFuIFNlbGFuZGVyIg0KPGFjZS1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KDQo+SGVsbG8gRGFuLA0KPg0KPlRoYW5rcyBmb3IgY29tbWVudGluZy4NCj4NCj5UaGUgZW5j cnlwdGlvbiBvZiBLXzEgaW4gdGhlIHN5bW1ldHJpYyBjYXNlIGlzIGFuIG9wZW4gaXNzdWUsIHdl IHNob3VsZA0KPmhhdmUgbWVudGlvbmVkIHRoYXQgaW4gdGhlIG1lZXRpbmcuIEppbSBTY2hhYWQg aGFzIGFsc28gcHJvdmlkZWQgYXJndW1lbnRzDQo+dG8gcmVtb3ZlIGl0Lg0KPg0KPllvdXIgZXhw cmVzc2lvbiDigJxvcHBvcnR1bmlzdGlj4oCdIGlzIGEgZ29vZCBjaGFyYWN0ZXJpc2F0aW9uLiBX ZSBpbmNsdWRlZA0KPmVuY3J5cHRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIG9mIG1lc3Nh Z2VfMSBpbiB0aGUgc3ltbWV0cmljIHZlcnNpb24NCj5tYWlubHkgYmVjYXVzZSB3ZSBjYW4sIGlu IGNvbnRyYXN0IHRvIGluIHRoZSBhc3ltbWV0cmljIHZlcnNpb24uIEJ1dCBhcw0KPnlvdSBwb2lu dCBvdXQsIGlmIHdlIGtlZXAgZW5jcnlwdGlvbiBvZiBtZXNzYWdlXzEgdGhlbiB3ZSBzaG91bGQg ZGVyaXZlDQo+S18xIGluIGEgZGlmZmVyZW50IHdheSwgYW5kIHRoZW4gdGhlIGtleSBkZXJpdmF0 aW9uIGluIHRoZSBhc3ltbWV0cmljIGFuZA0KPnN5bW1ldHJpYyB2ZXJzaW9ucyBvZiB0aGUgcHJv dG9jb2wgd291bGQgcHJvYmFibHkgbm90IGJlIHRoZSBzYW1lLCB3aGljaA0KPndhcyBhbm90aGVy IGRlc2lnbiBvYmplY3RpdmUuDQo+DQo+SSBoYXZlbuKAmXQgdGFsa2VkIHdpdGggbXkgY28tYXV0 aG9ycyB5ZXQsIGJ1dCB3ZSB3aWxsIGVpdGhlciBvbWl0DQo+ZW5jcnlwdGlvbiBvZiBtZXNzYWdl XzEgaW4gdGhlIHN5bW1ldHJpYyBjYXNlIG9yIGNoYW5nZSB0aGUgZGVyaXZhdGlvbiBvZg0KPktf MS4NCj4NCj5SZWdhcmRzLA0KPkfDtnJhbg0KPg0KPg0KPk9uIDIwMTctMDMtMjkgMjM6NTUsICJB Y2Ugb24gYmVoYWxmIG9mIERhbiBIYXJraW5zIiA8YWNlLWJvdW5jZXNAaWV0Zi5vcmcNCj5vbiBi ZWhhbGYgb2YgZGhhcmtpbnNAbG91bmdlLm9yZz4gd3JvdGU6DQo+DQo+Pg0KPj4gICBIZWxsbywN Cj4+DQo+PiAgIEkgd2FudCB0byBleHBhbmQgb24gbXkgY29tbWVudHMgSSBtYWRlIGF0IHRoZSBt aWMgb24gTW9uZGF5IHJlZ2FyZGluZw0KPj5rZXkgZGVyaXZhdGlvbiB3aXRoIHN5bW1ldHJpYyBr ZXkgYXV0aGVudGljYXRpb24gaW4gZHJhZnQtc2VsYW5kZXItYWNlLQ0KPj5jb3NlLWVjZGhlLTA1 LiBXaGVuIGRvaW5nIGF1dGhlbnRpY2F0aW9uIHdpdGggc3ltbWV0cmljIGtleXMgbWVzc2FnZSAx IGlzDQo+PmVuY3J5cHRlZCB1c2luZyBLXzEgYW5kIEtfMSBpcyBnZW5lcmF0ZWQgYnkgcGFzc2lu ZyAoYXMgZmFyIGFzIEkgY2FuDQo+PnRlbGwsDQo+PmFuZCBJIGRpZCBhZG1pdCBhdCB0aGUgbWlj IHRoYXQgaXQncyBhIGxpdHRsZSBmdXp6eSkgdGhlIFBTSyBhcyBzYWx0IGFuZA0KPj5hbiBlbXB0 eSBrZXkgdG8gSEtERi4gVGhpcyBwb3NlcyBzb21lIHByb2JsZW1zIEkgdGhpbmsuDQo+Pg0KPj4g ICAtIFRoZSBvbmx5IHNvdXJjZSBvZiBlbnRyb3B5IGluIEtfMSBpcyB0aGUgUFNLIGFuZCB0aGlz IG1ha2VzIHRoZQ0KPj5wcm90b2NvbA0KPj4gICAgIHN1c2NlcHRpYmxlIHRvIGEgcGFzc2l2ZSBk aWN0aW9uYXJ5IGF0dGFja1sxXSB0aGF0IHdvdWxkLA0KPj5vdGhlcndpc2UsIG5vdA0KPj4gICAg IGJlIHBvc3NpYmxlLg0KPj4NCj4+ICAgLSBJdCBzZWVtcyBzb21ld2hhdCB1bmh5Z2llbmljLCBm cm9tIGEgY3J5cHRvIHBvaW50IG9mIHZpZXcsIHRvIHBhc3MNCj4+ICAgICBhIE5VTEwga2V5IHRv IGEga2V5IGRlcml2YXRpb24gZnVuY3Rpb24uDQo+Pg0KPj4gICAtIFVzZSBvZiB0aGUgUFNLIGlu IG1lc3NhZ2VzIDIgYW5kIDMgYXV0aGVudGljYXRlIHRoZSBwYXJ0aWN1bGFyIGtleQ0KPj4gICAg IHVzZWQgaW4gdGhlIEFFQUQgYW5kIGRlY3J5cHRpb24vdmVyaWZpY2F0aW9uIHByb3ZpZGVzIGF1 dGhlbnRpY2F0aW9uDQo+Pm9mDQo+PiAgICAgdGhlIHNlbmRlciB0byB0aGUgcmVjZWl2ZXIuIEJ1 dCBmb3IgbWVzc2FnZSAxIGlzIGRpZmZlcmVudC4gVGhlcmUgaXMNCj4+ICAgICBubyBiZW5lZml0 IHRvIHRoZSBrZXkgZXhjaGFuZ2UgcHJvdmlkZWQgYnkgZW5jcnlwdGlvbiBvZiBtZXNzYWdlIDEu DQo+Pg0KPj4gICBUaGUgc29sZSBiZW5lZml0IG9mIGVuY3J5cHRpbmcgaW4gbWVzc2FnZSAxIHNl ZW1zIHRvIGJlIHRoYXQgRVhUXzENCj4+Z2V0cw0KPj5lbmNyeXB0ZWQuIEJ1dCBFWFRfMSBpbiB0 aGUgYXN5bW1ldHJpYyBjYXNlIGlzIG5vdCBlbmNyeXB0ZWQgc28gdGhlcmUNCj4+ZG9lc24ndCBy ZWFsbHkgc2VlbSB0aGVyZSBjYW4gYmUgbXVjaCB0aGF0IG5lZWRzIHByb3RlY3Rpb247IHNlZW1z IGxpa2UNCj4+dGhpcyBpcyBtb3JlIG9mIGFuIG9wcG9ydHVuaXN0aWMgdGhpbmcuIFRoYXQgYmVp bmcgdGhlIGNhc2UsIHRoZXJlIGlzDQo+PmxpdHRsZSB1cHNpZGUgYW5kIGNvbnNpZGVyYWJsZSBk b3duc2lkZSB0byBnZW5lcmF0aW5nIEtfMSBhbmQgZW5jcnlwdGluZw0KPj5hIHBvcnRpb24gb2Yg bWVzc2FnZSAxLiBJIHJlY29tbWVuZCB0aGF0IGJlaW5nIHJlbW92ZWQgZnJvbSB0aGUgZHJhZnQu DQo+Pg0KPj4gICByZWdhcmRzLA0KPj4NCj4+ICAgRGFuLg0KPj4NCj4+WzFdIGEgZGljdGlvbmFy eSBhdHRhY2sgaXMgZGVmaW5lZCBhcyBvbmUgd2hlcmUgdGhlIGF0dGFja2VyIGdhaW5zIGFuDQo+ PmFkdmFudGFnZSBmcm9tIGNvbXB1dGF0aW9uIGFzIG9wcG9zZWQgdG8gaW50ZXJhY3Rpb24uIFRo ZSBzaXplIG9mIHRoZQ0KPj5kaWN0aW9uYXJ5IChlLmcuIGFsbCBudW1iZXJzIGJldHdlZW4gMCBh bmQgMl4yNTYpIG9ubHkgYWZmZWN0cyB0aGUNCj4+cHJvYmFiaWxpdHkgb2Ygc3VjY2VzcyBvZiB0 aGUgYXR0YWNrIG5vdCB3aGV0aGVyIGl0IGlzIGEgZGljdGlvbmFyeQ0KPj5hdHRhY2sgb3Igbm90 Lg0KPj4NCj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+QWNlIG1haWxpbmcgbGlzdA0KPj5BY2VAaWV0Zi5vcmcNCj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFjZSBtYWlsaW5nIGxpc3QNCj5BY2VA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= From nobody Thu Mar 30 11:44:11 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C08C1296BB for <6tisch-security@ietfa.amsl.com>; Thu, 30 Mar 2017 11:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HTW9mkLJ69gL for <6tisch-security@ietfa.amsl.com>; Thu, 30 Mar 2017 11:44:07 -0700 (PDT) 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 38127128D8B for <6tisch-security@ietf.org>; Thu, 30 Mar 2017 11:44:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CB892200A3; Thu, 30 Mar 2017 15:08:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F0BE9636BB; Thu, 30 Mar 2017 14:44:04 -0400 (EDT) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> CC: Benjamin Damm In-Reply-To: <1490892227379.87358@ssni.com> References: <1490892227379.87358@ssni.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: [6tisch-security] new con-call time until IETF99. X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 18:44:09 -0000 --=-=-= Content-Type: text/plain We had moved the 6tisch-security call time to the current time in order to attempt to accomodate some UTF-900 people on the west coast (and the weekday that they were unavailable), but that hasn't helped. We started with JITSI, and it was sometimes a problem, and we went back to webex+etherpad, and when the webrtc version didn't require a .exe download, it was great. I'd like to go back to JITSI; the caveat is that there is no PTSN dialin, only VoIP. I have shown this the week of April 10, but it would be repeating every two weeks until the week before IETF99. Here is the poll: https://doodle.com/poll/6gq8fphkw9t8wi8r Please note that in the upper-right, you can set the time zone that is displays the poll in. If you login, you can also see the possibilities on top of your calendar, if you use a compatible ics system. Please use "If-Need-be" (YES), if you could participate at least 3 out 4 times. If-Need-Be usually means you'd have to tweak some other part of your life, but that you'd be willing to do that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdUfQACgkQgItw+93Q 3WVOigf6AmtV40BzlVqm/JeptDMyZwqe5qNAHREsM3V58Tnrdj1d/lWQxjse5ibJ UMwKl/iQkbpr83Po34zxISE2EN40RO/A6926DquLedPN1XIviV6yHip7//FUvsdr t6p9naglMpgF8tK8pRCkjWDRtO6F9Z+MPe7Ty+qFraY2unTKO0oOikO2YVckPuRa lgOkIcBYswzeiF9v8t6NdVIEynjebVC5Zh+w9vbcEjXZzdtHPrnGNuFZpsH2aEKw fupZ9IF674Jk4tuc4Zl06FGGYsPLXWX641p3jh4+wezpn88KGfw1qBuNh0pNPGYF zgoQAZMFPueSFJjuR0vbt1+hN2HL6Q== =pErK -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 13:17:48 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC6129469; Thu, 30 Mar 2017 13:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 96cxaFcejAz7; Thu, 30 Mar 2017 13:17:39 -0700 (PDT) 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 B430C126B72; Thu, 30 Mar 2017 13:17:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A0E54200A3; Thu, 30 Mar 2017 16:41:36 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 929A8636BB; Thu, 30 Mar 2017 16:17:37 -0400 (EDT) From: Michael Richardson To: Thomas Watteyne cc: "6tisch\@ietf.org" <6tisch@ietf.org>, "6tisch-security\@ietf.org" <6tisch-security@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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 Archived-At: Subject: Re: [6tisch-security] IP-IP-IP example? X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 20:17:42 -0000 --=-=-= Content-Type: text/plain Thomas, here is an example of a join message header, as seen on the join side between pledge and Join Proxy. Please let me know how I can make this more complete for your code. If you want hex dump, I'll do that, but I'll have to create a full topology with some addresses. Let me do a second email for CoAP proxy example, once you are happy with this presentation. I don't have a good idea for size of OSCOAP pieces, I will pull those out. L2: srcmac=ab-cd-12-34-56-78-ab-cd dstmac=88-88-aa-bb-cc-dd-ee-ff IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 nh=17 UDP: srcport=1234 <- could be a constant? dstport=TBD <- we could ask for a port, or use 5683 ULP: OSCOAP stuff. Travelling from Join Proxy to root/JRC using IPIP(IP): L2: srcmac=ee-ff (2-byte, assigned short-address) dstmac=next-hop-l2 IPv6: ver=6 tc=0 flowid=0 src=2001:db8::eeff dst=2001:db8::0001 (assume JRC got assigned short-address 0001) nh=41 RPI header: rank=X, instanceID=Y IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Travelling from root/JRC to Join Proxy using IPIP(IP), if JRC is co-located in the DODAG root: L2: srcmac=next-hop-l2 dstmac=ee-ff IPv6: ver=6 tc=0 flowid=0 src=2001:db8::0001 dst=2001:db8::eeff nh=41 RPI header: rank=X, instanceID=Y RH3 header: X hops (do you want me to fill this in?) IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Travelling from root/JRC to Join Proxy using IPIP(IP), if JRC is NOT co-located. in the DODAG root. JRC is now 2001:db8:1::abcd. L2: srcmac=next-hop-l2 dstmac=ee-ff IPv6: ver=6 tc=0 flowid=0 src=2001:db8::0001 dst=2001:db8::eeff nh=41 RPI header: rank=X, instanceID=Y RH3 header: X hops (do you want me to fill this in?) IPv6: ver=6 tc=0 flowid=0 src=2001:db8:1::abcd dst=2001:db8::eeff nh=41 IPv6: ver=6 tc=0 flowid=0 src=fe80::abcd:1234:5678:abcd dst=fe80::0 UDP: srcport=1234 dstport=TBD ULP: OSCOAP stuff. Link-Local anycast: https://tools.ietf.org/html/rfc4291#section-2.6 as far as I can tell, we can make up our own LL-anycast, but we could reasonably also use fe80::0 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdZ+EACgkQgItw+93Q 3WVhPQf/Z8vO8JpsH/ja9IGcqSK2WVkQbpkPU53GasybgYdNc4jJZoObGRTepCUA m5mCTpo0c0+nMB8iTQevO+LEjnO8Swhwfz1sCRhoLfSVCt7pbzFLqy22VRL+Z5Aq LAUmQ5N9hoX34e9gWaLBCVfdPH+luqAVzx/k/30y7ceiKgoVVguLQXusv4z+yx42 DhRRNX0iSMtSMV9+vZF+Tnj6KoKa8/7YV6LSy45YmmoWUjH+QFkk6/4HftxJcoWq 5RlSbyNROExraxAjwQI9CrZl879S78K7dzGXYvZkqDoHahxaD0vwoFz3c+4k1M4J /e2zF95xqn9w1TPPDRWQ4trLWgLfGA== =yU4t -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 21:45:16 2017 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E35127F0E; Thu, 30 Mar 2017 21:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KYLuK5FolUdk; Thu, 30 Mar 2017 21:45:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B10127286; Thu, 30 Mar 2017 21:45:13 -0700 (PDT) X-AuditID: c1b4fb30-3dbff7000000628e-19-58ddded6e3dc Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 99.A9.25230.6DEDDD85; Fri, 31 Mar 2017 06:45:11 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.125]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 06:45:36 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Michael Richardson CC: Thomas Watteyne , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch] [6tisch-security] IP-IP-IP example? Thread-Index: AQHSp9ZZlc6sGqDRW0ie53KaWu2hSKGttCWAgACNzAA= Date: Fri, 31 Mar 2017 04:45:09 +0000 Message-ID: References: <11574.1490905057@obiwan.sandelman.ca> In-Reply-To: <11574.1490905057@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUyM2K7q+71e3cjDJ4uV7BoXrmI3WLZ3T5m i55D/ewWR1+/Z3Jg8Viy5CeTx6QXh1g8WubsYQ5gjuKySUnNySxLLdK3S+DKWDh3PXPBi8iK 5ndGDYwTwrsYOTkkBEwkFl99wdzFyMUhJLCeUeJLXycjhLOEUeLls2XMIFVsAi4SDxoeMYHY IgJ6EsuPPAMrYhboYZRY8mAtWJGwgKXEqesboYqsJDZuP8kCY296f5AVxGYRUJV43P8OrJ5X wF6iZ+02NhBbSKBSomnnF6BeDg5OAWOJPS+tQMKMAmIS30+tARvJLCAucevJfCaIq0UkHl48 zQZhi0q8fPyPFeKeyYxA8xdDzReUODnzCcsERuFZSPpnIaubhaQOoihe4tebF6wQtrzE9rdz mCFsTYn93cuhahQlpnQ/ZIewNSQ6v01kxRS3lpjx6yAbhG0q8froR0ZkNQsYeVYxihanFifl phsZ6aUWZSYXF+fn6eWllmxiBEb2wS2/DXYwvnzueIhRgINRiYd3gfvdCCHWxLLiytxDjCpA cx5tWH2BUYolLz8vVUmEV24fUJo3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Yklqdmp qQWpRTBZJg5OqQbGwOR3cXcXdR+6n5W+qvbGTyntCZeUWXvWLq2LVT524DGT8ccys0m7pjsx 6p36/XGNRHN6zr+SJKlT0svkdPrDmeLu8zho7Li2IDEy2d3iQubPFUvmhulOzt1aeOTJXy7b Z6/8v81qqOey5N+x0uDdlZ87Z00w3qj4pfmca2DklPcpb11cgxbGKLEUZyQaajEXFScCAJmn NVX0AgAA Archived-At: Subject: Re: [6tisch-security] [6tisch] IP-IP-IP example? X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 04:45:16 -0000 --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023 Content-Type: multipart/alternative; boundary=Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Transfer-Encoding: 7bit --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwNCg0KDQo+IE9uIDMwIE1hciAyMDE3LCBhdCAyMjoxNywgTWljaGFlbCBSaWNo YXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IFRob21hcywg aGVyZSBpcyBhbiBleGFtcGxlIG9mIGEgam9pbiBtZXNzYWdlIGhlYWRlciwgYXMgc2VlbiBvbiB0 aGUgam9pbg0KPiBzaWRlIGJldHdlZW4gcGxlZGdlIGFuZCBKb2luIFByb3h5LiAgUGxlYXNlIGxl dCBtZSBrbm93IGhvdyBJIGNhbiBtYWtlIHRoaXMNCj4gbW9yZSBjb21wbGV0ZSBmb3IgeW91ciBj b2RlLiBJZiB5b3Ugd2FudCBoZXggZHVtcCwgSSdsbCBkbyB0aGF0LCBidXQgSSdsbA0KPiBoYXZl IHRvIGNyZWF0ZSBhIGZ1bGwgdG9wb2xvZ3kgd2l0aCBzb21lIGFkZHJlc3Nlcy4NCj4gDQo+IExl dCBtZSBkbyBhIHNlY29uZCBlbWFpbCBmb3IgQ29BUCBwcm94eSBleGFtcGxlLCBvbmNlIHlvdSBh cmUgaGFwcHkNCj4gd2l0aCB0aGlzIHByZXNlbnRhdGlvbi4gSSBkb24ndCBoYXZlIGEgZ29vZCBp ZGVhIGZvciBzaXplIG9mIE9TQ09BUCBwaWVjZXMsIEkNCj4gd2lsbCBwdWxsIHRob3NlIG91dC4N Cg0KVGhlcmUgaXMgYSBuZXcgZHJhZnQgd2l0aCBtZXNzYWdlIG92ZXJoZWFkIGNhbGN1bGF0aW9u cyBmb3IgQ29BUCBzZWN1cml0eSBwcm90b2NvbHMgKERUTFMvVExTL09TQ09BUCkuIA0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVy aGVhZC0wMA0KDQpTZWUgRmlndXJlIDEgYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQgZm9yIGEg Y29tcGlsYXRpb24gb2YgdGhlIHJlc3VsdHMuIA0KDQpJdCB3YXNuJ3QgcHJlc2VudGVkIGluIHRo ZSBDb1JFIFdHIG9uIFR1ZXNkYXkgb3V0IG9mIGxhY2sgb2YgdGltZSwgc28gSSB0aGluayBpdCBp cyBmaXJzdCBvbiB0aGUgYWdlbmRhIGZvciB0aGUgRnJpZGF5IG1lZXRpbmcuIA0KDQpHw7ZyYW4= --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5IaSBNaWNoYWVsLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPk9uIDMwIE1hciAy MDE3LCBhdCAyMjoxNywgTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNy K2lldGZAc2FuZGVsbWFuLmNhIj5tY3IraWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OyB3cm90ZTo8 YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+PC9zcGFuPjxi cj48c3Bhbj5UaG9tYXMsIGhlcmUgaXMgYW4gZXhhbXBsZSBvZiBhIGpvaW4gbWVzc2FnZSBoZWFk ZXIsIGFzIHNlZW4gb24gdGhlIGpvaW48L3NwYW4+PGJyPjxzcGFuPnNpZGUgYmV0d2VlbiBwbGVk Z2UgYW5kIEpvaW4gUHJveHkuICZuYnNwO1BsZWFzZSBsZXQgbWUga25vdyBob3cgSSBjYW4gbWFr ZSB0aGlzPC9zcGFuPjxicj48c3Bhbj5tb3JlIGNvbXBsZXRlIGZvciB5b3VyIGNvZGUuIElmIHlv dSB3YW50IGhleCBkdW1wLCBJJ2xsIGRvIHRoYXQsIGJ1dCBJJ2xsPC9zcGFuPjxicj48c3Bhbj5o YXZlIHRvIGNyZWF0ZSBhIGZ1bGwgdG9wb2xvZ3kgd2l0aCBzb21lIGFkZHJlc3Nlcy48L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TGV0IG1lIGRvIGEgc2Vjb25kIGVtYWlsIGZvciBD b0FQIHByb3h5IGV4YW1wbGUsIG9uY2UgeW91IGFyZSBoYXBweTwvc3Bhbj48YnI+PHNwYW4+d2l0 aCB0aGlzIHByZXNlbnRhdGlvbi4gSSBkb24ndCBoYXZlIGEgZ29vZCBpZGVhIGZvciBzaXplIG9m IE9TQ09BUCBwaWVjZXMsIEk8L3NwYW4+PGJyPjxzcGFuPndpbGwgcHVsbCB0aG9zZSBvdXQuPC9z cGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVyZSBpcyBh IG5ldyBkcmFmdCB3aXRoIG1lc3NhZ2Ugb3ZlcmhlYWQgY2FsY3VsYXRpb25zIGZvciBDb0FQIHNl Y3VyaXR5IHByb3RvY29scyAoRFRMUy9UTFMvT1NDT0FQKS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0 c3Nvbi1jb3JlLXNlY3VyaXR5LW92ZXJoZWFkLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWF0dHNzb24tY29yZS1zZWN1cml0eS1vdmVyaGVhZC0wMDwvYT48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlNlZSBGaWd1cmUgMSBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVudCBm b3IgYSBjb21waWxhdGlvbiBvZiB0aGUgcmVzdWx0cy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pkl0IHdhc24ndCBwcmVzZW50ZWQgaW4gdGhlIENvUkUgV0cgb24gVHVlc2RheSBvdXQg b2YgbGFjayBvZiB0aW1lLCBzbyBJIHRoaW5rIGl0IGlzIGZpcnN0IG9uIHRoZSBhZ2VuZGEgZm9y IHRoZSBGcmlkYXkgbWVldGluZy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkfDtnJh bjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-63B59689-3FDB-475F-93BA-FE2F26022756-- --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR7DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF8jCCA9qgAwIBAgIQPmPdJI0I/Fh4Z0IWiX4FyTAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMjIwOTI2MTRaFw0xNzEyMjIwOTI2MTNaMGsxETAPBgNV BAoMCEVyaWNzc29uMRgwFgYDVQQDDA9Hw7ZyYW4gU2VsYW5kZXIxKjAoBgkqhkiG9w0BCQEWG2dv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXJhZ29zZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJJTmaZN/AJeYDz6jrMPRAFTMd1Ijw2eHX8gmp1QI0yxcaHKHXdU HR9v92W8bE24UrsQrMoCZXngRVqMv4VG5yDF6f2VwLtunh/Wp3dq72SA5dgrMe7D1u1HXG6pYb5+ /OtkZpIC3Zt7Bl6dpmfJlbGhf2juJrZm+JaS2vR+sGVdyKinIiUyciBngPh6J/jvCVxf9k8BNi+b 4CR0gfr8+qRj/wKrcUwgti+tG87lfWmvPK4sf52y64RNR4ZtsdCtT4LYMomcTrFWbgr2dcG+lx+R 0pVC6qqDs7vVJ3VBEPK3oEJeOtJnimtHL+fboNToUxwifYOR5d1aebxKnHGgT/MCAwEAAaOCAcEw ggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDov L29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlh c29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2VyMCYGA1UdEQQfMB2BG2dvcmFu LnNlbGFuZGVyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsG AQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFIHidNufe3WwHbOEvGidlbceG/3/ MB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG 9w0BAQUFAAOCAgEA1JVNvEJtJx5cKn+1f5QKWgHmrlQjvjdDm8pX6H5MHzpxoaccG4G0dq1UlMP+ T6bK3z4H4i7rQzZStfeAGbBJNbpjwxmG1diKM4w4+8pXKoeR/2KRUxYMEob5vo71QH4Sia1x9ntw SVcK78CNdbhDsJlZXA+sk5Et5zqZ8RH26xgRrQ7H6Z5ZbmxEMpUdMWBWCy5vf7ii7OA5CmyoatDJ 1iGi8im009qVYZJJMxilb6vqu6RJD+xSOXnikIBJmPnOz2ZC71+FG2bgj70dwE1J7X7KroQJbRm9 zzbKdhMXHfDQCu3WGaad3t64zXsnOk5GuHfLTsN7LTBzdGg/jPghI19+wL7P6NUyXngfU9hiIO4e I9/5wyiuUxcU+zutMWBlL+ZjUHa/6pk/072TiL+Dgc9CWwmCdbELlNaW4yw4fNBLfkVH6h6L/flo PA1i90+LF5Y2FSaRHi+1/J2Oktb7d4rLFx/Qd/9JUm7MxiueywEV76Ng0Ylga904WMkV9+ooJxGh wnSXbkAtNUO2/eSllqnphldoEB5hOdwZZXK/215uG0gtV2qU7uwu0/fMAZnjps9Nb/ngXtM7Bn6R 8jS+m0WAk3mIADwbA6+EFq2s3D2gD10zaKgCUFuIPeBDwXPszGr/kCSlJ23cbPF3sc3CGLkYiS7I +2rVTsH+jX0pYLswgga2MIIEnqADAgECAhEAoAzLzJuZmOziOnD0fMHAWTANBgkqhkiG9w0BAQUF ADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2 MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDoxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZKFzoDkgTIVuhcxlbeUUeyj7/q47d mKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCTu7CiMnfi0cuJf/JCiuIj5vkNfF8h hdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR5Mw9GBdyf7wagU6+25Uc2H9Yd4+W u6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicngZrxLowTbCBIFEOiXEBRuZ8tBGsy8 sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo0+rn/IdpLjyMKw4EBTRMiEGeKudm aURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechwx0gQXkG1QF5vMEkwwX10MHa6PwF6 hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr8IZF2ncYemSDF84G+lqY4ry50dBh Cja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2ELLkRJw7I1qOsBdC6mwOe+vaJvZ5/7 ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0dyE+0G86tqH9xNbNfMaPAzPQ/dQmp NDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJhm3Emf1y/tLZ1TG5SJ6CYC9QYdz4k YnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ1Ls63QDVSp2MYWu2cghIj5mPfLAd m52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN06XqaUNslpMgQZqB1FyYfe7nuvmy dn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4tbWPYiMnRzIMjrt3X87MVPAIrzBh uGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs5orjYfaJ87oREdsmISv+iHgrOB0B 6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB47tDJA84joZvgVcD2Sjewe8A+zj4 +r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY4if7vQX6q8qmabnZ1nxvsMQt9u66 TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBshhMkUhyhYUcCXSDT81iyPPcMuFnP j4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzOxnkkvyxRnvOCpiY0w370/HNqyvJx Mmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+Y90kjQj8WHhnQhaJfgXJ MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE3MDMzMTA0NDUwOFowIwYJKoZIhvcNAQkEMRYEFFEJCQNOhHuwtlvQhYrIEVJHO8R7MF0GCSsG AQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjICED5j3SSNCPxYeGdCFol+BckwXwYLKoZIhvcNAQkQAgsxUKBOMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhA+ Y90kjQj8WHhnQhaJfgXJMA0GCSqGSIb3DQEBAQUABIIBAFwQ9cdMqmLK6xA1kSsnYwA9YYp3z78+ 9TTg/+ly54m950vjimW9jDUK6doUsChGRyyoY05EsOuYiNSqmBN7sxne3hi6z9glZGytbYN9TZgk HRSgyeZ/koTga5nICvPGcEgyKPGlkWVqAgg6c1CO3y/6a0WCsoe2eiiOGzoKFSX7Jark8xiyoFiS KFgUDnXASMgsKx3x9EkyhDkedYjMxu+4fdEDMUMg75DJtKir7t6Va/NbQKtyeNK6Z1yFG7QpjZwV jK3J+m4jZXQMO9vcexalH0IicPvny7fYaWi+IrHsj2NkDZvggcZj2+PJMcG+wHI93nBNq2aJzlzB gh8+w5oAAAAAAAA= --Apple-Mail-593801AB-F1A3-4E94-845C-B78154849023--