From nobody Thu Jul 3 14:51:25 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D551B2A56 for <6tisch-security@ietfa.amsl.com>; Thu, 3 Jul 2014 14:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001, T_MIME_NO_TEXT=0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz2Ok95Mprc5 for <6tisch-security@ietfa.amsl.com>; Thu, 3 Jul 2014 14:51:22 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [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 6737A1B2A4D for <6tisch-security@ietf.org>; Thu, 3 Jul 2014 14:51:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F5882002C for <6tisch-security@ietf.org>; Thu, 3 Jul 2014 17:51:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 268F363B0E; Thu, 3 Jul 2014 17:51:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 102FA63B0A for <6tisch-security@ietf.org>; Thu, 3 Jul 2014 17:51:20 -0400 (EDT) From: Michael Richardson To: 6tisch-security <6tisch-security@ietf.org> X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/G37FdDCsR44-LEEbjiN8aRDHLEI Subject: [6tisch-security] draft-richardson-6tisch-security-6top-01 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:51:24 -0000 --=-=-= This update is available at your nearby ID draft directory. ASCII art from Jonathan's slides with a few additions. (Use a non-proportional font) I think that the join request could be the NS+ARO/EARO. I have a shitload more text, and so please don't be surprised if there is a -02 when you look, assuming I can get it in ontime. I made up "JCE" to the join management parts of the Authorization Server/PCE. We might also have the ACE... +-----+ +------+ +----------+ +-----------+ | | | | | JOIN | | Joining | | JCE | | 6LBR | | Assistant| | Node | +-----+ +------+ | (proxy) | | | | | +----------+ +-----------+ | | | | | | |-------BEACON (1)---------->| | | | | | | |<----Router Solicitation----| | | |---Router Advertisement---->| | | | | | | |<------CERTIFICATE----------| | | | REQUEST (2) | | | | | | | | | | | |-------CERTIFICATE--------->| | | | RESPONSE (multiple) | | | | (packets) | | | | | | | |<-----JOIN REQUEST (4) -----| | | | (NS w/ARO ) | | | | | | |<---NS (DAR) (5)-----| | |<--??(6)-| | | | | | | |--??(7)->| | | | | | | | |----NS (DAC)-(8)---->| | | | +------+ | | | || | | | ACK +------+ | | | | |-------JOIN ACK (9)-------->| | | | | | | | | |================(10)==========>|----------6top----(11)----->| | | | DTLS | |<===============(13)===========|<---------CoAP----(12)------| | | | (many packets) | -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7XQVYCLcPvd0N1lAQIQ3AgAvniSL/ewwr34uQUAghkTTc6s2XAnv4rb nmgGEPszI8fs1UYxD8gb6yKojOzhVel+VjLuOVVqILLff7jYErVLfFJ3X77r2PKV ZbuDPbhlb69kRwZtB1JcsVlh5qyAB1zMPA8Mg2Jx6p0NsDCfDGJrywHF77aMfI9r CtsMjCI6mSEewRMwu57ueWbrwTp2dzrLydgU1ftV5mdUMD04GqzGi+kdzoXvA4bu o2b3NhBEWowIhVtD202DIDjS7cun9Sbf6eF2Un6eVb6cWsI1scMWUhEKaehWV5AO aN/vW68wyKbShGZtBdXkBH83x64h0CLinXNlsI1CmpCZQW/qHAzktw== =15r8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 3 20:03:24 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472B31B2B45 for <6tisch-security@ietfa.amsl.com>; Thu, 3 Jul 2014 20:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xSQSbb3nF0r for <6tisch-security@ietfa.amsl.com>; Thu, 3 Jul 2014 20:03:03 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D221B2B2E for <6tisch-security@ietf.org>; Thu, 3 Jul 2014 20:03:01 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so918117qaq.10 for <6tisch-security@ietf.org>; Thu, 03 Jul 2014 20:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=TBY8+7+c7oOg8MECJ2Hg28j0N2m/vkAC6g5ttuk/ujA=; b=g2a1kb6Mfau+uwmBASEA8BLdbQp5Psd5kLuYuUabrRzafpLopB1m2PNHjAee902jEf 23owQNwnSjh+B5CXQOO/yLSsJqy7kHdINddoh2mJde0Fp+x/aeOJxESvUnpCTjqjAYpd n9WzEKEDVkjQRT2EuVRwHc1lRdsacLAC/7XBtalnKY1gqxcuOV9E3a7lGh0Sf/i5pBe2 TCx5MR/aGhNRWteOf5a905qBKYVJhOWz8551jgmkZOfFmfC007NLyoPlNPCIHyy2oUyr 7E164XSkYQa+u0J48qDeEQSCyAiS0hV8qxef7wGsTHvMIRXEvo5f7wzgEsUvbVQbqK4E Ywxg== X-Received: by 10.224.55.202 with SMTP id v10mr14684486qag.10.1404442980683; Thu, 03 Jul 2014 20:03:00 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.140.95.184 with HTTP; Thu, 3 Jul 2014 20:02:40 -0700 (PDT) In-Reply-To: <3034.1404424280@sandelman.ca> References: <3034.1404424280@sandelman.ca> From: Thomas Watteyne Date: Thu, 3 Jul 2014 20:02:40 -0700 X-Google-Sender-Auth: -_oPLDseXHkAHbvdwtb4gg_RrT4 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11c3029af8950204fd555ccd Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/rdrkMrTu1zlPsc3QOTeJaWjdahY Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch-security-6top-01 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:03:05 -0000 --001a11c3029af8950204fd555ccd Content-Type: text/plain; charset=UTF-8 Michael, A quick clarification: although your e-mail is entitled draft-richardson-6tisch-security-6top-01, the draft is http://tools.ietf.org/html/draft-richardson-6tisch-table-of-contents-01, right? Maybe rename the draft at the following iteration? Thomas On Thu, Jul 3, 2014 at 2:51 PM, Michael Richardson wrote: > > This update is available at your nearby ID draft directory. > ASCII art from Jonathan's slides with a few additions. > (Use a non-proportional font) > I think that the join request could be the NS+ARO/EARO. > > I have a shitload more text, and so please don't be surprised if > there is a -02 when you look, assuming I can get it in ontime. > I made up "JCE" to the join management parts of the Authorization > Server/PCE. > We might also have the ACE... > > > +-----+ +------+ +----------+ +-----------+ > | | | | | JOIN | | Joining | > | JCE | | 6LBR | | Assistant| | Node | > +-----+ +------+ | (proxy) | | | > | | +----------+ +-----------+ > | | | | > | | |-------BEACON (1)---------->| > | | | | > | | |<----Router Solicitation----| > | | |---Router Advertisement---->| > | | | | > | | |<------CERTIFICATE----------| > | | | REQUEST (2) | > | | | | > | | | | > | | |-------CERTIFICATE--------->| > | | | RESPONSE (multiple) | > | | | (packets) | > | | | | > | | |<-----JOIN REQUEST (4) -----| > | | | (NS w/ARO ) | > | | | | > | |<---NS (DAR) (5)-----| | > |<--??(6)-| | | > | | | | > |--??(7)->| | | > | | | | > | |----NS (DAC)-(8)---->| | > | | +------+ | | > | | | |-DAO-| node |--DACK->| | > | | ACK +------+ | | > | | |-------JOIN ACK (9)-------->| > | | | | > | | | | > |================(10)==========>|----------6top----(11)----->| > | | | DTLS | > |<===============(13)===========|<---------CoAP----(12)------| > | | | (many packets) | > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a11c3029af8950204fd555ccd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+TWljaGFlbCw8ZGl2Pjxicj48L2Rpdj48ZGl2PkEgcXVpY2sgY2xhcmlm aWNhdGlvbjogYWx0aG91Z2ggeW91ciBlLW1haWwgaXMgZW50aXRsZWTCoGRyYWZ0LXJpY2hhcmRz b24tNnRpc2NoLXNlY3VyaXR5LTZ0b3AtMDEsIHRoZSBkcmFmdCBpcyA8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC10YWJsZS1vZi1jb250 ZW50cy0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGFyZHNvbi02dGlz Y2gtdGFibGUtb2YtY29udGVudHMtMDE8L2E+LCByaWdodD8gTWF5YmUgcmVuYW1lIHRoZSBkcmFm dCBhdCB0aGUgZm9sbG93aW5nIGl0ZXJhdGlvbj88L2Rpdj4NCg0KPGRpdj48YnI+PC9kaXY+PGRp dj5UaG9tYXM8L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxicj48ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBKdWwgMywgMjAxNCBhdCAyOjUxIFBNLCBNaWNo YWVsIFJpY2hhcmRzb24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86bWNyK2ll dGZAc2FuZGVsbWFuLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWNyK2lldGZAc2FuZGVsbWFuLmNhPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+PGJyPg0KVGhpcyB1cGRhdGUgaXMgYXZhaWxhYmxlIGF0IHlvdXIgbmVh cmJ5IElEIGRyYWZ0IGRpcmVjdG9yeS48YnI+DQpBU0NJSSBhcnQgZnJvbSBKb25hdGhhbiYjMzk7 cyBzbGlkZXMgd2l0aCBhIGZldyBhZGRpdGlvbnMuPGJyPg0KKFVzZSBhIG5vbi1wcm9wb3J0aW9u YWwgZm9udCk8YnI+DQpJIHRoaW5rIHRoYXQgdGhlIGpvaW4gcmVxdWVzdCBjb3VsZCBiZSB0aGUg TlMrQVJPL0VBUk8uPGJyPg0KPGJyPg0KSSBoYXZlIGEgc2hpdGxvYWQgbW9yZSB0ZXh0LCBhbmQg c28gcGxlYXNlIGRvbiYjMzk7dCBiZSBzdXJwcmlzZWQgaWY8YnI+DQp0aGVyZSBpcyBhIC0wMiB3 aGVuIHlvdSBsb29rLCBhc3N1bWluZyBJIGNhbiBnZXQgaXQgaW4gb250aW1lLjxicj4NCkkgbWFk ZSB1cCAmcXVvdDtKQ0UmcXVvdDsgdG8gdGhlIGpvaW4gbWFuYWdlbWVudCBwYXJ0cyBvZiB0aGUg QXV0aG9yaXphdGlvbiBTZXJ2ZXIvUENFLjxicj4NCldlIG1pZ2h0IGFsc28gaGF2ZSB0aGUgQUNF Li4uPGJyPg0KPGJyPg0KPGJyPg0KwqArLS0tLS0rIMKgICstLS0tLS0rIMKgIMKgIMKgIMKgIMKg IMKgKy0tLS0tLS0tLS0rIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tLS0tLS0tKzxicj4N CsKgfCDCoCDCoCB8IMKgIHwgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgfCDCoEpPSU4gwqAg wqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoEpvaW5pbmcgwqB8PGJyPg0KwqB8IEpDRSB8 IMKgIHwgNkxCUiB8IMKgIMKgIMKgIMKgIMKgIMKgfCBBc3Npc3RhbnR8IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfCDCoCBOb2RlIMKgIMKgfDxicj4NCsKgKy0tLS0tKyDCoCArLS0tLS0tKyDCoCDC oCDCoCDCoCDCoCDCoHwgwqAocHJveHkpIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKg IMKgIMKgIMKgIHw8YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqArLS0tLS0tLS0tLSsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS0tLS0tLS0tLS0rPGJy Pg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwtLS0tLS0tQkVBQ09O ICgxKS0tLS0tLS0tLS0mZ3Q7fDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8Jmx0Oy0tLS1Sb3V0ZXIgU29saWNpdGF0aW9uLS0tLXw8YnI+DQrCoCDCoCB8IMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfC0tLVJvdXRlciBBZHZl cnRpc2VtZW50LS0tLSZndDt8PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwmbHQ7LS0tLS0tQ0VSVElGSUNBVEUtLS0tLS0tLS0tfDxicj4NCsKgIMKgIHwgwqAg wqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIFJF UVVFU1QgKDIpIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 LS0tLS0tLUNFUlRJRklDQVRFLS0tLS0tLS0tJmd0O3w8YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKg IHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoFJFU1BPTlNFICht dWx0aXBsZSkgfDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChwYWNrZXRzKSDCoHw8YnI+DQrC oCDCoCB8IMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IMKgIMKg IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCZsdDstLS0tLUpPSU4gUkVR VUVTVCAoNCkgLS0tLS18PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAoTlMgdy9BUk8gKSDCoCDCoCDCoCDCoCDCoCB8PGJy Pg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDC oCDCoCDCoCDCoCB8Jmx0Oy0tLU5TIChEQVIpICg1KS0tLS0tfCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8Jmx0Oy0tPz8oNiktfCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxi cj4NCsKgIMKgIHwtLT8/KDcpLSZndDt8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8 LS0tLU5TIChEQUMpLSg4KS0tLS0mZ3Q7fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKgIHwgwqAgwqAgKy0tLS0tLSsgwqAg wqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4N CsKgIMKgIHwgwqAgwqAgwqAgwqAgfCZsdDtEQU8tfCBtZXNoIHwmbHQ7LS1EQU8tLXwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDCoCDCoCDC oCDCoCB8LURBTy18IG5vZGUgfC0tREFDSy0mZ3Q7fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKgIHwgQUNLICstLS0tLS0r IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fC0tLS0tLS1KT0lOIEFDSyAoOSktLS0tLS0tLSZndDt8PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDC oCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB8PGJyPg0KwqAgwqAgfD09PT09PT09PT09PT09PT0oMTApPT09PT09PT09PSZndDt8 LS0tLS0tLS0tLTZ0b3AtLS0tKDExKS0tLS0tJmd0O3w8YnI+DQrCoCDCoCB8IMKgIMKgIMKgIMKg IHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoERUTFMgwqAg wqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCZsdDs9PT09PT09PT09PT09PT0oMTMpPT09 PT09PT09PT18Jmx0Oy0tLS0tLS0tLUNvQVAtLS0tKDEyKS0tLS0tLXw8YnI+DQrCoCDCoCB8IMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCht YW55IHBhY2tldHMpIMKgIMKgIMKgfDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tPGJy Pg0KTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJTJCSUVURkBzYW5k ZWxtYW4uY2EiPm1jcitJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdh cmUgV29ya3M8YnI+DQrCoC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS08YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQo2dGlzY2gtc2VjdXJpdHkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OjZ0aXNjaC1zZWN1cml0eUBpZXRmLm9yZyI+NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2No LXNlY3VyaXR5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82dGlzY2gtc2VjdXJpdHk8L2E+PGJyPg0KPGJyPjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+DQo= --001a11c3029af8950204fd555ccd-- From nobody Fri Jul 4 07:51:04 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA0E1B2A55 for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 07:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM-ag-40nk7d for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 07:51:01 -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 235561A00B6 for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 07:51:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 65C5A2002C; Fri, 4 Jul 2014 10:51:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 78AD063B0E; Fri, 4 Jul 2014 10:50:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5D6C663B0A; Fri, 4 Jul 2014 10:50:59 -0400 (EDT) From: Michael Richardson To: Thomas Watteyne In-Reply-To: References: <3034.1404424280@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/naNkWztSFc91RYr7781gdWXx-70 Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch-security-6top-01 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:51:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thomas Watteyne wrote: > A quick clarification: although your e-mail is > entitled=C2=A0draft-richardson-6tisch-security-6top-01, the draft is = http:// > tools.ietf.org/html/draft-richardson-6tisch-table-of-contents-01, > right? Maybe rename the draft at the following iteration? what? huh. tables-of-contents should be different... Oh. I'll post the right draft name, and repost -02 of table of contents. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7a/UICLcPvd0N1lAQKtFwf8DK5ZRqzlx67YoMe6ZleAFDqsSCl9dhw2 +l/plYqLVyJj4MKuWrHJGvcyXNEwysYUoDkZJb+TiNKXN6pUuwAQOEVz/hd7+Ixq aaROG33JWMQGBXzQZx9FgV+oIE4wGEKE7YYgyxUtA622V746yAcbDspFFAA1et8B qxOCj/mgeXD1AoewEbm7CC5TgP2NULKb/7nqsH2Nm7W2/GpuebW3G+atZTP5bNwY 3Yavw4RvKWOM0eFl0o61JiJCpQ0oNmH7IAlAU4PAuoXPPd1ipRvMNQn/1Ape9+2u lQlE6TxwqaE/BnJyyXUEl9rxPliPYarEsb4LVJQeKNmPoIvSw74qaw== =c7gZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 4 08:09:45 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F341B2A6C for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 08:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.04 X-Spam-Level: ** X-Spam-Status: No, score=2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, MISSING_HEADERS=1.021, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsOy5g8n9VLQ for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 08:09:42 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD291B2A8A for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 08:09:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 087692002C; Fri, 4 Jul 2014 11:10:18 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3FDB563B0E; Fri, 4 Jul 2014 11:09:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 245FD63B0A; Fri, 4 Jul 2014 11:09:40 -0400 (EDT) From: Michael Richardson In-Reply-To: <21839.1404485459@sandelman.ca> References: <3034.1404424280@sandelman.ca> <21839.1404485459@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/PIN49PDcOaMurO_e02XTQTaS_sY Cc: Thomas Watteyne , 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch-security-6top-00 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:09:43 -0000 --=-=-= okay, I've unconfused the drafts. Sorry for that screw up. http://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7bDsYCLcPvd0N1lAQJwaAf/UgeH/YYWVNCKduCd8Ky+be0ttI+S1ZxO wcFfdztlvjzLOHmf++Za/D084D/G0rpPkLWsoTOjx9M37O85OasN87y/5Jmk7Zg3 17odfnn8wyduENPAdg29SJJ/pIKe31dFPXpA64C8ZbsXtTBfE522+hBkNhVEuCVJ KdNIX13mTuXBoekWr+mmyGGHECsDJnMsf2HwRy7RLGCFuvIIgJqxrLTfYDf23by5 yBrlN53j7cjb4++GhkTJ0niK5+1hzXqU3NhDBlNWnViOOd0PdbrKHXbK4uMDAKMs mo5LFn0mWMotEbLdfOEfTvKSsp1bx7+GZorUMD/lOjCJYB+Ne3hSEg== =ZDzK -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 4 08:11:40 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225981B2AD4 for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18UrZ610AH4R for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 08:11:30 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758051B2AD3 for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 08:11:30 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so1429934qac.18 for <6tisch-security@ietf.org>; Fri, 04 Jul 2014 08:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=x6SvqS530yOUi35nGjnLpw1fdm1phCqTPNK8pwBz6SI=; b=MxicZxuFkb5NKURR3y0zcEPd0ThHXyavTTAfnMz2iIOEhKK8C62Bh+4iXQ6VQVTOJx kKd2CrXOQtM9L4UHeAb4hDbGeFUP9lN78qt9mCE4wGyXhnO2vCHq/l4S+Qb5SB6eEkyv jU4nY7t4aSM2MEL/WQje3O1ig+uYpHKWLAVuQ0FOPoHTc+s235uBzgIsRx0hAjFaik6S lwDCj6nDwaQFCfT6LL+Vq4VUl+UEtGrTBkarAaafXF0Qiyj6+rIa6Kvuir7hVHtTvT+p WlNv7LXphalYi/JDR0GFZiHPpVjl/6k9TEdzx4l2avv35dIt+8B9nFA952nkdrUpDMU9 pENA== X-Received: by 10.224.111.196 with SMTP id t4mr19673061qap.63.1404486688702; Fri, 04 Jul 2014 08:11:28 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.140.95.184 with HTTP; Fri, 4 Jul 2014 08:11:08 -0700 (PDT) In-Reply-To: <26003.1404486580@sandelman.ca> References: <3034.1404424280@sandelman.ca> <21839.1404485459@sandelman.ca> <26003.1404486580@sandelman.ca> From: Thomas Watteyne Date: Fri, 4 Jul 2014 08:11:08 -0700 X-Google-Sender-Auth: I5Y0pFbGxIpJU-HnhNf73WTS2J4 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11c2d6002c040b04fd5f8a8b Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/lz2bFxNi9MgVBqHnj50q9oToJjg Cc: 6tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] draft-richardson-6tisch-security-6top-00 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:11:38 -0000 --001a11c2d6002c040b04fd5f8a8b Content-Type: text/plain; charset=UTF-8 Excellent, thanks! On Fri, Jul 4, 2014 at 8:09 AM, Michael Richardson wrote: > > okay, I've unconfused the drafts. > Sorry for that screw up. > > http://datatracker.ietf.org/doc/draft-richardson-6tisch--security-6top/ > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a11c2d6002c040b04fd5f8a8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Excellent, thanks!

On Fri, Jul 4, 2014 at 8:09 AM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

okay, I've unconfused the drafts.
Sorry for that screw up.

http://datatracker.ietf.org/doc/draft-richardson= -6tisch--security-6top/

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




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


--001a11c2d6002c040b04fd5f8a8b-- From nobody Fri Jul 4 13:41:37 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB70B1B2F80 for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 13:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, MANGLED_TOOL=2.3, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uydtbysTXA5i for <6tisch-security@ietfa.amsl.com>; Fri, 4 Jul 2014 13:41:35 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F641B2854 for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 13:41:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 838D02002C for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 16:42:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D304763B0E; Fri, 4 Jul 2014 16:41:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BE6D363B0A for <6tisch-security@ietf.org>; Fri, 4 Jul 2014 16:41:33 -0400 (EDT) From: Michael Richardson to: 6tisch-security <6tisch-security@ietf.org> In-Reply-To: <3034.1404424280@sandelman.ca> References: <3034.1404424280@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/j2SsRzuj7FOcYN6tumJlwfEnPGY Subject: [6tisch-security] joining process threat summary draft-richardson-6tisch-security-6top-01 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:41:36 -0000 http://goo.gl/7bMYjc gives you a diff of -00 to -01. The document should grow a number of additional authors, and an acknowledment section of the people who participated in the weekly calls. (And we will have no calls until after IETF90) section 4.1.3: maybe too alarmist. Have I missed any threats? I'm posting the threat text here for discussion: 4.1.1. threats to the joining node A node may be taken out of it's box by a malicious entity and powered on. This could happen during shipping, while being stored in a warehouse. The device may be subject to physical theft, or the goal of the attacker may be to turn the device into a trojan horse of some kind. Physical protection of the device is out of scope for this document; this document will henceforth assume that the device is sealed in some tamper-evident way and this document deals with attacks over the network. An attacker may attempt to convince the joining node that it is the legitimate Production Network; this is done by putting up a legitimate looking Join Network, and following the protocol as described in this document. The Joining Node can not know if it has the corrrect Production Network until steps 11-13, when it attempts to validate the ClientCertificate provided by the JCE. When the joining node determines that this is the incorrect network, it must remember the PANID of the network that it has attempted to join, and then look for another network to try. It SHOULD have some limit as the number of times it will try before going back to sleep, or shutting down, and it SHOULD take care not to consume more than some specified percentage of any battery it might have. Should a malicious production network be present at the same time/ place as the legitimate production network, a the malicious agent could intercept and replay various packets from the proper join network, but ultimately this either results in a jamming-like denial of service, and/or the the ClientCertificate will not validate. It is a legitimate situation for there to be multiple possible join networks, and the joining node may have to try each one before it finds the network that it the right one for it. The incorrect, but non-malicious networks will not attempt the 6top provisioning step, and SHOULD return a negative result in steps 8/9, refusing the node's NS. Those incorrect networks will be recognize that the node does not belong to them, because they will be able to see the Joining Node's IDevID in the ARO of step 4. 4.1.2. threats to the resources of the network The production network has two important resources that may be attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory for routing entries. A malicious joining node could send many NS messages to the Join Assistant (from many made up addresses), which would send many NS/DAR messages to the 6LBR, and this would consume bandwidth, and therefore energy from the members of the mesh along the path to the 6LBR. This can be mitigated by limited the total bandwidth available for joining. A malicious joining node could send many NS messages, and if the 6LBR agreed to accept the new node (by IDevID), then the Join Assistant would MAY inject routing information into mesh for the Joining node. Non-storing DODAGs store are routing information in the DODAG Root (probably the 6LBR), which is generally not a constrained node. Storing DODAGs store routing entries at all nodes up to the DODAG, and those are constrained nodes. Using a separate Join DODAG, and having that DODAG be non-storing will reduce any impact on intermediate nodes, but it does cause resources to be used for the second DODAG, and it may have a code impact if the nodes otherwise would not implement non-storing RPL. 4.1.3. threats to other joining nodes A joining node (or the nodes of a malicious network, co-located near the legitimate production network) may mount attacks on legitimate nodes which have not yet joined. The malicious nodes may attempt to perform 6top operations against the joining node to keep it from being able to respond to the legitimate 6top session from the legitimate JCE. During the Join phase, the Joining node MUST have all other resources and protocols turned off, even if they would normally be accessible as read-only unauthenticated CoAP resources. Malicious nodes could use the Join Network to mount various DTLS based attacks against the joining node, such as sending very long certificate chains to validate. One might think to limit the length of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] the chain may as a long as the supplier chain, plus may include additional certificates due to resales of plants/equipment/etc. Validating from a trusted certificate down to the specific certificate which proves ownership would eliminate random certificate chains, but the attacker could just feed the joining node legitimate chains that it observed (and replayed) from the legitimate JCE. This does no good; the Joining node finds that the DTLS connection is invalid, but it may significantly run batteries down. From nobody Sat Jul 12 17:43:00 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6B51A0B06 for <6tisch-security@ietfa.amsl.com>; Sat, 12 Jul 2014 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8by-4_AzptSM for <6tisch-security@ietfa.amsl.com>; Sat, 12 Jul 2014 16:04:39 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7091A0B0D for <6tisch-security@ietf.org>; Sat, 12 Jul 2014 16:04:36 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so2114399qaq.10 for <6tisch-security@ietf.org>; Sat, 12 Jul 2014 16:04:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=XJduSsBVnwCHNzNhhOGFlHQr5FJ2rn4P1nBseVuhOdM=; b=VNromScj8HoeQpOsEBTOLIVzkmBikmlOYt0ZBCTPwkhCxMvwiogtxlOGdcZBauJ37D sWnFNSB+80V83ucBwSb9+s4HCxA2UD1hF1OdKFk4XjXkhYmNGn2aGwFqpOWgZa5hIXFa aN/D4CNDWNY6a1V572rRnc14u52jV0+5aQ+ztf8U3OzT1apSCf/GVZym3UR8+UQ6fhv4 Z4VJc2l7EmIBqhUEhGdFvuwvj0HtIoViSMiuyEBgolH0tUcfbj/knbxNagbX8SGvmr4w 4wAO6IyvavJpnI6ISwJga/VekIXl7oOz18ljdWFkQlQtvz0x2lDB/bDL0TbaQwgoTA1W TNOw== X-Gm-Message-State: ALoCoQnZoN3rR2ppE5cDBkkyBdMncAt9R3D9P6opGUqJMRAn+vTXQ9184a1SJr+16wrOAd2bWMog X-Received: by 10.140.48.161 with SMTP id o30mr11364188qga.68.1405206276105; Sat, 12 Jul 2014 16:04:36 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:482e:2de0:c30c:8b94? ([2601:a:2a00:390:482e:2de0:c30c:8b94]) by mx.google.com with ESMTPSA id d3sm11900638qad.43.2014.07.12.16.04.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 16:04:35 -0700 (PDT) Message-ID: <53C1BF0E.3000303@nthpermutation.com> Date: Sat, 12 Jul 2014 19:04:46 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 6tisch-security@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/6ZFIXWCphObFC145oPW8Yxp4SY4 X-Mailman-Approved-At: Sat, 12 Jul 2014 17:42:58 -0700 Cc: mcr@sandelman.ca Subject: [6tisch-security] Comments on draft-richardson-6tisch-security-6top X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 23:04:41 -0000 Michael Richardson asked me to comment on the subject draft. I'm not a subscriber to the list, so any replies need to be cc'd to me. I took a look at the document primarily with respect to whether or not the as described model made sense. Comments: 1) The document has more than its share of unexplained acronyms. While I appreciate that this references back to other WG documents, it makes this document somewhat difficult to evaluate on its own merits. Of special note, is the use of IDevID (and an apparently incorrect reference to DevID) which is an 802.1AR term. The general rule for the IETF document series is that it's OK to point to other RFC's for general acronyms, but to explain in sufficient detail any acronyms that come from other document series. 2) There needs to be a discussion of pre-conditions. For example, where exactly did the IDevID come from? If manufactured in, what are the assumptions about the provisioning of the roots of trust (manufactured and local) to the various nodes in the system? 3) It's unclear why you're proposing specialized "join assistant" nodes. If you intend for this to be a distinct role, then a discussion of how that role is assigned, and why it needs to be distinct from the "non-leaf node with routing" role is necessary. My personal opinion is that making them distinct is a bad idea as it adds to the complexity of provisioning a mesh and probably requires real world geography and topology information to be sure you cover all the places that joins could happen. (E.g. what happens if a joining node can only see a non-join assistant node?) 4) In section (3) you refer to a locally significant DevID - I assume you mean an 802.1AR LDevId? Or something else? 5) DOS attacks on the "join assistant" are probably less problematic than DOS attacks on the mesh as a whole. Why not have the join assistant verify the cert chain of the joiner (to include a signed challenge for timeliness and proof of possession of the related private key)? Then have the JA send just the mac address of the joiner to ask if that MAC is a legitimate joiner. If you get a yes answer back, the JA sends the rest of the joiner cert chain upstream and gets back the LDevID which it then gives to the joiner. The Joiner now uses the LDevID as its credential to join the network. It's possible to DOS any given node with join attempts, but its pretty easy for such a node to throttle them (handle not more than one distinct MAC per 5 minutes unless you're in mesh building mode), but since the JA never sends up unauthenticated IDevIDs and the associated cruft, you don't translate that DOS on the JA to a DOS on the mesh. Since the MAC is tied to the IDevID you have a pretty good protection against MAC forgery doing it that way. 6) You need to handle the case where there are two legitimate meshes within earshot of each other. There needs to be a mechanism for a node to figure out which mesh it needs to belong to. The specific case of a legitimate mesh next to an illegitimate attacker suggests that you need a way for the joining node to be pre-provisioned with the root of trust for the LDevIDs for a particular system. E.g. as much as you need to authenticate the joiner to the mesh, you need to be able to authenticate the mesh to the joiner. Steps 2 & 3 seem to be where you install the "authorizer"s certificate as the controlling entity for the mesh - if you install the wrong one, how do you recover? 7) A discussion of permanent storage would be helpful - e.g. what's on the node at manufacture, what's on the node after enrollment, and how much of that has to stay on the node after a power cycle. 8) A discussion of disenrollment, both from the ejection model (e.g. controller says that the node is no longer welcome both in an emergency - this node is compromised sense - and in a non-emergency routine deletion) and from the removal model (node powered off and moved to another location to be joined to a new mesh). The former needs protocol elements and perhaps a discussion of LDevID revocation. The latter needs a discussion of minimum UIs on the node (e.g. a reset switch, a magic control cert, etc - doesn't need specification, but does need a "you need to think about this" paragraph). 9) Steps 12 and 13 are specified to use the JOIN key rather than having the joining node (which should at this point have its credentials) join the network as a full member. Why? 10) Continuing my comments from (5) above, there's no need to include address assignment in this flow. That should be deferred until the node can register with its own LDevID (or its own copy of the master key). 11) There's no need to set up a DTLS connection between the JCE and the joining node. You're either passing back an LDevID, or you're passing back a key. The former is just a signed blob that can be passed along from the JCE to the JA and thence to the joining node. The latter is an encrypted blob (using something like ECIES using the IDevID of the joining node) that can be passed along from the JCE to the JA and to the joining node where it can then be decrypted - it might be signed by the JCE. Unless there's a real need for setting up a security association between the JCE and the joining node, avoid it. 12) Have I mentioned how much I hate master keys? 13) You have (page 7) > If the > IDevID is less than 64 bits, then it is possible that it could be > placed into the EUI-64 option of the ARO which confuses me. An IDevID is an X509 certificate and in no way is less than 64 bits. I hope this helps. Mike From nobody Tue Jul 22 08:35:58 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0697D1A0146 for <6tisch-security@ietfa.amsl.com>; Tue, 22 Jul 2014 08:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYeLVEZJgiQY for <6tisch-security@ietfa.amsl.com>; Tue, 22 Jul 2014 08:35:55 -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 B8B4E1A0041 for <6tisch-security@ietf.org>; Tue, 22 Jul 2014 08:35:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C26E2002D; Tue, 22 Jul 2014 11:37:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EE43D63B0E; Tue, 22 Jul 2014 11:35:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D843D63B0A; Tue, 22 Jul 2014 11:35:54 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <29041.1406040862@sandelman.ca> References: <11d780c34b70259712554da027761f52@xs4all.nl> <16479.1405981140@sandelman.ca> <83de38e02402485b5de024d46040e920@xs4all.nl> <29041.1406040862@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Cc61-WmeLJAVcK4MJcb4hM4h8uc Cc: consultancy@vanderstok.org Subject: Re: [6tisch-security] 6tisch bootstrap X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:35:57 -0000 --=-=-= Peter agreed to my sharing this. peter van der Stok wrote: > My suggestion is to make the protocol less RPL specific. There are > stacks with other routing protocols, and it would be a pity if your > solution could not be used outside tisch. I think that it could be used... > ND supports the concept of default router, and you could use that to > propagate the packet from default router to default router to 6LBR. Or > work on a way that the routing can be present during the ND process as > Pascal suggests for RPL and seems to have implemented for smartmeshIP. The solution depends upon 6lowpanND, and to a lesser (and optional) extent, Pascal's EARO message. The Joining Node does no actual RPL actions until after it has been blessed by the JCE. The provisioning assistant has to know which mesh protocol it is running, but the activity to send the DAOs is just standard RPL, not specific for the join process, I think. The join assistant can do whatever protocol is appropriate for the environment. Maybe some other protocol would require some additional support from the JCE, but no support from the JCE is required if it isn't also the 6LBR. > Michael Richardson schreef op 2014-07-22 00:19: >> peter van der Stok wrote: > I like the work, we >> were thinking in the same direction. Small > question. For the TLS >> connection from JCE to joining node you need a > routing table from >> 6lbr to joining node, but that one does not exist at > that moment, I >> think, >> >> Yes. That's why the Join Assistant has to emit a DAO about the new >> joining node. Alternatives include: 1) some kind of tunnel -- >> requires state on the Join Assistant, and on the 6LBR, code which >> never gets used again. 2) some kind of proxy -- ditto. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU86E2ICLcPvd0N1lAQLvWwf9ENcFsndaHAeh01D9uZtSPsl4kQsvUi0A VZQsy6Q5jt+r5gfy81IxkksPOYmKxcqwIFdeUwwdXu7EtLGIHGnCoEjYbEHm83Xs plTCrP2drXCI0SGvU+H6eTAypswDVFwnBpo6X32tziN3bwLVU+t6e93YYpGmQQAS Qtosxtp5V2Uu8fElPRSJpWon6u+e4LuETcVBOaVD5odxiVSvmaYkadjwAPFYFWSc fpkQtrLWl8UVIw0wlVMC7MjIWzBs2GwuncIydmtbxaaNJO8Ph2PNilrb7m210agd gmnlbLRjbd4BhN1Sxxk56/Y7h4T6fL86UC0dOudLM4fw/vfgDQW37g== =AtPU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 23 06:04:28 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231E51ABB20 for <6tisch-security@ietfa.amsl.com>; Wed, 23 Jul 2014 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22a8SKn0yN0T for <6tisch-security@ietfa.amsl.com>; Wed, 23 Jul 2014 06:04:25 -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 D42131A0AD5 for <6tisch-security@ietf.org>; Wed, 23 Jul 2014 06:04:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4FB6420012; Wed, 23 Jul 2014 09:06:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0CA6F63B0E; Wed, 23 Jul 2014 09:04:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E811D63B0A; Wed, 23 Jul 2014 09:04:23 -0400 (EDT) From: Michael Richardson To: Michael StJohns In-Reply-To: <53C1BF0E.3000303@nthpermutation.com> References: <53C1BF0E.3000303@nthpermutation.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/CA5LUxgRLQmjYg4AgmD702loNxo Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] Comments on draft-richardson-6tisch-security-6top X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:04:27 -0000 --=-=-= Michael StJohns wrote: > Comments: > 1) The document has more than its share of unexplained acronyms. While > I appreciate that this references back to other WG documents, it makes > this document somewhat difficult to evaluate on its own merits. Of okay. I will import more definitions that I need. Were there particular TLAs that gave you pause? > special note, is the use of IDevID (and an apparently incorrect > reference to DevID) which is an 802.1AR term. The general rule for the > IETF document series is that it's OK to point to other RFC's for > general acronyms, but to explain in sufficient detail any acronyms that > come from other document series. Sure, I can do that. > 2) There needs to be a discussion of pre-conditions. For example, > where exactly did the IDevID come from? If manufactured in, what are > the assumptions about the provisioning of the roots of trust > (manufactured and local) to the various nodes in the system? okay. > 3) It's unclear why you're proposing specialized "join assistant" > nodes. If you intend for this to be a distinct role, then a discussion > of how that role is assigned, and why it needs to be distinct from the > "non-leaf node with routing" role is necessary. My personal opinion is > that making them distinct is a bad idea as it adds to the complexity of > provisioning a mesh and probably requires real world geography and > topology information to be sure you cover all the places that joins > could happen. (E.g. what happens if a joining node can only see a > non-join assistant node?) The goal was not to have distinct join assistant nodes, but rather that this is a role that a node may be told to take on, provided it has the ability (code), and also power budget to be able to do so. Further, a goal was that any additional things that the Join Assistant would not be uniquely for Join Operation. So a Join Assistant needs to: 1) send enhanced BEACONs for the JOIN network: it would do so for the production network too. 2) send RAs for the Join network: it would do so for the production network too. 3) send DAR/DAC upstream for leaf nodes that do not participate as routers. 4) send DAO messages upstream for leaf nodes. 5) restrict (but forward) traffic from the JOIN network to timeslots allocated for this purpose. 6) restrict (but forward) traffic from the JOIN network to only for the address of the JCE. So, only point 6 is particularly unique to being a join assistant. Point 5 may be already be there; in general traffic coming in on certain timeslots will often only be forwarded in designated other timeslots (GMPLS-like), so this is just extended it slightly to recognize which encryption key was used. > 4) In section (3) you refer to a locally significant DevID - I assume > you mean an 802.1AR LDevId? Or something else? Yes, thanks for catching this. > 5) DOS attacks on the "join assistant" are probably less problematic > than DOS attacks on the mesh as a whole. Why not have the join > assistant verify the cert chain of the joiner (to include a signed > challenge for timeliness and proof of possession of the related private > key)? Then have the JA send just the mac address of the joiner to ask > if that MAC is a legitimate joiner. That would imply that the join assistant has the right trust anchors, as well as the CPU, RAM and energy to verify the new node, and can do this during some kind of denial of service. We also can't expect the Join Assistant to know which joiners belong on which network, nor can we expect the joiner to be able to verify that this is a legitimate join assistant. > If you get a yes answer back, the > JA sends the rest of the joiner cert chain upstream and gets back the > LDevID which it then gives to the joiner. The Joiner now uses the > LDevID as its credential to join the network. How would the joiner know that this is the right network? That's why this step has been moved to being yet-another-parameter to be provisioned during the 6top transaction. > It's possible to DOS any > given node with join attempts, but its pretty easy for such a node to > throttle them (handle not more than one distinct MAC per 5 minutes > unless you're in mesh building mode), but since the JA never sends up > unauthenticated IDevIDs and the associated cruft, you don't translate > that DOS on the JA to a DOS on the mesh. Since the MAC is tied to the > IDevID you have a pretty good protection against MAC forgery doing it > that way. Whether or not the MAC is related to the IDevID is a good question which we have not yet resolved. It seems like it is good idea; but there may also be (privacy) reasons why it would be better to make them different. Yet the IDevID should ideally have OUI-like vendor/unique-number properties. > 6) You need to handle the case where there are two legitimate meshes > within earshot of each other. There needs to be a mechanism for a node > to figure out which mesh it needs to belong to. The specific case of a > legitimate mesh next to an illegitimate attacker suggests that you need > a way for the joining node to be pre-provisioned with the root of trust > for the LDevIDs for a particular system. E.g. as much as you need to > authenticate the joiner to the mesh, you need to be able to > authenticate the mesh to the joiner. Yes, this is a legitimate concern; we have been told of real examples from the oil refinery industry where different mesh networks legitimately overlap, and also may overlap with a legitimate mesh network at the 7/11 just outside the gate. The zerotouch process is to avoid any such pre-provisioning: the legitimate mesh will possess a certificate rooted in the vendor, assigning ownership of that particular joining node to the operator of that mesh. I'm wondering how to best capture my email: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 into the draft. I have recently (IETF90 reception...) learnt that DOCSIS 3.0 does something like this. > 7) A discussion of permanent storage would be helpful - e.g. what's on > the node at manufacture, what's on the node after enrollment, and how > much of that has to stay on the node after a power cycle. okay, I've opened ticket: https://tools.ietf.org/wg/6tisch/trac/ticket/20 > 8) A discussion of disenrollment, both from the ejection model > (e.g. controller says that the node is no longer welcome both in an > emergency - this node is compromised sense - and in a non-emergency > routine deletion) and from the removal model (node powered off and > moved to another location to be joined to a new mesh). The former > needs protocol elements and perhaps a discussion of LDevID revocation. > The latter needs a discussion of minimum UIs on the node (e.g. a reset > switch, a magic control cert, etc - doesn't need specification, but > does need a "you need to think about this" paragraph). I've opened ticket: https://tools.ietf.org/wg/6tisch/trac/ticket/21 > 9) Steps 12 and 13 are specified to use the JOIN key rather than having > the joining node (which should at this point have its credentials) join > the network as a full member. Why? Step (2) and (3) probably confused you. Wow. re-reading, yeah, it totally messed you up. This isn't a certificate request for the joining node, it's the joining node asking for information about the network it is joining from a nearby node. The idea is to help the joining node decide that "this isn't the right network" earlier. I think that I will rename them, but I'm not sure exactly what to rename it to yet. This is what I changed: dooku-[/corp/ietf/richardson/6tisch-security] mcr 9394 %git add -p diff --git a/draft-richardson-6tisch-security-6top.xml b/draft-richardson-6tisch-security-6top.xml index 3e790b1..28dc45a 100644 --- a/draft-richardson-6tisch-security-6top.xml +++ b/draft-richardson-6tisch-security-6top.xml @@ -485,21 +485,23 @@ packets, and should contain a prefix appropriate for join traffic. -
- Step (4) will involve doing a public key encryption to node - performing the authorization management role. In order to do this, - the new node needs to know the public key of the manager, and so in - this step it requests that certificate from the neighbour that that - it received the beacon from. - This step is optional, and it's benefit has not been demonstrated by - a real world use case, but has been retained for now +
+ At step 10, the JCE will need to present a certificate chain + anchored at a trusted CA built into the joining node. + It has been speculated that a significant amount of traffic could + be avoided at step (10) if the common parts of the certificate chains + could be cached in the join assistant. + + + This optional step involves the joining node asking for certificates + from the join assistant. +
-
- the proxy neighbour sends the key in one or more messages, - along - with the address of the authorizing server. The address of the - authorization server could be an attribute of the certificate that - is received. +
+ the proxy neighbour sends requested cached certificates to the + joining node +
So steps 12/13 are before the joining node has it's credential, it's the step where it gets it's credentials. > 12) Have I mentioned how much I hate master keys? Yes, me too. > 13) You have (page 7) >> If the IDevID is less than 64 bits, then it is possible that it could >> be placed into the EUI-64 option of the ARO > which confuses me. An IDevID is an X509 certificate and in no way is > less than 64 bits. Good point. The intention was to actually put the serialNumber (802.1AR 7.2.2) which is inside the IDevID. That serialNumber needs to be the same as the EUI-64. No size is specified in 802.1AR, but we would like to get it into the EUI/OUI space of the EARO of draft-thubert-6lowpan-backbone-router. Posting a -02 now... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8+y1YCLcPvd0N1lAQJuPAf9GrG5zk2Mj48v6b5oIV9DF44Iw7eotT2S xsDbX8Uw44cJOqFl7tI7zjxaXOpHAg437ADzOcd1Ornw+DY36Zbd1VzUAZpKDWA1 TadjkAP07ITomZt1wyF2kp57QzpbDLLPBngieq8duw+XsG7Cxg1vPL53adTtF4f9 MOf6e67aI95RwNeDsaaFh1Wlp12BMYnh+7snEbpjJhFmkWo0QdkiX8Y8Y5IceajS 556TcW4S163TDPuS30iyrnA5ovYfypkiTmsozMlR1NzVawjSMOkJs/XCDfAQGO+P 3udduraJwDgzDep0Rp48/GX1Kt6XJbczg8EUxXj0/yTMIJGMPhKVYw== =jrg2 -----END PGP SIGNATURE----- --=-=-=--