From nobody Mon Dec 1 08:55: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 1BEC41A6FEC for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 08:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.899, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhbOA3y_vW46 for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 08:55:54 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4FC1A6FC6 for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 08:55:53 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so9767182iec.29 for <6tisch-security@ietf.org>; Mon, 01 Dec 2014 08:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=EBj9hOvMSewFG6cNp2KgOzgW4FqX9niC8hSEBnGfHFE=; b=cDCTFWHUj2k4Wvjz8Y9Q6M6bk4lTeWwsNl/klQscrFvGdKnNg5DkypbZoniTuOyERZ DPCsfEezkhSHW8MSWSRUipvxgRCUiLNivQFb12AL6oZtckHk0h02ZOSOnnftKycxNc0C gj069iwATW4uDVbZU9a+W/n8Ka28mueEDvXrG5hQ7E1JU5v3JKEOTDLrUXlwiLPzzkaY 7M9rdM4p7jepKic871+DeN3XeTT7gRjXZbQEOKzdD11GEjlAoxgyQdIYM5MI2+RtyzcB SsFFd2IwDPwmJBgLUr19bRCRRZzyAimr+PjDcD/dhJKbtCWNdItyUuNizn8PKhbIIo/5 +Spg== X-Received: by 10.107.30.12 with SMTP id e12mr32450503ioe.9.1417452952876; Mon, 01 Dec 2014 08:55:52 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id cy6sm10506202igc.21.2014.12.01.08.55.52 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 08:55:52 -0800 (PST) Message-ID: <547C9D91.4010400@gmail.com> Date: Mon, 01 Dec 2014 11:55:45 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: 6tisch-security@ietf.org References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> In-Reply-To: <54789C85.1080505@gmail.com> Content-Type: multipart/alternative; boundary="------------010607090809030000080107" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/vaixvCnOl1VlA8C5gKq_hcWlhPk Subject: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:55:56 -0000 This is a multi-part message in MIME format. --------------010607090809030000080107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Proposed agenda: 0) Agenda bashing 1) Join protocol details a) desired properties b) realizable properties 2) Next steps: a) consensus on 1#a and 1#b b) form tiger team to work out details - project phases - communication of sub-results c) what to squeeze into architecture draft, etc. I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call. Best regards, Rene On 11/28/2014 11:02 AM, Rene Struik wrote: > > Dear colleagues: > > > I have set up a conf call for Tuesday December 2, 2014 at a time that > tries and accommodate people in different time zones to the largest > extent possible, without trying to discriminate against various parts > of the world. > > > Please see dial-in information below. > > > Agenda to follow Monday around noon. > > > Looking forward to a collaborative meeting, in good spirit. > > > Best regards, Rene > > == > > > 1.Please join my meeting. > > https://global.gotomeeting.com/join/594299061 > > 2.Use your microphone and speakers (VoIP) - a headset is > recommended.Or, call in using your telephone. > > Dial +1 (647) 497-9351 > > Access Code: 594-299-061 > > Audio PIN: Shown after joining the meeting > > Meeting Password: collaborate > > Meeting ID: 594-299-061 > > GoToMeeting® > > Online Meetings Made Easy® > > Not at your computer? Click the link to join this meeting from your > iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting app. > > > > > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should > allow people to have their private time in the 12am-6am time window. > {Other groups do a much better job at this...} > > > On 11/28/2014 10:39 AM, Michael Richardson wrote: >> Subir Das wrote: >> > Thanks for arranging the calls. It would be good to accommodate Asian time >> > zone for broader participation. I would suggest choosing a time that is >> >> I'm happy to do this at another time; the original choice of 11am Eastern was >> to accomodate Pacific Time Zone People who couldn't meet before 8am. >> >> From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >> or >> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >> >> I am also happy to alternate. >> Shall I put up a doodle poll? >> >> >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------010607090809030000080107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

==


1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


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

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

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

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




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



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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------010607090809030000080107-- From nobody Mon Dec 1 10:37:19 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA081A6F11 for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 10:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Omdx7kJdxX for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 10:37: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 576C51A6F03 for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 10:37:17 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3761D2002A; Mon, 1 Dec 2014 13:40:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7CDC8637F5; Mon, 1 Dec 2014 13:37:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 63241637F4; Mon, 1 Dec 2014 13:37:16 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <547C9D91.4010400@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/NbAh2eOH3BnSrJn4bxrWaoyHpKM Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:37:18 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: > 0) Agenda bashing > 1) Join protocol details > a) desired properties > b) realizable properties Please, where is the text and/or slides that go with this discussion? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVHy1WYCLcPvd0N1lAQLPkwgApP1bafAdytiABzZISjVfuNYnaiaR7NBR lseRWo/fSgvd+MOB/qhEvZuKPcaYp+eSrkGLgSpWpHXxcAkbKFl/yTXk6HTOO9iU ay+6TPlz5V2DAHTX+TXGky+hN+htsziVuatN+1qKQ6U6hwv7IlBZQkJRfvIMAdLJ zTbqrBbzWdbH74N+knldnYxXMTCkT2XQR4L3kpuJSFD1kWLJCE0X0s4RZ+vP5xzJ 2PX0YUwSlHYDucgiUY9OvFJmtuTsf6ZSsB7kE3ADm9d3ykAIPjE4prAMjkD2CIDW DRL6DfUhoQ5QvPxfpWv85dFX8eofIFSYL/tc7nEHUxs5VkfqBUfjGQ== =tvEL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 1 17:07:57 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB461AC42D for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 17:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJOl0MCsrVGk for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 17:07:54 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388B01AC42A for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 17:07:54 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so10834466ier.28 for <6tisch-security@ietf.org>; Mon, 01 Dec 2014 17:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sQqSz+wDtxiXoCDpOZTFjiZZy6AYfuLGX91iPewfM9g=; b=YM0vekoT9YZmyH5q0+i02+TMx0rEW2nFJ+m/1Ek1wcGsF8joU8zojPmUpN63BSZXiX kGzdrTgh9m/sbspRbNiFe6etwaORsySTFXK6hvbwmQt0HXLQqsxW0cEAlWEmxRs2gKHP WYaHLaAOfdpIkkdG274w9t6L1knoRP6FUEJfzRM2vVFNRI+P6dxX+J4LAp7aBijN1pYO YEi485nBHHgKfFalF6Clu4vaGp4CdDWXIv5h1dcZVv9jB2aceKd8wmvIvE3IpRFN2KAk 3audNDYexBe2hK5oYveLq+FNQ1Hwhxknb3f6PFqHQE2YITfDfVaCQfX4eRNQS1BpeiDk m5iA== X-Received: by 10.107.40.16 with SMTP id o16mr9526062ioo.26.1417482473249; Mon, 01 Dec 2014 17:07:53 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id a1sm10379457ioa.27.2014.12.01.17.07.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Dec 2014 17:07:52 -0800 (PST) Message-ID: <547D10E8.6040308@gmail.com> Date: Mon, 01 Dec 2014 20:07:52 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <6015.1417459036@sandelman.ca> In-Reply-To: <6015.1417459036@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/guMRfepx1SDedPpqWrcpQ4HqQ70 Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 01:07:56 -0000 Hi Michael: As already said, I have material to be discussed during the 9am EST call, so as to make progress on the suggested agenda items. As I am sure you understand, the reason to have a conference call is that often times actual conversations are more effective in making technical progress than having a long sequence of emails. I am looking forward having the conf call tomorrow being an example illustrating this point. I also welcome technical points brought up by an as wide set of people, where each gets the floor to bring their insight across. Speak with you tomorrow. Best regards, Rene On 12/1/2014 1:37 PM, Michael Richardson wrote: > Rene Struik wrote: > > 0) Agenda bashing > > > 1) Join protocol details > > > a) desired properties > > b) realizable properties > > Please, where is the text and/or slides that go with this discussion? > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Mon Dec 1 18:59:34 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFAC1A0089 for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 18:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV7_Hap-1FJB for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 18:59:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2961A007C for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 18:59:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 32FA22009E for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 22:02:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3FDA8637F5; Mon, 1 Dec 2014 21:59:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 28528637EA for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 21:59:29 -0500 (EST) From: Michael Richardson 1From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <547D10E8.6040308@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <6015.1417459036@sandelman.ca> <547D10E8.6040308@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/YhMLbxmlykpTDs6_cvQmW0L1LBg Subject: Re: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 02:59:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: >> > 1) Join protocol details >>=20 >> > a) desired properties Here are the requirements which the 6tisch-security group was given. True, they were communicated orally, and perhaps my attempt to capture them was poor, in which case, I hope that some people will post adjustments. I pull the following text out, as a kind of executive summary: The ultimate goal of the join protocol is to provide a new node with a locally significant security credentials so that it is able to take part in the network directly. =3D=3D=3D=3D Intro: A challenging part with constructing an LLN with nodes from multiple vendors is providing enough security context to each node such that the network communication can form and remain secure. Most LLNs are small and have no operator interfaces at all, and even if they have debug interfaces (such as JTAG) with personnel trained to use that, doing any kind of interaction involving electrical connections in a dirty environment such as a factory or refinery is hopeless. It is necessary to have a way to introduce new nodes into a 6tisch network that does not involve any direct manipulation of the nodes themselves. This act has been called "zero-touch" provisioning, and it does not occur by chance, but requires coordination between the manufacturer of the node, the service operator running the LLN, and the installers actually taking the devices out of the shipping boxes. ... 3.2. Join Protocol deliverables This section works from the ultimate goal, and goes backwards to prerequisite actions. (Section 6 presents the protocol from beginning to end order) The ultimate goal of the join protocol is to provide a new node with a locally significant security credentials so that it is able to take part in the network directly. The credentials may vary by deployment. They can be one of: 1) a network-wide shared symmetric key (this is the production network key, or MasterKey) 2) a locally significant (one-level only) 802.11AR type LDevID certificate (which allows it to negotiate a pair-wise keys) One of these two items is delivered by JCE to the joining node using the 6top protocol. That is, the JCE provisions using a secure "northbound" interface. The authentication of this interface the subject of the Join Protocol as explained below. The above credential are used for authentication to generate per-peer L2, using a key exchange protocol. The choice of key exchange protocol, and what kind of link and multicast keying needs to be done is also provisioned by the JCE. There are a number of options for doing this, such as: 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] (IMPORTANT, a good option. Uses certificates from common CA) 2) work in 802.15.9 (uses certificates from common CA) 3) Security Framework and Key Management Protocol Requirements for 6TiSCH [I-D.ohba-6tisch-security] (this document provides the phase 0 required, using the network-wide shared key) 4) Layer-2 security aspects for the IEEE 802.15.4e MAC [I-D.piro-6tisch-security-issues]: the MasterKey is used to derive per-peer L2 keys Per-peer L2 keying is critical when doing peer-2-peer schedule negotiation over 15.4 Information Elements. Therefore a network-wide layer-2 key is inappropriate for the self-organizing networks, and a protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. For networks where there is a PCE present and it will do all schedule computation, then the only trust relationship necessary is between the individual node and the PCE, and it MAY be acceptable to have a network-wide L2 key derived in ways such as [I-D.piro-6tisch-security-issues] describes in section ?. The trust relationship between the PCE and the joining node flows from the LDevID certificate loaded by the JCE. When the PCE and JCE are co- located, the existing 6top/DTLS security association could be reused. 3.3. Join Protocol connection setup The intermediate level goal of the join protocol is to enable a Join Coordination Entity (JCE) to reach out to the new node, and install the credentials detailed above. The JCE must authenticate itself to the joining node so that the joining node will know that it has joined the correct network, and the joining node must authenticate itself to the JCE so that the JCE will know that this node belongs in the network. This two way authentication occurs in the 6top/CoAP/ DTLS session that is established between the JCE and the joining node. [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] explains how to access that information model using CoAP. This information model will include security attributes for the network. The JCE would therefore reach out to the joining node and simply provision appropriate security properties into the joining node, much like the PCE will provision schedules. This 6top-based secure join protocol has defined a push model for security provisioning by the JCE. This has been done for three reasons: 1) 6tisch nodes already have to have a 6top CoAP server for schedule provising 2) this permits the JCE to manage how many nodes are trying to join at the same time, and limit how much bandwidth/energy is used for the join operation, and also for the JCE to prioritize the join order for nodes. 3) making the JCE initiate the DTLS connection significantly simplies the certificate chains that must be exchanged as the most constrained side (the joining node) provides it's credentials first, and lets the less constrained JCE figure out what kind of certificate chain will be required to authenticate the JCE to the joining node. In EAP-TLS/802.1x situations, the TLS channel is created in the opposite direction, and it would have to complete in a tentative way, and then further authorization occur in-band. 3.4. End to End considerations for Join Protocol In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node, there needs to be end-to-end IPv6 connectivity between those two entities. The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node. .. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVH0rDoCLcPvd0N1lAQJznQf/euRdGdEibgjuLd1RcfblTV6V+re4KX6c LXINRKXmjtV7oOWbYWmilI/gOb+W4jLMOhJg6Gj5qpyBue5clQ9wkvCtoQSdLPdW rdkQ9iV1y7K3SUXnPOwJjbKKnI6ESb6PEH1haZwl5V5C4ROdqMZq3yPzVAg6NRFb 7g+Q/unYE09Fw1idTEp6ZQzEOFPOO7wSaBjJ4ar4bpAfRECT8n+68HVmK1+dO9aP 132ZZ1/AIqQJK+UU2IOayBF5b7hTT2G/jh5VgHCOzF05IViu760uoO23nzssB0Kh GPolg+rv1AF2Q7MeuxrfpaWC3SohNzTO4RL9M0/gge8cIv+anZZJfw== =ZdGP -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 1 19:04: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 5247F1A0099 for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 19:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZgTLO6kaT1R for <6tisch-security@ietfa.amsl.com>; Mon, 1 Dec 2014 19:03:58 -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 5912F1A0083 for <6tisch-security@ietf.org>; Mon, 1 Dec 2014 19:03:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 88AED2002A; Mon, 1 Dec 2014 22:07:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 9C2A8637F5; Mon, 1 Dec 2014 22:03:57 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 80D9B637EA; Mon, 1 Dec 2014 22:03:57 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <547D10E8.6040308@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <6015.1417459036@sandelman.ca> <547D10E8.6040308@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/lb8XdcomOQgkY-V3fkvyl2YFxXg Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 03:03:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: > As already said, I have material to be discussed during the 9am EST c= all, so > as to make progress on the suggested agenda items. I'm looking forward to receiving the material in a form that I can open=20 prior to the call.=20=20 gotomeeting fails on most platforms, so I will be on the telecon only. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVH0sGoCLcPvd0N1lAQLvmQgAsoTdeyMml/HgbxkzmRGOh5hvyDV14ipD 1UVzpDKdrqDrFkripEEDjObpd/oyjIvn6Y7IWxW4OTftzbTTMGOr7s847dkkja2u 3XkGxst3jqWkiga1E3gCoJjG7/gKqqBmRNHmLZ/vdNk5065O8kLSkLGaDF7FI8Ym rp406JhHzi9BQXSfczH252/rlnyn0KlqYeWMVtSwKz3rPFMyEjvvXaUx3XhBfvj3 THvEojLv1PRER8ZWkiuG31gnJGPnhBO+thKP2vvhkLJartYcn32GDuK4RLY33B9D l8ty35sPzyp5ZcZrPgeik3C/QX2X1A1zM/k8g00VAkvujdVfIeAKYg== =qA8b -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 2 05:56:36 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6DF1A1BAF for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 05:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.899, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uflxZh7EXtKT for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 05:56:31 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2561A1B44 for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 05:56:30 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so15970586iga.9 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 05:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=59saVOR430B6snB5SyQNfJD0KJ+NGgjHecr6rvQYNRc=; b=VTcK2InyuxAN/d97Hf/jvCZRnCz7+wFEhEnvPHPgvRIwkoETdTGBGMwfroX1yN67Xu Eh2bL729iZWZhJYK7tJoB+eFeD7aF8EGDU0z+HWdU2zzf61Vncz7YZR8Uxl9NIqgDsxR CjepUHphEHJ3YWSr9DzFAc+uOPXy7XiFChNIPl5/cv76GstPTH7KMbA1F+VultNtCgIo InC/+VutRbpD1EdDWAQKb7Y0zoLHlKmpLvT1S7QZg2H5E0FMpgNlEXldZnku8Zbzjvub EjR5v1X/+SMRLaQ/2Zwj59BP6Jmx9BqeUkYvzsi409AgC/GY5GgkMs1mpVAqmEuzbqeW kAhQ== X-Received: by 10.50.50.196 with SMTP id e4mr43588516igo.26.1417528589433; Tue, 02 Dec 2014 05:56:29 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id 12sm8417322ios.32.2014.12.02.05.56.27 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 05:56:27 -0800 (PST) Message-ID: <547DC509.8070506@gmail.com> Date: Tue, 02 Dec 2014 08:56:25 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: 6tisch-security@ietf.org References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> In-Reply-To: <547C9D91.4010400@gmail.com> Content-Type: multipart/mixed; boundary="------------040902030708000800070508" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/SXLTjIXxWlO-eosJdnTf78XHgyI Subject: [6tisch-security] (slides for participants) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 13:56:34 -0000 This is a multi-part message in MIME format. --------------040902030708000800070508 Content-Type: multipart/alternative; boundary="------------020400090807040202010605" --------------020400090807040202010605 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues: For those of you who somehow seem to have display problems with GoToMeetings, please find attached slides to be discussed during the call. This focuses on MAC behavior and Routing aspects of the join process. It is my strong desire that the group as a whole gains more understanding of how the MAC actually works and also considerations that may trigger routing questions, mostly from a security perspective. The slides are pp. 17-25 (and the desired/realizable properties of the join process). Agenda item 2) will be discussed without slide hand-out. Slides will be discussed on the call. Rene On 12/1/2014 11:55 AM, Rene Struik wrote: > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and 2), to be > discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: >> >> Dear colleagues: >> >> >> I have set up a conf call for Tuesday December 2, 2014 at a time that >> tries and accommodate people in different time zones to the largest >> extent possible, without trying to discriminate against various parts >> of the world. >> >> >> Please see dial-in information below. >> >> >> Agenda to follow Monday around noon. >> >> >> Looking forward to a collaborative meeting, in good spirit. >> >> >> Best regards, Rene >> >> == >> >> >> 1.Please join my meeting. >> >> https://global.gotomeeting.com/join/594299061 >> >> 2.Use your microphone and speakers (VoIP) - a headset is >> recommended.Or, call in using your telephone. >> >> Dial +1 (647) 497-9351 >> >> Access Code: 594-299-061 >> >> Audio PIN: Shown after joining the meeting >> >> Meeting Password: collaborate >> >> Meeting ID: 594-299-061 >> >> GoToMeeting® >> >> Online Meetings Made Easy® >> >> Not at your computer? Click the link to join this meeting from your >> iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting >> app. >> >> >> >> >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should >> allow people to have their private time in the 12am-6am time window. >> {Other groups do a much better job at this...} >> >> >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >>> Subir Das wrote: >>> > Thanks for arranging the calls. It would be good to accommodate Asian time >>> > zone for broader participation. I would suggest choosing a time that is >>> >>> I'm happy to do this at another time; the original choice of 11am Eastern was >>> to accomodate Pacific Time Zone People who couldn't meet before 8am. >>> >>> From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >>> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >>> or >>> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >>> >>> I am also happy to alternate. >>> Shall I put up a doodle poll? >>> >>> >>> >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020400090807040202010605 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear colleagues:

For those of you who somehow seem to have display problems with GoToMeetings, please find attached slides to be discussed during the call. This focuses on MAC behavior and Routing aspects of the join process. It is my strong desire that the group as a whole gains more understanding of how the MAC actually works and also considerations that may trigger routing questions, mostly from a security perspective.

The slides are pp. 17-25 (and the desired/realizable properties of the join process).

Agenda item 2) will be discussed without slide hand-out.

Slides will be discussed on the call.

Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:
Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

==


1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


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

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

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

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




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



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


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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020400090807040202010605-- --------------040902030708000800070508 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="6TiSCH Security - Security Architecture for Join Process (Rene Struik, December 1, 2014).pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="6TiSCH Security - Security Architecture for Join Process (Re"; filename*1="ne Struik, December 1, 2014).pptx" UEsDBBQABgAIAAAAIQBHdResbAIAAH0VAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMWNuOmzAQfa/Uf0C8VsGBttttFbIPvTz1 slK3H+DCJHELtoWddPP3HWBJHUS5rIO8L0GG+MyBmTMXr27u88w7QKGY4LEfBkvfA56IlPFt 7P+4+7S49j2lKU9pJjjE/hGUf7N+/mx1d5SgPNzNVezvtJbvCFHJDnKqAiGB45ONKHKqcVls iaTJb7oFEi2XVyQRXAPXC11i+OvVNyRQsBS8W1rorzRHO0RKTVSGN1V9eR0gou+9r7eW1mOf SpmxhGrkTg48bdldiM2GJZCKZJ+jtUAWoPBa/T3Pggr8RQlKxjG4cs4gfDsrhQ+woftMex/v 0Tt1QEi+bX1zlpduLO8PfbYvVGkMrNp99SKchX+NPcWVL2fhMYXBK+cMwjfuKVw7oVAmgttC SHVp6yfgoUjQmCeBVL+RNYkKZoJF++AfZdFM3vPofuidTQb2n9m2fITuK1jovoRF7hNf5MYR hubt5XCmwI66/UtCd+GuHmDl7thTQKZaxX6gwXpo6gLcWXVVasekalTZYaG/gxtoxUz9WedM Ewx7QXMZ5JTx5iXGdKahfUI17T+mNQ2fgKrcZ9jIjSO40KCaZtdY2Ku8FRYG9qj4/EyPYq8f GvB6cXFOVY2tsfs44RBWdVwEM4q1eKGcT1JIFxKbOCg0g1PSGaXXpTWDlmMmj5LhPH7o80B7 ng6fgF7dOyJy4whNf2bwXR8zuPgMYkD3hcNJkMleaZFbK6KGeaQi3U+ibgZRc0CZ92jnf3lx hyd7WCOa6nW2vLg0ztD7grPMVQcGf2YZ0k/AfQz+yUMUMF0cTWOc4O4OTZDq8HT9FwAA//8D AFBLAwQUAAYACAAAACEAR78a0BMBAAB1AwAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKzTS0vEMBAA4Lvgfwi5b9NdH4hsuhcR9iZSf8CYTNto 8yCZyu6/NxR8FGoV3GMyj3zJkO3uYHv2hjEZ7yRfFyVn6JTXxrWSP9X3qxvOEoHT0HuHkh8x 8V11frZ9xB4oF6XOhMRyF5ck74jCrRBJdWghFT6gy5HGRwuUl7EVAdQrtCg2ZXkt4vcevJr0 ZHstedzrC87qY8gn/6e3sEiggUAoH3EVYpZFMvkurIbYIkmuvXrI22nMKLKai3nQ5rQg6gb7 7MD0M5TPWPESsP0JtP47yDeNUXjn1WDR0cwQxDTjyxQCiRAx5bJx7EsvdHVKkBoSefvLyMac JdLlKUl4IHQa9TIKQvgQiclnqd4BAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KK ZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsE Z/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9 qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U 26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTkueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0J rRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5o xlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGv sTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsD BBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEwLnht bC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O 0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7f SrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTz mwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAY1wj tMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMS54bWwucmVsc4SPwWrDMBBE 74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDI m2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5 yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhop a5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0Ig kFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn 4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVA u2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c 9g8AAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlNS54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/ r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8 uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/P DsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAG AAgAAAAhAGNcI7TBAAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIueG1sLnJl bHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6z eFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZlo QZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWz s3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHOEj8FqwzAQRO+F/IPY eyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR81 3PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojm gSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvn rahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5g kda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oM XXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvV kK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD/ /wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTMueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6 nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8 a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Ayd g3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAA IQBjXCO0wQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOEj8Fq wzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yG WlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/O ENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxz wWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAg AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KK ZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsE Z/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9 qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U 26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTE0LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogt Ca0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+ aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbR r7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBL AwQUAAYACAAAACEASHqJReQBAACjEQAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1s LnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8 WMFu2zAMvQ/YPxi6LwrlNm2HOr0MA3oYMGzdB6g2kxhzJENSu+XvJyRZ5gTF20XgxQBpmHp4 JB8p3z/83g7VK4fYe9coms1Vxa71Xe/Wjfrx9PnDrapisq6zg3fcqB1H9bB8/+7+Gw825Y/i ph9jlaO42KhNSuNHrWO74a2NMz+yy29WPmxtymZY69G2P+2atZnPFzpMY6jlWczqsWtUeOzy +U+7MZ/8/9h+tepb/uTbly279MYROg59xzmgDWtOjdqb8eC9mWWkSr8NgmohFGQgDCkyCLJh FkJsmGvEhlROYEoMSXExR1zcCKFYIBBkhFAQQRhSZBBkw1wLsWGuEBtiOUEgSEoxCCqGydNN ZJjQHWLD3JWEMQaOX4MfYw56nGsnF0JRXri+2Jg4/IOxH68H53HIHgzYvVKVAguFypNzQcuR EIKqbq5KFgpYfkyNKqUuqiHJPg/8Pe2GvEmeKnbiREikJBUqKkmhIAjDiO0/eAEqupNu8k3D v6RLJTlzR31mQjUhKcWHgk9FBR/0Md2i7qmLqlrKd7zJXWpv6v0TZkRK0qCiSeUDpoOkqCDI hSmq7qA4DawLU3Rrdz5xvFSRiTPqiQFx1UUV5LXnXxfL2sn1t3X12a+V5R8AAAD//wMAUEsD BBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIyLnht bC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O 0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7f SrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTz mwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAY1wj tMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyMy54bWwucmVsc4SPwWrDMBBE 74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDI m2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5 yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhop a5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlMjQueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9C IJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW 5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRl QLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd 3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTI1LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S 6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZc Qjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0 /88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQU AAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyMS54bWwu cmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9 LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qx mWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sK xbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAGNcI7TB AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMjAueG1sLnJlbHOEj8FqwzAQRO+F /IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtg nR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZloQZYhki/OENKCucg0 qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQ cnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTE5LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQ U3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0Fufg ScNKDF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7 Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2 DwAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUxNS54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/ r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8 uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/P DsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAG AAgAAAAhAGNcI7TBAAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTYueG1sLnJl bHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+ONgR6nB3mzU7T/S6z eFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnIolA8a5hyjt9KsZlo QZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D4Aydg3ku5PObCsWz s3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wQAA ADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE3LnhtbC5yZWxzhI/BasMwEETvhfyD 2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O0/0us3hRYhe8hlpWIMibYJ0f Ndz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZaEGWIZIvzhDSgrnINKqI 5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0wzU8c8FiGilrkHJ7 562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGUxOC54bWwucmVsc4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNx PmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnD Sgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lTVX2qtGVAu2OK q9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1TbqN3c9g8A AP//AwBQSwMEFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3Ns aWRlMTMueG1sLnJlbHOEj8FqwzAQRO+F/IPYeyQ7h1KKZV9CIJBTcT5gkda2iC0JrRLqv6+O NgR6nB3mzU7T/S6zeFFiF7yGWlYgyJtgnR813PvL8QsEZ/QW5+BJw0oMXXv4aH5oxlxCPLnI olA8a5hyjt9KsZloQZYhki/OENKCucg0qojmgSOpU1V9qrRlQLtjiqvVkK62BtGvsTT/zw7D 4Aydg3ku5PObCsWzs3TDNTxzwWIaKWuQcnvnrahleR9U26jd3PYPAAD//wMAUEsDBBQABgAI AAAAIQD4f5nMiAMAAOkSAAAUAAAAcHB0L3ByZXNlbnRhdGlvbi54bWzsmMFu2zgQQO8L9B8E 3lNbFC3JRuQi7SJAgRQw6vQDGImOhdKSQNJZp8f0e4ot0AX2kr/JB+QXdkjT8cjMoQiQ0/om cTijmcfhDKnTd5uVjG6E0nXbFCR+OySRaMq2qpvrgny5PD/JSaQNbyou20YU5FZo8m765o/T btIpoUVjuAHVCMw0esILsjSmmwwGulyKFddv2040IFu0asUNvKrrQaX4X2B+JQd0OEwHK143 xOur39FvF4u6FH+25XoFn98aUUI6P/Sy7vTOWvc71nAUfZc0vxHz9ZUW5rxtjAY6ZApha1l9 4toI9bG60OZgJKqrgtCYZSxnw5iSSE3sCMyNyWB6OnhOvWmN0Acme2N7IzTzVnpy78YSVqld mwNLB6PIVu5tHczYB4UD/Fi50NIYEuQpJmotuJB2YpogcRKKUyRmoXiMxKNQzJA4DcRJhsQO VM+1ZITELva+GLs2Do3DPniKGyAcBp5g32K32D3zsHJIPwSXYK5xSC6JsX6ILunlWsguwWjj EB7r+RfSYxhPHOJjPf9Dfgz7R0N+DK8ODfkxzJ+G/BiOD7LwcH0YTkwa8mN4/WjIb4Tjo47f djPjTTL/FpWbgoxjxoZDUChvC5Lmo9y9mNsO6qculRAN23gP3T72atlwPE52avGQJizdJUIl FnwtzaXYmLm5lWJ6yicwNpsp//R5piLJbc0WzcmXuQ1/gKfIGxl3MIfLayjzEnLJyIKAiwso bWdu8IprAQWOT3RXvhcL/zQrTXTD3dytzZ70bAEF0Gk8N89LwVHr3lehbIeBmr/9Sivr6ryW 0hmw3UJ8kGr7LbPZVkuwjGfZEt9EluOCl8DyTNUcQimXXEGRtuGAi3wiOJrzeP/j8f5X9Hj/ 8+Hun4e7fx++f3+4+5tEXW3K5Tlf1RLWyG7eJysnMXXpzSelRoae/diWMUTncHvI1gd4pJb3 iquLgrBRZsM+0n9l+ha5p5/s6W+345H+a+e+Re7psz39OMni9Jj8r196LHOPf4Tw5zSH/nPM /tfOfsvc40/3+CnNIfkxfuiGl/xq/m13TNi3YsEvmvfqq71nQC+HVudfQRuO6NdwZZqtmxL6 nL2HuOb+v2mrlqiHmyG4GUv6ffUI9wVnFkvUw833cC1ZOMWiwnGE+wK4lqiHO0Zw01HWb4pH uC+Aa4m6nypA7+B+BJcz/Gdn+h8AAAD//wMAUEsDBBQABgAIAAAAIQCEWx85+gQAAOATAAAV AAAAcHB0L3NsaWRlcy9zbGlkZTEueG1s3FjNbttGEL4X6DsQvDaMRIqmfmAp8I+UixMblnLo cUUuRSLkkthdylKLXpyn6aFogRboxbc+ih/Ar9Bvl6Joyk7tJg4QBwbkJTk7s/PNN7Ozu/9q lSbGknIRZ2xo2i/bpkGZnwUxWwzNd7OJ1TMNIQkLSJIxOjTXVJivRt9/t58PRBIYmM3EgAzN SMp80GoJP6IpES+znDJ8CzOeEolHvmgFnFxAa5q0nHbba6UkZuZmPn/M/CwMY58eZ36RUiZL JZwmRGLlIopzUWnLH6Mt51RAjZ7dWNIInvnTJFD/54vy94yP9slAZEkcTOIk0Q/KUXqUcGNJ kqFJfB/abLM12m/tSNIwpL48EVJ9UzqVNj1QykU+45SqEVu+5vk0V1+xgrfLM27EAUJiGoyk QF7p1h82YvqRQazU25i+qDSRwSrkqVow4DNWQxPxXatfTCIDupKGX77067d+dHqPrB+N75GG s6UBOLQ1qrwqPbrrjlu5cw5QCFsk1PC2nilxQ64OM6zJNjXM+UnmvxcGy+B1CUZ2FGEePeA8 u4goCYR6XWIA1CqLt4Gp3gmlfn7xJgsAJylkpk3sAOT19nrtdgmT1+nZ3b0dsBy70/GUgILM 7XpOKbBFggxyLuRrmqWGGgxNDk+1JbLcsKAWUT6yTJGqCsiWKGq1CkWFR7BWgnP81+Emg0TI qVwnVM8C2NAI30iyQBJzbSyg4XnJDf1NiYRIWEWpnyeHnu113QPLGx/vWe64P7Z6x07fcibt 8aE37k4O3YNfTEOucwAlwHrKilRr5bCSAP6hSZn1bmrCpDy5/Sx+QjhcwKMMUqJ1hMSHnh9S ZlFSEs8XOx98oUNIBjDwSG/kyFa5JnXGwTVtkAVnhBM4/mVXSbd2tHUEAPyvAoVhyf+PZ0Gn 3d27mwhuIxGUP+Jz6K/Ik0ebKPqSz2KZUBMMQHa5Tt/te12nv7dJHZUv2gu2TaGSgFWC71QQ ZEHbdfTsuo70bReh36SG7Xbb7VLiVm5sya5R+l8M18R4kIBBzKWuZYZI5VFCCTLiHjbeXP12 c/WncXP1x/XlX9eXf19/+HB9+btp5LH0owlJ4wRKOqhWfkS4oEhjy3Z6TZLKEfa0UFpC8iJ+ b3kyxvZnCeoXPJZri3A/iiWSv+DUogm2CyaF1XZq1irEkZ2fwB7vLnt0LPQGMdWV4ynZI4r5 E7HH7nRtXT0VvL2eh15AgVpzyAODUIDL8orq6yhpVd5rIn4Gh1SVTAk/0RthzFDYEFkYKysn ksRUa5kXk4zJ2UovbF68RedTrmAD7OOYqEqho10pUEXZwjRqblKOngdb+y5Hmz0GX8y3HYZ7 rP42SDTEGlX203lNBo2qfMBjktyifxWETYGWo2kxj3mDy6jeCr0HU/S/gHnGgBjHRLwwGoiU 2a1TvNyhvwbuPWOIf8zQ6Ucxz5owPwXxvoGMPI3mpEG/p8DlGbPlRQOMryAX57rm390NnjHG 55T986sx1R3Ql4a77rof7u4/tvE+P6hrr6tu8Un3k1r9w6CWndu3wN/a6wrUuwc4fUIpb2cw rO6E/IS/IfnpUrc6uOqSlKNHw6scl1uqS4RoLYJTYZzigz7IM5zt9aGMYDLEZqy64QkKtIOq HQ1jhiODaeB2ShKO3pRRXM6h2cedxUwfx2V6nmVS94E43ilNauWlajXamMMQ93OjfwEAAP// AwBQSwMEFAAGAAgAAAAhAO0C0Oj/DAAA928AABYAAABwcHQvc2xpZGVzL3NsaWRlMTgueG1s 7F1bbttIFv0fYPZQ4FcPJon5FmXEbsTuJN2DdGLE7gWUyZJFhCIFkn71Z/d6BjPADDA/vZss IFuYc6vIoihRsuyWI9shAii0RLLIqsP7OPfBl99fTRJ2IfIiztI9w3phGkykYRbF6dme8cvJ m+eBwYqSpxFPslTsGdeiML7f/+tfXk53iyRiODotdvmeMS7L6e7OThGOxYQXL7KpSPHbKMsn vMSf+dlOlPNLnHWS7Nim6e9MeJwa1fH5Osdno1Ecih+y8Hwi0lKdJBcJL3HlxTieFvXZpuuc bZqLAqeRR7cuaR93Fh4nEf1fTE9yIWgrvXibT4+nR7n8+f3FUc7iCPNlsJRPMC3GTvVDtZv8 M8Vu2NiZO/ysPhPfvRrlk/2XfBf3xq72DEz+NX3iIL4rrkoWqi/D5ttw/KFj33D8umPvnXoA XIEelO5K3dHi7QysAS5B3dFHEWLZzxLBbH1z6giOM7zLwk8FSzPcrpqF7HCMvcWrPM8ux4JH BX2tbj58f1EPRTNCg0/HrLyeYt7KuEyEgbnEjbr20B36A3voVQeqveX01ScosARybsurgyy6 pnk6xf/yS76bFOVxeZ0IOX+4S76L0fCB1UpwdXuGSJ//cmywKM5LOaWsmJSHieCAvmnISefy wkY8xMV9+eOfX/74D/vyx78///bfz7/97/Pvv3/+7V8Gm8ZlOH7DJ3GCkziuwcIxzwtR7hnP LTuQFy8HpROW++9FeZnln9g/sjgF/tl39t9eYmVKAENeHz5xqbjL+pawqZZo5UJp6DUL5dPQ QG8937MLtfbyqDVL9ZLRjLPTy5+zCDPCz8tMztMccJ3A9gJICsyHNfBs35zD8HBo0neMgOyb w+p3jU/MQF6Ub0U2YbSxZ+QAnxyHX7wrSrqkZhea1SJL4uhNnCTyj/zs9DDJ2QVP9ow3bw5N NToOae2WpOxyzxh6tifP3PpNii2hT1JeKezOnWESlwJIiid7RoBB6pskuL9OIwm6kseJ2sbw SSrXlWaQ1qVe3xqy7DLneHpSyFWD8TQcZ5CDYZnTKnZhmRaCJ2fAqt4J552D9+EryOtfsQxy vruBrq50/z2WlL1qYRFSJ42OeM4/zj4yS85ZLcsdsGsvCpntYdd2fGfwMMBrmgfmG/no9OBd JqUr8H7MzulhPLgn+IZX6XGlJg9pc17xQ1M6NYiPy5zHZ+OSHWZpCsGV5cxtdKY+nO/Kk9aa Uwnk4zGfihOpCmfUpT6GLIfGhpj5ei2pHAS27ymbwnYGvguQy9mrLQsHsroSynZgepYlrxrQ q6X7nFROYkgqkjhLpHKakUiWQyhha9kDkvqN0JLiuiW7yV68UfDm2XklXytZW1kPSnRCqhcT gyUCkhEbCiBKDt+w37yMhuaVayS16M0IgOZXtlIXAqQRI5WxXravhAA2SuLpj2R/0XRXpqUd WEOXFgMaGBLPhg3eBoMlFTgp6HpXTGSPBSkEVhpiXo2Ch2CIeZbpD1cpMwvmtcTB/ZtiQ/sH E/JFwahlbn0zppiSRfuHbSsLT9VdLH7/oQLN9ix3weTvgbYdm7+C3KvzEv5E/KskOFpG0h3R N3io6HPsgd+jT0nZLXmcFebIJgfDsQm0gUtQptUJjNWD7IopRaLJDUbONDgjZeM0fNT90hz+ ILDg+SueYwjltmBEDe0gsOAZkHZ1HGzWdNASk/omomPBpNb8xcwv98hLSIN9CmEC077iYRTf Rj+sQ7e1uIMKJ6HIyxhkLi8Fi4viHNyH2ARohgugkT7VtkHjOi7hQFreXZrS9h2QUpUj5gVu ZZovt72fGGhuz2tVOJqIySkiF+D+WSmK8hnrAJE0tfBxa+6sGmMEn/f5GRz8VESMh6EoChZm aZlnScdot2VxA6z6nJxrmANiHbYk57xgOCAxRlKsS73aju35AUwCknM9ZEkY3kDFVnD66Yjx KELsqWC8KOKzlGJZzzqQ9GdxC8qEdDGL01HWcfpbA1WHG7RCdsiz27JstT0QcXDAgcLa35AT XTNcluP6JE6/VX28ltijiJgOGVQ4rYNVKWIEm4CPZvw1fNyHAB/TtSgetBw/nh0M/G/Xnrsz ft4LMOKnYMI3BSCswZyibAjW7SlKzwykQb4cQLbtDHsArY5ZdgmgY5EjK+UZE2X4YhMCSHP1 WgC1I47bMbQGlo/IS+VQVsxsW4HZvo/Yeq/AVsW8W/hhMbEClRpDkgnczITBWhfFJmD00Mh+ xeXD/HFNJ+hZMCw73ObtsmBvQWtc8utNoE0z/lpoSTppy0a3P3QkR0FKz7UslwRYW2gh6mt/ wyzYWlZTFzF2wMNPp0gHesbCJDuPNgGhh0bbNwILsOkF1kMQWAfI7r2Mo3K8CbwtEPe+FA7b Flm+j1QXZWe58OgWRBbMdMfvRdZqO71LZJ0cH/7IKH0yOkeq8HdHh6/XzW7VmTbphc6QkTAB 60m51b7Wfh3pNX7j/VUH40lamS1FHF0dhKlyYmokkCKzTW9AeREtRVYTRybpuDqToT7JLZOj yCiZyyddL+uUxvmBF2OV3xphiy5y0cwpKPNZhmXSj2KkUqqr8Fg7yYpY7LSsM1wT2psOGyF3 Sx+osqHnLrB9YLU/HSpGI+S93eZgfYQcGXy6PngSp1kuM5fmRm+Sckdqf0wCMqXVXd8mc8vX caIuYDUWlkalzIrFXxKWinCUCeu3ztijm63hsy4Gbce0KKGHmPYegk8Egk2ZRRcEh/SAS1G4 IdlW5f61ZFuPq9nE06eCKx2m6cAVQLdZXCGw7SzozB5XTxFXOn7Thasmy+Lu8sqzAlWyQrZY V35yj6uniCsd1unCVZMKcXdczdr4jhdYvbyqfYOnbOIPdLinC1dN5sJmcIWke0lr9fYVlfE+ aVytch0HC66jNLdWVHDV/mBnxc7QcmWhBinELgPeqhJQN+MZUm2sHXhIpqGLalVrFO36WtC2 MnQKBqK1WzdPwXeXlGxNRFTVbNGWfHSq4tm6NDyPZf25QZe2sHfPf4C0uRv/0SQddgnHOzuf N4HYsew6tbVpbrAdECM8hdhDRaOtALH8SWGzjeJyJTZR3N9dftij2NgYixescnUB8Tu6ujei GF0qOtL+VS3A1xXFfxrFunx2AZfzCF6N914WL5XFKypHbVMjuA7vB41lur2ctqGP7G5VruCY w4FjSm0/I7JRVW6hwL3OqfU8mcoJENTU9lxk5FssV2inJHW34Vg0tNpxmtMzWxpjyfkE3VdU +AcR8zpIha+pFZDsegJDUcendNhEBolmtBtWCJ1waNRy/5O4ZiiZ4KdJXIwpB70V+5UBj4U2 IEvuaQu30TQpkfe4pJg2vKGCP9DJXB12UNDkJ9/SSezUILUFT6HG7oqKKv74tVXIwDzsDSEC /4MNZ65UIZrn0CpkoC2f7akQezgYIDFa1Q91Gky9DpnpiiKdXymYFzqV6bqMFT3LZkQ8XPJe h6ynCtfTISsfPq0/9MPXMEDbe/gsy3PR3kU9fAMUIdcGgy6KQrMG36uK9/B7b8B1FO8tMXYW GgZu6+FDJ74xzDYqokb/yydovS1/8obab2o67jwEx8n1BrLWECae5/mLTRADH//wMEoTr2J3 Ifofl+MkddVi4T+lPE94/o76YRJBgpaeaQR8oiVm/YXg79KD/BMFCBj1CkV16tF5GmKXKmIw DQ9UJloxDY/CUnk2mNHGs9F7RGKEDoVq8jA0uSCL+rNOV5S9rtgnkSO7EWNrZ4yOovax6UzL z79P0udJqSg/MdsLlH4QXP0QFnNHhAX9MOtfvf9w8nq3XY9+l0tcEDf3db11Oz0s4jVDP7u0 GKG7HgrdR/HZeS5lDIt4iRnJmOobifplNuV523HEFMAZqz8eISa+2oRnyNAsUQTeEuPN7L5Y Q6K38X1KZU9fB+XrmU43ud/Oqlia6ptylxy4Tvd7JpbmdJpEW4mlHVKr2t77Jqg/WO/7JhS7 0ChLm0AC4tAL94Hi7nK/x4niPgwhbYdtpsS72qTuoEIB8U2iuEWFBoHsz4HzNwGGuhTjkVGh PYy3D+NVaarA+CZhPGNSdOZBo+2DLfN3NlK4sX56Dlrt9ybF4zYpNKnfJYwbpmMTcalZFKNB eNV6rpHFjxTFvSy+d1m8nJ9zF3nxBrRb5MVdkHKUc0EJlV19GAPPR1u7Pq9h/VYrmkpboE22 RYufCg7Sag3yZAm/T3boV7729diUFY+brpN+WGEoxx3alsojch3TMT3pDM+oFuRgIhWif94e 8/O2yBA/m+M0n9yzSEnX1XvhqOq8elVcmOQ/8+mHCxmGwBvw8HIavE4KX00R54DfQbs2u+Bl UDEK3c+IHCpTvOKKNsCmS7LoRBWaQ1NF53gjFAVS0IUW754yGBqHluDc8dIoge5oYJ7QnlG9 PaacfMwyGbjASPJM+L86NW1Vw2ETr+3b/z8AAAD//wMAUEsDBBQABgAIAAAAIQAo05GMPwQA AFAOAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE3LnhtbOxX3W7bNhS+H7B3IHTVYnBtyZZsC7GL Oq0LDGlqJO4DMBIdCaFIgaQdZ8Nu0ucZNmADdpO3yQPkFfaRkuzMczu3wIBe5MaWxMPz853v 8BwevVwXnKyY0rkUI89/0fEIE4lMc3E58j7Mp62BR7ShIqVcCjbybpj2Xo6//+6ojDVPCXYL HdORlxlTxu22TjJWUP1ClkxgbSFVQQ1e1WU7VfQaWgveDjqdqF3QXHj1fnXIfrlY5Al7LZNl wYSplCjGqYHnOstL3WgrD9FWKqahxu3+h0tjRJac89T+63KuGLNPYvVWleflTLnl09VMkTwF Xh4RtAAsXrteqMXcq4AYHto72y8bTTReL1QxPqIxYiPrkQfwb+wvNtGYrQ1Jqo/J9muSvd8j m2Rv9ki3GwPwYGPURlVF9O9wwiacM5Yg55eckWgTmRUnZj2R8Mn3rIe6PJHJlSZCIuoKDHmc YR97pZS8zhhNtf1cYZCcrhqLj4Fpvmmr/uL6nUwBJ10a6UzsABQNwkGnU8EUdQd+P9wBK/C7 3cgKWMh6/SioBDZI0LhU2rxlsiD2YeQpROos0dWJNtbTrYiNUchpznmTkFrEYlhRweKR3ljB C/y7dNOYa3NubjhzuwA2NCI2yi9RYcoZS9nirOKGW7MiC1STpdTPx9GbqT/xw9Z02g9avUk/ ag2n4bQ1eT3ww94wijph8ItHzE0JoDTPUyaWhdOqYIUD/pHHROvDuQeT5uTxu/4J6egBHmuQ UadjQRPo+aEQLUYr4iV6ZyHRLoU0hoEDozFjv2+hNA5QxOYsinRGFUXk/6+bbGOnSqcrwSZT qIWqAD5dBr4fRP2mFOa5QRk4EuNgaDi8h/x7WW4rrczqZBmrykOWUUG9YIhc9oNhWJeHrQnn qNiUiSUZtJZx4/sBLGP0REzUlatGW4o4cWdLkYDpLgTk0GbiIKaAKCikNFfGHT9EF+aYMwoS 7yHQw92vD3d/kIe73+9v/7y//ev+48f72988UuYmyaa0yDmUdHsozIwqzeBPyw8Gewj3SuWU PxJzBQ4m1dwz4wlNrlrLkjjq63jLMgsfyulrso0mV53jx1IYtAUy4yiLTPKUKRJYL78+91+U bpucnTOvF/bRMF1n8HvD7qBbo9b0h0EQDLdHXhiEw8h5DCwqTY7xX3xcfY5I1suL5SkGAkv6 zRG2rbv/ru/AHkPfDLm2njccckRykZEnJGy+bQt7QuIJiaYwGiSqsSYxCheHz/SeTxwZh3ej b+vA2HSjZ1oWjKTM0JxrgvsOOWXmWqor8qPMBboveRY8f35Qk3LndHXhwGNzB0m4ekfL9yuH FK5Whqlj96mE8nrm2IpgVsgLLLipQWBcdQMIxWZonIvm0pIuceXKBcZQ+Ggwk+A2ZKhCVxYM l0F0Q4zhczdhmuJMSlMPKaXVBOdMpdo+1eas85jy/gYAAP//AwBQSwMEFAAGAAgAAAAhAF/2 Cy27AwAAHwsAABYAAABwcHQvc2xpZGVzL3NsaWRlMTYueG1s7FbLbts4FN0P0H8gtC1cW7Il PxCnqN26mzQ1kvQDGIm2hFKkQNKOPcVs0u8ZzAAtMJv8TT4gvzCHpGQnbopmFrPLxpbEy/s4 955DHr3elJysmdKFFOMgfNUJCBOpzAqxHAefLmatQUC0oSKjXAo2DrZMB6+PX/x2VI00zwh2 Cz2i4yA3phq12zrNWUn1K1kxgbWFVCU1eFXLdqboFbyWvB11Okm7pIUI6v3qKfvlYlGk7K1M VyUTxjtRjFODzHVeVLrxVj3FW6WYhhu3+0FKx6gsPeeZ/dfVhWLMPon1e1WdV3Pllk/Xc0WK DHgFRNASsATteqE2c68CZnhoH2xfNp7oaLNQ5fERHaE2shkHAH9rf7GJjtjGkNR/TPdf0/zj I7Zp/u4R63YTABnsgtqqfEU/lhM35ZyxFD1fckaSXWXWnJjNRCKnMLAZ6upEpp81ERJVezDk NMc+9kYpeZUzmmn72WOQnq6biPeBab5p6/7y6oPMACddGelCHACUDOJBp+NhSrqDsB8fgBWF 3W5iDSxkvX4SeYMdEnRUKW3eM1kS+zAOFCp1kej6RBub6d7E1ijkrOC8aUhtYjH0o2DxyLbW 8BL/rt10xLU5N1vO3C6ADY+ojfIlGKZcsIwtzvxsuDVrsgCb7Eh9mSbvZuEkjFuzWT9q9Sb9 pDWcxbPW5O0gjHvDJOnE0R8BMdsKQGleZEysSudVIQoH/OOAidan8wAhzcn9d/072tEDPDYg o87Hgqbw87IULUb94KX6YCHVroV0hABPrMYch4mF0jhAUZuLKLI5VRSV/79psl0c305HwaZT 4IInwM9pEIZRAtnzzJ5KYSAUZM4BVC55xhSJHpDClvYDFR6decu7KkebQaFeNEQz+9Ewrvlh SeEyFTue+ClrWLyTiV7ch4Q6rQh7w+6gO/CNaxRjEEXDPQniKB4mLuMdCxwG/3mAGT0RE/XZ Ed2yHGI+X4kUJPJycLk6xRFRU8hPyr4Tv+54ZAeTZIUyTu2ILs2UMwrOPDKvdzd/3t18I3c3 f99ef7+9/uf269fb678CUhUmzWe0LDicdHvQgZwqzZBjK4xqmB7M9xtVUH7PzOkJgNpn3swQ mNoM/zMSz0g04/CMhEMCknKgsE5k/P0Jj82VKuXqA60+rt1BgpuiYWrqPlWQk1o09yZwWpRY sMJpBE5fp6AUm+HxQjR3sGyFG2QhcKoWojAsILjcGarAesFwt4WU41Zx4Q5MU55JaWrJrawn m7l3bZ/qcDZ5HFr/AgAA//8DAFBLAwQUAAYACAAAACEA3n05aiIEAAAqCwAAFgAAAHBwdC9z bGlkZXMvc2xpZGUxNS54bWzcVt1u2zYYvR+wdyB0O7i2ZEu2hThFnda9SVMjTrFrVqItIhQp kLSTdBhQpK+xPULRARuwmzxN8wB5hR1SUpxlHuAWGzDsxpaoj9/P+c75yIOnl6UgG6YNV3IS hE96AWEyUzmXq0nw5mzWGQXEWCpzKpRkk+CKmeDp4bffHFSpETnBbmlSOgkKa6u02zVZwUpq nqiKSXxbKl1Si1e96uaaXsBrKbpRr5d0S8pl0OzX++xXyyXP2HOVrUsmbe1EM0EtMjcFr0zr rdrHW6WZgRu/+08pHaKybCFy92+qM82Ye5Kbl7paVHPtP59s5prwHHgFRNISsATd5kNj5l8l zPDQfbR91Xqi6eVSl4cHNEVt5HISAPwr94tNNGWXlmT1YrZdzYrXO2yz4sUO624bABncB3VV 1RX9tZy4LeeUZej5SjCS3FfmzIm9nCrkFAYuQ1Mdq+zcEKlQdQ2GOiqwjz3TWl0UjObGLdcY ZCebNuJDYNo149y/vXilcsBJ11b5EI8ASkbxqNerYUr6o3AYPwIrCvv9xBk4yAbDJKoN7pGg aaWNfclUSdzDJNCo1Eeim2NjXaZbE1ejVDMuRNuQxsRhWFPB4ZFfOcO3+PftpqkwdmGvBPO7 ADY8ojYqVlCY9sFytjytueG/OZMl1OQo9cNR8mIWTsO4M5sNo85gOkw641k860yfj8J4ME6S Xhz9GBB7VQEoI3jO5Lr0XjWiCMA/CZjsvFkECGmPH76bd2jHAPC4gIx6H0uawc93pewwWhMv M48+ZMa3kKYIsGc19jCMHZTWA4rafESZz6mmqPzfTZPdx6nb6SXYdgpaqAXw9zIIwygZtlI4 4xYy8CTGYGg5vIP8O1nulFYVTbOscxWgy1DQIBqjl8NoHDfycJrwicp7mTiSwWuVtrnvwTJG j+VUn3s1Oili4s7XMgPTfQnooevEXkwBUSCknGvrxw8xpT0SjILEOwh0d/Px7uZXcnfzy+31 b7fXv99++HB7/SkgFbdZMaMlF3DSH0CYBdWGIZ9OGI12EO6Z5lQ8MPMCB5Ma7tnDEzcYF5ZV Jt0yzEEHKX1Np3HA1TP8SEmLI4HMBSRRKJEzTSKX4df3/Yta7RrzaN4N4iEOS38qhINxf9Rv EGvPhlEUjbfjLo7iceIzBha1J8/2Lx5V/yCJIjdu/nskQq+XXJckZ4ZrluMwwI1FW87MDk55 YtVD/P+PzPdKnxO1tmS5FgL4WMqFIVxC/hQLn9//ZPkKyrCMlp/f/7wDLnCuHVjNsPV/9VUK j+3tKhP6Fa1eb/xEwqXRMn3klyoMrWaabk3glJf44OehxEHsRyvFZng8k+11LF/jMsklDlgu ucW0xT3PUo15IxmuudA6Lhhn/uy05alSthm/lfPkMq9du6cmnEse59cfAAAA//8DAFBLAwQU AAYACAAAACEA2I8yl0cFAACaEAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUyNS54bWzcWMtuGzcU 3RfoPxCzSoLYkhVJtgXLQerEbVHHCSwHXVOcK83EM+SApB6TVZD8RrvuqmiBFugmq35K/AH5 hZ7LmfEraqMAAdoUBkYcDnnJe+65L+/dX+aZmJN1qdHDaGuzHQnSysSpng6jZ6eHGzuRcF7q WGZG0zAqyUX397/8Yq8YuCwW2K3dQA6jxPti0Go5lVAu3aYpSOPbxNhcerzaaSu2cgGpedbq tNv9Vi5THdX77Tr7zWSSKnpo1Cwn7SshljLpcXOXpIVrpBXrSCssOYgJu69daR+aqVEW868r Ti0Rj/T8a1uMiqc2fD6eP7UijYFXJLTMAUvUqj/Uy8KrxjIMWje2TxtJcrCc2Hx/Tw6gm1gO I4Bf8hOb5ICWXqhqUl3OquTJirUqebRidas5ADe4OJS1qjR6X53+VrffaHRCCmafZiQ6F8pV OyQkHBl15oQ2ULdCwRwkWE0PrDWLhGTseLpSXh3Pm6MYET68SIQvC+DmU59RBCyhaLez293t b3d2e/XGanWArxHgYIKArV9+ZeKScRrjN0zKQeb8yJcZBfygpRzgNDxgrQy3G0akN56NIhGn 1gdIhcv9QUYS1G9HAXQZLjaRCpd79+bnd29+E+/e/Hr+6vfzV3+cv359/uqXSBSpV8mhzNMM Qu51I6ESaR35YbSx1dkJlw+HskC//0SL74gKUF+MwDfag1k8WBEuhyfuCRUbfTCs7POPVtp+ 30r3+FxQtwH7U1qJIf5II7HuN9jd7W3D8wPFt/rtNo+DoRqi7/TxxwuY7t1ep7fbD0pdpTHb n9Vs4PqA+bFa5NIegYzb3X6nF4lsngXCpjqG+7PFqg983/HsGDEOd2Kr8Dmr+HPwAAHxxTDq BF1WMymoBcuPHdl5CDHC0lRajqri7csfzmo+ILB6evvyx8EKTgRihHt8lAaHRvsrFP4eJ/Kp CI7XWNu5Qtrg36w9XNgGLg+jP3+qafwpcDgxM8+a38nTaeLvCJllZgFEcjPnaU95Yay0pXj8 4ICTjSdhJuK5STV/1ibGuxaasHtsbDVxizanm3chBAmAYuGNuIbhhy03rmgQnpdWJItchKh+ NS7U1ny0xD39iPxHHnQpfIXQ29eEVdHgf2T5bydi5ii+KxKzIFQZd4VPUgdCl+I5mYI94gWJ mFxqYUS2uCgsagfrU3JreUUP7rvd+DVYvdqvb3jFqMzHJrvhEluodC4C+Sqf2PiELqEsgbdO OFIzm/qS1R5nlDtRE/sh6VRmG2ayMUIMQeEjpPcSSXctxnymqGhS5FzKEcCxLVBQOHZtWqYu RBBbRxKg5Y0ymVvHfT5TMJSE68BXgIicEjAopOYqXaAYB82ZQXAtoUyez3SqqjTD0VCrMqwJ 7tRMwLMk1/mlcBx8T0cH3wSENWXrYLhe+rzhZv+J5HMRgqrIwxkI2SQLHjdPkVou0w8yM/JJ ShOkZCBYLhCmandUGQpe4UqtEmAvdtqdza3eZpdaAciY0O7EjrPUdXMsUp9wwvd25jhN1WLM zCrO+430meNEF2IBNVYRY/ILIh2iIraGNMimv5YHb68VDj5f64WKGSoT0EUgGJM4o8KjgjAA TM58giKOuQ+Azgi0n6Jf4/ZQ3ALq7ABAeS2I/r0gAeY8lVaeXG1S1iwy/657CE1E1bpi2HSz KrOPZfFkHgpbNOme7EGY4t6Eq14svVyCGjvN8SFU2/rIoWVB3yZD9a1OddP+xjMUTJx0J6jW PFo59NVeWlTWmhM++hSUb6dVr5efGONDEq0l4URfieZRfRyG+M/C/l8AAAD//wMAUEsDBBQA BgAIAAAAIQBNFyzmOwUAAEUSAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTI0LnhtbOxYzW4bNxC+ F+g7EHtKgDqSFUm2BUtB4lYBCtcxLBs9U1xKy5pLbklqLeUUOK/RnnsqWqAFevGpjxI/gF+h H7m7tvUTR659CNDagLTaHQ5nvvlmOLO7L6apJDk3VmjVjTaf1SPCFdOxUONudHLc39iOiHVU xVRqxbvRjNvoRe/LL3azjpUxwWplO7QbJc5lnVrNsoSn1D7TGVd4NtImpQ4/zbgWG3oGrams Ner1di2lQkXlerPOej0aCca/1myScuUKJYZL6mC5TURmK23ZOtoywy3UhNVzJvXgGRvI2H/b 7Nhw7q9U/tpkg+zQhMcH+aEhIgZeEVE0BSxRrXxQioWfCmK4qC0sH1eaaGc6Mmlvl3bgG5l2 I4A/859YRDt86ggrbrKbuyx5s0KWJd+skK5VG8CC6029V4VHy+60N5vtyqMjzhD2seSkce1c sYJCw75mp5YoDXcLFPReAmn+0hh9lnAaW3+7cJ4d5NVWHhG/eZYQN8uAmxNO8ghYwtFmY6e5 095q7LTKhYV0gK9SYBGCgK2bvtLxzOM0xHe4STvSuoGbSR7wg5e0g93wgWhJWNeNuNo4GUQk FsYFSIlN3Z7kFNSvRwF0GgwbUQbjri5+vbr4g1xd/H55/ufl+V+X799fnv8WkUw4lvRpKiSU PG9GhCXUWO660cZmYzsYHzb1Cl3vSE8ceE9e8YTmQhvypPF0F6FxYEYwEJ+wFW5WPuGyiNGd kdpajtRzvzfoWwH+mJHyMN8zUN7/BYY3W1vI/kDzzXa97q9DsCqyb7fx7wU85ZutRmunHZy6 TWXPAe9mBdcnKABpklKzD0JuNduNVkRkLgNphYpRAnzUigfe3uHkAHUONvmo+H1WcWjvJYri 227UCL6sZlNwy/X2UJz4jxPUVG4JyiExBR06KygQeBC2vZfBfa3cLdZ+D7L58o16OEfUxi2e hpT2ziJrTaBvN/r7l5K5j+H2t1ooT3qlY060kjPCdJpOlGDUAYg55z+NsAjhuhNnqRmVcnZP xXeqJPHEeB9+gC8kM9pppuVX5Ey4hCguxskQ4QwOUhYynFovNp0VIpYbnKtBYM6qIt2XYt0C B7cqciJWq8m5EOvBLB1quRDoTRzZ1xVpVaQ3HiPQPjOsliLuCynDDzMe7klDcorsquOv3y/3 uSUG51GNvbjrzXFkYkELKdQpCZEkNI5xQtuVMVgHzvVyfQHOzyJ1BgVvlpNmmXglGQvEhHLc eCZqRYbcnXGubmiKBi7w+DonhcqFFUMc706TgqrrwPrfY+nBfKYDxzKxGVUErH3MWvbwnKJq dl+DVtfAh5vCp8KGslieeNcl9H+eVUXzo9VQaecrII99dn5491MFoVAjQ60zE+Ymhn949zNA 9S0lpEZCUYlRjWck5jkmJcxxRks/K5EnUMG0GonxxISJp5ZRg7kFBUO8DTeg6imqSSJYUhzX Cc0wwllCRxAimbbCiZwTOnEJNPpj3NcZX1b8LV3pmYstZhgVH2Kno9sN+JrN00eOyfXq+lIP 99kYUnSU/wKPMEpwX3D06L4pvkb/hMKxELsHWUqWsn+eusXJhVbYsxtnFT21oOCcBY9LgAd5 c5LFoW0F8qszkfjDYMhJjNkB5wNDci70ooU3y0NemPWKtwy4rF48MGm+o9mbPFiN9ynIQbRW uJXhAPfDCURvRDAKiRQPwlCk9i0mS4zYFIshdqyqNxVoZ7uRbytRKoTD1I0Gy1GDAUhxdKoY J9GsHxdjeXqktQvtW6nJW16o9lfldrjES6DePwAAAP//AwBQSwMEFAAGAAgAAAAhAMzHVuQY BAAAtw4AABYAAABwcHQvc2xpZGVzL3NsaWRlMjMueG1s7FdNbhs3FN4X6B0IrtqFLWkiybbq UZC4VdHCdQzLQdcUh6NhyyEHJKVIXTqHySpogRboxqtexQfwFfqRo4mlSEntNEvbwIjDeXw/ 3/v4+Hj8dFEqMhfWSaNT2tlvUyI0N5nU05S+vBztHVLiPNMZU0aLlC6Fo0+HX35xXA2cyghW azdgKS28rwatluOFKJnbN5XQ+JYbWzKPVzttZZa9gtZStZJ2u98qmdR0td7eZ73Jc8nFt4bP SqF9rcQKxTw8d4WsXKOtuo+2ygoHNXH1hktDRMbHKgu/rrq0QoSRnn9vq3F1buPns/m5JTID XpRoVgIW2lp9WInFVw0xDFrvLZ82mthgkdtyeMwGiI0sUgrwl+GJRWwgFp7wepLfzfLixQ5Z Xny3Q7rVGIAH74yGqOqItsPpd7r9JqILwZH2qRIkeRdcvYJBw6nhvzqiDcKtUTAnBaTFM2vN q0KwzIXpOnh+Nm9MBUSC8aogflkBNy+9EhRYItBuctQ96h8kR73Vwlo6wtcocEhBxNYvnpts GXCa4DdOsoFyfuyXSkT8ECUbwBoeyJaCdykVeu/lmJJMWh8hJa70J0owUL9NI+gsOpYzDudu r9/eXv9Jbq//uLn66+bq75vXr2+ufqekkp4XI1ZKBSVPupTwglknfEr3OslhdD4aDQr98MLM PHhPnouCzaWx5KvO18dIjQczooN4wleE2cSEYZ2jj2bqYDtTT4Jt0LcB/HNmKsD8wESF+N9j eLd3gN0fad7pt9thHJPVkP2wj/8gECjf7SW9o34Map3KgQMhzAau/6AApEnJ7CkIedDtJz1K 1FxF0kqdoQSErNUfgr+T2RnqHHwKWQl2dnHo5BmK4m8pTWIsu9kUw/LDsbCoroQzrY0njFQW FJBgoAukmElXkF+M1IEg2mSCoNISLeS0mIApYWawgyuRMNG/B0U2Mtqv0ftnGA11HoVzg9HJ GqHj3g+oYHsjCjxS+s+bFcX/Fz4BWWeUzEZSqfhip5MTZcmcITtt/I1GKztrYmHH1Fnxwx9C 9qRfbgJYyAzzJLemJBVzTs4FMRMX0+C+eQTzA2De8ZQYrZYPIChhuQfD2cwXIR88HqnoGUS1 //nQ3tqUQmfnzLKL9dJ+z21Z19tP3ENbjmyfMPd0I5wAP65v/Y/ViI2SEItEzejH6rBeRNar QwMtUN1m9CacsVbUeD6SORbYu3bpAWQ+Wz+2tk48Gat1vlmtH+n7IfqSTzjddtXb7bYydpf1 vQbD5qrDlf2JVS/msZzhBoeSjsMYUxU6hNAOQfROBM2XLPEhtmH61KGXRVPPYlvGL3VzN8pm aBdCl5Wjw/Ho83Hp8syi5dICXREaWDQ4l/VFoLwwxscDf6UpeF6rDqOVOQxx7Rz+CwAA//8D AFBLAwQUAAYACAAAACEAwwEf8l4EAAC8DAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUyMi54bWzc V81OI0cQPidS3qE0p10JbGNsYxzsFeusk5VYQMAq52am7enQ0z3qbhucE2JfIpGSc05RIiVS LpzyKPAAvEK+7vEAZi1+slySy7inp7uqvq++ri5vvDrJJE24sUKrbrRSqUXEVawToUbd6P3B YLkdkXVMJUxqxbvRlNvoVe+LzzfyjpUJYbeyHdaNUufyTrVq45RnzFZ0zhW+DbXJmMOrGVUT w45hNZPVeq3WqmZMqGi23zxmvx4ORcy/0vE448oVRgyXzCFym4rcltbyx1jLDbcwE3bPhdQD snhfJv7X5geGcz9Sk69Nvp/vmvB5e7JrSCTgKyLFMtASVWcfZsvCq8IyDKp3to9KS6xzMjRZ b4N1gI1OuhHIn/onNrEOP3EUF5PxzWyc7ixYG6dvFqyulg4QwbVTj6pA9DGc1kqjVSLa4zHS PpKc6tfgih0MFrZ0fGRJacAtWND9FKv5pjH6OOUssX66AB9vT0pXnhHvPE/JTXPw5oSTPAKX ANqorzfWW2v19eZsY7E60FcasEhB4NadvNbJ1PN0iN8wyTrSun03lTzwB5SsA294IFsS0XUj rpbf70eUCOMCpWQz15ecQfq1KJDOQmBDFiO4q/Nfr87/oKvz3y/P/rw8++vyw4fLs98iyoWL 0wHLhISR1UZEccqM5a4bLa/U2yH44NQbdL13m316zVM2EdrQi8bLDaTFQRUhODwRJyCWeDAs 8nNvltY+ztKq9wvplmQ/Z5Y8xU9Mksd+R92rtUa7Vkh8pVlv1DAOiSqF3m6vrqM0gE7Q2mjW m+utAOq2jH3+PcySrgfSj9WUMbMFMa41WvVmRHIig2CFSnD8fcaKDz7ew/E2ahxi8lnxfhbp p7+Jgvh9N6qHUBcrKcByvZ1Dy80klBgyfMSMr6p0cfpTwodsLB0d8am9OP25s0ASQRchjCcB GGjlbin4Wzj0TlEb50Rbv6XZcLw9eJxgE6Tcjf7+Zabi56Dh7ZC+00J57AmfoIaTUHSw3/+G Mp3wJRIOE8IJJuWU5qh4mH8RknlvFmKmlHZPtHuvRRpbTpbHYyPcdImsUB6To0RzXxMd4bBz n1wPGfcfN8BGUz4fRHH0/195VhythEu55NZ6lhJ6wSujyhIdC5dC+T8M2RG/OP3Rk/NyiVwq LMWGgyJ7Tehcpj6JpOc9zZ8NJTu2BZK5GB9W6b1qatfqlZVmpfGllxCTVkMyU8q1lGPHaWjQ X1Csxwoyot23r8mxQ9B7JwKukl1m2N7tm+6Rlep5Kf63gfhia7UUyUBIGV7M6LAvDU0YCjbu itpgMKtJt5Yh9huHRd32e8PV/8m1/8byTffwn+J0dpMt6i9Cm1E0txiW/W4szTuW70zC1Yc2 HpJDCjCVo5J5a1h6swS3sMjwIdzHasuiqUFnx8L9HB+oskFOxmjv/XU79FUezR46b8cM7t5Q LdDJ4BY4KLrBbE9rF9I8swSPrjDtRzN3GOK/R+8fAAAA//8DAFBLAwQUAAYACAAAACEAisQM unUEAABZDAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUyMS54bWzMV81u4zYQPrdA34HQKQtsYlux HceIvUjcui2QTYIki55pirbYUKRKUo7dU5B9igW2556KFmiBXnLqoyQPkFfoR8rKr7HNbgO0 F5mihvPzzceZ8darWSbJlBsrtOpFjbV6RLhiOhFq0oveHA9XOxGxjqqESq14L5pzG73qf/H5 Vt61MiE4rWyX9qLUubxbq1mW8ozaNZ1zhW9jbTLq8GomtcTQU2jNZC2u19u1jAoVLc6bp5zX 47Fg/EvNiowrVyoxXFIHz20qcltpy5+iLTfcQk04fc+lPiJjRzLxvzY/Npz7lZp+bfKj/MCE z3vTA0NEArwiomgGWKLa4sNCLLwqiGFRe3B8Ummi3dnYZP0t2kVsZNaLAP7cP3GIdvnMEVZu sttdlu4vkWXpV0uka5UBeHBj1EdVRvQ4nHaj2a4iOuQMaZ9ITuKb4MoTFBp2NTuxRGmEW6Kg Bymk+bYx+jTlNLF+uwye7U0rUx4RbzxPiZvnwM0JJ3kELBFoM95sbrY34s3W4mApHeCrFFik IGDrZjs6mXucRvgNm7QrrTtyc8kDfoiSdmEND2RLwrtexNXqm6OIJMK4ACmxmRtITkH9ehRA p8GxMWVw7vril+uL38n1xW9X539cnf959fbt1fmvEcmFY+mQZkJCyXozIiylxnLXi1YbcSc4 H4x6ha7/entAdnhKp0IbsrL+YgtpcWBFcA5P+IkQq3iwLPPzwSxtPM7SurcL6lZgP2eWPMQf mSQf+wN2r9ebnXpJ8UYrbtaxDomqiN7prG+iNABOwNpsxa3NdgjqLo19/n2YFVz/kH5Ik4ya XZBxo9mOWxGRUxkIK1SC6+8zVn7w/o6KPdQ4+OSz4u0s489gGwXxx14UB1eXMymE5foDFCb+ Q4F6yi1BKSSeCqOKCt9roVAPcYkSTlaYVu7y7F3yoruEH4EkwaePimYInXfo/B2s+bqOQnmP wfEdAoe77pHAdTaB173or58XlH4OTPYBBjnhc0s42spICpvy5CVxKcoxsaku0FRGnBSWJ+RU OGw4wmeM577MPwWaFvK5USUaoS1P9ANojubZSMsHuDTQ+m5u9jJgVp8DF88yq6VIhkLK8GIm o4E0ZErB1OEQ1yTcE3DyjhjeUNW8uOt/IyYp9xVujqfT6N+2MJwcfLtDPMLgXq7zAo1yAamH 3xMPnZkbQeXzofpM1+ffQ/LZilBMFp7tCF4KNidjwWViCSYZMjbo2YTpQgEAu6wgf+KFexQ/ V8kBNfTwbgN6SgH5MAKeEsPhgnz3SXFrsKxiXlFohP9RJfzkQG7YfchRC4geowoI63xCO/V4 rdFaa768KRCXZ+/dKacn9vLsJ7KS6aSQmticM8Ixj/w/U7xoM8uaf5gByskTy2oYZdK8pvn+ NNx6zNjgLsoEtnKA4rVB9FYELVJk+BCapdq1mDgwdtHQPNmxqqbXpMDs7UvkGM3IYRLDWOyo QWNUHP8KMGagOx2Xo1p2qLULrFtogkVXqvarhTks8ceg/zcAAAD//wMAUEsDBBQABgAIAAAA IQB88aW5XwUAAE8TAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTIwLnhtbOxY3W4jNRS+Bol3sOaq SNtNmiZpGzVZdcMGhLrdqu2Ka8fjZMx67MF20oSrVfc14JorBBJI3PSKR9k+QF+Bz55Mm59p adlIIOBmMpnx2Oec7zvfOfb+s0kqyZgbK7RqR1tPqxHhiulYqGE7en3W29yNiHVUxVRqxdvR lNvoWeeTj/ezlpUxwdfKtmg7SpzLWpWKZQlPqX2qM67wbqBNSh3+mmElNvQcs6ayUqtWm5WU ChXNvjcP+V4PBoLxzzQbpVy5fBLDJXWw3CYis8Vs2UNmywy3mCZ8vWBSB56xUxn7X5udGc79 nRp/brLT7NiE10fjY0NEjHhFRNEUYYkqsxezYeGvwjDcVJY+HxYz0dZkYNLOPm3BNzJpRwj+ 1F/xEW3xiSMsf8hun7LkVclYlrwoGV0pFoAFN4t6r3KPVt1pbtWbhUcnnAH2oeSkduNc/gXF DIeavbFEabibR0F3E4zmB8bo84TT2PrHufPsaFws5SPiF88S4qYZ4uaEkzxCLOFovbZX32vu 1PYasw/z0SF8xQQWEITYuslzHU99nPr4DQ9pS1p36qaSh/jBS9rCargALQnr2hFXm69PIxIL 40JIiU1dV3IK6lejEHQaDBtQBuOuL3+8vvyFXF/+fHXx69XFb1fv3l1d/BSRTDiW9GgqJCbZ rkeEJdRY7trR5lZtNxgfFvUTus7Lgy55zhM6FtqQjdqn+4DFgRXBOFxhJ1ws/MFtjs+9KO2s orTt1wV1i2CvEyUf4keC5H1fYvd2tb5bzSm+1ajVq7gPQBVE393d3oM0IJwIa71Ra+w1g1Pz NPb4ezeLcP0J/BhNUmoOQcaderPWiIgcy0BYoWKkv0csf+Ht7Y+OoHGwyaPi1ynjT/cAgvht O6oFU8uZFNxynS6EiX8zgp5ySyCFxFOhX1Dhay0U9BBJFPNWCSkCM4Ihj3Khp5Wb4/BXWMKL OdRxgba1OdaGBPfuI4dNIHM7+v2HGY/XEYgv51wljCoCyA1ljoyFFX1ITKaNl/EQoIGBoj4h MbcwmJMBFZLH64vPeiEmhFjORka4KcmMBtDWY7qxYO9fpZEnoNVSxD0hZfhjhv2uNGRMQWLk T7XXm6E0N8wLS05e13GJsGQoxuAfZd444jR5oSDVjMdQJcoQdKEGei32zmhfpnArZG4g7XaK fAQZy/Nxicyn07Sv5RKTt9Ch3AhwGZU318Hk+7Ho9Twa92PxhRgm3BeiKa4JDVCgzggp0IVw EqDKtHWbczyyjmdL0HAVH1NDT+Zr2gM1KS82K1A8TBqXoPh7dWUVDd938pvccJNABDh8R2Ic caDRhyR79Q2S5HgKFaIGRT1kDJnXZ/L+7Xd8ghHON8NuZN+//f4JoQMHKHOBAoGZTn3uz8H3 z5EBbnh/Coul1L4JJyNUJsgWRCCmjpKguV4b+iDiXCC8aGQOo5ZIuNpWLVJQhBpbXhxXsXus qg2MTvN8sRlnAtsCVIsxNgePtLLcvv9VLDRAdyTOgoqBMPbcN8NEq4rfwwQRK8kVJEkQuukC Qnfo0X+8NCCoXFnkZh5NFHCtoEkjizT0TSS6RieoDPpEUtR0OuR2Ia7YO669SPy7QHlI77TM dABwD78BjB65IRrdYTkoH0T2NTWtHy69H/Upe+MLxUJ13ED3Jhi6GOsLJc5V4tsCg0pZ1hCu bnnDzjc/b8FtcQTDpHlJs1fjUHFwsoSKiyqPRxki7bdqGHo7BBtD4Ytw2CKqQ4t9Ng4baNgy sjO0uvmZTTzCiZPvOAc+mXD+gMMgRw22g4rjLAyba3QFZ/kBRXqitQud3Wwmb3k+tb+bLYdb HId1/gAAAP//AwBQSwMEFAAGAAgAAAAhADy/3ZvrBAAA0A4AABYAAABwcHQvc2xpZGVzL3Ns aWRlMTQueG1s5Fdbbhs3FP0v0D0Q85Wg1WNG0ugBy4EtR2kBv2ApC2A4lDU1hxyQlGQ1yI+z nqIFWqA/3o0X4C30kKORbFeB7SANAvRHmhmS93HuPfde7ry6zASZc21SJftBWK0HhEumklSe 94O342GlExBjqUyoUJL3gyU3wavd77/byXtGJASnpenRfjC1Nu/VaoZNeUZNVeVcYm2idEYt XvV5LdF0AamZqEX1elzLaCqD1Xn9lPNqMkkZP1BslnFpCyGaC2phuZmmuSml5U+RlmtuIMaf vmfSLjxjI5G4f5OPNefuSc7f6HyUn2q/fDw/1SRNgFdAJM0AS1BbLay2+VeJbXioPTh+Xkqi vcuJznZ3aA++kct+APCX7heHaI9fWsKKj2zzlU1Ptuxl09dbdtdKBbBgrdR5VXj0b3dapTtn nCHm54KTeO2Z207s5b6CTWHgLDT5oWIXhkgFrwsw1GCKc3xPa7WYcpoY97nAgB3PS413gSm/ GSf+3eJIJYCTzqzyKh4AFHdanXq9gCludMJ26wFYUdhoxG6Dg6zZjqNiwxoJ2su1sW+4yoh7 6AcannpNdH5orLN0s8X5KNUwFaIMyGqLw7BIBYdHsnQb3+Hfh5v2hLEjuxTcnwLYkAjfqDgH w7RXlvDJWZEbfs1tmYBNLqXeD+LXw3A/bFWGw3ZUae6340p32BpW9g86YavZjeN6K/oQELvM AZQRacLlLPNSNbQIwN8PuKy8HQVQaQ/vvptfEY4m4HEKOfUyJpRBzg+ZrHBaJB4zDxaY8SGk PSh4ojd2N2w6KK0HFL55jTI5pZrC8//WTL7WU4TTU7CMFLhQEODTNAjDKG6XVBinFjTwSYzC UObwluTfmuWOafl0FSzrRAWIMhjUjLqIZTvqtlb0cJzwhso1TVySQWreK21/QpZxeij39YVn o6MiKu7pTDJkuncBMXSReFKmIFFAJJPZgeAUqbslbW6vf7u9/pPcXv9xc/XXzdXfNx8/3lz9 HpA8tWw6pFkqQMNGE3ScUm04rKiEUWdLmu3plIo72zytkT+rjLO7JzPr2xD8IT8bM+OGvGi+ 3KSYww5c+pxQo8MVRXygpEVPIKcCnJgqkXBNImfs5wf+WbF2kXlQ8JqtNrqlbwths9voNFbg lc2hE0XdTb1rRa1u7C0GFoUkn+7PrlVfMIsiFOyAJKm2vol9K/k0TC1ZpHZKOvWoGraqTV4b jwY/9bZklE+rooaLufDM+pL4uHr87eEzPjk46ZFJiiZJflGpJBk3hp5zwqiUypKZ4WRvdEwm Gq30tUSpYTwh+5wyJX8kJsUr5gJLrJ4Zi5UXGCFJRpfwdDIBr/w5J0BNiOR2ofQFliU06JdV cqQ0J3gTS5NivuA84UmV3IvNcypZ9AjGRqGNuj7vGOhHWD4Qmswpok0ZQ00oSXVv570O+vVK 4fu9EhimslxwwPvhATSbDvh4p30MnK/r5cbysqD/j+nHZlq7hrSuUSRRaHyOV1QItSBZeuka Ijg0k4ZjO5jmiFY+W03dral6Lz0+1Sd9qyguPHgs70BM6COan8z93ICrneUa3MCnHJpXM89m C2aVNMOCn1okxmU/AFEchsSxLC9NyQxXvlRiDE5lajET4TZmqcZ8IDkuo2jIuAaM/YRrszOl 7GpIyp0kGGcL0e5ppc4ZjynzHwAAAP//AwBQSwMEFAAGAAgAAAAhAGTk0vsnBQAAMhQAABYA AABwcHQvc2xpZGVzL3NsaWRlMTMueG1s5Fhdbhs3EH4v0DsQ+5SiVWSt/heRA0eKgwJObFjO ARgupSXCJRckV7YS9CU5T9ECLdAX38YH8BX6kauVLMdFncBpBPTFXu0OhzPfzDfD4ZOnF7kk C26s0GoUtR7vRYQrplOh5qPo9dlhYxAR66hKqdSKj6Ilt9HT/e+/e1IkVqYEq5VN6CjKnCuS ZtOyjOfUPtYFV/g20yanDj/NvJkaeg6tuWzGe3u9Zk6FilbrzX3W69lMMD7RrMy5cpUSwyV1 sNxmorC1tuI+2grDLdSE1Vsm7cMzNpWp/2+LM8O5f1KLF6aYFicmfH61ODFEpMArIormgCVq rj6sxMJPBTE8NG8tn9eaaHIxM/n+E5rAN3IxigD+0v/FIprwC0dY9ZJt3rLs+A5Zlj2/Q7pZ bwAL1pt6ryqPPnWnW7tzyhliPpec9NaeeXHiLp5p2NSKvIW2ONLsrSVKw+sKDD3OsI4fGKPP M05T619XGLBXi3rHm8DU76xX/+b8pU4BJy2dDlvcAqg36A729iqYeu1Bq9+9BVbcard7XsBD 1un34kpgjQRNCmPdC65z4h9GkYGnYSe6OLLOW7oR8T4qfSikrAOyEvEYVqng8UiXXvAN/odw 00RaN3VLycMqgA2N8I3KORhmwmYpn51WuRG+eZEZ2ORT6n2r1xk/b0/ixvCw/6zRmRz0G4NJ p9sYHEz24k6nNZwM4l8i4pYFgLJSpFyVedBqsIsE/KOIq8braYQt3dHN3/YdwtEBPH5DToOO GWXQ82OuGpxWicfsrQ/MhhDSBBvc0xu332p7KF0AFL6FHVV6Qg2F51/XTL7epwpnoGAdKXCh IsA/06AFnNs1Fc6EAw1CEqMw1Dl8R/LfmeWeaUW2CpbzqiJEGQzqxMPOsNePh90VPTwngqFq TROfZNBaJLXt98gyTo/UM/M2sNFTERX3pFQMmR5cQAx9JO6VKUgUEMnmbiw5RerekTbXl79e X/5Bri9/v/rw59WHv64+frz68FtECuFYdkhzIUHDdgd0zKixHFY0WvHgjjQ7MILKG2KB1sif Vca5/ePShTYEf8jP1pbckkftHzYp5rEDl74k1DCvKuJjrRx6AjmR4ESmZcoNib2xXx74z4q1 j8ytgtfp9tEtQ1todYbtQXsFXt0cBnE83NS7btwd9oLFwKLSFNL9s2vVA2ZRjIIdkVQYF5rY ruTT2CwLp9EEtNNMS5JyR4W0yVZGoUiuS8m/l6zYV9ad8XRjec2MQI+qF8mFDBXiIeO8U96v 68YUR7zSJmQT74IbJ1A+zrmUjVKB5NZpnW4Fviol3xYwq9Hb/eHDl4VwruZjaciCInSUMRSq mulbkltt/b+rzxXOWyB+Tq/ZLe6ssychuXBiHqYE8mDOcYOBB6PDjrTWiZ4+mGs74hKhzlGM Jj8Rw9OS+UODxpAbJpItXz8h+kNWxN3sfAely7QR70JSN50prSM5VXTO/Vy93QA/gef/0zjO jifHCZmVxmU4BqbCstL6SxIixYyzJcNQQG2B6RFJxnxLwe0EdZwIHE6pYpw82kq0hyyGW/Xe mvmbdV84PMSZvT47b4l9o7ZwMH5OmC4x2xaSLonRgA148q+GzTfy836TSDiMV1dKeKxvmZg0 L2lxvAiTGS7PHDcIKF4VqFurqXIjgmlQ5PgQ5kKFC4kwYlIshsYzVV9LpSV6jMDpZiaUcJg6 cd/lqMEEpjgqIUYeXLSchTsEl59q7VZjaOE1wThXqfZPq+288Zjj/wYAAP//AwBQSwMEFAAG AAgAAAAhAJTWPPnNBQAAhRYAABYAAABwcHQvc2xpZGVzL3NsaWRlMTIueG1s7FhNbhs3FN4X 6B2IWSWoZVljSZaESEEs22kLJzYs5QA0h5JYc8gBSclWim6S8xQt0ALd5DY+QK7Qj5wZyVLc Ri7cRotu9DNDPvJ973sfH9+z5zepJDNurNCqG9V29yLCFdOJUONu9GZ4UmlFxDqqEiq14t1o zm30vPf1V8+yjpUJwWxlO7QbTZzLOtWqZROeUrurM67wbqRNSh3+mnE1MfQaVlNZjff2mtWU ChUV880m8/VoJBg/0myacuVyI4ZL6rBzOxGZLa1lm1jLDLcwE2avbKkHz9hAJv7bZkPDuf+l Zi9NNsjOTXj9enZuiEiAV0QUTQFLVC1eFMPCX4Vh+FFdmz4uLdHOzcikvWe0A9/ITTcC+HP/ iUm0w28cYflDtnzKJmf3jGWT43tGV8sFsIPFot6r3KNP3WmU7lxwhpiPJSfNhWd+OHE3hxp7 qkV+hzY71ezKEqXhdQ6G7k8wj78wRl9POE2sf5xjwF7PyhXvAlM+s9785fUrnQBOOnU6LLEG ULPVaO3t5TA191u1g8YaWHFtf7/pB3jI6gfNOB+wQIJ2MmPdS65T4n90IwNPw0p0dmqd3+ly iPdR6RMhZRmQYojHMKeCxyOZ+4GX+A7hph1p3cDNJQ+zADYswjcqx8gwExZL+Ogi50Z454eM kE2eUj/W2ketk+PDfqVffxFX6sfxfqVd3zuo9A/3Thr148NW7bDxU0TcPANQVoqEq2karBqs IgF/N+Kq8mYQYUl3eve/fYtw1AGPX5DTYGNEGex8k6oKpznxmF17wWwIIe1ggQ29cb1a7KF0 AVD4FlZUyTk1FJ7/u9vki3XycIYULCOFXMgT4K/ToB3X2mUmDIVDFgQOQxdKCt/D/XtJ7hMt mxSxct5UhCAjgepxu95uHsTtRpEdPiXCPtUiSzzHYDXrlFvfgGScnqpDcxWS0WciBPd8qhiI HlxACH0gNiIKeII8sqnrS07B3HtY8/HDzx8//EY+fvj19t3vt+/+uH3//vbdLxHJhGOTE5oK iSzcryMbJ9RYjl1UanHrHpa9MILKO8NCVoM+BeFc72zqwikEf8h31k65JU/ip0uGeeyQSg+P dAwfcwnva+VwIpBziYyYaJlwQ2K/138e9weF2gdmTe7qjQOcleFQqNXb+639ArvyaGjFcXup do240W6GHQOK3FIg+4OV6hFJFEOuI5II48IRti10+l4LhQNAM24tEWlGmSNaEcXdtTZXnRVe QSkXevJ53Yq9vG6Nw8udl/kRkiQ/kORMBp14zHBvlfcL9RigzpvaDnkllEjFW46KRVWkZlQS ptN0qgQLhSAZSX1tySVowLkiP4AlXnAUahKCErjkB0mpomPIg9MrTMkVaB3hGBX146lyLeT7 1iXUOUUiebyIUHnRj6qcjAzqrBUUnf4ERA/sJWVX/0PpTwDXC1AyrUZiPDU5LTNUTSl3uKXl kBY6dYeHqyg/ueJzu0OkUFf4GvnJ+Z+nBY3FeHKpDTE808ZtFKbdDcKD29AjMv1zSmo1al9f nHvYwr2T96UhMwpVo4zhKC/PwpWRK2Xvf1fA5BK0AuJDirHPgfGFvOqAT1TOrVicohd6Cp6S Q0It6CXpfIfw3fHuDnSB4EVqiR4RJzwhKcothvca7YdwV9wJ7Hw0jLhBXwGc3JIS9kgPHs21 LXGJUOeg3Hb7xOEL5cPw7OisgxNurJ3IpRtszwsNr1DJFHfJa+EmGFJIcKgtcGISfsPZ1Pey fIKEkxT1qdNMy//RDZdW18vRTbXx1VghO8DrjpoI3AuTKUdhRoaD/rdr+bashv++jt+W6mq5 37J6x32ubAYUfYzwlXcp8bNsXDJpXtHsbBaAQz8WyouzEY8y1LNFp2I5BEZRFqtx6DUo9LhC 24JiMiwOUdKhLQUdTabQU6HQu0JZ7NDJQAvVUYNbveKQcNyjUScPQ1vKpRdau6K1geoF+8ci uWn/q1jObx6toT8BAAD//wMAUEsDBBQABgAIAAAAIQAYwdwA6QsAAFRhAAAVAAAAcHB0L3Ns aWRlcy9zbGlkZTUueG1s7F1bbttIFv0foPdQ4FcPJo7FhyjKiN2InTg9g3RixO4FlMmSRYQi BbL86s/0egYzwAwwP9lNFpAt9LlVfIgSJUsaOVI7RACbJuvBqjo891G3bl78dDeK2I1IszCJ Dw3zecdgIvaTIIyvDo1fL073PINlkscBj5JYHBr3IjN+OvrhLy/GB1kUMNSOswN+aAylHB/s 72f+UIx49jwZixjPBkk64hJ/plf7Qcpv0eoo2rc6HXd/xMPYyOuny9RPBoPQF68S/3okYqkb SUXEJd48G4bjrGhtvExr41RkaEbVrr3SEUbmn0cB/c7GF6kQdBXfvEnH5+OzVD1+d3OWsjDA fBks5iNMi7GfP8iLqT9jFMPF/lT1q6IlfnA3SEdHL/gBxsbuDg1M/j39RCV+IO4k8/VNv7rr D983lPWHrxtK7xcd4A3KTmlUekSzw+mZPbyCHtEH4WPZryLBrHJwugZHC28T/2PG4gTD1bOQ nAxRWrxM0+R2KHiQ0W09eP/dTdEVzQh1Ph4yeT/GvMlQRsLAXGKgjtV3+m7P6nfzirq0mr6i gQxLoOZW3h0nwT3N0yV+q5v8IMrkubyPhJo/jJIfoDf8wGpFeLtDQ8R7v54bLAhTqaaUZSN5 EgkO6HcMNelcvdiA+3i5r5//+fXzf9jXz//+8um/Xz7978vvv3/59C+DjUPpD0/5KIzQiO0Y zB/yNBPy0NgzLU+9vOqUGpRH74S8TdKPgD77RxLG9PtH868vsDgS2FCviJ94Wwy0GBUu9Sot XKsSfdVaudQ7AFxM+eRaLb1CetnictVo0tnl7S9JgEnh1zJRUzWFXduzuh7IAlNi9rqW25mC cb/foXuMsOx2+vnzEqKYgTSTb0QyYnRxaKTAn+qH37zNJL1SVYQmNkuiMDgNo0j9kV5dnkQp u+HRoXF6etLRvaNKrVgUs9tDo9+1uqrl2jPFXKJsRN5p+E61MAqlAJjC0aHhoZNikIT413Gg cCd5GOlrdB/Fal1pBmldivUtUMtuU44PKAa1GozH/jABFfoypVVsgjMtBI+uANeyENqdQvjJ S1D2b1gGNd/NWNdvevQOS8pe1rAI4omDM57yD5NfzZw282VZA7vWLM9sD7uW7dq93QBvp3Pc OVWfTgveeUSdg/dDck0f4/Ejwde/i89zSXlCl9OyH8LSLkB8LlMeXg0lO0niGMSVpMypxGZZ nR+oRgvhqQn5fMjH4kJJwwmJWdYh5aFSIyZuL8XKnme5Xa1WWHbPdQByNXuFcmGDq3NStrxO 1zTVWwN6BbtPsXIUgqmIceawcpwQJasuNNmaVo9YvyItRdc17iaV8UHiTZPrnF9zrs0VCE2d YPVsZLBIgBlxoQGiefiBctMcDcmr1khJ0YcRAOGv1aUmBCg9Rgnjctm+EQLYIArHP5MKRtOd a5eWZ/YdWgxIYDCeBTW8DgZTCXAS0EVRTGSLBUUCCxWxboGCXVDEumbH7S8SZiY0bIWDx1fF +tarDvhFw6imbn03qpjmoqOTupaFr2odjd/dVaBZXdOZUflboG1H588h9/Jawp4If1M+jpqS tCb6eruKPtvquS36NMtuyeLMMUc6OTwcm0AbfAlatbqAsnqc3DEtSErnBiNjGm4jreNULqnH dXO4Pc+E5a/9HH0Itxklqm95ngnLgKSrbeOy8AjNUakfcnTMqNSl/2LiySP6JZTCPgaZQLXP /TDa5UYPlvG41XwHOU58kcoQ/lwuBQuz7Bq+D7EJ0PRnQKNsqm2DxrEdwoHSvJskpeXacErl hljXc3LVfL7u/cRAs7pfK8fRSIwusXkB9z+TIpPPWAOIlKqFHyv7zvI+BrB5965g4MciYNz3 RZYxP4llmkQNva3qxfWw6lM8V3kOyOuwJZ7rev0e0RixWJN4tWyr63pQCYjnWsgSGT7gis3h 9PczxoMA208Z41kWXsW0nfWsAUn/L27hMiFZzMJ4kDQ0vzJQy+2GUiDbZNltmVutLhxxMMCB wsLeUBNdeLhM23GJTr9XebwU7dGmWLllkOO02KyKsUewCfiUHv8SPs4uwKfjmLQfNB8/Xcvr ud+vPrc2ft4JeMQv4QnfFICwBlOCsnKwbk9QdjueUsjnA8iy7H4LoMV7lk0EdC5SBKY8Y0L6 zzdBQKWvviSg+o7jdhStnuli5yU3KHPPbF2AWa6LvfVWgC3a867hh4XkFcjFGOJMYGZGDNq6 yDYBo11z9mtfPtQfp2N7rRcMyw6zebtesDdwa9zy+02grfT4l6Sl3ElbVrrdvq18FCT0HNN0 iMDqpIVdX+s79oItpTU1OcaOuf/xEuFAz5gfJdfBJiC0a277irAAm5awdoGwjhHgexsGcrgJ vM047l1FDtumLNdFqIvWsxxYdDOUBTXddlvKWqynN1HWxfnJz4zCJ4NrRAv/eHbyetno1jLS Jr4pI2QUTOD1pPBqt5R+DeE1bmX95ZXxJS2MliIfXbEJk8fEFEggQWZ1uj2Ki6gJssJx1CEZ V0QyFI2sGBxFSslUPOlyUafUzyueDXV8a4AreslZNSej4Ge1LRN/EAMdVZ1vj9WDrMiLHcsi wjWi0lRtgNitsqIOiJ56wXrFvDxVFYMB4t5WqVzWUD3Dn15WHoVxkqrIpaneq6DcgS6PSUCk tB71KpFbbrlP1ASsSsMqUamiYvGXgqV2OKqY9ZUj9miwBXyWxaBld0wK6CFPewvBJwLB6qRF EwT79IErKtwQt+WxfzVua3E1GXj6VHBVbtM04Aqg2yyusLFtz8jMFldPEVfl/k0Trqooi/X5 qmt6+sgK6WJN8cktrp4irsptnSZcVaEQ6+NqUse3u57Z8lVhGzxlFb9Xbvc04aqKXNgMrhB0 r9xarX5FJ3mfNK4WmY69GdNRqVsLTnAV9mDjiZ2+6aiDGiQQmxR4Mw9A3aplOOc81kgE+YEs ulLfRX4ytjj6nYbqfLlBZ3JnSrfODXhk1nNuVBGFTcy3tmX5EEJthLDOOFV3AqHN7jN+UEeu XIhHnNavnSdcXLpF7/roXWS/Atpr2q8Potczq+P8ZezgLvDrcugtz8HOMGmLXOWpfXynsrfI QvbWtpAfQq7Ts5SWUFM9/0S82yJXbeVsczvEW2SDA9aPxLmOhWw/0xtufyLkLtYBpnl3Ps5b bWGutrDg2L3VKTWFIjYKOC6gur2AYNPs2HZ+csbCGZpZndjxrF4b0Lk40KAW0KlEmzyiA83Y tqZTg8j5tmSoiv9AEg+vjOdssJa86ojCin6iRqldGPEUbdDsicxDELZq0C+ncK5GfotLtwQ4 lwAfhG8Z3dcE3yrAfdPwdZx+d4bZigiaFr5tII7OnbVQfpce+lJ+93ZAfquUWHmgoA31dGa7 CCe5kSerPZCxMAnhPPm9wYQkYJvpE2E6vdmWI01t06McEOpIYXNwPE5q2MVp/+8wRcRSwfFN AEJ2vUF4dZ2uov/NZ6B+aT9Uabt2wYBwusoqJiWx23VnM6l6Lv4RQVE8YL5FBA0ZSlQRWEga 3AqpVCfyiEyl5Zp4suEMI0qln80eQtAY8fQt5dW1+jTIMA6g8yO1bnFD8LfxcfqRdhkZ5RzG Efez69hHkXzbcewf63DWbOyf+VIHzYLItacB04T7eYlADJDmVE8euqbNuPmH+FXCPPZRpLBc 0HeZWJVqURrqeCJ18N9G8V4kSZohcnQypzA9EFw/8LOpGn5GD/CGyFhMNZE8+P3F6wPMAcuS kWDiLszUkX4+Hke5GZRN5bxYZwQzaZAfazh5ys6a6bbOCz/mlB8jx4ek3AyMsos3HeKaSMzQ YrXCahJH90hiHDA5DNNgb8yRZHvFlQ7p4OY3/sTqKWN2DY3jNLkJA5Gxy0QOGZJvT3hA1GTT rVKpej4134tSOWs6u/x2M169jOK4xvyHtOOdJ92neP48D78fpb/w8fsbRYr47wWQ9heJunFr DPInxkTRqgjSbIfY7blSyfdiJA+nC6BRBVRf6BB+oCy4Rq5tki7I74Os3gY+d/xHBynkSCxw 7hyqJRJf6Ly8cvQhSRSboyfVEn5L3TRd5d3hEv8nwtEfAAAA//8DAFBLAwQUAAYACAAAACEA 6eNuF8EEAACxDQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbNRX3U4bRxi9r9R3+LRXqYQx GALBxY7AhKgqJQg7DzDeGXtHzM6sZmaNnUvyMr2pWqmVesPb8AC8Qs/Mrh2bEEgqkFpfrGd3 Z76/c76f3X89zRVNhHXS6E6yub6RkNCp4VKPO8n7wXHjVULOM82ZMlp0kplwyevu99/tF22n OOG0dm3WSTLvi3az6dJM5Mytm0JovBsZmzOPWztucssuITVXzdbGxk4zZ1In9Xn7NefNaCRT cWTSMhfaV0KsUMzDcpfJws2lFV8jrbDCQUw8vWJSF56lfcXDvysGVoiw0pO3tugXZza+Pp2c WZIc8UpIsxxhSZr1i3pbvNXYhkXzzvHxXBJrT0c27+6zNnyjaSdB8GfhikOsLaae0uph+ulp mr27Z2+avblnd3OuABYslAavKo8+d2dnc3tn7tG5SAH7WAlqLZyrTjBIODHphSNt4G4VBdPL sFscWGsuM8G4C48r59PTyVxViEhQXmTkZwXi5qVXIkEs4eh2a297b2e3tfeyPljtjuGbC3CA IMbWTw8Nn4U4DfEfH7K2cr7vZ0rE+MFL1oY2XICWgnWdROjG+35CXFofQ0ou9z0lGKi/kcSg s2jYiKUw7vb6t9vrP+n2+o+bq79urv6++fjx5ur3hArp0+yY5VJByNZ2QmnGrBO+kzQ2W6+i 8VFpEOi7R2IC3tIbbY0KzKW+F4XbBzge3Igm4gpr4ejcKywrlB7EavdzrLaCdhB4HvKnxCoE +hmhArKUM3sC4uxu77ReJqQmKpJLao64hehWL0Jch+Wx0X4wjVAPy1MUJyxDIAPD7gO+d4BK 9qGTtFB+EhpGyfcTIcpcAMdKn0G9TGOtWMHtcTUPKlinU8MFHRDKK52b0gtLh7SkT5BgaUYG Bti4SaAUD5V0GTFyIJ3gdCFm9MIZYo68Qe12pRVkdGNsUGxXhHFKTZ6XuvbE/bBO3+iNfDxo g0w6wDgjqSdGTQQ5YdFe6OejXjQxk5ZTwZB/6yvKqxSIeRAx/G9R4QAcMFZ+eAYKLHDnIpVc OGBHqKAB8mZmLgOogRFBuyBe1ZIDeiFHuNFS8DXy85CjpZXKI/KkjIOgEQ3BrEvJffYsWK9E BeakMkwREf1hsFWJMfOgKFxYYoGxNaG3VgjweC5V7BsyJ5QMo8jWBn5fKuZ1Dlv+r5Q8mLaN SN8ai/8Ti3tGj+S4tJHFzTNmMbqg5jwzraXzVg5R3Bzqz5IB4Gk1HgbOgCJVLVwjV6LkoZp9 I3D3QxZagZvlS029P8uHRt1p4puYchdNPM47oTFXncR3b69+pZ/OiHGODHOwzcmxjq08uPAj hfeH80xrlo6NRXAVfmPG9a7a0MdkzEswdxwdRwbrVJVhzg4Zb0Vjqe6HiBRGyXQGlnkm1RPX 6ieJyqLSozSNpUam08iavE5uLfylsRd1lrg1AtaoaxLYSk8s9SGOVFgzvdMIMPhqHrh5vjy1 rTbvR/rQl8apOFVVEz2W8yE/VfYXVrybxLEB3y7IiF58VACbMFNg66ctmNFkjhdhyvL6xGGG wzjLcBjbBnr+VcBLfNOEuWUktfSYcMEcj67XSbRAO8Tghs4/qEbg/NwYX4+8URI01qLDqlaH JT64uv8AAAD//wMAUEsDBBQABgAIAAAAIQDJMuUt9AQAAKoQAAAVAAAAcHB0L3NsaWRlcy9z bGlkZTMueG1szFjNTiQ3EL5HyjtYfQIJGBh+FkbMrAib3csui4DN3eOumbZw2y3b3dA5ss8T JVIi5cLb8AC8Qj67p4EZJkB2YTdC6nG7y/X3VZWr2H19nitWkXXS6H6ytrKaMNLCpFKP+8mn k7fL2wlznuuUK6Opn9TkkteDH3/YLXpOpQyntevxfpJ5X/Q6HScyyrlbMQVpfBsZm3OPVzvu pJafgWuuOt3V1a1OzqVOJuftU86b0UgKemNEmZP2DRNLinto7jJZuJZb8RRuhSUHNvH0lEoD WCaOVRp+XXFiicJKV+9scVwc2vj5oDq0TKbwV8I0z+GWpDP5MCGLrxpkWHRmjo9bTrx3PrL5 YJf3YBs77ydwfh2eOMR7dO6ZaDbF7a7IPs6hFdnPc6g7rQBocCM0WNVYdN+czbVut7XoiARg Hyti3RvjmhMcHN4bceqYNjC38YLZz0BNe9aas4x46sJ2Y7w4qFpRwSNBeJExXxfwm5deUQJf wtCN7s7Gztar7s7m5GBDHd3XMnCAIPrWn/9k0jr4aYjfuMl7yvljXyuK/oOVvAdpeAAtBe36 CenlT8cI6NzvK+II+NUkuppHdUZcQKXry9+uL/9k15d/XF38dXXx99Xnz1cXvyeskF5kb3ku FdBY30iYyLh15PvJ8lp3O6ocRQWGfvCGKkQrOzKK3C6A8IiDqA6e0AxGtRZg2SDyIC7r93FZ DzIRrK17nxOX4NT/CEuweyaeNzZfIddjUK9tra6GdYSmDe3tLfwFghDgG5vdzZ2taNTdwA2I BzNbdz0CeKQGTfnWaH9yHsUNywPULiyD7wO3eXGxv4e4+LWfdKPGwxjVqbQ+pt5UxESefnBg UlqZgvZxtvMZBoVcnd+JweM6Hxo1E3NrKMU3MReTMkRUY48fsA+8ZrmpiEnNUK+ZKT0zI6bJ nxmLZF3wGfcsB9WQGFeSNPOGSb+4xM6kz5iSHrnY0oNQ8zGFUstGpRahyuKQr5nRbGi4TVfY jPGk00Nu+dHdbJvnVfmwb5sEiVlyA9c3gPMI/iL7fwMUUOXGEvOSUgALwDhrLr2KVB1u5iEw k3pkufO2FL60NMEznnNlURgLCI19ArI28JaRJReCnGMZWYLQBVoZryyxSnLIH3Jxugywmaud p3xx2mffCb5jsuhi7sXk/fo/HZEvmJCH1lQyJTcfpJiik9y8m2sTwJYYIScJXYb2li+nJrRL DCDiHbuTd6Q08BnWS0j0EVl0VywzuRmTJlO6QE4V0jwjnLnZncrmxRmPfWv0nqX07e9Nh+CD dXgj3DcvCPtsVfyOEfiLKdGOu5j8KA4O/aSlFBVdcuWWWOlKrlBEQmCNRkpqYme8foaAeOpF 8Pwo3EoexMs+hFfsA5+pLZiv8aQhQMJ7I4xy8GhlVBXSEY1lJm3KCo5OgnHnMLxgC7MHEybP Sy1FM8DgLp66Tl8iER/U3vNTYoVCCxzLPHRkkzugMCg6bOEskyJj0t25i6bvndlaghHmiR3B vyr2JV74OqFfU5BuJX9Z9N2evx1Xpq+rR9rSxl33Z4s4YjSjLJbtdCuU/cCLj1WsUBjacUns x60CkRu6ZZDekqADlzk+xF5cv3cYaDDHcRwG2Ylux+G0xDAvdUojqaXHaIc52yP4+4nGXWQx xaBtPmlmv/zIGB8HpwmnoHnDOqwm4rDEfxoG/wAAAP//AwBQSwMEFAAGAAgAAAAhAAxvseo7 BgAAbxQAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWzsWM1uGzcQvhfoOxB7atGsJa3+lUiF rdhpAScxYgU9U7uUlg2XXJBc2WrRS/I8RQu0QC95Gz9AXqEfubuS7dqGbDhADr1Y9JIcznzz zXCGz74/zwRZMW24kuOgtdcMCJOxSrhcjoO3s6NwEBBjqUyoUJKNgzUzwfeTr796lo+MSAh2 SzOi4yC1Nh81GiZOWUbNnsqZxNxC6Yxa/KuXjUTTM0jNRCNqNnuNjHIZVPv1LvvVYsFj9lzF RcakLYVoJqiF5ibluaml5btIyzUzEON3X1FpAsviU5G4X5PPNGNuJFcvdH6an2g//Wp1oglP gFdAJM0AS9CoJqpl/l+JZRg0rm1f1pLo6Hyhs8kzOoJt5HwcAPy1+4tNdMTOLYnLj/H2a5y+ vmFtnB7esLpRHwANNoc6q0qL/mtOtzbnDYvh86VgpLexzC0n9vxAQadW4DQ0+bGK3xkiFawu wVDTFPvYvtbqLGU0Me5ziUH8alWfeBmY+ptx4udnL1UCOGlhlT/iGkC9QXfQbJYw9dqDVr97 Dayo1W733AIHWaffi8oFGyToKNfGvmAqI24wDjQs9SfR1bGxTtPtEmejVEdciNoh1RKHYUkF h0eydgvn+PXupiNh7KldC+Z3AWxIhG1ULBFh2h+WsMWbkht+zi1ZIJocpX6NetPB9OjwMDw4 6ByEneZ0Gg6m/edhO2o1nx+0pv3Bfve3gNh1DqCM4AmTRealapwiAP84YDJ8exrgSHt8+X/z C9zRATzuQEa9jAWNIee7TIaMlsSLzbWJ2HgX0hEO2NEaO4kcktbjCdP8gTI5oZrC8M+rJduc U3rTR2DtKIRCyf/bo6DTHA7rQJhxiyDwFEZaqBl8A/Vv5LiLszytXGWdqAA+Rvx0omFn2OtH w24VHC4ivJ5yEySOYpCaj2rVd+AYo8fyQL/zsegCEfn2pJAxeO5NgAedI3biCWiCMDKZnQpG QdwbSPPp4++fPv5FPn388+L93xfv/7n48OHi/R8BybmN0yOacYEgbHcQjCnVhkGLsBUNbiDZ vuZUXFrmgxr0qfhmJ6dI1IXZMsphhci5t2dbzqYyY0+VtLgAyIlAAKRKJEyTyOn2cD/fy7XO EdeyW6fbx9Xo74BWZ9getCus6ptgEEXDbXLrRt1hz2sMKEpJntz3TkyPSJoI2TkgCdfW31hf Fn1GN/DHk6jMz2IlfNw8Jhwu136BcLBYyaSu+khezAU3KUuIkuR1bNXchUL/CYmarc7dmD0m Vl8mdX70WeJ/6viLw05+UvpdyGWYa7VEBW1IUtXjJKa5LTQuHGJYjIFdE6rjlFsUWIWmgiTM 8KUkoJ5BzaLLuv0JuUKw+1xQ0R3B5SsvO+EyFoVrZXY7xZVHO0i1KSM/Ky5RQaoYGDwlC27J GbcpGTSjvVZ3r8Mas9PpD8TkLOboWrytT8mS5oRKKtaGY5Mr3OxmlqgFUYX1rZZTmBtTMBRi KbVEMsSmVWTOCE0SBztLnjogrebzwvc/mD6jOjH1AicCm9Hj7F0BuLw1Hy/r7QjZtNDaXbZV ozlyyscstwYpR6yfoIO4ipUh36yZ/fZu1R+YfLzKdySbijunNYulsgTKkJxq67wEcntbejPu fOxqG8v0w1V1hcC8OII3Z+f+7HnxCq02hs5ZZcW9LWnvLp1vv3mNQqfgWhl3nNHL+VRosqK4 8qZTVHp1xXVl2ZUO4eHFHszY6v/gwm3Tas9cOYQulPjaeVOt3daaft6GtDWIBp5LqHd6SEhu 7J1Y12y9frO7qdm6UXvQL0v+umSDix/ckApJzsbBEIVg4Lx6qVXNkHbRZfFsHECjyr105Dry Q5mUDKdclGP4R0hfSt/W1XrO5Ptoyo941SOX7a6buKvbja0u4di97/D96S01U6n4BC9JCxty Zhdhz3I8OYX1lRNeunJYyARzT0UmbLauhOdlPt4dT5uGeatQFZfO8mut/cbYLdsfLh2lfN33 VS2r/ynfozCsn6hioV/S/PXKA4yXN/gdkY1POa4ApyuWbpdAKM8w4dtKidcM36FSbMaymazf tJICL3Jc4pWCSzApILhzLNLcOJAMKRwtFF5pZv4BwmZvlLLOyTgJKdL/2lI0vtTHYYjnwsm/ AAAA//8DAFBLAwQUAAYACAAAACEAj1R5Im4HAACjLQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU2 LnhtbOxaS2/cNhC+F+h/IHRK2vix6/VrkXXgOHHawnEWXgc5cyXKy5oiVYpaP05F8jfac09F C7RALzn1pyQ/IH+h31DSPvyIN7GdBoEuNrUkhzPDIWc439x/cJwoNhQ2k0Z3gsb8YsCEDk0k 9UEneL6/PbcWsMxxHXFltOgEJyILHmx8/dX9tJ2piGG2ztq8EwycS9sLC1k4EAnP5k0qNPpi YxPu8GkPFiLLj0A1UQvNxcWVhYRLHZTz7SzzTRzLUDwyYZ4I7QoiVijuwHk2kGlWUUtnoZZa kYGMnz3F0gYkC3sqov9Zum+FoJYePrFpL+1a37077FomI+grYJonUEuwUHaUw/ynxjA0Fs5M P6go8fZxbJON+7wN2dhxJ4DyT+gvJvG2OHYsLH4Mx7+Gg2cXjA0Hjy8YvVAtAA5Gi5JUhUTn xVlptFYrifZEiG0/UIItjYQrZnBQ2DHhYca0gbiFFszWAKPFprXmaCB4lNHPhfDh7rBaijRC i6cD5k5S6K1vopMAqoScreZ6a31ltbm+XM4rBnvtVfMzvwOVWCO9tZZXYVNeeY1mY53aUypc W1xsLNIAUuTyytIafvCLVJSwSEE6bbvjh+CJNoB48xvI2ypzPXeihKcK9fE2GGEJtzsQc7W1 0lwOmBoqrwqpIxhWJ5grOzypfNtot3/s5/fzXRwl0o0nQ/1QCv6ApIISO4HQc1ubOHennaDp Bet7ypG0zlsCyxK3pQTHiV0MaGqYeX3GPIRO92UiMrYrjtieSTgOWSpdONjmiVSY3cCBDgfc ZgI8VlrA0kTGbfREmFvpTtrEnPMsoocYpf6PlnyCuxe4A+h2wXGd4qs5wVaz2L5+DqOynttO 8O9v5Y6VJnCVyj6BsjZzN8BWy5A7EbFDccL4Ae4Lup7YHalDNc+62727tSqvtrun0skDfxmz KXVdfTTG+yws/Ahu5Fs7HI9M76OZuzWmGHeO02V8p2/cgFnBQpOkeeHZ7tFHkmsyUbjJ2hRn uAIf62jOmTmhI5aVtyG786ORGpcWPF4k2DCbR5dF1MTudLce32M/0B/hwvm7N6jhz9dJdK0c 8rD2EbM41O8kOTtmYhaJIeJXxDrkMtwJmzSpqWvlWt7287WarcmbqI4vZriJnuLOSeRp4RZh QdroOWVCrliszFE2ZTRXO8o+z4SS9IZbQiyMYHjsOW/NOX1zhkdcql1u+d7lke7tMTVe+5oB 7Wd9xCrPXx+wGQ5YbyBjx2JrEsRJOnMWOQlE8t7JO8OUyLJzHVMW/YVe1U+EFpar2oZmsKE3 P//SEykuNQqwyc/DkkJhdfbm519vzlYoffBlPqLPOrlIIHWIGCmUYtrD3exZG3uD/yvnMubg mv7olmxjzN8FGroigKCsrJ6w1w9NSV0/ozXmvtbuRGatTIxeN194Y9o9F0uNKddWRynyIqV7 U0nTL027yNtX+Xqfwids4XJ4o3UVtsGIGKCIhk+qj1GOmbENSuoT2jOJV7D+0VNkjToBz53x hM+gPq3VZqtFDzJk59cbvulxggoAKtCN96AXSMzbzD0RCGOp0QkssBu/Eh/uZK5EGsohlMfX Zlsq5RdRmh1h2WUgGGd6EumQ4FIy6QSAS+jC9xMI3HmsI992XKqiDeestBf+MhyFQEawNjD2 NGBHlgM3yn7KuRVATr7XgIu86AFz/sPLHDA72dOf7NF5smUKwIXrEFQ7gQtY0dxy+CJ9IRHK 3Y7upWG1p6Sf/eMX3Kalqhy0vGt6A56KizRWjPUupICDSEmzoEHAhvY8E5fBQoyrA+A3Cu9w Ee/zfg9gT7n7zDpIBgEE39EP7aFvx4gAN/0UeshDaeRix92EviHR1M116HEdzydJTo0sDbuh Y0NOChvtpd+z8YiHIj47FtjTCCgDjfGIzRjY0DTdCkrCuLIX8I2yI8yrdzpq3mjAApiK9wsr 522oErmF0uALTGviyjvME5mYH2WxL+eQNpKV9X1nMSTvBEi5QNd4GcpDnGBter4VAOyxHnxj IRlyOYrMDCQ0gd5Knorv/Oc47+L7utaY2HdcnuqgozRxSsvDBX0bJSM6ul75BLULqLjYV3dc 4K1nRok4xmVQ6Sff0eUu5ESmbF8/WhN8Itj7NtFzghe3xScMNOoT165PXH3i6hP32fi4kcMr Xzm1q6pdlS8Vql1V7arq4PDaVWvj0L7K8X1YPmDlfD7AV56hALQqWaQ3zk3VOgL1V3hM3GCx YxOlh0trRaRdZQvWms31FXrJUK1jo9EisJdG4BFR5B18oqQow6xyJ1fUOlp6bkxVJz7vvQ8+ nnoNvHv9+7vXf7F3r/98+/Lvty//efvq1duXf5wp/ltCamZUlDjXaHqZwPGoLvGRyKQFNIfX U4o8wsXYwPnd97IWNbxoVmW9obJPefps6OVCtTLyHHhG4acUL2hSFYaOhyDFBBReH1BuyWm8 pHwBK8dkDNvXVR1wlCPpQLWfMVB7h31GgbHjlPLQAqkPehZGYt8XvbpkzxjnNwWlsESJOC9I U6tcDk2UWG/8BwAA//8DAFBLAwQUAAYACAAAACEA7QLQ6P8MAAD3bwAAFQAAAHBwdC9zbGlk ZXMvc2xpZGU3LnhtbOxdW27bSBb9H2D2UOBXDyaJ+RZlxG7E7iTdg3RixO4FlMmSRYQiBZJ+ 9Wf3egYzwAwwP72bLCBbmHOryKIoUbLsliPbIQIotESyyKrD+zj3wZffX00SdiHyIs7SPcN6 YRpMpGEWxenZnvHLyZvngcGKkqcRT7JU7BnXojC+3//rX15Od4skYjg6LXb5njEuy+nuzk4R jsWEFy+yqUjx2yjLJ7zEn/nZTpTzS5x1kuzYpunvTHicGtXx+TrHZ6NRHIofsvB8ItJSnSQX CS9x5cU4nhb12abrnG2aiwKnkUe3LmkfdxYeJxH9X0xPciFoK714m0+Pp0e5/Pn9xVHO4gjz ZbCUTzAtxk71Q7Wb/DPFbtjYmTv8rD4T370a5ZP9l3wX98au9gxM/jV94iC+K65KFqovw+bb cPyhY99w/Lpj7516AFyBHpTuSt3R4u0MrAEuQd3RRxFi2c8SwWx9c+oIjjO8y8JPBUsz3K6a hexwjL3FqzzPLseCRwV9rW4+fH9RD0UzQoNPx6y8nmLeyrhMhIG5xI269tAd+gN76FUHqr3l 9NUnKLAEcm7Lq4MsuqZ5OsX/8ku+mxTlcXmdCDl/uEu+i9HwgdVKcHV7hkif/3JssCjOSzml rJiUh4nggL5pyEnn8sJGPMTFffnjn1/++A/78se/P//238+//e/z779//u1fBpvGZTh+wydx gpM4rsHCMc8LUe4Zzy07kBcvB6UTlvvvRXmZ5Z/YP7I4Bf7Zd/bfXmJlSgBDXh8+cam4y/qW sKmWaOVCaeg1C+XT0EBvPd+zC7X28qg1S/WS0Yyz08ufswgzws/LTM7THHCdwPYCSArMhzXw bN+cw/BwaNJ3jIDsm8Pqd41PzEBelG9FNmG0sWfkAJ8ch1+8K0q6pGYXmtUiS+LoTZwk8o/8 7PQwydkFT/aMN28OTTU6DmntlqTscs8YerYnz9z6TYotoU9SXinszp1hEpcCSIone0aAQeqb JLi/TiMJupLHidrG8Ekq15VmkNalXt8asuwy53h6UshVg/E0HGeQg2GZ0yp2YZkWgidnwKre Ceedg/fhK8jrX7EMcr67ga6udP89lpS9amERUieNjnjOP84+MkvOWS3LHbBrLwqZ7WHXdnxn 8DDAa5oH5hv56PTgXSalK/B+zM7pYTy4J/iGV+lxpSYPaXNe8UNTOjWIj8ucx2fjkh1maQrB leXMbXSmPpzvypPWmlMJ5OMxn4oTqQpn1KU+hiyHxoaY+XotqRwEtu8pm8J2Br4LkMvZqy0L B7K6Esp2YHqWJa8a0Kul+5xUTmJIKpI4S6RympFIlkMoYWvZA5L6jdCS4rolu8levFHw5tl5 JV8rWVtZD0p0QqoXE4MlApIRGwogSg7fsN+8jIbmlWsktejNCIDmV7ZSFwKkESOVsV62r4QA Nkri6Y9kf9F0V6alHVhDlxYDGhgSz4YN3gaDJRU4Keh6V0xkjwUpBFYaYl6NgodgiHmW6Q9X KTML5rXEwf2bYkP7BxPyRcGoZW59M6aYkkX7h20rC0/VXSx+/6ECzfYsd8Hk74G2HZu/gtyr 8xL+RPyrJDhaRtId0Td4qOhz7IHfo09J2S15nBXmyCYHw7EJtIFLUKbVCYzVg+yKKUWiyQ1G zjQ4I2XjNHzU/dIc/iCw4PkrnmMI5bZgRA3tILDgGZB2dRxs1nTQEpP6JqJjwaTW/MXML/fI S0iDfQphAtO+4mEU30Y/rEO3tbiDCiehyMsYZC4vBYuL4hzch9gEaIYLoJE+1bZB4zou4UBa 3l2a0vYdkFKVI+YFbmWaL7e9nxhobs9rVTiaiMkpIhfg/lkpivIZ6wCRNLXwcWvurBpjBJ/3 +Rkc/FREjIehKAoWZmmZZ0nHaLdlcQOs+pyca5gDYh22JOe8YDggMUZSrEu92o7t+QFMApJz PWRJGN5AxVZw+umI8ShC7KlgvCjis5RiWc86kPRncQvKhHQxi9NR1nH6WwNVhxu0QnbIs9uy bLU9EHFwwIHC2t+QE10zXJbj+iROv1V9vJbYo4iYDhlUOK2DVSliBJuAj2b8NXzchwAf07Uo HrQcP54dDPxv1567M37eCzDip2DCNwUgrMGcomwI1u0pSs8MpEG+HEC27Qx7AK2OWXYJoGOR IyvlGRNl+GITAkhz9VoAtSOO2zG0BpaPyEvlUFbMbFuB2b6P2HqvwFbFvFv4YTGxApUaQ5IJ 3MyEwVoXxSZg9NDIfsXlw/xxTSfoWTAsO9zm7bJgb0FrXPLrTaBNM/5aaEk6actGtz90JEdB Ss+1LJcEWFtoIeprf8Ms2FpWUxcxdsDDT6dIB3rGwiQ7jzYBoYdG2zcCC7DpBdZDEFgHyO69 jKNyvAm8LRD3vhQO2xZZvo9UF2VnufDoFkQWzHTH70XWaju9S2SdHB/+yCh9MjpHqvB3R4ev 181u1Zk26YXOkJEwAetJudW+1n4d6TV+4/1VB+NJWpktRRxdHYSpcmJqJJAis01vQHkRLUVW E0cm6bg6k6E+yS2To8gomcsnXS/rlMb5gRdjld8aYYsuctHMKSjzWYZl0o9ipFKqq/BYO8mK WOy0rDNcE9qbDhshd0sfqLKh5y6wfWC1Px0qRiPkvd3mYH2EHBl8uj54EqdZLjOX5kZvknJH an9MAjKl1V3fJnPL13GiLmA1FpZGpcyKxV8SlopwlAnrt87Yo5ut4bMuBm3HtCihh5j2HoJP BIJNmUUXBIf0gEtRuCHZVuX+tWRbj6vZxNOngisdpunAFUC3WVwhsO0s6MweV08RVzp+04Wr Jsvi7vLKswJVskK2WFd+co+rp4grHdbpwlWTCnF3XM3a+I4XWL28qn2Dp2ziD3S4pwtXTebC ZnCFpHtJa/X2FZXxPmlcrXIdBwuuozS3VlRw1f5gZ8XO0HJloQYpxC4D3qoSUDfjGVJtrB14 SKahi2pVaxTt+lrQtjJ0CgaitVs3T8F3l5RsTURU1WzRlnx0quLZujQ8j2X9uUGXtrB3z3+A tLkb/9EkHXYJxzs7nzeB2LHsOrW1aW6wHRAjPIXYQ0WjrQCx/Elhs43iciU2UdzfXX7Yo9jY GIsXrHJ1AfE7uro3ohhdKjrS/lUtwNcVxX8axbp8dgGX8whejfdeFi+VxSsqR21TI7gO7weN Zbq9nLahj+xuVa7gmMOBY0ptPyOyUVVuocC9zqn1PJnKCRDU1PZcZORbLFdopyR1t+FYNLTa cZrTM1saY8n5BN1XVPgHEfM6SIWvqRWQ7HoCQ1HHp3TYRAaJZrQbVgidcGjUcv+TuGYomeCn SVyMKQe9FfuVAY+FNiBL7mkLt9E0KZH3uKSYNryhgj/QyVwddlDQ5Cff0kns1CC1BU+hxu6K iir++LVVyMA87A0hAv+DDWeuVCGa59AqZKAtn+2pEHs4GCAxWtUPdRpMvQ6Z6YoinV8pmBc6 lem6jBU9y2ZEPFzyXoespwrX0yErHz6tP/TD1zBA23v4LMtz0d5FPXwDFCHXBoMuikKzBt+r ivfwe2/AdRTvLTF2FhoGbuvhQye+Mcw2KqJG/8snaL0tf/KG2m9qOu48BMfJ9Qay1hAmnuf5 i00QAx//8DBKE69idyH6H5fjJHXVYuE/pTxPeP6O+mESQYKWnmkEfKIlZv2F4O/Sg/wTBQgY 9QpFderReRpilypiMA0PVCZaMQ2PwlJ5NpjRxrPRe0RihA6FavIwNLkgi/qzTleUva7YJ5Ej uxFja2eMjqL2selMy8+/T9LnSakoPzHbC5R+EFz9EBZzR4QF/TDrX73/cPJ6t12PfpdLXBA3 93W9dTs9LOI1Qz+7tBihux4K3Ufx2XkuZQyLeIkZyZjqG4n6ZTbledtxxBTAGas/HiEmvtqE Z8jQLFEE3hLjzey+WEOit/F9SmVPXwfl65lON7nfzqpYmuqbcpccuE73eyaW5nSaRFuJpR1S q9re+yaoP1jv+yYUu9AoS5tAAuLQC/eB4u5yv8eJ4j4MIW2HbabEu9qk7qBCAfFNorhFhQaB 7M+B8zcBhroU45FRoT2Mtw/jVWmqwPgmYTxjUnTmQaPtgy3zdzZSuLF+eg5a7fcmxeM2KTSp 3yWMG6ZjE3GpWRSjQXjVeq6RxY8Uxb0svndZvJyfcxd58Qa0W+TFXZBylHNBCZVdfRgDz0db uz6vYf1WK5pKW6BNtkWLnwoO0moN8mQJv0926Fe+9vXYlBWPm66TflhhKMcd2pbKI3Id0zE9 6QzPqBbkYCIVon/eHvPztsgQP5vjNJ/cs0hJ19V74ajqvHpVXJjkP/PphwsZhsAb8PByGrxO Cl9NEeeA30G7NrvgZVAxCt3PiBwqU7ziijbApkuy6EQVmkNTRed4IxQFUtCFFu+eMhgah5bg 3PHSKIHuaGCe0J5RvT2mnHzMMhm4wEjyTPi/OjVtVcNhE6/t2/8/AAAA//8DAFBLAwQUAAYA CAAAACEACRKYtyMMAACNWwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU4LnhtbOxc227byBm+L9B3 GPAqRZNYPIoyYi9ib5xtkU2M2Nv7MTmyiPAgkCMf9qrYfZfeFS3QAr3Zp2keYF+h3z/DgyhR sqzIldcRDNg0OSfOfPzmn2/++V99c5PE7ErkRZSlB4b5smcwkQZZGKWXB8YP5ycvfIMVkqch j7NUHBi3ojC+Ofz9716N94s4ZMidFvv8wBhJOd7f2yuCkUh48TIbixTPhlmecIl/88u9MOfX KDWJ96xez9tLeJQaZf58lfzZcBgF4tssmCQilbqQXMRcouXFKBoXVWnjVUob56JAMSp3q0mH eLPgLA7pbzE+z4Wgq/TqbT4+G5/m6vH7q9OcRSH6y2ApT9Atxl75oEym/k2RDBd7M9kvq5L4 /s0wTw5f8X28G7s5MND5t/Qbmfi+uJEs0DeD5m4w+tCRNhi96Ui9V1WAFtSV0lvpN5p/nb7Z RxP0G30UAYb9MhbMql9O5+Ao4V0WfCpYmuF1dS9kxyOkFq/zPLseCR4WdFu/fPD+qqqKeoQq H4+YvB2j32QkY2GgL/GijjVwBl7fGrhlRp1adV9VQIEhUH0rb46y8Jb66QJ/1U2+HxfyTN7G QvUf3pLvozb8wmjFaN2BIdIXP5wZLIxyqbqUFYk8jgUH9HuG6nSuGjbkARr36y9///WXf7Ff f/nn55/+/fmn/3z++efPP/3DYONIBqMTnkQxCrEdgwUjnhdCHhgvTMtXjVeVUoHy8L2Q11n+ if05i1Lgnz2z//AKIyMBDNU+/EZT8ZbVK+FSD9HSgaqh1wyUR1UDvVV/Tw/UysOjxyyth4x6 nF1cf5+F6BE+kZnqpxng2r7l+mAK9IfZdy2vN4PhwaBH9xgB2esNyuc1PtEDeSHfiixhdHFg 5ACfqodfvSskNalJQr1aZHEUnkRxrP7JLy+O45xd8fjAODk57unakaWVLE7Z9YExcC1Xldx6 pmhL1IXIG43dmRKSSAogKUoODB+VVC9JcH+Thgp0kkexvkb1carGlXqQxqUa3wqy7Drn+HpS 8KrBeBqMMvBgIHMaxS4s00Dw+BJYrROh3Bl4H78GX/+IYVD93Q103dLD9xhS9rqFRbBOGp7y nH+c/mQWlFkOyxrYteZJZnvYtWzP7j8O8PZ6R70T9enswLuIpUvwfswm9DEePRB8g5v0rJwm j+lyduLHTGlXID6TOY8uR5IdZ2kK4spy5jRzZp2d76tCq5lTE/LZiI/FuZoKp6bLOg9ZDo0N MXV7JVb2fctztU1h2X3PAchV71WWhQ2uLknZ8nuuaapWA3oVu8+wchyBqYhxFrBymhElqyo0 2ZpWn1i/IS1F1y3uJnvxTuLNs0nJryXXltaDpk6wepEYLBZgRlxogGgeviPdLEdj5lVjpGbR uxGAmV/bSl0IUEaMmozrYfs/IYAN42j8Hdlf1N2laWn55sChwcAMDMazYIO3wWCqCZwm6Cop OnKHBUUCSw0xt0LBYzDEXLPnDZZNZibMa4WDhzfFBta3PfCLhlHL3PpqTDHNRYfHbSsLX9U6 Fr/3WIFmuaYzZ/LvgLYdm7+E3OuJxHoi+lEJHC0jaU309R8r+myr7+3Qp1l2SyvOEnNkk0Ph 2ATaoCVo0+ocxupRdsP0RFKLG4wW09CMtI3T6FEPK3N4fd/Eyl/rHANMbnNG1MDyfRMrA5pd bRuXlRy0wKS+S+iYM6lr/WLqyQPqEspgH4NMYNqXOozW2+jBKnJbSzsocRKIXEYQc7kULCqK CbQPsQnQDOZAo9ZU2waNYzuEA2V5d82UlmdDlCoXYq7vlKb5Ytv7iYHm/rpWiaNEJBfYuYD2 z6Qo5HPWASJlauHXvbWzso4h1rwvLrHAT0XIeBCIomBBlso8iztqu6+K62PUZ3iuUQ5IddgS z7n+oE80RizWNb1atuV6PkwC4rkdZIkM75BiSzj96ZTxMMTeU8F4UUSXKe1lPe9A0pfiFpIJ zcUsSodZR/H3Bmq93VBPyDat7LbMrZYLIQ4LcKCwWm+ojq4ULtN2PKLTr3U+Xon2aEes3jIo cVptVqXYI9gEfGrFv4aP8xjg03NM2g9ajB/X8vve12vPrY2f9wKK+AWU8E0BCGMwM1E2Auv2 Jkq35yuDfDGALMse7AC0fM+yi4DORA6vlOdMyODlJgio1uprAmrvOG7H0OqbHnZeygVlqcy2 JzDL87C3vpvAlu15t/DDIlIFymkMTiZYZsYM1rooNgGjxyb2ay0f5o/Ts/2dCoZhx7J5uyrY W8ga1/x2E2irFf+atJSctGWj2xvYSqOgSc8xTYcIrE1a2PW1vmIVbCWrqUsYO+LBpwu4Az1n QZxNwk1A6LHJ9g1hATY7wnoMhHUE797rKJSjTeBtTrj3FDlsm7I8D64u2s5ysKKboyyY6ba3 o6zldnoXZZ2fHX/HyH0ynMBV+Nnp8ZtVvVtrT5v0qvaQUTCB6km+1V49+3W413jN6q/MjC9p qbcUaXTVJkzpE1MhgSYyq+f2yS+iNZFVwlGP5rjKk6Eq5J7OUWSUzPiTruZ1SvV8y4uR9m8N cUWNnDdzCvJ8Vtsy6Ucx1C7V5fZY28mKVOxUVh6uMaWmbEP4btUZtTf0TAPbGcv0lFUMh/B7 u0/mOoeqGXp6nTmJ0ixXnksztTdOuUOdHp0AT2n91vfx3PLqfaIuYDUWVo1K5RWL/xQsteCo HNbv7bFHL1vBZ1UMWnbPJIceUtp3EHwiEGyOWXRBcEAfuKLCDXFb6fvX4rYdrqYdT58Krupt mg5cAXSbxRU2tu25OXOHq6eIq3r/pgtXjZfF+nzlmr4+skK2WJd/8g5XTxFX9bZOF64aV4j1 cTVt49uub+74qlobPGUTv19v93ThqvFc2Ayu4HSvZK2dfUXHeJ80rpYtHftzS0dlbi05wVWt BztP7AxMRx3UoAmxy4A3SwfUzawM6Wys5btwpqFGtU5rFO3ztZBt1dYpFIhWsm6dgu8vOLKV iLA8s0VX6tMpD89WR8PzSJ0/N6hpc6l3+gdEm/X0j8bpsIsc11583gVi27Qq19YmuMF2QIzt Kew9lDLaEhCrRxqbbRTLpdjE4f7u44c7FBsrq3iLz9wN6kVuc+KumdK35wzkuH3lawjCdl1v PgiC7+GHNiFIyivZHbwHJqs0wRlJ+TH6eSuinnf8py3PhOfvKB6GNaCXjNIQKjNCYlQ3BH+X HuWfyEBgFCsE3qmnkzRAktJiGAdHWokuxsFpILXejR6tlXfcL1OEYogIBbrzUDVNWYv9b9VZ V/ZJ5NjdQN11TATKReFj0qmQH39M0hex1J+8mI4FQg8E1w+CYiZHUNADDCQijVCpCPrx4fzN ftsffZ0mzsUnaZFVa2Kmfjo5KdvRSvZQ7/hhLKMk+hF+8cM4u26712zkZR+q4c/ZBS/Q7Cxl AQ9G5CadDVmhPM5eFBGiYpDXNEUuQmihjk3RKd/s3xrm5wD1UH2Mvq1CNDzxz+CZHEUFu84m CId1IVIxjCQb5ghlU4hgkguWTGIJJ7RC/vevf2vvjS6PtrKIth56CJsIMIrSFpxUDu4Ij2Av WynpU3Hr7HDcaWT2cepOTxjbNjKPKRDRlxiZdXSLObNx1sBcbo7ulkprL5Uc2AsLQ3wA4pj1 HwLF3c6cW1nvfzGKl2NzFsmLMb9D8fooXrZ746y9e9Nwsbr6S3UauyPiTPdOoXK5wWKO1kPa l2LhUuiu0EM6oshqAhaC0X0JLe8AreyCbXrwOMvkfafRAu4p7zeApkVcCeMpGdZBCK3ycHZj XOB4j6V02o046Kwuw34hihcT7SwlL8f7jpYX0vJiBcupj5FUjv1+A9rtCVimA9mqB0KmLYeu SAW+6+Hgd30YyXXVIU5A4DckYE1H3aTPvFg9usVKfv3tw0i12DS3amtJNDOujheXltqGiScJ 4q5qIQy+8tW6Brc/IAiwincK6mlms8rPUxH0VAUYoVqZuhAc8Qtaqkb3OnTBi6g+WxLC7wHa vsqKlLZCymjN5AtaBnAO4vx7Pv5wpVQ5xKVGyEgEecWtMUQfkuyQtEmCEK0QtNJLMuplisCz dDHmyIxk59r9E19HOEGcVpI3ERsCEWENhuP8kucQMlOBM4tYMeDQtI7pKJOPWabkRNSkSsLf smi6KqvDJYJpH/4PAAD//wMAUEsDBBQABgAIAAAAIQAlJM5zagoAADtmAAAVAAAAcHB0L3Ns aWRlcy9zbGlkZTkueG1s7F3Lchu5Fd2nKv+A6pUmsV7U0yzTU7LG8mRK1qhETc0a7AbJHnUD PWg0JWo15fmNyTqrVFKVVGXjVT5l/AH+hRwA/aQombRIW3KwkZoEGmxcXNx7cc8B+tnXV3FE RkymoeAdb3NtwyOM+yII+aDj/XB+tLrvkVRRHtBIcNbxxiz1vn7+xz88S9ppFBDczdM27XhD pZL2+nrqD1lM0zWRMI6yvpAxVfgoB+uBpJdoNY7WWxsbu+sxDbmX3y9nuV/0+6HPvhF+FjOu bCOSRVThydNhmKRFa8ksrSWSpWjG3N14pOfomd+NAv0/Tc4lY/qKj17JpJucSlN8MjqVJAwg L49wGkMs3npekFczHzmq4WJ94vZB0RJtX/Vl/PwZbaNv5KrjQfhj/Rc30Ta7UsS3X/rVt/7w +yl1/eHLKbXXix/AE5Q/qntle3SzO7ub27tFj86Yj2EfRIy0ys7ZOyhaOBb+RUq4QHetFMTh ELXZgZTicshokOqvbef9k1HxU1oi+seTIVHjBHJToYqYB1mio9utp9tPd/daT3fyG21tI76i gdQMQdGvUnBb+5sbG1Olt99qPd3VRVqGe1ub+1v7pvWiCbRu20za6uqFCMZa9D38N0NH21Gq umocMTMkEBxtowP4AwWI0OGOx/jqD13MkeuO19rWP9QzAglCqcyokTRWhxGjmF0bnhlXavre pz76//7t39+//Rd5//af7978+92b/7z79dd3b/7hkSRU/vCIxmGERra28fhDKlOmOt7qZqvo AR5CN6ienzEahdcsIKcSE0+qkKXPMPgKumeeF3/x6Ohq0UXTaz0Qd+rC3k1d2FqiLmip318V rBbs7cLITEyk7Z0986VRhZ3drf19W6M+TebUBWgjiak8xpDvbe+2djwSjSIz/iEPYF70cNkC PVC97EhwdX5ldKmXncCg6hmCwbEDeVOzDg9yzTLa/SHN0raQ15TrPIxZSk7YJTkTMYW1bWjV Jix7qVW5qPz0HrdrXSs0ssv8TIZq3J6ih0YZTafnll3t6X6EL9FeCma/0a1WrVfGcmm5wzhJ 09mO99+/5fN/RqHfPpEfkLgPMjWEuoU+VbACF2xM6ACeSztKshJyP1ojp0fdr9xg5BZ1qbr/ OlThwAQWpCHwaa6jOcErXWMSMRGii0nn8YB07hvR/ejuPeBuEaoU1cHNSk+oIZGM+CJOMhsp PtEf4ozriYaw002oIkRZ6oR6yYNVJVYZD0ia+xWy8pMIOcw/YtCAkVG6hiKJdQxZOT18+YR8 p/8w5a99tcAx+pId9qkMR9R3/roMupeq0d+GOnQhok8CNsKqFgsg7b7VmNTVumFebQz/kbHT l6y5h3WL7OLNT2KRX8P2xuG1DXKgxVzw1Uj4NCL9SFw2F58fDnt6NGVRqLNLW1jnYAFXxUEP OFD4U2N6Il/Dg1Mq6Vk9M3BbePfwulU9vV2R6vWqSXfMu8T9wk1NEQk6Q/NJDE13GPYV6UsR I/LmqZLIGmOFa4I+JUjE0vRGQWNeOrdp04YmwVPP0LxinEkaOT3+JHr8+y+/dVkC96CXjTru gzb7TPL091/+ujh91elFlyIzafIb+j4ZsgQMEBWibn96snxR3q/yqxVe4KICFy0ZKMgCAkuY sU7rDNxyIxZ1cilhKKd1OaBaeIpKN4oV0HyAKUBaywWokPMmWko0+gqce9PM/QpDnxk5t3A6 L9F0DVaS3uVrZEA7Hs2UMA1PcApK1BNA8tPNbQ1RG/yxoBeU5Rogn4aKwhPKVL1iCMH1RceT YAaYX6Kj41TlCGZeRS8buTgKo8j8SMTJJX52B8joREkcKiRrozDueIBh9arf3KCpAy95YK4V DSN7jbg14gbAvg2f1RQWPNpQyGuPXEoKVkL6c0YluAXRXzjICKbrHlHmg+mzR2S9pFcv4Vl8 KCyQS7mPVsFU8Ii9PFT4pAkFgAWoOubdxC/GVMvn/OpHKpNcVApSPhHdIU3YNInZukbdLOVA C+km4+DmEhyY85l5iNvgZkKjARgHEXIprH9Oe13QE/LRJ1KhZ+gAo8f8hbww131EjgfmFp2M gdAQqPKqWHM7kLA8zbgPKVseQ6R7rh84TfxTX5ER1QIrx9KMWVXjBetP1tVgfDH50EZV46AP 5kKz3Vq9vBSgbiRLLL17XV5Ow9jBhaA9q6y0DYkgSZPr7QTyfpHFYSx+Cq1wC4JHM2DrGWTO Vsk6HnJfEBiWpuEFpiEXXXPlAYWVhvNBfK2NeS2tKxA917woTdn41nysEmCmDCwO0TcFdyTC MB9qUy2fIRCaiMJAzz8jQc3GYpCTHRx1ZSk5E7VYv48ZXUgnO+a5KDPdTH59f9yR1Wkvf475 KqN2yi+cc9BYT9Wyj59nbLlwwzkzA6WeoIC5Dcj+Rmttc2dtmxGaJtDStJmvaKwjPs/4urmb MMtlm5duhMG+GXPduu52Lk/zmG53eQuL5xftK+HSnK+cj4a3fF95IghSkoiEaBYp5CA1ZwyU FyHv6TwXPNjOec5B32w4T3CXsL7q0wtmhnYuFowztQ/N1JZU8+ZKpFxi3LFO0Au5mm+Y10nD Ry89cIcx4gyoHgA9JbNUkYPuCcFT9xgFTEKwiaTkfU2Ypyp+IDNGf85AzcIDX9qYVwNWJNlc wFfkTmbOccyYy7jFaNj0RWk6ZnSxj8CMFHsOLBsUhN0shRWxW9CAuj64leOMkneJHp0ncovF ReZHawHB/fbRzLxYvMUYlWbocUcwYE8LbHeqMSInAhWp07HYHXUbCWCKHJa3BWRp3r3c/jX/ 3pApAlg8SXL5Hc93jwD+YSPN6Eb42tAEmDHLqtT64HAdYCHWtgP/uRvXWWjM87iNzXQiWTO8 cXp2L/zQ+UeDwC8MmithnDagT7vY16t6m6Syy3xnJguA/P7wt1PfxarvmciQRRs0lRf5c3XJ 6IWm8JIVtjZYe9LYvQXcn5MsZSC58Atid8fQIMC5I6nLxpZsEKfsDw0awkkyjKdhL4z0+Q2k H6qUXIbYCp2yOFzVNDMc6RP6sOLqUsgLnOHA6cAeNWBI7Qnqa+g+kWIU6mOFMHPWUdIPB1nO fy/qOZv/CG1+lcKdYzH7iNZyVf9citqQyGr0vk+0XJshGdDkuclBr2S5aVbh0VGxrqzT4R4D iQ1kMSV8EYGdmY41IgbrGo2vGemNSxBMm1dnOhdhOu+XVfg/VlNfjhMoZ34aCs4tWMG6LgVR GmfWZcoFuI8yWV95PufZHcH+YbANnU6WRws6WtZttKy73bhTIadCH8SXFrwV90O4eE0nPw9x zW1bcNsWqu139b18Veha7upb4k69TwZVuBn3mDf5VaPnknIfnZSbfv60c1Vf8u5YN3Hy6fKI gMZqzD7TrgYXHC40OLx5joh5/4J9twgui9eN+JF8TZPvR4Ysireo4IQMoBr4KtEQKhwfqlZV 8DYHnMHJB/o1Dopj+755sQbFzah2zov3kwQZjqvQbyPo48xOhZMKQEBQVB+WwUFRlPosgoCd 25dxxGdCKIOc4BUduiX95LZpfZX/HC7x6pfn/wMAAP//AwBQSwMEFAAGAAgAAAAhADPM6oVu DAAAMXcAABYAAABwcHQvc2xpZGVzL3NsaWRlMTAueG1s7F3dbtvIFb4v0HcgeLVFG5vDfwqx F7ETZ1FkEyP29p6hKIsIRQok/ZO9WmRfo32EogVaoDd5ms0D5BX6nRnOUKIkS3YkW9owAWya nBlyZr45f3PmnKff34xS7SouyiTPDnS2Z+hanEV5P8kuDvSfzk+e+LpWVmHWD9M8iw/0D3Gp f3/4xz88HffKtK+hdlb2wgN9WFXj3v5+GQ3jUVju5eM4w7NBXozCCn8WF/v9IrxGq6N03zQM d38UJple1y9WqZ8PBkkUP8+jy1GcVaKRIk7DCl9eDpNxKVsbr9LauIhLNMNrT33SIXoWnaV9 +l2Oz4s4pqvs6mUxPhufFvzx66vTQkv6GC9dy8IRhkXfrx/UxfifGYrhYr9V/UK2FPZuBsXo 8GnYQ9+0mwMdg/+BfqJS2ItvKi0SN6PmbjR8M6dsNHwxp/S+fAG+QL2UeiV6NNsdj3n4BNGj t3GEab9IY81UnRM1QrTwKo/el1qWo7tiFPLjIUrHz4oivx7GYb+k26Lz0esr+SoaEXr5eKhV H8YYtyqp0ljHWKKjthnYgeuZgVNXFKX58MkGSkwBH9vq5ijvf6Bxeoff/GbYS8vqrPqQxnz8 0Muwh7fhB2Yrxdcd6HH25KczXesnRcWHVCtH1XEah4C+ofNBD/mHDcIIH/fl0z+/fPqP9uXT vz9//O/nj//7/Ouvnz/+S9fGSRUNT8JRkqIRy9a1aBgWZVwd6E+Y6fOP5y+lBqvD13F1nRfv tb/mSQb8a9/Zf3qKmakADP59+IlPRS9ll3Appui2ifK92Yly6dVArxzvyYlaeXrEnGVqymjE tXfXP+Z9jEh4WeV8nFrAtQOH2czk8PUD5thGC8QMs0o3NYKyawSuKKAQijEoyuplnI80ujjQ C8CPvym8elVW9FFNERrXMk+T/kmSpvyP4uLdcVpoV2F6oAfmc8Phr0eVqWJppl3juWM6vOWp Z5xwxaqR6kagt9XCKKliYCkZHei+Qf9oxMMeAf5F1ufXVZik4hqvTzM+szSGNDNyhiVotesi xPrJQFl1LcyiYQ5KGFWFaHUWzTQVYXoBtKpCaLcF8ONnonp1eASyfZ30q+E68AY+IAjDOQjT UX6jubzzCm4adQ6rmImxVRRis8BzHWY5CngBq3HVUE/TtCyXWQJ4luUzSy5QCeE7Ai/LCXV8 qlt4mniyQZxwvI+fYSGeJPW6EBSQHtwfMlr5M+ZODV91eH52/INGq6J/CR7w3enxi1XJVnST ndUs5pgu20zTA8UUUDqrijC5GFbacZ5lWPB5oXmWImJ1ZQw1MdCGlU40KhaWZHOKj9qeafo1 KgLTNCBwiDUheappGcwHohVjXUyI0gSLk8Z2ASGiJd6iEqvREsLd87AcCqrVxxV94yzRKImj 8cnN3sYDwSrrRUbCVkOzwiiCRCPpVkqlqdoAcFUVBZdrfeB0xbo8VY0HA8zKXSqrGvzNedZU HiVZXgjaMP3ZDakdiPKCZIpegxcqOC1mh1YgEfUGLEATS1xRphkASUguQA9jtkWknWQxWhEz 6HF9h6i/gI9puUCY5DcLiEqcphBQb8XRBPW4J6RWg445bw4kAmjWymHYjwUoHcni0LTCTI3R eehaAZYPja5ULYg56JrDkYsqPc4hRWB278eQ46x/Ghbh25bMKZb2nQU9G9/RlscfT8xjtu0B +XxlgMAGM2KeZdj8OdFVkOANSnmGcWScyFU3Jcm1uPLUMwVige+G9EyV2iD3XiOoIOc1TLtR ae4LNKXKNorfIwItgAhfA01gqsXAO6BtRp2YR73WDDRoidtD0UwnMCRFs0zPVQKwlBQ7oO0s 0KD0bQ/QLNfxCFwkVFqwdBF1A6luFNUOaDsLNKXPbgPrhHVLyWgd0B7QEvcArNPZJormGixQ rNNyTLruKNoDmHwfAGjbtblg2RbfOyB7jOeYjyijfVt7Cw8ANLWrsA2s07MCJoFmerY1Y/jr ZLSdldGUhXgbgFZvgHJdACB7RDPayclxrYmQiXdyT7Uzo2FE7myvxcbzFimdvmnynXYONG6a fTQRrQPaes1ozlbZax2b8W0yAprNAvaI1o0OaGsG2lZZN2ygqzOjkd3wgf2MNq8LONtl3ZB7 /GSvZabd6QLzfFM24ND2AEBzt0lGY67nKqXTNLhJrTOj/S7MaM5WWTdc2/Pknjost6yjaDtG 0ZQjXHY14QIJb2+4GtFhBFdZbef4VbqNM0ddGURmJb9KbQDftb9Jx976pALzTV8a/1ntrDFF tUzb8jlZI1cg3/JrtEGnXuAitzE/y9o5uz5wIHyt4QY+ivu6lsbwpaYr/u21SCWPJhQJP/+g k9P4TGl0pOXc3flp1m6/y3DqKUFvDk7hHMyBCVivG6em4XgzprZtxWl1K/qU+L8U1R1O4QRN J2pm/YmX4dRXmq/CKT/eNOGt7t/bW51T1R+Iqs6lr7bjgWLWnpYMRxjam6vCB1m4IEuHZSyc xfS1rH3tlau9cNZdt1d7R235ISTpUC2mZJNe8ctQHCiL9GIUB19Fc29BsWfaSrfZXRR3tJgT lkdFsXLmW4jioDmneh/J4RYUQ9CVNse5ipOJw4+8AMm62EKuhYyOFjeHRoS//TRV/P2dUFpK i2c1tLZEEXydnrYiimvtjWs90tN5N1Dc0eKN0+LF5+yCrfKi8AzGXSf4pmNNo6cQ/XDuOt2m 43o3HbGBvE02+kmkOcxvjklL2vlwSOvOva0baVvlSDGFNMftfF2FAt0yte7ktiM8ZCRNkyE0 mMFP66uT6k0MDXR72ji/5Mz6pOsqoh9IFaQ5XsRYEFi0Q0A6imV4+EdK/2IdpVgSgEWdV+fh alaIb9KcrOanzFcPYVFQ+ZkYPjxeBTcuzI/mwyWB6lBG3ckQv2YqDAqGZv5JbXGodrplMVJ3 9gZkhlJbmylv1FSa0/VMucOMOTF3LIQpcGHE/Mam/HWMmCLvEEvkkeZcmY2bOW/MxF87574b MGwrYxE7OAnh2ZyATCxzI4BU/O0t87O4QBC7v2hxFe1taJnzCGqCLCPqmaTHzfYrNtQlfX9Z 5JdjDSRX2VXrGjNkfaIl3j7RUbFFqhU5wmAxsvMHpseDdtR7rzjhF7g2UEaU3EP8EY/bDBoQ IHyJZcDJha97Bw1wUh/2VOw4cAIZHse2Ao9C4XBy2YSRm9+E4hag+epzJyK0LNiYZkx53Cy0 3jHGo75xVngf8117g3pRF5XE7nMnVT5GzDE7k53c4G+FyPjWTXaMLbfZEb75yl7TpnWAUHoI gsjtGrbrB1jLfHnuFHY7Q93GDXXLzM2MJIVWpLW2vZnwvVbswjpigdyDN9mOxVz4wO0edjsn oS3ArrI13yIzcHCtT2bwXb5kCLuuYVlwVNo97HZ0d8PYlbIvqQJcCL5VJ1AGgFonMBv1v5b9 OfWdjG9Z31ftt3UCk1kGzvXZkzpBANdeC+8CdPHIZQ5XPbZYJTCVlrx4eZuN2typBEs9/do+ gbcTAqhyLaNq57+6ov8qQ/zopWIV8L1WsapTCRpP7Q679/ZpZeYKphjge63Y7VSCDrtklJ0T gRfClNJi1cUiMyLMoMvp7ppNMZ1K0GF3KXbvphIoo4xUCRoLzL1VAt8JfDuY1Ag8DxsHjtgl MH0bWRJa2ux8E/8j7hKYK2j8Ir3K+jT+BRshO2Vp7axVG9b4J3jUItZkqb2/W9TZZjtwLeps pxJ0rGkpa1oFu8oDbjF2ge9OJZB5njpTzGSimcc8FsQs5VN3C3YbJ7u10N1OJejo7lK6O6kS LD5Q4Sj4NmEpG6P3tK+Y8JqUiRc3m1ZNHD/m2wnOPC9k38V/8tFf9cTbyt6kZJaeytKn/EzD 3przsoChLcqYNgqLVzJOP7JTZn0k1kJ2RxFPHRlSw1fZUfGeZwmitJdI63h6mUUoUufXGkdH IvlWOY5Oo0qcfqMD3ZyNwhSC+3WJfjxAriB8C+7yVGk8KWTL4VX6vPNMU9r7uMAKxOjP93zl 3UJi04zzKZHK8s+j7ElaEQ/HntBkjkt6EIfiQVS2akQlPcCHwfuWaiIr3DDWfvvl7++SC2TB jKrLIv7tl3/s7e1RoaUZLbEmZEZVsvvUSVajtPgxHL+54m9A7lhkWEQaRtwaY1jp9SjaFEHK pgSpxC5od6zKkBqSLsYhKqPYeSazsvYvkUmR5m2ApJtVrGtI91qFBWYoi+EoCDsS/IHPRQrS 0ds850ODN/GW8Ltumq7q1+ESCW8P/w8AAP//AwBQSwMEFAAGAAgAAAAhABPBjW0fBQAAHBEA ABYAAABwcHQvc2xpZGVzL3NsaWRlMTEueG1s7Fjdbts2FL4fsHcgdNVicWzL/0bsonGcLkCa BImDXTMSbQmhSIGkHKfDgCJ9je0Rhg3YgN3kaZoHyCvsI2U5iet1bpEBvtiNLYuH5+c73zk8 9M6rWcLJlCkdS9HzqtsVjzARyDAWk553PtovtT2iDRUh5VKwnnfNtPeq/+03O2lX85Bgt9Bd 2vMiY9JuuayDiCVUb8uUCayNpUqowU81KYeKXkFrwst+pdIsJzQW3ny/Wme/HI/jgO3JIEuY MLkSxTg18FxHcaoLbek62lLFNNS43U9c6iOy4IyH9lunI8WYfRLTNyo9S0+UWz6anigSh8DL I4ImgMUrzxfmYu6ngBgeykvbJ4Um2p2NVdLfoV3ERmY9D+Bf209sol02MyTIXwYPb4PoeIVs EA1XSJcLA/BgYdRGlUf0aTiNIpxTFiDnE85IcxGZFSdmtivhU9WzHur0UAaXmgiJqHMw5CDC PvZaKXkVMRpq+zrHIDiaFhYfA1O801b9xdVbGQJOmhnpTCwB1Gw32pVKDlOz1q62Gktg+dVa rWkFLGT1VtPPBRZI0G6qtHnDZELsQ89TiNRZotNDbaynDyI2RiH3Y86LhMxFLIY5FSwe4bUV vMC3Szftcm3OzDVnbhfAhkbERvkEFaacsZCNT3NuuDUrMkY1WUr92B7UhtXK/rA0aA52S/Vm tVJqD4d+qdHa9Vt+q1UZ7vk/ecRcpwBK8zhkIkucVgUrHPD3PCZK52ceTJrDx7/1O6SjDnis QUadjjENoOe7RJQYzYkX6KWFQLsU0i4MrBmN6VerFkrjAEVszqIIT6iiiPy/dZMt7OTpdCVY ZAq1kBfAP5dBu9pZVMIoNqgCx2H0hYLCK7i/kuS20NJonitjVXlIMgqo7nfqnWbLh6F8oy0J 56dYVInlGBbTbuH6GiRj9FDsqktXjLYS0XBPMhGA6C4EpNAmYi2igCeoI52YAWcUzF3Bmvvb X+9v/yD3t7/f3fx5d/PX3YcPdze/eSSNTRDt0yTmqMJaHdUYUaUZvChV/fYKlr1WMeWPxFxV gz5zwpn+cWbcKYR4yIHWGdPkRfXlA8Msdiilr8h0s+h5AykMTgRywlERkeQhU8S3vn593r8o 1TYxS+2u3mjhrHSHQrXeqbVrc+yKo6Ht+52HbtfwG52m8xhQ5Joc2b+4Uz0jiXy0a4+EsTLu CNsUOp3Q4JIZouN3THefsAh9cdE9Pt+lNiWoB3+LGnCFkB86fMpdL3jOlNoDZPNSOjreO+6S CbKaSMVILHQ8iQyRgqSPkk0CKcbxJFNu8MOSwvhmMP6SF2x7sr1FqCZX5e9fn45IKJl+uf2E HHmLeQTvc8K6mZWyx6aYuslBuFQnn0CxDtNsi7vI9tFoRzM0VvvjCLcKewI6urqzyX2sMyL4 m0nEH2ITgX5hpo091SzjjJJ8iwhmrqS6JAkVdILDhUuJ4TlLycf3Pxs6+TzT/ofXTS6mb+9b H9//QsKcmDHqW7FSUdYsJCE19IJq9i+luw6gjqPrT0wbSsi8M4bM0Jhr2xBBNndtJfoaN+DZ FonkFRofGqZgIVqgCN2bC5nhycgtkrfG4flBqVlfBSvGjGJGnY/X7iu/POOxuE8HXL2l6fHU QYq/CdB4B+5VirnOdgGIPohAaZxgwY3AAlcvN01TbIbYSBQX8DDD3weoNzaORWwwYONmb6jC sCkY/tjAeIcr5cjdlkxyKqWZT9zo/c6iyVXDdmHOOo8by98AAAD//wMAUEsDBBQABgAIAAAA IQAhAvNC3QUAAOYZAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE5LnhtbOxZ3U4bRxS+r9R3GO0V qSAGx5hgYSJC46pVAigQ9Xq8e9Y7ZXZnOzM23l6h5DXa21aqVLVSK/UmV32U8AC8Qr+ZXTs2 OAZD0qK0QjLr9eyZ8/Odc745u/VomEo2IG2EytrB2v3VgFEWqkhkvXbw4qiz8jBgxvIs4lJl 1A4KMsGj7U8/2cpbRkYMT2emxdtBYm3eqtVMmFDKzX2VU4bfYqVTbvFV92qR5ieQmspafXW1 WUu5yILqeX2d51Uci5A+V2E/pcyWQjRJbqG5SURuRtLy60jLNRmI8U9PqbQNy8JDGbn/Jj/S RO4qG3yh88P8QPuf9wYHmokI/gpYxlO4JahVP1TL/NcMy3BRu/B4bySJt4axTre3eAu2sWE7 gPML94mHeIuGloXlzfDt3TDZn7E2TJ7MWF0bbQANxps6q0qLLpvTXGs0RxY9pxBh70li9bFx 5RMcEp6q8NiwTMHc0gtqN8Fq2tFanSTEI+Nul8aHe4PRVs4jbvM8YbbI4TcrrKQAvoShjfpm Y7O5Ud9crx4sV3v3jQQYhMD71g4fq6hwfuriv7/JW9LYQ1tI8v6DlbyF3fCBaElo1w4oW3lx GLBIaOtdykxqdyVxQH818E7nXrGYh1Du/PUv569/Z+evfzt7+cfZyz/PXr06e/lrwHJhw6TD UyEh5EEjYGHCtSHbDlbW6g+98n5TJ9BuP9vZZY8p4QOhNFtau7eFsFigwiuHT+gJE0f24LKM z9wobVyO0gO3L6A7cvb7jJJz8YJBcrZfQHdjfQOZ7yG+tl5vrOLaB2oE9IdN/LkFDu6N9fr6 ZtMbNQljF39n5shdV4Qfq1nK9VOAcaPRrK8HTA6kB6zIIqS/i1j5g9O3299DjYNOLipun1n4 2d1BQfyuHdS9LbOR5M2y218pkaHiIU0iYpEilzCW4Z4VXMqCARPEeBiSMcwqdkyFW42CSRoL ZuDEg8XrtpBVHZXZCVh/jV1cfUfBnEJyfQLIPuedR5DW2uO7Hfz1UwXtW/nGedUoKaKOkNJ/ 0b3urtRswBEZgGK106n2mVjmsqWMyAW3nkCKd6vzY+68G6rUudFQ2NcUsRTe5T34fmnKoTcN 7Xz1Ox1nwHz1u32L6BXoqk51Q8RsQqyfraDv6iK30DlX2nU1lpAmFS+zE2EThce4MX3NMwDm H7DlOqGYVcz+B6mr73skekkXFd8n/ztROkZnrFXKvpksGCJmYFEaDAVoFtkY0BnZE6WP7wye aVgmXjxWP6IBmBrKm2FGrYSodcD0m9PvaUgpUhR00vbNm9MfPj4QX+oflEUHXPPnkwzkOh1k fpmZk5pvNyzbmBPkmdC/2wq/nCrLwhYs18o1PgfuBXEgfAOf23k1fdsXYPgLSp4rE1hOiTk2 5wBMrSnZJY+7oavvVH+uuItrOVMWXt0wu9yQFO6Q+MB3wTk02xTpBCE5LNKuklXXHLf589Of F1Rgfvgu0KvWbWFHGsdWHAAvHiEmWAuYzqLkJuUhjnLIYop2oggQfq8YXr6zRnc0ztG7qp+B /L6XsN+4go4BuPzm9McpVT7KJHe88j+SGvMax+3hsmhqza5Wt9djKefaMhUvqk+3PBdfaK4f pso98UzwkOxUfl3dYj6Uz6bPMZi93ZC2VbODO0K69vaPnrQ8K3dsy6pQyUnaxaVRbMSUWILz CukVyQvSJcO5PxWcWxW/S7z48lzuOqy44iZsGtq30sxxr6OhF7zQ+GfNT6rKnLkm8am0/2zK rfMwX+4xG/OVsHstRgPKGA6LboqAQxZqOY5WTBjGp09fEcW8L637EWvYEs6mCs9oFvNjcrcW SYKbmf8BI3V1xpaxeqc3S90uT2L9QLZ8DYDL0ZuBUOpnPN8feBzjhQdYC2ZYuJXjQIPYuKVv l2BeKdxQyk8us6cG41/MwLmfZIZHiF75KiHqg1G6wWTsZoQYi4P+WRTzdpAhyBozXwwSj8q5 efpcKespcyXJaV6KdlfVdrjEW5rtvwEAAP//AwBQSwMEFAAGAAgAAAAhAE6+Xs2oCAAADjoA ACEAAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWzsW91u20YWvi/QdyDYy0K1 +SOJEiIXtmp1AzipUbvY6xE5MhkPfzocyXYXCwTpI+wb9H6xC+wCi3ZztY+SPEBeYc85Q0qk RDmqY8dOLRiwhzPD+fnm/HznDP3k68tYGDMu8yhNBqb11a5p8MRPgyg5G5g/nI5anmnkiiUB E2nCB+YVz82v9z7/7EnWz0XwjOWKSwPGSPI+G5ihUll/Zyf3Qx6z/Ks04wm0TVIZMwWP8mwn kOwCxo7Fjr2729mJWZSYxftyk/fTySTy+TepP415ovQgkgumYP15GGV5OVq2yWiZ5DkMQ2/X lrQH+/NPRIB/x2f697Hce8L6eSqiYBQJQQ+4UT4U0pgxMTDHZ5a5s/dkZ6kXn0y4r45yhW04 Ho5EBRw4z04l51hKZt/K7CTDVpj9+exYGlEAh2IaCYsBexybGopu9JhANz1u7fWzciTWv5zI GBcL0BmXAxNO+Ap/w0uszy+V4etKf1Hrh9819PXDw4besFk9AWxoPinuSu+oYTu7dqfc0feA C0vOBDfs+eb0GwBhdpT657mRpLBdjUI6DKE335cyvQg5C3Ks1psHuMqpEBGcPAsNdZUBbipS ghf9dCOsNZn3zwFxY3zxLA2gL5uq1ERkllBz210QWILO7rodx6vj59l2r4PtiKJluc4uPODK FgNlMlff8jQ2sDAwJWydJmKzQjJYv+yC8ycpChkdkkiMi4HZa9tteqHSEkeofiKKB6YHM+o5 WR+xOUwCelmxSOgyrEUkJHi4Y0RIXR6kwRXONoa/gAIYAlhamMqfTONCMoA9/3HKJDcN8TQB tHuW68ImFT0QJKYhqy3jaksyjYcpqAUIMEt8GHVg+kqWD0MFz4hYGmdMHSUnmY9dcTWIw+nl n5nMCrAUyOnz9CRkGW/CTPcltPVGcBCRqxN1JTihANIIw8IOxQwWVAg/YMD6EitBqgYmT1o/ nMDqhDqqPuexGgrOwDoWr6m9oYj8c0OlBg8iZRRGkKQMbCVMiceuaDkwBZRhdpC4Em0oau24 Vke6qzrioESRAbh9HUHcTDA3YAtKlboFVbFAJ1Bt6AxKW1PTFRekutehnW11pa4r6g+rKSgJ pCh5g6aQulSUlcQR9PSmynrC/TQJDMFnXGwwHTmiD5juNIzk5rOR4H/AbKN0KlW48eZcrYk3 xnIUTa6Z7ffauFUL17lDCwd09fk0Bjb708BEpwaeszB4hAos/qYGr+O10fsSOQBmYHXbSxbP thxnzg7cbsfWHW5u8ECB5nTy/pz5RzdQ5NZnwkJHzsQZuGRpYl3AJ99DFZ6s5cJBUD8g9QkR wAnzgdh9GSctoQpPxJYaONMNfr7U4OfYAAelp6AiUAhcgS4XJANnLDnGYkX6VerL+hMREJ3/ S/vQHlq2M2q129/YLffwcNjy7G6vdeiM9vftjuO6TvuvQLKIu+YQbXAgUrSn93EVcrPFdHrB tRWovTcvf/3izcvfFmYQFoXL5UlwzCRDEK/jQsVov5vNzCOYUZoiYT0WcCRhKgIoW6Qrd8Rq Jkg3VxVe042bK7xj2W4ZDXRsoDDAzAn7kuLYXq+9VXgd6HwIdydFrik8BhALBaurfE1792XE BEQXIZM5h6CGxOxWFPmOlcVedYvkoO5IRQKw4qghIROTwh8SBfoAf1iJlZu1Y+sObyWyrWjH PavE3Ld5rndgeyPwaLuW23KHh92W1z0Ytg461oHdtnoHztCZ+7aAKa6imOugf9m5vdeZWfYO /MA8d+DOKEbXeTkolplAX8hnLDMgzTcwhQKvpi6hFJxDaXxmYx0or7qEUnAOJeb7kFyEHkWh rIF2XTPv45Q1TtnHLWvcsqZd1rTLmk5ZA/m0UETJOWgx/jGNSSr+pCvKEvonStkesat0qp4G wB+Xaoid2JbbdT1314L8g+xj+lE+DcqMAFDopdfDiREGOo8DvpbyOUFpbDHjQRmYnHJNmISj x4rYFiyOskJSUWbG4OwoOZCwFyDUkzRR+0T0xiyHLBSm/yB7fDxNfJoFh8oz/4BPitKxr3Qq tjT3tdb9CeyZ3mjqV7RWyCQkuzSZvC7pC+ddcMRaL0xJ1/nni3X880VrDf980bqWf0KOaybs BRl+DDA2unUgsFVG/+7139+9/pfx7vU/377699tX/3n7889vX/3DNLJI+eGIxZGAJK0DijUn By3LLhK6N+AQeAKFTDvbw8Bo4h4PA0+gOAx3exj3fBh4AsVhtLeHcc+HgSdQHEYHDyNm8mhg llxdp1NqHmTJ+eK7NW/a5EMXnvg+fe0aJ3ED245IFaB1F6DRNRjQky1ojdkxRKoAzVuAZjld vA7aorYmFYFQFaj1Kqh5tgfJ5S1qa1BDqHQ+shJfwDcWcJ25Emxoi+e4dg8BjRJIrEIU0Sor tDZDzuh2IxFIFMJ0OnVas58bWcjxFL55kMRUB+abl7/gQGU2mvI2DiYisa4WfdAXOIsPUyBO LVdQ/XxlNUa59Rz5IkbR6HcBfbj9WKBve228Lyls6cNG/28r6Nuomw8R/eWgRKNffplSgd/2 Kkb5YcO/Kvz2ZgH6xxf+5TCkgB+gpnuDue2xPyH4G6QfLdtDlP7lwEPDb++2uygwn6L0/++/ q7bnoaLfHGlA+tclU/N+4d848rhF3/oRAa7FIXgvvSbL1xx82L2uRYxwi+OGt/XN8YimfRtZ g608Eo1rjlAcz+ts6NS2OBKO85ilEqVk/VSFXM5jFriFONbxYHEfUf0uQwcTiy7FFylFSqdK pqHPKRufwP1umbNYCW7g8origMWtS/2WRd/OFaugT2zI+pxzif8w8GlFH/VsF7DdR4tPc3xQ Csk8FH60+Kwh8PUc1mMWoGaKbdXTVY8ZoDUsmAK+rYkGl7WG3nZdSmktEkKP1gat4a3gcimK 3RrpNYS00+7Wc1qPVoLmTLNKLuGDpsWHOfihU/l/nHv/BwAA//8DAFBLAwQUAAYACAAAACEA yg4Z29kAAAC+AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnht bC5yZWxzrJC9asQwEIT7QN5BbB+tfUUI4eRrwsEVacLlARZpbYtYP2h1Iff2UUhjw0GalDPL fjPM/vAVFvXJRXyKBnrdgeJok/NxMvB+Pj48gZJK0dGSIhu4ssBhuL/bv/FCtT3J7LOoRoli YK41PyOKnTmQ6JQ5tsuYSqDaZJkwk/2giXHXdY9Y1gwYNkx1cgbKye1Ana+5Jf/NTuPoLb8k ewkc640I9KFlNyCViasBrTGw8/Tr9zrHCfB2jf4/a8jiHb+SVC6bMitfcCV63Vb8aYab1Ydv AAAA//8DAFBLAwQUAAYACAAAACEAjuJAPNQAAAC+AQAALAAAAHBwdC9zbGlkZU1hc3RlcnMv X3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzrJDBasMwDIbvg72D0X1W0sMYo04vo1DYaXQP IGwlMUtsY7llefsZCiOBwi67CH4JffrQ/vA9T+rKWXwMBlrdgOJgo/NhMPB5Pj69gJJCwdEU AxtYWODQPT7sP3iiUpdk9ElUpQQxMJaSXhHFjjyT6Jg41Ekf80ylxjxgIvtFA+OuaZ4xrxnQ bZjq5Azkk9uBOi+pXv6bHfveW36L9jJzKHdOYKleXIGUBy4GtL51brXV1RXwvkb7nxoyecfv tMRL2cis+oKr8GuGm693PwAAAP//AwBQSwMEFAAGAAgAAAAhAHUlNbNUBQAAVhEAACEAAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMWO9u2zYQ/z5g70BoHwfXli3LthC7 c5y4LZCkQeM+ACPREVeK0kjaSTYM6Gttj9Mn2d1JsmPHmZ20HZYACU0d78/vfnc8+ej1XabY Uhgrcz30/Fctjwkd54nUN0Pv42za6HvMOq4TrnItht69sN7r0Y8/HBWRVckZv88XjoEObSM+ 9FLniqjZtHEqMm5f5YXQ8Gyem4w7+Ghumonht6A7U812qxU2My61V503h5zP53MZi5M8XmRC u1KJEYo78N+msrC1tuIQbYURFtTQ6U2X3H0B0ebXv3qMhMwSPvreCOKOr1TCNM9gYyadEgzQ YZNcO9BEAraYGSFQVC/fmOKquDR07mJ5aZhMUE913mtWDyox+qhBDBbNreM3tSYe3c1NNjri EYDB7oYe5Owe/8IhHok7x+JyM17vxun7HbJxerpDulkbAA9WRouokHEZ0qWMtwMK6oDgmVsY wXqryCppjufP8viTZTqfpFzfiLEtROwQjTLaGPCpVSMGbGGFOQG+IDErGdivRa6VLKZSKQwa 18xEIrsWAK95l7Q9FgNtHeSoMBLyQthYE38Ak+XaGeHiFE/PQUu1D7Hb+gGEv7YBdIc0suvb 8zwBpXzhcsh1jdQqFb1+0A9bZUJ6IVC8NFwnxW/7A9xkmJp+Jwz9DgW21lMY696IPAPWWcDG gLtkhy/PLDoODtYiaF7nCAEFpDS7HXqDbrtLBx48yaQThimZgc0W/pROpYInpzqhw45LVa7B gNLEPgyYFpA5zLwtyvw/5nO3Tv8MAz3O71gfTUCpXCxRmrk72CzrBwAutnhgTH6Lzth1nquD FeGeoELtCDq6NzN+tx1UiQlhAUBspaYb9oNulZpOK6gEVsWwxv1/k5oiQlyTe6oA+A8o3BoO jU9DqyYS2GIMRJ3KijnXJITiyrord68EJR/yCtFhsnmUiPmHsv2stmjfgHIFVTv0hG58vPIY V+7s4Wf7O2SPEE6kcdR5mM3cRAkO9VuB7UbhTF5N3v7y7nQ2HfjIZkecJhtCJ5fccLD/bFMQ B1YG0bUGBeq3pOzTxIU28bCRU5dZsRbhWHMVOvST9ESaFikr7wyHdwJVNTbwqoQ01QHKIVmp Nmo3oXtRWigVj/OyG/0dyE6UjD8xlzORSMfOucWiJ2fgAodUHwb2C4Hs1EBW9yC7VDwWaa4S cKK90QyeDatMqHWgZ98EUewWaqlWpPxKhLHlEcB2A+GSjsRJqqTSJDGMRwebvBJxDtOFEkuh DlBPSD9D/SyV5nDtdFc9Q/s0XxiXHux8UDbkg7GZyvlO7TAD7W4kL+R2WHMbZwRoeTDxhfsZ vR5z9l9vG/0DxuqLRQZTNzTU3xbcQBl7MDViDVAX/ZoiwNoD6vtYAlzdQGM23rrrk0nq4SQH U7GmnjaHUh56P2e6oapBSvCtB4KXyYvt1oPY4gMohvJioWXlQbmuLiK0uOcemsPYjdPzH8HY HwTdftDwW8cnjaA9Pm0MeqHf6I8HvV53fOx3w+M/vaodWyUToQFQtLDvFgNXqVjx346b0I2+ fP7rpy+f/16XIjiFwk8wbvuWfCEDe/8tA+cOGLeDfg+GcChS4uHDEQyCezyREKL1rYZIrZK/ ifBqG6jyUHwPJ74v7vDuW44H68qnJvXvI8KLKz9xJewpV/O65Kmjf6OS32b1CzFf1+FJqz+Y tFuN3snJpBH0pr3GuNefNCZBZ9DpdDvhuN1d1WECL2NOZgLfoR8X4t7C89tN+G35wXcoPYC3 fmWHJb7eI5NjZc558X4JVOcRfJsBfXhCWwV8f4GFvCGCOurvQ0b/AAAA//8DAFBLAwQUAAYA CAAAACEAtM9YGbsAAAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0 ZXIxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S9iAiTXoRoVepHxDSbRpsk5BEsX9voBcLgpeF mWXfzNbNe57IC0M0znIoaQEErXK9sZrDvbseTkBikraXk7PIYcEIjdjv6htOMuWjOBofSabY yGFMyZ8Zi2rEWUbqPNq8GVyYZcoyaOalekiNrCqKIwvfDBAbJml7DqHtSyDd4nPyf7YbBqPw 4tRzRpt+RLCUe2EGyqAxcaB0ddZZ0dwVmKjZ5jfxAQAA//8DAFBLAwQUAAYACAAAACEAUK1G LXEGAACGGwAAFAAAAHBwdC90aGVtZS90aGVtZTIueG1s7FlPbxw1FL8j8R2suZfsZpuQjbqp kt1NC23aKLst6tE7651x4xmPbG/SvaH2iISEKIgLEjcOCKjUSlzKpwkUQZH6FXi2Z3btjEMS GgGCTqTsjP3z+/+en2euXH2QMXRAhKQ870TNdxoRInnMxzRPOtGd4faltQhJhfMxZjwnnWhG ZHR14+23ruB1lZKMIFify3XciVKlivWlJRnDMJbv8ILkMDfhIsMKHkWyNBb4EOhmbGm50Vhd yjDNI5TjDMjenkxoTNBQk4w2KuJ9Bo+5knogZmKgSZNyhUGN95t6Topk1GUCHWDWiRrmipY2 rizh9RLAVB23ba4SVwLG+8un0TMApuq4tYb+m9MzABzHIH+d99ZWv9FvlVgHZG/rtFtwtdse 3qHfqsns6WaJGpC9vVzDezZzQPZ2pYbvbfZ7/W1PHgOy+NUafrm33Fvb9PAGlDKa79fQjUYb rhI9h0w4ux6Et9vdbqMy/AIF3p/HjGYx4bnyIsjGXKTnMnyfi20A6AeGFc2RmhVkgmOIzS5m dCSolgevE+zM2KFY1oY0LyRjQQvVid4vMMT5gt6r59++ev4UvXr+5Ojhs6OHPxw9enT08HtL y1t4HeeJu/Dl15/8/uWH6LenX718/FkYL138z9999NOPn4aBygW++PzJL8+evPji41+/eRyA bwo8cuFDmhGJbpFDtMcz0M0YxpecjMT5VgxTTN0Vm3kicY41lwD9vko99K0ZZjiA2yK+Be8K CpUsALw2ve8JPEjFVJUu9zS7kWYecIdztsVF0Ao3NC/H8cNpnoSZi6mL28P4IMS7i3PPv/1p AQWRhkh2U+KJuctwrnBCcqKQnuP7hATMcI9Sz647NBZc8olC9yjawjRokiEdedG0WHSdZuCX WUhA8Ldnm527aIuzkNY9cuAjISswCwg/JMwz4zU8VTgLkRzijLkGv4lVGhJyMBOxi+tLBZ5O COOoPyZShtbcFqCv4/QbUD3Cbt9hs8xHCkX3QzRvYs5dZI/vd1OcFSHsgOapi31P7kOIYrTL VQi+w/0M0c/gB5yf6O67lHjuPr0a3KGJJ9IiQPTMVAR8eY1wL34HMzbBxJQaqOteuc5o/qZ2 n7l2bwoaTJ7rxyr2SbjjdbrLxZj++8t0D0/zXQKZUd+r3lTpN1U6+s9X6ZPy+eJr86IcQ6XW vZNtuk0Lnp3YgU8oYwM1Y+SmNE24hE1ovA2Dep05U5L5Ca9I4VZnMjDwcInAZg0SXH1AVTpI cQENfNP0+IksSScSFVzCQdEMB2lrpnAIUPZEuaKPR7ZySKx2+NgOt9yD5pyMkSoxR9aKUUsT OCuz1ruvx6xppTrRbL5qTSOaKYqeanOVtYnNsRtMPlcNBufWhO4GQU8EVl6FU72WHQ4+mJGx trv1UeUWzbq6vxAXyRSPSekjrXfdR03jpCpWaopoPWwwrBnR/9RqDre2Jvsa3M7iJJfd5RPY Vd57HS9VJ+fKM8bLx9OR5W5yshwddqL2yvJKhGJcdKIJnJnhNivA61I3lJgl8DopVsKG/anJ bAy/8Ga7Ugyiz8m4ZqMaryns1YFCSNXDMrWhYabKEGC55mTlX14Bs16UAoFqdDYpWmsQDP+Y FGBH37VkMiGxcp3tjGjb2ceylPKpImKQjg/RiE3FHgb361AFfcZUwqsPUxH0g+hE2tpmyi/O ZWEMvMHT3DArUlyWW52iVSZbuAnVuQzmyREPdAvKbpQ7vyom5S9IFTeM/2eq6P0EXkO0xtoD Mbz8FRjpTOlEXKiUQxUqUhpvC2gcTO2AaEFQXfR2jeAVtPkV5ED/2pyzNDQ1BqdJtUcTJCjs RyoVhOxCWTLRdwqxZrl3WZIVIRNRjriysGKPyAFhQ10DV/XeHqEUQt1Uk7IMGNzx+POfywwa JbrJcfPNq2TzvdfmwN/d+dhkBqX8Omwamsr+cxGNtfzOx643y6u911VETyzarMtVVgAzZyto l2n/F0U451ZrK1ZN4+WVSjjwYl1jGJw3RAW8TEL6H+x/VMTMfs/QG+qQ70FtRfCNQhODsIGo vmQbD6QLpB0cQeNkB20waVLWtGV3q61WbdYX0kYtXDDne8zYWrKz+Pucxp43Zz47Lxcv0til hT1b27ETTQ2ePZ6iMDSpDjLGMeZDmPutio/ug6N78P1gypQ0wUQewKtD6KEHJg8g+S1Hs3Tj DwAAAP//AwBQSwMEFAAGAAgAAAAhAHjnkwfNCAAAsDcAABQAAABwcHQvdGhlbWUvdGhlbWUx LnhtbOxbW4+jxhJ+j3T+A+I9GS4Gw2i9EVedh0SJdvboPEY9NrbJYmwBe/v3qeqbaeNpcAbl orUt7eCmqK6uqq+qupp98+OXQ2V8Kpq2PNYr0/7BMo2iXh83Zb1bmf97n38fmEbbkXpDqmNd rMyvRWv++PY/370hj92+OBQGPF+3j2Rl7rvu9Pjw0K5hmLQ/HE9FDfe2x+ZAOvjZ7B42DfkM fA/Vg2NZ/sOBlLVp1OQAbBe/pcWWfKw6Iy3aclebb8UEWQWz1F2LA+uqeUL2BX9Kfcaw6VOb DzbSts3uOaka4xOpVqZFP+bD2zcP5JETVN2QLqcfTscJNh+cMX6UoOqGdIGFX8mPEpD1GtYz nDuOMytzOW2PiF0OebvwCUOFvsffHcisrI0xpUTscjGgV3TWI2KX3oA+jbI0yxV5KBGj9wf0 TuqkQaTQU6J9VdYfBtSWFcKHU0uS7bH671XyMEwSSyj+TAXWlz6EU2yPdad41FU/PJDfj00O pPhIRbqyNrqvJ/DXNXhu1JSkQrnIY0F642xo3V4MgQQKu0NZz8r7zA5mOi+PLvagrvWX7bZc Fya9VVbVU/e1Kn5q6SLbY1VuchjEmxTRhcTSaQ+X3BAK3a4h9BmjOXb/L7v9056cQEEMlbuW s961xunYAiTpxFd546Sg5I5h10NHZNpsSffzccOG3T6kJRsK8B0NFmIiFxlMncxdvm4ym0n1 otrUpdlUNOo7ytLkksGGw6XBoNQmOL9BMFTbPsRUlN1o16QqNqh3Fu6EWXBqcT2Lido92RTc RrjuoY1saiThKzRyg+9csVFARddqrTdbiGxfMdsUI/WnW7wwnbDea6wkYpSwDFXO9gKOVd0H Z1Ubn1dm6DmeaazJaWVuISbB5eEEVm/rnWmQagfJfN01zO1HwUwVf7ZmKBYG3tdDnG2J8cGC lThwatouJe2euQa9xV2gqnEmJr/jgVrnWgDz9D8hhRuAM/xtUoAeVdMW222x7vrG7o2g7thP HkqPH7uiedpvPhvP1cfmHQHzo6vCejZl261MGhHwR7MyUdv0lhqceWC8UivhbKQ67QkPtwhR gWRGTl1VykB/9cSDtV2VnS7u9qVQyM+0lL4bf2NLwXxS1IW7QQusofRuiIF4XZnHptsfIQqd 9uU6b6DYobEDvMWA6ILp2oANAP3bFJ/wL8Mc44HcqnK3796VO6MpIR91+6YofoWwRL1vhJnN cxdjKRhRj+qJ256Y2M/Fp6J6jzHQx9xuGntwdRpNeBigdJf+p/7mCHreYZHTx5sSQ2TuZRj4 qysfBmZYlBqHaUEj9C9FpNpSKx/2PH1c5N7+QvDGucxaCFTAZL1UEHLY/0kRbky1LGINVux4 Qjiw4nDFMCgLohPp9gb+A/mvbNbVub59f3wHsdWA3SAyA7cBr/6eFR4GBkg2+AyFExtkzoSs mGp5dYtaE8l6ljLqbAI574WyUbIp9r5R2bI4U6dTsDinsrmGFV2zsRdVDZa9hCgMbcVGhhqG tiH6XYLj8+9gaN4baKkzFV+6hkDp+URxwMGvDqJd14Li3l9Ymff+Am6gX9dfAIf6mZyM5529 MqGdBDHnC1xBA8qEMQfHHByDK+gyQd3OWkMrk1+IEbjPRiSNK0ZcQbMQIwsx4okR2CfwJowY 8SFpYt8Eunb4xzTEQmEzwZfM8/sQJMOREdg4tJL4J7XlQh+/YlPC+nZc5TRb9svhPE5z74a2 XJ6HoS94c6shU3b517fl8jRLYlV+bVsuWwaRl3DdcLdB+WXPTWmsJokLaYRTSxLhQwNlomok +ZkKYrr0IXzmDptdbbj/ONjc0s3GBmyudoNpy7uHiAtHGtA7fydskihzLuTXwiYO4zBbToUN 5tZEgGwcNlHuL6Uwd9hoD4EWr4YNnGL4ueieznAIdFO26R9AMaxoYROkiS89o4ctdjnMNlmS R7nqprMeAl05ZNLCZpnH7nTYwKmhfwNsLCuCLRXH5B02Wth4r4YNmj4VJ3QzwGZJP9x6/HC1 hwgle1C3U91aCxuMvtKRJsAG+WdibT1sscvXn51S+dWzUC1snBTzzdRsk+cetO459Xi2wQr2 Dht4y4CXoqxpcL0l4Gtg40VewJU+yysHvVcJ+DsJ1145QFeSB+UjsIF4uvAdxY20sPFTP09U mGmLtChKrEQ43gTYpBF+FXkottijFBEK7KMoDmJVHi1sfMdfxAuFv/aVA9Qlpx6HjWXl+Y2w oZt+2hKgzQHaEqDNAdoSoM0BtnRoGvALsZX/d7cEli/CxkvssxZngA3tqQoX1MAmzVMnFNvk Edgom15ul/NehSJCcdM4W4a+kIHRa2GTWBF8FDfVFmm3wiZzAGUqfy1sosRPPbWloYGNEoDG YZO6kWOLVDatSPtmYRO8CBvLcl3ZdZoBNnjiILOIBja4aZcxcgQ2KOFF0aXNNpYVn889JsAG QZOobj0rbKI0DjI1W2phAxo8hzImvwY2qBupyXHYQD26tGweI+6w0e5twhdhgy7Zc3Pqjnzr okRwdHJpnBn2Npmbxb0WQy8bUBGUuRHaUsYJ2WbhB9EiVrJHj/+wJYCwucgG88ImitILWGph 4+bLdCEy8eywsTI4crzDppiwt7HZy0E8myg+qezNZ0g3fuDHXsrNokk3qZ3aifDtkXQTWqEV qOFam24CK8wisWGbkG5gBx7FalU0K24SH74iwjN5tLhZukEeqvJr0k2eJ4ksGMbTTRamiWw4 3NONNt3YL/8/BBcCvzxcmwM3vpK/aJznsFDwepG/evlgmG98ywuXAmMT8g2I4MvcOAU3QRxc 5INZcRNDKInFtn0CbrzES6a3oJVzrXHcoOJl8r7jRo+bl18UgP8rYtmezA+vrtM8x80cEbt1 +SZPrEDkpZF8EyTLeClKiwm4CXIvd1Q/7eFyWKfFbpRH4syQ8Z8VNwmgJlZxr803ge15jrrd 0uSbJInhdURuwXHcBAkkY0H+LeEGXoVQX7ChL6vBKH3N7e0fAAAA//8DAFBLAwQUAAYACAAA ACEAUK1GLXEGAACGGwAAFAAAAHBwdC90aGVtZS90aGVtZTMueG1s7FlPbxw1FL8j8R2suZfs ZpuQjbqpkt1NC23aKLst6tE7651x4xmPbG/SvaH2iISEKIgLEjcOCKjUSlzKpwkUQZH6FXi2 Z3btjEMSGgGCTqTsjP3z+/+en2euXH2QMXRAhKQ870TNdxoRInnMxzRPOtGd4faltQhJhfMx ZjwnnWhGZHR14+23ruB1lZKMIFify3XciVKlivWlJRnDMJbv8ILkMDfhIsMKHkWyNBb4EOhm bGm50VhdyjDNI5TjDMjenkxoTNBQk4w2KuJ9Bo+5knogZmKgSZNyhUGN95t6Topk1GUCHWDW iRrmipY2rizh9RLAVB23ba4SVwLG+8un0TMApuq4tYb+m9MzABzHIH+d99ZWv9FvlVgHZG/r tFtwtdse3qHfqsns6WaJGpC9vVzDezZzQPZ2pYbvbfZ7/W1PHgOy+NUafrm33Fvb9PAGlDKa 79fQjUYbrhI9h0w4ux6Et9vdbqMy/AIF3p/HjGYx4bnyIsjGXKTnMnyfi20A6AeGFc2RmhVk gmOIzS5mdCSolgevE+zM2KFY1oY0LyRjQQvVid4vMMT5gt6r59++ev4UvXr+5Ojhs6OHPxw9 enT08HtLy1t4HeeJu/Dl15/8/uWH6LenX718/FkYL138z9999NOPn4aBygW++PzJL8+evPji 41+/eRyAbwo8cuFDmhGJbpFDtMcz0M0YxpecjMT5VgxTTN0Vm3kicY41lwD9vko99K0ZZjiA 2yK+Be8KCpUsALw2ve8JPEjFVJUu9zS7kWYecIdztsVF0Ao3NC/H8cNpnoSZi6mL28P4IMS7 i3PPv/1pAQWRhkh2U+KJuctwrnBCcqKQnuP7hATMcI9Sz647NBZc8olC9yjawjRokiEdedG0 WHSdZuCXWUhA8Ldnm527aIuzkNY9cuAjISswCwg/JMwz4zU8VTgLkRzijLkGv4lVGhJyMBOx i+tLBZ5OCOOoPyZShtbcFqCv4/QbUD3Cbt9hs8xHCkX3QzRvYs5dZI/vd1OcFSHsgOapi31P 7kOIYrTLVQi+w/0M0c/gB5yf6O67lHjuPr0a3KGJJ9IiQPTMVAR8eY1wL34HMzbBxJQaqOte uc5o/qZ2n7l2bwoaTJ7rxyr2SbjjdbrLxZj++8t0D0/zXQKZUd+r3lTpN1U6+s9X6ZPy+eJr 86IcQ6XWvZNtuk0Lnp3YgU8oYwM1Y+SmNE24hE1ovA2Dep05U5L5Ca9I4VZnMjDwcInAZg0S XH1AVTpIcQENfNP0+IksSScSFVzCQdEMB2lrpnAIUPZEuaKPR7ZySKx2+NgOt9yD5pyMkSox R9aKUUsTOCuz1ruvx6xppTrRbL5qTSOaKYqeanOVtYnNsRtMPlcNBufWhO4GQU8EVl6FU72W HQ4+mJGxtrv1UeUWzbq6vxAXyRSPSekjrXfdR03jpCpWaopoPWwwrBnR/9RqDre2Jvsa3M7i JJfd5RPYVd57HS9VJ+fKM8bLx9OR5W5yshwddqL2yvJKhGJcdKIJnJnhNivA61I3lJgl8Dop VsKG/anJbAy/8Ga7Ugyiz8m4ZqMaryns1YFCSNXDMrWhYabKEGC55mTlX14Bs16UAoFqdDYp WmsQDP+YFGBH37VkMiGxcp3tjGjb2ceylPKpImKQjg/RiE3FHgb361AFfcZUwqsPUxH0g+hE 2tpmyi/OZWEMvMHT3DArUlyWW52iVSZbuAnVuQzmyREPdAvKbpQ7vyom5S9IFTeM/2eq6P0E XkO0xtoDMbz8FRjpTOlEXKiUQxUqUhpvC2gcTO2AaEFQXfR2jeAVtPkV5ED/2pyzNDQ1BqdJ tUcTJCjsRyoVhOxCWTLRdwqxZrl3WZIVIRNRjriysGKPyAFhQ10DV/XeHqEUQt1Uk7IMGNzx +POfywwaJbrJcfPNq2TzvdfmwN/d+dhkBqX8Omwamsr+cxGNtfzOx643y6u911VETyzarMtV VgAzZytol2n/F0U451ZrK1ZN4+WVSjjwYl1jGJw3RAW8TEL6H+x/VMTMfs/QG+qQ70FtRfCN QhODsIGovmQbD6QLpB0cQeNkB20waVLWtGV3q61WbdYX0kYtXDDne8zYWrKz+Pucxp43Zz47 Lxcv0tilhT1b27ETTQ2ePZ6iMDSpDjLGMeZDmPutio/ug6N78P1gypQ0wUQewKtD6KEHJg8g +S1Hs3TjDwAAAP//AwBQSwMECgAAAAAAAAAhAFiXqoRiNgAAYjYAABQAAABwcHQvbWVkaWEv aW1hZ2UxLnBuZ4lQTkcNChoKAAAADUlIRFIAAAElAAAAyQgGAAAAZZYkOgAAAAFzUkdCAK7O HOkAAAAEZ0FNQQAAsY8L/GEFAAAACXBIWXMAACHVAAAh1QEEnLSdAAA190lEQVR4Xu2dCXgU Rd7/BxAFAbnkVlESbjk03LjigYrHrgqJB1eAXOQihNyZibPKvuv+3XVXX313DQQC4UwEQu7J HCQBjBwJhBwkMwERPFBXUeS+Mv9vDSUmk5qjp3smk1Cf5/k+E5ju36+7uurbVT3d1TIOh8Ph cDgcDofD4XA4HA6Hw+FwOK2AmJ213ZJ21T+XpNMrFFrDSqF6a9exOLmmZmZk6anONCSHw+EI R6lUtk/S1L8s1+rLknSGi5DRUSl0+gsKrX5PolY/iYbncDgcYcBEFsFQfjQ3GDFCzK+StIZn ZDJjO5qGw+FwbKPQ1Q5XaOu+YhmLWKHnVZ2gPd6PpuJwOBzboDfzHno1DSxTkUS76kJoKg6H w7ENTKmCaSYSSaGrzwgsK+tI03E4HI51YBxfmBuJlFLoDCr+axyHw7EbGAc3JQ6H4z7AOLgp cTgc9wHGwU2Jw+G4DzAObkocDsd9gHFwU+JwOO4DjIObEofDcR9gHNyUOByO+wDj4KbE4XDc BxgHNyUBKItOdFKoj42Rq+sWKLR1cWIl1+nD5Zr6WfGao72NRv7wMofDTUkASo1+CPZnh0Kn v87aVzFS6Oq/kmv0vj4ZGXfSdBzO7QkaRKsxJTLvU2LJ0QFyneFZhcbwki2R5VaW1N+vNBrb 0xAOk6CqG4F9OcLaR6mk0BquyrV1b/lkGDvQtBzO7QcaQ6swJaXS2D5Jo1eQSeRYeSxJodVf lGv17yiLjHfQUMLBsApmsY0VX2ph/84q1bUTaGYO5/bifZgFGsJJ84YhpaQxJWM7haY2hhXf HpGpWRQa/ds0mGAStUcfTdLqz7BiO0PoMSXT1BzO7YWy6ER/NIJvzRuFlMIQKlXs8ImsD2M5 zYovQF9EFVb0pSEF8ZaufgEjntOEff1MWVTdlabncG4fFOraMejJ/MRqGBLpepLW8EeazmHk uprBjNiChP38XqGrH01DCsLVppSk03+uzDfcQ9NzOLcPCm2dPxqA5L8k3ZK2frsU15PiVdWe zPgCxE2Jw3FzyH0xcq2+kt0oxAtDkGLlZ8ccGi6Zw02Jw2njKHcfH4vKryEXgJs3CHFC4z+u 0BqUyszDPWg60XBTssADrw6Qec55VuYx52WbGvLqUzLPedzoOC7CaGyXqK1/NElr+Csa3kar 0uqLFDr9z6j8zQwJ/39Zrq3bnqSpC0kqPv6HpF21XoklXw4Qovg9J3tKcV9QY7gpmTHYt5Ns qLdC5un9jWzonEswpis2NXTORXzW4dNX5hXI50znOA9yo91b2jo/VGZR722DIZ1M2nXsxfB8 w100tNvATakxPh1gRm9B12BMRsHynHMen2/QYByO9Mh1dU+h9/Mru3LbJzTYKwpt/Svu+uwV N6VGDPUeBGP5tonRCJXn7N2yIT7daUQORzoy0EvCcGsTu2IL0C5DSczO2m40rNvBTakRHj5e TKMRIs85p2TDvB+iETkc6SA32KES72leqYUJPa33aUi3hJtSIzy9n2EajRB5ev8oG/rKSBqR 0xaJKjzdJVFdOyFJW/e8Qqd/QazkGv1MZVHtg7aGUzF7a7uhse1lV2wB2mVw67fYclNqBDcl jjUCk8s6kovDCm2dJklrOJMk0U/s6LlcQyM6odDWv6ssMtxH0zVDKlOSa/VBNKRbkqCt7Mfa biFCOX2nLDoxgoYUBDclTqtBoaldgl7NOXbFkkYKraFEubd2IE3ZhNvFlEwzBGj1n7O23V6h B1oeVVjRhYYUBDclTqsgsVA/XqGp+wq9GtKzcapgGv+nzKhuNvmXyZS0+r3mywuVu5sSgcyN JNfUnWVtvx36MUF9dDYNJRi5jswyyYzrLHFT4ghHodF/DFNqYFQoySXX1n0fr6r3pKlvcTuZ EiFBXfc0trcQvdNafNoUyu0o9k1FJnwTc7sDNyVOqwAVvpJRmZwmNAwfmvoWt5spEchkbcrS U73Is3u2pFRV91IWFTk+uRvF3UypHYxFlLgptU0UmtqvFdo6VCBXqTaCpr7F76bEWt5+JWkN S2lIDgNS9qxyc6Ksm9IwGIsYDeWm1CZRqGFKGlQgV0nNMKWdMCUNTIm1vBCp3fs+pZZGrq19 h1luzpMNU/KBuYgQN6W2iTuYkjKjuisMZQ9zeSFS1+4hvS4almNGkrYui1luzpNlUxrqM779 MJ8GyOiwhnqfkA1/+UEakdNWkMOU5KhArlICy5SMxvYJhUfTWMsLUaK69lK8uuYFGpbTCHL9 KlFTe4pVbs5SguaoKrnMyH6Sf7BPf5jKF+2Hw1wcVLuhPlpZv/kO3R7BcWNumlItKpFrlKCu aWZKBLmmZmai+uhF1jpChBh18YU1k6W4MNyGaIdy8Zdrjl5mlZkzBAO8AQXS/CzayYZ6h7cf 5n2VZTg2NcznZ9nQ2fwE1BYxmZIaFclFsmRKxEQSC4+GYJkf5YVHG8zXE6LEwtpziLUWcXyh Z+M0NY9YklJT/UBkemmbeMkkC5+MjA4JqqPPoDz+yyorJ6o0Id/Qh24Gm1E+d7Yf6hPQfthr lR2G+ZyxVzCk3R0857xkmv6E0/ZA5XELUzJhNLZTqGvHyFW10XJ13YfWhKFaCuIdlpPeFSOP vUJjbYCJlWL4+DDdCrcjsKysIzFOe0Xu+I7THO+eWFj1R5RPMoxZVBkJEXpkN/C5W6HW8wvQ HMdABXIfU3KAxIKjj6LRHWHlEqTCo7/EqarG0bBuwYf5hrsSCuvmw4ALYS4nsI0n7RGM4Txz H81EDFleWHsVn+hZ1hrwWSdCh7CN2+ILapYSQ6S7wOEIBxUJpnQUldQ1ktqUCPGFlV5oFD+z 8gkRGrOOhrTNiFd6dxg25+WOw7z9bKn9CO83ZCNnD6Zr2oU8t2awvLBGxdpOKZSorq5O0FSH x2H4SlNyOO4Bhi1fo0GTs6ZLlFAgvSkRElQ12ax8QoSyuEDDWUHZ/o7hPtEdhvucuWPEa0Z7 1WHEa5c7DH/tI3t+LYrPreyJ/SlibaMUSlAdzea9GY7b0nZM6eiHrHxCBCNooOEs0n64z6I7 Rrx+EYLZCFe74a99TENZhAyBsC03WNsoXrU/xhTUDqepOBz3o82YUmGNgpVPiGyakpdXxztG vnak48jXjY7qjpGvX5YN9rX62ia5BL0+S0I5bZT6LS0cjqSgksKUalBhXaOEgionmhI7p71K UFVbNyVP7z4Yin3JMhsh6jD6tSdpxGaQoRu2pd5826QSysmPpuJw3BNuSr/LpikNebWvJKY0 8vWnacRmkHt7sC3HzbdNKpF7lmgqUcQVHH4Q5TUXvctgW4orOLKI3OpBJrmjq3M4lkGl+TpR hQrrIjnVlBj5hCihwJYpze/bcdTrX9456g2jGN1ly5RUMCXG9kmhBFWdQ1PpNiYhv2Y+yup7 DMWvsXKYC8vewOd/E1XVyg8N7vc+Po6bEa+q/hpnPNJLcIninGZKVQpWPiGKL6hyC1PCthw3 3zappFDXDKWpHCK+oGYmyukSK7YduhpfUJ1AQ3E4bFxtSrEFlStoaknhpmSfxJhShumRlWqV eUyBOhZXUMuf7OdYxtWmlFBY/XeaWlIQ9y/MfAJkjyndCVO6ixiLGLVSUyKvQo9XVV1gxbVX KONf4/KrH6MhOZzmoDu9F2N+Mu53karynPGe//j8qnx2PvuFGLZNaTRMaTSMRYxsmVIBTImx fVJIjCkpi4o6sWIKEcr4XFxuzeM0JIfTnERVdVx8fuUNmAUqjQuUX/ljQn75WJpeEshUJYh9 plkugUI5XKIh2ZhM6Q2Y0pswFxGyakqHYEpVMCX2NoqVeFNix7VXKGOY0hFuShzLJBYcHRCf f+QgqwI5TXlHNiozD1u9gdBeEgsOYvur1Mw8AoUGU0LDMukCU0JP58tOMBYx4qbETYljA9LT iC+oPIoK08CqSFILua7DCNVkao3EnMODHLnDWFlUd29cfsUf4wuqPpdiuxHjp4TcwxZvaiR0 GQtTehim9DDMRYTuGsNNiYbkcCwTn1s5JDavcmVcftXBuPzKKhEyoOdyMj6v6jw+UQktC8te wWddXN6RXaioG+PzKlNsKS6vcl1cXpUWlbsSf18zjylMlQ2IcRZxD8EoZ9KisEj3MXN7dnr4 jS9YRiNEnUe/NpGGbAYxJRyD4+ztFa+YHHGmxIopRChvbkocYSiLqrtGqqp7OaoYde1AeX6V R2xu1TRUvkUJeZVZaPQwqEpUStcIZnchNv+IDkaTkJh75OXEgqrnWEIjeTZWVT0pqrCiL919 m3Qe/WZ+54fnGh3W6De/lA327UTDNeOmKR2BKbH3TazE3Dx505TYce0VTkDclDgti1KpbI/K OA+V8QfzCuoM4Uxcjkr/sjL7m7vpJkhK5xHzpsBcTnQeA4MRqoffvHDX6LlWnz2L37G/d3ze kWOsfZNCcXkVT9FUgpHClLBvl6OzKmbRkBxOy4Gey3JUyqvNKqmUyqv8Kjr38Hia0ml0Gvn6 H+56+M3NGIpVdHp4brUdqoJUMKVXaAiLZGQYO8A4djP3TwLF5h0JoKkEI4kpQQn5VW/QkBxO y+HsYQkRGvNfyDzfNGWrJSH3iAI9igbWPopW7pFtyurqO2kqQcRllz3AjClQ6M3+Hw3J4bQs cTmHt6KxkS685IIhXYnPLfeiqWzRrvs43x53j54/7q5xc58Uqk5j33ys0+jX75d5BbLfaSaS 6Pwqj7jcimOs/RQrxD0bm3toGk0liAT0slgxhQrD61MJ2ZWiHwzmcESDBhEfRyqlExSbW1Fn zwVrYkadx74Z3HnM3EN3j5174+6x84yOqPOYef+FUjqOfGO0TCZ97ywh7/AraLzfsPZVtHIr DsbsPDJcwK0Y7SJz9INQxpXMeI4I24B9nE7evOKM8uNw7IJcz2BWUElUobV1cZsYUtcx8zK6 wFQk05h533QZM5fcTiB5w4rOKh8LY1oLM/guNq/ijC1h2fNEWP4Ku4waCYYXk3M4jvRYErI+ 78dSdO7+/tH5ldiGyvmIWcuMI04XEbcYWo2/P8E+rDSduIQorzIqOrdyprLocI+2MHTnuJjY /CPeMA9URicot0IdWXrKykslfTp0fnjue0xjEam7x8w70W3MvOE0keSQu98jcw4PsiaU7X2x OYcnEZGbStHIE2PyKj5D2VxoVlZSKbeiAUZyDiebr2NzDx/Cv8sZ+gqmg2UqrjNjSCTEr43J rVig5G9G5gjBZEq5qETOUI51U+ry8Btj0av5ueu4+UZn6O5x8/5BU7kV8flVE2NzKg7G5Rxu YJabo8qp+AVxV5LrX8llZRavrRGToNfIwrHOV3G5Em9HI8EYr8TkHfkzn+GSYzctaUp3j50f zTIT6TSvHsbXj6ZzKyLTq3uht2JglpsDQuP/MS5H+Is7yRS6WL/aPJ6UIr0ye+7O53BMtKQp dR2/IJVtJhJp7PxvnDmEEwuGdQHo2Vxjlp0QoccVk3skhIYVTFx2xR9hHNeZsSUS9lND03E4 1onNP+SNsyw500qumJzD1odv4+bnMM1EKklsSp3HzJvSjfTuxs5X2hKGpRHk9ga6KpOo7RV9 UU7fmpebUMXkHrqxIrvsXhpWMOQX0tjcQ1Ws2JIp59A30TsOetCUHI5lUFm8ccZGpZFeMdnW Tanr+Pk53cbPNzpN4yQypeF/6tZ1/Ly10CVmHgvC/l3sMn7uezQKk5jsQ2WsshOimKxDJ2k4 h/BNLeqEelDIii2Zsg99H5t1eDRNyeFYhpuSbbCd73cbt+A6M4dtYb0FUTRUM2KyyotYZSdE MLb9NJzDIEY6K7Zk4qbUdiA300VnHZ4O80hCN/1fNpV96F+oANExOw/Y1Rhb3pQWoOE6SeMW iDalLmPnPwxz+4EZ336dpeGaIYUpxWYfFn29BjH+wYwtlbgptQ2IIUXllCXEZpf/CvNogHCA 7VB2eQPM6ZeYrIqXaCiLYHmYEiOGBIrJLrdqSvfAlO5Bo3WaJDClbuPmvYjezmVmfAHq6bXg ARqyCTdNiV1+diu7XLQpYTv+zowtlbLLuSm1BWJzD76Ihn2OeZDtUEzWoV/kqqr7aTgmWM55 ppRVrlIWnbA4T5HJlB5Bo3WWxos3JcSYy4wtUN3H+TJfYcRNidOqiNlZnoJuLw6ow0KPqXwp DcckJvPQC+hVXWGsK1rRWYfSrD1m0CpMadz8eczYAmXVlBhlJ0wSmRIztlTiptQmQEUphGGQ C5mOK6v8zzQcE3LtKSqr/DRzXZGCKQXTNEy6j1+Y0/2RhUZn6Z7xC2FKS0SbEiu2YFkwpWiY EqvshEkaU2LHlkrclNoEMVkHYUrl5IA6LhumRGahhHn8MzqrjPSq2DEcUVbZlysyD1gdOqKx 5nR/FA3WSbrnUZjSBJGm9ChMiRFbsCyaUhlMiVF+glQmkSmxYkulMpjSfm5KrR1XmBKBPDyK xnGQub4Dis4uO4dtf9No4wlxbkomU9rKKkOBUtFwDsNNiWMXMTthSlk4oOJk05QIETs+Hxmz s2wbhhO/MGLYpeidZdfQQzq0Iqf8T2QKWRraIsSUeqDBOkuI/21XL19RE5f1gCmxYguVJVOK yiyPQ7k1sMrTXkVllb1PwzlMzE6YEiO2dOKm1Ca4aUpl5ICK0EG7TIkQklHdNTpz/3hU0CVo KPGClF0WvSJz/9Pk0QmEsmsOne6P+MKUfNFonSOY0i+9HvWdQtM5BOLAlNjxhajn+PnMmSVR 1gNxMqhiHzvbQtl/Fy7B4xs3TYmdQxod5KbUFnC1KbkaDGu29PRCg3WS0EO50N3L9wmaziF6 PbJwMSu2YE1Y+DwN2YyozINP4Djti846eIV9DJsLZkR6pVUYFtl88YE9cFPi2EUUTCkaB1SM otzZlLwWvs1swBKqx6MLHH56ntDz0YUfsuIKFQxSSUMyIe/ni8o+9HzMzgNL7BEM7OXojP39 6eqiiYIpseqPdOKm1CYwmdJOHFARwlnYbU3pHq/5z6DBXjFvwNJq4e7e05Z0oykFQeZigpnU suMKUw8v3/o+o0K60tBuh8mUGPVHOnFTahNE7TwAUzpIDqjDcmdT6jd2fhc02B29JiwyOks9 J/he6TXB9y3ZDMtvwGXRa9K8e3o96vt+T69F11lxHdKji5chtFvOWR2deTCcVX+kUlTmgZOR OaWDaDpOa6WtmxKh1/jFo3pOWFzObMQSCcZ3uafX4nX3ePlNgtncBzPsa0nkV7LuXr6voGeT 30tKQ4JgcGd7TlgU3WeiL4Zd7jWhftTOfaNgHGdYdUi8DjREZR3cSFNxWjMYvm1lH2T7hRjk 7OzW9HrEbyQa7EY03J+hhsYNWVLdNJkT+Ky2JBjYd1jG4jag53UBxvJ9Ly/fUyxhP77Hcuid sdc3ieSZ4PtRjwm+C3pOXPScPerxyMLHu09YPKSnV2B3WmySQm7hiM7c/1fUmevmdUisSC+J vAWGpuK0ZmAo3uhWX4SMjihqx4ELrWa2vxnKO3p5LZyEHs2bPSb6zhOqnhOWxMBQ/gxTIMPB k9D13hMXGaUSTOQctA6G8kxvL98RXSb79WPp3on+w3o+uvg1GFQxho2XWbEcFeJd6D1hUWmP CYtC0KvrQktOMpT5hnuiMw98it71NVZ9clDfx+zY70NTcFo7yozqO6My93+MM80liJxxhOgs FEhD3Vb0H7+4D0zpXegiq3ELFgwOsSJkPhk2bwi9xSifO7FOQu8JvteYMcXopuFuccaF8/AN ++5Zkbk/fMWO/ZX4/AUntrOOCOv/sCLzQPrybaXTaWhOW0FZVNQJvZ2Xo3bs/xgHeostwYg2 r8g8+N6KHZ8/RkPcnqDnhWHWP3tPXIyGLFITFu3vPs63B41sPz4+HXpP9N3KjClai26gV/g2 zSQ5gdlld5MbaaMy93k5pPR9D5HnKmk4DodDIMMsNN4z96IRixFMKZWGFEzviUsmIEaDeUwp hO36yVnXmDic2w7ycsKIzKIekdv2PRm1Y19Y1Pb9y4QoMvPAHPKIhrW3r5Kf9dFwS++dhEYs RhMX/T8aUjgzZtzRe9Ki48y4YjVx0bXek3wluaObw7mtIXciR23f98GKHfvOYFhqdFQrtu+/ BEPbQa9bNP+JHUO43hMWFzAbtBCJMSUM4RCjqFlMidR70pIYmonDacsY2903xbtzn0cXelhT 3wmLhwzwCrwb/R67rx0s33ZgyIptn1ewTEaEvkPcP9IUTegzccnOPpOWGMVIlCmhLO+duGQ9 K65E4qbEadv0nOg7C2fg/YzKb1FotBVkPaxu9YZAMl/3im37dqyAkUivfScj00s9aapbcFPi cFoxfSYt9r538uLzfSajsgtXQ6/JS+bQUEyWb9/3YuSOfVfYpiJW+4zLt+37G011C2zXTrPt FCxJTIkRVxJxU+K0VcivOH0mLz7YFxXdUcHUaq3d1Ide0ocrtu8zOkuR2z4/FL9+f2+azgQa 7k7WtgqSSFPqC1NixpVAgkzJc1Yf2ZA5S2UeszfIPGd/JvOcY4BOQqdkHnO+gr7G399Ap6Hv TPKY/QP+/7/4+0escwb6Bf/+Ff/G33MKZA+9OpFGN6HQ1vsrtPp6hc5wHp8XJdTPCo1ep9Qc H0ZT3SI6t7p/klafiGX2Iu/XpmW1dWfxSfSrSRr9OXxSGcgn2b7zCp3p80IjkVz4rDsu19aF +jAmKyQzqiYW6cfLtYb3sGwplj2FzzPNct7K1ygnI58c2ybX6g/Ji+pvTbOjzC67W6Gu+198 fxr6JlFb93dSl+jXgjHF0xn+52b5GE5j35L/Xlgh+Q24ktJz4sLRqOSnzSu9UPWaEmTxocvI 7fu2ssxEMm37vH7FlqbzgnNTMtFO5untA0OBAc2+DjNpkEwec4rJa81JErnui8Go8F+gETU4 Tbq6j0x7RFGoa8fg/6vQ2K43W1a0DP9NLKweT1OZII1brtP/Dd8Tc2GsI0I6/S6aRpa069iL jfcpSVd/Wa6pc/jew6RdddNhfFca5bucqNW/Sr92T/pNXjy575QlZ/tO8TOKUZ9p/k0OYmNa xJSmwJQY2ylIk5eIM6XJMCVWXAmE/bNtSp5zXkKP56dmhiKFPObUyEa8YuqdKrWGUajs5Mz+ e0OTWGhYm0z7BKhB5LCWk0Q6/WXSmGk6WXJyWUcY1UroGnN50ao7/NstLm/tqgs1+/469vVN 04Y4gHyXYZ5ZPKjen37tnhBT6gdT6oeKLkb3Tl3yCA3ZjMjtpTClz2EgTtK2z2BKJU1MCfu0 nbWdQgRTUdBwDnDTlFhxpZENUxrl0xXGsZ9pKGLlMfuqzMP7bXIvFkmlLPvmbgxp8ppXfqlU h96C3te0X0ChMTyC/8dQjbWsFDJo/6o5eutygFJbNxam+BN7WXFC3GtyTe2ta6Jv6fThTZbR wZQ0tfPo14LBvsxvEs8kbkotZEp+K823UZiW3OgzcdFzNJwDtLApecx+EjpnZiY/yIbMSYZZ BWBYN88hDZ3zJgxpquw+7yavZU/QVvYjxpGk0yuSdhneYkmuM/wDjcJ8uFXLWraRYuW6Y08F lpV1pKnQ0PRvmMVA4zUcQQOMw99RjSVX66OxTSYpNPoYNPIYubYuNklriFWo6+JM0hKRdQ1x b2kM85S51U1m9lTs0stNOZrqAvY3HbHewvAq3iFh2xS62j8RU6eppDclnWFuk3gmcVOSLf+0 dGvkts/JBWmnaPmnzU2p72OLh2BYepS1rfYI6+Y5OnPlTVralOZEw4huNDKlqzAk3996Ny1B olY/CI3iapMGotNn06/tBuYW3DgGehs3YDJW3wjtKMoi4x3oBW5vnA+6mqStW55cZrxllFIh fU/pWHMDd39TCpjcf6rf2f5T/Y1iNNCaKW0r3c4yE6nEMiXQrs/URdPQgA+wtteipvhdg3b2 n7pkMI3jIMZ2iLOZmUMC9Zvib8uU3m1kSERn0MtZhv9/TbCGer8o8/Dxkg3xEfW8nRBTUmqq H0hUHc1LKDx6MLGwdpHSaLx1oy57SKL/DD2e+ej5vCZIWoN3orbueYVaP5L16FLM3tpu6G3s Nst1JrHkywF0EUlhm1LdX5K0tU86JF39n5vEM4mbkizy09LSyG2lMBDnyIIpmRg4cUHvAZMX P9Zvqv9L9oj0+MT1kCg+Ph36TwnQscpKCtk0JU/vD81MyXF5zL4CcyK3BlQjbohswEu3hhtC EGJKCYVVsQmqmobEwqPGBHVNeXyjazyJasMUmAn5qb1RQ3NYN8g1K3yeluv0GxS6L5q8xFSp qu6FXAcar5OkM3ztrJkQmpnSTV26ub/ChV4k1jWPx00Jw7fP9rPMRCpZM6UWA8MklEu9eTlJ pIZ+U/2szyzqOed/m5mLFDIZ1OwPZYOFzX1OEGJKCnXNCzCl/yaojl6FKaWSKVXoV+QJgR4K TZ1570USJe3SlyH+rReZKlWniCkdbLKcpu4r+rXkWDAlidUaTGma39kB0/yNYmTTlD6FgThJ y9Pdz5QGTvQfxionKYTjdXnQdH/rL9t0likRecy5jB4TmVVS0E19gnpKqsoRGL4tR08pIbGw 5nky8SH9ygS5+I31TzaJJZGStIb1v+XjptQCcFNyBsr26H3+i1VOkmiq3xcyr0DrF1mHzvnA zEiuoodD7tz+UrBMQ7dGsUzxvHPMf4GzhSBTUte8Q4ZupuFbYU1lVKHpDcy3IFPgKIuOTcDQ ax3i1CLOd/g8I1g6/VlyoRx/N2q0htMJWsMokufdPSd74vsmwzfom8bXuKSEmxLoO9lv7ICp AT8MmBaACu+4+k3yf4iGbEbEp3v3w5jIMMspikjf6z6mhGHbwMkBf0KZ/soqJ7HC0O1y/6kB C2g2y3h6/4+ZkRBjeVbm+YqHcM15BCqjcagpzTmOHH1oNruQ0pR+wycjowO56KzQ1Y9WFunH m+5hEqAkTd1EGJvGbJuuYxj3IomvLKruCpMqafI9zExeUu+U+mZuSsQw5TqDwxe6FRr9243j 3ZS795Smzu+Ls2/lQFR4R4XG8pW1i8MRGXs/Y5mJVBJjSmS775sSNEiMBk3yv2/Q40FD+09Z PAO9zmSUx8+schIrUs4DpviHk54Y3XzLeM6OgHk0uiVg9nX0lKJknrPuoksIoR3WT/89lknf yUbME/QLlDNMSQrkmrqPmmzTTb1BvsswGjvINfpPG3+Hf1+DkSnfLz0lqKdoD816SmJvCVDX v9YknklubkqEQdMCImFMlwdOR+UXqmkB1wdO94siP4HTcM3A8GrH8gwYiJMk2JR8fDr0m+I3 Cfv89wHT/UvR2PXi5G+ATuPvS8wyaqQB0wN+wrLHB073r8Xfh/BZbktYvgSx/9H/sSDTkMIu hsyejt7M2SZGYvq3906Y0zv4d5zdGmK6PkUexG0Ua/Yh2eCXBc1fLpUpkddCJRUfRw+nXp6k Md2Q+b7D0hk+hr7F340arf6SXKd/nKaTwYDITZmNvzctQx4URi8qGet/5IjQG/sn4ixS7jPc Q1NxU/qN+6ZEdh4wzS8WDfQYKj85y5+3JTSUX9DIvsRwQjFqlE+Ti5DmLM/YU7I8Yy8MxDmK SN9jvyl5BXbE0CoCjZ1sP9M4nKAGGNDhAVP94zD0mvjAHwIGDDa9kMCJE+yT6z3kodnGRiKl yC9wMmE3YkplSlhnHBo1mRWgUUOTVFV/aXQfkqKgZjT+73uzZSSS4WqSzvAPmfHmSZ2bkhn3 T1sycNBjAZMHTQ96wrb8p5ChC13VKjCN/SwzkUoYHh4KNZu6xALtBk0LnA+TuDpoeqDRZZoW sLlFJvof4v0UjOlbpqmI0xeyB72b3M9jDzdNyXRP0K0GgqFQJv26CdZMSa4zLG4cQ1oZLiVp 9WE0lQlyV/fNKVIMjZ+2l046fQ32zzSdSNIuQ4jZ9+SxHNNQ0hFQ5q82iaczXaNaTL++PYlM L+28PH3PYZaZSKb0Pe/RdFYZMjOwOwypftBjMApXaXrgofum+PWim+Bq2sk8X3kJxlSDns0V hrkI1GxyjapONnT2TFNsgShLT/VCo9A3aSRqw0r6dROsmZLpDmydvom5SSKdaU6kd5XZvz+L 9huRpac6o3eWlKSr/wHLmP1aJ0LEJHbps8hcTSRPEvbt5jWrW8tcwjBvsmkjHEBZdOxhxPj9 YWKd/pcEtWEG/fr2ZNnm3WPRU/o+Ip0Ms6TX8vS9J/Bp11n7/mn+f2AahxM18LGAEJq+5Rj2 0r0wpQUwp//DZyGMpQoik7zZK7L8DpnHq9Gyod529Y5ZkLug0SheQK+jSK41VKKRr0vQVvaj XzchQV0blVB49BRRorpG3fiObvKLmHxX/TtoZFXQScR0XFrDCegwhlCpMIOZgcm/P/hrDrkN IEFbN5Zc5MY+FNL8J5hx7RBiHJNr67b/dvsB4f3S0s4YXr2L8qlD7Fq5Tv/n34Z2jkCf3fOT a/WVRIlaw3JyTY5+fftBfq5dtnXPezAlGIgTtHXP6WWb99g9YdWgx4K874NRuFIDrcwz1QxU vqi0wi7oXfYSq+BNe3oqMzKsXuvjuDHEiESYUTOkjtfaIDe2ha7X9I7YUhITkb77V6ah/Kat e65jmat2a+ueK9C5Zem7S8I3Fj9JU9pFS5iS56xwmz/Bk/JatvWzhzEM/cuy9D17l23d/bVo pe8+sSy9JBNlFkCOBU3F4bQtotIqupCeScTWEkX41t0fWBIaxRrouEUT2rr7NL7fvmxLSXzE 1uKFy7aWzLFXEenFf7o5XBPu+iZT+kOQ0WV6LOgCTW0RMqTB/gSjPH5ilpcEQrntC91YPIam 5HDaBss3752Ank8NTIUYi0PCUO4aTOsdMkShYV0KMaX7YRauEkzpC5raIugZvRqxZfc5VnlJ KZT9vpCM/U0mL+NwWi3h6bv74GyrRw8HFdxxwZD+Y+11287G3UzJL13VC73OI6yycorSd6+g qTmc1g3OslEYXuBsK0rfhm0rujUlREswaAZM6XEYhot03+PWTQlmP2MZekmMsnKOtuzWmT9t z+G0StDDSWFWciHaUrK3pRvEAzClBx5fanSV7n98qVVTQrm80aycnCgcx6MBGwqcMmMi5zaF /MSOs+uosK27p4vVCvRaSDwa2iqSmNLWkjQarsW47U1pS8nxkI06kdP8cjhgaVph3/Atu1ei UtWjx3EpfHPJFdFCnLAtxTVhW4uVth7RkMiU1tBwLQY3JW5KHAkgP3+Hby4uR4W6AUMiwyBJ ReIifkng+j0P0JTNwPcprHUFyi1MafCMpUYXyropbSp6g1FOThOOIzcljjhidu7thl5N0bIt xQ2sSiaZNiP+5pLtgcm/z4PcGG5KDoubEqdtEba5aD4M6Sqrgkkt9JjOh2wtuTWHTGPajimF wJSCYRauEjclThsjbEvxx+FbimEYrlHYpuJEmroJ4ZuLUljLC1HYlqIWN6WHYEoPwixcJ+um FApTYpWVs4STHDcljjjCNxVtx9mNnOFcorDNxatp6iZgO1JYywtR2CY3MaUnYBYukx2mxCgr Z4mbEkc0aMg7WJXLWUK+TTR1E6QwpfCNxaqWvJubwE2JmxJHJGGbdsGUilChXCPks2JK7HXs 164vIrYUPUhDtgjElB56IsToKsGY7DAlVlk5R2Gbd3FT4ojDbUxp4653WMsLEWJfC9uoXURD tggmU3oShuEicVPitDlMprQJFcpFCtvANqXgDZqJMKYzrHWEKGxj0bHQTcVTaViX45amxCgn ZylsIzcljkiIKYWRyuQqWTAlnwxjB1TqYFTqM8z1hGjjrhPYr78Hbyx+Mnxz8SNknh9LIsM9 Ka9DecwIfmUIzMJVwhCujqZmQkyJWUZOUig3JY5Y3MWUCGR+YlTox8M2FH0ctlG3xZJCN+3a jsb2Gba9Cp/nmXmINu5qgH7FOmcsCbG+QEP6dNnW4olSTOXp+WSAx5Cngi8OeQqm4QI99ESw 1ef9uClxWh03TWkXKpSLZMWUhBKRWtQjbKP2eTSEAzCYBmY+e7VRdzp0g+YJGtphvLwCOz70 VMi6IU+FwjScrksPPhFi9S0UoZu0MCXG/jpJoRt13JQ44kBPYgdEehWukYSm9BuhG9VjEPcU M58Awdz2RKaXin5N8pCZy4ZiaFXjAeNwoi54PBny/2hKi4SmwZQY++oshW7gpsQRCSpSqzcl 8j4rxP53s1yCpbsatFY9lIYVhcezwffDmLZ6PBXyMwzkusfTMBIphN4RekjHH3wyJECmtP32 29A03WL2vjpH3JQ4okFDhCnpUKFcpA1ayU2JgKGXLzOfQIVuLppAQ0rCQ08HT8Rwzvuhp0Pn ihVM7k2Pp0NmDXlm6a2XJtoidIP2Q9Z+OkvId2zZeo3F2SA4HJvgrLYjlFQmFynEWaa0Xv0c K59gSWxKLUw7mMQe5n46S5t2lUVkFvWg+Tkc4YSkwZQ2oDK5SCFpTjQlRj7BWt92TCloS9GD IRu13zL300nCSWctTc/hOAY3JTO1EVMK/zD/rpANuv+EpmkbmPvpDKXpzgWv18ykm8DhOMZN U9KiUrlGIWlqJ5oSO6cgtXJTIjeCBm0peDA4TbMZhnSduY9OUEia5lrIBs3fWvqBaE4bgJuS mdzAlNCwO2F/Jixdr14QtkETYq9CNmrehjFkhm7Q/MrcNzNhqHUDy4vVNRjSVyHrNUu4IXEk wWRKaaikLpJTTYmRT7AsmpKy/eCXI3p4PBviaUues8I9oHsceO13u+D16hkY4pYyt020NA2I /RPMSIXyWkl+sYShzBOjsE2amcGb9vSk28/hiMfVpoSGUUJTSwppIOx8AsUwpZFPhgwe/kzY zmEzw68PeybcaKcahj4Tlj5sxop7aRibhGzULQhZrz3P3C6xWq85h95MfOT76aJvDuVwnArO mP9GgybXBFwi9AQqAzM03Wl6yQher1rJyidUZNhEQ5oY8YflA4bODDvCMB37NDOsRuYV2JGG s0jIOt1olM13rG2SQugV8ddpc1oHYWmahTiDXmdVZGcoOE1zOSRVM4umlwS/1apewWnqalY+ wdpYNJ6GNTHsmbBImEtDM7MRIPSYbM7xtDSt8G3m9kgglPlBv3RVL5qKw3FvlqTs7Ba8XrOX VZmdqOLgTbmSXIdQKo3tsf1/lsJYg9epvw3+d9PtGvZseOrwZ5cZxSn8nzScRULWF37O2iYp FLy+8COahsNpHQSlqcaFrFcfQcM2ukIYptxYuk6tCVqnmkQ3wSGCUgsehCF9hG2/xMojVMFp hbHm05cMf2ZZLttoBOiZZWnkQjkNyQSGWM7aJikUuk4TSNNwOK2HoHU5g0LXqd9DAz+BM+s1 fKJCO1UNwesKz6KHsD9kXeF/8O8ofAbZ1HpVPNb5YOm6ws9gbj8RgzOLK1zrCn8h16S8GReB hz8Tnsc0GiGy25QY2yaBUEYzaBqHIdcBQ9apg1E3Psdx+w5/f29NWMaAfXoveH3xSBqCwxGO T0ZGh9D1mt6hm9UDg9ZpBzkq00Xbddon0YtZgUqsReW8zGoszhRyfonGkU0aBoxsCRrJfJZC 0wrfCEq1PPskMaURMBZRamFTCt+gHUXTOIR3emlnxMnFNl43j21NKN8GnDyOm/94wOG0IMZ2 89MKuyxNVc1Bhf4eZ2xy1nau1qlJ7yspJKOoP3nUgm6Iwwx/NiJvxHMRRlF6NsKmKWE4W87c HwkUJNKUlq5TxS1Fj5QV2x7BmIpxPLrScBxOy6NUKtsvXauai8p5kVVppRIa9mX0zFZIeWfx 7W5KpmOXqqpmxbVXOO5nAnlvieNukEcnULlL0KUn3XqnCPGLA5Oz76YpJQGGkjcSxiJG9plS YTlrn6SQKFMyGtsHr1NdZcW1W6mq80vTCp+iITkc9yEoVSVnVlqptL4whKaSDPR08kbOgrmI 0IhZMCUrs0T6Zmb2wPbXNtsfiSTelNhx7RY3JY67Qqa1YFZaCYRe0nlnDBFcYUqBm7LvDU4t 1LP2SwpxU+JwLBCUmjd9aWrBNQwHUFml1dJ1qhP+qwofoqkkYxRMadSs5UZxirTDlFQwJfa+ iZUEwzdmXLuVWsBNieOeBK1RjQtaqzqDXg3p2UirtapjgcnSzw098rnIdWyjEaDnl/+LhmMS mJx9L7Zfz9wvCRS0RsyFbiO50M2Ma7fWwpTWclPiuCHONCXEPbL4w/w+NJVkjHp+WRiM5fro 55cbHRXW96XhmHBT4nBaCKeaUqrqAHpKks8+MPKFkMGjZkWUsczGHmHdiuHTYrrRcExCP9rR G8O3OtZ+SaHgtappNJVgJDGlVNWF4DUFfJpcjvtx05QKYEoFqKjSKii1wCmmRBj9QsRI9HYy oa+h7+zRaCwLU8oY/lzEgzSMRQKTkzti+w+x9ksSrS3wp6kEc9OUGDEFCPt2IzC1wIeG5HDc B5MprYEprUVllViI6zRTMuHj02H0rGiPUbOiRtkjsixd0y6C1uSnsfZLCgWn5v3N/EFje1Eq q+9kxRSqoLX50TQkh+M+tGpTcjJotC9gHy6y9k2sYHhVIam5/WkqQfivKhjNiilU6CEXkx4h DcvhuAfclCxDZigIXJOfunRNwXXW/okRDO9GYEreX1izIFiDDN2C1uS9x4rpgC4Gri1Y4Zta 1ImG53Dsoh2ZxTEgJffFwNSCmMC1eYl26HUyswB5nz+NYRFiSmh4Z9BISEORVIFr8lq1KRHI xHdL1+R/hH05CzNoYO2nw1qTfwVl/0HAJwUDlEobzwbiWIZ/mH8P1vHDtlxkxnNMV6FtS9fk vRS+Kv8+8qsjucgvVKSORqaXwmAdG5JyWhHk5saA1XkVqIykEgvRl/6r8r1xarX6fJfJlFJg SuwYooSeQKs3JQKZPibgk9zJQavzEmAIW7BfGbaVr8bnYZjOj0EpeZdY5fObsOxpaDOW+7dF rclfDR1svB5TKfnXYZ5Xm8j0f4xlm6sBuX7APn4jVMhxEvuq81+dGxi6fkdvWnSctkbwWtX9 ONi1jMpjn1LyfvFflzWahmPCTcm5hHxc1BXl+zTKQnXTJNhl5bBS8hoQ/0fEzoJpxi5NyV0Q kJI3p7GWphQsQP4VgatzV+HzawEm5ZCwPWVBa3LG0SLgtCUCVucEo7LhQDuugDV5/0umuqAh m0EqDyoqTIm9vhgFpuTe9qb0G6S3hQYbCRNBr4ldXg6oATHTQj62/4I5mbEhICX/HWzHFUY8 yYQ6tV+qOd85bgQO7krzgy1c+ZloEHfSkM0gU+4GrsmtY68rTjhLb7c1fLzdCEjJxTCMXV4O qNSRi9Sm4eiq3HcY8aRTSm4DMT+aktNWQHd8Jc445KzjsAJsmBIBDeUd1rpihJhXycV5moJD CUzZOQHDqJ9ZZSZUOLYOz/Md8Em+R+CavO9YcSXTmrwvwjfk30NTctoCrjIl0697q/NKWOs7 qoDVuRv5m1+bY+qlpOTVsspMiBDjHIlFwwqG/FKG4TW5GM+ML41yf1mSkj2VpuS0BW6aUi45 uA4rYE2uTVMiLEnJHYzldQEpOTfMYwhRwOrsywGrc/7DryVZJmBVDsyAXX72Cr3QE+SeJRrS IXCsN7BiSyVs4wXUP/58XVvClaZE8E5P74wz29Po5fxP0Orc94UqMCUncUnKzkfEnMFvB2BK os1AClPyT8l7lxVbKnFTaoO42pQ4rgGmlMw6VkIkjSnl/pUVWypxU2qDmExpNQ6wCKHXw03J zTCZEuNYCRGOq3hTWgVTYsSWSthGbkptjaDVOTClHBxgxxWwOoebkpsRsCobpsQ+XvYqYHW2 BKaUDVNix5dCqHvclNoaOKgrIXJwxYibkpvhB1NiHCdB8pfIlFixpZI/N6W2Bw4sN6U2CDcl TqslIDlbHrAKB1iMkrM3zpDw7bQc8fglw5RYx0qAYCjSmBIjtlTyXwVTSuam1KYISN45039V 1oWAVdk4yI4paFXOQhqO4yYEJOe8xzpWQoR6UWzP1DTW8F+1E6bEji+FTHWXm1LbIvzD/Ltw NvsoYFXWNdZBt6nk7BwyBw8Nx3ETcFyex/E53+x42a8GnLAiaDiH4abEcYglKTu7ofIEBCRn 7fBPztLapU+yc/2Ss2IXr5H+9UYc8ZApaNFgP4AusxqzVSVnNeBEtXd+WloXGs5huClxOJxb kGlwyckGDbcUJmOA2XxpTeQaEpYt9/8k612pTjbclDgcTjPmpxV28V+Vf9/iNblDrAkN/KF5 Eg/FuSlxOBy3ImB19jKWmUim5KyfyLOQNB2Hw+FYx39VznP+yQ7+iGKXsqqEvq2Fw+HcxpAJ 2PySs3azDUW0rvkl58TSVBwOh2MfgSk7Hw9Izv6GYSoOC72vBnyqA5Mz+JxaHA5HMO0CknOn wZgO+a/KvmFuMEIFQ7oIbQ36T84gGp/D4XCE45ua2cPvk6xgGNMa/+TsEv9VWZ8JVC70gd9/ Ml8ITC7jrwLncDgcDofD4XA4HA6Hw+FwOBwOh+MKZLL/DyQalSerNlxaAAAAAElFTkSuQmCC UEsDBAoAAAAAAAAAIQDqbXpNAFQAAABUAAAXAAAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWf/ 2P/gABBKRklGAAEBAQBgAGAAAP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEI AMABAAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoW FxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaH iImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm 5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQAC AQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ0 4SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SF hoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl 5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP6qKKKK/QD+ZwooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArJ1bXNK0KGO41W7FrFKzKjGGeYsUXc 3yW8UzhVXBZyoUEqC2WAOtXH+MdJuNXttOht9IsNXC6hGLqO/vLqxWCxkVkupoprSWKUyqu0 pGVmSR1RGiUHz4OnCRw88RSjinUWHbftXSlShU5VGT9yVb90pNpJc+j2WrRz4qVeGHqSwypu ukvZqrGrOm5OUU+eNFOq1Zv4FdbvRMyrXxbd6l4guTp81h/wjOmK1rftdmOz1B79Fuwz263N 1FK1rLPJpUVncNapa3ImuDHcOQlUdf8Airpnhuya/wBT0nVVitdHv9b1GztbeW+1q2s9NF/J crb6NZwz3t9d/ZtPluIbGJUvJxJDDDA9zJ5K/jd+1bqeqftAeH/AWpeANatP2gv2ZfDnjHxX aftM/DG18I+ONJ+LHj/Svgz4s8LatbeC/hcLuw0TWJdc0fXPCHiDVbOLTfEHhu18Q6mtnbHV tQ00fZx3vwo/bes9I8SfEPwX+0JFb/CvX9J8M3Xx6g8R+DbK81v4d+HvA/iW9sovhz4c8daw k2t67pvxYsbvxvpmmeMvDy6fLpkGsWJl0i8lhmtJIPsHkuC5ITlSc0sM1ClCliKNV+zlUw7q VFeFerWeIlKpZ4KEXGnhqUpR9pW9n48amZyp81GblW+tSeJpc9CrKipOhVjQjC04UkqK5JRV ebpxryrR9rP2cT9YvhL8T/Dfxo+G/g/4p+EINetfDPjfSItb0e38T6Hf+GtfitJZZYVTVND1 OOK+065Dwv8AuZ0G6PZNGzwyRu3oteO/Dz4o6Rr/AIJ8N+JdV1/TrtPE9laa1o+pWEF39g1H Q9ehGq+HL2GYWNtEwvNEubK5ZljRFMuxiZAc+l2evaTfyxQWt2rzzo8kMLRyxSyRRgM0qpLG jeXgghyArZwCTxXyWKwdajVrJUKqowqVVCaU6lN04SdnGs6VJVIqNn7TkpqS97khey9eliqN WMP3kIVJRhzUZyhGtCUrfu6lNTk4VFL3XC7aknG7aNeiiiuM6QooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArx/wCNc1/b+FLKWw8bQeA3XXYDNq1x NqFul1brperu+n+fpkM91ENypqMj+X5KwadKZnSMFh7BVa6srO+iEN9aW15CsiSrFdQRXEQl jOY5BHMjqJEJJRwNyk5Uit8NWWHxFGs48ypTjNxahK6T2tUhUpv/ALfhKPeLMa9J1qNSknyu pBx5rzja/W9OdOat3jOMuzR8DeLLL4p678OPikPB3wwuviJ4mudBHw51zw5rniPTvA+teI9R 1xrvwr4x8SeDPGWvaD9k0S0s9F1bUfEds1x9pF80S2MaSNd27QeN/AT9nDwj+y34atfhFpkf jRvCfhTx1rHiiHRfFFrp+v6p450i8vrq/wBV13Up9N0nS9Ci0eDTvCdqFs49MvZXgkAmuUKS vbfrNVG60vTb5mkvdPsrqRrW4sTLcW0Msv2K7UpdWgldDILe5Q7Z4QwjlHDqa9enntWHtYex jGjVUU405zUrwpOlC7k5QajCdaEWqaqQhWmoVE4UZU+OWXJ0IUY1pXjWdaUpRTVSXPGackmm nCUYzioyUZVI3qxqRlKLx/DWq+FfEujWmoeGJdN1DRIs2Vk9nbLFbW/9nkW32WGB4YjbC18t YkhEUYjRUEahNtdDHDDCu2GGKJdxbbHGka7mGGbCgDcRwTjJHU1l6D4e0PwvpsWj+HdLstH0 yGSaWOysIVggWW4kaaeTYvWSWVmd3YlmJ5PAxs14tSUXOapup7Lml7NVGnPku+Xn5fd5rW5u VJXvbQ76cZKMXUUPa8q9o6aai52XNy815ct72TbdrXbCiiisywooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigD4j/aE+OfxhtPj58Fv2VP2eJPhloXxL+Jvgf4nfGPxd8R/i74a8R/EDwj8O/hT8 Lb7wd4auGs/hn4Q+IHwp17xv4r8ZeOPiH4W0LSYT8SfCOl6DpFt4k8Q3cutz6da6DffkD8Lf 2hP2ufgp8Q/2k9B0XR/gInx9+P3/AAWE+G37NPjPW9a0Pxx4i+FWlaPrv7FPgrUG+Lfhfwlp 3j/wp4pg8+z8CaF8QLb4aav4+1G6srDUNS+GFz47u9VFv8R7f9rfj1+zp4n+IXxE+Fvx2+Dv xJ0n4SfHn4SaT428HaJ4k8W+A9Q+Kvw68U/Db4k/2DP418BfEH4daT8QPhVrWs6fNrXhLwh4 u8Oar4d+I3hDWtA8VeF9MnlvNW8PXev+Gta+RPA//BMzxho3imy8e/ED9px/iN42uP29/CH7 d3ijWP8AhTth4UstU1nw98AJ/gje/C3Q9J0/4gX0fh7wsJbk6t4S1m7ufEWs+HfDFjpPhLXx 441231H4gatyYOlUjjqNSu6sadVUsJmk/ar2dfB1fELg/MKsMF7OTxOGw8ODssxkMdCDw9Sv mFDGOjDEVa+Xyn9FHFZfDLq9JPDuosDiK2Doyw1SdWOa0uF+K8Ph54ucqX1evOXEOMy2WF5p VMNQwU8EqqpOlmk35j+11+3z8ev2WYfi3aeK/jt+wR4L8X/Ar4Q6P490T4Z+P9L1K4+Lf7au rw+Fr/xT4oufgz8JPC/7WE/xG/Z78Hy6jp138O/C9z4y8OftAaveeItM8SeK7q3Pg7Qre41v jP2o/DvxF/ad/br/AOCdl/puofs+p4K8SfstfHn45+A/Avx7/Z31z4+6L4I8f6YPgLrCeL7v T4Pjt8MtJ1XxppH/AAkuhRfD/wAV6Np/hXWvAX9n+LMXviP/AITCzbwr9RfF7/gnx8SvHmp/ tlaF4C/aR8OfDP4S/t025k+NOmT/AAEHjP41aVqMvwh0X4O3tp8OvjHc/FvQ/DWj+DNS8P8A hrSWuPC/i34N+Or3S49T8ax+E/EvhrUPElhrHh32Twf+x7rOifEj9j34neJfirZeI9b/AGWf 2bfiD8ANXt9N+H0nhyy+Jd3490/4SWE/ja2STxxrr+B0sD8LPtB8M7vFq3T68yR67ZJpii+4 XhcXiqNZYhShVi6GJwfPOMVQx9fIeMY46Slh51XUoYbOa/DFPCzm6VJOjTxeCyrLKccbSjUs Xl+FWGlgalH2ksBmmExjWHnL2kJU+HKeX80a9BQhWrxhxA8UqftmnXqUa+PxeHng40/Kv+CO up/E7X/+CdX7OPib4r+N9O+IHiHxT4a1LxHba/BofiDS9dk0/Vtf1S6mXxtq/iTx347vvG3j K51p9Y1TWPGkcvhuDV11C2ibwza3dldalqnlnwp/b2+K3xM/ai8S/B3Vfir+yB8HvE/hH9oL xL8LdV/Yo+N3hv4mfDj9qfXvhhpMmv2fh34ufC34s6x8Sf8AhFvi/ceONA0rT/jJ4W8P+Af2 ctV8GXfg7Vo/BOofFjStSgk8dj3H4Ef8E2/gf4H+Dnw7+D37Qnw6/Zv/AGqLX4HT63oXwJ8W ePf2afDE/inwJ8NL7VU1vSvDOpaj8QfFHxcm1bxRZam1xPq3i/wvJ4B0fXRHpbp4F0q80+W9 v5Pix+xp8bfjrrXhrwp8Xv2kvAfjf9nzwj8fPBfx50Dw3d/szaZpf7Q+m3vw78YQfEDwb4O0 74+aH8VtN+H+h6No+v2tv4YbxL4b/Zs0T4j6j8Kvtvg/UfGlz4m1nXPiBqfrVZTr5lhK3K6W Eq1Y08TRbtDD4Gvj8q56tWpSn7SWY4bLVj6dSnRw+Mpzm8VPD5isa8DmBz16uWyed8tSMniK uLqYWu6M1XvKhmkqdPC0alKpS+r18RPBzhUqYjKcXQqwwUU6eBeZYd/mn8FP2jP22/hJ4K8Q Wek+PvgX8TfHv7QP/BZr40/sq2+v+PfhX8U00vwJpP234vx+I/GMViP2j9R1XXvD/hiP4eeF Jfhx8L4vEGgL4d8EaBdfDaTxpqlxquj+M/C36u/sw/Hj4w+PfjN+2F8Ffi3c/DXW7/8AZi8S /BPwtpXi34c+CPFHgC08WXPxB+A/hH4neJdT1Dw14m+JfxRm0yBPEWv3ltoenW3iS6k0/RY7 a0v9R1m+SXU5vIbD/gnV4gsfG+lainxu8Pr8OvC3/BQLU/2+vCXhKD4Q6snjC28S+MNF+KVr 8Q/h94j8e3PxivNH13SdY134jw6x4U13S/h34YuPCdjo11o2paV4vfV7fVNE9H8S/sj/ABk0 j46/HX4ufs//ALRvhz4R6P8AtP2Hw8T4z6B4q+BjfFXxZpXiX4f+EpfhzbeO/gf41HxY8CaF 4B8T3vgKHQbJLT4kfDn44eC7PxN4Y0vxG3hG8srzxB4d1rzKUMfSyWjRcZvHrJsDllOCqUv9 kr4LgrgbC4erzOaowoYfPMBxZhZSwzqValbE0azo1cBLDYih2ZniMpxubZpWo1MNTw2IeZYy lWWFrU1UxmP47zzGRSp08OqiqU+GMRlDlGpCGHgqNejSnLGSqRrfLP7PX7Y3jD9oLxJ/wS08 Z+P/AIXfA+Txl+0z+z3+11488QeL7DwTqj+KfhvfeBYvhfAdG+D2v614n1rVfB/h3xnFqsUf j3Tr2616bxEmi6Cn2yzXTlEnhH/BGT9qXxl8Yfgb+y9+zv8AAlfAFt4G/Z5+Deiat+0943+I Fhrt74m1bUvFHijx1pvhr4b/AAR8I2XiLwldytb3vh3WpfGHxu1qPxH8OtF1bSbr4e+H9E8X +MbLxgngb7n/AGf/APgnUfgXF+wZEfjJJ4tP7Efwd+O/wmMsvgBdGl+KJ+Ni+C1PiKUp401N PBsnhs+ENz6YieKF1ttRO2/0cWgFzn/Bz/gmxa/BTw5+xpb+GPixYXPjP9mLwH4p+CPxK8R6 h8LbO40D9pT9njx1LqGqeKPhP4w8Iy+M5ZtAFp4rOgeMPBGvt4l8UweE9Z0zWYbjw/r+keL9 c02TujCpTxtapCMZYaeJly01P2UanJmvGFTLa1VqE5ywOEp5jk+KxmFjGnXrUJXccweFxuQ5 pOIxeU1csx2HpN0cRU9nVwz9lUqRpU6NfNKuIw1Km1Cmsbi8FVo4HAYidaOHw2IxEZVHhZP+ 1sqxf+Cp3jjxBZ2f7H3wR03wbq3xH8O/tL/tQ23ww8c/DXSvFh8D2nxN0LTvhJ8UPG+k/D3x 14qV2l0j4O+I/Gnhrwufje9tpvie7v8A4TWPjDR4fA3xAXU5PBHiD80f2iYtc+DHwB/bg+EP wX8M+Gf2IPirofxW/YO8T/Eb9n/4ZavN8T/2Uz8Ovi18XfDXw40r4g/s1z+DvDn7KviLwhJ8 Wr3SH8NftE+HvEPhGy0jxHB8OfEHh+PwXb3PxIb4rXn7G/ED/gnP+zs/hHRrb9mr4dfCL9kT 4meB/iX4U+NHw5+InwZ+CfgDw/Yab8TvBOl+JNA0S98feCPC9n4OsfiZ4RvvC/jLxh4Q8ReG NT1jSb+48OeKdYPhnxN4R8SrpPibSvM/Gn/BObxJ8WvBP7S978X/AI6aF4m/aF/aPPwLgm+J vhn4P6l4Q+Fvw80T9mjxva/EX4OeFfC3wZu/i/4p8T3fh608af214h8cDWfjfd694wvvEepQ 2mv+GtKtND03SeenRqQqYqcoVZc+a4fG1PZzp0pYjLKFLhSr9Sw1anVp4iWMnmOV4++Hx1Wj k8sCniOWjmlWlUToZhgoRyyPtKcYYWhgKElVo1p/7UuJMwxeOxmKwzWIwiof2Bi4UqOJwcZZ vLMKOFw1Sc8spTg/IfGH7XfxT+B5/wCClfiPSfg/8IfEnj/9njxx+yZ4e8WfEn4Z/Bjxva3v iOz+IPwV+FF38QPj/wDGLwR4T8V+NfiR8SfCvwK0nxJrPiqz8EeHvEX/AAlFn8JfB0PgseNI TZ3Pji26/Rf2/fGenfs3fEf4w6F8X/2MP21b65+JPwO+FHwF8Q/sw6n4v8AaFqfxE+P3iPwX 4C8O+Cfjr4BvfGv7RWrfCq98K+JvGGn+I9Tvbf4ja3r+u+Ebi4sLjwD4K1/SYP8AhIvf/Cn7 JHxk8Ha5+1J8SfD37SmkeHPjR+0tr/wJ8aS+LPDfwN07/hCPCvir4N/CjwX8ONX0y6+H3jT4 h+OdR8R/Dj4kXXhO6vNZ8O2Xjvwn478P+GNeuPD3hv4qWXiawsviEvlesf8ABNm9+K15+0H4 7/aA+Mfh3Vfjd8cbH4B2ml/EP9nz4Lw/AvQvh1f/ALMfi27+Inwc8Z23gzxl8R/j5f8Ajv4g 6T47vFutc8Q/EDxpr2nap4P0jw94C0rw/wCHtF068k1S6ccTFU44hurTdDJoY2WGcMPiPYYf CYBZxhcqjzLCLEYmrSxEMurzp5RPB4iviKlfHYvLqeCy+Ee2yeUMNrRhUoRwsoqtTxNelWxH Jl1BLMWqEcVDCYS2Or476tiscsbhaVPDYHA4XHVXmb+ff+ClsH7Z/hz9iP442/xk1n9mf4u6 Kvin9kPVvh9rnwp8I/E79n/XG+IMH7X3whS78C+KvBXjTx7+0bpdx4U1C2XR7ux+J2m/EjTt U066l1DSrr4V31vFb65J9keFfjb+0t8NP2q/hD+zt+0XrvwH+IemftD/AAz+L3jfwF4i+DPw z+Inwn1LwB4j+Cdz4En8S+EvE9j41+L3xotPiFpWv6J8RLKfRPGGnXPwyuNPvfDGoxX3hC8T xBZLo2F8W/2Of2l/2jvhh40+HPx8/a58E6jZ6/f/AAZvfD2j/CP9mCP4ceAdHu/hV8avBXxh v/EfiDRvGPxw+L/xI8S+MvEsfgu38F2VzpXxh8HeBfD2j6hdancfDrxHrcUF4n0F8Uf2Z7H4 o/tIfs9/HzU/ElpHpvwN8C/tB+BtQ+Ht/wCFodasfHtj8e9L+H+lXb3ur3GsW9vpVpoVv4Hk W402fw/r0PiGHWXt5ZtLSzY3t0IVqU3Usp+1zDMqk6VSfLD6tLhynhcFKqqcZQVSeaYbBwVe nTq4qFLCUKtZ/v8AMnjOaOJwdTBU8HiJwUVUxtapUo0JOpGtLC5bLDToycYSpqpicPXjWoU5 UMNOVfEU5wjg44D6t5h/wUB/ak8X/sofDTwB4z8Pr4a8K+G/FvxW0DwH8Rfj34/+H/jz4q/C /wDZw8JarpOu6inxL+JPw++Guv8Ag7xVrXhvVdf0nRfhxb6i/jrwH4a8M6/430fxD4o8Uwab p50jWfmb4j/8FFdc+En7OPwr8Ya38ev2DPHviz47ftG3/wAB/hp+0/4J8eXmm/sd6Z4btrHx L4r1T4r/ABLtdU+JOqL4Y1TwR4W8K63oeq/CDSP2hvEb+LPHlvoGl6X8UvDq+Kru18H/AGHP +yH4c+E3h8xfsKaX8A/2L/FN34k0nXPFJ8G/svfDfVPhx8UdP0yx1bTIvDvxW8FeCbv4QeL9 cstOh1q81Tw1qXg/4q+ANf0TxDBZS3Wq6z4Zm1/wnr/zxp3/AATYvrfR/E3jqX4y+H9J/av1 r9qT/hr/AEb4x+A/gvb+EPhL4X+LEXgC3+EkumWn7Pdz8RvEdxq3gTxd8MU1PQPijba18Xb3 4heONc8UeJfGlv8AErw34ik8O3PhqFDEe1xUZOcsPPEYGs+b3akqMMdw1DHYLDeyxMZqjUy2 PEMqeJjiMoxXtp1Vzqs8pxWEulUypUMMqnIqtGljVDlpyftMXPBZ+sBise54WoqUKOPnk31n D055zgp4ejhJwy6VV5tGr4noH/BVi9h8NftDeE9H8Wfsxfta/Ff4Xa7+zN4Z+E3xL/Zm8XS2 HwI+LWvftcfEq4+Enw+0bxVpWkeOP2g9b+Emu/DrxtaXh+IWiv4/8eXOteEYtH8UeH5dNu/E 0XhrSPb/ANof44ft1/slfBT4ifFH4iav+yX8XbDTNZ/Z40bwb4k8F/DT4w/Ca7sNd+Jf7Qfg b4V+OfDnib4Va58Y/i5Dr2k23g3xf/b/AIT+IOlfGzw1eWnieD+ydY+GGqaVF/al16v40/ZG +K/x4+E/xI8AftM/tKJ4u17xR4i+G/i74bat8FPgz4e+DXhD4F+LvhD4i0rxx4E8Z+CPC/jD xT8c/GniLxRJ450bTdc8Xj4j/Ffxj4R1mx02w0Lw94P8G2smuT67z/xN/Y8/aA/aO+FPxV+G P7Sf7V3h7WLPxj4Z8KWXgG0+BP7OunfCLwj4C8feBvHGj/Evwl8Wdc0j4h/FP9oLxt478VaT 4w8MeGVbw9F8TfCHw41Dwvaapo+oeCrnV9Uh8TabonWhySlGrVrUcTg6lRxlQWHxmVYWlg6k sHGjJ03RzitWo5hCtXUqWFxM6+WKrj4YSWYwopTyueJwtvqtDByxlF4qE4YytXpuUsuWJxEa 8cPH2mXSisTUp4SNCNbDupmlGnhavsskqnqfxZ/aB8Z+A/2v/wBlD9n/AEjTPDFz4N+OvgD9 p3xV4u1PUrLVZvE2naj8FtL+Ft94Wh8OXlrrVnpVpZX8vjfVV1+PU9F1ee6jt9PGnXGlNFcv d/mh8Kf2u/2nPjB8HP8AgnB+0N8fPCH7IfiPTv2p/wBq74e+E/CPgLTfgd45utf+CTT+CPj6 Zvid4V+I/iv46+KrSX4gava+DLS48OXWneAPDlx4C0PxZ4k8I3uo+NJZTr7/AHDoX7IPx88Q ftQ/BP8Aai+PX7Tngvx7q/wR8BfGT4e6H8N/hd+zxe/CL4fXdj8XLLwjDdeJs+Jvjn8ZvGVt 4zhufDATXru58W6n4W1nR7bwzp/h/wAH+CNS0rxLr3jbE8Df8E8P+EM+AX7A/wADv+Fv/wBp f8MP/GXwl8W/+Eo/4V/9j/4Wf/wi/hj4o+HP+Ef/ALE/4Ta6/wCEK+3f8LK+2f2r/a/i37L/ AGL9n/s24/tHz7CKFKt7bAVK7clTznh6pX/eNqnlsOMcxxGcT5YtJ1aXDqy6UJ01LE0+WEcv l9dpS5ahXyyGXY7D/uvrNTJs0p060aNX2lTH1eH+IIYKjGq6adOEs0xWVUazbhSquhD283gP rKn8J/su/tF/tS/AnRPGfxC+K/j34W/FP4T+Kf8Agrn8a/2dfjJqv/CtfiN4d8YeCNL8W/EX xB8JPB3jHw34o1z49+P9N0rwLpXxSHwp8MaN4N1fw9qkXgT4a3Mnh5PE2sSafZa5Z/rH+zR8 efGPx88Y/tOahLoeh6Z8Hvhb8cdT+B/wh1q0ttTGveOr34a6Jpen/GDxZqWo3GpT6Te6JafF S78QeAfDsOkaVYNaz+Bdek1C91SW8hXT/i348/s23/wQ/ZY/bv8AhlM3jL45eFv2uvHPxh8V /BT4ZfBv4EfEbUvi14O+N/x5XxJ4rdPE3xK8P+KvHvhax8M2PxIj0XXPC/xT8WeCvgz4F+E5 sIT408VavJe6XPD9UfC79hH4Dad+y/8AAz9nf49/Cr4UftHQ/Cjw9aXWoah8Y/ht4P8AiPaa v8UtYhudR+I3xFttP8Z6RrltYa74z8V6x4j1nUL+3VbyX+154ZbiRHYNOX/WI4LC0aqjVqZf kHC+CqQq1PYxpZjLh/h3BYzB0p0KdaFZ5DUyDN69dN+yxL4uwEoN0cLhK8Kzqpl+IxmKxtNe yWaZ/wARVqFTD0LxllFPNs0zHC4x4OcsL7CvmUs9y7LoVJOEYU+GMwp06darKtNfbtFZOg6B oXhXQ9G8MeF9F0nw34a8O6XYaH4f8PaDp1no+h6FomlWsVjpej6NpOnw29hpml6bZQQWdhp9 lbwWlnawxW9vDHDGiDWrvlyqUlBuUU3yuUVGTjfRyipTUW1ZuKnJJ6KUrXfzqvZXSTsrpO6T 6pNpNpPZtK+9lsFFFFIYUUUUAFFFFABXifxK/aW/Zy+DPiXwz4L+MHx/+Cfwp8Y+NRC3g3wn 8Svir4F8C+JfFq3GoLpMDeGdC8Ua9peqa8J9UdNNhOlWt2JdQdbNN1wwjPtlfzI/t/fF22+3 /wDBWj4Zaf47/Z1+BPi3xl8K7bwTdfCDxZ8PPHvxn/bH/bJsLP8AZqt7nw74w+C+mah8bdA8 P+Efhfp665feBtNj8CfAf4qaL4Q1Lwl8W/if4qutD1qbWNQ0/wAzNMweXUaldQhV+r4TGY6d GVRUpV6WDhC9CjVle1arWrUIRVGjjsWoOpVpZdiaNHE1cN7WR5THN8XHCyqToqpVwmHjWhD2 qo1MXi6OHVatTWvsKVKdarKVSeHw7qwpUK2Mwrr06j/oH8fftH/s8/CnxTovgb4o/Hn4MfDb xr4lm8P2/h3wf4++KPgfwd4p1+fxbqGr6T4Vg0Xw/wCIdc07VtVm8Tap4f17TfD8djaTvrOo aJq9npq3Nxpt5HDWsP2mf2ctX+Kep/AnRvj98E9Z+OejLfnVPgtpfxW8CX3xY05tL04avqCX /wAO7TXZvGFk1jpbJqN4LjRoza2DreThLciQ/k3+zBcaX4+/bh8I/EXwZfaV4h8Q3/8AwRH/ AGal8CeNIp7fUMjxX8V/iNeyTWuozieJoNT1TRtDub9p1k3y6dEt0hMcsZ3P2DPjB+xno37L f7Gv7L3xQn+HN1+1b8N38PWmvfs6a94Qi8c/tDfDb9qnSbfxFN8R/ivr/wAKtO8N6z8Qvh3e S+Kb/wAb+Nb/APaA1rw9oPhVPD3i0eNrj4gt4e8WWmuat0ZjKrhaGYxjWprEYWefUKMXD2df FPLuJeJeHKdbAUpyrxxE8F/q9SxuPoyTjKvnOV4BSoxqPGTweEpfVo14U8VJvCZBXqW5alLC 1M24UyziapHGTVOnKjTnLM/qWDaTlKjl+aY+o28LDB1/r39kj/got+zv+1B4B+CV7ffEv4L/ AA0+O/xo8I2/iux/Zku/jj4H8Q/FvTUuYdT1CG0tPDEzeGfGOupLoWmTa/Fdw+CrASaSJL5I DZwNcmf9pv8Ab5+Fv7Jfgv40+Pviv4g+ER0j4ZePvhJ8N9B8PeHvjh4dl+IOo+KfizZ+HrjT tM+JfhTxJonhe1+FV/p9prOo+Ov7Ms9e+IWo6j8F/Dmr/FGC2hit5/Dtv+Qfg/wz4c8I/wDB vh+zZqnhrQNF0bUbHx1+yl8RbS9s9LsUuYPHmpftxfDa6v8AxfHK0DOPEN3LfXiz6qSbt7e5 lszL9kcwVtftcQSSW3/Ba+9zFFZaB+03/wAEyPFuuX1zPBaWOj+GPB+hfsp+J/FOv6neXUkN tY6T4f8ADuk6nrWrX1zLHb2Om2F1dzukULsKxNeVPF4ihzUqEcLmNTD4ipJOWGpYWjmXB8cR WbnUjUhTw+D4gxtKdepWUfZ4SOOqRpOq6GF9ulk+Bq5jW5IV3gvrlbB0sO6lsQ6tLMsNhFNV VGSVOrSxeHnGg4VatOSrYf6zWl7PGP8Ad3xP+1R+zB4JufhxZeM/2j/gN4SvPjHZaZqXwitP E/xf+Hug3PxU07W5bCDRr/4cQar4itJfHFlq8+qaZDpl14ZTVIL+XUbCO1kle7txJv8Axc+P 3wJ/Z/0rStd+PHxq+EnwT0TXtQk0nQ9Z+LnxH8HfDfStZ1WK2e8l0zStQ8Zazo1pqOoRWkcl 1JZWc01yltG87RiJWYfgJ40+IelaN+0Z/wAFA9V+KX7XP7DPwe+F/wC1dofwz1b4W6z+078E fEHxt079pT9k26+AfhzQNGsP2f8A4heFv2uvgV4T+IfhHT/FN78Ro5/hV4F8N+NvFsXifxT/ AMJVeG+j+JHhdr32/wCBGufDb9jb9pH4f65+1l8ZrDRvAh/4Js/swfBr9nv9pr9pPRbr9n3S PE194I8T+P7742eDtR/4XHLZal8N/ix4ugvfhF4x8R/Cnxv4mi+JGp6ZoEc2oafrX/CDatPo EU8TOrSpzn7LBSrzpOKxM1N4d1Msz/Mq2XYxU5Rp4fMMvq5Phcoxn1ivh5yx+NxypYL6xk0s vzHz62U0aMasoTxGMqYfC0qrw2HpTpzxzqYrh/CPE4CrUozVXCcmc4nNE6VLEyjlWAw+IqVI xzOU8u+/W/4KKfssx/tOax+zLP8AF34WWWseH/2eLH9ozVvGmo/Fj4dWXhhfCuppf67badYF /EL3V1dad8NNKvPi/wCJr+5XT9O0P4Y6j4V8ZRzaloGvy6lpX1tqHxG+HukWvgq+1Xx54M0y y+JOr6V4f+HV5qHijQ7K18fa9rulXuu6Jongq4ub6KLxTq+saJpuo6xpWm6E9/e6hpVhe6ha QzWlrPNH/PN8Yj8IPE/xW/aN8G/s5eH/AA34P8KftL/8ET/Hvw5/ZG+F2m+Cj8Err4teKbDx z+0vr+reGPg38JfE+i+Btd1i5lsvEVj4xjt9A8LCDVfDmv2Pjaya78P6xbaxc9f42/ax/Z1+ NGif8EaPh58Ifi14R+JvjHQf2p/2ctQ8a6F4Gvx4kvfhjLon7NnxZ0a60H4uQ6Ylw/wl8Y3W q309hpHgf4jL4Z8Ya1caB4wj0rRLs+CvFn9jVgcQ8R9Sw9SLjia+eZRlbU/dr1aOb+I/GXC+ KrewVkp5PleSZdUapx5U6sZ4tuc3Wq3jsopU5VquGdZ0KGQ5pmVd8vNTpYjKfDzhriWi5yvL 2FLOM4zDOMJCnUqTdN4DE0cNVqSw1SFH9rNL/ad/Zr1zxvrnwz0X9oX4Hax8SPDGn+J9W8Sf D7S/iz4C1Dxv4e0rwTq17oPjPU9c8KWmvza9pOn+Edc03UdG8T3t/YW9toGrafe6dqstpeWs 8Mex8I/j38C/j/pGqeIPgP8AGj4TfGzQdD1JdG1rW/hH8RvB/wASNI0fV3tYr1dK1TUvBus6 zZafqTWVxBdrY3c0N0bWaK4ERikR2/nx8QfDrxb4h/4J4/8ABRq0+F2hxT3ev/8ABWP48eLv jJbWvg7WfHv/AAknwm8Jftc+EX+LMniLwD4X1jw74s+JGg2vwo8LXcPifwD4X8QaN4h8aeDt L1LwnpN9Fcaptl+rf2fPEU3xd/ap1H4+fB39rv8AYy/a5+K3g39lPxD8Oh4H/Zi+D3xT+C/w b1nQ9a8d+E9f+H2l/H/9ozQfjZ+2t4N8Fa74R1PRvEx+HHgO88HxfEmLR/FPxA1fQ/C+paBa a89rGX4mWJpYGrWjyRxOTZbmVeNOLnXpPMOE6XE8K1DB05VsXicHUxGJp5Fh5RpQ56+EzXMH W5cvq4AnMcooYSeZU6Neblg86zfKqEqytQqf2Vn1LI+XEYr2VPDYXEVY+1zGqqlVU8PTrZXh X7R5g8Vhv16+JvxZ+FfwV8KXPjz4yfEv4f8Awl8DWV3ZWF54z+JvjLw54D8KWl9qU4ttOsrn xF4q1LStHgu7+5YW9lby3iTXU5EUCSSELXgvxa/a68I+BLP9k3XfAMPhv4x+C/2sPj94N+Cv hnxx4Q8eaZceF7HSPGXgX4heNrT4h6FrOi6d4m0rxvpqR+AxY22nafqGmWuoJq326LX4lsfs 15+aX7YPiP8Aab8N/tL/ALFHxy+P+s/snfsleBPAGlftHaDF8SPHN58R/wBrT9mb4efFnxjp 3w0svh3r/jTxHqD/ALBl38OvHHizwZafFXwh4Q8Z+LLxvB2hvc3/AISsNTvvE/xJ02yj8Y0z w54esbj9ljxz4Q+O/gL4++GvjB/wWy8OfElPEvwa+CXjr4K/AWy8T3/7NPxT0XxyPgpF4z+J nxh0/wCIfhLxF4s0PU/F2vfEP4ffETxL4D1n4ja743tbG8TXNP8AEFtBeFrVMRisBCfLTpVs /wAgwlWEZQqVo4fE8ZcPZHXwOLpU51KmGnmeWZli8wp4mo8JUweEnl0YQlicyw9fDv8AszDU sHia0qkqtWPD3EWOh7lZYaWKwnDPEuZYathcSqcKNf8As/G5XhKcqXtK9LGYiGY05JYfLpLH /vXq/wC0V+z74f8Airo3wJ1746/BzRPjf4igt7rw/wDBvV/id4J034q67bXdveXlrcaN8PL3 W4fF2pwXNpp+oXVvNZaRPHNb2N5PGzRW0zJg+Pf2tP2VvhV4hHhH4oftMfs+/DfxYdbi8NDw x49+M3w58H+IT4jm0rw/r0OgDRfEPiTTtSOty6H4s8LazFpQtvt0mleJfD+opAbPWdOmuf50 9RsNQk+Hf7bP7K/7Q37YP7LH7P3xH+Mn7Vvxq8Taz8LfHX7JvxX+LP7aXjS88Y/FL+0v2dPi 18B/+EF/a38E+JfjXqlh4PtPhlJ8EtV+D3wF8RweBbnwjZeCjYXWueBPENtD9B/FPwL4av8A TP8Ag411HXtJ03XtfuPgR8PtG1TX7/S44tR1S28Kf8E+9I8Q6MJ0kDy2sdl4jubrXbazD4td Sm80lpYY2XgqZpOjlNXNKlGM/q/D9fiGrQjNJ1I0sJlOJllcK0HiIUK+HrZhUwdfFVl7RqNH FPK6NR4jAUe7D8O4avnMcpWLrfvMfVyunWVGag6kc7y7JqGaRlWp0I4nB4uGPnmNHDYT20VD CRwzzR0sfhswj+5/gn4/fAj4l+NPGvw3+HHxr+EnxA+Inw1urmx+I3gLwT8SPB3irxp4AvbL UZtHvLPxr4W0LWb/AFzwrdWmr21xpdzb67Y2EsGowTWMqJcxPEtb4cftF/s+fGLX/F/hP4R/ Hb4N/FPxT8PpjbePfDXw4+J/gnxxr/gi4F7eaaYPF+jeGdc1TUfDUw1HT7+wMWs21k4vbG8t Svn200afh5+2V8KfFVvYfsq+BP2XPDa+HPihqv8AwSa/by+Gnwv0rwNHa+H9RY23w/8A2XR4 U8LaA8D2cFpLDqOoXB0BVltms9YvEu7W5tbwpdR6P7Md/wCAfi98Wf2DbTwx+2f+yR4r1z9m vwt4xj8K/Ab9l39jz4ueCPi94D8BT/BrUfAfi/4S/tB6hP8AtZ/Gtf2e/B2m6jceGJdb0n41 /DfwR/avxX8FeEvDdg9v42+w6c3fjK1TBVsyoT9nUnlUMfCtNJU44uphc04py36zRpe1qYil h6C4fwmKxWHp08fNQzKpS+tUZYXDSzLyIYDD1snwec0qlWFPMsHjMdhsPKM61TBrBYPLq8cL jatHDrDuWZYnFYrC4PGVqmX0KMMI8VOniIxxdPB/sRon7Yv7I3iXxp4Z+G/hz9qf9nHX/iJ4 0sbDVPB3gLRPjh8MtV8aeLNM1XS31zS9R8M+FrHxPPrmvWOpaJHJrFhd6XY3VveaXG+oW8kl orTDxj4G/wDBST9kn43+BPjp8ULT41/CHwZ8OfgJ8YfEXwn8W+MfFnxi+GlpoNvb6Vrq+FvD fj3VtZi8SPoXhzwh8UNet9S/4Vbf6nqxTxlosFjqVhKt7fXGj6d+Qng/wz4c8I/8G+H7Nmqe GtA0XRtRsfHX7KXxFtL2z0uxS5g8eal+3F8Nrq/8XxytAzjxDdy314s+qkm7e3uZbMy/ZHMF aOlD4LSeB/jhpnjf9rnw3+yF8df2d/8Agrr+0v8AGXwT8RfEGi+HPiD4M+EuufE3xL8TbfwD eftJ+ENfmtvCfg/4Y/Gb4Z+IfFmm+A/EfxG8X/CQa54nu9Ch+HXj9PFr2OjavLq1aeYY/CTl Tl9UpY6i0lCEfaUM78OsM8TSVWvRdevRwnFGZ0KGGliKNPGzpUp8lKviKVPB+rVyXAxwWIxF OWKapcQRyuM3zTmqWFybivGVqmIjhsNiHQwuOxOX5NCdeGHxNTKXUrv/AIUYQUMV/RT8O/iX 8OPi/wCENJ+IXwm+IHgn4oeAdeN8ND8cfDvxVoXjbwhrJ0zULrSdSGk+JfDV/qei6idP1Wxv dMvhZ3s32TULO6sp/LubeaJPjT4r/tl/ETQfHvxu8NfAv4BaT8bvDf7K+haHrn7R2val8Y4P ht4g0691vw1H8QP+EA+CnhUfDvxvp/xQ+JmmfDdoPFWpaP468X/BHwclx4h8G6Da+Pru+1Xx BJ4S8P8A2Qvj1+0X8SvAPxt134J/CD9h34yXenftNeL9In+PXww+IXxA/Zk/Z8/ab0mbwl4W 1S4+NHgy40P4Q/ta6z4r8babqd1D8LfiJeSeKfF/hq58VeCNbh0L4o62miPpFj5bp3x28Jfs k/Er/goz4c/aa17wx8O/ih+0Fqngz45/BXwBH4s1HxLd/G248R/szfDr4R33w3/Z5l1Hwn4U 8RfGTxVonxY+Heq+C7bwl4T8Ht45aPWfBupah4L0eDxZosN1hmGKr0sPVxGFjONVcPTzbAYa ph61SWYZpiMvy7H5flEKMqWGxeMjPB43HY2f1OGHxMpZWqU/q0pVsM+TLsspSxtXDYqnCtCO aU8FU5MRDnwmBhnKwOJxleeHrThhq1NxoYOUMWlBTxs6kaSlRi6f2vrv7Vfxi8e6l4Ai/Y+/ Zy0746eEPG3wN8P/AB8/4XF8Vfiprv7P/wAFpfDnjko/w+8E+DfGWk/Br43ar44+KXiHT4dQ 1/WfDcHhbR9B8DaBHo954s8Xade+KNB0289v/Zi+P+iftO/BTwn8YtF8N6/4LfW7vxX4d8Se CfFH2GTXvBPj34eeL9e+HnxE8HajeaXcXek6pL4Y8ceF/EGiR61pF3c6VrUFlFqunStaXcQH 4qan+1fqP7KnwR/Yz/4Jkp+0F8CP2Vfj/pH7H/wfk/aD/aE+P/xP+HvhzR/2cvC9r4P07wpN a/DPw94617w3Z/Fv42azrOk69YeB9Cjll8LeCLHSrTxf43TUNIn0nStZ/Zj9kTw/+z94S/Zy +Fvhb9l3xt4Z+JPwQ8OaHc6L4R8f+FPHWi/Eyw8ZXWn6tqFv4r8S6l4+8P3l9pXivxXrXjFN f1HxtrMFyZLvxfca291FbXXnW0XsVI0Fi86hhKzxeBwubYzA4TFTnTnKf1TMcyo1PYPD06dN 4ajGNPAVa1dTnisVgm8LKn7DHvE+ViKUqWAymdXDPDYrE4bB4iclGuoVcPictp14yxKrylGO NxlTkzHBUsJ7GGFy2pWji6GIeIwOIofSFFFFZHGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRWZca3o1pqmm6Hd6vplrreswajdaPo9xf2sOqatbaQLQ6tcabp8kq3d9Bp gv7E6jNawyx2QvLQ3LRfaId5daa76Lzdm7L5Jv0TGk3sm7Jt2V9Ert6dEk230WrNOvzm/ak8 Y6b4U+JzXuo/FE2V7aeFdBufD/w8i/aR8ffs8+Oba80++1i9k1H4PeAbLQ9V+G37UvivxhNN aaTZeDfHNtJoll4h0LTPCWrX0un+LLyz039BtL1vRtcjvJtF1fTNYi0/U9Q0W/l0u/tdQjsd Y0m5ez1XSbx7SWZbbU9MvI5LXULCYpdWVzG8FzFHKrIPH/Hvwa+G2t6jrHjjxf4s+LPh4TR2 s2qXGi/tMfH74a+ErCKzs7XTopYfD3hD4qeGPB2hxvFbwtdvYaVYLfX8k+o3xuNSvbu6nxqx nJ4arTlC1OrTxKctp0nSm4ypVEm6bnGpGcK0E2oe9BpyjJd+X16OGr1ViqdacZU50JUqaSk6 irU3KnUi5U5cqdOUalNSi5SXsqilSlUpy8e1/wDaahbxnrPwkg17wfa+PIfiH408K3nhOO8l tvH2leAdP+AmvfEvQ/GTaOmsLqNlJea9baVaweI2sf7BubSeazsIF1JRdweN/Dj9pTxtrfw9 0qSXxp8NPismh2nwBuz4r+H8vjSyg0HxB4suNdtPEfw2+IeqW3xG1d/E3j3w3FoWl6pr32q7 0D+0U14Dxh8M9Et7rTE1f6V1r4CfBLw2kEniL4i/G3QI7r7R9mk1r9tL9qPS0uPscDXV35DX 3xygWX7Lao9zceWW8iBGml2xqWF64/Zy+Elpd6fYXfjX492t9q0lxDpVlcftj/tVQ3epy2lt JeXcWn20nxvWa9ktrOKW6uEtkkaG2jknkCxIzjl9ji+VpV4RqulkkJVFKd/aZVKs6lZQaahU zCVVVak4ONWnXgpQqyoznh5d0cTlMacIvDYqSUMX70qNHWWKqU51pRcasZezp0oSwtOlKU4R w8l7TnrwhXh438QPGSXXw+/Zm139ov4s6L8PtC8eeKJ9W8XeIPAvxA8d/s1+GorbVvhH408S eG/DN34p0/4rQeIJVsdWTTIXkn8YWln4k1Kyt7saBp4kj02Hwfxj+154q+B/h+3tPA/ibw74 38FSeJviDq/w51f4l67ZeJfFXxG+GWg/8IrJptt4R8U+O/jL8NNU8b6MdZ1Dxno+k/EXQb74 5eOb3RtM8M6kvw68XWGpW3iHVfun/hl/4a/9DN+0R/4l7+1l/wDPrrz7X/hz+zD4V8WaJ4C8 UfHL4j+G/HPiVbJvDngzX/27/wBo/R/FniBdRvJ9O09tE8O6j8fbfWNVW/1C2uLCyNhZ3Aur y3ntYDJPFIi7TjUeOlWpqjQpYiqqdPBxqzbqJSwtXD03UlDmxGJpPBRpKtKm6tXCVsbh5xks TVqN4XE5esPSpV6ONxzw0ZVq0nQoxpJOWJVepCjTrP6rSlDFvmjGo6VOtRwtaKi6FKMMzQ/2 oLlP2lPHXws8X+LvhjY+DfD2j6zqtmmiv4K1LUtBsdF0XQ9YvNV+Ifiqz/aC1PxX4Nt7WK61 KO/Xxp+zr4G8MwXrafpVl481O5n0ibxN9tgggEEEEAgg5BB5BBHBBHQ18t3P7NPwP13Tdfsr zxd8a9Z0i1F/ovii0uf2wv2otQ023Askk1TSdft5fjbNawgafdxyX9hqKKBZXKNcReRMpb6L 8N2+lWnh3QbXQr+41XRLbRdLt9H1S81/UvFV3qWlQ2MEen3914o1jUNW1fxJcXlosNxPr+q6 rqepaxLI2o32oXlzcS3MmlBVI0aNObjUdKhR5qynKc63tfaVKdepeKS9vBN05J8klCXs0oJR h5uNlhZyhOhGrTn/AAqlOdCnRp81CnRpzdNQqzamp80q0ZJtSqRcpczfNtUUUVscQUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfLv7WXjHwH4Z+Gt3b698UvBHw s+Ic1rq2v/BrV/FPj/wN4B1geNvDtokKXvhe98eahY6RdPbw65Ho+vxXKXWlT6J4iuNI16F9 L1qWC4+oqKipBVIOLtrZpyXMk4yUoySTi1KMkpQkmnGajJO6RvhqyoV6dZxc1CTcoKUYqpFp qVOfNCpGVOom4VYShKNSnKdOStJn5KfHb43/AAYtW8LaF8If2g/A114c0T4Z+IvDvgJPht+2 R8L/AId2HgX4sPeaYfC/jz4q2uofF3wbe/EbwlbxR/adTtL3/haP2iS3159T+G/iO717zJ/O viB8a/CniX4ifGexsP2ifhzq3g7xt4P1jSLLW9e/ai+G2kaBp19JpnhuOzPw88Pwfth+LfBT l9XsLttNXXv2Y/hnq+nWE19e6p481jU4pYPGP64fEz4oeCfhB4Xbxj4/1O+0vQRq+h6DHLpn h3xL4r1K71rxLqlromg6Xp+geENH13xBqV7qmq3trY2sFhpdy7zzoCFUlhW+HPxb8DfFRPEI 8IXmvC98J6nbaP4l0TxZ4J8cfDrxPol9faZZ6zYDUfCnxD8O+FvEtvaajpl9b3mm6i+k/wBn ajGZhZXc8lrdJDyQoKU6iVeFacFj4VoyiqjX1+UatdVo+0+OEMVRp0qk17WGFnhMNKc8NDD0 4+zHMHTw9Gay7ERowjTjDEOtLlqeyqYeUW6rw3JK1bBqbhG1N4ipi68oPE4nE1av5geP/if8 L5PDPjb4f+Ef2sPh1q3hC78Y+Lf+Ebk8RftheA/FWtv4R1z4PeFoLRbjxB4/+KGsa/qNvZfF JvE02jWXia8v5NHuoorq2tbfRU06Q3fFvxh+H+maP4t8I/D39r3wPJ4f/wCE18Wy+EtR1D9t Dwhq/imLwprnwd8L2trjxh4t+LF74umjs/ifJ4pfRodb1a4vNDuUju7GK00dNNmr9e65jTfE r6l4n8TeGx4c8T2MHhq30KX/AISfUtOt7Twxr9zrcF3dS6d4ZvHvW1DVbjQoILVtduhpkGk2 0+qWlhZ6lf6la6zZ6Vbw7u+apGTq4Chlkuam5e0o4ZYSUJzvUtKtJYJc837svb4pKCdZcucM zp8qawtRqhUeKd8XC7r1J06csS/9mUp13Ko7zjeUVVqzdoKcl+W/gz45fCrwt8bbJbb9pjw3 J4Y0nx1qk83jrxX+3D4I8c/DDWPgmfh1daboHga28B+JPjdq3id/iNZ+N5NEv7/xXrXw9Gs3 L6VrWq3XxW1e01L/AIR7VLfjr9oz4HWy/H34e6f4n/Z2+I9t8d9Snv7D4lj9o39nKw8I2kWu eF9I8KWkHxZtfEHxF0n4g2z/AA5fSBJpP/CC+DviF9p8M2mgyaXcWfiGTUNO039AIPj/APCW 5+Jl58IYvFE3/Cc2Fze6fc2snhrxZB4eGsab4csPF+peHoPHc+hR+A7vxPp3hbU7HxDqHhe0 8Sz+IbHSJjf3WmxW8Uzx+geEPF/hvx74a0bxj4P1e217wx4hs11DRNZsxKLPU7F3dI7y1M8c UkltMY2aCbYI54ik0LPDIjtnHDKrQjTWIjWpSwM8FVkrylicJiXhpVfaVYVVJTxFTAUq1TE0 JUa9XELE13VdbE4qdXSeP9hiIYmpltejUh9VqUlOtOlCFWhVxFfC14xeGjzcqr1qVKjUdTCL DU8PRp4dUsFhVR/K7TfiJ8FdA8Saj4jsv2tfhjqF/rXxA8YWHiG2l/ay8Cx+Ddd+Hd58Br/Q tM1e5+H03xNfwm2r6h8T9P0G4OtXOkXPj23mncXeqr4Yg2W3leifHLwzovwd8S6D4c+Olh4d uZ/DHwV8PS+G9f8A21/gr4u8W3nizw7qOryfE7xX4BvLP9qPw/a+Ffh9rWlP4b0hfCvhf40/ AvU7iysr+XwxpHgK4sUj8VftP4g8VaT4YOnf2smsiPUpr2GK50zwz4k16ysv7P0u91i6udcv 9C0nUrLw5p62VhcLFqfiCfTNOub9rXSbW6m1W/sbK5Twf4t8P+PvCfhnxx4T1D+1vC3jDQdJ 8T+HNU+yXtj/AGjoeuWMGpaXffYtStrPUbT7VZXME/2a+tLW8g3+Xc28MyvGtPDyqqtFV4yS w+UYPExhShFKlgKWJhQp1Y05RjTWYQqYueJpWhSrz56+Hp0atGnUpKOaQpQoylgKvL7TEVsP VqYiWtSeLpYmVSlN4dKc8NOjRw9Op71SGGgsLUnOlOrGp8W/skftI+B9a8O/DX4N+IvjB4I8 d/F7VdN+JOowro/xX+H3jzUZNK8M+Lbm40HRdQm0n4ufFLxHe+I5PAWo2Or21tceKvH2pNo/ hvxLea/4y1W+0e+1O9+9aKK7U5yV6koyqNzcpxi4KXNUnKN4uU9YwlGDafv8nO1zSkeNiKlK rVnUo0pUY1JTqSpuoqkYyqVJzcaXLTpclKKkoU6bUnCMUud6WKKKKDEKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKAPkH9trwuvjL4P6J4fkbxQkEvxd+EusXsng/w n8YvFeuppXhLxppvjDW/sKfAzwj4x8daBfS6LoGoQaR4khtNIsLDXpdKt5PEejX17p87fmV4 8+E11q1t4i0DTJPjL418LN8aL74jafP8SP2dv2ttc8d+P/DmufDiXwlaaF8UfE/xS/Ym/aD0 a91T4Q3wTT/hhql94S8azS+FLqR1ufB/imxh1q7/AHzorhq4GFT26TUViZudb3XJzbnlNSzv NRcVLJcFypxvFPERT5cTVUvbwOdVMFCjFU5z9hGpGnatCEY+0WKjKUV7Cc1OVPGYiEn7Tld6 VTkVbD4epT/EDxt8OPD3iKfV9ZtbD4yaz4w0vwJ+yV4c+GXjnx9+zJ+2P4g8eeF9c+BvxA1P xJ4/8QXXi+0/ZcsJote8QeHbu30vTPFuiaVp+r6/cnUIdXs/DtjfXHndz+zBp2m/BX4t+P8A 4geLm/aG1s+IT41hj1vSP2af2kBJ49h8UeOp/FWn6r8RvCNh+w14N8Q3Pifw7ZMlho+t+Jvj d8V59Gjvdd0vQDpGhasbG3/YaitY0JQxLxUZwVR1cyrtck+T2uawo08ZOzrOV5qhCz5r3c+d zU5Jk83VTB1cDOjWlQrLLoy/2ijzRjleHw+FwsKbWC5YQVPDxlKmo8jqznWjGNVqS/I7XNQX Wf2hNT8cWfh34l+Fvht4j1HX5fiGnh79m/8Ab2LfGLwzq3wzl8F2PhX4nfAnVPgPffCbVdf0 vVrhbuT4qW3iCPW9R0DStK0aXwzbhDJF8yfDP4AeGND+F3xS8L+Kvh9quk+N9f8A2b/D3wZ+ H/ifwv8Asi/tka/HpHiyx/4WfH4q8a30+ofsq+EbzRJfHMHi7QI9bvNJg1fW3ij1m0urrUoE j/tX+gyisY4FQjNRnFOdBYfnVO1SEI0sRQg6UlUTpuFHF4iDhG1KrOrUxNenVxdSpiJb0+IK lJJQp142qYGppiYazwOLpY2DknhHGbq4ijSVaU1KX1anTwNF0sDThho/h5Hpfi7xJ8Xbr4te MNB8W6Dc6p8VNJ8c3ugeGv2cv24/EkFnpWlfszeIfggtta6pqn7JnheS91C417UbDVmjl06x totIa7IuZb22htbz6U/4J6+Cn+E1lr/gG7m8b+JdQ1LwX8ONZvvGnjn4JfHb4d6vb6t4S8J6 J4G1v4f2vi34nfBT4a6Dr3w+8Lz2llefCbTP7V/4S200bWfEdvd+GhDpF/rt5+l9FbYeh9Wn WnTcF7eGGpVUoSXNSwmGp4ajBXqtRtClSnKSXNKpTV3ySqQnyYnNFiMHRwXsakKOGwtLCYaK rU5RpUqNd16Sa+qxnPkcp01zVP4c9f3kKdSJRRRXSeQFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAUNU1TTND0zUda1rULLSdH0ewvNU1bVdSuobLTtM0zT7eS7v8AUL+9uXjt7Sys rWGW5urqeSOG3gjklldERmHyvdftw/s72OsnQdQ1T4radqB8IaT4zgfUv2a/2ltO0y/stesL ++0Tw3pOu3vwjg0PWPidrE2k6voOmfBzStRvPi1feM9H1jwJbeCpfGmk6joFt9O+JfDui+MP Duv+EvEunxat4d8UaLqnh7XtLnaVIdS0bWrGfTdUsJnt5IZ0ju7K5nt3eCWKZFkLRSI4Vh8v y/sJfssSfA6x/Zvj+G1/YfBrTfh/ZfCyz8KaR8SPirol3H4CsdM8b6Mvh6TxdpHjex8bXEN5 pXxI8cafrN7c+I5tT1+08R30OuXuoILcQc9Z4tRxLw8cPKcaMHhIVp1YRq13RxynHE1IU6jo UYV/7MlCdKliJ1KLx0HClOOHqS7sL/ZtorGvHJuo1OWFWHap0va4S04wqyi61T2P15Ok50Iq r9Ul7Vw9tE77w7+098DvFl5fWfh7xq+pmwa2Rr6Lwt4zi0XUJJ/DOv8Ai24i0HxBc+HodC8S zaJpPhbX4PFcPh7UdUl8G+IdOk8H+K00bxbLb6JN59r37e37IPhrx54t+F+r/HPwrH8QfA3g 3RfHnifwjZWfiLV9a0/QvECXk+mWsFro+i351Xxa+n2Fzrd58P8ASGv/AB5pXhxYvEuq+G7L QLm21KbE0X/gnV+xzo3w+i+EM/wgfxh8H7Sz8H2Wl/B34pfET4rfGH4Q+H08CeHtR8MeGrnw t8LPit458ZeAfCmqW2n6re32paz4b8PaXq/iLxPJF418R32reMbW012Djtb/AOCcHwn8VfFb xD8QPGHxR+OnirwJ4jtPEVpcfs56n4h8AWfwS0//AISjQdI0HV7zS5dA+Gmi/GW21SYaJYak mrS/GG41FbyP7G1y+gLFosarvFp1o4ZUJv2OJ+rVMRz0qTrwwOLnhniVSderTjXzH6hh5UqN OuqeEeMxUsSqsaGGqaU45S5QdWpjo01Kn7WMI0ZV5ReNwKmsPFpUZP8As/8AtJuVatQ9ning XGGJpxxEJdlH/wAFAv2eJNRt9HbR/wBqe11e7tdNvLXSNQ/YJ/bs0zVbmHV73VLHTRb6dqP7 OFrezT3TaFr18tpHA12mh6Br3iKWGPQNE1XUrT3fwJ8fvg38S9UsdC8EfEHQNd8QalpniTXL Hw6ktxY+Irnw/wCFNY0jRNX8SpoGqW9lrH/CMPeeIfDtxoniVrJdC8UaN4i8PeI/DGoav4e1 3StUvPLfAX7C/wCyb8Nvht8O/g/4a+C3hy5+GfwnuPDl58PvB3jPUPEnxJ0nw7feDtf8a+Kv CWoRL8Rtb8VXF/qPhjxJ8QvFeueH9Q1ae/vdH1S9sbzT57efQPDz6V6H8FP2cfg1+zv4dTwp 8H/CEvhTQo/EXxA8WC0n8T+L/E8z+Ifil4kj8XePNSm1Hxfr+v6nPJr3iGJNRaGa8kttOK/Z dJhsLIm2O8eZVqilyzw6ljPYzinTrTjz4VYBVKbdSFKXs542eMcatZc+HwtOiuXGVquB5qv1 N0k6CxMazeFTjVlSnSS9ni3jpKcIwnJqrHA08LT5I3p18XVrVFLC0aOM9voooqjmCiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAqX97Dp1je6hcJdyW9haXF 7PHYWF9qt9JDawvPKllpmmW95qWo3bJGy29hp9pdX15MUt7S3nuJI4mxfBnirTfHXhHwv410 e31a00nxb4f0jxJplrr2kX+ga5b2Gt2EGo2kGs6FqsNtqmi6pFBcxpf6TqVtb6hp10stne28 NzDLEvS1Ba2trY21vZWVtb2dnaQx29raWsMdvbW1vCoSKC3ghVIoYYkVUjijRURQFVQABSV7 yvqmociWji17T2nM3fn570uS3J7Pkqc3tfax9i3y8qsnzXlzNu6cWo8iitOVxanzNufPzQ5f Z+zl7X//2WNoYXJzZXQ9IjAiLz48YTplYSB0eXBlZmFjZT0i77yt77yzIO+8sOOCtOOCt+OD g+OCryIgcGl0Y2hGYW1pbHk9IjM0IiBjaGFyc2V0PSItMTI4Ii8+PGE6Y3MgdHlwZWZhY2U9 Iittbi1jcyIvPjwvYTpkZWZSUHI+PC9hOmx2bDRwUHI+PGE6bHZsNXBQciBtYXJMPSIxODI4 ODAwIiBhbGduPSJsIiBydGw9IjAiIGVhTG5Ccms9IjAiIGZvbnRBbGduPSJiYXNlIiBoYW5n aW5nUHVuY3Q9IjAiPjxhOnNwY0JlZj48YTpzcGNQY3QgdmFsPSIzMDAwMCIvPjwvYTpzcGNC ZWY+PGE6c3BjQWZ0PjxhOnNwY1BjdCB2YWw9IjAiLz48L2E6c3BjQWZ0PjxhOmRlZlJQciBz ej0iMTIwMCIga2Vybj0iMTIwMCI+PGE6c29saWRGaWxsPjxhOnNjaGVtZUNsciB2YWw9InR4 MSIvPjwvYTpzb2xpZEZpbGw+PGE6bGF0aW4gdHlwZWZhY2U9IkNhbGlicmkiIHBpdGNoRmFt aWx5PSIzNCIgY2hhcnNldD0iMCIvPjxhOmVhIHR5cGVmYWNlPSLvvK3vvLMg77yw44K044K3 44OD44KvIiBwaXRjaEZhbWlseT0iMzQiIGNoYXJzZXQ9Ii0xMjgiLz48YTpjcyB0eXBlZmFj ZT0iK21uLWNzIi8+PC9hOmRlZlJQcj48L2E6bHZsNXBQcj48YTpsdmw2cFByIG1hckw9IjIy ODYwMDAiIGFsZ249ImwiIGRlZlRhYlN6PSI5MTQ0MDAiIHJ0bD0iMCIgZWFMbkJyaz0iMSIg bGF0aW5MbkJyaz0iMCIgaGFuZ2luZ1B1bmN0PSIxIj48YTpkZWZSUHIgc3o9IjEyMDAiIGtl cm49IjEyMDAiPjxhOnNvbGlkRmlsbD48YTpzY2hlbWVDbHIgdmFsPSJ0eDEiLz48L2E6c29s aWRGaWxsPjxhOmxhdGluIHR5cGVmYWNlPSIrbW4tbHQiLz48YTplYSB0eXBlZmFjZT0iK21u LWVhIi8+PGE6Y3MgdHlwZWZhY2U9Iittbi1jcyIvPjwvYTpkZWZSUHI+PC9hOmx2bDZwUHI+ PGE6bHZsN3BQciBtYXJMPSIyNzQzMjAwIiBhbGduPSJsIiBkZWZUYWJTej0iOTE0NDAwIiBy dGw9IjAiIGVhTG5Ccms9IjEiIGxhdGluTG5Ccms9IjAiIGhhbmdpbmdQdW5jdD0iMSI+PGE6 ZGVmUlByIHN6PSIxMjAwIiBrZXJuPSIxMjAwIj48YTpzb2xpZEZpbGw+PGE6c2NoZW1lQ2xy IHZhbD0idHgxIi8+PC9hOnNvbGlkRmlsbD48YTpsYXRpbiB0eXBlZmFjZT0iK21uLWx0Ii8+ PGE6ZWEgdHlwZWZhY2U9Iittbi1lYSIvPjxhOmNzIHR5cGVmYWNlPSIrbW4tY3MiLz48L2E6 ZGVmUlByPjwvYTpsdmw3cFByPjxhOmx2bDhwUHIgbWFyTD0iMzIwMDQwMCIgYWxnbj0ibCIg ZGVmVGFiU3o9IjkxNDQwMCIgcnRsPSIwIiBlYUxuQnJrPSIxIiBsYXRpbkxuQnJrPSIwIiBo YW5naW5nUHVuY3Q9IjEiPjxhOmRlZlJQciBzej0iMTIwMCIga2Vybj0iMTIwMCI+PGE6c29s aWRGaWxsPjxhOnNjaGVtZUNsciB2YWw9InR4MSIvPjwvYTpzb2xpZEZpbGw+PGE6bGF0aW4g dHlwZWZhY2U9Iittbi1sdCIvPjxhOmVhIHR5cGVmYWNlPSIrbW4tZWEiLz48YTpjcyB0eXBl ZmFjZT0iK21uLWNzIi8+PC9hOmRlZlJQcj48L2E6bHZsOHBQcj48YTpsdmw5cFByIG1hckw9 IjM2NTc2MDAiIGFsZ249ImwiIGRlZlRhYlN6PSI5MTQ0MDAiIHJ0bD0iMCIgZWFMbkJyaz0i MSIgbGF0aW5MbkJyaz0iMCIgaGFuZ2luZ1B1bmN0PSIxIj48YTpkZWZSUHIgc3o9IjEyMDAi IGtlcm49IjEyMDAiPjxhOnNvbGlkRmlsbD48YTpzY2hlbWVDbHIgdmFsPSJ0eDEiLz48L2E6 c29saWRGaWxsPjxhOmxhdGluIHR5cGVmYWNlPSIrbW4tbHQiLz48YTplYSB0eXBlZmFjZT0i K21uLWVhIi8+PGE6Y3MgdHlwZWZhY2U9Iittbi1jcyIvPjwvYTpkZWZSUHI+PC9hOmx2bDlw UHI+PC9wOm5vdGVzU3R5bGU+PC9wOm5vdGVzTWFzdGVyPm50MyIgYWNjZW50ND0iYWNjZW50 NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBm b2xIbGluaz0iZm9sSGxpbmsiLz48L2E6ZXh0cmFDbHJTY2hlbWU+PGE6ZXh0cmFDbHJTY2hl bWU+PGE6Y2xyU2NoZW1lIG5hbWU9IkRlZmF1bHQgRGVzaWduIDgiPjxhOmRrMT48YTpzcmdi Q2xyIHZhbD0iMDAzMzY2Ii8+PC9hOmRrMT48YTpsdDE+PGE6c3JnYkNsciB2YWw9IkZGRkZG RiIvPjwvYTpsdDFQSwMEFAAGAAgAAAAhACrJLE5mBwAACScAACEAAABwcHQvbm90ZXNNYXN0 ZXJzL25vdGVzTWFzdGVyMS54bWzsWutu2zYU/j9g7yBoPwfXkixZthGniB27K5C2QZ1iv2mJ toVQlEbRidNhQNE+z7ABGzBs6NM0D9BX2DmkZMuXBI6TXoC6BWyaOiR17t85zMHjWcyMCyqy KOFt035kmQblQRJGfNw2X531Kw3TyCThIWEJp23zimbm48PvvztIWzyRNHtGMkmFAbvwrEXa 5kTKtFWtZsGExiR7lKSUw7NRImIi4acYV0NBLmH3mFUdy6pXYxJxM18vtlmfjEZRQI+TYBpT LvUmgjIigYNsEqVZsVu6zW6poBlso1YvvdIhcBgMWIjfw7H+PBWHB6SVJSwK+xFj6gcySrtM GBeEtc3h2DarhwfVFSo6GtFAnmQSn+F+uJMa4MZZeiYoxRG/eCLSQYpP4fTnF6fCiEJQi2lw EoP0cW/1ICdTPzmQ6X2Xlo+LnUhrNhIxviyIzpi1TdDxFX7CItKiM2kEejJYzAaTFxtog0lv AzUwqw8AhuaHIleao3V2fNf33IKllyAYwseMGs6cO70EZJieJMF5ZvAE+NViSLoToKZHQiSX E0rCDKc19yCv4iwUCZ6eTgx5lYLgJqEAO37dNn+ZEgEGmy/RdPDefL40A+kbw8tnSQjLyFQm JkppGwnWLL/u+Z5poBw927ZhjG+2WJ2KTD6hSWzgoG0KYF3tTi5y0yCtggQP5QlamdIS40sT sKeeKRuW0uXcxpAPFIGcdZLwClcP4Rt4A2eHsyeJeG0al4KAXDMUCjUN9pSDOJtNywWnl+qH 2/QcUJUoPxmWn/Bp3E3A8MFECQ9g17Ypi2FXwi8wtiCJUyJP+CANkBDfBdk8m/1MRJrLQoId Pk8GE5LSTSLRtEqYmg3chGVyIK8YeA6ML5iNmqPkhHfEuToXLQUizemUB8CxpfYN6eglkKEp 2DVLz2Hs4MpQRiQArR+JiDB47QkRGVUrtaeQEs2PMa9QgvolrSArPdi4GPSlD1Yc5O+qxyUe wGFAMqi2glybTz5FeXhKBMHXZ8BZ26S88mqQmxisBTMulA1D7X63OyHYqo4rCyes4X4qxGhf ekgnDMEyohBiTeGxu7qfazm2XQMjXQSsIoztnfArcELCxgAmIOJ+Lm/8+P73j+//Mj6+//P6 7d/Xb/+5fvfu+u0fppFGMpj0SRwxsJQaBLK5T1dsp7HBe9Gtgyz3qfu77IiFKoH/2ml4Dd/2 +hWnZ3kV13ftSsc+tiue1et5davT9zud3yDoqmQVEkllFNN+NJ4K+mKqk4RY8XuDMHmyHAdu ix7y0Haq8N+yXUxJUkUfeD8MNjdElg0nwMo7RxrbcZrOeqRxt4o0LxMIwIh/isSfpZA1l6eW sABQnkEw6IWRosIIWgpnmOlXoEHGwqfxOI9MCoPAgl0jU7Pp2A0dmPx6o+atgCxABW7TySFC rVGrN4FYB/kCYRQAYBeMYFxC+vZgf1TqMkwV4+EcpFrqX37uElkcIZhnUdw2G3Mi0kKg1eMh vCgYDomYHucgROUalOmWScdfNwWFk0paesikg3BhGfrpHKQS3T007VvNul1TKcht1C3UqpJP kYi8OkiwQINu3fJqkLAeTtWoijk+zDUBjlyqM75ZOKjUUGApA8AWYj81qZDVWhzlyalIkpGC jFksu4wSyF75EnnYZVFwbsjEoBBSjLzeRbgKdTGAz2wRTdEHVHwsPjBi4/EK75DWTscPaJDw 0GD0grItjlIBbMejziaR2P4k5UA7ntRPpkJOtmZKpYpdj4pGt5wEAeCOmBmC+ypmrqN1faLw NZIrhauOXkoi94heugXQ9CFbreaoPYLWCHq4L2NLeFmFQ4hu98fEN4BNnRrvDC6xl9Rcd0n/ E7okAMbn03gTptD9nt3RY7mu3fummTefNrSYvqhv7qvbvCE1r277dsM67jStSq/RqFfcXqdT afrHFtS53fqRd2xbx54/r24z6J5T0KmJEHYNjN21qP3w5t8fPrz5b4GMHqykVeWMbszDsLgK CJh4RlID+vxtk0koTOUMRuE5jIZjB+eg1JUzGIXnMCJBALcLQJEPihl4rmfmNLViBmoK/cgt ZqBvoWe8YgYqSD1TL2bqpjFhEYfGp/oyjVHCftITxUiHRHVrs9Y21TYNTU8hFVxe6tyMEi6P VEtnSDLoE2/qq2Zp0KEjVXemwWkg9XUIdFihx6pD+xLF0QgaEFjmLWhLdPnTcq8W7opM45wK vKTCsVp9y0UMqKU4t0y12urtEhYNRXRbpygvBGi5+/v5+k2qs+1gZzsm4qRtup6vRLFX2I2t vS+lMNQSmiWUfLWFwpq266Lt7hX21SkMtZQrzF0ozK75dn2vsa8yJqKaco15JY01nAY02/Y+ dst9x5cKiqimXGP1hcYcB1qmSxqDXH9GhgO4li0C5hoSAYil0vdNF7z6ZvkzgAa8JGIS4QX0 WMuw4MZL4VuulVAquYD8koB8t7ac579ZAaFUcgE1FgJC6Szn1W9WQCiVXEDNkoDgb1GW09g3 KyCUirqeKtc+2Dxd/AHb4f8AAAD//wMAUEsDBBQABgAIAAAAIQBIVTBc0AQAAEYTAAAlAAAA cHB0L2hhbmRvdXRNYXN0ZXJzL2hhbmRvdXRNYXN0ZXIxLnhtbOxY4W7bNhD+P2DvQHA/B9WS LNmxEbuwXacdkKRBnWK/aYm2hFCkRtKO02FAkT7PsAEbMGzI0zQPkFfYkZQcJ/GKoFm2/ggM WKfj3ZF3vPt44u7zVcHQkkqVC97DwTMfI8oTkeZ83sNvj/e8HYyUJjwlTHDaw2dU4ef9r7/a LbsZcMVCHxClqURgh6su6eFM67LbaKgkowVRz0RJOYzNhCyIhlc5b6SSnIL9gjVC3281CpJz XOnL++iL2SxP6AuRLArKtTMiKSMafFBZXqraWnkfa6WkCsxY7RtL6oOPyYSl5jmdu/8j2d8l XSVYnu7ljNkX4ygdMYmWhPXwdB7gRn+3cUuKzmY00ftKmzFjz1iyhDGsymNJqaH48qUsJ6UZ hdkPl0cS5SlsDEacFBB/Y9sOVGL2lYOYs3tDfV5bIt3VTBZmsRA6tOph2OUz8w9KpEtXGiWO mVxzk+z1FtkkG2+RBmfdBODQelLjlfPorjtR0w9gDc6lNxAYwueMonDtnVOBGJb7IjlRiAvw 14VBjCDx5nQgpTjNKEmVYTvvIV71XCYkZvYyQ/qshMBlqYRMftfDPyyIhIStVJwcrJuvVRVE H01PD0QKamShBTZRuk8Em367FbdjjEwc4yAIgDYru9YupdIvqSiQIXpYguvWOllWqUG6tYiZ lAuTZXaXGL/BAJuOs5lYdi/XOWb8MCHQq6FIz4z2FJ7gG5Q7zJ0J+Q6jU0kgrsoEhWLEvuMQ zk7Hj6DstX2JOnEYYSQ3R6abI3xRjAQkPqQo4QlY7WFdkyMNb7DRiShKovf5pEyMoFmLcfN4 9T2RZRULDXl4KCYZKem2kDhZG0znhjHClJ7oMwaVA/SSBWbnKNnnQ3li5zWZAkhztOAJeOxb uymdvQExkwpB03c8gx3cJsqMJLDrA5kTBsvOiFTUarpKIRsy3xbco8TsL+kmamNgqzLsl5vY elCt1dEbPkDBQGTMttXiLn0qFuXpEZHELJ+BZz1Mufd2UqUY6EIa15sNpCu/TxfhGleui7Bp 7FmIcbX0bxZhCpmxWYOAbQA8dfl+bi1GfhgETcjYa/SqMe2pIr+AiiRsDr0FwO9/VZpXFz9f XfyGri5+vTz//fL8j8sPHy7Pf8GozHWS7ZEiZ5ApTUC1dYF7QbizpZRNjSeqKrCH1++MpfY0 /zGMm+3heOB7g6iz40WtuOUNm37kRYN4MAz8IB6H4U+AwPbkSommOi/oXj5fSPp64U4MeQsE EGF6/yYofApKdD8IG/Dzg8icT9pCEazPIM8/wMyWGUDzs2AnvHv2R48IOzN96+x3uGPbDXv0 G8S1hIM8g50Q3vv1AJ12GOzEt3qpJ9xxuDN96gQ2UMYmyRfaCTTvlqRtXh+pE1AsPVwU27oB 2388oCo3u4Gn2sRV/76lS/9fa/OpJ6h6+nVPMAxHe347HnntYGfsRZ0XvtcZdtpetDdqvojH gzG0BeueQMEFBIU9tV80D24FPr7/85uP7/96hEbAfoa4uw0g69uUhMkDUiK4KulhpuEbRK+A Sk+Ams5Dw4MGQa+ASk+AIkkCFzQgURE1B8YdZy3TrDmAZm4oqjnQ7TlOXHPgO91xWjWnhVHG cg7fjvaB0UywV45RU7YXvHX31f8bAAD//wMAUEsDBBQABgAIAAAAIQCTqn2YuwAAACQBAAAw AAAAcHB0L2hhbmRvdXRNYXN0ZXJzL19yZWxzL2hhbmRvdXRNYXN0ZXIxLnhtbC5yZWxzhI/B CsIwEETvgv8Q9m7SKohI015E6FXqB4RkmwbbJCRR7N8b6MWC4GVhZtk3s1XznkbywhCNsxxK WgBBK50yVnO4d9fdCUhMwioxOoscZozQ1NtNdcNRpHwUB+MjyRQbOQwp+TNjUQ44iUidR5s3 vQuTSFkGzbyQD6GR7YviyMI3A+oVk7SKQ2hVCaSbfU7+z3Z9byRenHxOaNOPCJZyL8xAETQm DpQuzjIPNHcFVlds9Vv9AQAA//8DAFBLAwQUAAYACAAAACEAaDsnQygBAAB6AgAAEQAAAHBw dC9wcmVzUHJvcHMueG1sjFLLTsMwELwj8Q+R79QGoYhESSpwmhuIA3yASZyH5NjR2m3h71nn IdE2SLUPXmt2ZnYsJ9vvXgUHCbYzOiX3G0YCqUtTdbpJyedHcfdEAuuEroQyWqbkR1qyzW5v kiEeQFqpnXBIfYcAhbSNRUpa54aYUlu2shd2YwapEasN9MLhFRpagTiiQa/oA2Mh7UWnycyH a/imrrtS5qbc9zjAJAJSjZPYthvsojZco/Y3x8lIGYa0rTliOH+8CYDRAt+JeGwm0rFPVc9K jSXm5QqyRMQWmi8sg4NQKSkKhotgC0Xq3IPl5OA1SgWvsL8gelpReOKFYhRNimcA54vVGeBn CMMVKZ7vot3LChCGjHG+AjD2j/lj7rdnYLglko988l2yXwAAAP//AwBQSwMEFAAGAAgAAAAh AIn0BA7ZAQAAlAQAABEAAABwcHQvdmlld1Byb3BzLnhtbJRTwW6jMBC9V9p/sHxvIaGlKQqp ulrtqYdKSXu37AlxZWzLNinJ13eAJkASrbI3zzDz5r03w/y5LhXZgvPS6JxO7mJKQHMjpC5y +r76ezujxAemBVNGQ0534Onz4tfN3GZbCV9vjiCA9hnL6SYEm0WR5xsomb8zFjR+WxtXsoCh KyLh2BcClyqaxnEalUxq+tPvruk367Xk8MfwqgQdOhAHigUk7zfS+gOavQbNOvAI03aPKC1Q nG5oq49O4sa4/W/mlliLFpSslqXcg6BNIYIE40C8wjoQv8/p9P7hIaWEVcG8iM/Kh5zGNBqW roxtK5/u0xT9PquMxuObVq+kgI5NE/KlEoOof3rOFCzmLPM1wX0+TigRuNa4ZYDZ3XkWp/10 2cw4WUhN6pzeTuIEV7/D11PbjGW8n1NUyOfVh4ZM+ybYimai7+gVJdZ4dGKC8lrlXUmXnM0O eD1IAz6Q1FAaCzZVUFIPHei5nGhOkkuax9lmQOfUUDPuAvUmSZwcGB4VY8MZBW0C+BXUoady rD/iHzbRrODCKk7S/+J1idMFCt64AO4aSile6flxjLP/S+h0euGkWFrG8a8nHM/qcRZP8QDQ C45WHyM8Epy0bf+2xTcAAAD//wMAUEsDBBQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAAcHB0 L3RhYmxlU3R5bGVzLnhtbAzMSQ6CMBhA4b2Jd2j+fS1DUSQUwiArd+oBKpQh6UBooxLj3WX5 8pIvzT9KopdY7GQ0A//gARK6Nd2kBwaPe4NjQNZx3XFptGCwCgt5tt+lPHFPeXOrFFfr0KZo m3AGo3NzQohtR6G4PZhZ6O31ZlHcbbkMpFv4e9OVJIHnHYnikwbUiZ7BN6qCIKK0wKfL5Yhp SANcejTGcVTW1bmp/SosfkCyPwAAAP//AwBQSwMEFAAGAAgAAAAhAM/n1N37AgAALAgAABAA CAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAnFVNc9owEL13pv9B41N6cAyU0IYRziTQTPpBYIKTHjuqvQYNQvJIMkn6 67uywUCw26ZcWK2e3+4+Sbv04mklyBq04UoOvPZpyyMgY5VwOR9499G1/9EjxjKZMKEkDLxn MN5F+PYNnWqVgbYcDEEKaQbewtqsHwQmXsCKmVPclriTKr1iFpd6Hqg05TGMVJyvQNqg02r1 AniyIBNI/Kwi9ErG/tr+L2miYpefeYieM0w4pBGsMsEshDTYmZGyTER8BeHZ2fk57lRr+l3p xITtD85d2vQyywSPmUWhwjGPtTIqtWRSlESm6hH0VHFpabAPRJnAYK3FZ9eFFOFE+ibWAJLM FuqRnHT779/RoAZIp0yzuWbZwoSd8xZidms6EzwB9J/RYGPSW2XRg7jSoDc8SUBudtF9sKbj 8VDwrMBvTTqLmYAhKhemTBhA6spBb4C5WzFlXJuQrm1/DbFVmhj+C+9F1yM/mQGn98BbM82Z tKi7g5WLwhaZsTqM8IIgN+6V68Lch+3bvBu2CwAafwSWXEW1JOJWgHlFCCcj5nMUwznLOjH4 oQJljEmKh2JrBOn09hUpkiv1KPPs/hhBynJhyQgMn8v9XCthEs1S66NkOV/6PcvxafkG4lxz ++wzHS+4xTPINfggUFJpjd/q1DLN8AbmB4JUQUawxkdJ7tQLxV4CPkmthAtCZhayeq5bsI9K L/GakC/4GNz/SRsvd8XlLkQpgCtbQ0J2faQWtmHc0XXq6Y5w7k1VwXZh74AJvLCvj9ut55vk tmiPrtTPxuTYDpsqroM2VFMHbSioDtqQ6y322vLw+rXalG+n3avdvGLx0s8zYoq+U09wdAgN 5Y0vh+QKFmzNsX80yXUI+iemBokOmRrEuVO5dYf417yOgQ25TST5CpA5Uvf8jjte0T/dRCq6 VdVJvnG5NPdZpEZuYG0a8aGTzhYMHw9O0u3+zkFvsAdr4UiGCybnkGwxxxtuqD2Uwz9sd05b +Cvm19bnxtJ2zIe/AQAA//8DAFBLAwQUAAYACAAAACEAt1ZkPIwBAADhAgAAEQAIAWRvY1By b3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAfJJRT+QgFIXfN/E/NLx3gHY62ZAOJmp80qTRGs2+EbjOEFtoAK3z76XMtDvGzSa8 lHP4OPfQ+vKz77IPcF5bs0V0RVAGRlqlzW6Lntrb/DfKfBBGic4a2KIDeHTJL37VcmDSOmic HcAFDT6LJOOZHLZoH8LAMPZyD73wq+gwUXy1rhchfrodHoR8EzvABSEb3EMQSgSBJ2A+LER0 Qiq5IId31yWAkhg66MEEj+mK4r/eAK73/zyQlDNnr8NhiDOd4p6zlTyKi/vT68U4juNqLFOM mJ/il/u7xzRqrs3UlQTEayVZ0KED3tgRXGO1CVnjwMfEIsSya7w4Jq90IIJ1vN3bWFkS562p 6k74cB9f5VWDujrwBzCQPQb3rt9q/FOeTjj40NOj8k25Tp5lY+Y1LmYCxemG0DytlhCW1p+F OptixlTfMSioLBbCjvXNynN5fdPeIl4QWuakyknZkopVFSuqyJtdaap46wLsT2P9n7jOaZGT oqUlK9asJGfEGcBT6O8/Jf8CAAD//wMAUEsDBBQABgAIAAAAIQBlFusb7AAAAF0BAAATAAgB ZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAJyQwW7DIBBE75XyD2jvBEzqNrYwUWIn5x7S3BHGCVIAyxCrVtV/L5bb fkBvu5rVm9nhuw97R6MegvGugmxNAWmnfGvctYL38wlvAYUoXSvv3ukKJh1gJ1ZP/G3wvR6i 0QElhAsV3GLsS0KCumkrwzrJLimdH6yMaR2uxHedUbrx6mG1i4RR+kLUI0Rvcf+Hg4VXjvG/ yNarOV24nKc+xRX8Bz6hzkbTVvDZ5HXT5DTH7FjUOKPZAReb4hXTLaXswOpTsT9+AernYwbI SZtevywtJd4YS/MsMk6WgZNfA8HJ7Lz0Ir4BAAD//wMAUEsBAi0AFAAGAAgAAAAhAEd1F6xs AgAAfRUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEAR78a0BMBAAB1AwAACwAAAAAAAAAAAAAAAAClBAAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAADpBwAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTgueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAA AAAAAADoCAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAAAADnCQAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTEwLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAAAAAAAAAAAAAAAA 5woAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBj XCO0wQAAADcBAAAgAAAAAAAAAAAAAAAAAOcLAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54 bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAAADcBAAAgAAAAAAAAAAAAAAAAAOYMAABw cHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAA ADcBAAAhAAAAAAAAAAAAAAAAAOUNAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTIueG1sLnJl bHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAADlDgAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAA IAAAAAAAAAAAAAAAAADkDwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAADjEAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAA AAAAAAAAAADiEQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAADhEgAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAA AADgEwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE0LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AEh6iUXkAQAAoxEAAB8AAAAAAAAAAAAAAAAA4BQAAHBwdC9fcmVscy9wcmVzZW50YXRpb24u eG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAAAAAJGAAA cHB0L3NsaWRlcy9fcmVscy9zbGlkZTIyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TB AAAANwEAACEAAAAAAAAAAAAAAAAACRkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyMy54bWwu cmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAAAAAAAAAAAAAAAkaAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMjQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3 AQAAIQAAAAAAAAAAAAAAAAAJGwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTI1LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAAAAAAAAAAAAAAAACRwAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAAADcBAAAh AAAAAAAAAAAAAAAAAAkdAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMjAueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAAAAAAAAAJHgAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTE5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGNcI7TBAAAANwEAACEAAAAA AAAAAAAAAAAACR8AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxNS54bWwucmVsc1BLAQItABQA BgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAAAAAAAAAAAAAAAkgAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlMTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIQAAAAAAAAAA AAAAAAAJIQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE3LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAGNcI7TBAAAANwEAACEAAAAAAAAAAAAAAAAACSIAAHBwdC9zbGlkZXMvX3JlbHMvc2xp ZGUxOC54bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wQAAADcBAAAhAAAAAAAAAAAAAAAA AAkjAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA +H+ZzIgDAADpEgAAFAAAAAAAAAAAAAAAAAAJJAAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwEC LQAUAAYACAAAACEAhFsfOfoEAADgEwAAFQAAAAAAAAAAAAAAAADDJwAAcHB0L3NsaWRlcy9z bGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhAO0C0Oj/DAAA928AABYAAAAAAAAAAAAAAAAA8CwA AHBwdC9zbGlkZXMvc2xpZGUxOC54bWxQSwECLQAUAAYACAAAACEAKNORjD8EAABQDgAAFgAA AAAAAAAAAAAAAAAjOgAAcHB0L3NsaWRlcy9zbGlkZTE3LnhtbFBLAQItABQABgAIAAAAIQBf 9gstuwMAAB8LAAAWAAAAAAAAAAAAAAAAAJY+AABwcHQvc2xpZGVzL3NsaWRlMTYueG1sUEsB Ai0AFAAGAAgAAAAhAN59OWoiBAAAKgsAABYAAAAAAAAAAAAAAAAAhUIAAHBwdC9zbGlkZXMv c2xpZGUxNS54bWxQSwECLQAUAAYACAAAACEA2I8yl0cFAACaEAAAFgAAAAAAAAAAAAAAAADb RgAAcHB0L3NsaWRlcy9zbGlkZTI1LnhtbFBLAQItABQABgAIAAAAIQBNFyzmOwUAAEUSAAAW AAAAAAAAAAAAAAAAAFZMAABwcHQvc2xpZGVzL3NsaWRlMjQueG1sUEsBAi0AFAAGAAgAAAAh AMzHVuQYBAAAtw4AABYAAAAAAAAAAAAAAAAAxVEAAHBwdC9zbGlkZXMvc2xpZGUyMy54bWxQ SwECLQAUAAYACAAAACEAwwEf8l4EAAC8DAAAFgAAAAAAAAAAAAAAAAARVgAAcHB0L3NsaWRl cy9zbGlkZTIyLnhtbFBLAQItABQABgAIAAAAIQCKxAy6dQQAAFkMAAAWAAAAAAAAAAAAAAAA AKNaAABwcHQvc2xpZGVzL3NsaWRlMjEueG1sUEsBAi0AFAAGAAgAAAAhAHzxpblfBQAATxMA ABYAAAAAAAAAAAAAAAAATF8AAHBwdC9zbGlkZXMvc2xpZGUyMC54bWxQSwECLQAUAAYACAAA ACEAPL/dm+sEAADQDgAAFgAAAAAAAAAAAAAAAADfZAAAcHB0L3NsaWRlcy9zbGlkZTE0Lnht bFBLAQItABQABgAIAAAAIQBk5NL7JwUAADIUAAAWAAAAAAAAAAAAAAAAAP5pAABwcHQvc2xp ZGVzL3NsaWRlMTMueG1sUEsBAi0AFAAGAAgAAAAhAJTWPPnNBQAAhRYAABYAAAAAAAAAAAAA AAAAWW8AAHBwdC9zbGlkZXMvc2xpZGUxMi54bWxQSwECLQAUAAYACAAAACEAGMHcAOkLAABU YQAAFQAAAAAAAAAAAAAAAABadQAAcHB0L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAGAAgA AAAhAOnjbhfBBAAAsQ0AABUAAAAAAAAAAAAAAAAAdoEAAHBwdC9zbGlkZXMvc2xpZGU0Lnht bFBLAQItABQABgAIAAAAIQDJMuUt9AQAAKoQAAAVAAAAAAAAAAAAAAAAAGqGAABwcHQvc2xp ZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEADG+x6jsGAABvFAAAFQAAAAAAAAAAAAAA AACRiwAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhAI9UeSJuBwAAoy0A ABUAAAAAAAAAAAAAAAAA/5EAAHBwdC9zbGlkZXMvc2xpZGU2LnhtbFBLAQItABQABgAIAAAA IQDtAtDo/wwAAPdvAAAVAAAAAAAAAAAAAAAAAKCZAABwcHQvc2xpZGVzL3NsaWRlNy54bWxQ SwECLQAUAAYACAAAACEACRKYtyMMAACNWwAAFQAAAAAAAAAAAAAAAADSpgAAcHB0L3NsaWRl cy9zbGlkZTgueG1sUEsBAi0AFAAGAAgAAAAhACUkznNqCgAAO2YAABUAAAAAAAAAAAAAAAAA KLMAAHBwdC9zbGlkZXMvc2xpZGU5LnhtbFBLAQItABQABgAIAAAAIQAzzOqFbgwAADF3AAAW AAAAAAAAAAAAAAAAAMW9AABwcHQvc2xpZGVzL3NsaWRlMTAueG1sUEsBAi0AFAAGAAgAAAAh ABPBjW0fBQAAHBEAABYAAAAAAAAAAAAAAAAAZ8oAAHBwdC9zbGlkZXMvc2xpZGUxMS54bWxQ SwECLQAUAAYACAAAACEAIQLzQt0FAADmGQAAFgAAAAAAAAAAAAAAAAC6zwAAcHB0L3NsaWRl cy9zbGlkZTE5LnhtbFBLAQItABQABgAIAAAAIQBOvl7NqAgAAA46AAAhAAAAAAAAAAAAAAAA AMvVAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA yg4Z29kAAAC+AQAALAAAAAAAAAAAAAAAAACy3gAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9z bGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAjuJAPNQAAAC+AQAALAAAAAAA AAAAAAAAAADV3wAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJl bHNQSwECLQAUAAYACAAAACEAdSU1s1QFAABWEQAAIQAAAAAAAAAAAAAAAADz4AAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhALTPWBm7AAAAJAEA ACwAAAAAAAAAAAAAAAAAhuYAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIx LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAFCtRi1xBgAAhhsAABQAAAAAAAAAAAAAAAAAi+cA AHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0AFAAGAAgAAAAhAHjnkwfNCAAAsDcAABQAAAAA AAAAAAAAAAAALu4AAHBwdC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAFCtRi1x BgAAhhsAABQAAAAAAAAAAAAAAAAALfcAAHBwdC90aGVtZS90aGVtZTMueG1sUEsBAi0ACgAA AAAAAAAhAFiXqoRiNgAAYjYAABQAAAAAAAAAAAAAAAAA0P0AAHBwdC9tZWRpYS9pbWFnZTEu cG5nUEsBAi0ACgAAAAAAAAAhAOptek0AVAAAAFQAABcAAAAAAAAAAAAAAAAAZDQBAGRvY1By b3BzL3RodW1ibmFpbC5qcGVnUEsBAi0AFAAGAAgAAAAhACrJLE5mBwAACScAACEAAAAAAAAA AAAAAAAAmYgBAHBwdC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbFBLAQItABQABgAI AAAAIQBIVTBc0AQAAEYTAAAlAAAAAAAAAAAAAAAAAD6QAQBwcHQvaGFuZG91dE1hc3RlcnMv aGFuZG91dE1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAJOqfZi7AAAAJAEAADAAAAAAAAAA AAAAAAAAUZUBAHBwdC9oYW5kb3V0TWFzdGVycy9fcmVscy9oYW5kb3V0TWFzdGVyMS54bWwu cmVsc1BLAQItABQABgAIAAAAIQBoOydDKAEAAHoCAAARAAAAAAAAAAAAAAAAAFqWAQBwcHQv cHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQCJ9AQO2QEAAJQEAAARAAAAAAAAAAAAAAAA ALGXAQBwcHQvdmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQDY/Y2PrAAAALYAAAATAAAA AAAAAAAAAAAAALmZAQBwcHQvdGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAM/n1N37 AgAALAgAABAAAAAAAAAAAAAAAAAAlpoBAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAA ACEAt1ZkPIwBAADhAgAAEQAAAAAAAAAAAAAAAADHngEAZG9jUHJvcHMvY29yZS54bWxQSwEC LQAUAAYACAAAACEAZRbrG+wAAABdAQAAEwAAAAAAAAAAAAAAAACKoQEAZG9jUHJvcHMvY3Vz dG9tLnhtbFBLBQYAAAAASQBJAMgUAACvowEAAAA= --------------040902030708000800070508-- From nobody Tue Dec 2 07:52: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 5F5AA1A026F for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 07:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgbxIKSGgu1E for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 07:52:24 -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 67E021A1BEE for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 07:52:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 952A62002A; Tue, 2 Dec 2014 10:55:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6896E637F5; Tue, 2 Dec 2014 10:52:22 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 54D8C637EA; Tue, 2 Dec 2014 10:52:22 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <547D3382.5030104@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547D3382.5030104@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Ad5JBWDOW_ElAiM2s6Plguw4tX8 Cc: 6tisch-security@ietf.org Subject: [6tisch-security] invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:52:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene, you said in the "9am" call that you sent the slides out, but I didn't find them in any email to the list. If they are the same slides at in Honolulu, then I guess they are in the proceedings. I'm sorry I was unable to turn on my mic in the coffee shop, you would have just have had muzak and espresso machines and crying babies; I had just come from dropping son at school, and I did not have time to either return to my home office or make = it to work in time.=20 You have done an excellent job of explaining the layer-2 security processing that the join assistant will need to be able to do.=20=20 Will you commit to writing this processing up in a way that can be put into the detailed 6top join processing?=20=20 I see now that my mistake was in assuming that it was well understood that a node could process both encrypted and unencrypted packets, and could distinguish packets encrypted with one key from those encrypted with another key. I see that it was this detail that you wanted to discuss; I see no controversy myself, but this may stem from having spent 20 years working on layer-3 IPsec mechanisms (rfc2401 and rfc4301 speak at length about this ki= nd of thing).=20=20 I see from your explanation that this is all possible with 802.15.4, and I thank for this detailed explanation. I can not disagree about any of it. Are we done talking about layer-2 issues now? You have my agreement. Will you document the layer-2 attributes which must be configured for the 6= top YANG interface definition? Which role do you think should own the multica= st key material? The JCE? the PCE? the 6LBR?=20=20 Tero has suggested a mechanism whereby the we could have a cycle of 16 keyI= ds for the multicast key. We will need to delineate which RPL messages can be trusted when secured with the layer-2 multicast key, and which ones require a peer to peer key.=20=20 Clearly the Minimal IE-based 6top interface has to use peer to peer keys. Given that we have introduced locally significant key pairs via the 6top interface, do you think that there is value in using the assymmetrically secured RPL messages that you defined in 6550? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVH3gNoCLcPvd0N1lAQLmVAf9HI4TNlhb4L4fNkA6fTjG9/A1vaQ8l2mv C27da9O0uHksF+hMvuqmZtFp7C9BQn/WUozWx5NxHucvxSM4QEgRi2bwBoDypU52 s00IPDcQf/Htqy1U/AQUeFxYt086pZmU1QVSFGRgVcQmL/6uSI/r1HsRoHziTsct oDPnsjY7F+uKVUbpw4nFGo8CeoY2cjg0h1dGF3UZa2FWmCoWrum9w1DjjHRw0s/m DY3bsD9hsrAZgOHRH0fs1+KOUo0P/51zbLFtDIgkJ2wbflyZxzyhNhaWvDzS9YiV HQi5da84jT6Pl1BXcYCTWvaf/rgLVny2MwZGXYNMH3RlVGy77nOLJw== =dLQX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 2 08:01:53 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790511A1BE6 for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 08:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY3jD30bhh9T for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 08:01:50 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA55C1A1BD2 for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 08:01:50 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so12034494ier.28 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 08:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TxumAUuTCEVaCx/h1t68zlJgy0a2kEeNKEls2mjNEjs=; b=M0JtfbdvtzpUqGKbAjg04qW3OFynA91ijBk8hqsKJ6NKsw3pr6kHefQ5AnSZCu1coM p0nAGBu523UsfL8g2CqgGHFWujytb2TMb1LB90BrHQKNlSelZ42ed01dd9Zdqzrb/bmU 5+v1s4u3pb2H8ZKpH+zrmCOcYMIQN8Ahbubu37l7r9WenHxkPyV42bzsywLYNoTaPvaz WOINCYxjpn57mL3EC0nPhglD04X180EFZ9o+tR2i7vlYpXIjlMvw1g5jeX4/Gby6rudP V7rCWqdWBmR/Y7mvM5OtDZEB0POiPiaMM3F0JXYv2Nt/HYSrNjNzWeBTorAC7hT1+8zE oTfA== X-Received: by 10.42.255.72 with SMTP id nh8mr3161261icb.1.1417536109769; Tue, 02 Dec 2014 08:01:49 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id o2sm12040855igv.12.2014.12.02.08.01.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 08:01:49 -0800 (PST) Message-ID: <547DE26B.5090503@gmail.com> Date: Tue, 02 Dec 2014 11:01:47 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Richardson References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547D3382.5030104@gmail.com> <3933.1417535542@sandelman.ca> In-Reply-To: <3933.1417535542@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Stkoo8wkxJeRgjxCeTWwmHku0Ww Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:01:52 -0000 Hi Michael: I forwarded the slides prior to the call to the 6tisch security mailing list. This also included details on what to be discussed during the call. (see http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00295.html) I did a partial write-up of all details, but my xml2rfc editor (I used the online version) did not seem to work yesterday. I will try and get this off my to-do list, since the devil is in the details. I will have to reflect on some of the higher layer routing aspects you asked about. (I did have some slides about routing aspects, but we kept it to MAC behavior, both because of time issues and because you had to drop off the call and we really would like you to be there). More later. Rene On 12/2/2014 10:52 AM, Michael Richardson wrote: > Rene, you said in the "9am" call that you sent the slides out, but I didn't > find them in any email to the list. If they are the same slides at in > Honolulu, then I guess they are in the proceedings. I'm sorry I was unable > to turn on my mic in the coffee shop, you would have just have had muzak and > espresso machines and crying babies; I had just come from dropping son at > school, and I did not have time to either return to my home office or make it > to work in time. > > You have done an excellent job of explaining the layer-2 security processing > that the join assistant will need to be able to do. > > Will you commit to writing this processing up in a way that can be put into > the detailed 6top join processing? > > I see now that my mistake was in assuming that it was well understood that > a node could process both encrypted and unencrypted packets, and could > distinguish packets encrypted with one key from those encrypted with another > key. I see that it was this detail that you wanted to discuss; I see no > controversy myself, but this may stem from having spent 20 years working on > layer-3 IPsec mechanisms (rfc2401 and rfc4301 speak at length about this kind > of thing). > > I see from your explanation that this is all possible with 802.15.4, and I > thank for this detailed explanation. I can not disagree about any of it. > > Are we done talking about layer-2 issues now? > You have my agreement. > > Will you document the layer-2 attributes which must be configured for the 6top > YANG interface definition? Which role do you think should own the multicast > key material? The JCE? the PCE? the 6LBR? > > Tero has suggested a mechanism whereby the we could have a cycle of 16 keyIds > for the multicast key. We will need to delineate which RPL messages can be > trusted when secured with the layer-2 multicast key, and which ones require > a peer to peer key. > Clearly the Minimal IE-based 6top interface has to use peer to peer keys. > > Given that we have introduced locally significant key pairs via the 6top > interface, do you think that there is value in using the assymmetrically > secured RPL messages that you defined in 6550? > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Dec 2 08:20:23 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31031A1C04 for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 08:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.501 X-Spam-Level: ** X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] 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 FsoJZmPGy7KQ for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 08:20:19 -0800 (PST) Received: from smtpdb9.aruba.it (smtpdb9.aruba.it [62.149.158.251]) by ietfa.amsl.com (Postfix) with ESMTP id 081981A1BF1 for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 08:20:18 -0800 (PST) Received: from mail-pd0-f172.google.com ([209.85.192.172]) by smtpcmd03.ad.aruba.it with bizsmtp id NgLF1p01R3jdzTD01gLGrL; Tue, 02 Dec 2014 17:20:17 +0100 Received: by mail-pd0-f172.google.com with SMTP id y13so13443067pdi.17 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 08:20:15 -0800 (PST) X-Received: by 10.66.141.165 with SMTP id rp5mr111615957pab.121.1417537215482; Tue, 02 Dec 2014 08:20:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.79.10 with HTTP; Tue, 2 Dec 2014 08:19:45 -0800 (PST) From: Giuseppe Piro Date: Tue, 2 Dec 2014 17:19:45 +0100 Message-ID: To: Rene Struik , 6tisch-security@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/jEhgQ5U99eDjoOcappbrs4pIqLs Cc: Giuseppe Piro Subject: [6tisch-security] Joining node and DeviceDescriptor 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, 02 Dec 2014 16:20:21 -0000 Rene, many thanks for the today's discussion. I've understood that we could use the EXTEMP flag for mixing unprotected and protected packets within a secured network. I agree with this point. The problem I've remarked during the call is related to the creation of the DeviceDescriptor associated to the joining node (that stores the EXTEMP flag). In particular, form the reading of the IEEE 802.15.4 specification, I've realized that in the Incoming Frame Security Procedure we have that: - the presence of the DeviceDescriptor is done at the step "g". The Device Descriptor Lookup Procedure may return a failed status in the case the descriptor is not found. - the check of the EXTEMP flag is done at the step "j" and it supposes that the previous function did not return an error In the case EXTEMP flag is set to TRUE, the neighbor node can receive an unprotected packet. I'm fine with this. My question was related to the creation of the related DeviceDescriptor. In the case the joining node sends for the first time the message, the incoming frame security procedure will fail at the step "g". To solve the problem, the neighbor node may generate a new DeviceDescriptor (with the EXTEMP flag set to true, for the moment), thus being able to receive next joining messages from the same device. Did I capture well your point ? In that case, does the joining procedure waste resources (in terms of packets, delays, etc..) ? What do you think ? Thanks and regards, Giuseppe -- Giuseppe Piro, PhD Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: peppe@giuseppepiro.com phone: +39 080 5963301 web: giuseppepiro.com From nobody Tue Dec 2 09:43:59 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F51A6F60 for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 09:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=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 rzFkvde4oVgs for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 09:43:48 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DD21A6F3D for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 09:43:48 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so12044232ieb.21 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 09:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=a/CHoEOPEnWPJ+P6HFnULgMErxcDu5mTQODRzvgYz2A=; b=cTuWRFlch7P2czMaxC3wRuYqk2OBkgOfdUJamsHpGKe8BHOeItyngZFLpAXNBstntl G7B7QV+xFAhiQJGYcWMLgez8hyx7JB2VcYcXfh1+JLJQ7+MrhwwOzteaYFvCh7X7CrPF GpOuqQq9Y2JYL+19TIXm356GLyrU3UaV/4gGME2mDa6KlvTK5PaTj7i9LPSGWV7wpi3v MtPhRhqhIp+lNSuoXILy8EIqHje9/jsn0FJ1P1leTtcDNmT7alAFsRbDyD3voDqA2Yi1 y0Lb6LfalzdCMx7tOFW4rQY8Z+4Ma5vY5gAvK85BPQU3tvlN/w08HqD8LZ/kErAashTR X1JQ== X-Received: by 10.107.165.75 with SMTP id o72mr429518ioe.33.1417542227114; Tue, 02 Dec 2014 09:43:47 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id w8sm12168915igb.7.2014.12.02.09.43.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 09:43:46 -0800 (PST) Message-ID: <547DFA50.8000801@gmail.com> Date: Tue, 02 Dec 2014 12:43:44 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Giuseppe Piro , 6tisch-security@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------090006000605020406020302" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/PRZgrFWks5x4Rf5_jcwRNCc9lls Cc: Giuseppe Piro Subject: Re: [6tisch-security] Joining node and DeviceDescriptor 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, 02 Dec 2014 17:43:53 -0000 This is a multi-part message in MIME format. --------------090006000605020406020302 Content-Type: multipart/alternative; boundary="------------080906050803010901090603" --------------080906050803010901090603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Giuseppe: Thanks for your note (and for good points on the call). Correct. The exempt flag is simply a mechanism to ensure that the higher layer can act on a received MAC data frame received from the joining node also when the joining node does not have cryptographic keying material yet. With the first message, while MAC security processing fails, this is overridden ("pass through filter") by setting the flag via intervention of the higher layer; once the exempt flag is set, this is automatic. In either case, once the received frame is at the higher layer, the higher layer can act on it at that stack level. As said on the call, the higher layer should only set this flag if it wants to accept entertaining join messages and should remove the flag once the joining device should have the proper keys or spent its grace period. I did not check the reference to processing steps for now, but essentially trust this to be correct. Will revisit MAC aspects later on. Best regards, Rene On 12/2/2014 11:19 AM, Giuseppe Piro wrote: > Rene, > many thanks for the today's discussion. > > I've understood that we could use the EXTEMP flag for mixing > unprotected and protected packets within a secured network. I agree > with this point. > > The problem I've remarked during the call is related to the creation > of the DeviceDescriptor associated to the joining node (that stores > the EXTEMP flag). > > In particular, form the reading of the IEEE 802.15.4 specification, > I've realized that in the Incoming Frame Security Procedure we have > that: > > - the presence of the DeviceDescriptor is done at the step "g". The > Device Descriptor Lookup Procedure may return a failed status in the > case the descriptor is not found. > - the check of the EXTEMP flag is done at the step "j" and it supposes > that the previous function did not return an error > > In the case EXTEMP flag is set to TRUE, the neighbor node can receive > an unprotected packet. I'm fine with this. > > My question was related to the creation of the related > DeviceDescriptor. In the case the joining node sends for the first > time the message, the incoming frame security procedure will fail at > the step "g". > > To solve the problem, the neighbor node may generate a new > DeviceDescriptor (with the EXTEMP flag set to true, for the moment), > thus being able to receive next joining messages from the same device. > > Did I capture well your point ? > In that case, does the joining procedure waste resources (in terms of > packets, delays, etc..) ? > > What do you think ? > > Thanks and regards, > Giuseppe > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080906050803010901090603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Giuseppe:

Thanks for your note (and for good points on the call).

Correct. The exempt flag is simply a mechanism to ensure that the higher layer can act on a received MAC data frame received from the joining node also when the joining node does not have cryptographic keying material yet. With the first message, while MAC security processing fails, this is overridden ("pass through filter") by setting the flag via intervention of the higher layer; once the exempt flag is set, this is automatic. In either case, once the received frame is at the higher layer, the higher layer can act on it at that stack level. As said on the call, the higher layer should only set this flag if it wants to accept entertaining join messages and should remove the flag once the joining device should have the proper keys or spent its grace period.

I did not check the reference to processing steps for now, but essentially trust this to be correct. Will revisit MAC aspects later on.

Best regards, Rene


On 12/2/2014 11:19 AM, Giuseppe Piro wrote:
Rene,
many thanks for the today's discussion.

I've understood that we could use the EXTEMP flag for mixing
unprotected and protected packets within a secured network. I agree
with this point.

The problem I've remarked during the call is related to the creation
of the DeviceDescriptor associated to the joining node (that stores
the EXTEMP flag).

In particular, form the reading of the IEEE 802.15.4 specification,
I've realized that in the Incoming Frame Security Procedure we have
that:

- the presence of the DeviceDescriptor is done at the step "g". The
Device Descriptor Lookup Procedure may return a failed status in the
case the descriptor is not found.
- the check of the EXTEMP flag is done at the step "j" and it supposes
that the previous function did not return an error

In the case EXTEMP flag is set to TRUE, the neighbor node can receive
an unprotected packet. I'm fine with this.

My question was related to the creation of the related
DeviceDescriptor. In the case the joining node sends for the first
time the message, the incoming frame security procedure will fail at
the step "g".

To solve the problem, the neighbor node may generate a new
DeviceDescriptor (with the EXTEMP flag set to true, for the moment),
thus being able to receive next joining messages from the same device.

Did I capture well your point ?
In that case, does the joining procedure waste resources (in terms of
packets, delays, etc..) ?

What do you think ?

Thanks and regards,
Giuseppe




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080906050803010901090603-- --------------090006000605020406020302 Content-Type: application/pdf; name="6TiSCH Security - extracted slide Security Architecture for Join Process (Rene Struik, December 1, 2014).pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="6TiSCH Security - extracted slide Security Architecture for "; filename*1="Join Process (Rene Struik, December 1, 2014).pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO29fVwU1fv/f3ZnZ1FcU9MU0nS1UlGEnZ2d2Zk0MTPTIu8ys3fk vZiFCqgocrNSmlaYmVaaGNZby4rS1FJLBbxFRXmb5h0gggLerCIiotztb2aA3UHPWaHmLPy+ j0/5x4rL7Guv63ld55zrXHMmRG/woYx6g/h/zYuJ09xD3I1GXs8YzD680ag3GhmDnjUYDPrQ yfrXe+inu1N68f/QKbXeZmIM9re5B/ZwHy5exiz8O8uIb9BPk/7Gmqr+FuTOGbn7/2aQ/63m 94Lc33aXPjVEEEez+l60vpdBb+TNeoYz0uI7BMX9B7v7Pv+q74gX+7v7vq6njO6+g/SUu2// Yc/rOXffgb4Dg9x9Bwzr08d3WOjkSVMnzpoRqqcY4VdmBM2eNn2m9AvC6xmhM/V0377ugwfo 58ZNzJhZ0pzoDMDowepF7i8M1g+XFDDmagW08E0ZjjLBFfD1VcBDFCRkRnwcMyvpyAEdmPWz 2tshgqXtImhRBAUVYaTqKUL8hQdEWJ+JzC/aaNFNUrXyGQWMX5O8TAdr18EKOgwcXEd93WGE uiO8rHjZogIPD0/PFBL0X0S2leng7Tp4Jzro+uqgITri5uVkf7zRz7M7ODdhJxh+gJwE0yEE E2Yd1t5htoqSLF0bMLmzDxj+HvkaVAfTSHRwjUOHkWokOkyNRIe5ceigDY1EB91IdDjLp67U gT2fOtVBy3SwBorBOM4FhF05u8Qcb7NNmaR/4ubmLWqw7mk3X5hNTI0ktws6BJsYcY51obey j/iKY52/LhYMb016QnU06BhD19LBG+E6qPrqoGA6gvoEX0sbq+0zf+Gy5P+MaQK+7KiRTQ3N jEyJMBPm4RZh6msRBk7rleLTYz27a4O8Y0FwE7Iz1DP4R11+XsHFpX41ngmTe0bgU6aDN8Kj lzLV1zMm1FTZ46bND4zuoWkj8wkn04D2CVtfW7AwOnoH55dlWXQnwYER5cDyHzIU5hMG/wzk mciCoo2iT4jBfcHw/5LTZD5h5DqEdRvcJ/VllIIxauVmlVwrSNTtU4FTG+TTdYdTBBGYnSKB 8VK/L5YSYG2SejBs7cI4m4spsnYJenZWyUHBEpfUXQdqwXML5HlU5hETbo9IxngbgDdnqOHu MLnMHU+AtYnqQVB3OJuSKuKOhKw5RVmWgdrQmC+6+wLSTTMB6g5zg7vD3HDusM+8WGlmjphl KDPzCq48lLltrKewsh/kpo5LAHQT0gTziCilYT3CGhrMIyaHCGGNYjYjzFBfERRMREZU/tFF 8RYPQ9L3nRLjLfcKr6XZbIZWgV21r42fDjZbWoyBuoducPfQDeYee2VSEkEhSnLKVCZXbH4p quRKUWKizXOTKrBtV75pK3B4jzYd6hRhIWlm4SZRxilBfrNK0quH+fXyYb62iAYmg224wDXK RVCIkU2ZafCk4S1sRQW+ROeko8lasPA3YgU0gfAiEyzGBBJ03lJ2OtEmMNG160CQe5psD8WC b3As+IbDQm4GAQvE6kgRM6zY6h9emUcQIQB8+jERIdvNoGpEmI0iE4j9FHN9RZhhw/zs3LO5 X471WKx1fy8O3JlODoMZQ9TRsEyYjY2ACVEEXiYmDWs+Xv84AG1OAjgQDG4g4mbeKdzbIstz sXbUZjW4s5yMglqCaXAgnFVzXAYE0zBAOEYNwSBoIBQZNeJm5xVeXCoCAfKGwWcSZq7BacBe R6oLDVzD0OBYFnKUnmHNCDMosiyMs9w4XjQ0Mbr8Xln8smWCS0YePpj8Y7djzcCjQ5sugBEq ampwQjnsdbWHEcq5rqiGJlQU0SCE2gutnEkkFD7LVabQGpQxp0xYGOvagPDoIWD4U+QrUCpN jYFK7LXFuNml2ReH+nkuJsBpEl7t5RquvFjLEg0CpmN3iDOLYMKBUGZ3yPrMrPwTGxN1bQja UwVmTCRnQ8E0uwDM4/+VZngg9xDZGrYm5sy4t4aCzlmunc6y6RaAdj1pcKCMfBrKJv5a69mZ y0U24wkQn65+EcqmuYHYtJuBN4hsGjCaIW5WTuVPvokeGzQgKrcWE7VENBCYtSzR8ECIIjAD MbIKiMdUIBJqBho3EEKyKhOT1Ug1iAokH4UCQbsICA8RiK/lImpZAj8Q70tAtAbxnyKAoPED 0awKiF4gCmoGFj8Qc+1AeJKtYMUJnsVenJhdWg3EqdD+oPgbUhYdnFyHwARijllfHUaYjoyZ JcUxETM8N2gm3eNVSy6RA6FYsC7AYrKExWgQDcWCbwxY8NixiLp6fO9SEYtb5R1A8dPki1As eNxYBMzLPlR8eqxHNRYTEVhgryxPGtWizGbzkyrLnxAWCBkmgxE7GX3sZEQeIVtCyJBE4C5v 37uyv128MKVIjdWB28fINhAyRB2YybD2icw/sdRPMMbhPXEgNo4cCiFD0oGXjJFhqX/YrIxI xrJviPlQMhjXkOEnkfEe2QIyt5BE4N0MS8iaWZFm0eaowI65mhYIQ6CpUGZqkRVRkeanvQoG agE9RNMSshSTVGDenjztbqso6UR01icdaQ4+WEdsgFqDcwkWaVVYcOQj0ITBOdk3VyRhBGVa rpVt9LN5enouBgn+/n88uhN0/ko7FZo2pKIzomSgSNoIOjunqCzeIpgktDwOfLyfHADpbZB0 4O1tOFniFV6a05yYvvbnrm5g7u8aTxgiFNVgiNjrOJIIsxnRk65IHScj9OLThPZucUnWlqF+ 5yMrCss6ffdUmP5IWlOw67vmz8tIMclF8bwZLoqrrygOJir4+tmF33ey2KasfWRc+UZ9UnPQ +5Emg6FuMjWYm0y1RHCooU6ZxWOk9cbHvokei4kOqbHg0mnycYcOijLLhfAMPL/S9b1hkIbd MBhnuXM8fYafzTYxidxdea+srMBiDbXZaNooBO3NkE0XTi51P7Ny5YLto1UxQ1q8CXWZ2QUu u1btsggr2RzqMictoAo1qJyLKMrPEpuWXug8HVzaT74MaUWVdPAMovdRkVbUgOC87Otzxnqm kN/2SQD9upE0zClG7FW5IL/ga0XVThlCNoM5xejkFi2F2g4jK/YXvljgsVhjsxEgP9etKWzq Kung4MZQZup6iVlcUXmxHdFK/+Th5mCFRrMEsgMq6eBNOHdAE86Ffx4TsyzGO2n/YTWIjlB3 hMKBvUKHhoORi0Ddh6zQrue58CUxg8Q7PAI+1DSFAipqMMOHPmUANem67wgtooiQ+UuWPAbW 3CBWwrKGqIM3IWbzymSNyDvHi81jPVLI0s8iQb8e5HgoGNgrdQIYRTVgqEl3KBisC8D4vBqM MZomUDBY3GCMDDscfbu8OXEcgDUBxCJoumCdUKFIurA+G1l2fdtY3SU18F0i94YMCexVurog wTcCJPjGgASPHQl+VllmSRUSi+BI0NjLcxISUkUKzNtOQsd0UQRuJEJqkDBq3GBISBowI3Eo utzaS0Iij/gIhoQoAjcSc+1IDJZ7w7HKp432s1gwrfKDMiMuphdYbJ6V9AUQEJQKsoe5dYDS ib1EGNRbpDNLorMz6Qalk8FOZ0bIwio63zynIaF0Mo2BTgY7nX3nXqum0+eo3Bv227xFEWg6 FbnNW/JGy3GBkzTAP1Gtg3KJvUZZFy65RsAl1xi45BqMy1reELhEnAelTIvdnLzk68K0fzHo HxAETpaTXrBasclZbVSZWrEdzd8/6gI+ep4Mh5FhcnKju0L1gtlluZV/bvSsrhf8xw1KqKQD L6EhdkK/bkt8DCNUFNHghJoo3IQmZEYVp2XZdAMAGzgQnHxEvk0vI9RZWVgRQuOic87/tyTL Y4Pm5Avh4MMb5BAoGU5u/FeoMmwpTf5ZjFiJ0LzP3DRIHZgJPWon9AUiFkqoySWEVq1PfT4j tVBCTdgJzYheGMMlHd7XBIzer34ENrabnPXnKrMbmxH9oVjYe3z+xwubgtXD1I9BsXBBFXzm 9TLp1t3AgVqQc4KE1tUkHbjxDK/BcyYBrbaKIrDjWVSD52skCcXT7AI8V9Xg+ZW6OQxPxuDk vgZldmh6RxYV58frYmN1bYi1niD8F/l44tgjZ5wcDaFQu1VY+Y2LJdLREIuJOG9/cOtteV+N qZZRMDM6+4id0b+IpTBGGUMjYFQ6rLVhGKXMDjRo9O1hTH3RYKCNkeFF+4WhNdpWdrCf5m5Z gV/LqLJ7Je3YYn9/3Z44605raqTV2zvVf/Qrd0visy+W+I212KLv3cu3TEjQEAM/sH22Mw5E HupshNKEfSfhZHBaxM3bjETTJQRNzrYRlKGpT3BRRRVNvf4mCShNNHaazoTZaXpOLdtccvQ0 MGK3L42whCI9DQGz8pLXCDBVCDA1T9qT+lTPpKbA8nST56B0YN9OuJ12OWP2pS5ESL8hIzzA NxoiHQoI/h2FPsEVFduyJEA+J9VQQFgXAPJhDSBt1fIatr1zjRH7fk2Iffr6dq4Z4TcRRRWL h5y0IcB/ompZopYI5L60Iu1zJ4OPWO6WM0TnpP3HtOAjH+IHKBb4dxXOWyqul1RhsRKBBe8i LPakADC6pVo2P7HfAWpixaZfE6JBS5E7QBPOR98rkO4AjQ4bBV7+lHwCVk8XdXAczrPKY3uu jrx444SfxUaNI2J1uhE5/cG5q259YXyw2LcY4kLK77xfkiWe093rIpwP1ugSPt4W4FCr1VA4 GNxw1GTPNuDFycOBfyIJu5Fe0oG5jSRjXqHfk08Sb/R7MbYF2J5NjICNaizjxCPK9EFLHhnX uZsOjLGp34W1TrCcE6co0zox705lbrt4jxRSmCeCPrtIDdQpHG6nWM/NuZ4p5NBJKjawK+hl gvdcsc5qygo5Zd6ymLeTDia7g7euqtvDjGEW+1xNiAMZFTGGd5YgIkC/Z78WROxRPwmzhCiC MyH2OhSxxNYmP/8RWpadaNFpYlr6bdy4nALFNu1ClEWQfYGKWCQoc+b1E2kiHp59h4Be/UnZ OoUxyXQIeCCMUt+JMQWbGFt7z72Y+2W8bh0QdYAIuQ6ZPUyuIWRtl9TmILKpWjYttz+PQxLB 0Yg+X0WexxHb6+ut00sGax+NWbdYD/aEEidRxuAZrEeVRxUeL349vrLSlja/eXlZsy62cltJ i9V9OvXuCT4/0cITNkU2i5VVlIsUmSJb+wZXHD09VreOGBXY1TN6SCsftmvXrtPZQDCmN3zo M5tdgE2MgE2P1GYg4rj6eZQIjsYZywlX32JDskdpN8+PW9cdnLlN5MhKJqxRLgTVuc/U10MM 9JDssyFXSrIswrz9gE3n7e0fl+CdkeDvHxubMmJsdOW92+Ipn7ZDbIcmA+aeUeWGtHgaZi/O gN9poZLT9ghO+7yW01i5CKTTFJknrNj8UsXt4t7EDn23Y63BxT6aBIQxxEce4ZxLz7p8asvS sTbaaPy0Cbdy1c9tXgCBudp5sBiX1PCIjQtllsHpUcUn0sbaPD08pQnUJz0eBXEztNFQ29AN BwovF8EZERM5RWb5/htX/zbrYmet+3xxULixgjgNK5VzNPoOP2VK5QlnQgv99lq036ou2mxg X3uyHGEPARGc9hAmlIU2aUn82Pgx4KUvyOegcLDY4UgP/VqcMYhwtFX3gxqDxQ2H7tD1zJDL fQiy34gBLcENFQIOJ6cIKHSv4fmo3CJhOrmPOGADNyvIMoQ5MLMhzCav78+PF9joG9YWvNRV vpcjY4PHz0ZkDRvzzqj9oMbg8bNxLTPcwcYi4iysqsg5qeYpU1VM3RC/I7CsMD6x0nBB28Ea NLWVD7inctsMJdXJwQYK7fjNvXngxFDxZJ5yawK4+Rr5GMI7mFGNm5lz5+fTYz26gz5BqeCl HvKbxx2o8sZGgKooogFRZeQ6eBOizKlMTc/61jNRh35JtNmMLdWp/v7AfY/2WxinvJNjFhTi NOT2qV1zxgqcGsvjwM1tpA/CNZg5DQjNq1yf36mG0//IOTXa18a82EbNwTmt79IYtjLOmFXc lBh1M14F+uUQQdBIYRpDpDCuiRR1TaQcJM7Bilk84yRSlOlWmJUSWZTdjAiZ/+Xq1uAbH2IX NEycnDuhdJj82GUnuHmBhE7EJB1YwyQjtPjKNxEba8JkmzxMHK3lvNjVzSEaWpRpLc8Myz6d ZbF5BgtrcNvZ0W+AzLwmbtCA4VwQMJ/UBMxqdV+oYzjsAXPkmjBDrgmYghbyrW5ZwHC4A6YN 9fLd4mu+YkPG2t+INdBo4VwULR5itPQBN38lUU7BHi25h74ps0dLSK2DFWrGe8bg5Ahohcb7 82GVJVI7cVhgIDj+q7xp1B4pkg6XRIpYaJj3NXRokUS4IFLu2iNlGJEBiRRJB95IuUTHTtaT AHTYBr6GhImooDGESZWOhgsTh0ecnEOtjEcCoiqTrxws8Fgsbv2D7Imae9Awwb5Jk3AmtDIr 0aabpHp+amfQ8zdyFNQvpkYSKaYGjxSTSyJlmxQp3wqRsgARKSaXRErV9MsqRIoRESlm3JES F2W987NZPKQPXDirKZEZwyAXgQwTQ32NYYAV486EXLm20U8IE9A+r5YIXi4Cc4ykXUuvipH+ AwAoOImIETP2GDHHThRj5InHwFpojJixx0h0rRgZTj6L8IgLYiTZHiODb0KPRmIoJ93/isVI nnTPkhAjGzR3YDFCOdsDVCRGMmblHsr+09dDfCak5r0OCeCJVrWKxbxcigsi5ZIUKSMBuNmO OI/yC+5I+agqUgaAb2CRQhlcECl5NZEiLOY7wyNF0uGCSPH1rI6UTaQO6hHaJZFyuipSIjXF KBFmvA1cZ8Oy8wsShTXSQK3WK3oIuDCU7A71C/atUDFSwqVICRgtRMoI+JhC0djX8obqSJkF vkUoQJ7krowC78zgD2KWLYvhxv3krQUBW2t1O/K1dOCPlD/tkTID2mXIUKxrIqVq3jVccxtq DPybsWnXsiQ853+5mgA3xxJ7UcbAjucUCc9vwX9hdRXKybNKlamrWDPnFO/PLxByRkd2FDge IMeilkdcg2fNlMe31nlRDo/wjQFP7PvB/j/G/R59erDWHbj17gkKOxE7UMbAjKfpEwnPjiqw HlIkFxWwBgpnkTwu8vK55UuzKismJpEenh77w3lQ3NytC8ItjYJRoxE7o+HWvOvVjHbUFMGM YcS+ERy0+tdfIu4M1B4G4BZJrIdNQ43SLjDiNihlOp0u/6fPzNyO2hEAbLwjF1HLErixiJRj Megq9NZ5xsi4BIvXJSyybmluQY3BOGmWVMQYbbYNqiwua0GQSX8Naw4KrmoYSLe6pANJhiLd 6qbmPRKLbpKEV7/hozqAHeuIUoQ9XAFHbzscP5CwMwgZI+ciOMQFStZBTSHUGBxuOGJ7rdpa nMQL41rPnjQo/IH4DdK9L+ngacRNtYp07ydcebPvxHs3LDYb9WkTEPCbVvbwAXtnsaiDpRBn GijTWex9NvirGHVSWrI7iNaroUUemmowMuzdxJII1P0UynQTz1o8dfusiyphQr7kcz7l6KOg YqtGflCmQS4FBYcy9aY2zCulZbZOxJX5iz5uDY4lEwdhcNAUbjgSzobeOBifqJukGviBTbu5 C+hTqoXdrsfQ+HeVIktv7P++QKpuADkiFMvIVXA0vBDI1HepwsCWKv4/rdpRdnn/0LG7bTZb fEyAvpvXnv3Jn3hV5u39flun3WtXpSYnH967/9CxPbHed4tKsoQ3VpRWuB3VNH9havtXm4O3 hneQzxBomXK0KxXZDcsIKy6M6e1rq7Cl9XvmQv44EvyV26Q5bMFHm7FvpGfMuiPe+TEAtO06 EPyvA3zXQdSBuk9ZoQbglTsqr17v1m5Gn7mVVysSbTaPQZq4OGv0kK6g2bbmsENyJVE81gdN 335lmt/M4mMbsyyegzQdrAl//HgLLOzq5gsbpmhnT+hUZJgKmHXrTm5+J4H2tH7uF8ZPUYFv 35d3CNlbgxmTwQk2irQGB8wpTD60aEZlecXB+e2CNxkI0DPErQI2txO1cDxiUajI3C7oq83z DtzK9LNUTNA/bqCNKjD4Q+0mGDGiFp7DeQNeG/PQ0qICcbRYtexQ2t9tQPpezVxYljYZnDwv R5EsbT0/817F0vhYm4dnE1VgoPax4dGgWU/tS1A1YgWYx3mg2Miww5V377UnQvR70h8H67/Q wI7rlHTwiG5UhRzEvFwqPpbujX7zv2wGzu0kTkDtweK2x+1BQfzMYh/BHuYDrcH3gzSJUHuw uO1hcveOun27OfHG/IUftgLpnxNbYUt3k1TjwrmDlBFcmHzlxRnR5ZVH+nUYFzhBDULD3Yqg vuFx+0Z35Hr6nFvGGt9sRfiGx+2b22mX+8y7oSV2AJARQPwMG3UYqbCDKPopMupYz0YV3svv pHtKPSZsFGjWmYQdpVqlA6tThMXizov/C9fm9BsS6wY2PAd3iqgDr1NSf4nf8k4ZpQ1Vgcx1 xEZZHdS+GGDEjnasp6TPejnoGUuxipi+dn2X5iD8nsYDagypqR3rPagWa15uu04eKer3AhJA 90L4LpKkozHAwTQYHI65GcM52fdVZG62YmbK3cqKdkTnpJSUJuAThtgCW7EynBM4lCpn3Mry 04YmW158zQtULiLfgcLB4YdjTQ0cWwU4piPg4FwCx8EqOLKITbD1Hks5gUOR9V4beugE/SMb Ul4GoGOeSgdb7IkiOApRU1Hm1iRLdnK2VCIfUR4ABlrIDjAyJB3YyShykLFakwQjQ9SBmYwf 7GSc70j8CpuBsWLPMocYUxSZgcV6fRV866818YnRwgLzpi3L0nLcuLtuEyiQnJhosVW4hTx3 wZdo1nP5jt2Pg6PuXQwIU7EUg3PEsfaeV3CkwGKzVUzUP5Fya6YaZHg2GQZbeIpajDQilhRZ eMbNzju+qJMluvLe3qSklJvxqiaVNjcqGQyKWVD5/FNJ3ms9WrSnwfP/a0Gh9NGozXxF9GWE lBXvbZHVt6K84lqLvX76SeMm3U0DmnHvqfaRxpgJtvFq/VetwJ7jrWXhRxlr6UM8xLT2OCV8 2tbTVxbvyfxwb+a2c1dRFzMhNiAfuNifmdaP9p0Xrrfp9GVoljS5JEs+LqTIp8Cv0BRpwp4i 5966s7/bDM/uoEuGFQxsA31EdZWOxpAiTQ2WIh17AazYrM7BSyrK7AWs2PJyROmtzESLbp26 d+tXAPW+th1sbiUqQaZBZXYDMmcuj1GP69oTgEUb1HMQPmGNRpw+iYvMSb42I7HSVibWsSdN VoFzfk26orTQqKdUK1NTD88vPnSwU7St4mC/Z4a1zFGD9IXycUGWikz1yGvRu89F7Twr/IlJ zEBdrM55zX6x+bvPQfOaGXte2zIoUMprEWALNK+ZG0leM+PPa6uFvEbWrBhLNHuh3Jqx57Wp ccKKMUTKa6tqrdTkIliDGWtR1PhJhO1Ke+KNfq8Ofhz87xH5OWSyrGZ2TVZb2zO5GVg0Xx2I EmE0Yj0HdFbhoeunxQcvp6bGgud+JGFHX0o68Ga0hPSIMpvNopukajqGBUaC9IMmIHM9sllV 9hH+RO86i7pYnbOZ/WLCH1g2MxuwZ7Nt1dlsA9gKy2aiAuzZLG9/twIPMZsFgReOktBdXEkH KpspYgn/H1duLk4SZmkArM6Ql/AdwJoNrkhl86pT2d+1RLAyEUIqwxm9pmY9/KLu+Uj7Gb8a aQ+QGarZjrAH5qWqlM0CklL3ATB/idoTZQ+82SyIDy7LjxdPdhQfZ//cAnIEyhiYs5lkjHFP +jYBMe+r58OyjySi/qlsNzSViRdTLpU5u1fHNamMxp/KcvIWSqlsj5jKBtTqZjbKdfAGxLa1 ItXrrZ9s2F10gSQ6Xwha3wwsc9eMgQKLfaMYmc0ouTGQ2ewBxtRdR6qeFv+Q3UehLkYhnh3y wMUsu6pXEuuOX0JdDJVX0PRHwmcF4sVoxFGmD1xs/V95VRcTJCIvpliQ00oGOYs7yFds8h8v Bnknb7ANGuQs7iCPm1N+IPf7As/qIGfkQe7YvxR18AaEJZTZvxwatHvuxc7E9Avjf2oBItZq 3oUGOfbuh9SENTui06aKQZ71NiFzCiXHQghyeP8Scz9jcz9eVxXkwp9W9Bgos+y/jnO5gVij AbEpcP+1vjmag/p+qFTxwPeTx9BXR3JQ36/O2WL10YtVF1uYlIESh8oWaHFCtvgz4xrqeiZE H8sD19t9/vpDcwbf4DmDx54zthfcen9OvJQzrGDAennOkMUq9m4Y3aErz4beeUbshjn/lzxW HRVgM4+OVWUqwKnvfmUOL2S1I0BPurWv+csFHn7gkIbIhUYC/68jnZVfCxXpxvuvNW/738tT MlEGQq43lDnC5JwlvyQrUbePGKgNHKh9pG3byeN9wJNLyakoE9U5WXx5OKfKRB/vkx20wNay ESpZKFefUmlXrvKI+TSm5d0yW1aixZYdAE5MbdIGlh04Y0NnB1EB3uxgTY8oLCzbqGsDxk8P AwOWw7MDh70ta6vu5z9slx4T1v3LlrUC55sSf8AQ4YxOEoQiiKRO+6r35MIw7WYhQbw6cEVv cP6IZikMfVGKUtlBvFads8OC3Wd+OpmL8BI6OyizYxRVmv3fpX4eKeoR5R2A8VvyBZRp6p8V PtqTgXI5/qwQYwTgg51qeBpgsKeBrS9VpYGFYAc0DTAuSQN/SmnAR0gDw+T3NcoAw96AJ1mi 3abNRgJ4/xccgALBuCoHhKraN2sGMmKIj6CUM/8+Acgti3mz19o3tOTEUvFsMmJwNDD+Qgah vpRyocs0eOg6a9Z0TehyDRq6rFwH8tYZZXyxZtOEYz8+q7uk5gePB9aXNQTCHujoVcQeqTNW madms1rDuPETHm2dN3H85PFJzXZH3iu8caIddzo92QMM+8X9GSj83L+O6Frf04iowdD3X+vP jKvzdpxatj8DNueXrkTjbIsJiCi+t3yo327bvbISXyL65tJCW5pfP/Xh3MCJKhAT0NILZaw6 Z4ovDmdXGevDvZkIOhs4U/DYO3eFTDFZyhSbwB+wyOCxt+1aMyOyHZni+RT4ocs8hfsmu5Gz j1XcqnAT5vqfL/QE5xlCNs5Tco/UvXA3b8l39sJda9M41PWoutaO6GGz7dfr0u8dWABI11Mo W4jX+jfZova3NCLuHn/gW8Yfy3lYiZ6n6hHmcanOy4G8k5ZUdDkwctfZPzOtqOvVuRy4K9P6 sHIgj70xdcVmIQk8MmhxUzXQTwDQQ0x47L2pcZtKct6fIz4BZ0+AFTx/slYeYOU6kLdnK3OD yZWA7eEFO9LG7qY+JZ/ap1GtuaAthUJo+icbdUS3kVBoTPXIA6Omx9rzQDtuIkqcYnnApFge MNUjD2w5cwUeGrW/ZZ3zwHfH82ouBt1E5OvTwvnQDFWfFk5EBnBczFkLpzJ3d21Lu1uR70t0 TkpN0YBPtcQeaBLA3sgZF3GpNHdKVb+AkAQuypMAZTTIhfBG+Chsqu/s0wStOH+1ufRkbu8C v0ghM5ZPuVtSnJ62ND7RVlrR/tUv4peujl+9fMmSVWvWrGm6oW37CzmXDP8bKUyiPm8ta2Sn OJlcZKZg74fhEd8Ae3ALr6OWfo+6JIW4RfeBS06bv6YVPcZ+VeqVmVBkzQqmDLNSCw3pSlgX Ghkh14otH9h0A+b72Tx/2VV6Kzd/RpMvV33YCrz7mO5xlCZkY5MimqQ9Ad3KVR65d/mF28/M 12m7gGatCRD7ljoa5Tvlcte/b9i0b/uzBgPu25a36n6KLMlOz/KzeG5SBbYdGD1mOjh52w22 0JfUYM5gO21/ZZ6Or8lgU+R3tps5uQ6eQkxj6tuKboQejTEnraI8141gwJNPPgna7iISIdMp UQfm1smtSxOenZX3DLFDbz7VGmQOgu5bSDoUyj3Stf5V7qllHbyNlNZnQguKlmbpLqmpjmHg uXm1jjin5Tpc0kjZy1cDYmKgjZRVIhRKMdLF/mWKkQU19jZG6/nwG1cOztC1Ad2YqWBAE1I2 5+YouQ6eQripvnfTGmF302513xh99zZDfD7/kx+9wVPDNL0cOuz3gIo6kLesKXMP6MnQtMSi m/cKEm3iQ4Biba/lrgf9P3JLh7q6Pi2Inx7MqvLzzgwrLLTpfxnadK0rYd2VDDpjuVaQZdOt I9hRXWdOVQHjSfJ9yGxCkkIjHqSgzGzCys0qELTobJ6DyHcm9AGj+2sDUK6qR4jD7jurfbE6 h/jC5Iyqiy1ITodmYmdNjMqUYs8H5xxJ8xMysdhyQG8jCei4zToJcUXG7RW/D564tiMAvDdI hKwFRQXoW/aVeUDzj6tnX04tHjp2N3VBG9kn4Ef3z0BliNuLD7YISGIoDnG7w/0+/iwl++dT lxFXqXOjweLk9K+PXpClPXOtyyBCWplTizJmFlwvfj3eUn7vSFJKP9248rR9hw4/dejII2BH y6bTZZoouSYadXi5IgcsBMy9Ufj9WIul8l5JfKEf0Wr+wphW4H8r3U3QmHTS+fhATP6RYV16 4MKyg1m7zlsRXjOhTvJ90PcXhD/QyJZaDeEpXZnIzpibXbl79VCPFDLSGgRMP2juQiObxx7Z v1ZH9jwAu91dWM47sYQiQ5L3mxG3xdt2POZ/GLNs2RW/7zh1+ZRJ4yeogT+nvQqziqipIazi iGpKbK4yIiYzykT1vCvJ1093yoq+d6yfaVxg4GdtL6jB+jlNZIeKmxwGEdtuUOlXmXNwI274 ENq798rSRFFRFU3bjZ8w7tL4KcNbZhOADm7GQ/3E4PfTK1PWPnph0hQCPNMfnIGFMiX2wFCI dhFlBunRc6xlBYnibn7n6YBeSXpAfST2V6Dmv4r4KChrXun+/E7iQ5AGDny9lyfIuCI/h8pc Swpmv/wm+uXTZS1V4Jl7KtlJafaTtUURgl9wnqzt/WbU7fwsi26Fih8/BgybRT4O84tR3M1G 3HKukF/OzrtaLPhln6rn5MEgI4QcDnOKqKOhnMLIRCAfa2Ks766eEbarZ80IyTu7aIbuJABj ftTIn3PtEGFy4hFFthZT3wxZHMMlHTykBcPfUZVA3WHC746XJXe0UYHeg1TNESLQ7lBEhPdb YowkCu54Rxhwp3Ulu0JjRNzqQczQFBpfwq6e+jDCV1i4v7RnJ8hYLz8mzVxLB2anbDkyrsYp OaoWCBGYnSLh+VK/2KXNwCc/qmGPzRCW5q7zyHfuE0CmSt6/bK6lo8E9Qhtc5JHFq58An3yu qoTNM2jxSYuohl9lyrLnovMOHdyos3mmaGJ1YFp/8iwUDRo/GrcOCGh4LibavvQoyNhEvgT1 irPCozJobEsT0fhcQKPPfNWjCBHY0Yj+tBqNJeWqcthUhxYfLYhqE1NkqhO3NT8n83SBjTYY h4HbkweAzwK0ZigcbCOBA3/Jqg5wsI0BDh43HN4B4TcL/LTuqp7NaNDsOHEJCgbfSMDAX/HY ljZJAkML+hxBgOHk6X64wbBPg03i0/Q4nHPxgNl5p7LT0zw2qMCYlppTMCxEEfixKJTmGXki Fq+RL8I8YsJe8hm5yY7Fs56q1ggRuLF4K3q+gMXK1QRYElgLC4cIxgkWioiIm3n58P5uMwQs vD9/WhV0l4Q9R0PSgZuMHDkZXcmBKHtgJiM4xU5GoKoNQgR2MsIkMhYJZLRHkMFhJyPq8q31 3WZ4blDF5u4HQX/LGwNMtXS4ioyvcvqD9AtkN5Q9Gp4MrhGQwVAuIsOjmoxYsg+MDIZyDRlp wiRjTx8rSB+hKUXZAzMZs1ImSKtWNXi2HE4G46zWphAZv8dXkxGbpiqDijA1EjJMuMnImFd4 /pOfWghkxOp0IP11zd8oe+AmI1Uio6Ua9H0RQQb2sl9dyDC7hIyDVWTsA0H9yGegZJhx1+e9 x86+nF6QqNunGj99CDhbgcgZ2GuPdSEDf+3xrT/iq2egsfNV92AiWIMryNgvkeF/aR94966c DEcbg6gDuaOmSBuD95s1ZHT2CXs+nAJXYsk3USbBDEeoCMewFa3cQN9fVU8iROCG4w0HHEYV tGOBpV0Dx0ZPCQ7Vu5sQcNDovgVl4BDLsYXpS22ensKYEtkhATz2IWmFLeRZZ4VQRRby3ldG b51+erD2I1Xv9j1B64PERYRr8POxtJqPj/Pg+2osi5+Pm3Y+9qvenYzgw0nvnjJ8JLwVcbui JF43gHh6eDS4PJJsCyv/sVIhFNFnqcwDpl9+e3fZZZIg5y9f04tNegQ0nac5gXANdj422/lY pboDFcE3Ej6cHDanUI9c+K287PShnou1qf46cPmUfELq6L9ieSf3ZCjSf5U67auIS6m/bcyK rqiwLY1pk3TscI8eqS2Az2T39ggPNTwmZmfFUaUw+UuGiSfJw2anZiP60XLKzE4FY3wZ0waA kVtVabD+frNYlEQ8W0mZ/v6AqNK85NVDPTZoFoRzIHy4Bu4R/HXJ8Jt/rbd75J0UkoN6xMmT IBXyyJhqjyxQHYN6hMHtEWt6eN6Na0t1I9WheyLB3AUktHvEjL8eGH6hxiNt9qneiUJ4xMnj F5XyyM4qj7ymOgr1CIfbIwkBEXdPbBsreKTt4UfBXIrsB/MIh78OVyePiDoa1iOcWPxC3V6i TNaKvnXg+OqhlbTROIzYRNME2DuRPAf1Cv4aWJVXPCSvgHdokoV6xeQCryySvNJNlSrzikmm QPAKYqVS33u0jLB7tOIiLt9auGhjJVU+Za123KRxwce/cAOdo9ygq2oOfwmqbo4xN7hjxOIT j7gZRRnHhF/Y83O7gujyyoPzHzMYjYbygz4LX+MJopNbe/D1ribQRnwefyVIdNCLVQ7aD6Ze gzuIN+B30FbJQa/eVR2B3e0pKuAZRPeXQnd7RpcmC2P+JNXAD2xx1qDQLpHghShtZ6hf8Bdh 7H4ZuY8EU7+RL25NtXQ0hF9ovpYCDvHQ+Pr6hYKeofdj/G+2u38n2mzUBRAbG9sxTAusiW7L YYs5UQ3P4Ly/03v0HzbxTOpJqrDArkDfQ3MaVpHinTWkKVKRSn1ja36nvRbtRyqabg1a3SGO wxbZPPYiTNC5Wdb9izbq1gGQ94nmEKzdXBKBuF1QmXbzkXOOlNlsfkQIAGv7ErI5iKN7VBTB m3CeIJURmX3szsslnimkuGYwdJaffSnLHM660RTJHNaz0aXnr7XQnQQ/5rwH3v5Dnjkcd4vz Tm7AU+iJwaHZNz55ucQmzET0j9/8dYsKjJylvQSlVNSCuFdcoVLh5Tc2R5/20n77XP9PCbBz hCYNygiPmxHr+bCcytVpukvqiNmewHc7+TKEEbPB6KTTWRFGgjJnWa+UbdStIAZqmZDnwNsv kO0gnpGU4C3yp47dnF8i3i8PQO55TQpSBFY8/DeuCr9w8jXttzGJW7zAn6GadZDBRdKBxEOR wSUoPTLn0J8iHqDTRbkx7BNVs0GsAvGIg5EUmagGWPJOff1ui0rblLUtDUbDpl8NL7sHH3Ev VIEundxkHWL2owwkTZwB55MgAqKullaY48dEld65nj9D+62qW88tu77rAAafazYGigyDHZmf vo6+eXt2DTKBCGQY1yAzVELmB81B2RRNLoI1sIgpWn1FUDAR1nNhOdfzC3Q2T08DcGu/ZXcc B375VCt7NhnvgEVsXjPBkxtdX1hoGCxxm67dzvyyk62y7GC/p/UpRzs/mdLzWFpzEHesySgo LJwrYLkswRIvwrIcAQvXYLDYD5oQRbAG1MFdihw0Efd7Scbf3WbY6PIpSUSlrV1OrgY00zW5 Dtm8M1NOTkJWZvMuNWD7xzETkpL3qEFUsuoUjA9RBG4+VoVfvs2IfCwX+CjRrIfxIerAz0dh NR/TNAcgk3lRBJoPZe4dDdi6Ottm0XaZ/9FKAOKnalpC6gFmysnxuAqd3f7WzrK0RJuuDQjs 2hX0jtYchcJhaiRwmBoDHCb8cAjhyiUdOqwGr1xSnYGS4eTYVKXOLg+7deynFgIZjwlz5z4B ZEsoGWZXkHFXImOjQMbOpxBkmF1ARnlhukRGx2LNPigZZvxkbFoukHEgVQNeiZbv5DosYXRy KKVCW/2iCDUA07xV+2BMiApcwESqxIQw1dj5muZ7lCUwMxFgubT/4EaJieNwJoyGxsAE7RIm AiQR0wbKRciwoBsJFjRuLBLGRtz9O3+GhMUeBBZ0Y8CCxY2Fd8DmkrKCLN0k1fCOPqBje40V SgaLvTRmfeP3kDSxNBaw9lmwK07zF8oeuMmYeTc3vyphPKJJhpLBYidjZeL7AhnHBDL8K+Qb 6zJL8K4jw0s1BnRk5CeXyYzB466qnyzuUVpi6yRW1b8dReShjNHwWPCNAAva6DoswltFg45D 5EdVOowh6sCLhe7o9R1h+U2JVv1eGe4O1r2qeRFlD8wzjNFz7tbMMNrByaCNLiLjwB6dSMYx qCUYF5CRLyOjFamG7NRKOjDv1E6Li8g99V8/WyV1AXj7+39w7iNw+wu3r1BWwczH2bm3q4td T9zVJEH5YFzAx5qYQUkpTYD/dtUeqCE4l+CxUcJjfDR44iQJIJtfkg68m19xc27m/PBnmkcK eWPeR6DXDfI1qE+cFSAV8sm2NTFvA+D/oSoR5hET1aAeqaWDZxBNJsosTd7YdC0tUWxmGKzq CJ5YqbkNaTIRdaA9okyTieSRtT06a8CIOepHoMYwNY4wEXUgnaJImAQEX875oXeatG9OGIxz L/dQgXVubq/DlgcmqeCGc382IOJq6Y2eLTwWaxNSU0HuMc1hqHfM2L0zenNZjXf6gide11RA vWN20v+jjHdCyq/+mj40uqKyKH7ZspgBSXtSJn3v5QbaZTcdLPOQWaYI7SFFDrJNHbPpYlqi RbcOBHYd+CwfAlSU/JBB+zNZzIzYTMgjpCjyTBb/+D+XqHxb5mRrQJ8k1UUYKQz2Gpz36J01 pLQSSGkvJ4XiGbkQnoVbg63vOMPCxpm4XbbyRIvNc1PMjMTKyHuFRbmLfBN/9bqQO+71Lx/N CZz4XGtb2dLswj+HtsiK3Hdyz76klJQFhqs2vwMW3ZmfAyeNuzB+yuQJgXt6NHNLjfX/NjIA PMl3lB3P59izY2h0T4Aye3bCKuymONdeALr1pMGOpRroGojBXktz5lvHDgAjVpAQz4dT6HE/ 2y+ePJo/o7JyopCiK21ph45916VzE3Agr2lHSDtglSAeIUiRdsCAyLt/5R7c6GexFS/N9iPI fkNWdgLrv2paDhvQGRbdX6TQWRBz7+T93myOx2JCe+tRcPoI2QXKC/YiW8JbW2x/H5whPmg8 vCl44j25DnsvnKgDea+EMr1wAXPv5vz65lCPQaqXJrwHihaQGthut6SDR0zBFdntzgjOy7vz 8RyP7iDWZovw+FEFRpxwewPKCI+fkby8UxIjpe4CI9NJPay3iHFWblPmQXDBAqtFczwGufn7 60CLIZpdCHsg73BS6JSM0duL0gv8dAMIcDJXA3uAuySCMuB8YLn3G7/nn9gWr2sDWvX1Adz3 mlyYMVgnDYr44XBMrkQdZhZR7FJkcmU9F1l+7Mgc3VNqerIXUD1NeiPsgRmOhLdm3hSmDyIc f78Ah0MUgRcOa1Z0TumJbQIcQ9hAwLfTHIEag3ENHNs8q+F4nuwEWxuJOsyotjdlDqhIDys/ ULRNZ/NcrBFvMW+xj4TmDtbJ/arKWMSaNS+ntMgs4TFfsx2KB4Mbj7iICxmHeqcJg0uCdyrg O9ba3nMYg2tIPBzlUFGHmUU4RZFyaICl9EB8os2jiQoktZV3etcyBmYy4v4syDgUkSas38Hf pxFkcLjJCIgoPXBMmnZIZCyBk2GmGpKMWjowOyUg8nJO9ptLPUWnVMKdIorA7JQ5pQc+cTjl U4RTTC5xSpHkFHGt8Bj5BEKHK5yyusopf2m2QZ1iwu+Uq3Kn+Gv2Qo1hdoFTDjiccipf/riI Wjpc4xQpfX2v+R3qFLMLnFIqc0pTzR6YMTgDdqcE1zhFXFWf+gPuFM6A3SlzL+csq3bKLM1v MKeIIvA75Y7dKdzBWjvADmM4eWiES51CNwan0A3qFHudg2Nx1ytTv9qWWxJv0Q0AYNv7mi1Q j7DYPTIz59yxl+dIHhkrFyHzCOsCj1y902yOp+gRf8D5aXZDPcLj9khA2O1blT+VeDZRPftG CNhxiXwMtvnLOTn6SqHN31XbivPjE8VnuGm1YP8GzVaoX7AXWpz5xXHrFm90smVT3wop9Nat uN+LTpZkJXoGg1Fd24KVHcjWML/wTg7mV8YvAdHWW8nXWlRWVqTNb2eotG18qrMO9L/V1AZz D4+91OHUPfYdNd7Jow+V2VELypp7uWhplq2yfHISsK1auf3sG1vX7wPq15q+AjUM9kW+M8PI dOBfUjrTUeMgziCtonDuB/uv+e3DGHXS0QPuYHqA6hBUhAm7iNW7rtgs2s0xW/UtwLWNxDXI bgtnMDuRochui/XM3Es3jszRTVJ17ToQtG9Ra2VbU9HnKGlqiLi7XZGKvvdbO6/tLemkW/ee zfbbpH2gbS832flt9n0fjhLnQxRi1FNk3ydoTMTN438O1dlsdEu30StX6S49DYZscqs+XXi4 u0E/xT3EnfOhxf8EbYIo2euJ0/T9R7r7jjDrTSYfgaKRgcIvUPpelKieogw+jFFvNAke5Sn9 yGnub3Z/xauXwcfMmVma7f6c+Joxm8yssfvz4muDmaK47novRvg1A0V17y97w2Qvgw9lolie 6f624+V4x8swr16UD80aTd2niq9MNM1w3WdU/bvByHcP9bJfS+9l9BESEU11D+ju+KnR8d4A Ly/hG7418iXpq4kP+WXFr9aLYmgf8UZ3VvLIyEnCF3pe+C1h+k7zZuHDRAVmM0V3n171kjXz 3Wd69RI+jTYKwiY7fhrieDnb8VL2BtkVJlZdgWLM8jfIrqv3MvmYzayB6x4oWozleOHdNXLE 94aKPxa+EWNkhDf3Yn0oxshxgjOMPjTPmY2CK+z/LvtCsrdOqLoYY2LlGt52vBzveBnmVSNs qqjRYKI5Ux3UvAN9s+wS0x/20ymOl1UmoU1G+b/LLjsJavRnvIxmrsrtnMPtNCUYRD/S3727 yqtbbSIogQchDCQSXnI4RAn9QvAYTQa27voF7GTWrIaGFqAZD6VKX4WK5GiZCebanTdL9ga5 y8Y/QOb975bJqGJBVCH7yjJ0ZT+d4LhukOOnk+/3qYh5MNQmcpFyOXAKa5viH4RE4MPtM81+ teqvYaKM3b29RMIYYe5hR0e4qpDkWcpsQoAps1gwlKJZcG8+kBmkN4yHXgJu9EleDMOKgnuZ eCHzi1OGqnAQdcNzm4yK2XDvIISHezkymuOnwfBrzHjgA2UJUhg45eLgwKEiz/HRwvBQPQ68 MFIaC8XBLbRuA6I9RzgGRCPNCD6nhVUKzVSPh/Kv/zbULbXyvOPNU6BvdqRe1EgBpUDmsYlQ l8Jt6aBL/jVmwG35giOeZIaHjyAPDn736ZkE/4z+js+YDL3wRGiORmRFOCqBtb5qdXBU4/Ev yTDTBh+eksgQpyAj36m6LiX9fp2wE2ausKuzZh8TJyzfaB9z9eV7iVe/fyhj7QlpkBfMClOg fpsMj0+5JWWpReaMcBisiMkBnBME2XWgEZEOJ0IThUw+InONd0yPHpqJ6xnyzsc82VurrstT wixacK/DinXOn3WKeVT+FKPAZBYYMskGNfv3fEDmA/YJrhVKIe5G2igEBCu2VRmFVQwlHjAV Oln/un56HeOMg0YCz/tQrJ43ClgZWCkSVPY4q/5YXs9J52aKHyusxWiGrd8HwwO86oOl1W1N 7h/iBTPEQ+NtAhQEVOg5nz4Kw6RsxJT/noyJh88fET51TH8ehFcMFcSsCTFTkEVhrYlCzcyp HiPiP1h18ILeOq46xGitz6pDpma57KvLpoxzq6eMEkPV4fUwO983Ia+xEiISx8N/UTZ/k/3i CplK71ofU718coSTyczrGUNVFBuNjLTxZ5DiqYcQUJSeqppQGY2Ot5kYg/1t7oE96jGwUg/W IBgTJ6YkzmAP+De7s0LcmYT/WKr7SC9auBRjkPKasOAS/hNWzq9WTSNoweXPCx41MJTRLAyJ Na/6SRjwgsW7D/bqVfPTqvmNkRPsM1J4K8VSnLn7QPsr3vGh1P2pTjRSTapjaFmmw5blxE+s yXLi8+5kSe7/Etz/Jbj/S3B1TXD/KFZoI+PD3Bcr1frE4mHgw8FDBcM/X+VDXAyhQVD34BJK jCyHh+qywK6hoc5TUwNP/fOpKeSrKbywr3aoycg5Kt2IaT7CibIfy9KfIw14w2GX+TgI6mOZ KedA13QPL4LIQuShZe2Hl34evoiX/RgRtOPlv1gdkb1oYXUrjP69jKyPqSqB/JMC3X2A1mEl OQHqW8jgYTbTdR077jfavxg7zD4GjuIga1wxpOALP0SORXnOXjKnKFnNXAgFg72cgPLEDLk5 zD4cSxvlov9xcQxeLoVzKruaXKbsxxPlH1JTloePdGHQ69Yys0IVI5qRfsaK00YMJSOak5by /38uGdUhdmWcwLOj/BoyL74tv1zNmAIvKPpWB7+BNcrfEYgYtBH661EngsywxF+be7/lxPle neZV1cGo9LxKX10yYmVTPsj0RZwd/tOqXLiXsJSszk0yynuZOF7axrXvZPy/yDZ8L3lmfQZo 1AroQRqNDIXKxQ/jFR42qPGsxgAP8mWqPUVETC4C4YZDeeqhu7eIfcbxVXCzgjBjDUSyr+T4 9k5XZ2I3xHRYqoFOW+CTYhlgU6CQzqwJkvrOhOEDh8lk/n991IDntn8UN/XJ4mJB4YEsXufV 8b/J4uJQgczi/zi2ZG+ZDf94GQa1gkOKLY6STTCnOwYL+EoTS8T0qhYh3xKXLQfg+0rv/sP9 UwztMf+gjiPfGocuRKZDL/LgZFhcfiCoe/jWtTw64CH4oAwRYlcva+WR4ugpqy4e/X+3e/8T ZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjE1NjQ2CmVuZG9iago0IDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQyAvVGV4dF0KL0ZvbnQgMTIgMCBSCj4+ Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tp ZHMgWwo0IDAgUgpdIC9Db3VudCAxCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFs b2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0YSAxNSAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8 L1IxMAoxMCAwIFIvUjExCjExIDAgUi9SNwo3IDAgUi9SOAo4IDAgUj4+CmVuZG9iagoxMCAw IG9iago8PC9CYXNlRm9udC9TeW1ib2wvVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxPj4KZW5k b2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1PYmxpcXVlL1R5cGUvRm9udAov U3VidHlwZS9UeXBlMT4+CmVuZG9iago3IDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS9U eXBlL0ZvbnQKL0VuY29kaW5nIDE0IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjE0IDAg b2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjE0Ny9xdW90ZWRibGxlZnQvcXVv dGVkYmxyaWdodF0+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9JQUdSSEIrV2luZ2Rp bmdzL0ZvbnREZXNjcmlwdG9yIDkgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENo YXIgMS9XaWR0aHNbIDQ1OF0KL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKOSAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0lBR1JIQitXaW5nZGluZ3MvRm9udEJC b3hbNjIgMCA0MzcgNzIyXS9GbGFncyA0Ci9Bc2NlbnQgNzIyCi9DYXBIZWlnaHQgNzIyCi9E ZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY1Ci9NaXNzaW5nV2lkdGggNTAwCi9G b250RmlsZTIgMTMgMCBSPj4KZW5kb2JqCjEzIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29k ZQovTGVuZ3RoMSA1MjI4L0xlbmd0aCAyNTQxPj5zdHJlYW0KeJztV31wVNUVP/fe97WbDdls lpBmVd7yTESSJQTEhA/DkuyuSXasCQmyi1p284GJBInAZIhSZi1QcROcbaHOaFWCigYk+pag BoZ2EAUzYzvWGe1Iodp24mitcXQq0ukMpOe+m6TEtk5n+k+d8Z393d+955x37j33Y997QAAg ExLAoO7WhpL5YF3Zh7G4rXl9vFO0nY0AZGlz12b9hZKDB1FxHkBevLbzrvWvf7nEBFDyAKQ1 d3V0rxX+05xYbG1rjbecJW98DOC+Ads3tqHClWN/GMC+BdvXtq3fvEX4uyQA6uzY0Bwfv78X +zuzPr6lk92mzEH/x1Gp3xNf3zo+vhQWns4NmzaLttvN7Z0bWztvfeO6Neh/AoA1wv/b9fZ/ tJSiNJMIfYCuxtrPoQnLxxAtiEdhL+ylg8IHFiBMrNXCR/IwzIeNln4BbMUyAH8j/fBjS7MU mtDehN6nkSvQ1oxMrBh7Sa/FP4QdGPsLOkhP0VOWdRnGreUeQuigPIx6Hm87vADvk5Pocz/s QdsxeJvfhZH3wgBcJLNResiHZJTWoZbw/jHOOvTei+P9JZyFvxI3qSBJcgJ9XPQBayyitwT6 nEZ524rC5RbSQTaQjeQhjDlCGV2IUTfQXbSPmvQUi0oV8rDiUsrUDoxCgOLuzcYMebTvQwP2 3AT3TkYV8htCST1pJG3kEdKHYzhNRlG+pD66DGedy89YTHJIH8vr5KdQhpWV6hOagrFlUCAf dCiAGzCrIPZRj2NugbvhPkvuR9mKc/kj2Ad9sB8OQhqOw6u8TzgH78NFnJ0sFJ5XGVlEVqFE UTaSbWQHzkfPFbKbPE4GyXEc35vkXToTsxbSgdmLUW6nj9Gj9E36K/oBHaGf0C8YMBtbw5rY JnaAHWJvsbekaqlP2i+dl87LRDatmXIpbuVOpQelV7Wp69Qd6k/UJ9SX7XNhBuZVjHnVwirM qhsz2Qq7IGmtWhrlKLyEMgyf8DxQxsYz4bKIBEiIrESJktUkRtaTTWTLZEbPkGdJPzmKubyL 8h45R/5I/kI+s+QiVWguLZrMr4420FV0HX2EPkofp8/jjhykJ+h79H3McYRewBwzmItNZ9ew IAuhNLLb2Ra2nQ2wU+wcG8V1c0g3SRXSSulOzP2MNCJ9jCtJZSYXyAvlxSht8j3yNrlHfhJ3 9Kg8qjisWXEpOcoS5UFlnzKonFUuqdPVXHUWyly1VG1QO9Qu9ZA6on6kHbYtt7XbNtqL4RDM g1e+dnpfwt39Gr1TKYF8cg53w70sC710fvaoQ+2wtdNBPjq1gczGlfo9XGQ2CEtnYBW7HTrk Jpahfgr9ZJP0AHmeheAwHFC7yAkWY6PsgFygLBHzSR9jh9RuNaZ+hCP9ku2R29S5ZLncQ/rp MjzRG0k9fEUuwA+w5810DpyBh2AX6QIN9mqHSSaetdN0JumRn2JHpD4WlLeR63EFPfIw2wkL YTo4YDbMwr0ugxsB/rLyshsWzC+dVzLXV1w05/rZ1xUWXGvM8uozr7n6Kk/+9/Jm5E5357iy nVnTMh0ZdpumKrLEKIHioBGK6WZhzJQKjepqH28bcVTEr1DETB1Voak+ph6z3PSpnn70XPs1 T7/w9E96Eqe+FJb6ivWgoZu/Dhj6EFldH8H67oAR1c1Rq36LVZcKrUYmNrxevEMP5rUFdJPE 9KAZ6mpLBmMBjJfOsFcZVa12XzGk7RlYzcCaGTI60yRUQawKDQUXpylomTgqs9YIBM0aI8CH YLKCYLzFrKuPBAMerzfqKzZJVbPRZIJRaWYVWS5QZXVjKlWmanWjt/N0oEdPF59M9g45oSlW 5GgxWuJ3REwWj/I+sovMm42AefN9I3m+4iHybGPEtFUNEWiMHIPasUS6JhEIRHlvrqrIg5b7 DHSfcd+IhyWDee06byaTD+pmX33kSquXl9EoBvUVh1dEvDhqI9ir8zRWRKwMMCjJK8FBch1P UyTcagS5Jna3btqMSqMteXcMFys/acKKbu+R/Fr/sbE/QG1QTzZGDK+5zGNE44Gr0m5Iruge rPHrNVMtvuK0M1vMdHpa1njFkXllpXXSZtUsd17DUU9MNeEjMmpwi5h6s44jiRgmLSjnRWs5 JJvL0Q2vKMEZbcf5iyWdi/lCyAVOQ09eANwIxuinUzXxcY1S4LwAvMq3y+SWQ/tE3SwqMufM 4TtFrcKlxZFVWO2FvuIuM2x0OnUzjFMGdRG8Kbq4BKfc6+Wr3DPkhyZsmIn6iGjr0OQ5Av6S oqhJY9xycsIyfSW3JCYsk7fHDNzOR4G/0E03tcLJX5YzNyfYttgkud9gbhV2PD5BPS3JBcm6 SGE82eMpjCV7o7g0ITyKyWTI0EPJWDI+NJZoMnSnkUyHw8nOYGwipaGxkz0e098bbSM4qeYC MRtmTlWEeWhU1KiHRX3Ax6GWXq4DyMB3vbG37B9YI7vy2mFp/kQcUAK7YRo+iZ1YW4S3fjo2 xp/7fgeEQujiytb81foQvfFI9Xyk7RaRw4KeF3RQUL+g5wQ9LWi/oH2CagRVC7pZUKUgv6AK QUsFLRKkCJIEMUHEfyvyecQ5xO8Qv0W8hngZ8RLiRcQA4jCiH/EcYh/iScQTiF7EdkQzYo0V 80URekDQIUHPCjog6BlBTwoKCFou6CZB5YJUQbIgKgj8fuSziHcRw4g3EGcQpxGvII4iBhEv IPoQP0V0I1qq57ttbltZaoh0+WvU1H41tUdN7VZTG9RUh5paq6Za1dQdamq1moqqqYh6rTZL 07VrtKu0fC1Py9XcmktzatM0h2bXNE3RJI1q+Agzc1iYhhsqSdg82QzhJt38qsEYIvb61aZs VBLTFYZwY2WeWV5k0l3WP+IQGUsT8vBOD/8zPAaEjO3c7RnnaBRyi/71ypvSCtd1n4CZpAxU LBcMqjNfV7m2AbUpS5vi2pSlzSNH6mB+ON4Tuxr+TeB/XuQbrVM8g+083bpIWoPKaNUdggdp hh3ziXm80cpcZ2eFldwSb942z3EJ8NU/A/8THPiQyURwk2+5bzk34ecVN03jz59xU962JV7P cdI/bnKiOhunEk9ZAr+dEvjWzzBJw5+lvkOkd8jT+IE3BvIYO0Y+BCi5POochWWfYVk6b0G2 N7vAm+1NMLiUoHAZ5OG/lyekYX7GB8gJeklyYCz3L4DQMjytjDRjgFH8lc7LwVsHaB061V0y +Zkv/E5QKr7Vwi86/m/uxpXHi+QjFKxs/x+/oL/tl4Tv2LyU+Px8TvA5Nl5iG0+iNT8EXDh/ FGsK2ABWtd9zVwtik/XMJCl8O9f+y96+5vc5fD42RUEmBgWJ7/AdONhBGBBn9hsuvm/wGzFt vnh8TdbSC5pHbLQDA3suc3618s9tAJfr7B+opdh0TOyzfwCNOhXlCmVuZHN0cmVhbQplbmRv YmoKMTUgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwvTGVuZ3RoIDE2NTI+ PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHht bG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywg ZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5j b20vaVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmVlMzYwMDJm LTdjYTItMTFlNC0wMDAwLTViMjAyOWYyNWNlMycgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRv YmUuY29tL3BkZi8xLjMvJz48cGRmOlByb2R1Y2VyPkdQTCBHaG9zdHNjcmlwdCA5LjEwPC9w ZGY6UHJvZHVjZXI+CjxwZGY6S2V5d29yZHM+KCk8L3BkZjpLZXl3b3Jkcz4KPC9yZGY6RGVz Y3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmVlMzYwMDJmLTdj YTItMTFlNC0wMDAwLTViMjAyOWYyNWNlMycgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUu Y29tL3hhcC8xLjAvJz48eG1wOk1vZGlmeURhdGU+MjAxNC0xMi0wMlQxMjoxOTozNS0wNTow MDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6Q3JlYXRlRGF0ZT4yMDE0LTEyLTAyVDEyOjE5OjM1 LTA1OjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5QREZDcmVhdG9yIFZl cnNpb24gMS43LjM8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ZWUzNjAwMmYtN2NhMi0xMWU0LTAwMDAtNWIy MDI5ZjI1Y2UzJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDplZTM2MDAyZi03Y2EyLTExZTQtMDAwMC01YjIw MjlmMjVjZTMnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ZWUzNjAwMmYt N2NhMi0xMWU0LTAwMDAtNWIyMDI5ZjI1Y2UzJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0 bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz42VGlTQ0ggU2VjdXJp dHkgLSBleHRyYWN0ZWQgc2xpZGUgU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciBKb2luIFBy b2Nlc3MgKFJlbmUgU3RydWlrLCBEZWNlbWJlciAxLCAyMDE0KTwvcmRmOmxpPjwvcmRmOkFs dD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2VxPjxyZGY6bGk+UmVuZSBTdHJ1aWs8 L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpjcmVhdG9yPjxkYzpkZXNjcmlwdGlvbj48cmRmOlNl cT48cmRmOmxpPigpPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6ZGVzY3JpcHRpb24+PC9yZGY6 RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRzdHJlYW0KZW5k b2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMTApCi9DcmVhdGlv bkRhdGUoRDoyMDE0MTIwMjEyMTkzNS0wNScwMCcpCi9Nb2REYXRlKEQ6MjAxNDEyMDIxMjE5 MzUtMDUnMDAnKQovQXV0aG9yKFwzNzZcMzc3XDAwMFJcMDAwZVwwMDBuXDAwMGVcMDAwIFww MDBTXDAwMHRcMDAwclwwMDB1XDAwMGlcMDAwaykKL0NyZWF0b3IoXDM3NlwzNzdcMDAwUFww MDBEXDAwMEZcMDAwQ1wwMDByXDAwMGVcMDAwYVwwMDB0XDAwMG9cMDAwclwwMDAgXDAwMFZc MDAwZVwwMDByXDAwMHNcMDAwaVwwMDBvXDAwMG5cMDAwIFwwMDAxXDAwMC5cMDAwN1wwMDAu XDAwMDMpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCkKL1RpdGxlKFwzNzZcMzc3XDAwMDZcMDAw VFwwMDBpXDAwMFNcMDAwQ1wwMDBIXDAwMCBcMDAwU1wwMDBlXDAwMGNcMDAwdVwwMDByXDAw MGlcMDAwdFwwMDB5XDAwMCBcMDAwLVwwMDAgXDAwMGVcMDAweFwwMDB0XDAwMHJcMDAwYVww MDBjXDAwMHRcMDAwZVwwMDBkXDAwMCBcMDAwc1wwMDBsXDAwMGlcMDAwZFwwMDBlXDAwMCBc MDAwU1wwMDBlXDAwMGNcMDAwdVwwMDByXDAwMGlcMDAwdFwwMDB5XDAwMCBcMDAwQVwwMDBy XDAwMGNcMDAwaFwwMDBpXDAwMHRcMDAwZVwwMDBjXDAwMHRcMDAwdVwwMDByXDAwMGVcMDAw IFwwMDBmXDAwMG9cMDAwclwwMDAgXDAwMEpcMDAwb1wwMDBpXDAwMG5cMDAwIFwwMDBQXDAw MHJcMDAwb1wwMDBjXDAwMGVcMDAwc1wwMDBzXDAwMCBcMDAwXChcMDAwUlwwMDBlXDAwMG5c MDAwZVwwMDAgXDAwMFNcMDAwdFwwMDByXDAwMHVcMDAwaVwwMDBrXDAwMCxcMDAwIFwwMDBE XDAwMGVcMDAwY1wwMDBlXDAwMG1cMDAwYlwwMDBlXDAwMHJcMDAwIFwwMDAxXDAwMCxcMDAw IFwwMDAyXDAwMDBcMDAwMVwwMDA0XDAwMFwpKT4+ZW5kb2JqCnhyZWYKMCAxNgowMDAwMDAw MDAwIDY1NTM1IGYgCjAwMDAwMTU5NjIgMDAwMDAgbiAKMDAwMDAyMTA2NCAwMDAwMCBuIAow MDAwMDE1OTAzIDAwMDAwIG4gCjAwMDAwMTU3NTIgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAw MCBuIAowMDAwMDE1NzMxIDAwMDAwIG4gCjAwMDAwMTYyMjMgMDAwMDAgbiAKMDAwMDAxNjM4 MyAwMDAwMCBuIAowMDAwMDE2NTE1IDAwMDAwIG4gCjAwMDAwMTYwODggMDAwMDAgbiAKMDAw MDAxNjE1MCAwMDAwMCBuIAowMDAwMDE2MDI3IDAwMDAwIG4gCjAwMDAwMTY3MTEgMDAwMDAg biAKMDAwMDAxNjMwMyAwMDAwMCBuIAowMDAwMDE5MzM1IDAwMDAwIG4gCnRyYWlsZXIKPDwg L1NpemUgMTYgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8MUJBNzY0RTdFNjdFOTcx MTJCRjU4NUI5NzFCMjk2NDU+PDFCQTc2NEU3RTY3RTk3MTEyQkY1ODVCOTcxQjI5NjQ1Pl0K Pj4Kc3RhcnR4cmVmCjIxOTYxCiUlRU9GCg== --------------090006000605020406020302-- From nobody Tue Dec 2 13:39: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 9B7911A1EF8 for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 13:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] 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 k4Cd0ujCHdbl for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 13:39:19 -0800 (PST) Received: from smtpdb10.aruba.it (smtpdb10.aruba.it [62.149.158.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA31A6F21 for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 13:39:18 -0800 (PST) Received: from mail-pd0-f176.google.com ([209.85.192.176]) by smtpcmd04.ad.aruba.it with bizsmtp id NlfE1p00Q3oogoH01lfFAV; Tue, 02 Dec 2014 22:39:16 +0100 Received: by mail-pd0-f176.google.com with SMTP id y10so13941114pdj.7 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 13:39:14 -0800 (PST) X-Received: by 10.68.57.196 with SMTP id k4mr9651005pbq.76.1417556354655; Tue, 02 Dec 2014 13:39:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.79.10 with HTTP; Tue, 2 Dec 2014 13:38:44 -0800 (PST) In-Reply-To: <547DFA50.8000801@gmail.com> References: <547DFA50.8000801@gmail.com> From: Giuseppe Piro Date: Tue, 2 Dec 2014 22:38:44 +0100 Message-ID: To: Rene Struik , 6tisch-security@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/rAUSD7rpN2TI_nw6aPqR6v0NTc4 Cc: Giuseppe Piro Subject: Re: [6tisch-security] Joining node and DeviceDescriptor 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, 02 Dec 2014 21:39:21 -0000 Rene, I've definitively got (and agree) this point. >From my understanding of the standard, in the case the device addressing mode is set to NO_ADDRESS, the Device Descriptor Lookup procedure may return a Device Descriptor associated the macCoordShortAddress, which exists since from the first message sent by the joining node. In this way, the Incoming Frame Security Procedure does not fail (at the step "g") and the exempt flag can be checked (at the step "j"). I'm not sure that this is a good solution... but we can spent few time to understand if this aspect could be useful or not. Regards, Giuseppe On Tue, Dec 2, 2014 at 6:43 PM, Rene Struik wrote: > Hi Giuseppe: > > Thanks for your note (and for good points on the call). > > Correct. The exempt flag is simply a mechanism to ensure that the higher > layer can act on a received MAC data frame received from the joining node > also when the joining node does not have cryptographic keying material yet. > With the first message, while MAC security processing fails, this is > overridden ("pass through filter") by setting the flag via intervention of > the higher layer; once the exempt flag is set, this is automatic. In either > case, once the received frame is at the higher layer, the higher layer can > act on it at that stack level. As said on the call, the higher layer should > only set this flag if it wants to accept entertaining join messages and > should remove the flag once the joining device should have the proper keys > or spent its grace period. > > I did not check the reference to processing steps for now, but essentially > trust this to be correct. Will revisit MAC aspects later on. > > Best regards, Rene > > > > On 12/2/2014 11:19 AM, Giuseppe Piro wrote: > > Rene, > many thanks for the today's discussion. > > I've understood that we could use the EXTEMP flag for mixing > unprotected and protected packets within a secured network. I agree > with this point. > > The problem I've remarked during the call is related to the creation > of the DeviceDescriptor associated to the joining node (that stores > the EXTEMP flag). > > In particular, form the reading of the IEEE 802.15.4 specification, > I've realized that in the Incoming Frame Security Procedure we have > that: > > - the presence of the DeviceDescriptor is done at the step "g". The > Device Descriptor Lookup Procedure may return a failed status in the > case the descriptor is not found. > - the check of the EXTEMP flag is done at the step "j" and it supposes > that the previous function did not return an error > > In the case EXTEMP flag is set to TRUE, the neighbor node can receive > an unprotected packet. I'm fine with this. > > My question was related to the creation of the related > DeviceDescriptor. In the case the joining node sends for the first > time the message, the incoming frame security procedure will fail at > the step "g". > > To solve the problem, the neighbor node may generate a new > DeviceDescriptor (with the EXTEMP flag set to true, for the moment), > thus being able to receive next joining messages from the same device. > > Did I capture well your point ? > > In that case, does the joining procedure waste resources (in terms of > packets, delays, etc..) ? > > What do you think ? > > Thanks and regards, > Giuseppe > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- Giuseppe Piro, PhD Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: peppe@giuseppepiro.com phone: +39 080 5963301 web: giuseppepiro.com From nobody Tue Dec 2 13:57:26 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 5B0341A878E for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKeK4zx9q2-V for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 13:57:21 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1575F1A8794 for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 13:57:09 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id tp5so12518752ieb.12 for <6tisch-security@ietf.org>; Tue, 02 Dec 2014 13:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U0m2ZHLlbw3GVF0hobLow/R/TnCnOzuJwQMGX3rEtwY=; b=yJS7CrqDHNY47JuCE2gkNDh+uvVsL1kVJaVleGm53Tu+R6WIRns7DhMQT6Thh0dqu+ 6LBzWRMYt9AGtNjOyAYqzcG0PXmHdx90dVtvlLnYoXSUiSawb6+vlB1FCcacY4bk03Sf NQXbqLwn04qbl3eZ5kfniEZodB7nncdinZqp9w92q7x1X4f1eP/9bG8uoMtw1y3mMGQ4 SXCkloE8APArYcIm8WZfrTdyZ7howAx5pdrLGIs6en0cUdb4VVgWDOlclI9ScbTBNFAK mVtUPgqILom4bDhg45jA3FnyfX3uQ5mQimS1KUsqEPrW54swQfCvgCDcbllTNoRC55Bg Rg2Q== MIME-Version: 1.0 X-Received: by 10.42.25.144 with SMTP id a16mr4638783icc.66.1417557428139; Tue, 02 Dec 2014 13:57:08 -0800 (PST) Received: by 10.42.246.136 with HTTP; Tue, 2 Dec 2014 13:57:08 -0800 (PST) In-Reply-To: <1758.1417189169@sandelman.ca> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> Date: Tue, 2 Dec 2014 16:57:08 -0500 Message-ID: From: Subir Das To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf303ea582f3fa79050942ce1a Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ypCxIcUXLw6gemv-B2RK4WPeOFg Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 21:57:25 -0000 --20cf303ea582f3fa79050942ce1a Content-Type: text/plain; charset=UTF-8 Sorry for my late reply. Either you or Rene should do a doodle poll on this and then schedule one call. I was also equally confused yesterday with two call notices. -Subir On Fri, Nov 28, 2014 at 10:39 AM, Michael Richardson wrote: > > Subir Das wrote: > > Thanks for arranging the calls. It would be good to accommodate > Asian time > > zone for broader participation. I would suggest choosing a time that > is > > I'm happy to do this at another time; the original choice of 11am Eastern > was > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > From long experience, our choices essentially are at 15:00 UTC or 03:00 > UTC. > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > or > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > I am also happy to alternate. > Shall I put up a doodle poll? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --20cf303ea582f3fa79050942ce1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for my late reply. Either you or Rene should do= a doodle poll on this and then schedule one call. I was also equally confu= sed yesterday with two call notices.

-Subir

On Fri, Nov 2= 8, 2014 at 10:39 AM, Michael Richardson <mcr+ietf@sandelman.ca>= wrote:

Subir Das <subirdas21@gmail.com<= /a>> wrote:
=C2=A0 =C2=A0 > Thanks for arranging the calls. It would be good to acco= mmodate Asian time
=C2=A0 =C2=A0 > zone for broader participation. I would suggest choosing= a time that is

I'm happy to do this at another time; the original choice of 11a= m Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.
>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC= .
=C2=A0 =C2=A0 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing or
=C2=A0 =C2=A0 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
I am also happy to alternate.
Shall I put up a doodle poll?

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




--20cf303ea582f3fa79050942ce1a-- From nobody Tue Dec 2 15:06: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 D63AE1A1A6C for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 15:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3gzia_33ubX for <6tisch-security@ietfa.amsl.com>; Tue, 2 Dec 2014 15:06:54 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D721A1A6B for <6tisch-security@ietf.org>; Tue, 2 Dec 2014 15:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5449; q=dns/txt; s=iport; t=1417561614; x=1418771214; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Y5iXFLEUjJt9LW07sbmJEu3uVvEfoWc60SIR/Ps7Fag=; b=D9x9bqslPNeYinVe5U1RCwrUAg9WnEKU2tAS4G0Zir1P1GVJLNtfjaWn uGVzgLUs1cs0j4UA3G7aQA2Nmksmm8+q/VQpqkIfv/MLAqF8DYFrNcvfe 5x/eN+DzsgLcgQJmSdhXEeyljJXFG4gQbsypfm1DPvEKTuv0V0u3qUSfU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAKZFflStJA2I/2dsb2JhbABbgkMhI4ErBMRtiEUCgRkWAQEBAQF9g3sHAQEBBHkSAQgRAwECAScoERQJCAIEAQ0FhUkHglsDEgHQMQ2FewEBAQEBAQEBAQEBAQEBAQEBAQEBAReNJAGBE4ImEQeESAWQYYkmgX+OXIZFghKBaW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="scan'208,217";a="102079576" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2014 23:06:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB2N6rH0003187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 23:06:53 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 17:06:52 -0600 From: "Nancy Cam-Winget (ncamwing)" To: Subir Das , Michael Richardson Thread-Topic: [6tisch-security] agenda for upcoming 6tisch security calls Thread-Index: AQHQCqSWdjQZp0LMKEudydVDV3H0mJx2bG6AgAAl3ICABrLXAP//jVyA Date: Tue, 2 Dec 2014 23:06:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.84.64] Content-Type: multipart/alternative; boundary="_000_D0A385D8DC969ncamwingciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/dGnU1CwH_EiEmEiE9xOX4pLy5TI Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 23:06:57 -0000 --_000_D0A385D8DC969ncamwingciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I too got confused on the meeting notices. I am on PST and could do a 7amP= ST or late evening to accommodate Asian timezones=85. Thanks, Nancy From: Subir Das > Date: Tuesday, December 2, 2014 at 1:57 PM To: Michael Richardson = > Cc: "6tisch-security@ietf.org" <6tisch-sec= urity@ietf.org> Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls Sorry for my late reply. Either you or Rene should do a doodle poll on this= and then schedule one call. I was also equally confused yesterday with two= call notices. -Subir On Fri, Nov 28, 2014 at 10:39 AM, Michael Richardson > wrote: Subir Das > wrote: > Thanks for arranging the calls. It would be good to accommodate Asian= time > zone for broader participation. I would suggest choosing a time that = is I'm happy to do this at another time; the original choice of 11am Eastern w= as to accomodate Pacific Time Zone People who couldn't meet before 8am. >From long experience, our choices essentially are at 15:00 UTC or 03:00 UT= C. 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing or 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing I am also happy to alternate. Shall I put up a doodle poll? -- Michael Richardson >,= Sandelman Software Works -=3D IPv6 IoT consulting =3D- --_000_D0A385D8DC969ncamwingciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <913F6AFD877AB646891D80C3B5A0E5C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I too got confused on the meeting notices.  I am on PST and could= do a 7amPST or late evening to accommodate Asian timezones=85.

Thanks, Nancy

From: Subir Das <subirdas21@gmail.com>
Date: Tuesday, December 2, 2014 at = 1:57 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>
Subject: Re: [6tisch-security] agen= da for upcoming 6tisch security calls

Sorry for my late reply. Either you or Rene should do a doodle poll on= this and then schedule one call. I was also equally confused yesterday wit= h two call notices.

-Subir

On Fri, Nov 28, 2014 at 10:39 AM, Michael Richar= dson <mcr+= ietf@sandelman.ca> wrote:

Subir Das <subirdas21@gmail.com<= /a>> wrote:
    > Thanks for arranging the calls. It would be good to acco= mmodate Asian time
    > zone for broader participation. I would suggest choosing= a time that is

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

>From long experience, our choices essentially are at 15:00 UTC or 03:00= UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
I am also happy to alternate.
Shall I put up a doodle poll?

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




 --_000_D0A385D8DC969ncamwingciscocom_-- From nobody Thu Dec 4 06:10:26 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 168A61AD3B8 for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 06:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 792QgBf5nqKx for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 06:10:13 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324861AD3B7 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 06:09:56 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r2so18751584igi.0 for <6tisch-security@ietf.org>; Thu, 04 Dec 2014 06:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zPaIiHGpgh3ctH9i2r1O16EZAozYBywOsE0qt11Kdno=; b=GIISjYRDKZNx1LHpDWzFPbOqtbO6KCiErVD+o1v+lWqa4MBr5Vjh8vd9JD4yJURE8i e8eNbifY/zT1J6ES8KzK7LHq0Ut62Qi0rxdfkU2mw2a0GizdUixn9NyonwPEkQqx/aan mA4TGQouEyudOjZdp8vj980Ryqe0oL79C3lSZaFV+3Fo6oR9VN9CTdJ1YNjT9wSqXq4p HyKv0ZRjPx5BEbThwgFNTuqsJ6yeaVkTObd5IUrdbzYQxVYHDYiUWS064X+tyAAwKAj4 3r56St6yuRoDNYznL2bWBhURfx6988l3GGOVXLOpe9AZgwz3RHleQ4q+9DVZKRx8uw/A FlFw== X-Received: by 10.50.142.33 with SMTP id rt1mr62126573igb.12.1417702194916; Thu, 04 Dec 2014 06:09:54 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id c1sm20321652igo.17.2014.12.04.06.09.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 06:09:54 -0800 (PST) Message-ID: <54806B2E.4090408@gmail.com> Date: Thu, 04 Dec 2014 09:09:50 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tero Kivinen , Giuseppe Piro References: <20771.1417540254@sandelman.ca> <21632.19591.491812.845025@fireball.kivinen.iki.fi> In-Reply-To: <21632.19591.491812.845025@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/toh-TFsWG6hZghrJN6Y00lDVqJo Cc: Michael Richardson , 6tisch-security@ietf.org Subject: Re: [6tisch-security] Giuseppe Piro: Joining node and DeviceDescriptor 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, 04 Dec 2014 14:10:22 -0000 Hi Tero: Please note that setting the security level for data frames to zero would have any MAC data frame, irrespective of originating device pass incoming processing and be pushed to the higher layer, whereas with the exempt flag mechanism this is only the case for those data frames that originate from a specifically identified device (in casu, the joining node). Since MAC security processing (with security switched on) impacts the recipient device's state, one cannot do "after the fact" pass/stop filtering at the higher layer without risking entirely messing up security-related tables at the MAC. Thus, your suggestion about "wrongness" may itself be wrong (well: imprudent). Best regards, Rene == Actually doing any of the security level checking on the MAC level is wrong unless the frame is something that is responded by the MAC level too. I.e. if the frame is something that is always passed to the upper layer for processing then there is no point of doing security level checking in the mac. On the other hand if frame is something that is processed on the MAC level and automatically responded from there, then security level processing needs to be done on the MAC level. On 12/4/2014 6:59 AM, Tero Kivinen wrote: > Michael Richardson writes: >> From: Giuseppe Piro >> Sender: "6tisch-security" <6tisch-security-bounces@ietf.org> >> Subject: [6tisch-security] Joining node and DeviceDescriptor >> Date: Tue, 2 Dec 2014 17:19:45 +0100 >> >> Rene, >> many thanks for the today's discussion. >> >> I've understood that we could use the EXTEMP flag for mixing >> unprotected and protected packets within a secured network. I agree >> with this point. > I assume oyu mean Exempt flag. > >> The problem I've remarked during the call is related to the creation >> of the DeviceDescriptor associated to the joining node (that stores >> the EXTEMP flag). > This is not true anymore in the 802.15.4-2015. > > In the revision the Exempt flag is moved to the > DeviceDescriptorSecLevelZero table, which is used for security level > zero packets only. This is because the Frame Counter that is also in > the DeviceDescriptor table needs to be moved to be per key, not per > device, so we needed to separate the per key and per device uses of > the DeviceDescriptor. > >> In particular, form the reading of the IEEE 802.15.4 specification, >> I've realized that in the Incoming Frame Security Procedure we have >> that: >> >> - the presence of the DeviceDescriptor is done at the step "g". The >> Device Descriptor Lookup Procedure may return a failed status in the >> case the descriptor is not found. > Yes, but if the security level is zero, then > DeviceDescriptorSecLevelZero table is looked instead and if entry is > found from there, then that is returned. > >> - the check of the EXTEMP flag is done at the step "j" and it supposes >> that the previous function did not return an error > Yes, and the actual security level checking is done in step i) where > we match that the security level of the incoming packet is at least > the level specfied in the SecurityLevelDescriptor table. That step can > return "conditionally passed" status, which means that security level > was 0, but the security policy mentioned that minimum security level > might be overriden per device basis (i.e. > DeviceOverrideSecurityMinimum is true). Only and only in that case is > the exempt flag checked. > > Btw, I am working on to simplify the security state machines in the > 15.4, and I have already worked on the outbound one, but still need to > work on the inbound state machine. > > If you want to see what I have done for the outboud state machine > check the following document: > > https://mentor.ieee.org/802.15/documents?is_dcn=704&is_group=0mag&is_year=2014 > > I hope to update that next week to include the inboud state machine > too. If you have any comments please send them to me, I would really > like to have someone else to check out them too, in addition to me. > >> In the case EXTEMP flag is set to TRUE, the neighbor node can receive >> an unprotected packet. I'm fine with this. > Only if DeviceOverrideSecurityMinimum is set to true for those frames > where security override is allowed, and the device is listed in the > exemption table. > > If you really want to mix unsecured and secured frames, it is better > to just set the AllowedSecurityLevels or the SecurityMinimum elements > properly, i.e. say that for data frames the allowed security level is > 0 and check the security levels in the MCPS-DATA.indication call (i.e. > allow upper layer to do the work). > > Actually doing any of the security level checking on the MAC level is > wrong unless the frame is something that is responded by the MAC level > too. I.e. if the frame is something that is always passed to the upper > layer for processing then there is no point of doing security level > checking in the mac. On the other hand if frame is something that is > processed on the MAC level and automatically responded from there, > then security level processing needs to be done on the MAC level. > >> My question was related to the creation of the related >> DeviceDescriptor. In the case the joining node sends for the first >> time the message, the incoming frame security procedure will fail at >> the step "g". > Yes. And as the DeviceDescriptor / DeviceDescriptorSecLevelZero table > filling is upper layers problem, it needs to take care of this. The > 802.15.4 does not specify how this is done, and it is outside the > scope of the spec. > > The specification do have MLME-COMM-STATUS.indication call which will > be called when "on receipt of a frame that generates an error in its > security processing, as described in 9.2.3.". > > I.e on the first message the upper layer will be notified that it > received a packet which failed the security processing, and then the > upper layer can fill in the DeviceDescriptor / > DeviceDescriptorSecLevelZero tables as needed and the next packet will > then be properly processed. > >> To solve the problem, the neighbor node may generate a new >> DeviceDescriptor (with the EXTEMP flag set to true, for the moment), >> thus being able to receive next joining messages from the same device. >> >> Did I capture well your point ? >> >> In that case, does the joining procedure waste resources (in terms of >> packets, delays, etc..) ? >> >> What do you think ? > I think it is better to configure the security so that > macSecurityLevelTable the SecurityMinimum is set to zero for those > frame types which we want to receive in clear also. > > We have exactly same problem in the 15.9, as we (joining node) are > setting up the security with node which is already having security set > up (coordinator). We are using either data or multipurpose frames when > sending our packets out (with empty data, and all our data in the > payload IE). Before 15.9 can be used the upper layer needs to > configure the security levels of the SecurityLevelDescriptor > accordingly, so that security level zero packets are allowed to pass > the security level processing. -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Dec 4 08:23: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 6474B1A0276 for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 03:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1LH22cM107Q for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 03:59:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 C81AE1A0248 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 03:59:08 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB4Bx5Kr021240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Dec 2014 13:59:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB4Bx3ux024242; Thu, 4 Dec 2014 13:59:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21632.19591.491812.845025@fireball.kivinen.iki.fi> Date: Thu, 4 Dec 2014 13:59:03 +0200 From: Tero Kivinen To: Giuseppe Piro In-Reply-To: <20771.1417540254@sandelman.ca> References: <20771.1417540254@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 46 min X-Total-Time: 29 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/wWwQtyQCAcp3xiOCy7skJ3HMTso X-Mailman-Approved-At: Thu, 04 Dec 2014 08:23:38 -0800 Cc: Rene Struik , 6tisch-security@ietf.org, Michael Richardson Subject: [6tisch-security] Giuseppe Piro: Joining node and DeviceDescriptor 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, 04 Dec 2014 11:59:11 -0000 Michael Richardson writes: > From: Giuseppe Piro > Sender: "6tisch-security" <6tisch-security-bounces@ietf.org> > Subject: [6tisch-security] Joining node and DeviceDescriptor > Date: Tue, 2 Dec 2014 17:19:45 +0100 > > Rene, > many thanks for the today's discussion. > > I've understood that we could use the EXTEMP flag for mixing > unprotected and protected packets within a secured network. I agree > with this point. I assume oyu mean Exempt flag. > The problem I've remarked during the call is related to the creation > of the DeviceDescriptor associated to the joining node (that stores > the EXTEMP flag). This is not true anymore in the 802.15.4-2015. In the revision the Exempt flag is moved to the DeviceDescriptorSecLevelZero table, which is used for security level zero packets only. This is because the Frame Counter that is also in the DeviceDescriptor table needs to be moved to be per key, not per device, so we needed to separate the per key and per device uses of the DeviceDescriptor. > In particular, form the reading of the IEEE 802.15.4 specification, > I've realized that in the Incoming Frame Security Procedure we have > that: > > - the presence of the DeviceDescriptor is done at the step "g". The > Device Descriptor Lookup Procedure may return a failed status in the > case the descriptor is not found. Yes, but if the security level is zero, then DeviceDescriptorSecLevelZero table is looked instead and if entry is found from there, then that is returned. > - the check of the EXTEMP flag is done at the step "j" and it supposes > that the previous function did not return an error Yes, and the actual security level checking is done in step i) where we match that the security level of the incoming packet is at least the level specfied in the SecurityLevelDescriptor table. That step can return "conditionally passed" status, which means that security level was 0, but the security policy mentioned that minimum security level might be overriden per device basis (i.e. DeviceOverrideSecurityMinimum is true). Only and only in that case is the exempt flag checked. Btw, I am working on to simplify the security state machines in the 15.4, and I have already worked on the outbound one, but still need to work on the inbound state machine. If you want to see what I have done for the outboud state machine check the following document: https://mentor.ieee.org/802.15/documents?is_dcn=704&is_group=0mag&is_year=2014 I hope to update that next week to include the inboud state machine too. If you have any comments please send them to me, I would really like to have someone else to check out them too, in addition to me. > In the case EXTEMP flag is set to TRUE, the neighbor node can receive > an unprotected packet. I'm fine with this. Only if DeviceOverrideSecurityMinimum is set to true for those frames where security override is allowed, and the device is listed in the exemption table. If you really want to mix unsecured and secured frames, it is better to just set the AllowedSecurityLevels or the SecurityMinimum elements properly, i.e. say that for data frames the allowed security level is 0 and check the security levels in the MCPS-DATA.indication call (i.e. allow upper layer to do the work). Actually doing any of the security level checking on the MAC level is wrong unless the frame is something that is responded by the MAC level too. I.e. if the frame is something that is always passed to the upper layer for processing then there is no point of doing security level checking in the mac. On the other hand if frame is something that is processed on the MAC level and automatically responded from there, then security level processing needs to be done on the MAC level. > My question was related to the creation of the related > DeviceDescriptor. In the case the joining node sends for the first > time the message, the incoming frame security procedure will fail at > the step "g". Yes. And as the DeviceDescriptor / DeviceDescriptorSecLevelZero table filling is upper layers problem, it needs to take care of this. The 802.15.4 does not specify how this is done, and it is outside the scope of the spec. The specification do have MLME-COMM-STATUS.indication call which will be called when "on receipt of a frame that generates an error in its security processing, as described in 9.2.3.". I.e on the first message the upper layer will be notified that it received a packet which failed the security processing, and then the upper layer can fill in the DeviceDescriptor / DeviceDescriptorSecLevelZero tables as needed and the next packet will then be properly processed. > To solve the problem, the neighbor node may generate a new > DeviceDescriptor (with the EXTEMP flag set to true, for the moment), > thus being able to receive next joining messages from the same device. > > Did I capture well your point ? > > In that case, does the joining procedure waste resources (in terms of > packets, delays, etc..) ? > > What do you think ? I think it is better to configure the security so that macSecurityLevelTable the SecurityMinimum is set to zero for those frame types which we want to receive in clear also. We have exactly same problem in the 15.9, as we (joining node) are setting up the security with node which is already having security set up (coordinator). We are using either data or multipurpose frames when sending our packets out (with empty data, and all our data in the payload IE). Before 15.9 can be used the upper layer needs to configure the security levels of the SecurityLevelDescriptor accordingly, so that security level zero packets are allowed to pass the security level processing. -- kivinen@iki.fi From nobody Thu Dec 4 13:31:16 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7571A6F51 for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=1.999, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMPdbN-vj5J0 for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:31:10 -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 CD0EA1A6F49 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 13:31:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7ECEC2002A for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 16:34:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BE002637F5; Thu, 4 Dec 2014 16:31:08 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A30F0637F4 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 16:31:08 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/-B5bmhqXyNnfBms3bf--WEPpplg Subject: [6tisch-security] summary of discussions on Tuesday 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, 04 Dec 2014 21:31:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I can not speak to the call at 9am. At 11am, we had Tero Kivinen join: Attending: - Thomas (TW) - Michael (MR) - Kivinen (TK) - Malisa=20 - Rene (joined :30) (RS) - Pascal (joined :50) (PT) Tero composed a summary of his views, which he sent to secdir and to me privately. is it at: https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmS= Vc and I will likely reply to that message into this list. The discussion started from a need to understand if we had one or two beaco= ns coming from the join assistant. I assumed that there would be two, and that one would be secured with the production network key, and the other with the well known beacon key. There was various amount of discussion as whether or not this was even possible to do with available MAC implementations. I took an action to research how much of the MAC implementation is in software in the "main" CPU, and how much is logic in the MAC (whether it's hard logic, or immutable firmware doesn't matter). I hope to post that summary on Monday. Associated with this discussion was some details about the current 802.15.4 receiver state machine, and changes that TK is making= =20 in the -2015 revision. A suggestion was made to have one beacon, just the production beacon. This made a number of us unhappy, as if you can trick someone to use lower ASN, you cause them to send more data with a previous key, and due to the replay issue with stream ciphers, you may be able to guess what sent the previous time. We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate the beacon and pull the correct ASN. Joining nodes won't be able to authentica= te the traffic, but will be able to use the beacon to synchronize to the netwo= rk and find the Aloha slot. We talked about the use of a virtual extended address for sending beacons, as the L2-keys are per-extended (source) address, and since multiple nodes will need to send the beacon (for radio coverage in the mesh), it needs to = be done right.=20=20 We discussed whether or not the join traffic itself should be encrypted with some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't necessary, and the situation from the Zigbee interop were recounted again. TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted. =2D TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and pas= sive channel scan we say: The information from the frame to be unsecured shall be recorded in the PAN descriptor even if the Status from the unsecuring process indicated an error" We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIDSmYCLcPvd0N1lAQLHyQf+KgU/OcwTjL1V5UJIEPy0C7IjtRPS2kQO wSNp4bEDv1zfXDyFtq/gWKgdzpNJajzrXXvu1OTCD9fD0PsbqvIx+KKQPL0gtJYo SbRczhEqLkKc3youPtHscu8paQ4staYhVQF281SvV5ZJ2rpMmPYRQL33ydQoCobb IjnqWE72THLo0vsqneEoZyX1mtQQRbEhSCmM06x6to4uMDEmaakOuNGI/WlT7ERz YDg7XQFB4w/GIr7A2RYdY/MUpmXbGyqopDHSXHD85lVfBONfS4y2btKfwmTx/077 Cy35eT6u+051qvC88iObckdBHfJwrHQDUeWtyDkbWRMnCBIBmjDjXg== =EWSR -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 4 13:32: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 4D02E1A1E0F for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkBeDNg8aoqR for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:32:22 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C113C1A0067 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 13:32:21 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so16946533ier.28 for <6tisch-security@ietf.org>; Thu, 04 Dec 2014 13:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=WfpnCL6gl4MyBr41Z6WaWiJaGXi5Y17C2nmR0TPQgmw=; b=WVmIWMdwsfJ8N7cJqxVGD/WwLwojgVzTjRABOl9QdXjOTzH6pVyaNvo5IG9PTPyab8 Rf5k2P/S+ayS7BFk9kIEYnamny8ob4xdzcbJCAyjt4RTbG6QbwZI4bK0LJFiKfpmXd78 4JP92pFSqlMvk1ggnsa59DkjBHQeEiFqvyEMxoEhFO+pQAzahBF7JSZmtMouX38phupH br0DjFsRX4M1X7Jdx1XmM7tboBTmlcIjGShm4MyfpAK3ktvW2gBj3tDns9liddoKzEqm rymJRb8EO7yQXZuxrHY/j4+52xNxXBDXTMtRoqXHmd2JZZLWdAvqmqPuCGXjzj6XumCM 3BFQ== X-Received: by 10.43.158.197 with SMTP id lv5mr13307149icc.88.1417728740787; Thu, 04 Dec 2014 13:32:20 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id f9sm14993721iod.24.2014.12.04.13.32.20 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 13:32:20 -0800 (PST) Message-ID: <5480D2E0.4070300@gmail.com> Date: Thu, 04 Dec 2014 16:32:16 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary="------------040107090708090905040207" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/LothFdINW-jxLkfOVLoMorDK_H4 Subject: [6tisch-security] scheduling 6tisch security calls through Jan 15th, 2015 - please read and act prior to end of tomorrow - Fri Dec 5, 2014 EST time 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, 04 Dec 2014 21:32:26 -0000 This is a multi-part message in MIME format. --------------040107090708090905040207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: I would like to solicit your feedback on the best times for 6tisch security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, Tue Jan 6th, Wed Jan 14th). Please note that participants are from many different time zones, ranging from PST time, EST time, Paris time, to Japan time. The only times that allow everyone in the time zones above sleep/private time in the 12am-6am time window (wherever they are) are a conf call 9am-10am EST or one at 5-6pm EST. If we cannot agree on a time, we have to use a rotating schedule that inevitably disadvantages some considerably, since putting some people in the "middle of the night" block. My suggested times are below. a) The table below shows how different times impact different participants PST EST Paris Japan #A: 2p 5p 11p 7a #B: 6a 9a 3p 11p #C: 8a 11a 5p 1a b) Suggested schedule (all calls at most one hour): Tue Dec 9th: 9-10am EST {Schedule #B above (Thomas indicated he would be in Europe then, so "West Coast" represented on otherwise "decent" hours)} Tue Dec 16th: 5-6pm EST {Schedule #A above} Tue Jan 6th: 5-6pm EST {Schedule #A above} Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most likely, Yoshi in Atlanta then, so no "night owls" required)} NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where Wed am2 is the mid-week plenary (hence, picking the time in that block) *Please confirm availability at these times via the Doodle link by end of *tomorrow*, Friday December 5, 2014, 11:59pm EST* {The Doodle poll simply mentions the times above, and you can indicate Yes/No/Maybe for each of the dates} Please be mindful of others than yourself, whose biological clock we should also take into account. If you have comments, please do *not* pollute the 6tisch mailing list, but just send a private note, *keeping the same subject title* of the email. If you already ventilated opinions, please send those again, with the *same* subject header as this email. http://doodle.com/2cg4p34x3c3uca55 == email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040107090708090905040207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear colleagues:

I would like to solicit your feedback on the best times for 6tisch security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, Tue Jan 6th, Wed Jan 14th).

Please note that participants are from many different time zones, ranging from PST time, EST time, Paris time, to Japan time.
The only times that allow everyone in the time zones above sleep/private time in the 12am-6am time window (wherever they are) are a conf call 9am-10am EST or one at 5-6pm EST.

If we cannot agree on a time, we have to use a rotating schedule that inevitably disadvantages some considerably, since putting some people in the "middle of the night" block.

My suggested times are below.

a) The table below shows how different times impact different participants
         PST    EST  Paris  Japan
#A:     2p     5p     11p    7a
#B:     6a     9a        3p    11p
#C:     8a   11a        5p     1a 

b) Suggested schedule (all calls at most one hour):
Tue Dec 9th:     9-10am EST {Schedule #B above (Thomas indicated he would be in Europe then, so "West Coast" represented on otherwise "decent" hours)}
Tue Dec 16th:   5-6pm EST   {Schedule #A above}
Tue Jan 6th:      5-6pm EST {Schedule #A above}
Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most likely, Yoshi in Atlanta then, so no "night owls" required)}
NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where Wed am2 is the mid-week plenary (hence, picking the time in that block)

*Please confirm availability at these times via the Doodle link by end of *tomorrow*, Friday December 5, 2014, 11:59pm EST*
{The Doodle poll simply mentions the times above, and you can indicate Yes/No/Maybe for each of the dates}

Please be mindful of others than yourself, whose biological clock we should also take into account.

If you have comments, please do *not* pollute the 6tisch mailing list, but just send a private note, *keeping the same subject title* of the email.
If you already ventilated opinions, please send those again, with the *same* subject header as this email.

http://doodle.com/2cg4p34x3c3uca55

==
email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------040107090708090905040207-- From nobody Thu Dec 4 13:47:39 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEAF1A6F2D for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuLhSHCpiBfM for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 13:47:32 -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 149E51A1B99 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 13:47:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 578852002A for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 16:50:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 9E4D8637F5; Thu, 4 Dec 2014 16:47:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 852C0637F4 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 16:47:30 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: References: <547DF315.4080808@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/UuQ2Kj12Wf6guYrMM9D4eXQlpHc Subject: [6tisch-security] security architecture and terminology updates 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, 04 Dec 2014 21:47:34 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable 1) we have to have some security terminology for the architecture document, I have posted an email to the 6tisch list with proposed text. =20=20=20 2) I propose to remove the following text from the architecture document: section 4: -Security is often handled at layer 2 and Layer 4. Authentication -during the join process can be handled by the Protocol for Carrying -Authentication for Network access (PANA) [RFC5191]. and also: -(tbd PANA) There is a debate whether PANA (layer 3) or IEEE802.1x -(layer 2) should be used in the join process. There is also a debate -whether the node should be able to send any unprotected packet on the -medium. Regardless, the security model must ensure that, prior to a -join process, packets from a untrusted device must be controlled in -volume and in reachability. I would add after a brief description of the 6top/YANG interface used by the the PCE, which seems to be missing from section 4: +Security is performed at layer 2, but configured using the same layer-5 provisioning interface used for provisioning the schedule. =20=20=20 3) I would propose text about the join process as follows.=20=20 This is cut down and slightly edited from what was proposed two weeks ag= o. X.1. Entities involves in the join process The following actors are involved: there is a new joining node. It is (radio) adjacent to the join assistant. The join assistant is part of the production network, and participates in one or more DODAGs, such that it is reachable from the 6LBR, and the JCE. X.2. Join Protocol deliverables The ultimate goal of the join protocol is to provide a new node with locally significant security credentials so that it is able to take part in the network directly. The credentials may vary by deployment. They can be one or both of: 1) a network-wide shared symmetric key (this is the production network key, or MasterKey) 2) a locally significant (one-level only) 802.11AR type LDevID certificate (which allows it to negotiate a pair-wise keys) These two items is delivered by JCE to the joining node using the 6top protocol. That is, the JCE provisions using a secure "northbound" interface. A Join Protocol describes the authentication of this interface. The above credential (2) can be used for authentication to generate per-= peer L2, using a key exchange protocol. The choice of key exchange protocol, and what kind of link and multicast keying needs to be done is also provisioned by the JCE. There are a number of options for doing this, such as: 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] (IMPORTANT, a good option. Uses certificates from common CA) 2) work in 802.15.9 (uses certificates from common CA) 3) Security Framework and Key Management Protocol Requirements for 6TiSCH [I-D.ohba-6tisch-security] (this document provides the phase 0 required, using the network-wide shared key) 4) Layer-2 security aspects for the IEEE 802.15.4e MAC [I-D.piro-6tisch-security-issues]: the MasterKey is used to derive per-peer L2 keys Per-peer L2 keying is critical when doing peer-2-peer schedule negotiation over 15.4 Information Elements. Therefore a network-wide layer-2 key is inappropriate for the self-organizing networks, and a protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. For networks where there is a PCE present, it will do all schedule computation. As a result the only trust relationship necessary is between the individual node and the PCE, and it MAY be acceptable to have a network-wide L2 key derived in ways such as [I-D.piro-6tisch-security-issues] describes in section ?. The trust relationship between the PCE and the joining node flows from the LDevID certificate loaded by the JCE. When the PCE and JCE are co- located, the existing 6top/DTLS security association could be reused. X.3. Join Protocol connection setup The intermediate level goal of the join protocol is to enable a Join Coordination Entity (JCE) to reach out to the new node, and install the credentials detailed above. The JCE must authenticate itself to the joining node so that the joining node will know that it has joined the correct network, and the joining node must authenticate itself to the JCE so that the JCE will know that this node belongs in the network. This two way authentication occurs in the 6top/CoAP/ DTLS session that is established between the JCE and the joining node. [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] explains how to access that information model using CoAP. This information model will include security attributes for the network. The JCE would therefore reach out to the joining node and simply provision appropriate security properties into the joining node, much like the PCE will provision schedules. This 6top-based secure join protocol has defined a push model for security provisioning by the JCE. This has been done for three reasons: 1) 6tisch nodes already have to have a 6top CoAP server for schedule provising 2) this permits the JCE to manage how many nodes are trying to join at the same time, and limit how much bandwidth/energy is used for the join operation, and also for the JCE to prioritize the join order for nodes. 3) making the JCE initiate the DTLS connection significantly simplies the certificate chains that must be exchanged as the most constrained side (the joining node) provides it's credentials first, and lets the less constrained JCE figure out what kind of certificate chain will be required to authenticate the JCE to the joining node. In EAP-TLS/802.1x situations, the TLS channel is created in the opposite direction, and it would have to complete in a tentative way, and then further authorization occur in-band. X.4. End to End considerations for Join Protocol In order for a 6top/DTLS/CoAP connection to occur between the JCE and the joining node, there needs to be end-to-end IPv6 connectivity between those two entities. The joining node will not participate in the route-over RPL mesh, but rather will be seen by the network as being a 6lowpan only leaf-node. X.5. Join node discovery mechanism In order the JCE reach out to provision the Joining Node, it needs to know that the new node is present. The mechanism will use a protocol piggybacked on the 6lowPAN Address Res= olution mechanism described [RFC6775]. The 6LBR will need to inform the JCE about the new node. (This interaction is presently out of scope) Prior to being able to announce itself in a NS, the joining node needs to find the Join Network. This is done by listening to the enhanced beacon which are broadcast in designated slotframes by the network. These are the same enhanced beacons which are used by the production network. The enhanced beacons are transmitted in "MIC- only" (authentication only) mode. Nodes with the production network key can authenticate the beacons. The newly joining node can not authenticate the beacons, but it can read and process them, and can use this as a way to synchronize to the network. During the Alpha period, the joining node can send a Router Soliticiation, and receive an appropriate Router Advertisement giving the Joining Node a prefix and default route to which to send the join traffic (the ND DAD mentioned above). =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIDWb4CLcPvd0N1lAQIHHQgAwcreZrBMp6GU2kUSH2gq0q1Ihv+9JAhJ v/ftnso4WZET++rXSOyG5DA5es+8WPqoJ/92e0KxO9MJRDUptKK5vr8PkhL0shId zJR2tsE6UcHBCZ6Lp5k37/qqTKoHiS3DjzW0Nxh8guEWtcg6dMqdJ5ThGlOlQZwP ZEz5y+URVKwRc0BsOfdWtRzRLSzYT+57C3astuBZCfUtgTBpuguyu40GUCB5fDV6 sGbsvjZ/8fuf9RfjXuzwsXJHLACVhHurcq9ycytF/FnWqzhAMGQlIy8N3pAMwfzM 5jEmcbkSdV8VPHNxvs2j7zWYNBP3SoomMdpef9KjgGDWuOVH5qGScQ== =LerN -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 4 14:23:06 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06F1A7029 for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 14:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koOFRmbZIQNH for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 14:22:50 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2381D1A7010 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 14:22:50 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so15513293igi.0 for <6tisch-security@ietf.org>; Thu, 04 Dec 2014 14:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oWyLJcOHsYZGPEciKYBOi5mEOgdDuWtFFwCW1iViCiw=; b=E65/YCUCAFy/W31X7LX6vOyFULnsyesRtcHD59ARq+VtOG7pwk3mZdpmszcWrnGAhF SZy1fo59ndhwFTdR+J5BYibYQ41Kaj/OOHlUCTrCqpE8D6JOoi12zX3Qlytz1Ts5Lh+9 H8SpEcCaj6PQEboNQSGWzHaEgOUD1n1BiPi9a5V04KJ0KzFoM5rWnsbD5HtOYqgDbq1A /la1FvXu0U7QnFXMs9ULVaRkm0EBLLMCDYQje7JRSuz9lsM8/CQTU/2pMUpWjDoA2loV bv4WrX+39eCDOLi4kQ/0gxnrOJqmkYZstCBJ368nWoA/ecdiNtehHxyMGVAF5YNXOiDz DD2w== MIME-Version: 1.0 X-Received: by 10.42.25.144 with SMTP id a16mr13543445icc.66.1417731769199; Thu, 04 Dec 2014 14:22:49 -0800 (PST) Received: by 10.42.246.136 with HTTP; Thu, 4 Dec 2014 14:22:49 -0800 (PST) In-Reply-To: <10894.1417728668@sandelman.ca> References: <10894.1417728668@sandelman.ca> Date: Thu, 4 Dec 2014 17:22:49 -0500 Message-ID: From: Subir Das To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf303ea5827d72da05096b6633 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/b7IefVDWfEHSnCVt-Y05f80E0xE Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] summary of discussions on Tuesday 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, 04 Dec 2014 22:22:52 -0000 --20cf303ea5827d72da05096b6633 Content-Type: text/plain; charset=UTF-8 Thanks for posting the call minutes and sharing Tero's review. I tried to join the call but failed and then thought that there is no other call. I was on the 9 am call where number of participants were less. Having two calls in a single day is very bad and confusing. I noticed that both chairs joined to this call but they were not in 9 am call. Does this mean they didn't know or endorse the 9 am call? Whatever it may be, Chairs must bring some order here. I understand that these are ad hoc calls but if the WG needs to involve more participants, we need to have one call and decide the call time that is acceptable by majority of the participants. -Subir On Thu, Dec 4, 2014 at 4:31 PM, Michael Richardson wrote: > > I can not speak to the call at 9am. > At 11am, we had Tero Kivinen join: > Attending: > - Thomas (TW) > - Michael (MR) > - Kivinen (TK) > - Malisa > - Rene (joined :30) (RS) > - Pascal (joined :50) (PT) > > Tero composed a summary of his views, which he sent to secdir and to me > privately. is it at: > > https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc > and I will likely reply to that message into this list. > > The discussion started from a need to understand if we had one or two > beacons > coming from the join assistant. I assumed that there would be two, and > that > one would be secured with the production network key, and the other with > the > well known beacon key. There was various amount of discussion as whether > or > not this was even possible to do with available MAC implementations. > > I took an action to research how much of the MAC implementation is in > software in the "main" CPU, and how much is logic in the MAC (whether it's > hard logic, or immutable firmware doesn't matter). I hope to post that > summary on Monday. Associated with this discussion was some details about > the current 802.15.4 receiver state machine, and changes that TK is making > in the -2015 revision. > > A suggestion was made to have one beacon, just the production beacon. This > made a number of us unhappy, as if you can trick someone to use lower ASN, > you cause them to send more data with a previous key, and due to the replay > issue with stream ciphers, you may be able to guess what sent the previous > time. > > We transitioned to the idea of having one beacon, authenticating it only. > Nodes which have the production network key will be able to authenticate > the > beacon and pull the correct ASN. Joining nodes won't be able to > authenticate > the traffic, but will be able to use the beacon to synchronize to the > network > and find the Aloha slot. > > We talked about the use of a virtual extended address for sending beacons, > as the L2-keys are per-extended (source) address, and since multiple nodes > will need to send the beacon (for radio coverage in the mesh), it needs to > be > done right. > > We discussed whether or not the join traffic itself should be encrypted > with > some well known key (different from the production network key, which the > joining node does not yet know). Opinions were expressed that it wasn't > necessary, and the situation from the Zigbee interop were recounted again. > TK suggested that older receiver state machine implementation would have > difficulty with encrypted traffic that was differently trusted. > > - TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and > passive > channel scan we say: The information from the frame to be unsecured shall > be recorded in the PAN descriptor even if the Status from the unsecuring > process indicated an error" > > We discussed what to do with the architecture document, and some text was > promised prior to Friday's 6tisch meeting. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --20cf303ea5827d72da05096b6633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for posting the call minutes and sharing Tero&= #39;s review. I tried to join the call but failed and then thought that the= re is no other call.=C2=A0 I was on the 9 am call where number of participa= nts were less. Having two calls in a single day is very bad and confusing. = I noticed that both chairs joined to this call but they were not in 9 am ca= ll. Does this mean they didn't know or endorse the 9 am call?=C2=A0=C2= =A0 Whatever it may be, Chairs must bring some order here.=C2=A0 I understa= nd that these are ad hoc calls but if the WG needs to involve more particip= ants, we need to have one call and decide the call time that is acceptable = by majority of the participants.

-Subir

On Thu, Dec 4, 2014 at 4:31= PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I can not speak to the call at 9am.
At 11am, we had Tero Kivinen join:
=C2=A0 =C2=A0Attending:
=C2=A0 =C2=A0 - Thomas (TW)
=C2=A0 =C2=A0 - Michael (MR)
=C2=A0 =C2=A0 - Kivinen (TK)
=C2=A0 =C2=A0 - Malisa
=C2=A0 =C2=A0 - Rene (joined :30) (RS)
=C2=A0 =C2=A0 - Pascal (joined :50) (PT)

Tero composed a summary of his views, which he sent to secdir and to me
privately.=C2=A0 is it at:
=C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.or= g/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc
and I will likely reply to that message into this list.

The discussion started from a need to understand if we had one or two beaco= ns
coming from the join assistant.=C2=A0 I assumed that there would be two, an= d that
one would be secured with the production network key, and the other with th= e
well known beacon key.=C2=A0 There was various amount of discussion as whet= her or
not this was even possible to do with available MAC implementations.

I took an action to research how much of the MAC implementation is in
software in the "main" CPU, and how much is logic in the MAC (whe= ther it's
hard logic, or immutable firmware doesn't matter).=C2=A0 I hope to post= that
summary on Monday.=C2=A0 Associated with this discussion was some details a= bout
the current 802.15.4 receiver state machine, and changes that TK is making<= br> in the -2015 revision.

A suggestion was made to have one beacon, just the production beacon. This<= br> made a number of us unhappy, as if you can trick someone to use lower ASN,<= br> you cause them to send more data with a previous key, and due to the replay=
issue with stream ciphers, you may be able to guess what sent the previous<= br> time.

We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate th= e
beacon and pull the correct ASN.=C2=A0 Joining nodes won't be able to a= uthenticate
the traffic, but will be able to use the beacon to synchronize to the netwo= rk
and find the Aloha slot.

We talked about the use of a virtual extended address for sending beacons,<= br> as the L2-keys are per-extended (source) address, and since multiple nodes<= br> will need to send the beacon (for radio coverage in the mesh), it needs to = be
done right.

We discussed whether or not the join traffic itself should be encrypted wit= h
some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't=
necessary, and the situation from the Zigbee interop were recounted again.<= br> TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted.

- TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and = passive
=C2=A0 channel scan we say: The information from the frame to be unsecured = shall
=C2=A0 be recorded in the PAN descriptor even if the Status from the unsecu= ring
=C2=A0 process indicated an error"

We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting.

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


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


--20cf303ea5827d72da05096b6633-- From nobody Thu Dec 4 20:58:35 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 0F5D91AC3FD for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 20:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClYC2zWaRIWN for <6tisch-security@ietfa.amsl.com>; Thu, 4 Dec 2014 20:58:29 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19C51AC3F9 for <6tisch-security@ietf.org>; Thu, 4 Dec 2014 20:58:28 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sB54wO0D013713; Fri, 5 Dec 2014 13:58:24 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sB54wOjr010706; Fri, 5 Dec 2014 13:58:24 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id PAA10687; Fri, 5 Dec 2014 13:58:22 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sB54wLMI000070; Fri, 5 Dec 2014 13:58:21 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id sB54wLV9024442; Fri, 5 Dec 2014 13:58:21 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 13:58:21 +0900 From: To: , <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] summary of discussions on Tuesday Thread-Index: AQHQEAml7sHvy3YEHkO8JRYfQvUuVJyAYI5w Date: Fri, 5 Dec 2014 04:58:20 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0DBFA@TGXML210.toshiba.local> References: <10894.1417728668@sandelman.ca> In-Reply-To: <10894.1417728668@sandelman.ca> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.148] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Je06DTV-GRlplnB7L3K56CAyekE Subject: Re: [6tisch-security] summary of discussions on Tuesday 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, 05 Dec 2014 04:58:33 -0000 Michael and all, Thank you for the minutes. I could not attend this one due to difficulty i= n time difference while I was able to attend the 9am EST one. As I mention= ed before, I can always comment on the minutes even if I am not able to att= end a call. So everyone please do not much mind about time differences. A= ctually I like email discussions. Let me comment on several things. [1] If my understanding is correct the following scheme is most likely the = way for beacons. - Use of a single, not-well-known key for protecting beacons. - Use authentication-only (no-encryption) for protecting the beacons. If so, I agree with this scheme. [2] Regarding a virtual extended address, I think macDefaultKeySource in IE= EE 802.15.4-2011 is such an address. [3] I almost agree with Tero's review, except for the following paragraph: "As I described earlier, this does not protect the nodes who has lost sync with network (i.e. who has been sleeping so long that they do not know the current schedule and current ASN) against replays of the beacons by attacker. On the other hand as the AES-CCM nonce also has the extended address of the sender there, it is enough for the node to make sure he will never go backwards for ASN when sending packets using current network key. If he is tricked to send frames using wrong ASN, then other real nodes in the network will not be able to read those, but that is just DoS, not real security vulnerability, which would happen if he would generate frame with old ASN he has already used, which would generate same AES-CCM nonce." As I mentioned in other email, nonce re-use in AES-CCM is much more than ju= st a DoS, as it gives hints about the key.=20 Best Regards, Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Friday, December 5, 2014 6:31 AM To: 6tisch-security@ietf.org Subject: [6tisch-security] summary of discussions on Tuesday I can not speak to the call at 9am. At 11am, we had Tero Kivinen join: Attending: - Thomas (TW) - Michael (MR) - Kivinen (TK) - Malisa=20 - Rene (joined :30) (RS) - Pascal (joined :50) (PT) Tero composed a summary of his views, which he sent to secdir and to me pri= vately. is it at: https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmS= Vc and I will likely reply to that message into this list. The discussion started from a need to understand if we had one or two beaco= ns coming from the join assistant. I assumed that there would be two, and = that one would be secured with the production network key, and the other wi= th the well known beacon key. There was various amount of discussion as wh= ether or not this was even possible to do with available MAC implementation= s. I took an action to research how much of the MAC implementation is in softw= are in the "main" CPU, and how much is logic in the MAC (whether it's hard = logic, or immutable firmware doesn't matter). I hope to post that summary = on Monday. Associated with this discussion was some details about the curr= ent 802.15.4 receiver state machine, and changes that TK is making in the -= 2015 revision. A suggestion was made to have one beacon, just the production beacon. This = made a number of us unhappy, as if you can trick someone to use lower ASN, = you cause them to send more data with a previous key, and due to the replay= issue with stream ciphers, you may be able to guess what sent the previous= time. We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate th= e beacon and pull the correct ASN. Joining nodes won't be able to authenti= cate the traffic, but will be able to use the beacon to synchronize to the = network and find the Aloha slot. We talked about the use of a virtual extended address for sending beacons, = as the L2-keys are per-extended (source) address, and since multiple nodes = will need to send the beacon (for radio coverage in the mesh), it needs to = be done right. =20 We discussed whether or not the join traffic itself should be encrypted wit= h some well known key (different from the production network key, which the= joining node does not yet know). Opinions were expressed that it wasn't ne= cessary, and the situation from the Zigbee interop were recounted again. TK suggested that older receiver state machine implementation would have di= fficulty with encrypted traffic that was differently trusted. - TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and passi= ve channel scan we say: The information from the frame to be unsecured shall be recorded in the PAN descriptor even if the Status from the unsecuring process indicated an error" We discussed what to do with the architecture document, and some text was p= romised prior to Friday's 6tisch meeting. --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Fri Dec 5 01:11:29 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68741ACE24 for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 01:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRU1yaWy9yBD for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 01:11:18 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09AB1ACE29 for <6tisch-security@ietf.org>; Fri, 5 Dec 2014 01:11:17 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so324681pad.31 for <6tisch-security@ietf.org>; Fri, 05 Dec 2014 01:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5TeJnOQzlVdwbLQ+B6B8BpKNB0RfnpQO5cD7W+piO/o=; b=ADdHCJ35k/iqOyvJGm0N7w7EhIDAuDNsRHUeQZ3OF0dWqsijeESoWzWXkrIoTM6Dty L9PzN9P485PHP4Q13uzz0VfZ5TGPv1eGXtKZ9PfYd7D+EYu9I19lASaahMy2SdRcYRQ7 ThCCqbRX/+eGh3v6XOBVMHePjraBJ2KpAM7guvtvCax6gQ5YYqC9/GQD3PYKqe6opNHa zBVMX6nz0fktWkzw7PF2WvtwOsS8rTPlV3T6n0Cem3E+pOGpGu2GYl5gQQ44iSEZvYRB 4nnbxNw3Bbln4Kf0nJJgeJR9WJG9CyQiSpfQYRdEnqFeZZFQKDylB7UFVOieysmaAfna Z+cA== X-Received: by 10.66.253.197 with SMTP id ac5mr26021751pad.152.1417770676759; Fri, 05 Dec 2014 01:11:16 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.150.69 with HTTP; Fri, 5 Dec 2014 01:10:56 -0800 (PST) In-Reply-To: <5480D2E0.4070300@gmail.com> References: <5480D2E0.4070300@gmail.com> From: Thomas Watteyne Date: Fri, 5 Dec 2014 01:10:56 -0800 X-Google-Sender-Auth: NhMiOUR9lXOkvVZbLAIsd4AtX_g Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=047d7b15acdf8fb156050974751a Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/1obchoqqXEsy7RAuBVk0iy_m7gk Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] scheduling 6tisch security calls through Jan 15th, 2015 - please read and act prior to end of tomorrow - Fri Dec 5, 2014 EST time 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, 05 Dec 2014 09:11:27 -0000 --047d7b15acdf8fb156050974751a Content-Type: text/plain; charset=UTF-8 [not trying to polute the 6TiSCH-security ML :-)] Thanks Rene for coordinating this always complex scheduling issue! Once we have found good times, if you send the schedule to this ML, I can sync https://bitbucket.org/6tisch/meetings/wiki/Home. Thomas On Thu, Dec 4, 2014 at 1:32 PM, Rene Struik wrote: > Dear colleagues: > > I would like to solicit your feedback on the best times for 6tisch > security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, Tue > Jan 6th, Wed Jan 14th). > > Please note that participants are from many different time zones, ranging > from PST time, EST time, Paris time, to Japan time. > The only times that allow everyone in the time zones above sleep/private > time in the 12am-6am time window (wherever they are) are a conf call > 9am-10am EST or one at 5-6pm EST. > > If we cannot agree on a time, we have to use a rotating schedule that > inevitably disadvantages some considerably, since putting some people in > the "middle of the night" block. > > My suggested times are below. > > a) The table below shows how different times impact different participants > PST EST Paris Japan > #A: 2p 5p 11p 7a > #B: 6a 9a 3p 11p > #C: 8a 11a 5p 1a > > b) Suggested schedule (all calls at most one hour): > Tue Dec 9th: 9-10am EST {Schedule #B above (Thomas indicated he would > be in Europe then, so "West Coast" represented on otherwise "decent" hours)} > Tue Dec 16th: 5-6pm EST {Schedule #A above} > Tue Jan 6th: 5-6pm EST {Schedule #A above} > Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most > likely, Yoshi in Atlanta then, so no "night owls" required)} > NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where Wed > am2 is the mid-week plenary (hence, picking the time in that block) > > *Please confirm availability at these times via the Doodle link by end of > *tomorrow*, Friday December 5, 2014, 11:59pm EST* > {The Doodle poll simply mentions the times above, and you can indicate > Yes/No/Maybe for each of the dates} > > Please be mindful of others than yourself, whose biological clock we > should also take into account. > > If you have comments, please do *not* pollute the 6tisch mailing list, but > just send a private note, *keeping the same subject title* of the email. > If you already ventilated opinions, please send those again, with the > *same* subject header as this email. > > http://doodle.com/2cg4p34x3c3uca55 > > == > email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | > US: +1 (415) 690-7363 > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7b15acdf8fb156050974751a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[not trying to polute the 6TiSCH-security ML :-)]

=
Thanks Rene for coordinating this always complex scheduling issu= e!

Once we have found good times, if you send the = schedule to this ML, I can sync=C2=A0https://bitbucket.org/6tisch/meetings/wiki/Home.<= /div>

Thomas

<= div class=3D"gmail_quote">On Thu, Dec 4, 2014 at 1:32 PM, Rene Struik <rstruik.ext@gmail.com> wrote:
=20 =20 =20
Dear colleagues:

I would like to solicit your feedback on the best times for 6tisch security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, Tue Jan 6th, Wed Jan 14th).

Please note that participants are from many different time zones, ranging from PST time, EST time, Paris time, to Japan time.
The only times that allow everyone in the time zones above sleep/private time in the 12am-6am time window (wherever they are) are a conf call 9am-10am EST or one at 5-6pm EST.

If we cannot agree on a time, we have to use a rotating schedule that inevitably disadvantages some considerably, since putting some people in the "middle of the night" block.

My suggested times are below.

a) The table below shows how different times impact different participants
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 PST=C2=A0=C2=A0=C2=A0 EST= =C2=A0 Paris=C2=A0 Japan
#A:=C2=A0=C2=A0 =C2=A0 2p=C2=A0=C2=A0=C2=A0=C2=A0 5p =C2=A0=C2=A0=C2=A0= 11p=C2=A0=C2=A0=C2=A0 7a
#B:=C2=A0=C2=A0 =C2=A0 6a=C2=A0=C2=A0 =C2=A0 9a=C2=A0=C2=A0 =C2=A0 =C2= =A0=C2=A0 3p=C2=A0=C2=A0=C2=A0 11p
#C:=C2=A0=C2=A0=C2=A0=C2=A0 8a =C2=A0 11a =C2=A0 =C2=A0 =C2=A0=C2=A0 5p= =C2=A0 =C2=A0 1a=C2=A0

b) Suggested schedule (all calls at most one hour):
Tue Dec 9th: =C2=A0=C2=A0=C2=A0 9-10am EST {Schedule #B above (Thomas i= ndicated he would be in Europe then, so "West Coast" represented on other= wise "decent" hours)}
Tue Dec 16th: =C2=A0 5-6pm EST=C2=A0=C2=A0 {Schedule #A above}
Tue Jan 6th:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5-6pm EST {Schedule #A above= }
Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most likely, Yoshi in Atlanta then, so no "night owls" requi= red)}
NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where Wed am2 is the mid-week plenary (hence, picking the time in that block)

*Please confirm availability at these times via the Doodle link by end of *tomorrow*, Friday December 5, 2014, 11:59pm EST*
{The Doodle poll simply mentions the times above, and you can indicate Yes/No/Maybe for each of the dates}

Please be mindful of others than yourself, whose biological clock we should also take into account.

If you have comments, please do *not* pollute the 6tisch mailing list, but just send a private note, *keeping the same subject title* of the email.
If you already ventilated opinions, please send those again, with the *same* subject header as this email.

http://doodle.com/2cg= 4p34x3c3uca55

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

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


--047d7b15acdf8fb156050974751a-- From nobody Fri Dec 5 01:59: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 6CD7B1A897B for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 01:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ9mqaWkUzO4 for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 01:58:54 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B2B1A8970 for <6tisch-security@ietf.org>; Fri, 5 Dec 2014 01:58:54 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so421982pde.1 for <6tisch-security@ietf.org>; Fri, 05 Dec 2014 01:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=t0IFAvSL9I8E4kTISqtcJM0uyXDsy4yel4pgKiwQRKk=; b=Hr8owDQOjLfXWRppmllWqgycIqwjzoWXvok156FB/nrP92zhvHp+aOEJQvgzgo/Lo8 N/qimqjvhkldFxrQIdJJ5c7SnYpZbloVCyw7xoGOvfV8Yu6rCB4FFaaRQJ801w/yjxSR p8pHyyvjsbXuJ/URAIjr10IUBCbiTny2hbBKkKkSwFcNXJV+fdBDmy/gFV4MLAUYdsSh k+W35tSyNN73eUum/pxtovlru9lRCumubZHzbQC8+ODUvtZLOg1yHMD/D0mPKtxz23dN Kwhqmo7vDZic+UKzHifLmI1XhuBCBUyvQBRohkwR1CwAn1aDIAUf7GQo2xeiJl7dJUSc L0jQ== X-Received: by 10.66.253.197 with SMTP id ac5mr26366697pad.152.1417773533229; Fri, 05 Dec 2014 01:58:53 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.150.69 with HTTP; Fri, 5 Dec 2014 01:58:33 -0800 (PST) In-Reply-To: <14176.1417729650@sandelman.ca> References: <547DF315.4080808@gmail.com> <14176.1417729650@sandelman.ca> From: Thomas Watteyne Date: Fri, 5 Dec 2014 01:58:33 -0800 X-Google-Sender-Auth: GFJyRQgaGti-_AU0egYRALwoDHI Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b15acdfd1fb330509751f1f Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/mtxjUrIiLhSwoU4L8XMUBPwUfFc Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] security architecture and terminology updates 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, 05 Dec 2014 09:59:00 -0000 --047d7b15acdfd1fb330509751f1f Content-Type: text/plain; charset=UTF-8 Michael, Some editorial comments *inline*. Thomas +Security is performed at layer 2, but configured using the same > layer-5 provisioning interface used for provisioning the schedule. > *rather than "layer-5", "application layer"?* > X.1. Entities involves in the join process > *involves -> **involved* > > The following actors are involved: there is a new joining node. It > is (radio) adjacent to the join assistant. The join assistant is > part of the production network, and participates in one or more > DODAGs, such that it is reachable from the 6LBR, and the JCE. > *add ", possibly over multiple hops"?* > > X.2. Join Protocol deliverables > > The ultimate goal of the join protocol is to provide a new node with > locally significant security credentials so that it is able to take > part in the network directly. The credentials may vary by deployment. > They can be one or both of: > > 1) a network-wide shared symmetric key (this is the production > network key, or MasterKey) > > 2) a locally significant (one-level only) 802.11AR type LDevID > certificate (which allows it to negotiate a pair-wise keys) > *I would expand what "it" refers to. "which allows two neighbor nodes to ..."?* > > These two items is *is -> are* > delivered by JCE *by *the* JCE* > to the joining node using > the 6top protocol. That is, the JCE provisions using a secure > "northbound" interface. *I know what north and southbound refers to. I'm not sure what it means here.* > A Join Protocol describes the authentication > of this interface. > > The above credential (2) can be used for authentication to generate > per-peer > L2 *word missing?* > , using a key exchange protocol. The choice of **the** > key exchange > protocol, and what kind of link and multicast keying needs to be done > is also provisioned by the JCE. There are a number of options for > doing this, such as: > > 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] > (IMPORTANT, a good option. Uses certificates from common CA) > > 2) work in 802.15.9 (uses certificates from common CA) > > 3) Security Framework and Key Management Protocol Requirements for > 6TiSCH [I-D.ohba-6tisch-security] (this document provides the > phase 0 required, using the network-wide shared key) > > 4) Layer-2 security aspects for the IEEE 802.15.4e MAC > [I-D.piro-6tisch-security-issues]: the MasterKey is used to > derive per-peer L2 keys > > Per-peer L2 keying is critical when doing peer-2-peer *https://tools.ietf.org/html/draft-ietf-6tisch-architecture-04 refers to "distributed" rather than P2P. I suggest to use the same terminology.* > schedule > negotiation over 15.4 *IEEE802.15.4e* > Information Elements. Therefore a network-wide > layer-2 *you use both layer-2 and L2. Homogenize?* > key is inappropriate for the self-organizing networks, and a > protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. > > For networks where there is a PCE present, it will do all schedule > computation. As a result the only trust relationship necessary is > between the individual node and the PCE, and it MAY be acceptable to > have a network-wide L2 key derived in ways such as > [I-D.piro-6tisch-security-issues] describes in section ?. The trust > relationship between the PCE and the joining node flows from the > LDevID certificate loaded by the JCE. When the PCE and JCE are co- > located, the existing 6top/DTLS security association could be reused. > > X.3. Join Protocol connection setup > > The intermediate level goal of the join protocol is to enable a Join > Coordination Entity (JCE) to reach out to the new node, and install > the credentials detailed above. The JCE must authenticate itself to > the joining node so that the joining node will know *will know -> knows* > that it has > joined the correct network, and the joining node must authenticate > itself to the JCE so that the JCE will know *will know -> knows* > that this node belongs in > the network. This two way authentication occurs in the 6top/CoAP/ > DTLS session that is established between the JCE and the joining > node. > > [I-D.ietf-6tisch-6top-interface] presents a way to interface to a > 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] > explains how to access that information model using CoAP. This > information model will include security attributes for the network. > The JCE would therefore reach out to the joining node and simply > provision appropriate security properties into the joining node, much > like the PCE will provision schedules. > > *will provision -> provisions* > This 6top-based secure join protocol has defined a push model for > security provisioning by the JCE. *I would add a sentence to describe what you mean by push model.* > This has been done for three > reasons: > > 1) 6tisch nodes already have to have a 6top CoAP server for schedule > provising > *typo* > > 2) this permits the JCE to manage how many nodes are trying to join > at the same time, and limit how much bandwidth/energy is used for > the join operation, and also for the JCE to prioritize the join > order for nodes. > > 3) making the JCE initiate the DTLS connection significantly > simplies the certificate chains that must be exchanged as the > most constrained side (the joining node) provides it's > *it's -> its* > credentials first, and lets the less constrained JCE figure out > what kind of certificate chain will be required to authenticate > the JCE to the joining node. In EAP-TLS/802.1x situations, the > TLS channel is created in the opposite direction, and it would > have to complete in a tentative way, and then further > authorization occur in-band. > > X.4. End to End considerations for Join Protocol > > In order for a 6top/DTLS/CoAP connection to occur between the JCE and > the joining node, there needs to be end-to-end IPv6 connectivity > between those two entities. The joining node will not participate in > the route-over RPL mesh, but rather will be seen by the network as > being a 6lowpan only leaf-node. > *to be generic, I would not specify route-over RPL mesh, but rather "not participate in the multi-hop mesh"* > > X.5. Join node discovery mechanism > > In order **for** > the JCE **to** > reach out to provision > the Joining Node, it needs to know that the new node is present. > The mechanism will use a protocol piggybacked on the 6lowPAN *"6LoWPAN" (case)* > Address Resolution > mechanism described [RFC6775]. The 6LBR will need to inform the JCE > about the new node. (This interaction is presently out of scope) > > Prior to being able to announce itself in a NS, the joining node > needs to find the Join Network. This is done by listening to *to -> for* > the > enhanced beacon which are broadcast in designated slotframes by the > network. These are the same enhanced beacons which are used by the > production network. The enhanced beacons are transmitted in "MIC- > only" (authentication only) mode. Nodes with the production network > key can authenticate the beacons. The newly joining node can not > authenticate the beacons, but it can read and process them, and can > use this as a way to synchronize to the network. During the Alpha > period, *not sure what Alpha period is* > the joining node can send a Router Soliticiation, *typo* > and receive > an appropriate Router Advertisement giving the Joining Node a prefix > and default route to which to send the join traffic (the ND DAD > mentioned above). > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7b15acdfd1fb330509751f1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael,
Some editorial comments inline.
Thomas
<= br>
=C2=A0 =C2=A0+Security is pe= rformed at layer 2, but configured using the same
=C2=A0 =C2=A0layer-5 provisioning interface used for provisioning the sched= ule.

rather = than "layer-5", "application layer"?
=C2=A0
X.1.=C2=A0 Entities involves in the join process

<= /div>
involves ->=C2=A0involved
=C2=A0

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

add ", = possibly over multiple hops"?
=C2=A0

X.2.=C2=A0 Join Protocol deliverables

=C2=A0 =C2=A0The ultimate goal of the join protocol is to provide a new nod= e with
=C2=A0 =C2=A0locally significant security credentials so that it is able to= take
=C2=A0 =C2=A0part in the network directly.=C2=A0 The credentials may vary b= y deployment.
=C2=A0 =C2=A0They can be one or both of:

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

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

= I would expand what "it" refers to. "which allows two neighb= or nodes to ..."?
=C2=A0

=C2=A0 =C2=A0These two items is

is -> are
=C2=A0
delivered by JCE

by *the* JCE
=C2=A0
to the joining node using
=C2=A0 =C2=A0the 6top protocol.=C2=A0 That is, the JCE provisions using a s= ecure
=C2=A0 =C2=A0"northbound" interface.

=
I know what north and southbound refers to.= I'm not sure what it means here.
=C2=A0
=
A Join Protocol describes the authentication
=C2=A0 =C2=A0of this interface.

=C2=A0 =C2=A0The above credential (2) can be used for authentication to gen= erate per-peer
=C2=A0 =C2=A0L2

= word missing?
=C2=A0
, using= a key exchange protocol.=C2=A0 The choice of

*the*
=C2=A0
key exchange
=C2=A0 =C2=A0protocol, and what kind of link and multicast keying needs to = be done
=C2=A0 =C2=A0is also provisioned by the JCE.=C2=A0 There are a number of op= tions for
=C2=A0 =C2=A0doing this, such as:

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

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

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

=C2=A0 =C2=A0Per-peer L2 keying is critical when doing peer-2-peer

https:/= /tools.ietf.org/html/draft-ietf-6tisch-architecture-04 refers to "= distributed" rather than P2P. I suggest to use the same terminology.
=C2=A0
schedule
=C2=A0 =C2=A0negotiation over 15.4

IEEE802.15.4e
=C2=A0
Information Elements.=C2=A0 Therefore a network-wide
=C2=A0 =C2=A0layer-2

you use both layer-2 and L2. Homogenize?
=C2=A0
key is inappropriate for the self-organizing networks,= and a
=C2=A0 =C2=A0protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 = keys.

=C2=A0 =C2=A0For networks where there is a PCE present, it will do all sche= dule
=C2=A0 =C2=A0computation.=C2=A0 As a result the only trust relationship nec= essary is
=C2=A0 =C2=A0between the individual node and the PCE, and it MAY be accepta= ble to
=C2=A0 =C2=A0have a network-wide L2 key derived in ways such as
=C2=A0 =C2=A0[I-D.piro-6tisch-security-issues] describes in section ?.=C2= =A0 The trust
=C2=A0 =C2=A0relationship between the PCE and the joining node flows from t= he
=C2=A0 =C2=A0LDevID certificate loaded by the JCE.=C2=A0 When the PCE and J= CE are co-
=C2=A0 =C2=A0located, the existing 6top/DTLS security association could be = reused.

X.3.=C2=A0 Join Protocol connection setup

=C2=A0 =C2=A0The intermediate level goal of the join protocol is to enable = a Join
=C2=A0 =C2=A0Coordination Entity (JCE) to reach out to the new node, and in= stall
=C2=A0 =C2=A0the credentials detailed above.=C2=A0 The JCE must authenticat= e itself to
=C2=A0 =C2=A0the joining node so that the joining node will know

will know -> knows<= /font>
=C2=A0
that it has
=C2=A0 =C2=A0joined the correct network, and the joining node must authenti= cate
=C2=A0 =C2=A0itself to the JCE so that the JCE will know
<= br>
will know -> knows
=
=C2=A0
that this node belongs in
=C2=A0 =C2=A0the network.=C2=A0 This two way authentication occurs in the 6= top/CoAP/
=C2=A0 =C2=A0DTLS session that is established between the JCE and the joini= ng
=C2=A0 =C2=A0node.

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

will provision -> = provisions
=C2=A0
=C2=A0 =C2=A0This 6top-based secure join protocol has defined a push model = for
=C2=A0 =C2=A0security provisioning by the JCE.

<= div>I would add a sentence to describe what= you mean by push model.
=C2=A0
Thi= s has been done for three
=C2=A0 =C2=A0reasons:

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

typo
=C2=A0

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

=C2=A0 =C2=A03)=C2=A0 making the JCE initiate the DTLS connection significa= ntly
=C2=A0 =C2=A0 =C2=A0 =C2=A0simplies the certificate chains that must be exc= hanged as the
=C2=A0 =C2=A0 =C2=A0 =C2=A0most constrained side (the joining node) provide= s it's

it's -> its
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0credentials first, and lets the less constrained= JCE figure out
=C2=A0 =C2=A0 =C2=A0 =C2=A0what kind of certificate chain will be required = to authenticate
=C2=A0 =C2=A0 =C2=A0 =C2=A0the JCE to the joining node.=C2=A0 In EAP-TLS/80= 2.1x situations, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS channel is created in the opposite direction= , and it would
=C2=A0 =C2=A0 =C2=A0 =C2=A0have to complete in a tentative way, and then fu= rther
=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization occur in-band.

X.4.=C2=A0 End to End considerations for Join Protocol

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

to be generic, I would not specify ro= ute-over RPL mesh, but rather "not participate in the multi-hop mesh&q= uot;
=C2=A0

X.5.=C2=A0 Join node discovery mechanism

=C2=A0 =C2=A0In order

*for*
=C2=A0
the JCE

*to*
=C2=A0
reach out to provision
=C2=A0 =C2=A0the Joining Node, it needs to know that the new node is presen= t.
=C2=A0 =C2=A0The mechanism will use a protocol piggybacked on the 6lowPAN <= /blockquote>

"6LoWP= AN" (case)
=C2=A0
Address Reso= lution
=C2=A0 =C2=A0mechanism described [RFC6775].=C2=A0 The 6LBR will need to inf= orm the JCE
=C2=A0 =C2=A0about the new node.=C2=A0 (This interaction is presently out o= f scope)

=C2=A0 =C2=A0Prior to being able to announce itself in a NS, the joining no= de
=C2=A0 =C2=A0needs to find the Join Network.=C2=A0 This is done by listenin= g to

to -&g= t; for
=C2=A0
the
=C2=A0 =C2=A0enhanced beacon which are broadcast in designated slotframes b= y the
=C2=A0 =C2=A0network.=C2=A0 These are the same enhanced beacons which are u= sed by the
=C2=A0 =C2=A0production network.=C2=A0 The enhanced beacons are transmitted= in "MIC-
=C2=A0 =C2=A0only" (authentication only) mode.=C2=A0 Nodes with the pr= oduction network
=C2=A0 =C2=A0key can authenticate the beacons.=C2=A0 The newly joining node= can not
=C2=A0 =C2=A0authenticate the beacons, but it can read and process them, an= d can
=C2=A0 =C2=A0use this as a way to synchronize to the network.=C2=A0 During = the Alpha
=C2=A0 =C2=A0period,

not sure what Alpha period is
=C2=A0
the joining node can send a Router Soliticiation,
<= div>
typo
= =C2=A0
and receive
=C2=A0 =C2=A0an appropriate Router Advertisement giving the Joining Node a = prefix
=C2=A0 =C2=A0and default route to which to send the join traffic (the ND DA= D
=C2=A0 =C2=A0mentioned above).


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




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


--047d7b15acdfd1fb330509751f1f-- From nobody Fri Dec 5 02:06:44 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923271A0108 for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 02:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6hOhkq9eJEs for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 02:06:39 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9541ACE2E for <6tisch-security@ietf.org>; Fri, 5 Dec 2014 02:06:29 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so107595pdb.10 for <6tisch-security@ietf.org>; Fri, 05 Dec 2014 02:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=chCas9CbKTvHKyW4FwHq2o1vSgCmXuSIuWyeFC3qzGc=; b=qYr+pdLgO5gEbq9zA3CruQKZc7nr44mGCkRqOufLQI5kyRiIDTvnvelpIB/1rKQfIA 4D9UKBF2KFFB0G2EN99WFsHheZXRK292Jk0ShcTi+obn819yTfCvExvYYDOoxvM8km2/ MGE4c43oNOVRdPhBce/OOH+sP+OYmvorf1tPV5GEzS2UdxdQ12GHoF1oJlMs0Oia0G7A 8BLtx5Rp3n5GaHFkB6DFrMEiZgBFgfpNS1MdRSoY/UW5yXz7cCxEfco+qZPcolrkmFQ9 bwieG0n5P9ShnsJKrfbg5NxsMs6L0mEgaN6FwEQjtJ+ozuwUMPTK1Pqjf1JVOyI0KkWP wMNA== X-Received: by 10.70.54.1 with SMTP id f1mr26969895pdp.63.1417773988784; Fri, 05 Dec 2014 02:06:28 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.150.69 with HTTP; Fri, 5 Dec 2014 02:06:08 -0800 (PST) In-Reply-To: <10894.1417728668@sandelman.ca> References: <10894.1417728668@sandelman.ca> From: Thomas Watteyne Date: Fri, 5 Dec 2014 02:06:08 -0800 X-Google-Sender-Auth: bB_Z4bMk3IMR-Qs3F_2kFOhlt3c Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11343cccf92f6a0509753af9 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/P5tvhuhucrBxiMidzjVvhs7mKo8 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] summary of discussions on Tuesday 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, 05 Dec 2014 10:06:41 -0000 --001a11343cccf92f6a0509753af9 Content-Type: text/plain; charset=UTF-8 Minutes archived at https://bitbucket.org/6tisch/meetings/wiki/141202b_webex_security. On Thu, Dec 4, 2014 at 1:31 PM, Michael Richardson wrote: > > I can not speak to the call at 9am. > At 11am, we had Tero Kivinen join: > Attending: > - Thomas (TW) > - Michael (MR) > - Kivinen (TK) > - Malisa > - Rene (joined :30) (RS) > - Pascal (joined :50) (PT) > > Tero composed a summary of his views, which he sent to secdir and to me > privately. is it at: > > https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc > and I will likely reply to that message into this list. > > The discussion started from a need to understand if we had one or two > beacons > coming from the join assistant. I assumed that there would be two, and > that > one would be secured with the production network key, and the other with > the > well known beacon key. There was various amount of discussion as whether > or > not this was even possible to do with available MAC implementations. > > I took an action to research how much of the MAC implementation is in > software in the "main" CPU, and how much is logic in the MAC (whether it's > hard logic, or immutable firmware doesn't matter). I hope to post that > summary on Monday. Associated with this discussion was some details about > the current 802.15.4 receiver state machine, and changes that TK is making > in the -2015 revision. > > A suggestion was made to have one beacon, just the production beacon. This > made a number of us unhappy, as if you can trick someone to use lower ASN, > you cause them to send more data with a previous key, and due to the replay > issue with stream ciphers, you may be able to guess what sent the previous > time. > > We transitioned to the idea of having one beacon, authenticating it only. > Nodes which have the production network key will be able to authenticate > the > beacon and pull the correct ASN. Joining nodes won't be able to > authenticate > the traffic, but will be able to use the beacon to synchronize to the > network > and find the Aloha slot. > > We talked about the use of a virtual extended address for sending beacons, > as the L2-keys are per-extended (source) address, and since multiple nodes > will need to send the beacon (for radio coverage in the mesh), it needs to > be > done right. > > We discussed whether or not the join traffic itself should be encrypted > with > some well known key (different from the production network key, which the > joining node does not yet know). Opinions were expressed that it wasn't > necessary, and the situation from the Zigbee interop were recounted again. > TK suggested that older receiver state machine implementation would have > difficulty with encrypted traffic that was differently trusted. > > - TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and > passive > channel scan we say: The information from the frame to be unsecured shall > be recorded in the PAN descriptor even if the Status from the unsecuring > process indicated an error" > > We discussed what to do with the architecture document, and some text was > promised prior to Friday's 6tisch meeting. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a11343cccf92f6a0509753af9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 4, 2014 at 1:31 PM, Michael Richar= dson <mcr+ietf@sandelman.ca> wrote:

I can not speak to the call at 9am.
At 11am, we had Tero Kivinen join:
=C2=A0 =C2=A0Attending:
=C2=A0 =C2=A0 - Thomas (TW)
=C2=A0 =C2=A0 - Michael (MR)
=C2=A0 =C2=A0 - Kivinen (TK)
=C2=A0 =C2=A0 - Malisa
=C2=A0 =C2=A0 - Rene (joined :30) (RS)
=C2=A0 =C2=A0 - Pascal (joined :50) (PT)

Tero composed a summary of his views, which he sent to secdir and to me
privately.=C2=A0 is it at:
=C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.or= g/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc
and I will likely reply to that message into this list.

The discussion started from a need to understand if we had one or two beaco= ns
coming from the join assistant.=C2=A0 I assumed that there would be two, an= d that
one would be secured with the production network key, and the other with th= e
well known beacon key.=C2=A0 There was various amount of discussion as whet= her or
not this was even possible to do with available MAC implementations.

I took an action to research how much of the MAC implementation is in
software in the "main" CPU, and how much is logic in the MAC (whe= ther it's
hard logic, or immutable firmware doesn't matter).=C2=A0 I hope to post= that
summary on Monday.=C2=A0 Associated with this discussion was some details a= bout
the current 802.15.4 receiver state machine, and changes that TK is making<= br> in the -2015 revision.

A suggestion was made to have one beacon, just the production beacon. This<= br> made a number of us unhappy, as if you can trick someone to use lower ASN,<= br> you cause them to send more data with a previous key, and due to the replay=
issue with stream ciphers, you may be able to guess what sent the previous<= br> time.

We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate th= e
beacon and pull the correct ASN.=C2=A0 Joining nodes won't be able to a= uthenticate
the traffic, but will be able to use the beacon to synchronize to the netwo= rk
and find the Aloha slot.

We talked about the use of a virtual extended address for sending beacons,<= br> as the L2-keys are per-extended (source) address, and since multiple nodes<= br> will need to send the beacon (for radio coverage in the mesh), it needs to = be
done right.

We discussed whether or not the join traffic itself should be encrypted wit= h
some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't=
necessary, and the situation from the Zigbee interop were recounted again.<= br> TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted.

- TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and = passive
=C2=A0 channel scan we say: The information from the frame to be unsecured = shall
=C2=A0 be recorded in the PAN descriptor even if the Status from the unsecu= ring
=C2=A0 process indicated an error"

We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting.

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


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


--001a11343cccf92f6a0509753af9-- From nobody Fri Dec 5 02:16:44 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3211ACE20 for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 02:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opw5rsSUQzhh for <6tisch-security@ietfa.amsl.com>; Fri, 5 Dec 2014 02:16:40 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA9C1A0115 for <6tisch-security@ietf.org>; Fri, 5 Dec 2014 02:16:39 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so429148pdb.32 for <6tisch-security@ietf.org>; Fri, 05 Dec 2014 02:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jj8DKiusvRE2owXJAbafAn+CwiKyLKFrMwmO7XXgiL8=; b=Y4r3yJiB9vk1QJLK7CSVr9t0D4r8BXMzMdZYfODcdWi9QGIAQORa9h/zN9CC46blwL JJXHUpqTifcCg0EWGXhsRMKUmVYDs6GIEDWEc6u1xz/uZybNPZLVS+HNNfDVblSkh9Wt ZrozwNCg2zKuoYHcoIGIyw1K5tc+W0bTiI+evmvLqIjaCY+lJz1QbVCzLxpUogm5dp+t brnmHHc8LEh2/zlLPs0b4YP/uPY1QjRS+SA5o0NcuL0lcKnMy7WRI8dTY+hbrbffx/AO gAmupUYcGUGQJF06R2wiIcrOfakzbs17Kb5wO4suq8z+i63MePJSVKMUiKo3WLs1N3V8 6j8g== X-Received: by 10.68.68.227 with SMTP id z3mr2332005pbt.3.1417774599112; Fri, 05 Dec 2014 02:16:39 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.150.69 with HTTP; Fri, 5 Dec 2014 02:16:18 -0800 (PST) In-Reply-To: References: <10894.1417728668@sandelman.ca> From: Thomas Watteyne Date: Fri, 5 Dec 2014 02:16:18 -0800 X-Google-Sender-Auth: Gdmo4hcY8m4vAY9-_QFO2lYFlE8 Message-ID: To: Subir Das Content-Type: multipart/alternative; boundary=001a11380ca05a0f400509755f7b Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/t2DV8OE7jJTo2GBT94uHOHZX34g Cc: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] summary of discussions on Tuesday 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, 05 Dec 2014 10:16:43 -0000 --001a11380ca05a0f400509755f7b Content-Type: text/plain; charset=UTF-8 Subir, all, Having two security calls is NOT something the chairs endorse. We have had extensive private exchanges to understand what happened, and have converged on steps to better coordinate for this situation not to repeat. Thomas & Pascal On Thu, Dec 4, 2014 at 2:22 PM, Subir Das wrote: > Thanks for posting the call minutes and sharing Tero's review. I tried to > join the call but failed and then thought that there is no other call. I > was on the 9 am call where number of participants were less. Having two > calls in a single day is very bad and confusing. I noticed that both chairs > joined to this call but they were not in 9 am call. Does this mean they > didn't know or endorse the 9 am call? Whatever it may be, Chairs must > bring some order here. I understand that these are ad hoc calls but if the > WG needs to involve more participants, we need to have one call and decide > the call time that is acceptable by majority of the participants. > > -Subir > > On Thu, Dec 4, 2014 at 4:31 PM, Michael Richardson > wrote: > >> >> I can not speak to the call at 9am. >> At 11am, we had Tero Kivinen join: >> Attending: >> - Thomas (TW) >> - Michael (MR) >> - Kivinen (TK) >> - Malisa >> - Rene (joined :30) (RS) >> - Pascal (joined :50) (PT) >> >> Tero composed a summary of his views, which he sent to secdir and to me >> privately. is it at: >> >> https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc >> and I will likely reply to that message into this list. >> >> The discussion started from a need to understand if we had one or two >> beacons >> coming from the join assistant. I assumed that there would be two, and >> that >> one would be secured with the production network key, and the other with >> the >> well known beacon key. There was various amount of discussion as whether >> or >> not this was even possible to do with available MAC implementations. >> >> I took an action to research how much of the MAC implementation is in >> software in the "main" CPU, and how much is logic in the MAC (whether it's >> hard logic, or immutable firmware doesn't matter). I hope to post that >> summary on Monday. Associated with this discussion was some details about >> the current 802.15.4 receiver state machine, and changes that TK is making >> in the -2015 revision. >> >> A suggestion was made to have one beacon, just the production beacon. This >> made a number of us unhappy, as if you can trick someone to use lower ASN, >> you cause them to send more data with a previous key, and due to the >> replay >> issue with stream ciphers, you may be able to guess what sent the previous >> time. >> >> We transitioned to the idea of having one beacon, authenticating it only. >> Nodes which have the production network key will be able to authenticate >> the >> beacon and pull the correct ASN. Joining nodes won't be able to >> authenticate >> the traffic, but will be able to use the beacon to synchronize to the >> network >> and find the Aloha slot. >> >> We talked about the use of a virtual extended address for sending beacons, >> as the L2-keys are per-extended (source) address, and since multiple nodes >> will need to send the beacon (for radio coverage in the mesh), it needs >> to be >> done right. >> >> We discussed whether or not the join traffic itself should be encrypted >> with >> some well known key (different from the production network key, which the >> joining node does not yet know). Opinions were expressed that it wasn't >> necessary, and the situation from the Zigbee interop were recounted again. >> TK suggested that older receiver state machine implementation would have >> difficulty with encrypted traffic that was differently trusted. >> >> - TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and >> passive >> channel scan we say: The information from the frame to be unsecured >> shall >> be recorded in the PAN descriptor even if the Status from the unsecuring >> process indicated an error" >> >> We discussed what to do with the architecture document, and some text was >> promised prior to Friday's 6tisch meeting. >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --001a11380ca05a0f400509755f7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Subir, all,

Having two security calls i= s NOT something the chairs endorse. We have had extensive private exchanges= to understand what happened, and have converged on steps to better coordin= ate for this situation not to repeat.

Thomas &= Pascal=C2=A0

On Thu, Dec 4, 2014 at 2:22 PM, Subir Das <subirdas21@gmail.com= > wrote:
<= div>Thanks for posting the call minutes and sharing Tero's review. I tr= ied to join the call but failed and then thought that there is no other cal= l.=C2=A0 I was on the 9 am call where number of participants were less. Hav= ing two calls in a single day is very bad and confusing. I noticed that bot= h chairs joined to this call but they were not in 9 am call. Does this mean= they didn't know or endorse the 9 am call?=C2=A0=C2=A0 Whatever it may= be, Chairs must bring some order here.=C2=A0 I understand that these are a= d hoc calls but if the WG needs to involve more participants, we need to ha= ve one call and decide the call time that is acceptable by majority of the = participants.

-Subir
On Thu, Dec 4, 2014 at 4= :31 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote= :

I can not speak to the call at 9am.
At 11am, we had Tero Kivinen join:
=C2=A0 =C2=A0Attending:
=C2=A0 =C2=A0 - Thomas (TW)
=C2=A0 =C2=A0 - Michael (MR)
=C2=A0 =C2=A0 - Kivinen (TK)
=C2=A0 =C2=A0 - Malisa
=C2=A0 =C2=A0 - Rene (joined :30) (RS)
=C2=A0 =C2=A0 - Pascal (joined :50) (PT)

Tero composed a summary of his views, which he sent to secdir and to me
privately.=C2=A0 is it at:
=C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.or= g/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc
and I will likely reply to that message into this list.

The discussion started from a need to understand if we had one or two beaco= ns
coming from the join assistant.=C2=A0 I assumed that there would be two, an= d that
one would be secured with the production network key, and the other with th= e
well known beacon key.=C2=A0 There was various amount of discussion as whet= her or
not this was even possible to do with available MAC implementations.

I took an action to research how much of the MAC implementation is in
software in the "main" CPU, and how much is logic in the MAC (whe= ther it's
hard logic, or immutable firmware doesn't matter).=C2=A0 I hope to post= that
summary on Monday.=C2=A0 Associated with this discussion was some details a= bout
the current 802.15.4 receiver state machine, and changes that TK is making<= br> in the -2015 revision.

A suggestion was made to have one beacon, just the production beacon. This<= br> made a number of us unhappy, as if you can trick someone to use lower ASN,<= br> you cause them to send more data with a previous key, and due to the replay=
issue with stream ciphers, you may be able to guess what sent the previous<= br> time.

We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate th= e
beacon and pull the correct ASN.=C2=A0 Joining nodes won't be able to a= uthenticate
the traffic, but will be able to use the beacon to synchronize to the netwo= rk
and find the Aloha slot.

We talked about the use of a virtual extended address for sending beacons,<= br> as the L2-keys are per-extended (source) address, and since multiple nodes<= br> will need to send the beacon (for radio coverage in the mesh), it needs to = be
done right.

We discussed whether or not the join traffic itself should be encrypted wit= h
some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't=
necessary, and the situation from the Zigbee interop were recounted again.<= br> TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted.

- TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and = passive
=C2=A0 channel scan we say: The information from the frame to be unsecured = shall
=C2=A0 be recorded in the PAN descriptor even if the Status from the unsecu= ring
=C2=A0 process indicated an error"

We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting.

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


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



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


--001a11380ca05a0f400509755f7b-- From nobody Mon Dec 8 01:58:38 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C721A89FA for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 01:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58lphOUknbnD for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 01:58:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 23D4A1A89EF for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 01:58:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB89wUaY023532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Dec 2014 11:58:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB89wTMV028378; Mon, 8 Dec 2014 11:58:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21637.30277.274859.506613@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2014 11:58:29 +0200 From: Tero Kivinen To: Rene Struik In-Reply-To: <54806B2E.4090408@gmail.com> References: <20771.1417540254@sandelman.ca> <21632.19591.491812.845025@fireball.kivinen.iki.fi> <54806B2E.4090408@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 10 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/OybV_JvcE8V98PlB6MO9BVV8Tcw Cc: Giuseppe Piro , Michael Richardson , 6tisch-security@ietf.org Subject: Re: [6tisch-security] Giuseppe Piro: Joining node and DeviceDescriptor X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 09:58:37 -0000 Rene Struik writes: > Please note that setting the security level for data frames to zero > would have any MAC data frame, irrespective of originating device > pass incoming processing and be pushed to the higher layer, whereas > with the exempt flag mechanism this is only the case for those data > frames that originate from a specifically identified device (in > casu, the joining node). Yes, but when we discussed this in the 15.9 the comment was that upper layer needs to verify the security level anyways. For example upper layer do not have a way to distinguish data frames from multipurpose frames, thus trying to set up different security level requirements for the data and multipurpose frames does not work. Also it is impossible to know the joining nodes address beforehand, thus entry for exempt flag cannot be filled there beforehand, which means first packet would always be lost. And if you have any exempts in your table, then you still need to verify the security levels in the upper layer. > Since MAC security processing (with security switched on) impacts > the recipient device's state, one cannot do "after the fact" > pass/stop filtering at the higher layer without risking entirely > messing up security-related tables at the MAC. 15.9 will recommend that all security level checking will be done on the upper layer, and no filtering are done on the MAC layer, mostly because the exempt flag processing does not really work that well for the first connection case. Unsecured data or multipurpose frames received by the peer do not have any impact on any of the state in MAC, and do not affect the security related tables at the MAC. Those frames are simply passed to the upper layer, which can then check the security level parameter and act accordingly, so the policy checking can be done after the fact on the upper layer, and in most cases it needs to be done there. Thus there is no functional benefits for doing those checks on the MAC layer for data and multipurpose frames (which are not acted upon on the MAC layer). The minimum security level processing in the MAC is only useful for frames which are acted upon on the MAC layer. -- kivinen@iki.fi From nobody Mon Dec 8 06:30: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 A94AC1A9076; Mon, 8 Dec 2014 06:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWFNee0PdpWh; Mon, 8 Dec 2014 06:29:58 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098E91A9083; Mon, 8 Dec 2014 06:29:42 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so4541352ieb.21 for ; Mon, 08 Dec 2014 06:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=PeOHu4t0wXUIusU06e+dPKo4mHuTbDtPYfRrc5IIsX8=; b=aTz6H+SDuVcDmlz1SLh9wJLZzGzosFfu3ZtUpPgKlzv5SOdJW/ONsJfJVKhx3WykoO DKVULKSWEkIXHdtMZxoqlqWm/1IRQJLcqXMvLUWoX2U6AZmJpr0EpFbrJMTqKqXevMDW h7ttBwIsUgx7Az3qVHMRrIWBKu2Vu5ldg9ToYCiunV6VRPm48BOPnw5pE826VT4wucuW yxeDne1h5cyfVSXqGuyTD8aMIVBW6/jZQFKQCv+TAHKehvNmoocqtAHeSj4pUJw4LDRx vNaGWecmgafjIfgLS2RVk5Ly+6yzyTZ67OozWQM6vm+pyZQapVRKjQpn5rkI/gbo/E3e DXSA== X-Received: by 10.107.35.83 with SMTP id j80mr10972228ioj.55.1418048980994; Mon, 08 Dec 2014 06:29:40 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id ga3sm3892737igd.10.2014.12.08.06.29.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 06:29:40 -0800 (PST) Message-ID: <5485B5D2.8010401@gmail.com> Date: Mon, 08 Dec 2014 09:29:38 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <5480D2E0.4070300@gmail.com> In-Reply-To: <5480D2E0.4070300@gmail.com> Content-Type: multipart/alternative; boundary="------------050908070402050904040803" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/0SAVX4-A8dOmTouwuVnYG8cAOmg Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: [6tisch-security] Please mark your calendar: schedule 6tisch security calls through Jan 15th, 2015 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:30:00 -0000 This is a multi-part message in MIME format. --------------050908070402050904040803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: The (rotating) schedule for the next few 6tisch security calls is as follows: Tue Dec 9th: 9-10am EST Tue Dec 16th: 5-6pm EST Tue Jan 6th: 5-6pm EST Wed Jan 14th: 11am-12pm EST This schedule is based on feedback on the Doodle pool conducted last week and offline comments received. Thanks for participating. This schedule tries and accommodate different time zones of participants (currently, ranging from PST time, EST time, Paris time, to Japan time). We may conduct another poll to determine the schedule after half of January. Best regards, Rene On 12/4/2014 4:32 PM, Rene Struik wrote: > Dear colleagues: > > I would like to solicit your feedback on the best times for 6tisch > security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, > Tue Jan 6th, Wed Jan 14th). > > Please note that participants are from many different time zones, > ranging from PST time, EST time, Paris time, to Japan time. > The only times that allow everyone in the time zones above > sleep/private time in the 12am-6am time window (wherever they are) are > a conf call 9am-10am EST or one at 5-6pm EST. > > If we cannot agree on a time, we have to use a rotating schedule that > inevitably disadvantages some considerably, since putting some people > in the "middle of the night" block. > > My suggested times are below. > > a) The table below shows how different times impact different participants > PST EST Paris Japan > #A: 2p 5p 11p 7a > #B: 6a 9a 3p 11p > #C: 8a 11a 5p 1a > > b) Suggested schedule (all calls at most one hour): > Tue Dec 9th: 9-10am EST {Schedule #B above (Thomas indicated he > would be in Europe then, so "West Coast" represented on otherwise > "decent" hours)} > Tue Dec 16th: 5-6pm EST {Schedule #A above} > Tue Jan 6th: 5-6pm EST {Schedule #A above} > Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most > likely, Yoshi in Atlanta then, so no "night owls" required)} > NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where > Wed am2 is the mid-week plenary (hence, picking the time in that block) > > *Please confirm availability at these times via the Doodle link by end > of *tomorrow*, Friday December 5, 2014, 11:59pm EST* > {The Doodle poll simply mentions the times above, and you can indicate > Yes/No/Maybe for each of the dates} > > Please be mindful of others than yourself, whose biological clock we > should also take into account. > > If you have comments, please do *not* pollute the 6tisch mailing list, > but just send a private note, *keeping the same subject title* of the > email. > If you already ventilated opinions, please send those again, with the > *same* subject header as this email. > > http://doodle.com/2cg4p34x3c3uca55 > > == > email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 > | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------050908070402050904040803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear colleagues:

The (rotating) schedule for the next few 6tisch security calls is as follows:

Tue Dec 9th:     9-10am EST
Tue Dec 16th:   5-6pm EST
Tue Jan 6th:      5-6pm EST
Wed Jan 14th: 11am-12pm EST

This schedule is based on feedback on the Doodle pool conducted last week and offline comments received. Thanks for participating.

This schedule tries and accommodate different time zones of participants (currently, ranging from PST time, EST time, Paris time, to Japan time).

We may conduct another poll to determine the schedule after half of January.

Best regards, Rene

On 12/4/2014 4:32 PM, Rene Struik wrote:
Dear colleagues:

I would like to solicit your feedback on the best times for 6tisch security conf calls for the next few calls (Tue Dec 9th, Tue Dec 16th, Tue Jan 6th, Wed Jan 14th).

Please note that participants are from many different time zones, ranging from PST time, EST time, Paris time, to Japan time.
The only times that allow everyone in the time zones above sleep/private time in the 12am-6am time window (wherever they are) are a conf call 9am-10am EST or one at 5-6pm EST.

If we cannot agree on a time, we have to use a rotating schedule that inevitably disadvantages some considerably, since putting some people in the "middle of the night" block.

My suggested times are below.

a) The table below shows how different times impact different participants
         PST    EST  Paris  Japan
#A:     2p     5p     11p    7a
#B:     6a     9a        3p    11p
#C:     8a   11a        5p     1a 

b) Suggested schedule (all calls at most one hour):
Tue Dec 9th:     9-10am EST {Schedule #B above (Thomas indicated he would be in Europe then, so "West Coast" represented on otherwise "decent" hours)}
Tue Dec 16th:   5-6pm EST   {Schedule #A above}
Tue Jan 6th:      5-6pm EST {Schedule #A above}
Wed Jan 14th: 11am-12pm EST {Schedule #C above; week of IEEE 802 (most likely, Yoshi in Atlanta then, so no "night owls" required)}
NOTE: the last date is a WEDNESDAY, since that is an IEEE week, where Wed am2 is the mid-week plenary (hence, picking the time in that block)

*Please confirm availability at these times via the Doodle link by end of *tomorrow*, Friday December 5, 2014, 11:59pm EST*
{The Doodle poll simply mentions the times above, and you can indicate Yes/No/Maybe for each of the dates}

Please be mindful of others than yourself, whose biological clock we should also take into account.

If you have comments, please do *not* pollute the 6tisch mailing list, but just send a private note, *keeping the same subject title* of the email.
If you already ventilated opinions, please send those again, with the *same* subject header as this email.

http://doodle.com/2cg4p34x3c3uca55

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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------050908070402050904040803-- From nobody Mon Dec 8 07:46:12 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC53E1A6FFE for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 07:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyOft59HVpRW for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 07:46:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 D3C0E1A8776 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 07:46:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB8Fk5hK001358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Dec 2014 17:46:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB8Fk5Qw005356; Mon, 8 Dec 2014 17:46:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21637.51132.993739.691771@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2014 17:46:04 +0200 From: Tero Kivinen To: Rene Struik In-Reply-To: <5485B5D2.8010401@gmail.com> References: <5480D2E0.4070300@gmail.com> <5485B5D2.8010401@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 8 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/8dKo1fOWPrqpO-xBOXGw2PH1KbA Cc: tisch-security <6tisch-security@ietf.org> Subject: [6tisch-security] Please mark your calendar: schedule 6tisch security calls through Jan 15th, 2015 X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 15:46:12 -0000 Rene Struik writes: > Dear colleagues: >=20 > The (rotating) schedule for the next few 6tisch security calls is as = follows: >=20 > Tue Dec 9th: =A0=A0=A0 9-10am EST Ah, I assumed this weeks call would be at the same time as last week, and as it moved to be that early, I most likely will not make it (i.e. I am still in car on my way back from my boat). If I be back on time (it depends how long my discussions there will take) I will call in, but most likely I will not be back on time. Those midnight - 1am calls are much easier for me to participate, as there usually aren't that much other things to consider at that times (except other teleconferences, like the 2 weekly BRC calls at midnigh :-) Btw, I just uploaded the new version of my 802.15.4 maintenance BRC call document to the mentor, and that version now has new version of the inbound state machine. The document can be found from https://mentor.ieee.org/802.15/documents=3Fis=5Fdcn=3D704&is=5Fgroup=3D= 0mag and if I have time, I will also make the actual state diagrams for the state machines before my midnight BRC call, so the revision might be 1 or 2...=20 --=20 kivinen@iki.fi From nobody Mon Dec 8 10:56:09 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1B21ACD8E for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 10:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q8lWQFIp4pf for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 10:56:06 -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 597DE1ACD9A for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 10:56:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B62D200A7 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 13:59:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0E49F637F6; Mon, 8 Dec 2014 13:56:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E8476637F4 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 13:56:03 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org In-Reply-To: <1002236033.2441698.1417140443412.JavaMail.zimbra@purplestreak.com> References: <8798.1417133396@sandelman.ca> <1002236033.2441698.1417140443412.JavaMail.zimbra@purplestreak.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/eSDzrF-u7teNoysbcDGmvefL4Lw Subject: [6tisch-security] 6tisch-security meeting connection information X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:56:08 -0000 --=-=-= The meetings have been moved from 11am EST (16:00 UTC) to 9am EST (14:00UTC). {6am PST} English : New York Time 6tisch security Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 The etherpad we have used is at: http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt The time for the meeting will alternate morning/evening in time according to a schedule which I believe puts it at 17:00 EST (22:00 UTC) on Dec. 16. An agenda to follow. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIX0QICLcPvd0N1lAQLSGQgAg4gB8/VVqeh4PPRMU65ivBXRvY9TrHzn 1WKVrF1ty7i7PQzktTOoF6fUobd0xN1FmqsUi/RcbkuP93eh7kgXmfbQau5xOwVy qe0HFNea75wZehEwt9k6/YGOecS3pYtGlJCISexVNi7iM03O/FYxEB3gLyw4vC7+ C9xdH9Atfq7qssulnn43DjufX6QlkqRY329u6jKmoI6+z2Cu5cEuq6BKc6RaPGDn aGVTOpn27bUq8JQFCT+/53VnI4P2lmjvNxXeNR6OYqqRf3HDtTAR2WVhlE5GSWeQ zGFOcdgydRWqnt2bV6ZA6ho2ly9vf/kV3yCMCaUcJBRVAKmK96xkqg== =Grqe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 8 11:34:06 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1761ACDF5; Mon, 8 Dec 2014 11:34:00 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBg8pkeudEbY; Mon, 8 Dec 2014 11:33:52 -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 670901ACDF1; Mon, 8 Dec 2014 11:33:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BA602200A7; Mon, 8 Dec 2014 14:37:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6973F637F5; Mon, 8 Dec 2014 14:33:28 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F0CB63745; Mon, 8 Dec 2014 14:33:28 -0500 (EST) From: Michael Richardson To: "Hilarie Orman" In-Reply-To: <201412081833.sB8IXd8Q004508@sylvester.rhmr.com> References: <201412081833.sB8IXd8Q004508@sylvester.rhmr.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/OJ9mflwG-reK9wNaAfzfV7jKlus Cc: 6tisch-security@ietf.org, secdir@ietf.org Subject: Re: [6tisch-security] Comments on draft-richardson-6tisch--security-6top-04.txt X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:34:00 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= re: https://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8 Hilarie Orman wrote: > A minor issue with the protocol is the encryption with a well-known > key. This serves no security purpose, but it allows traffic filtering > to keep the traffic on the special Join Network separate from the > regular network. That confuses me --- surely some packet marker would > be better for filtering than encryption would? sadly, 802.15.4 lacks both the SNAP header, and even such a thing as an ethertype. But, we have decided to dispense with this in a new revision. > Another confusing point is step 1B "send router solicitation". I'm > not sure what destination address is in this. Perhaps the beacon > provides the information for use by the joining node. IPv6 router solicitations are multicast, so it does not need to know a place to send it. > It seems clear that the initial communication must have mutual > authentication. I'd expect the joining node to start with a signed > join request, and nothing would proceed further until the JCE found > the device ID in its access list and decided to proceed with > further authentication. The joining node should not communicate > further until it has some reason to believe it is on the correct > network. The intent is that the device ID travels up the network to the JCE, just as you said, and that the device stays silent until the JCE see it. You are suggesting that the new device sign it's ID. Can you explain the value of that? (The exact way in which the device ID travels up has changed several times. We believed that we could use an extended ARO in the IPv6 Neighbour discovery which is part of 6lowpan, but we are having some doubts) > Even with that change, there is always the possibility of a malicious > relay node-in-the-middle. It could cause the joining node to > communicate with a very distant instance of the correct network, for > example. This might violate some proximity assumptions. The > malicious node could arbitrarily block communication and cause > unintended behavior of the network. Yes, so in draft-ietf-roll-security-threats (in AUTH48) this is called a wormhole attack. It's unclear how this situation is different than (intentionally) having a really good antenna, but I agree it is a concern. --=-=-= Content-Disposition: inline Content-Description: Signature -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIX9BYCLcPvd0N1lAQLkwgf/b9YntU0yFusD8evyGGpkd/7OOfy2NYsG bUB1jKb1yUdbAJmbIfuyX5wWjMGE0TJobqAy2aYQgOOhJdIodYNqb5X2nlcDTnM6 erny6t8b/uDC3iRfZpPYumGQ6X/NJi45Epb+dv1wkYUQa87y2ie5KGOXSbNMwtWr fziQbekaJj77R0aRIlnx+gzuYqPG4arCgglln201xScXJ/5CST4cmJ1LvIxCLNUU iiM+nEaWgOAUgJSxCRmt2WZpxUGW7z1zMxvPrdV++eash8DGDJXAvOzoHz/kGXtD z+oz3kLSsejB6vG0r/8mnYanE7uA3MJkWkDUXsUbVQL8xN97QXy02Q== =H79t -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Dec 8 11:49:07 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF461ACDAA for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 10:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_w4GAYqg_ev for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 10:50:53 -0800 (PST) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D861ACD9A for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 10:50:53 -0800 (PST) Received: from jva2tc103.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-2.webex.com [64.68.121.237]) by sjmda11.webex.com (Postfix) with ESMTP id E4D60C0478 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 18:50:52 +0000 (GMT) Received: from jva2tc103.webex.com (localhost [127.0.0.1]) by jva2tc103.webex.com (Postfix) with ESMTP id 96A517FD24 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 18:50:52 +0000 (GMT) Date: Mon, 8 Dec 2014 18:50:52 +0000 (GMT) From: Michael Richardson To: 6tisch-security@ietf.org Message-ID: <2129734853.105501.1418064652614.JavaMail.nobody@jva2tc103.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_105499_293800166.1418064652613" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Tp6XQNB-19ZU8OLI4xSzS9slq6s X-Mailman-Approved-At: Mon, 08 Dec 2014 11:49:06 -0800 Subject: [6tisch-security] WebEx meeting rescheduled: 6tisch security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:50:55 -0000 ------=_Part_105499_293800166.1418064652613 Content-Type: multipart/Alternative; boundary="----=_Part_105500_834485509.1418064652613" ------=_Part_105500_834485509.1418064652613 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGNoYW5nZWQgdGhlIHRpbWUgZm9yIHRoaXMgV2Vi RXggbWVldGluZy4KCgo2dGlzY2ggc2VjdXJpdHkKRXZlcnkgVHVlc2RheSwgZnJvbSBUdWVzZGF5 LCBEZWNlbWJlciA5LCAyMDE0LCB0byBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1Cjk6MDAgYW0g IHwgIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkgIHwgIDEgaHIK CgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bTRmYWJkZmNhZTFlYjk5NjMyNzIyNGI2YTI4NjNmNzEyCk1lZXRpbmcgbnVtYmVyOiA2NDEg NzA5IDExOApNZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pbgoKDQpKT0lOIEJZIFBIT05FDQoxLTg3 Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3 OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0MSA3 MDkgMTE4CgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4 LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0 byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t MzdmZTg5ZDg2NGRhOWM3NmNkYjUzODdlNjAxZGEwYWUNCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRp bmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMK CgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uCg== ------=_Part_105500_834485509.1418064652613 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gY2hhbmdlZCB0aGUgdGltZSBmb3IgdGhpcyBXZWJFeCBtZWV0aW5nLgog ICAgICAgICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoK Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6 MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUi PgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0 RDRENEQiPgoJCQkJCQkJCQk8Yj42dGlzY2ggc2VjdXJpdHk8L2I+CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD5FdmVy eSBUdWVzZGF5LCBmcm9tIFR1ZXNkYXksIERlY2VtYmVyIDksIDIwMTQsIHRvIFR1ZXNkYXksIEph bnVhcnkgMjcsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0ciBzdHls ZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjk6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7RWFzdGVybiBTdGFuZGFyZCBUaW1lIChOZXcgWW9yaywgR01ULTA1OjAwKSZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDsxIGhyCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFi bGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9Indp ZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQg c3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNGZhYmRmY2FlMWViOTk2MzI3 MjI0YjZhMjg2M2Y3MTIiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9u dC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1lZXRp bmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFu dCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFk ZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQkJPHRkPjY0MSA3MDkgMTE4CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIHBh c3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPmpvaW5qb2luPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQg c3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0 ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwt aW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBj b2RlOiZuYnNwOzY0MSA3MDkgMTE4PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk PjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAw QUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJs ZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9 ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tMzdmZTg5ZDg2NGRhOWM3NmNkYjUzODdlNjAxZGEwYWUiIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVl dGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250 LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAg Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAg ICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRh YmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4 Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJ CQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90 cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_105500_834485509.1418064652613-- ------=_Part_105499_293800166.1418064652613 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEyMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEyMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnCk9SR0FO SVpFUjtDTj0iTWljaGFlbCBSaWNoYXJkc29uIjpNQUlMVE86bWNyK25vbWNvbUBzYW5kZWxtYW4u Y2EKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjA5VDA5MDAwMApEVEVORDtUWklE PSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjA5VDEwMDAwMApSUlVMRTpGUkVRPVdFRUtMWTtJTlRFUlZB TD0xO0JZREFZPVRVO0NPVU5UPTgKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MgpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4wNDU2 NjgwLTMxMjA3MzU1Ny1TVT1pZXRmCkRUU1RBTVA6MjAxNDEyMDlUMTQwMDAwWgpERVNDUklQVElP TjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW00ZmFiZGZjYWUxZWI5OTYzMjcyMjRiNmEyODYzZjcxMlxuTWVldGluZyBudW1i ZXI6IDY0MSA3MDkgMTE4XG5NZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pblxuXG5cbkpPSU4gQlkg UEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRh KSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2Vz cyBjb2RlOiA2NDEgNzA5IDExOFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxu aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5c bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10 ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJ WkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tNGZhYmRmY2FlMWViOTk2MzI3MjI0YjZhMjg2M2Y3MTIiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJ CTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj42NDEgNzA5IDExODwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPmpvaW5qb2luPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJS PjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2 OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEp PC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MSA3MDkgMTE4PC9GT05UPiZuYnNw OyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0 aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9s bC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+ PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNw OzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFO VCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRp byBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVj b3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpv aW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48 L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOjZ0aXNjaCBzZWN1cml0eQpQUklPUklUWTo1CkNMQVNTOlBV QkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQxME0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJ T046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_105499_293800166.1418064652613-- From nobody Mon Dec 8 14:16:47 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE991ACFFE for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 14:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g20jSpQLjkXY for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 14:16:44 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969981ACFFA for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 14:16:43 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so5407710ieb.21 for <6tisch-security@ietf.org>; Mon, 08 Dec 2014 14:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=JwGGbux+R+foXGyiqXCLl+V50C3PN9c4gKg3H46uF6g=; b=s/VHFkoGRlc4b5b4HkDsbjb9Fwqssdb+cyAvUHdJ7U6jaL7Lr1PXMaBYXYhllLjpT6 wfemU1sN5a1v/M5A2C4j1upZy8Nk76RTgxJPybT+er3zvk64L2biqdpfuzT/hA1+oV+l chjHUZeU4FeOWCJq5IoHpgTgyrn8KLz0LXRYWReQ/Ojh3JOwZ1QRfAU9ps/54lJHeRPA ipYnUa6R5yPFeLD5zOb4vPps++fT6wRweKWOwl/bP5wYGqLb2Dagp+4KOUL7/Cbcp8oH rCqKBdywj+28E+zHUf8By6qfXqolXeiHlx8Or/FsbBxacLw6ndsUFxDXUsOYsvkUNSU6 Xkng== X-Received: by 10.107.11.195 with SMTP id 64mr11010787iol.51.1418077002744; Mon, 08 Dec 2014 14:16:42 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id 126sm10046007ion.12.2014.12.08.14.16.42 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 14:16:42 -0800 (PST) Message-ID: <54862348.4020909@gmail.com> Date: Mon, 08 Dec 2014 17:16:40 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary="------------070705060709030103080602" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/21qofGJt2sz81ecbwLFz0Q7OpPA Subject: [6tisch-security] suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom) X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 22:16:46 -0000 This is a multi-part message in MIME format. --------------070705060709030103080602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now. This leads to the following suggested agenda for this week (essentially a continuation of last week's one): Same as last week's, except with #1a-b) focus on routing/communication flow related aspects join protocol; #2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects #2c) {as consequence of two items above} what to squeeze into architecture draft The detailed agenda and dial-in info is below (#A, resp. #B). Best regards, Rene _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_ Proposed agenda: 0) Agenda bashing 1) Join protocol details a) desired properties b) realizable properties #1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST). For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call) Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf)) 2) Next steps: a) consensus on 1#a and 1#b #2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects #2c) {as consequence of two items above} what to squeeze into architecture draft b) form tiger team to work out details - project phases - communication of sub-results c) what to squeeze into architecture draft, etc. I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call. _B) Dial-in information:_ English : New York Time 6tisch security Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 The etherpad we have used is at: http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------070705060709030103080602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

A) Suggested agenda Tue Dec 9, 2014, 9am EST call

Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties

#1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST).
For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call)
Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf))
2) Next steps:
        a) consensus on 1#a and 1#b
#2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------070705060709030103080602-- From nobody Mon Dec 8 15:09:19 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2571A004C for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 15:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.899, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRAzR1vlFxX8 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 15:09:14 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6473F1A0086 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 15:09:14 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so3697996igd.1 for <6tisch-security@ietf.org>; Mon, 08 Dec 2014 15:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type; bh=wDggNg4lpbsXpP2sklRaD6PpZAZhoCI8KTFY6aexcGw=; b=UvyI1C9nCof7ivwgKY8w1ydsCnikl6vqf6tnqbFY8WLu4MOy9OHj02b1PIfF6E5wy5 GhyD0bX3NSCEt6syt+LvmA65ZANxDaOYMyMmjDhrc9bwGXVQCfY3/N7mRS2rV/H2rRB6 1LxOkimqtuDsWobSSkXcPO+/ujbuBH0QuE5GQKDXtxDdwvlu3kueLqQSWDWrur17U0OB Y8TMsJaRLuZyW3eCrY5ULIk8V4zSiuwlQTGwWDo695mQ5rJ5bMICC+3Egycpf584h+D0 v8rq8zgL8RUBkZhGxeKnDTA/QG48SxvtqbulVcoq8rwzR8vQOKhfAWefnI4MUXos5hRr tjlQ== X-Received: by 10.50.50.196 with SMTP id e4mr17347083igo.26.1418080153432; Mon, 08 Dec 2014 15:09:13 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id c62sm21255229ioe.22.2014.12.08.15.09.12 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 15:09:12 -0800 (PST) Message-ID: <54862F96.5040508@gmail.com> Date: Mon, 08 Dec 2014 18:09:10 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 CC: 6tisch-security@ietf.org References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> In-Reply-To: <547C9D91.4010400@gmail.com> Content-Type: multipart/alternative; boundary="------------000404010402030305050400" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/aYWKbUriYDjp8dq-gU1dx5p9i1Q Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:09:17 -0000 This is a multi-part message in MIME format. --------------000404010402030305050400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues: Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST. Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST {note taker: Rene Struik} {recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} {slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} 1. Attendance: Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik 2. Agenda The suggested agend was approved. 3. Join process - desirable vs. realizable properties RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this would be a plus. After asking, there was no further discussion on properties listed. 4. Join process - MAC behavior. RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22). PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call. PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use. 5. Join process - non-MAC behavior. Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call. 6. AOB Conf call scheduling. SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule. Best regards, Rene On 12/1/2014 11:55 AM, Rene Struik wrote: > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and 2), to be > discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: >> >> Dear colleagues: >> >> >> I have set up a conf call for Tuesday December 2, 2014 at a time that >> tries and accommodate people in different time zones to the largest >> extent possible, without trying to discriminate against various parts >> of the world. >> >> >> Please see dial-in information below. >> >> >> Agenda to follow Monday around noon. >> >> >> Looking forward to a collaborative meeting, in good spirit. >> >> >> Best regards, Rene >> >> == >> >> >> 1.Please join my meeting. >> >> https://global.gotomeeting.com/join/594299061 >> >> 2.Use your microphone and speakers (VoIP) - a headset is >> recommended.Or, call in using your telephone. >> >> Dial +1 (647) 497-9351 >> >> Access Code: 594-299-061 >> >> Audio PIN: Shown after joining the meeting >> >> Meeting Password: collaborate >> >> Meeting ID: 594-299-061 >> >> GoToMeeting® >> >> Online Meetings Made Easy® >> >> Not at your computer? Click the link to join this meeting from your >> iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting >> app. >> >> >> >> >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should >> allow people to have their private time in the 12am-6am time window. >> {Other groups do a much better job at this...} >> >> >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >>> Subir Das wrote: >>> > Thanks for arranging the calls. It would be good to accommodate Asian time >>> > zone for broader participation. I would suggest choosing a time that is >>> >>> I'm happy to do this at another time; the original choice of 11am Eastern was >>> to accomodate Pacific Time Zone People who couldn't meet before 8am. >>> >>> From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >>> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >>> or >>> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >>> >>> I am also happy to alternate. >>> Shall I put up a doodle poll? >>> >>> >>> >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000404010402030305050400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:
Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

==


1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


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

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

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

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




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



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


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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------000404010402030305050400-- From nobody Mon Dec 8 16:03:46 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 3798E1A1A2A for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 16:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] 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 wLFGaP7f-Qv9 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 16:03:26 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9D91A03A5 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 16:03:25 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sB903LIX000138; Tue, 9 Dec 2014 09:03:21 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sB903Kqm017772; Tue, 9 Dec 2014 09:03:20 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA17765; Tue, 9 Dec 2014 09:03:20 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sB903JUF011243; Tue, 9 Dec 2014 09:03:19 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id sB903IFa008218; Tue, 9 Dec 2014 09:03:19 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 09:03:18 +0900 From: To: Thread-Topic: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan Thread-Index: AQHQEzwCeswFS0vjcEirSrRRdThK4ZyGXR8Q Date: Tue, 9 Dec 2014 00:03:17 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> In-Reply-To: <54862F96.5040508@gmail.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.221] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B29D0E91DTGXML210toshiba_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/GXdA79y9PrAdzSEQQitc47dhbsA Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 00:03:30 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B29D0E91DTGXML210toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Rene, I would like to double check the meaning of =1B$B!H=1B(Bexempt status=1B$B!= I=1B(B. I thought the =1B$B!H=1B(Bexempt status=1B$B!I=1B(B is maintained = by higher layer and is different from the =1B$B!H=1B(BExempt=1B$B!I=1B(B fl= ag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes. I am asking this because, while the =1B$B!H=1B(BExempt=1B$B!I=1B(B flag of = 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows un= secured frames to be passed to higher layer, the flag solely does not help = for joining node=1B$B!G=1B(Bs higher layer to process authenticated-only se= cured beacons. Yoshihiro Ohba From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Rene Struik Sent: Tuesday, December 9, 2014 8:09 AM Cc: 6tisch-security@ietf.org Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (= now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, = 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan Dear colleagues: Please find below the minutes of the 6TiSCH Security conf call as of Decemb= er 2, 2014, 9am EST. Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST {note taker: Rene Struik} {recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/vi= ew?usp=3Dsharing} {slides discussed (and referenced in minutes): https://drive.google.com/fil= e/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=3Dsharing} 1. Attendance: Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik 2. Agenda The suggested agend was approved. 3. Join process - desirable vs. realizable properties RS went over the desirable properties of the join process (Slide 6). MR rai= sed point that privacy of the device identity of the joining node might not= be required. . SD suggested that it is fine to include privacy in list of = "desiderata"; evaluation metrics might consider these in "grey tones" vs. a= s "black and white" requirement. RS suggested that merit of privacy might d= epend on deployment scenario, but is on the radar in lots of IETF groups (i= n terms of traceability/tracking); if privacy can be easily offered as addi= tional feature, this would be a plus. After asking, there was no further d= iscussion on properties listed. 4. Join process - MAC behavior. RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2= 012 specifications (Slides 19-22). The main premise here was that a recipie= nt device that expects secured traffic, will reject all incoming unsecured = traffic, unless this originates from a device with so-called "exempt status= ". This "exempt status" construct allows receipt of incoming unsecured data= frames from a joining node that does not have network-specific keying mate= rial yet. How to switch on/off this "exempt status" parameter was also disc= ussed (see Slide 20). Furthermore, there was some discussion on how this co= mpares to the use of so-called "default keys" (aka "fake" keys) (see also S= lide 22). PG mentioned that 802.15.4 does not allow the use of the default key. SD su= ggested that an important point in not using default keys is that all incom= ing processing with keys will be treated transparently, irrespective of exc= eptions. RS explained that even if default keys were to be used, this would= mess up local security state (e.g., frame counters), which is not the case= if one would send unsecured traffic and use the "exempt status" construct = instead. PD summarized that using unsecured frames, rather than "fake" secu= rity with "default keys", should be adopted, which was consensus on the cal= l. PG came back to the "exempt flag" topic and suggested that details hereof a= re in the "device descriptor lookup table". RS suggested that we all have a= closer look at specification details, so that switching this feature on/of= f could be easily codified for 6TiSCH use. 5. Join process - non-MAC behavior. Given remaining time on the call would not allow full discussion of non-MAC= aspects (Slides 23-25) and given that MR had to drop off the call, it was = decided to revisit those topics at the next conf call. 6. AOB Conf call scheduling. SD suggested he was confused about having two call times in email traffic (= one at 9am EST and one at 11am EST) and suggested that other groups, such a= s, e.g., IEEE, often use cyclic schedule, so as to accommodate participants= from around the world and who may be at widely different time zones. RS vo= lunteered to look into this topic and obtain feedback on such a schedule. Best regards, Rene On 12/1/2014 11:55 AM, Rene Struik wrote: Proposed agenda: 0) Agenda bashing 1) Join protocol details a) desired properties b) realizable properties 2) Next steps: a) consensus on 1#a and 1#b b) form tiger team to work out details - project phases - communication of sub-results c) what to squeeze into architecture draft, etc. I will prepare material to facilitate discussion on 1) and 2), to be discus= sed during the call. Best regards, Rene On 11/28/2014 11:02 AM, Rene Struik wrote: Dear colleagues: I have set up a conf call for Tuesday December 2, 2014 at a time that tries= and accommodate people in different time zones to the largest extent possi= ble, without trying to discriminate against various parts of the world. Please see dial-in information below. Agenda to follow Monday around noon. Looking forward to a collaborative meeting, in good spirit. Best regards, Rene =3D=3D 1. Please join my meeting. https://global.gotomeeting.com/join/594299061 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or= , call in using your telephone. Dial +1 (647) 497-9351 Access Code: 594-299-061 Audio PIN: Shown after joining the meeting Meeting Password: collaborate Meeting ID: 594-299-061 GoToMeeting(r) Online Meetings Made Easy(r) Not at your computer? Click the link to join this meeting from your iPhone(= r), iPad(r), Android(r) or Windows Phone(r) device via the GoToMeeting app. [excerpt email as of Thu November 27, 2014, 9.42pm EST] I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This should all= ow people to have their private time in the 12am-6am time window. {Other gr= oups do a much better job at this...} On 11/28/2014 10:39 AM, Michael Richardson wrote: Subir Das wrote: > Thanks for arranging the calls. It would be good to accommodate Asian= time > zone for broader participation. I would suggest choosing a time that = is I'm happy to do this at another time; the original choice of 11am Eastern w= as to accomodate Pacific Time Zone People who couldn't meet before 8am. >From long experience, our choices essentially are at 15:00 UTC or 03:00 UT= C. 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing or 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing I am also happy to alternate. Shall I put up a doodle poll? _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_674F70E5F2BE564CB06B6901FD3DD78B29D0E91DTGXML210toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Rene,

 

I would like to double check the meaning of =1B$B!H=1B(Bexempt st= atus=1B$B!I=1B(B.  I thought the =1B$B!H=1B(Bexempt status=1B$B!I=1B(B= is maintained by higher layer and is different from the =1B$B!H=1B(BExempt= =1B$B!I=1B(B flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the =1B$B!H=1B(BExempt=1B$B!I=1B(= B flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes= allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node=1B$B!G=1B(Bs higher layer to process= authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: = 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call= ) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2,= 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of Decemb= er 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=3Dsha= ring}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=3Dsha= ring}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR rai= sed point that privacy of the device identity of the joining node might not= be required. . SD suggested that it is fine to include privacy in list of = "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and whit= e" requirement. RS suggested that merit of privacy might depend on dep= loyment scenario, but is on the radar in lots of IETF groups (in terms of t= raceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was= no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2= 012 specifications (Slides 19-22). The main premise here was that a recipie= nt device that expects secured traffic, will reject all incoming unsecured = traffic, unless this originates from a device with so-called "exempt status". This "exempt = status" construct allows receipt of incoming unsecured data frames fro= m a joining node that does not have network-specific keying material yet. H= ow to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on h= ow this compares to the use of so-called "default keys" (aka &quo= t;fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD su= ggested that an important point in not using default keys is that all incom= ing processing with keys will be treated transparently, irrespective of exc= eptions. RS explained that even if default keys were to be used, this would mess up local security state (= e.g., frame counters), which is not the case if one would send unsecured tr= affic and use the "exempt status" construct instead. PD summarize= d that using unsecured frames, rather than "fake" security with "default keys", should be adopted= , which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that detail= s hereof are in the "device descriptor lookup table". RS suggeste= d that we all have a closer look at specification details, so that switchin= g this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC= aspects (Slides 23-25) and given that MR had to drop off the call, it was = decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (= one at 9am EST and one at 11am EST) and suggested that other groups, such a= s, e.g., IEEE, often use cyclic schedule, so as to accommodate participants= from around the world and who may be at widely different time zones. RS volunteered to look into this topic = and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired properties
b) realizable properties

2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out d= etails
            - project phases             - communication of= sub-results
        c) what to squeeze into architecture = draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discus= sed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

D= ear colleagues:

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

<= br> Please see dial-in information below.

<= br> Agenda to follow Monday around noon.=

<= br> Looking forward to a collaborative meeting, in good spirit.

 

B= est regards, Rene

= =3D=3D

 

1= .  Please join my meeting.

<= a href=3D"https://global.gotomeeting.com/join/594299061">https://global.got= omeeting.com/join/594299061

&= nbsp;

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

&= nbsp;

D= ial +1 (647) 497-9351

A= ccess Code: 594-299-061

A= udio PIN: Shown after joining the meeting<= /o:p>

&= nbsp;

M= eeting Password: collaborate<= /p>

M= eeting ID: 594-299-061

&= nbsp;

G= oToMeeting®

O= nline Meetings Made Easy®=

&= nbsp;

N= ot at your computer? Click the link to join this meeting from your iPhone&r= eg;, iPad®, Android® or Windows Phone® device via the GoToMeeti= ng app.




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the =
calls. It would be good to accommodate Asian time
    > zone for broader particip=
ation. I would suggest choosing a time that is
 
I'm happy to do this at another time; the origina=
l choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn=
't meet before 8am.  
 
>From long experience, our choices essentially=
 are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / =
17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / =
05:00 Helsinki/10:00 Beijing
 
I am also happy to alternate.

Shall I put up a doodle poll?

 











_______________________________________________


6tisch-security mailing list

6tisc=
h-security@ietf.org


https://www.ietf.org/mailman/listinfo/6tisch-security<=
o:p>






-- 
email: r=
struik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 69=
0-7363




-- 
email: r=
struik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 69=
0-7363




-- 
email: r=
struik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 69=
0-7363
--_000_674F70E5F2BE564CB06B6901FD3DD78B29D0E91DTGXML210toshiba_-- From nobody Mon Dec 8 17:49:09 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D421A1AA2 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 17:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 fkh3-N8-_B4D for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 17:48:59 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5051B1A1A69 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 17:48:59 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so5684237ier.27 for <6tisch-security@ietf.org>; Mon, 08 Dec 2014 17:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=vXZvNAEnNJch4aPVIbctoH+gRCDU4pW5/baDzHoTDAA=; b=cAtEh3skOsVmfWGQM9HtI8Ec80+m7NjkFma0kQcARk/be0YFMSz29BMF3Fmq5Z/Hsw aYug0bkzI/TxBQxvdjuCv5z9Zv3dA4TxViey660EuCr1vO9e/+ulrqR0ZHCj/E1Vae7o JHgg9gSQihI6nQzBdbC0a0zf8FYAlDczmkU1QO3GV8K7l/+MdAQEtJJ3blIrA01ny2V1 WVYc21bPNQthIunGDwLid0AAceCWnSpZbNjZZefyO7Ez5VYFu2+otf61ER2HCOVJongz 7eAi/xJlhHM8o9dKQjlXd/m1kX6qFYyW0FWSoLVT+m5WC0tBT+DgUK6/0vDLPz5LTS6Y eQAw== X-Received: by 10.42.39.6 with SMTP id f6mr153342ice.14.1418089738203; Mon, 08 Dec 2014 17:48:58 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id c62sm21456760ioe.22.2014.12.08.17.48.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 17:48:57 -0800 (PST) Message-ID: <54865507.6080609@gmail.com> Date: Mon, 08 Dec 2014 20:48:55 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> Content-Type: multipart/alternative; boundary="------------020703000408050003090008" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/asyp9XuP8j4nJVoR3MJyMP7QSCs Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 01:49:03 -0000 This is a multi-part message in MIME format. --------------020703000408050003090008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yoshi: Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]). The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then). With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior: If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3. The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error. I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011. Best regards, Rene On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote: > > Hi Rene, > > I would like to double check the meaning of “exempt statusâ€. I > thought the “exempt status†is maintained by higher layer and is > different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of > Security-related PIB attributes. > > I am asking this because, while the “Exempt†flag of 802.15.4-2011 > DeviceDescriptor of Security-related PIB attributes allows unsecured > frames to be passed to higher layer, the flag solely does not help for > joining node’s higher layer to process authenticated-only secured beacons. > > Yoshihiro Ohba > > *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org] *On > Behalf Of *Rene Struik > *Sent:* Tuesday, December 9, 2014 8:09 AM > *Cc:* 6tisch-security@ietf.org > *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST > call) Re: (now with agenda) Re: invite for 6tisch security call Tue > December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan > > Dear colleagues: > > Please find below the minutes of the 6TiSCH Security conf call as of > December 2, 2014, 9am EST. > > Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST > {note taker: Rene Struik} > {recording: > https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} > {slides discussed (and referenced in minutes): > https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} > > 1. Attendance: > Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik > > 2. Agenda > The suggested agend was approved. > > 3. Join process - desirable vs. realizable properties > RS went over the desirable properties of the join process (Slide 6). > MR raised point that privacy of the device identity of the joining > node might not be required. . SD suggested that it is fine to include > privacy in list of "desiderata"; evaluation metrics might consider > these in "grey tones" vs. as "black and white" requirement. RS > suggested that merit of privacy might depend on deployment scenario, > but is on the radar in lots of IETF groups (in terms of > traceability/tracking); if privacy can be easily offered as additional > feature, this would be a plus. After asking, there was no further > discussion on properties listed. > > 4. Join process - MAC behavior. > RS went over some MAC security aspects of the 802.15.4-2011 and > 802.15.4e-2012 specifications (Slides 19-22). The main premise here > was that a recipient device that expects secured traffic, will reject > all incoming unsecured traffic, unless this originates from a device > with so-called "exempt status". This "exempt status" construct allows > receipt of incoming unsecured data frames from a joining node that > does not have network-specific keying material yet. How to switch > on/off this "exempt status" parameter was also discussed (see Slide > 20). Furthermore, there was some discussion on how this compares to > the use of so-called "default keys" (aka "fake" keys) (see also Slide 22). > > PG mentioned that 802.15.4 does not allow the use of the default key. > SD suggested that an important point in not using default keys is that > all incoming processing with keys will be treated transparently, > irrespective of exceptions. RS explained that even if default keys > were to be used, this would mess up local security state (e.g., frame > counters), which is not the case if one would send unsecured traffic > and use the "exempt status" construct instead. PD summarized that > using unsecured frames, rather than "fake" security with "default > keys", should be adopted, which was consensus on the call. > > PG came back to the "exempt flag" topic and suggested that details > hereof are in the "device descriptor lookup table". RS suggested that > we all have a closer look at specification details, so that switching > this feature on/off could be easily codified for 6TiSCH use. > > 5. Join process - non-MAC behavior. > Given remaining time on the call would not allow full discussion of > non-MAC aspects (Slides 23-25) and given that MR had to drop off the > call, it was decided to revisit those topics at the next conf call. > > 6. AOB Conf call scheduling. > SD suggested he was confused about having two call times in email > traffic (one at 9am EST and one at 11am EST) and suggested that other > groups, such as, e.g., IEEE, often use cyclic schedule, so as to > accommodate participants from around the world and who may be at > widely different time zones. RS volunteered to look into this topic > and obtain feedback on such a schedule. > > Best regards, Rene > > On 12/1/2014 11:55 AM, Rene Struik wrote: > > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and 2), to > be discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: > > Dear colleagues: > > > I have set up a conf call for Tuesday December 2, 2014 at a > time that tries and accommodate people in different time zones > to the largest extent possible, without trying to discriminate > against various parts of the world. > > > Please see dial-in information below. > > > Agenda to follow Monday around noon. > > > Looking forward to a collaborative meeting, in good spirit. > > Best regards, Rene > > == > > 1. Please join my meeting. > > https://global.gotomeeting.com/join/594299061 > > 2. Use your microphone and speakers (VoIP) - a headset is > recommended. Or, call in using your telephone. > > Dial +1 (647) 497-9351 > > Access Code: 594-299-061 > > Audio PIN: Shown after joining the meeting > > Meeting Password: collaborate > > Meeting ID: 594-299-061 > > GoToMeeting® > > Online Meetings Made Easy® > > Not at your computer? Click the link to join this meeting from > your iPhone®, iPad®, Android® or Windows Phone® device via the > GoToMeeting app. > > > > > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This > should allow people to have their private time in the 12am-6am > time window. {Other groups do a much better job at this...} > > > On 11/28/2014 10:39 AM, Michael Richardson wrote: > > Subir Das wrote: > > > Thanks for arranging the calls. It would be good to accommodate Asian time > > > zone for broader participation. I would suggest choosing a time that is > > > > I'm happy to do this at another time; the original choice of 11am Eastern was > > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > > > >From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. > > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > > or > > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > > > I am also happy to alternate. > > Shall I put up a doodle poll? > > > > > > > _______________________________________________ > > 6tisch-security mailing list > > 6tisch-security@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch-security > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020703000408050003090008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:
If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of “exempt statusâ€.  I thought the “exempt status†is maintained by higher layer and is different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node’s higher layer to process authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired properties
b) realizable properties

2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

==

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate Asian time
    > zone for broader participation. I would suggest choosing a time that is
 
I'm happy to do this at another time; the original choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.  
 
>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
 
I am also happy to alternate.
Shall I put up a doodle poll?
 




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




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




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




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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020703000408050003090008-- From nobody Mon Dec 8 18:00: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 800EF1A0033 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y8aPLwcTGbb for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:00:39 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FA61A02F1 for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 18:00:38 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so150150igb.17 for <6tisch-security@ietf.org>; Mon, 08 Dec 2014 18:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=YM0R7u8Kh8OVLD1P8LIJPdIGxAMi8VHGVsin89kgves=; b=hqHxIuY7wKlKUtG5IWEUTe442JDfaX3BUeGaBwHcpe4Td9ZXpKfIoENarf8Y/vYEc5 D8rJLKxGym84unVi82os3c+J9HVVGQB4xCkf3Z7OXSreD18HGPSiPCimZQiTfbWb7huh MSdSPDyQSzAIJmLI7xM1JX4R/CPJmmyr87vXAnz1IuMnZn2ijXInvL4OswrfinT7M3Ir Lnwv/GN5ksBmDpptiHUtBJBpk8o3ozRLcG0DVMohWt/tzZTMi+79f4haYwMakqGDu4fa BN0TfjRwd2KhaPB/brYUp0RhSOjUUAwC5bxmpnE9kHJAFxvWl3/RSsk8cTv0vdMkkjQu LjDw== X-Received: by 10.50.30.33 with SMTP id p1mr222235igh.22.1418090437970; Mon, 08 Dec 2014 18:00:37 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id mx10sm4774583igb.21.2014.12.08.18.00.37 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 18:00:37 -0800 (PST) Message-ID: <548657C3.8030308@gmail.com> Date: Mon, 08 Dec 2014 21:00:35 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <54862F96.5040508@gmail.com> In-Reply-To: <54862F96.5040508@gmail.com> X-Forwarded-Message-Id: <54862F96.5040508@gmail.com> Content-Type: multipart/alternative; boundary="------------050707040507050600060702" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/QO_dLDilJTs6d7jY74QTUzR_Zyw Subject: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 02:00:43 -0000 This is a multi-part message in MIME format. --------------050707040507050600060702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear colleagues: Please find below the (corrected) minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST. {Correction re active scan in italics} Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST {note taker: Rene Struik} {recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} {slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} 1. Attendance: Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik 2. Agenda The suggested agend was approved. 3. Join process - desirable vs. realizable properties RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this would be a plus. After asking, there was no further discussion on properties listed. 4. Join process - MAC behavior. RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22). /RS also discussed incoming processing of secured beacon frames (Slide 20), where a device without proper keying material can still extract visible portions of a secured beacon frame, even though it cannot rely on this. This feature is already supported in the 802.15.4-2006 spec as part of the "active scan" specification. {NOTE added (after the call): still to be checked whether this feature was not modified in the 802.15.4-2011 spec or with 802.15.4e-2012}./ PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call. PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use. 5. Join process - non-MAC behavior. Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call. 6. AOB Conf call scheduling. SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule. Best regards, Rene On 12/1/2014 11:55 AM, Rene Struik wrote: > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and 2), to be > discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: >> >> Dear colleagues: >> >> >> I have set up a conf call for Tuesday December 2, 2014 at a time that >> tries and accommodate people in different time zones to the largest >> extent possible, without trying to discriminate against various parts >> of the world. >> >> >> Please see dial-in information below. >> >> >> Agenda to follow Monday around noon. >> >> >> Looking forward to a collaborative meeting, in good spirit. >> >> >> Best regards, Rene >> >> == >> >> >> 1.Please join my meeting. >> >> https://global.gotomeeting.com/join/594299061 >> >> 2.Use your microphone and speakers (VoIP) - a headset is >> recommended.Or, call in using your telephone. >> >> Dial +1 (647) 497-9351 >> >> Access Code: 594-299-061 >> >> Audio PIN: Shown after joining the meeting >> >> Meeting Password: collaborate >> >> Meeting ID: 594-299-061 >> >> GoToMeeting® >> >> Online Meetings Made Easy® >> >> Not at your computer? Click the link to join this meeting from your >> iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting >> app. >> >> >> >> >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should >> allow people to have their private time in the 12am-6am time window. >> {Other groups do a much better job at this...} >> >> >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >>> Subir Das wrote: >>> > Thanks for arranging the calls. It would be good to accommodate Asian time >>> > zone for broader participation. I would suggest choosing a time that is >>> >>> I'm happy to do this at another time; the original choice of 11am Eastern was >>> to accomodate Pacific Time Zone People who couldn't meet before 8am. >>> >>> From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >>> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >>> or >>> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >>> >>> I am also happy to alternate. >>> Shall I put up a doodle poll? >>> >>> >>> >>> _______________________________________________ >>> 6tisch-security mailing list >>> 6tisch-security@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email:rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------050707040507050600060702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear colleagues:

Please find below the (corrected) minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST. {Correction re active scan in italics}

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

RS also discussed incoming processing of secured beacon frames (Slide 20), where a device without proper keying material can still extract visible portions of a secured beacon frame, even though it cannot rely on this. This feature is already supported in the 802.15.4-2006 spec as part of the "active scan" specification. {NOTE added (after the call): still to be checked whether this feature was not modified in the 802.15.4-2011 spec or with 802.15.4e-2012}.

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:
Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

==


1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


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

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

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

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




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



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


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


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


--------------050707040507050600060702-- From nobody Mon Dec 8 18:21:46 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 D46A51A0373 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 i-MEoVD9sxGS for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:21:39 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F111A016A for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 18:21:38 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so5192415igb.0 for <6tisch-security@ietf.org>; Mon, 08 Dec 2014 18:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=i39hGEgUHAH1c6nNY6dwyvjSSeEMWkgZUUwLImyg+Cs=; b=bmpqdRQ9pawJ+PA+MqZD49CyyDL6DQRX3ox9IamhJaJlEROL44S+ME9fLqZ4qud0Bm F+l76MdsluOt0TAzJPo6fBOfKlaRc8QrgUrqEExR5kLOI/X9owT8TRntbiRdACoJddfF Bgf6+vxoV8nkbIsQrpdpVHeRsWbaQmmlFZcTCEPMlXL8NHG4MzjZbgdEcmTU4lWXJeSb Lxtk9FamEVXfY842aofhreoINeGDIgyIH4j9TPufJtmum968CX3b/sEI/5npa/MSOBao w31JUm2ppma/WsoNVgABdqowG+yJROlUoVT/y8NeBVbbodhZ4fjcOM2nS1Vnz4Jgi1xx Uf5w== X-Received: by 10.107.152.13 with SMTP id a13mr14212037ioe.1.1418091697767; Mon, 08 Dec 2014 18:21:37 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id kq9sm214473igb.4.2014.12.08.18.21.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 18:21:37 -0800 (PST) Message-ID: <54865CAE.6030308@gmail.com> Date: Mon, 08 Dec 2014 21:21:34 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> In-Reply-To: <54865507.6080609@gmail.com> Content-Type: multipart/alternative; boundary="------------020108000201000907090108" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ShBUp1804yofMipoIUoho_JQ2pI Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 02:21:43 -0000 This is a multi-part message in MIME format. --------------020108000201000907090108 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yoshi: The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look? Best regards, Rene On 12/8/2014 8:48 PM, Rene Struik wrote: > Hi Yoshi: > > Good point (and I remember we discussed this, while going over Slide > 20, but I forgot to include this in the minutes [I will correct this]). > > The idea is that if a joining device receives a secured beacon frame, > it can still extract the visible portion of the frame, even if it > cannot do proper incoming security processing (obviously, it cannot > really rely on this data at this point, then). > > With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active > Channel Scan), of which the excerpt from p. 174 of the spec describes > the corresponding behavior: > > If a protected beacon frame is received, i.e., the Security > Enabled subfield in the Frame Control field is set to one, the > device shall attempt to unsecure the beacon frame using the > unsecuring process described in 7.5.8.2.3. > The security-related elements of the PAN descriptor corresponding > to the beacon (see Table 55) shall be set to the corresponding > parameters returned by the unsecuring process. The SecurityFailure > element of the PAN descriptor shall be set to SUCCESS if the > status from the unsecuring process is SUCCESS and set to one of > the other status codes indicating an error in the security > processing otherwise. The information from the unsecured frame > shall be recorded in the PAN descriptor even if the status from > the unsecuring process indicated an error. > > I did not check yet whether the later spec 802.15.4-2011 changed this > behavior or whether 802.15.4e-2012 did, but if I remember correctly > the 802.15.4e spec did not modify any of this, so the remaining check > would be 2006 --> 2011. > > Best regards, Rene > > > On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote: >> >> Hi Rene, >> >> I would like to double check the meaning of “exempt statusâ€. I >> thought the “exempt status†is maintained by higher layer and is >> different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of >> Security-related PIB attributes. >> >> I am asking this because, while the “Exempt†flag of 802.15.4-2011 >> DeviceDescriptor of Security-related PIB attributes allows unsecured >> frames to be passed to higher layer, the flag solely does not help >> for joining node’s higher layer to process authenticated-only secured >> beacons. >> >> Yoshihiro Ohba >> >> *From:*6tisch-security [mailto:6tisch-security-bounces@ietf.org] *On >> Behalf Of *Rene Struik >> *Sent:* Tuesday, December 9, 2014 8:09 AM >> *Cc:* 6tisch-security@ietf.org >> *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST >> call) Re: (now with agenda) Re: invite for 6tisch security call Tue >> December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan >> >> Dear colleagues: >> >> Please find below the minutes of the 6TiSCH Security conf call as of >> December 2, 2014, 9am EST. >> >> Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST >> {note taker: Rene Struik} >> {recording: >> https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} >> {slides discussed (and referenced in minutes): >> https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} >> >> 1. Attendance: >> Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik >> >> 2. Agenda >> The suggested agend was approved. >> >> 3. Join process - desirable vs. realizable properties >> RS went over the desirable properties of the join process (Slide 6). >> MR raised point that privacy of the device identity of the joining >> node might not be required. . SD suggested that it is fine to include >> privacy in list of "desiderata"; evaluation metrics might consider >> these in "grey tones" vs. as "black and white" requirement. RS >> suggested that merit of privacy might depend on deployment scenario, >> but is on the radar in lots of IETF groups (in terms of >> traceability/tracking); if privacy can be easily offered as >> additional feature, this would be a plus. After asking, there was no >> further discussion on properties listed. >> >> 4. Join process - MAC behavior. >> RS went over some MAC security aspects of the 802.15.4-2011 and >> 802.15.4e-2012 specifications (Slides 19-22). The main premise here >> was that a recipient device that expects secured traffic, will reject >> all incoming unsecured traffic, unless this originates from a device >> with so-called "exempt status". This "exempt status" construct allows >> receipt of incoming unsecured data frames from a joining node that >> does not have network-specific keying material yet. How to switch >> on/off this "exempt status" parameter was also discussed (see Slide >> 20). Furthermore, there was some discussion on how this compares to >> the use of so-called "default keys" (aka "fake" keys) (see also Slide >> 22). >> >> PG mentioned that 802.15.4 does not allow the use of the default key. >> SD suggested that an important point in not using default keys is >> that all incoming processing with keys will be treated transparently, >> irrespective of exceptions. RS explained that even if default keys >> were to be used, this would mess up local security state (e.g., frame >> counters), which is not the case if one would send unsecured traffic >> and use the "exempt status" construct instead. PD summarized that >> using unsecured frames, rather than "fake" security with "default >> keys", should be adopted, which was consensus on the call. >> >> PG came back to the "exempt flag" topic and suggested that details >> hereof are in the "device descriptor lookup table". RS suggested that >> we all have a closer look at specification details, so that switching >> this feature on/off could be easily codified for 6TiSCH use. >> >> 5. Join process - non-MAC behavior. >> Given remaining time on the call would not allow full discussion of >> non-MAC aspects (Slides 23-25) and given that MR had to drop off the >> call, it was decided to revisit those topics at the next conf call. >> >> 6. AOB Conf call scheduling. >> SD suggested he was confused about having two call times in email >> traffic (one at 9am EST and one at 11am EST) and suggested that other >> groups, such as, e.g., IEEE, often use cyclic schedule, so as to >> accommodate participants from around the world and who may be at >> widely different time zones. RS volunteered to look into this topic >> and obtain feedback on such a schedule. >> >> Best regards, Rene >> >> On 12/1/2014 11:55 AM, Rene Struik wrote: >> >> Proposed agenda: >> >> 0) Agenda bashing >> >> 1) Join protocol details >> >> a) desired properties >> b) realizable properties >> >> 2) Next steps: >> a) consensus on 1#a and 1#b >> b) form tiger team to work out details >> - project phases >> - communication of sub-results >> c) what to squeeze into architecture draft, etc. >> >> I will prepare material to facilitate discussion on 1) and 2), to >> be discussed during the call. >> >> Best regards, Rene >> >> >> On 11/28/2014 11:02 AM, Rene Struik wrote: >> >> Dear colleagues: >> >> >> I have set up a conf call for Tuesday December 2, 2014 at a >> time that tries and accommodate people in different time >> zones to the largest extent possible, without trying to >> discriminate against various parts of the world. >> >> >> Please see dial-in information below. >> >> >> Agenda to follow Monday around noon. >> >> >> Looking forward to a collaborative meeting, in good spirit. >> >> Best regards, Rene >> >> == >> >> 1. Please join my meeting. >> >> https://global.gotomeeting.com/join/594299061 >> >> 2. Use your microphone and speakers (VoIP) - a headset is >> recommended. Or, call in using your telephone. >> >> Dial +1 (647) 497-9351 >> >> Access Code: 594-299-061 >> >> Audio PIN: Shown after joining the meeting >> >> Meeting Password: collaborate >> >> Meeting ID: 594-299-061 >> >> GoToMeeting® >> >> Online Meetings Made Easy® >> >> Not at your computer? Click the link to join this meeting >> from your iPhone®, iPad®, Android® or Windows Phone® device >> via the GoToMeeting app. >> >> >> >> >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This >> should allow people to have their private time in the >> 12am-6am time window. {Other groups do a much better job at >> this...} >> >> >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >> >> Subir Das wrote: >> >> > Thanks for arranging the calls. It would be good to accommodate Asian time >> >> > zone for broader participation. I would suggest choosing a time that is >> >> >> >> I'm happy to do this at another time; the original choice of 11am Eastern was >> >> to accomodate Pacific Time Zone People who couldn't meet before 8am. >> >> >> >> >From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >> >> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >> >> or >> >> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >> >> >> >> I am also happy to alternate. >> >> Shall I put up a doodle poll? >> >> >> >> >> >> >> _______________________________________________ >> >> 6tisch-security mailing list >> >> 6tisch-security@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020108000201000907090108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik wrote:
Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:
If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of “exempt statusâ€.  I thought the “exempt status†is maintained by higher layer and is different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node’s higher layer to process authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired properties
b) realizable properties

2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

==

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate Asian time
    > zone for broader participation. I would suggest choosing a time that is
 
I'm happy to do this at another time; the original choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.  
 
>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
 
I am also happy to alternate.
Shall I put up a doodle poll?
 




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




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




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




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


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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020108000201000907090108-- From nobody Mon Dec 8 18:40:34 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436081A1ADC for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.402 X-Spam-Level: X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apr50wxKusSk for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 18:40:29 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5BB1A00AA for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 18:40:28 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id sB92eOCL012240; Tue, 9 Dec 2014 11:40:24 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id sB92eOWP018984; Tue, 9 Dec 2014 11:40:24 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id MAA18950; Tue, 9 Dec 2014 11:40:23 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id sB92eMfC019480; Tue, 9 Dec 2014 11:40:22 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sB92eFH6009920; Tue, 9 Dec 2014 11:40:15 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 11:40:15 +0900 From: To: , <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] summary of discussions on Tuesday Thread-Index: AQHQEAml7sHvy3YEHkO8JRYfQvUuVJyAYI5wgAYxacA= Date: Tue, 9 Dec 2014 02:40:15 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0EA65@TGXML210.toshiba.local> References: <10894.1417728668@sandelman.ca> <674F70E5F2BE564CB06B6901FD3DD78B29D0DBFA@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D0DBFA@TGXML210.toshiba.local> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.221] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/nC7lUCjcuL7M9OjqOYhXmc7kKXA Subject: Re: [6tisch-security] summary of discussions on Tuesday 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, 09 Dec 2014 02:40:33 -0000 Correction in my words: "as it gives hints about the key" should read "as i= t can reveal cleartext". Thanks Kris and Rene for correcting this. Regards, Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f yoshihiro.ohba@toshiba.co.jp Sent: Friday, December 5, 2014 1:58 PM To: mcr+ietf@sandelman.ca; 6tisch-security@ietf.org Subject: Re: [6tisch-security] summary of discussions on Tuesday Michael and all, Thank you for the minutes. I could not attend this one due to difficulty i= n time difference while I was able to attend the 9am EST one. As I mention= ed before, I can always comment on the minutes even if I am not able to att= end a call. So everyone please do not much mind about time differences. A= ctually I like email discussions. Let me comment on several things. [1] If my understanding is correct the following scheme is most likely the = way for beacons. - Use of a single, not-well-known key for protecting beacons. - Use authentication-only (no-encryption) for protecting the beacons. If so, I agree with this scheme. [2] Regarding a virtual extended address, I think macDefaultKeySource in IE= EE 802.15.4-2011 is such an address. [3] I almost agree with Tero's review, except for the following paragraph: "As I described earlier, this does not protect the nodes who has lost sync = with network (i.e. who has been sleeping so long that they do not know the = current schedule and current ASN) against replays of the beacons by attacke= r. On the other hand as the AES-CCM nonce also has the extended address of = the sender there, it is enough for the node to make sure he will never go b= ackwards for ASN when sending packets using current network key. If he is t= ricked to send frames using wrong ASN, then other real nodes in the network= will not be able to read those, but that is just DoS, not real security vu= lnerability, which would happen if he would generate frame with old ASN he = has already used, which would generate same AES-CCM nonce." As I mentioned in other email, nonce re-use in AES-CCM is much more than ju= st a DoS, as it gives hints about the key.=20 Best Regards, Yoshihiro Ohba -----Original Message----- From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Friday, December 5, 2014 6:31 AM To: 6tisch-security@ietf.org Subject: [6tisch-security] summary of discussions on Tuesday I can not speak to the call at 9am. At 11am, we had Tero Kivinen join: Attending: - Thomas (TW) - Michael (MR) - Kivinen (TK) - Malisa=20 - Rene (joined :30) (RS) - Pascal (joined :50) (PT) Tero composed a summary of his views, which he sent to secdir and to me pri= vately. is it at: https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmS= Vc and I will likely reply to that message into this list. The discussion started from a need to understand if we had one or two beaco= ns coming from the join assistant. I assumed that there would be two, and = that one would be secured with the production network key, and the other wi= th the well known beacon key. There was various amount of discussion as wh= ether or not this was even possible to do with available MAC implementation= s. I took an action to research how much of the MAC implementation is in softw= are in the "main" CPU, and how much is logic in the MAC (whether it's hard = logic, or immutable firmware doesn't matter). I hope to post that summary = on Monday. Associated with this discussion was some details about the curr= ent 802.15.4 receiver state machine, and changes that TK is making in the -= 2015 revision. A suggestion was made to have one beacon, just the production beacon. This = made a number of us unhappy, as if you can trick someone to use lower ASN, = you cause them to send more data with a previous key, and due to the replay= issue with stream ciphers, you may be able to guess what sent the previous= time. We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate th= e beacon and pull the correct ASN. Joining nodes won't be able to authenti= cate the traffic, but will be able to use the beacon to synchronize to the = network and find the Aloha slot. We talked about the use of a virtual extended address for sending beacons, = as the L2-keys are per-extended (source) address, and since multiple nodes = will need to send the beacon (for radio coverage in the mesh), it needs to = be done right. =20 We discussed whether or not the join traffic itself should be encrypted wit= h some well known key (different from the production network key, which the= joining node does not yet know). Opinions were expressed that it wasn't ne= cessary, and the situation from the Zigbee interop were recounted again. TK suggested that older receiver state machine implementation would have di= fficulty with encrypted traffic that was differently trusted. - TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and passi= ve channel scan we say: The information from the frame to be unsecured shall be recorded in the PAN descriptor even if the Status from the unsecuring process indicated an error" We discussed what to do with the architecture document, and some text was p= romised prior to Friday's 6tisch meeting. --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Mon Dec 8 20:58:51 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DBB1A06E9 for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 20:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] 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 IDdL9DRiMNTN for <6tisch-security@ietfa.amsl.com>; Mon, 8 Dec 2014 20:58:44 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1471A1B5A for <6tisch-security@ietf.org>; Mon, 8 Dec 2014 20:58:43 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id sB94wcgQ009977; Tue, 9 Dec 2014 13:58:38 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id sB94wcpl019602; Tue, 9 Dec 2014 13:58:38 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA19600; Tue, 9 Dec 2014 13:58:38 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id sB94wbHf006034; Tue, 9 Dec 2014 13:58:37 +0900 (JST) Received: from TGXML207.toshiba.local by toshiba.co.jp id sB94wbVT015200; Tue, 9 Dec 2014 13:58:37 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.170]) by TGXML207.toshiba.local ([133.199.70.16]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 13:58:37 +0900 From: To: Thread-Topic: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan Thread-Index: AQHQEzwCeswFS0vjcEirSrRRdThK4ZyGXR8Q//+KHYCAAAkgAIAAvfag Date: Tue, 9 Dec 2014 04:58:36 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> In-Reply-To: <54865CAE.6030308@gmail.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.221] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B29D0EB52TGXML210toshiba_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ohN4f6lQ3aK3IlHr9MhMReKrot8 Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:58:49 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B29D0EB52TGXML210toshiba_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBhbGwgUEFOIERlc2NyaXB0b3IgZmllbGRzIGFyZSBlaXRoZXIgY29udGFpbmVkIGlu IHRoZSB2aXNpYmxlIHBhcnQgb2YgQmVhY29uIGZyYW1lIG9yIG9idGFpbmVkIGFzIGFzc29jaWF0 ZWQgaW5mb3JtYXRpb24gb2YgdGhlIGZyYW1lLiAgU29tZSBUU0NILXJlbGF0ZWQgSUVzLCBzdWNo IGFzIFRTQ0ggU3luY2hyb25pemF0aW9uLCBUU0NIIFNsb3RmcmFtZSBhbmQgTGluaywgVFNDSCBU aW1lc2xvdCwgQ2hhbm5lbCBIb3BwaW5nDQpTZXF1ZW5jZSBJRXMsIGFyZSBjb250YWluZWQgYXMg UGF5bG9hZCBJRXMsIGFuZCBhcmUgbm90IGFjY2Vzc2libGUgZnJvbSBqb2luaW5nIG5vZGUgaWYg dGhleSBhcmUgZW5jcnlwdGVkLg0KDQpPZiBjb3Vyc2UsIGlmIHRoZSBCZWFjb24gZnJhbWUgaXMg YXV0aGVudGljYXRlZC1vbmx5IGFuZCB1bmVuY3J5cHRlZCwgdGhlbiBhbGwgaW5mb3JtYXRpb24g aXMgdmlzaWJsZSB0byBqb2luaW5nIG5vZGUsIGJ1dCBqb2luaW5nIG5vZGUgaGFzIHRvIHByb2Nl c3MgQUVTLUNDTSogZW5jb2RlZCBjbGVhcnRleHQgaW5mb3JtYXRpb24gZXZlbiBpZiBrZXkgaXMg bm90IGF2YWlsYWJsZSAoSSBhbSBub3Qgc3VyZSBpZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBz dXBwb3J0cyB0aGlzIGtpbmQgb2YgcHJvY2Vzc2luZykuDQoNCllvc2hpaGlybyBPaGJhDQoNCg0K DQoNCg0KRnJvbTogUmVuZSBTdHJ1aWsgW21haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb21dDQpT ZW50OiBUdWVzZGF5LCBEZWNlbWJlciA5LCAyMDE0IDExOjIyIEFNDQpUbzogb2hiYSB5b3NoaWhp cm8o5aSn5aC0IOe+qea0iyDil4vvvLLvvKTvvKPilqHvvK7vvLPvvKwpDQpDYzogdGlzY2gtc2Vj dXJpdHkNClN1YmplY3Q6IFJlOiBbNnRpc2NoLXNlY3VyaXR5XSAobWludXRlcyBvZiBUdWUgRGVj IDIsIDIwMTQsIDlhbSBFU1QgY2FsbCkgUmU6IChub3cgd2l0aCBhZ2VuZGEpIFJlOiBpbnZpdGUg Zm9yIDZ0aXNjaCBzZWN1cml0eSBjYWxsIFR1ZSBEZWNlbWJlciAyLCAyMDE0LCA5YW0gRVNUID0g NmFtIFBTVCA9IDNwbSBQYXJpcyA9IDExcG0gSmFwYW4NCg0KSGkgWW9zaGk6DQoNClRoZSBwYXNz aXZlIHNjYW4gbGFuZ3VhZ2UgaW4gdGhlIDgwMi4xNS40LTIwMTEgc3BlYyBpcyBpbiBDbGF1c2Ug NS4xLjIuMS4yLiBJIHRoaW5rIG9uZSBzaG91bGQgYWxzbyBsb29rIGF0IHRoZSBQQU4gZGVzY3Jp cHRvciBhbmQgc2VlIHdoaWNoIGVsZW1lbnRzIG9mIHRoZSBlbmhhbmNlZCBiZWFjb24gdGhhdCBh cmUgaW4gdGhlIFBBTiBkZXNjcmlwdG9yIHRhYmxlIGFyZSB2aXNpYmxlIHRvIGEgIm5ld2JlZSIg ZGV2aWNlLiBXb3VsZCB5b3UgbGlrZSB0byBnaXZlIHRoaXMgYSBsb29rPw0KDQpCZXN0IHJlZ2Fy ZHMsIFJlbmUNCg0KT24gMTIvOC8yMDE0IDg6NDggUE0sIFJlbmUgU3RydWlrIHdyb3RlOg0KSGkg WW9zaGk6DQoNCkdvb2QgcG9pbnQgKGFuZCBJIHJlbWVtYmVyIHdlIGRpc2N1c3NlZCB0aGlzLCB3 aGlsZSBnb2luZyBvdmVyIFNsaWRlIDIwLCBidXQgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGlzIGlu IHRoZSBtaW51dGVzIFtJIHdpbGwgY29ycmVjdCB0aGlzXSkuDQoNClRoZSBpZGVhIGlzIHRoYXQg aWYgYSBqb2luaW5nIGRldmljZSByZWNlaXZlcyBhIHNlY3VyZWQgYmVhY29uIGZyYW1lLCBpdCBj YW4gc3RpbGwgZXh0cmFjdCB0aGUgdmlzaWJsZSBwb3J0aW9uIG9mIHRoZSBmcmFtZSwgZXZlbiBp ZiBpdCBjYW5ub3QgZG8gcHJvcGVyIGluY29taW5nIHNlY3VyaXR5IHByb2Nlc3NpbmcgKG9idmlv dXNseSwgaXQgY2Fubm90IHJlYWxseSByZWx5IG9uIHRoaXMgZGF0YSBhdCB0aGlzIHBvaW50LCB0 aGVuKS4NCg0KV2l0aCA4MDIuMTUuNC0yMDA2LCB0aGlzIGlzIGRlc2NyaWJlZCBpbiBDbGF1c2Ug Ny41LjIuMS4yIChBY3RpdmUgQ2hhbm5lbCBTY2FuKSwgb2Ygd2hpY2ggdGhlIGV4Y2VycHQgZnJv bSBwLiAxNzQgb2YgdGhlIHNwZWMgZGVzY3JpYmVzIHRoZSBjb3JyZXNwb25kaW5nIGJlaGF2aW9y Og0KSWYgYSBwcm90ZWN0ZWQgYmVhY29uIGZyYW1lIGlzIHJlY2VpdmVkLCBpLmUuLCB0aGUgU2Vj dXJpdHkgRW5hYmxlZCBzdWJmaWVsZCBpbiB0aGUgRnJhbWUgQ29udHJvbCBmaWVsZCBpcyBzZXQg dG8gb25lLCB0aGUgZGV2aWNlIHNoYWxsIGF0dGVtcHQgdG8gdW5zZWN1cmUgdGhlIGJlYWNvbiBm cmFtZSB1c2luZyB0aGUgdW5zZWN1cmluZyBwcm9jZXNzIGRlc2NyaWJlZCBpbiA3LjUuOC4yLjMu DQpUaGUgc2VjdXJpdHktcmVsYXRlZCBlbGVtZW50cyBvZiB0aGUgUEFOIGRlc2NyaXB0b3IgY29y cmVzcG9uZGluZyB0byB0aGUgYmVhY29uIChzZWUgVGFibGUgNTUpIHNoYWxsIGJlIHNldCB0byB0 aGUgY29ycmVzcG9uZGluZyBwYXJhbWV0ZXJzIHJldHVybmVkIGJ5IHRoZSB1bnNlY3VyaW5nIHBy b2Nlc3MuIFRoZSBTZWN1cml0eUZhaWx1cmUgZWxlbWVudCBvZiB0aGUgUEFOIGRlc2NyaXB0b3Ig c2hhbGwgYmUgc2V0IHRvIFNVQ0NFU1MgaWYgdGhlIHN0YXR1cyBmcm9tIHRoZSB1bnNlY3VyaW5n IHByb2Nlc3MgaXMgU1VDQ0VTUyBhbmQgc2V0IHRvIG9uZSBvZiB0aGUgb3RoZXIgc3RhdHVzIGNv ZGVzIGluZGljYXRpbmcgYW4gZXJyb3IgaW4gdGhlIHNlY3VyaXR5IHByb2Nlc3Npbmcgb3RoZXJ3 aXNlLiBUaGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgdW5zZWN1cmVkIGZyYW1lIHNoYWxsIGJlIHJl Y29yZGVkIGluIHRoZSBQQU4gZGVzY3JpcHRvciBldmVuIGlmIHRoZSBzdGF0dXMgZnJvbSB0aGUg dW5zZWN1cmluZyBwcm9jZXNzIGluZGljYXRlZCBhbiBlcnJvci4NCkkgZGlkIG5vdCBjaGVjayB5 ZXQgd2hldGhlciB0aGUgbGF0ZXIgc3BlYyA4MDIuMTUuNC0yMDExIGNoYW5nZWQgdGhpcyBiZWhh dmlvciBvciB3aGV0aGVyIDgwMi4xNS40ZS0yMDEyIGRpZCwgYnV0IGlmIEkgcmVtZW1iZXIgY29y cmVjdGx5IHRoZSA4MDIuMTUuNGUgc3BlYyBkaWQgbm90IG1vZGlmeSBhbnkgb2YgdGhpcywgc28g dGhlIHJlbWFpbmluZyBjaGVjayB3b3VsZCBiZSAyMDA2IC0tPiAyMDExLg0KDQpCZXN0IHJlZ2Fy ZHMsIFJlbmUNCg0KDQpPbiAxMi84LzIwMTQgNzowMyBQTSwgeW9zaGloaXJvLm9oYmFAdG9zaGli YS5jby5qcDxtYWlsdG86eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcD4gd3JvdGU6DQpIaSBS ZW5lLA0KDQpJIHdvdWxkIGxpa2UgdG8gZG91YmxlIGNoZWNrIHRoZSBtZWFuaW5nIG9mIOKAnGV4 ZW1wdCBzdGF0dXPigJ0uICBJIHRob3VnaHQgdGhlIOKAnGV4ZW1wdCBzdGF0dXPigJ0gaXMgbWFp bnRhaW5lZCBieSBoaWdoZXIgbGF5ZXIgYW5kIGlzIGRpZmZlcmVudCBmcm9tIHRoZSDigJxFeGVt cHTigJ0gZmxhZyBvZiA4MDIuMTUuNC0yMDExIERldmljZURlc2NyaXB0b3Igb2YgU2VjdXJpdHkt cmVsYXRlZCBQSUIgYXR0cmlidXRlcy4NCg0KSSBhbSBhc2tpbmcgdGhpcyBiZWNhdXNlLCB3aGls ZSB0aGUg4oCcRXhlbXB04oCdIGZsYWcgb2YgODAyLjE1LjQtMjAxMSBEZXZpY2VEZXNjcmlwdG9y IG9mIFNlY3VyaXR5LXJlbGF0ZWQgUElCIGF0dHJpYnV0ZXMgYWxsb3dzIHVuc2VjdXJlZCBmcmFt ZXMgdG8gYmUgcGFzc2VkIHRvIGhpZ2hlciBsYXllciwgdGhlIGZsYWcgc29sZWx5IGRvZXMgbm90 IGhlbHAgZm9yIGpvaW5pbmcgbm9kZeKAmXMgaGlnaGVyIGxheWVyIHRvIHByb2Nlc3MgYXV0aGVu dGljYXRlZC1vbmx5IHNlY3VyZWQgYmVhY29ucy4NCg0KWW9zaGloaXJvIE9oYmENCg0KDQpGcm9t OiA2dGlzY2gtc2VjdXJpdHkgW21haWx0bzo2dGlzY2gtc2VjdXJpdHktYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJlbmUgU3RydWlrDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciA5LCAy MDE0IDg6MDkgQU0NCkNjOiA2dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaC1z ZWN1cml0eUBpZXRmLm9yZz4NClN1YmplY3Q6IFs2dGlzY2gtc2VjdXJpdHldIChtaW51dGVzIG9m IFR1ZSBEZWMgMiwgMjAxNCwgOWFtIEVTVCBjYWxsKSBSZTogKG5vdyB3aXRoIGFnZW5kYSkgUmU6 IGludml0ZSBmb3IgNnRpc2NoIHNlY3VyaXR5IGNhbGwgVHVlIERlY2VtYmVyIDIsIDIwMTQsIDlh bSBFU1QgPSA2YW0gUFNUID0gM3BtIFBhcmlzID0gMTFwbSBKYXBhbg0KDQpEZWFyIGNvbGxlYWd1 ZXM6DQoNClBsZWFzZSBmaW5kIGJlbG93IHRoZSBtaW51dGVzIG9mIHRoZSA2VGlTQ0ggU2VjdXJp dHkgY29uZiBjYWxsIGFzIG9mIERlY2VtYmVyIDIsIDIwMTQsIDlhbSBFU1QuDQoNCk1pbnV0ZXMg NlRpU0NIIFNlY3VyaXR5IGNvbmYgY2FsbCwgVHVlIERlY2VtYmVyIDIsIDIwMTQsIDktMTBhbSBF U1QNCntub3RlIHRha2VyOiBSZW5lIFN0cnVpa30NCntyZWNvcmRpbmc6IGh0dHBzOi8vZHJpdmUu Z29vZ2xlLmNvbS9maWxlL2QvMEIyYTZJbHh1MVhmQ1VtVTRSV0ZmYjFGSlNIYy92aWV3P3VzcD1z aGFyaW5nfQ0Ke3NsaWRlcyBkaXNjdXNzZWQgKGFuZCByZWZlcmVuY2VkIGluIG1pbnV0ZXMpOiBo dHRwczovL2RyaXZlLmdvb2dsZS5jb20vZmlsZS9kLzBCMmE2SWx4dTFYZkNablp6ZGxRNVYxaGtO RWsvdmlldz91c3A9c2hhcmluZ30NCg0KMS4gQXR0ZW5kYW5jZToNCk1pY2hhZWwgUmljaGFyZHNv biwgWW9zaGkgT2hiYSwgU3ViaXIgRGFzLCBQaXJvIEdpdXNlcHBlLCBSZW5lIFN0cnVpaw0KDQoy LiBBZ2VuZGENClRoZSBzdWdnZXN0ZWQgYWdlbmQgd2FzIGFwcHJvdmVkLg0KDQozLiBKb2luIHBy b2Nlc3MgLSBkZXNpcmFibGUgdnMuIHJlYWxpemFibGUgcHJvcGVydGllcw0KUlMgd2VudCBvdmVy IHRoZSBkZXNpcmFibGUgcHJvcGVydGllcyBvZiB0aGUgam9pbiBwcm9jZXNzIChTbGlkZSA2KS4g TVIgcmFpc2VkIHBvaW50IHRoYXQgcHJpdmFjeSBvZiB0aGUgZGV2aWNlIGlkZW50aXR5IG9mIHRo ZSBqb2luaW5nIG5vZGUgbWlnaHQgbm90IGJlIHJlcXVpcmVkLiAuIFNEIHN1Z2dlc3RlZCB0aGF0 IGl0IGlzIGZpbmUgdG8gaW5jbHVkZSBwcml2YWN5IGluIGxpc3Qgb2YgImRlc2lkZXJhdGEiOyBl dmFsdWF0aW9uIG1ldHJpY3MgbWlnaHQgY29uc2lkZXIgdGhlc2UgaW4gImdyZXkgdG9uZXMiIHZz LiBhcyAiYmxhY2sgYW5kIHdoaXRlIiByZXF1aXJlbWVudC4gUlMgc3VnZ2VzdGVkIHRoYXQgbWVy aXQgb2YgcHJpdmFjeSBtaWdodCBkZXBlbmQgb24gZGVwbG95bWVudCBzY2VuYXJpbywgYnV0IGlz IG9uIHRoZSByYWRhciBpbiBsb3RzIG9mIElFVEYgZ3JvdXBzIChpbiB0ZXJtcyBvZiB0cmFjZWFi aWxpdHkvdHJhY2tpbmcpOyBpZiBwcml2YWN5IGNhbiBiZSBlYXNpbHkgb2ZmZXJlZCBhcyBhZGRp dGlvbmFsIGZlYXR1cmUsIHRoaXMgIHdvdWxkIGJlIGEgcGx1cy4gQWZ0ZXIgYXNraW5nLCB0aGVy ZSB3YXMgbm8gZnVydGhlciBkaXNjdXNzaW9uIG9uIHByb3BlcnRpZXMgbGlzdGVkLg0KDQo0LiBK b2luIHByb2Nlc3MgLSBNQUMgYmVoYXZpb3IuDQpSUyB3ZW50IG92ZXIgc29tZSBNQUMgc2VjdXJp dHkgYXNwZWN0cyBvZiB0aGUgODAyLjE1LjQtMjAxMSBhbmQgODAyLjE1LjRlLTIwMTIgc3BlY2lm aWNhdGlvbnMgKFNsaWRlcyAxOS0yMikuIFRoZSBtYWluIHByZW1pc2UgaGVyZSB3YXMgdGhhdCBh IHJlY2lwaWVudCBkZXZpY2UgdGhhdCBleHBlY3RzIHNlY3VyZWQgdHJhZmZpYywgd2lsbCByZWpl Y3QgYWxsIGluY29taW5nIHVuc2VjdXJlZCB0cmFmZmljLCB1bmxlc3MgdGhpcyBvcmlnaW5hdGVz IGZyb20gYSBkZXZpY2Ugd2l0aCBzby1jYWxsZWQgImV4ZW1wdCBzdGF0dXMiLiBUaGlzICJleGVt cHQgc3RhdHVzIiBjb25zdHJ1Y3QgYWxsb3dzIHJlY2VpcHQgb2YgaW5jb21pbmcgdW5zZWN1cmVk IGRhdGEgZnJhbWVzIGZyb20gYSBqb2luaW5nIG5vZGUgdGhhdCBkb2VzIG5vdCBoYXZlIG5ldHdv cmstc3BlY2lmaWMga2V5aW5nIG1hdGVyaWFsIHlldC4gSG93IHRvIHN3aXRjaCBvbi9vZmYgdGhp cyAiZXhlbXB0IHN0YXR1cyIgcGFyYW1ldGVyIHdhcyBhbHNvIGRpc2N1c3NlZCAoc2VlIFNsaWRl IDIwKS4gRnVydGhlcm1vcmUsIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gaG93IHRoaXMg Y29tcGFyZXMgdG8gdGhlIHVzZSBvZiBzby1jYWxsZWQgImRlZmF1bHQga2V5cyIgKGFrYSAiZmFr ZSIga2V5cykgKHNlZSBhbHNvIFNsaWRlIDIyKS4NCg0KUEcgbWVudGlvbmVkIHRoYXQgODAyLjE1 LjQgZG9lcyBub3QgYWxsb3cgdGhlIHVzZSBvZiB0aGUgZGVmYXVsdCBrZXkuIFNEIHN1Z2dlc3Rl ZCB0aGF0IGFuIGltcG9ydGFudCBwb2ludCBpbiBub3QgdXNpbmcgZGVmYXVsdCBrZXlzIGlzIHRo YXQgYWxsIGluY29taW5nIHByb2Nlc3Npbmcgd2l0aCBrZXlzIHdpbGwgYmUgdHJlYXRlZCB0cmFu c3BhcmVudGx5LCBpcnJlc3BlY3RpdmUgb2YgZXhjZXB0aW9ucy4gUlMgZXhwbGFpbmVkIHRoYXQg ZXZlbiBpZiBkZWZhdWx0IGtleXMgd2VyZSB0byBiZSB1c2VkLCB0aGlzIHdvdWxkIG1lc3MgdXAg bG9jYWwgc2VjdXJpdHkgc3RhdGUgKGUuZy4sIGZyYW1lIGNvdW50ZXJzKSwgd2hpY2ggaXMgbm90 IHRoZSBjYXNlIGlmIG9uZSB3b3VsZCBzZW5kIHVuc2VjdXJlZCB0cmFmZmljIGFuZCB1c2UgdGhl ICJleGVtcHQgc3RhdHVzIiBjb25zdHJ1Y3QgaW5zdGVhZC4gUEQgc3VtbWFyaXplZCB0aGF0IHVz aW5nIHVuc2VjdXJlZCBmcmFtZXMsIHJhdGhlciB0aGFuICJmYWtlIiBzZWN1cml0eSB3aXRoICJk ZWZhdWx0IGtleXMiLCBzaG91bGQgYmUgYWRvcHRlZCwgd2hpY2ggd2FzIGNvbnNlbnN1cyBvbiB0 aGUgY2FsbC4NCg0KUEcgY2FtZSBiYWNrIHRvIHRoZSAiZXhlbXB0IGZsYWciIHRvcGljIGFuZCBz dWdnZXN0ZWQgdGhhdCBkZXRhaWxzIGhlcmVvZiBhcmUgaW4gdGhlICJkZXZpY2UgZGVzY3JpcHRv ciBsb29rdXAgdGFibGUiLiBSUyBzdWdnZXN0ZWQgdGhhdCB3ZSBhbGwgaGF2ZSBhIGNsb3NlciBs b29rIGF0IHNwZWNpZmljYXRpb24gZGV0YWlscywgc28gdGhhdCBzd2l0Y2hpbmcgdGhpcyBmZWF0 dXJlIG9uL29mZiBjb3VsZCBiZSBlYXNpbHkgY29kaWZpZWQgZm9yIDZUaVNDSCB1c2UuDQoNCjUu IEpvaW4gcHJvY2VzcyAtIG5vbi1NQUMgYmVoYXZpb3IuDQpHaXZlbiByZW1haW5pbmcgdGltZSBv biB0aGUgY2FsbCB3b3VsZCBub3QgYWxsb3cgZnVsbCBkaXNjdXNzaW9uIG9mIG5vbi1NQUMgYXNw ZWN0cyAoU2xpZGVzIDIzLTI1KSBhbmQgZ2l2ZW4gdGhhdCBNUiBoYWQgdG8gZHJvcCBvZmYgdGhl IGNhbGwsIGl0IHdhcyBkZWNpZGVkIHRvIHJldmlzaXQgdGhvc2UgdG9waWNzIGF0IHRoZSBuZXh0 IGNvbmYgY2FsbC4NCg0KNi4gQU9CIENvbmYgY2FsbCBzY2hlZHVsaW5nLg0KU0Qgc3VnZ2VzdGVk IGhlIHdhcyBjb25mdXNlZCBhYm91dCBoYXZpbmcgdHdvIGNhbGwgdGltZXMgaW4gZW1haWwgdHJh ZmZpYyAob25lIGF0IDlhbSBFU1QgYW5kIG9uZSBhdCAxMWFtIEVTVCkgYW5kIHN1Z2dlc3RlZCB0 aGF0IG90aGVyIGdyb3Vwcywgc3VjaCBhcywgZS5nLiwgSUVFRSwgb2Z0ZW4gdXNlIGN5Y2xpYyBz Y2hlZHVsZSwgc28gYXMgdG8gYWNjb21tb2RhdGUgcGFydGljaXBhbnRzIGZyb20gYXJvdW5kIHRo ZSB3b3JsZCBhbmQgd2hvIG1heSBiZSBhdCB3aWRlbHkgZGlmZmVyZW50IHRpbWUgem9uZXMuIFJT IHZvbHVudGVlcmVkIHRvIGxvb2sgaW50byB0aGlzIHRvcGljIGFuZCBvYnRhaW4gZmVlZGJhY2sg b24gc3VjaCBhIHNjaGVkdWxlLg0KDQpCZXN0IHJlZ2FyZHMsIFJlbmUNCg0KT24gMTIvMS8yMDE0 IDExOjU1IEFNLCBSZW5lIFN0cnVpayB3cm90ZToNClByb3Bvc2VkIGFnZW5kYToNCg0KMCkgQWdl bmRhIGJhc2hpbmcNCg0KMSkgSm9pbiBwcm90b2NvbCBkZXRhaWxzDQphKSBkZXNpcmVkIHByb3Bl cnRpZXMNCmIpIHJlYWxpemFibGUgcHJvcGVydGllcw0KMikgTmV4dCBzdGVwczoNCiAgICAgICAg YSkgY29uc2Vuc3VzIG9uIDEjYSBhbmQgMSNiDQogICAgICAgIGIpIGZvcm0gdGlnZXIgdGVhbSB0 byB3b3JrIG91dCBkZXRhaWxzDQogICAgICAgICAgICAtIHByb2plY3QgcGhhc2VzDQogICAgICAg ICAgICAtIGNvbW11bmljYXRpb24gb2Ygc3ViLXJlc3VsdHMNCiAgICAgICAgYykgd2hhdCB0byBz cXVlZXplIGludG8gYXJjaGl0ZWN0dXJlIGRyYWZ0LCBldGMuDQoNCkkgd2lsbCBwcmVwYXJlIG1h dGVyaWFsIHRvIGZhY2lsaXRhdGUgZGlzY3Vzc2lvbiBvbiAxKSBhbmQgMiksIHRvIGJlIGRpc2N1 c3NlZCBkdXJpbmcgdGhlIGNhbGwuDQoNCkJlc3QgcmVnYXJkcywgUmVuZQ0KDQoNCk9uIDExLzI4 LzIwMTQgMTE6MDIgQU0sIFJlbmUgU3RydWlrIHdyb3RlOg0KRGVhciBjb2xsZWFndWVzOg0KDQpJ IGhhdmUgc2V0IHVwIGEgY29uZiBjYWxsIGZvciBUdWVzZGF5IERlY2VtYmVyIDIsIDIwMTQgYXQg YSB0aW1lIHRoYXQgdHJpZXMgYW5kIGFjY29tbW9kYXRlIHBlb3BsZSBpbiBkaWZmZXJlbnQgdGlt ZSB6b25lcyB0byB0aGUgbGFyZ2VzdCBleHRlbnQgcG9zc2libGUsIHdpdGhvdXQgdHJ5aW5nIHRv IGRpc2NyaW1pbmF0ZSBhZ2FpbnN0IHZhcmlvdXMgcGFydHMgb2YgdGhlIHdvcmxkLg0KDQpQbGVh c2Ugc2VlIGRpYWwtaW4gaW5mb3JtYXRpb24gYmVsb3cuDQoNCkFnZW5kYSB0byBmb2xsb3cgTW9u ZGF5IGFyb3VuZCBub29uLg0KDQpMb29raW5nIGZvcndhcmQgdG8gYSBjb2xsYWJvcmF0aXZlIG1l ZXRpbmcsIGluIGdvb2Qgc3Bpcml0Lg0KDQpCZXN0IHJlZ2FyZHMsIFJlbmUNCj09DQoNCjEuICBQ bGVhc2Ugam9pbiBteSBtZWV0aW5nLg0KaHR0cHM6Ly9nbG9iYWwuZ290b21lZXRpbmcuY29tL2pv aW4vNTk0Mjk5MDYxDQoNCjIuICBVc2UgeW91ciBtaWNyb3Bob25lIGFuZCBzcGVha2VycyAoVm9J UCkgLSBhIGhlYWRzZXQgaXMgcmVjb21tZW5kZWQuICBPciwgY2FsbCBpbiB1c2luZyB5b3VyIHRl bGVwaG9uZS4NCg0KRGlhbCArMSAoNjQ3KSA0OTctOTM1MQ0KQWNjZXNzIENvZGU6IDU5NC0yOTkt MDYxDQpBdWRpbyBQSU46IFNob3duIGFmdGVyIGpvaW5pbmcgdGhlIG1lZXRpbmcNCg0KTWVldGlu ZyBQYXNzd29yZDogY29sbGFib3JhdGUNCk1lZXRpbmcgSUQ6IDU5NC0yOTktMDYxDQoNCkdvVG9N ZWV0aW5nwq4NCk9ubGluZSBNZWV0aW5ncyBNYWRlIEVhc3nCrg0KDQpOb3QgYXQgeW91ciBjb21w dXRlcj8gQ2xpY2sgdGhlIGxpbmsgdG8gam9pbiB0aGlzIG1lZXRpbmcgZnJvbSB5b3VyIGlQaG9u ZcKuLCBpUGFkwq4sIEFuZHJvaWTCriBvciBXaW5kb3dzIFBob25lwq4gZGV2aWNlIHZpYSB0aGUg R29Ub01lZXRpbmcgYXBwLg0KDQoNCg0KW2V4Y2VycHQgZW1haWwgYXMgb2YgVGh1IE5vdmVtYmVy IDI3LCAyMDE0LCA5LjQycG0gRVNUXQ0KSSBzdWdnZXN0IDlhbSBFU1QgPSA2YW0gUFNUID0gM3Bt IFBhcmlzID0gMTFwbSBKYXBhbi4gVGhpcyBzaG91bGQgYWxsb3cgcGVvcGxlIHRvIGhhdmUgdGhl aXIgcHJpdmF0ZSB0aW1lIGluIHRoZSAxMmFtLTZhbSB0aW1lIHdpbmRvdy4ge090aGVyIGdyb3Vw cyBkbyBhIG11Y2ggYmV0dGVyIGpvYiBhdCB0aGlzLi4ufQ0KDQoNCk9uIDExLzI4LzIwMTQgMTA6 MzkgQU0sIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCg0KU3ViaXIgRGFzIDxzdWJpcmRhczIx QGdtYWlsLmNvbT48bWFpbHRvOnN1YmlyZGFzMjFAZ21haWwuY29tPiB3cm90ZToNCg0KICAgID4g VGhhbmtzIGZvciBhcnJhbmdpbmcgdGhlIGNhbGxzLiBJdCB3b3VsZCBiZSBnb29kIHRvIGFjY29t bW9kYXRlIEFzaWFuIHRpbWUNCg0KICAgID4gem9uZSBmb3IgYnJvYWRlciBwYXJ0aWNpcGF0aW9u LiBJIHdvdWxkIHN1Z2dlc3QgY2hvb3NpbmcgYSB0aW1lIHRoYXQgaXMNCg0KDQoNCkknbSBoYXBw eSB0byBkbyB0aGlzIGF0IGFub3RoZXIgdGltZTsgdGhlIG9yaWdpbmFsIGNob2ljZSBvZiAxMWFt IEVhc3Rlcm4gd2FzDQoNCnRvIGFjY29tb2RhdGUgUGFjaWZpYyBUaW1lIFpvbmUgUGVvcGxlIHdo byBjb3VsZG4ndCBtZWV0IGJlZm9yZSA4YW0uDQoNCg0KDQo+RnJvbSBsb25nIGV4cGVyaWVuY2Us IG91ciBjaG9pY2VzIGVzc2VudGlhbGx5IGFyZSBhdCAxNTowMCBVVEMgb3IgMDM6MDAgVVRDLg0K DQogICAgMDc6MDAgUGFjaWZpYy8xMDowMCBFYXN0ZXJuIC8gMTc6MDAgSGVsc2lua2kvMjI6MDAg QmVpamluZw0KDQpvcg0KDQogICAgMTk6MDAgUGFjaWZpYy8yMjowMCBFYXN0ZXJuIC8gMDU6MDAg SGVsc2lua2kvMTA6MDAgQmVpamluZw0KDQoNCg0KSSBhbSBhbHNvIGhhcHB5IHRvIGFsdGVybmF0 ZS4NCg0KU2hhbGwgSSBwdXQgdXAgYSBkb29kbGUgcG9sbD8NCg0KDQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KNnRpc2NoLXNlY3Vy aXR5IG1haWxpbmcgbGlzdA0KDQo2dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNj aC1zZWN1cml0eUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82dGlzY2gtc2VjdXJpdHkNCg0KDQoNCg0KDQotLQ0KDQplbWFpbDogcnN0cnVpay5leHRA Z21haWwuY29tPG1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20+IHwgU2t5cGU6IHJzdHJ1aWsN Cg0KY2VsbDogKzEgKDY0NykgODY3LTU2NTggfCBVUzogKzEgKDQxNSkgNjkwLTczNjMNCg0KDQoN Cg0KDQotLQ0KDQplbWFpbDogcnN0cnVpay5leHRAZ21haWwuY29tPG1haWx0bzpyc3RydWlrLmV4 dEBnbWFpbC5jb20+IHwgU2t5cGU6IHJzdHJ1aWsNCg0KY2VsbDogKzEgKDY0NykgODY3LTU2NTgg fCBVUzogKzEgKDQxNSkgNjkwLTczNjMNCg0KDQoNCg0KDQotLQ0KDQplbWFpbDogcnN0cnVpay5l eHRAZ21haWwuY29tPG1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20+IHwgU2t5cGU6IHJzdHJ1 aWsNCg0KY2VsbDogKzEgKDY0NykgODY3LTU2NTggfCBVUzogKzEgKDQxNSkgNjkwLTczNjMNCg0K DQoNCg0KLS0NCg0KZW1haWw6IHJzdHJ1aWsuZXh0QGdtYWlsLmNvbTxtYWlsdG86cnN0cnVpay5l eHRAZ21haWwuY29tPiB8IFNreXBlOiByc3RydWlrDQoNCmNlbGw6ICsxICg2NDcpIDg2Ny01NjU4 IHwgVVM6ICsxICg0MTUpIDY5MC03MzYzDQoNCg0KDQoNCi0tDQoNCmVtYWlsOiByc3RydWlrLmV4 dEBnbWFpbC5jb208bWFpbHRvOnJzdHJ1aWsuZXh0QGdtYWlsLmNvbT4gfCBTa3lwZTogcnN0cnVp aw0KDQpjZWxsOiArMSAoNjQ3KSA4NjctNTY1OCB8IFVTOiArMSAoNDE1KSA2OTAtNzM2Mw0K --_000_674F70E5F2BE564CB06B6901FD3DD78B29D0EB52TGXML210toshiba_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Iu+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yz IO+8sOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcLHNl cmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wpIjsNCgltYXJn aW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIOabuOW8j+S7mOOBjSBcKOaWh+Wtl1wpIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg5pu45byP5LuY44GNIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi4yMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwi LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLjIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo5OS4yNXB0IDMwLjBtbSAzMC4wbW0gMzAuMG1tO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiPg0KPHY6dGV4dGJveCBpbnNldD0iNS44NXB0LC43cHQsNS44NXB0LC43cHQiIC8+DQo8L286 c2hhcGVkZWZhdWx0cz48L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkpBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPkkg dGhpbmsgYWxsIFBBTiBEZXNjcmlwdG9yIGZpZWxkcyBhcmUgZWl0aGVyIGNvbnRhaW5lZCBpbiB0 aGUgdmlzaWJsZSBwYXJ0IG9mIEJlYWNvbiBmcmFtZSBvciBvYnRhaW5lZCBhcyBhc3NvY2lhdGVk IGluZm9ybWF0aW9uIG9mIHRoZSBmcmFtZS4mbmJzcDsgU29tZSBUU0NILXJlbGF0ZWQgSUVzLCBz dWNoIGFzIFRTQ0gNCiBTeW5jaHJvbml6YXRpb24sIFRTQ0ggU2xvdGZyYW1lIGFuZCBMaW5rLCBU U0NIIFRpbWVzbG90LCBDaGFubmVsIEhvcHBpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzFGNDk3RCI+U2VxdWVuY2UgSUVzLCBhcmUgY29udGFpbmVkIGFzIFBheWxvYWQg SUVzLCBhbmQgYXJlIG5vdCBhY2Nlc3NpYmxlIGZyb20gam9pbmluZyBub2RlIGlmIHRoZXkgYXJl IGVuY3J5cHRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPk9mIGNv dXJzZSwgaWYgdGhlIEJlYWNvbiBmcmFtZSBpcyBhdXRoZW50aWNhdGVkLW9ubHkgYW5kIHVuZW5j cnlwdGVkLCB0aGVuIGFsbCBpbmZvcm1hdGlvbiBpcyB2aXNpYmxlIHRvIGpvaW5pbmcgbm9kZSwg YnV0IGpvaW5pbmcgbm9kZSBoYXMgdG8gcHJvY2VzcyBBRVMtQ0NNKiBlbmNvZGVkIGNsZWFydGV4 dA0KIGluZm9ybWF0aW9uIGV2ZW4gaWYga2V5IGlzIG5vdCBhdmFpbGFibGUgKEkgYW0gbm90IHN1 cmUgaWYgZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgdGhpcyBraW5kIG9mIHByb2Nl c3NpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+WW9zaGloaXJv IE9oYmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IFJlbmUgU3RydWlrIFttYWlsdG86cnN0cnVpay5leHRA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDksIDIwMTQg MTE6MjIgQU08YnI+DQo8Yj5Ubzo8L2I+IG9oYmEgeW9zaGloaXJvKDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIO+8sOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij7lpKfloLQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIO+8sOOCtOOCt+ODg+OCryZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij7nvqnmtIs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ IOKXizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q777yt77yzIO+8sOOCtOOC t+ODg+OCryZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij7vvLLvvKTvvKM8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+4pahPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDvvvK3vvLMg77yw44K044K344OD44KvJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPu+8ru+8 s++8rDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4pPGJyPg0KPGI+Q2M6PC9i PiB0aXNjaC1zZWN1cml0eTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogWzZ0aXNjaC1zZWN1cml0 eV0gKG1pbnV0ZXMgb2YgVHVlIERlYyAyLCAyMDE0LCA5YW0gRVNUIGNhbGwpIFJlOiAobm93IHdp dGggYWdlbmRhKSBSZTogaW52aXRlIGZvciA2dGlzY2ggc2VjdXJpdHkgY2FsbCBUdWUgRGVjZW1i ZXIgMiwgMjAxNCwgOWFtIEVTVCA9IDZhbSBQU1QgPSAzcG0gUGFyaXMgPSAxMXBtIEphcGFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIFlvc2hpOjxicj4NCjxi cj4NClRoZSBwYXNzaXZlIHNjYW4gbGFuZ3VhZ2UgaW4gdGhlIDgwMi4xNS40LTIwMTEgc3BlYyBp cyBpbiBDbGF1c2UgNS4xLjIuMS4yLiBJIHRoaW5rIG9uZSBzaG91bGQgYWxzbyBsb29rIGF0IHRo ZSBQQU4gZGVzY3JpcHRvciBhbmQgc2VlIHdoaWNoIGVsZW1lbnRzIG9mIHRoZSBlbmhhbmNlZCBi ZWFjb24gdGhhdCBhcmUgaW4gdGhlIFBBTiBkZXNjcmlwdG9yIHRhYmxlIGFyZSB2aXNpYmxlIHRv IGEgJnF1b3Q7bmV3YmVlJnF1b3Q7IGRldmljZS4gV291bGQgeW91IGxpa2UNCiB0byBnaXZlIHRo aXMgYSBsb29rPzxicj4NCjxicj4NCkJlc3QgcmVnYXJkcywgUmVuZTxicj4NCjxicj4NCk9uIDEy LzgvMjAxNCA4OjQ4IFBNLCBSZW5lIFN0cnVpayB3cm90ZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBZ b3NoaTo8YnI+DQo8YnI+DQpHb29kIHBvaW50IChhbmQgSSByZW1lbWJlciB3ZSBkaXNjdXNzZWQg dGhpcywgd2hpbGUgZ29pbmcgb3ZlciBTbGlkZSAyMCwgYnV0IEkgZm9yZ290IHRvIGluY2x1ZGUg dGhpcyBpbiB0aGUgbWludXRlcyBbSSB3aWxsIGNvcnJlY3QgdGhpc10pLjxicj4NCjxicj4NClRo ZSBpZGVhIGlzIHRoYXQgaWYgYSBqb2luaW5nIGRldmljZSByZWNlaXZlcyBhIHNlY3VyZWQgYmVh Y29uIGZyYW1lLCBpdCBjYW4gc3RpbGwgZXh0cmFjdCB0aGUgdmlzaWJsZSBwb3J0aW9uIG9mIHRo ZSBmcmFtZSwgZXZlbiBpZiBpdCBjYW5ub3QgZG8gcHJvcGVyIGluY29taW5nIHNlY3VyaXR5IHBy b2Nlc3NpbmcgKG9idmlvdXNseSwgaXQgY2Fubm90IHJlYWxseSByZWx5IG9uIHRoaXMgZGF0YSBh dCB0aGlzIHBvaW50LCB0aGVuKS48YnI+DQo8YnI+DQpXaXRoIDgwMi4xNS40LTIwMDYsIHRoaXMg aXMgZGVzY3JpYmVkIGluIENsYXVzZSA3LjUuMi4xLjIgKEFjdGl2ZSBDaGFubmVsIFNjYW4pLCBv ZiB3aGljaCB0aGUgZXhjZXJwdCBmcm9tIHAuIDE3NCBvZiB0aGUgc3BlYyBkZXNjcmliZXMgdGhl IGNvcnJlc3BvbmRpbmcgYmVoYXZpb3I6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5JZiBhIHByb3RlY3RlZCBiZWFjb24gZnJhbWUgaXMgcmVjZWl2ZWQsIGkuZS4sIHRoZSBT ZWN1cml0eSBFbmFibGVkIHN1YmZpZWxkIGluIHRoZSBGcmFtZSBDb250cm9sIGZpZWxkIGlzIHNl dCB0byBvbmUsIHRoZSBkZXZpY2Ugc2hhbGwgYXR0ZW1wdCB0byB1bnNlY3VyZSB0aGUgYmVhY29u IGZyYW1lIHVzaW5nIHRoZSB1bnNlY3VyaW5nDQogcHJvY2VzcyBkZXNjcmliZWQgaW4gNy41Ljgu Mi4zLjxicj4NClRoZSBzZWN1cml0eS1yZWxhdGVkIGVsZW1lbnRzIG9mIHRoZSBQQU4gZGVzY3Jp cHRvciBjb3JyZXNwb25kaW5nIHRvIHRoZSBiZWFjb24gKHNlZSBUYWJsZSA1NSkgc2hhbGwgYmUg c2V0IHRvIHRoZSBjb3JyZXNwb25kaW5nIHBhcmFtZXRlcnMgcmV0dXJuZWQgYnkgdGhlIHVuc2Vj dXJpbmcgcHJvY2Vzcy4gVGhlIFNlY3VyaXR5RmFpbHVyZSBlbGVtZW50IG9mIHRoZSBQQU4gZGVz Y3JpcHRvciBzaGFsbCBiZSBzZXQgdG8gU1VDQ0VTUyBpZiB0aGUNCiBzdGF0dXMgZnJvbSB0aGUg dW5zZWN1cmluZyBwcm9jZXNzIGlzIFNVQ0NFU1MgYW5kIHNldCB0byBvbmUgb2YgdGhlIG90aGVy IHN0YXR1cyBjb2RlcyBpbmRpY2F0aW5nIGFuIGVycm9yIGluIHRoZSBzZWN1cml0eSBwcm9jZXNz aW5nIG90aGVyd2lzZS4gVGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIHVuc2VjdXJlZCBmcmFtZSBz aGFsbCBiZSByZWNvcmRlZCBpbiB0aGUgUEFOIGRlc2NyaXB0b3IgZXZlbiBpZiB0aGUgc3RhdHVz IGZyb20gdGhlIHVuc2VjdXJpbmcNCiBwcm9jZXNzIGluZGljYXRlZCBhbiBlcnJvci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SSBkaWQgbm90IGNoZWNrIHlldCB3aGV0aGVyIHRoZSBsYXRlciBzcGVj IDgwMi4xNS40LTIwMTEgY2hhbmdlZCB0aGlzIGJlaGF2aW9yIG9yIHdoZXRoZXIgODAyLjE1LjRl LTIwMTIgZGlkLCBidXQgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkgdGhlIDgwMi4xNS40ZSBzcGVj IGRpZCBub3QgbW9kaWZ5IGFueSBvZiB0aGlzLCBzbyB0aGUgcmVtYWluaW5nIGNoZWNrIHdvdWxk IGJlDQogMjAwNiAtLSZndDsgMjAxMS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsIFJlbmU8YnI+ DQo8YnI+DQo8YnI+DQpPbiAxMi84LzIwMTQgNzowMyBQTSwgPGEgaHJlZj0ibWFpbHRvOnlvc2hp aGlyby5vaGJhQHRvc2hpYmEuY28uanAiPnlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8L2E+ IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFG NDk3RCI+SGkgUmVuZSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5JIHdvdWxk IGxpa2UgdG8gZG91YmxlIGNoZWNrIHRoZSBtZWFuaW5nIG9mIOKAnGV4ZW1wdCBzdGF0dXPigJ0u Jm5ic3A7IEkgdGhvdWdodCB0aGUg4oCcZXhlbXB0IHN0YXR1c+KAnSBpcyBtYWludGFpbmVkIGJ5 IGhpZ2hlciBsYXllciBhbmQgaXMgZGlmZmVyZW50IGZyb20gdGhlIOKAnEV4ZW1wdOKAnSBmbGFn IG9mIDgwMi4xNS40LTIwMTENCiBEZXZpY2VEZXNjcmlwdG9yIG9mIFNlY3VyaXR5LXJlbGF0ZWQg UElCIGF0dHJpYnV0ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+SSBhbSBh c2tpbmcgdGhpcyBiZWNhdXNlLCB3aGlsZSB0aGUg4oCcRXhlbXB04oCdIGZsYWcgb2YgODAyLjE1 LjQtMjAxMSBEZXZpY2VEZXNjcmlwdG9yIG9mIFNlY3VyaXR5LXJlbGF0ZWQgUElCIGF0dHJpYnV0 ZXMgYWxsb3dzIHVuc2VjdXJlZCBmcmFtZXMgdG8gYmUgcGFzc2VkIHRvIGhpZ2hlciBsYXllciwg dGhlIGZsYWcNCiBzb2xlbHkgZG9lcyBub3QgaGVscCBmb3Igam9pbmluZyBub2Rl4oCZcyBoaWdo ZXIgbGF5ZXIgdG8gcHJvY2VzcyBhdXRoZW50aWNhdGVkLW9ubHkgc2VjdXJlZCBiZWFjb25zLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPllvc2hpaGlybyBPaGJhPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMG1tIDBtbSAwbW0i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiA2dGlzY2gtc2Vj dXJpdHkgWzxhIGhyZWY9Im1haWx0bzo2dGlzY2gtc2VjdXJpdHktYm91bmNlc0BpZXRmLm9yZyI+ bWFpbHRvOjZ0aXNjaC1zZWN1cml0eS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+UmVuZSBTdHJ1aWs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIg OSwgMjAxNCA4OjA5IEFNPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86NnRpc2NoLXNl Y3VyaXR5QGlldGYub3JnIj42dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFs2dGlzY2gtc2VjdXJpdHldIChtaW51dGVzIG9mIFR1ZSBEZWMgMiwgMjAxNCwg OWFtIEVTVCBjYWxsKSBSZTogKG5vdyB3aXRoIGFnZW5kYSkgUmU6IGludml0ZSBmb3IgNnRpc2No IHNlY3VyaXR5IGNhbGwgVHVlIERlY2VtYmVyIDIsIDIwMTQsIDlhbSBFU1QgPSA2YW0gUFNUID0g M3BtIFBhcmlzID0gMTFwbSBKYXBhbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIgY29sbGVhZ3Vlczo8YnI+DQo8 YnI+DQpQbGVhc2UgZmluZCBiZWxvdyB0aGUgbWludXRlcyBvZiB0aGUgNlRpU0NIIFNlY3VyaXR5 IGNvbmYgY2FsbCBhcyBvZiBEZWNlbWJlciAyLCAyMDE0LCA5YW0gRVNULjxicj4NCjxicj4NCk1p bnV0ZXMgNlRpU0NIIFNlY3VyaXR5IGNvbmYgY2FsbCwgVHVlIERlY2VtYmVyIDIsIDIwMTQsIDkt MTBhbSBFU1Q8YnI+DQp7bm90ZSB0YWtlcjogUmVuZSBTdHJ1aWt9PGJyPg0Ke3JlY29yZGluZzog PGEgaHJlZj0iaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2ZpbGUvZC8wQjJhNklseHUxWGZDVW1V NFJXRmZiMUZKU0hjL3ZpZXc/dXNwPXNoYXJpbmciPg0KaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29t L2ZpbGUvZC8wQjJhNklseHUxWGZDVW1VNFJXRmZiMUZKU0hjL3ZpZXc/dXNwPXNoYXJpbmc8L2E+ fTxicj4NCntzbGlkZXMgZGlzY3Vzc2VkIChhbmQgcmVmZXJlbmNlZCBpbiBtaW51dGVzKTogPGEg aHJlZj0iaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2ZpbGUvZC8wQjJhNklseHUxWGZDWm5aemRs UTVWMWhrTkVrL3ZpZXc/dXNwPXNoYXJpbmciPg0KaHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2Zp bGUvZC8wQjJhNklseHUxWGZDWm5aemRsUTVWMWhrTkVrL3ZpZXc/dXNwPXNoYXJpbmc8L2E+fTxi cj4NCjxicj4NCjEuIEF0dGVuZGFuY2U6PGJyPg0KTWljaGFlbCBSaWNoYXJkc29uLCBZb3NoaSBP aGJhLCBTdWJpciBEYXMsIFBpcm8gR2l1c2VwcGUsIFJlbmUgU3RydWlrPGJyPg0KPGJyPg0KMi4g QWdlbmRhPGJyPg0KVGhlIHN1Z2dlc3RlZCBhZ2VuZCB3YXMgYXBwcm92ZWQuPGJyPg0KPGJyPg0K My4gSm9pbiBwcm9jZXNzIC0gZGVzaXJhYmxlIHZzLiByZWFsaXphYmxlIHByb3BlcnRpZXM8YnI+ DQpSUyB3ZW50IG92ZXIgdGhlIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIG9mIHRoZSBqb2luIHByb2Nl c3MgKFNsaWRlIDYpLiBNUiByYWlzZWQgcG9pbnQgdGhhdCBwcml2YWN5IG9mIHRoZSBkZXZpY2Ug aWRlbnRpdHkgb2YgdGhlIGpvaW5pbmcgbm9kZSBtaWdodCBub3QgYmUgcmVxdWlyZWQuIC4gU0Qg c3VnZ2VzdGVkIHRoYXQgaXQgaXMgZmluZSB0byBpbmNsdWRlIHByaXZhY3kgaW4gbGlzdCBvZiAm cXVvdDtkZXNpZGVyYXRhJnF1b3Q7OyBldmFsdWF0aW9uIG1ldHJpY3MNCiBtaWdodCBjb25zaWRl ciB0aGVzZSBpbiAmcXVvdDtncmV5IHRvbmVzJnF1b3Q7IHZzLiBhcyAmcXVvdDtibGFjayBhbmQg d2hpdGUmcXVvdDsgcmVxdWlyZW1lbnQuIFJTIHN1Z2dlc3RlZCB0aGF0IG1lcml0IG9mIHByaXZh Y3kgbWlnaHQgZGVwZW5kIG9uIGRlcGxveW1lbnQgc2NlbmFyaW8sIGJ1dCBpcyBvbiB0aGUgcmFk YXIgaW4gbG90cyBvZiBJRVRGIGdyb3VwcyAoaW4gdGVybXMgb2YgdHJhY2VhYmlsaXR5L3RyYWNr aW5nKTsgaWYgcHJpdmFjeSBjYW4gYmUgZWFzaWx5IG9mZmVyZWQNCiBhcyBhZGRpdGlvbmFsIGZl YXR1cmUsIHRoaXMmbmJzcDsgd291bGQgYmUgYSBwbHVzLiBBZnRlciBhc2tpbmcsIHRoZXJlIHdh cyBubyBmdXJ0aGVyIGRpc2N1c3Npb24gb24gcHJvcGVydGllcyBsaXN0ZWQuPGJyPg0KPGJyPg0K NC4gSm9pbiBwcm9jZXNzIC0gTUFDIGJlaGF2aW9yLjxicj4NClJTIHdlbnQgb3ZlciBzb21lIE1B QyBzZWN1cml0eSBhc3BlY3RzIG9mIHRoZSA4MDIuMTUuNC0yMDExIGFuZCA4MDIuMTUuNGUtMjAx MiBzcGVjaWZpY2F0aW9ucyAoU2xpZGVzIDE5LTIyKS4gVGhlIG1haW4gcHJlbWlzZSBoZXJlIHdh cyB0aGF0IGEgcmVjaXBpZW50IGRldmljZSB0aGF0IGV4cGVjdHMgc2VjdXJlZCB0cmFmZmljLCB3 aWxsIHJlamVjdCBhbGwgaW5jb21pbmcgdW5zZWN1cmVkIHRyYWZmaWMsIHVubGVzcyB0aGlzIG9y aWdpbmF0ZXMNCiBmcm9tIGEgZGV2aWNlIHdpdGggc28tY2FsbGVkICZxdW90O2V4ZW1wdCBzdGF0 dXMmcXVvdDsuIFRoaXMgJnF1b3Q7ZXhlbXB0IHN0YXR1cyZxdW90OyBjb25zdHJ1Y3QgYWxsb3dz IHJlY2VpcHQgb2YgaW5jb21pbmcgdW5zZWN1cmVkIGRhdGEgZnJhbWVzIGZyb20gYSBqb2luaW5n IG5vZGUgdGhhdCBkb2VzIG5vdCBoYXZlIG5ldHdvcmstc3BlY2lmaWMga2V5aW5nIG1hdGVyaWFs IHlldC4gSG93IHRvIHN3aXRjaCBvbi9vZmYgdGhpcyAmcXVvdDtleGVtcHQgc3RhdHVzJnF1b3Q7 IHBhcmFtZXRlciB3YXMNCiBhbHNvIGRpc2N1c3NlZCAoc2VlIFNsaWRlIDIwKS4gRnVydGhlcm1v cmUsIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gaG93IHRoaXMgY29tcGFyZXMgdG8gdGhl IHVzZSBvZiBzby1jYWxsZWQgJnF1b3Q7ZGVmYXVsdCBrZXlzJnF1b3Q7IChha2EgJnF1b3Q7ZmFr ZSZxdW90OyBrZXlzKSAoc2VlIGFsc28gU2xpZGUgMjIpLjxicj4NCjxicj4NClBHIG1lbnRpb25l ZCB0aGF0IDgwMi4xNS40IGRvZXMgbm90IGFsbG93IHRoZSB1c2Ugb2YgdGhlIGRlZmF1bHQga2V5 LiBTRCBzdWdnZXN0ZWQgdGhhdCBhbiBpbXBvcnRhbnQgcG9pbnQgaW4gbm90IHVzaW5nIGRlZmF1 bHQga2V5cyBpcyB0aGF0IGFsbCBpbmNvbWluZyBwcm9jZXNzaW5nIHdpdGgga2V5cyB3aWxsIGJl IHRyZWF0ZWQgdHJhbnNwYXJlbnRseSwgaXJyZXNwZWN0aXZlIG9mIGV4Y2VwdGlvbnMuIFJTIGV4 cGxhaW5lZCB0aGF0IGV2ZW4NCiBpZiBkZWZhdWx0IGtleXMgd2VyZSB0byBiZSB1c2VkLCB0aGlz IHdvdWxkIG1lc3MgdXAgbG9jYWwgc2VjdXJpdHkgc3RhdGUgKGUuZy4sIGZyYW1lIGNvdW50ZXJz KSwgd2hpY2ggaXMgbm90IHRoZSBjYXNlIGlmIG9uZSB3b3VsZCBzZW5kIHVuc2VjdXJlZCB0cmFm ZmljIGFuZCB1c2UgdGhlICZxdW90O2V4ZW1wdCBzdGF0dXMmcXVvdDsgY29uc3RydWN0IGluc3Rl YWQuIFBEIHN1bW1hcml6ZWQgdGhhdCB1c2luZyB1bnNlY3VyZWQgZnJhbWVzLCByYXRoZXIgdGhh bg0KICZxdW90O2Zha2UmcXVvdDsgc2VjdXJpdHkgd2l0aCAmcXVvdDtkZWZhdWx0IGtleXMmcXVv dDssIHNob3VsZCBiZSBhZG9wdGVkLCB3aGljaCB3YXMgY29uc2Vuc3VzIG9uIHRoZSBjYWxsLjxi cj4NCjxicj4NClBHIGNhbWUgYmFjayB0byB0aGUgJnF1b3Q7ZXhlbXB0IGZsYWcmcXVvdDsgdG9w aWMgYW5kIHN1Z2dlc3RlZCB0aGF0IGRldGFpbHMgaGVyZW9mIGFyZSBpbiB0aGUgJnF1b3Q7ZGV2 aWNlIGRlc2NyaXB0b3IgbG9va3VwIHRhYmxlJnF1b3Q7LiBSUyBzdWdnZXN0ZWQgdGhhdCB3ZSBh bGwgaGF2ZSBhIGNsb3NlciBsb29rIGF0IHNwZWNpZmljYXRpb24gZGV0YWlscywgc28gdGhhdCBz d2l0Y2hpbmcgdGhpcyBmZWF0dXJlIG9uL29mZiBjb3VsZCBiZSBlYXNpbHkgY29kaWZpZWQgZm9y IDZUaVNDSA0KIHVzZS48YnI+DQo8YnI+DQo1LiBKb2luIHByb2Nlc3MgLSBub24tTUFDIGJlaGF2 aW9yLjxicj4NCkdpdmVuIHJlbWFpbmluZyB0aW1lIG9uIHRoZSBjYWxsIHdvdWxkIG5vdCBhbGxv dyBmdWxsIGRpc2N1c3Npb24gb2Ygbm9uLU1BQyBhc3BlY3RzIChTbGlkZXMgMjMtMjUpIGFuZCBn aXZlbiB0aGF0IE1SIGhhZCB0byBkcm9wIG9mZiB0aGUgY2FsbCwgaXQgd2FzIGRlY2lkZWQgdG8g cmV2aXNpdCB0aG9zZSB0b3BpY3MgYXQgdGhlIG5leHQgY29uZiBjYWxsLjxicj4NCjxicj4NCjYu IEFPQiBDb25mIGNhbGwgc2NoZWR1bGluZy48YnI+DQpTRCBzdWdnZXN0ZWQgaGUgd2FzIGNvbmZ1 c2VkIGFib3V0IGhhdmluZyB0d28gY2FsbCB0aW1lcyBpbiBlbWFpbCB0cmFmZmljIChvbmUgYXQg OWFtIEVTVCBhbmQgb25lIGF0IDExYW0gRVNUKSBhbmQgc3VnZ2VzdGVkIHRoYXQgb3RoZXIgZ3Jv dXBzLCBzdWNoIGFzLCBlLmcuLCBJRUVFLCBvZnRlbiB1c2UgY3ljbGljIHNjaGVkdWxlLCBzbyBh cyB0byBhY2NvbW1vZGF0ZSBwYXJ0aWNpcGFudHMgZnJvbSBhcm91bmQgdGhlIHdvcmxkIGFuZCB3 aG8gbWF5DQogYmUgYXQgd2lkZWx5IGRpZmZlcmVudCB0aW1lIHpvbmVzLiBSUyB2b2x1bnRlZXJl ZCB0byBsb29rIGludG8gdGhpcyB0b3BpYyBhbmQgb2J0YWluIGZlZWRiYWNrIG9uIHN1Y2ggYSBz Y2hlZHVsZS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsIFJlbmU8YnI+DQo8YnI+DQpPbiAxMi8x LzIwMTQgMTE6NTUgQU0sIFJlbmUgU3RydWlrIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlByb3Bvc2VkIGFnZW5kYTo8YnI+DQo8YnI+DQowKSBBZ2VuZGEgYmFzaGluZzxicj4NCjxicj4N CjEpIEpvaW4gcHJvdG9jb2wgZGV0YWlsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmEpIGRlc2lyZWQgcHJvcGVydGllczxi cj4NCmIpIHJlYWxpemFibGUgcHJvcGVydGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBOZXh0 IHN0ZXBzOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgYSkgY29u c2Vuc3VzIG9uIDEjYSBhbmQgMSNiPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGIpIGZvcm0gdGlnZXIgdGVhbSB0byB3b3JrIG91dCBkZXRhaWxzPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg LSBwcm9qZWN0IHBoYXNlczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gY29tbXVuaWNhdGlvbiBvZiBzdWItcmVzdWx0czxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgYykgd2hhdCB0byBzcXVlZXpl IGludG8gYXJjaGl0ZWN0dXJlIGRyYWZ0LCBldGMuPGJyPg0KPGJyPg0KSSB3aWxsIHByZXBhcmUg bWF0ZXJpYWwgdG8gZmFjaWxpdGF0ZSBkaXNjdXNzaW9uIG9uIDEpIGFuZCAyKSwgdG8gYmUgZGlz Y3Vzc2VkIGR1cmluZyB0aGUgY2FsbC48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHMsIFJlbmU8YnI+ DQo8YnI+DQo8YnI+DQpPbiAxMS8yOC8yMDE0IDExOjAyIEFNLCBSZW5lIFN0cnVpayB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZWFyIGNvbGxlYWd1ZXM6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K SSBoYXZlIHNldCB1cCBhIGNvbmYgY2FsbCBmb3IgVHVlc2RheSBEZWNlbWJlciAyLCAyMDE0IGF0 IGEgdGltZSB0aGF0IHRyaWVzIGFuZCBhY2NvbW1vZGF0ZSBwZW9wbGUgaW4gZGlmZmVyZW50IHRp bWUgem9uZXMgdG8gdGhlIGxhcmdlc3QgZXh0ZW50IHBvc3NpYmxlLCB3aXRob3V0IHRyeWluZyB0 byBkaXNjcmltaW5hdGUgYWdhaW5zdCB2YXJpb3VzIHBhcnRzIG9mIHRoZSB3b3JsZC48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpQbGVhc2Ug c2VlIGRpYWwtaW4gaW5mb3JtYXRpb24gYmVsb3cuIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFnZW5kYSB0byBmb2xsb3cgTW9uZGF5IGFy b3VuZCBub29uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NCkxvb2tpbmcgZm9yd2FyZCB0byBhIGNvbGxhYm9yYXRpdmUgbWVldGluZywgaW4g Z29vZCBzcGlyaXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcywg UmVuZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPj09 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEuJm5ic3A7IFBsZWFzZSBqb2luIG15IG1l ZXRpbmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PGEgaHJlZj0iaHR0cHM6Ly9nbG9iYWwuZ290b21lZXRpbmcuY29tL2pvaW4vNTk0Mjk5MDYxIj5o dHRwczovL2dsb2JhbC5nb3RvbWVldGluZy5jb20vam9pbi81OTQyOTkwNjE8L2E+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Mi4mbmJzcDsgVXNlIHlv dXIgbWljcm9waG9uZSBhbmQgc3BlYWtlcnMgKFZvSVApIC0gYSBoZWFkc2V0IGlzIHJlY29tbWVu ZGVkLiZuYnNwOyBPciwgY2FsbCBpbiB1c2luZyB5b3VyIHRlbGVwaG9uZS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EaWFsICYjNDM7MSAoNjQ3KSA0 OTctOTM1MTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkFjY2VzcyBDb2RlOiA1OTQtMjk5LTA2MTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5v bmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkF1ZGlvIFBJTjogU2hvd24gYWZ0ZXIgam9pbmluZyB0aGUgbWVl dGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1l ZXRpbmcgUGFzc3dvcmQ6IGNvbGxhYm9yYXRlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6 bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+TWVldGluZyBJRDogNTk0LTI5OS0wNjE8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Hb1RvTWVldGluZ8KuIDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9ubGluZSBNZWV0 aW5ncyBNYWRlIEVhc3nCrjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPk5vdCBhdCB5b3VyIGNvbXB1dGVyPyBDbGljayB0aGUgbGluayB0byBqb2luIHRo aXMgbWVldGluZyBmcm9tIHlvdXIgaVBob25lwq4sIGlQYWTCriwgQW5kcm9pZMKuIG9yIFdpbmRv d3MgUGhvbmXCriBkZXZpY2UgdmlhIHRoZSBHb1RvTWVldGluZyBhcHAuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJpZiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0K W2V4Y2VycHQgZW1haWwgYXMgb2YgVGh1IE5vdmVtYmVyIDI3LCAyMDE0LCA5LjQycG0gRVNUXTxi cj4NCkkgc3VnZ2VzdCA5YW0gRVNUID0gNmFtIFBTVCA9IDNwbSBQYXJpcyA9IDExcG0gSmFwYW4u IFRoaXMgc2hvdWxkIGFsbG93IHBlb3BsZSB0byBoYXZlIHRoZWlyIHByaXZhdGUgdGltZSBpbiB0 aGUgMTJhbS02YW0gdGltZSB3aW5kb3cuIHtPdGhlciBncm91cHMgZG8gYSBtdWNoIGJldHRlciBq b2IgYXQgdGhpcy4uLn0NCjxicj4NCjxicj4NCjxicj4NCk9uIDExLzI4LzIwMTQgMTA6MzkgQU0s IE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJp ciBEYXMgPGEgaHJlZj0ibWFpbHRvOnN1YmlyZGFzMjFAZ21haWwuY29tIj4mbHQ7c3ViaXJkYXMy MUBnbWFpbC5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoYW5rcyBmb3IgYXJy YW5naW5nIHRoZSBjYWxscy4gSXQgd291bGQgYmUgZ29vZCB0byBhY2NvbW1vZGF0ZSBBc2lhbiB0 aW1lPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyB6b25lIGZvciBicm9hZGVyIHBhcnRpY2lwYXRpb24uIEkgd291 bGQgc3VnZ2VzdCBjaG9vc2luZyBhIHRpbWUgdGhhdCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5JJ20gaGFwcHkgdG8gZG8gdGhpcyBhdCBhbm90aGVy IHRpbWU7IHRoZSBvcmlnaW5hbCBjaG9pY2Ugb2YgMTFhbSBFYXN0ZXJuIHdhczxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+dG8gYWNjb21vZGF0ZSBQYWNp ZmljIFRpbWUgWm9uZSBQZW9wbGUgd2hvIGNvdWxkbid0IG1lZXQgYmVmb3JlIDhhbS4mbmJzcDsg PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtGcm9t IGxvbmcgZXhwZXJpZW5jZSwgb3VyIGNob2ljZXMgZXNzZW50aWFsbHkgYXJlIGF0IDE1OjAwIFVU QyBvciAwMzowMCBVVEMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgMDc6MDAgUGFjaWZpYy8xMDowMCBFYXN0ZXJuIC8g MTc6MDAgSGVsc2lua2kvMjI6MDAgQmVpamluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyAxOTowMCBQYWNpZmljLzIyOjAwIEVh c3Rlcm4gLyAwNTowMCBIZWxzaW5raS8xMDowMCBCZWlqaW5nPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gYWxzbyBoYXBweSB0byBhbHRlcm5hdGUu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TaGFsbCBJ IHB1dCB1cCBhIGRvb2RsZSBwb2xsPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuICxzZXJpZiZxdW90OyxzZXJpZiI+PGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+NnRpc2NoLXNlY3VyaXR5IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOjZ0 aXNjaC1zZWN1cml0eUBpZXRmLm9yZyI+NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gtc2VjdXJpdHkiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoLXNlY3VyaXR5PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiAsc2VyaWYmcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5lbWFpbDogPGEgaHJlZj0ibWFpbHRvOnJzdHJ1aWsuZXh0QGdt YWlsLmNvbSI+cnN0cnVpay5leHRAZ21haWwuY29tPC9hPiB8IFNreXBlOiByc3RydWlrPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jZWxsOiAmIzQzOzEg KDY0NykgODY3LTU2NTggfCBVUzogJiM0MzsxICg0MTUpIDY5MC03MzYzPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuICxzZXJpZiZxdW90OyxzZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPmVtYWlsOiA8YSBocmVmPSJtYWlsdG86cnN0cnVpay5leHRAZ21haWwuY29tIj5y c3RydWlrLmV4dEBnbWFpbC5jb208L2E+IHwgU2t5cGU6IHJzdHJ1aWs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmNlbGw6ICYjNDM7MSAoNjQ3KSA4Njct NTY1OCB8IFVTOiAmIzQzOzEgKDQxNSkgNjkwLTczNjM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4g LHNlcmlmJnF1b3Q7LHNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20iPnJzdHJ1aWsuZXh0 QGdtYWlsLmNvbTwvYT4gfCBTa3lwZTogcnN0cnVpazxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y2VsbDogJiM0MzsxICg2NDcpIDg2Ny01NjU4IHwgVVM6 ICYjNDM7MSAoNDE1KSA2OTAtNzM2MzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDvvLDjgrTjgrfjg4Pjgq8mcXVv dDsiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20iPnJz dHJ1aWsuZXh0QGdtYWlsLmNvbTwvYT4gfCBTa3lwZTogcnN0cnVpazxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y2VsbDogJiM0MzsxICg2NDcpIDg2Ny01 NjU4IHwgVVM6ICYjNDM7MSAoNDE1KSA2OTAtNzM2MzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDvvLDjgrTjgrfj g4Pjgq8mcXVvdDsiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpyc3RydWlrLmV4dEBnbWFp bC5jb20iPnJzdHJ1aWsuZXh0QGdtYWlsLmNvbTwvYT4gfCBTa3lwZTogcnN0cnVpazxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y2VsbDogJiM0MzsxICg2 NDcpIDg2Ny01NjU4IHwgVVM6ICYjNDM7MSAoNDE1KSA2OTAtNzM2MzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_674F70E5F2BE564CB06B6901FD3DD78B29D0EB52TGXML210toshiba_-- From nobody Tue Dec 9 08:37:21 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B511A8986 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 08:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwPQT-eolgpu for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 08:37:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3001A894F for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 08:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12605; q=dns/txt; s=iport; t=1418143033; x=1419352633; h=from:to:cc:subject:date:message-id:mime-version; bh=s8ZIMi977H1U+Qv/9IbEL6vwNPlboi/bVYRvL643yCI=; b=YJ/XUbtt90hWbRlYH9W3wrqnahsVd3Vj522zzKF91sLZVwvo7rpWtpyr Ppv6Xqs3MeR/rMOr+IFpDKFCkvsvQVgX8uZxNzee1xa72e26HIzce1FNv PAKVtMoDuOOHYm499rjSEKrVRtKXs9saP4eUDc76FANOTSr9ueSuZjZ/k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIkkh1StJA2E/2dsb2JhbABZgkNDUlzDeIgvAoEmFgEBAQEBfYQEAQQtRwUSARoQVhcPAQQBDQ2IMNceAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5ALMYMogRUFjg2KIoJfjX6DboF0JBx+AQEB X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208,217";a="104087824" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 09 Dec 2014 16:37:12 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB9GbBcU022314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:37:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.39]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 10:37:10 -0600 From: "Pascal Thubert (pthubert)" To: Michael Richardson , Rene Struik Thread-Topic: Proposed text for archie Thread-Index: AdATzjmZJHu11c8wSquZ34lo47VkwQ== Date: Tue, 9 Dec 2014 16:37:10 +0000 Deferred-Delivery: Tue, 9 Dec 2014 16:37:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.196.91] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848AB3927xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/8vM0cnWvx9sMfYdg756PRrqUDjM Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: [6tisch-security] Proposed text for archie 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, 09 Dec 2014 16:37:19 -0000 --_000_E045AECD98228444A58C61C200AE1BD848AB3927xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: Please find my summary of our recent discussions with the sort of level I w= ould expect for the archi spec at this stage. " The join process is the process by which a node, virtually out of the box, = will discover a network, get authenticated and authorized in the network, o= btain credentials to participate to the network, and obatin reachability th= rough the network. The architecture specifies 3 logical elements to describe the join process: - a Joining Node (JN), that is yet not authenticated to participate to the = network, - a Join Assistant (JA), that is already participating to the network, and = is reachable over the network - a Join Coordination Entity, that is the front end for authentication and = authorization for the JA. The text below makes a difference between a join IPv6 link and other IPv6 l= inks in the production network. With 6TiSCH, an IPv6 link is associated in = each node with a particular bundle of cells for multicast transmissions. Th= e production network can be a multilink subnet of such IPv6 links. In some = networks, the join process may happen on that bundle, using the production = prefix, but this exposes production information and may not be desirable. I= n a more secure mode, a separate IPv6 link, and associated bundle is define= d in each individual JA. A particular ULA prefix t is locally assigned by t= he JA for use in that IPv6 link and is not exposed to the routing fabric in= the production network. The ULA prefix uniquely indicates the particular j= oin link on which it is exposed. At the beginning of times, the JA exposes a joining set of information in a= beacon. This information includes link information for the bundle that can= be used to join (schedule IE...) and routing information (RA message). The= JN scans the network till it gets such message. The message is signed and = may be encrypted with a well-known key, but for all practical purpose it is= considered in the clear. The prefix in the RA exposes the ULA prefix when = that mode is used, as opposed to the production prefix. Upon reception of the beacon, the JN forms an address from the prefix in th= e RA. This address is not injected in the routing fabric, and no state is f= ormed in the network for that particular address. The JN contacts the JA to= join the network using that address, and the JA relays the request to the = JCE by encapsulating it in a JA-to-JCE message. At this stage, a DoS attack= by a rogue JN can only be local to the JA. The JA may throttle join reques= ts or perform additional checks to defeat such attacks. The size of the joi= n bundle for that particular JA is another constraint that limits DoS attac= k. The JN may store an ND cache mapping the ULA address of the JN with the = MAC address of the JN, but it does not need to. Upon reception of the join request from the JA, the JCE stores the request = to be processed asynchronously or dropped. When the JCE decides to respond,= it contacts the JN directly and establishes an end-to-end JCE-to-JN DTLS c= onnection. At that point of time, the JA can reach the JN's address over th= e join bundle, but the JN address is not advertised over the routing fabric= , so it cannot be reached directly from the JCE. To reach the JN, the JCE s= ets the destination address in the IP packet as the JA, and inserts a RH ty= pe 2 indicating the address of the JN, which only the JA can route to. The = JA receives the packet, processes the RH2. The prefix (e.g. a ULA) indicate= s which IPv6 link (which bundle) can be used to reach the JN. The JA resolv= es the MAC address of the JN (either using an NS/NA exchange or implicitly = if the IID is based on MAC-64), and forwards the packet to the JN. When the exchange between the JN and the JCE is completed, the JN owns a ne= twork key that it can use in the production network. The JN contacts the JA= again using an encrypted RS message. The JA responds with an encrypted RA = message with information on the production network. The relevant IEs are pa= ssed with the RA message so the JN may now form an address in the productio= n network. At that point, the JN uses efficient ND to validate its address,= and the 6LR -typically but not necessarily the JA) injects that address in= the LLN using RPL, as discussed earlier in the architecture. " Does this reflect a common consensus? Pascal --_000_E045AECD98228444A58C61C200AE1BD848AB3927xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

Please find my summary of our recent discussions wit= h the sort of level I would expect for the archi spec at this stage.

 

“

 

The join process is the process by which a node, vir= tually out of the box, will discover a network, get authenticated and autho= rized in the network, obtain credentials to participate to the network, and= obatin reachability through the network.

 

The architecture specifies 3 logical elements to des= cribe the join process:

- a Joining Node (JN), that is yet not authenticated= to participate to the network,  

- a Join Assistant (JA), that is already participati= ng to the network, and is reachable over the network

- a Join Coordination Entity, that is the front end = for authentication and authorization for the JA.

 

The text below makes a difference between a join IPv= 6 link and other IPv6 links in the production network. With 6TiSCH, an IPv6= link is associated in each node with a particular bundle of cells for mult= icast transmissions. The production network can be a multilink subnet of such IPv6 links. In some networks, th= e join process may happen on that bundle, using the production prefix, but = this exposes production information and may not be desirable. In a more sec= ure mode, a separate IPv6 link, and associated bundle is defined in each individual JA. A particular ULA p= refix t is locally assigned by the JA for use in that IPv6 link and is not = exposed to the routing fabric in the production network. The ULA prefix uni= quely indicates the particular join link on which it is exposed.

 

 

At the beginning of times, the JA exposes a joining = set of information in a beacon. This information includes link information = for the bundle that can be used to join (schedule IE…) and routing in= formation (RA message). The JN scans the network till it gets such message. The message is signed and may be encryp= ted with a well-known key, but for all practical purpose it is considered i= n the clear. The prefix in the RA exposes the ULA prefix when that mode is = used, as opposed to the production prefix.

 

Upon reception of the beacon, the JN forms an addres= s from the prefix in the RA. This address is not injected in the routing fa= bric, and no state is formed in the network for that particular address. Th= e JN contacts the JA to join the network using that address, and the JA relays the request to the JCE by encapsulat= ing it in a JA-to-JCE message. At this stage, a DoS attack by a rogue JN ca= n only be local to the JA. The JA may throttle join requests or perform add= itional checks to defeat such attacks. The size of the join bundle for that particular JA is another constraint t= hat limits DoS attack. The JN may store an ND cache mapping the ULA address= of the JN with the MAC address of the JN, but it does not need to.

 

Upon reception of the join request from the JA, the = JCE stores the request to be processed asynchronously or dropped. When the = JCE decides to respond, it contacts the JN directly and establishes an end-= to-end JCE-to-JN DTLS connection. At that point of time, the JA can reach the JN’s address over the jo= in bundle, but the JN address is not advertised over the routing fabric, so= it cannot be reached directly from the JCE. To reach the JN, the JCE sets = the destination address in the IP packet as the JA, and inserts a RH type 2 indicating the address of the JN, which= only the JA can route to. The JA receives the packet, processes the RH2. T= he prefix (e.g. a ULA) indicates which IPv6 link (which bundle) can be used= to reach the JN. The JA resolves the MAC address of the JN (either using an NS/NA exchange or implicitly if= the IID is based on MAC-64), and forwards the packet to the JN.=

 

When the exchange between the JN and the JCE is comp= leted, the JN owns a network key that it can use in the production network.= The JN contacts the JA again using an encrypted RS message. The JA respond= s with an encrypted RA message with information on the production network. The relevant IEs are passed with th= e RA message so the JN may now form an address in the production network. A= t that point, the JN uses efficient ND to validate its address, and the 6LR= –typically but not necessarily the JA) injects that address in the LLN using RPL, as discussed earlier in= the architecture.

 

“

 

Does this reflect a common consensus?

 

Pascal

--_000_E045AECD98228444A58C61C200AE1BD848AB3927xmbrcdx01ciscoc_-- From nobody Tue Dec 9 09:46:27 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 5CDA61A8A1E for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 09:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 QR20akmcyLUp for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 09:46:17 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E81E1A8A0E for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 09:46:17 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y10so972643pdj.34 for <6tisch-security@ietf.org>; Tue, 09 Dec 2014 09:46:16 -0800 (PST) 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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qS6RrotS4D++/8mVh481AFLiQpuyX1XdJAjDR65Mb3g=; b=CSn1+5AvWL0N4NTZCmgPh0pIzgZhjcDbZL+hklBpPKihhtxPy1kf12tqgqIFm7msKl bFsvhfHh4fQRU5feZ+8jgszv8f4sTBGWhRj7cEZrvr2ZCG8xrUheu1hBp+BsjT8qMZuN W7pdu0o9viBXjLiIYY4SYv5+jpc1SmY8CYHENBYSOsMrN+DV4yYP1O64G5yMHNS2Tj6g T2N2SKfKkQ03K4CkU94QppZF9+b0niIWquGr52qRwBSE6JWZkV2Kp/YYJPu/OhO4k1DD bNLaGJGN7+NJW4Mh9Umf4zL2hvrnPzAnVNNspIAzPFxpKTafqb3+yxi3ZdhFXysUCSzG MU9g== X-Gm-Message-State: ALoCoQmlmIwn12Ocwzdwa47unx5UM1kDC/oH+6VSxoi4/hJxfQfsxnC5kZF8mGsj9SnlaPt+1XuM X-Received: by 10.68.68.227 with SMTP id z3mr7534277pbt.3.1418147175910; Tue, 09 Dec 2014 09:46:15 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id t9sm2004282pbs.75.2014.12.09.09.46.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 09:46:15 -0800 (PST) Message-ID: <54873561.9030106@berkeley.edu> Date: Tue, 09 Dec 2014 09:46:09 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Struik , tisch-security <6tisch-security@ietf.org> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> In-Reply-To: <548657C3.8030308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/QwWxPJWBNWuGCIKTLW-rb2JQ5Fk Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 17:46:25 -0000 So the idea is that misinterpreting a frame from a completely different type of network is not a problem? I guess that it will just cause the joining node to try to initiate an authentication exchange that won't go anywhere. Maybe that's ok, but it leaves us open to *unintentional* denial of service attacks. I'd feel a little better about it if the proponents of "no fake keys" would acknowledge the concerns of the "well-known key" gang. We've said repeatedly that "well known" is not about security, it's about avoiding unintentional misinterpretation of foreign packets. We get that a well known key provides zero security. Do you get that the aether is filled with packets that don't abide by 6lowpan dispatch bytes, or even IEEE MAC header conventions? ksjp On 12/8/2014 6:00 PM, Rene Struik wrote: > PD summarized that using unsecured frames, rather than "fake" security > with "default keys", should be adopted, which was consensus on the call. From nobody Tue Dec 9 10:09:51 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E601A1A5B for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 10:09:49 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nYB4QWijbWRV for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 10:09:45 -0800 (PST) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8AF1A0161 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 10:09:45 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o142.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 8ea37845.0.94617.00-267.270145.p01c11o142.mxlogic.net (envelope-from ); Tue, 09 Dec 2014 11:09:45 -0700 (MST) X-MXL-Hash: 54873ae91c7af401-a110de2fcdf0c208fe8169b6845779f2b7d1e5c8 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id CF9D274095 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 10:09:42 -0800 (PST) From: Jonathan Simon Content-Type: multipart/alternative; boundary="Apple-Mail=_72F16F61-6C14-4E57-93D3-BB650BFC0F62" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 9 Dec 2014 10:09:30 -0800 References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> To: tisch-security <6tisch-security@ietf.org> In-Reply-To: <54873561.9030106@berkeley.edu> X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=GoBW+yFC c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=SyYMxH9GAAAA:8 a=XJwUhC5Vyd3FXRSC9kAA:9 a=Sw4i86Us] X-AnalysisOut: [Ew9LaH8C:21 a=S3lALl0oPwuMopil:21 a=pILNOxqGKmIA:10 a=zAgm] X-AnalysisOut: [LXHU5n4bMXN0GQgA:9 a=pqHXnhla8NI6wNZs:21 a=9zhM7Q8CWiUCu8m] X-AnalysisOut: [I:21 a=k5xwLkV3Zig0gao9:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014120916); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/IKDUaLsbbzA9N6k2uaXss0m5rrg Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:09:49 -0000 --Apple-Mail=_72F16F61-6C14-4E57-93D3-BB650BFC0F62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am kind of baffled at the direction this group seems to have taken. We all agreed that touchless operation is the goal. So beacons need to = be authenticated with a well-known key (yes, I know this does nothing = for security - this provides for protocol separation only). Mixing of = unauthenticated and authenticated frames is a non-issue, since = everything is authenticated. I don=92t understand the value of saving = a beacon key configured at a higher layer, as a) the network has to send = the beacons unencrypted for touchless operation, b) you don=92t get any = security benefit if a device is going to accept the beacon contents = regardless, and c) a device has to be able to fall back to the = well-known key any time, since the saved key may be stale (node moved, = node slept while key was changing, node is allowed in multiple = overlapping networks using different keys, etc.) This is all distraction from the real problem we have to solve: how do = we agree on session keys that allow a device and a PCE to exchange MAC = configuration messages in a minimal number of frames, and do so in a = touchless way. Everything else is either irrelevant, or application = policy. -- Jonathan Simon, Ph. D jsimon@linear.com On Dec 9, 2014, at 9:46 AM, Kris Pister wrote: > So the idea is that misinterpreting a frame from a completely = different type of network > is not a problem? > I guess that it will just cause the joining node to try to initiate an = authentication exchange > that won't go anywhere. Maybe that's ok, but it leaves us open to = *unintentional* denial > of service attacks. >=20 > I'd feel a little better about it if the proponents of "no fake keys" = would acknowledge > the concerns of the "well-known key" gang. We've said repeatedly that = "well known" > is not about security, it's about avoiding unintentional = misinterpretation of foreign packets. > We get that a well known key provides zero security. > Do you get that the aether is filled with packets that don't abide by = 6lowpan dispatch bytes, > or even IEEE MAC header conventions? >=20 > ksjp >=20 > On 12/8/2014 6:00 PM, Rene Struik wrote: >> PD summarized that using unsecured frames, rather than "fake" = security with "default keys", should be adopted, which was consensus on = the call. >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > = http://cp.mcafee.com/d/2DRPos81NJ5x5V5wsyYedTdEK3CkPqbwVBYSyUed7aar9EVdKff= fecnKr4qilH057Ox-NVsSva7X7BPr8VZAsYM_R-73Akn7KLsKCONvAm4NPXzfbnjIyCGztzBgY= -F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDa= BypuDSrzapoKgGT2TQ1kLCXM04SVssyr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEw= JmcvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJ= FVVEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45= Jffd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05J= zaxEwed42aaOFEw0zlJwrjhvdBO7_ --Apple-Mail=_72F16F61-6C14-4E57-93D3-BB650BFC0F62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I am kind of baffled at the = direction this group seems to have taken.

We = all agreed that touchless operation is the goal.  So beacons need = to be authenticated with a well-known key (yes, I know this does nothing = for security - this provides for protocol separation only).  Mixing = of unauthenticated and authenticated frames is a non-issue, since = everything is authenticated.   I don=92t understand the value of = saving a beacon key configured at a higher layer, as a) the network has = to send the beacons unencrypted for touchless operation, b) you don=92t = get any security benefit if a device is going to accept the beacon = contents regardless, and c) a device has to be able to fall back to the = well-known key any time, since the saved key may be stale (node moved, = node slept while key was changing, node is allowed in multiple = overlapping networks using different keys, etc.)

This is all distraction from the real problem we have to = solve:  how do we agree on session keys that allow a device and a = PCE to exchange MAC configuration messages in a minimal number of = frames, and do so in a touchless way.  Everything else is either = irrelevant, or application policy.

--
Jonathan Simon, Ph. D
jsimon@linear.com

On Dec 9, 2014, at 9:46 AM, = Kris Pister <ksjp@berkeley.edu> = wrote:

So the idea is that misinterpreting a frame from a = completely different type of network
is not a problem?
I guess = that it will just cause the joining node to try to initiate an = authentication exchange
that won't go anywhere.  Maybe that's = ok, but it leaves us open to *unintentional* denial
of service = attacks.

I'd feel a little better about it if the proponents of = "no fake keys" would acknowledge
the concerns of the "well-known key" = gang.  We've said repeatedly that "well known"
is not about = security, it's about avoiding unintentional misinterpretation of foreign = packets.
We get that a well known key provides zero security.
Do = you get that the aether is filled with packets that don't abide by = 6lowpan dispatch bytes,
or even IEEE MAC header = conventions?

ksjp

On 12/8/2014 6:00 PM, Rene Struik = wrote:
PD summarized that using unsecured = frames, rather than "fake" security with "default keys", should be = adopted, which was consensus on the = call.

_______________________________________________<= br>6tisch-security mailing list
6tisch-security@ietf.org
h= ttp://cp.mcafee.com/d/2DRPos81NJ5x5V5wsyYedTdEK3CkPqbwVBYSyUed7aar9EVdKfff= ecnKr4qilH057Ox-NVsSva7X7BPr8VZAsYM_R-73Akn7KLsKCONvAm4NPXzfbnjIyCGztzBgY-= F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaB= ypuDSrzapoKgGT2TQ1kLCXM04SVssyr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEwJ= mcvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJF= VVEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45J= ffd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05Jz= axEwed42aaOFEw0zlJwrjhvdBO7_

= --Apple-Mail=_72F16F61-6C14-4E57-93D3-BB650BFC0F62-- From nobody Tue Dec 9 11:32:01 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27521A87CC for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 11:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G934PcZY2uAk for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 11:31:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F3B1A87C7 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 11:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16136; q=dns/txt; s=iport; t=1418153509; x=1419363109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YifOOdHI7VrB5FTmmlEUYLbpHLdEiYW6y/FzCrrT5uY=; b=ZSrInYNgAlLUVOlMqVGimth/brytnQb9enpyt68asNdiM5m5GSsyHdCT vM2RmBxGf5vsptJhmybVPkXVgcW8JU4ZI600AopaMPPdOI0UWAFgB/GKP Oy6uuVMKUSA1H9lHIwLpdZZW6ut4aBtsnGUeMgokKoHEywYxcWl5abOSp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8HAAtNh1StJV2a/2dsb2JhbABZgwZSWIMFwHg8gWABCoU6TgIcgQ8WAQEBAQF9hAMBAQQBAQEgSwsQAgEIDi0EAwICAiULFBECBA4FiDgNwCeXGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReNAwGCYD0XBAeCbzKBFQWODYNZhTyJU4gXgX4QDhSBPm+BA4FAAQEB X-IronPort-AV: E=Sophos;i="5.07,547,1413244800"; d="scan'208,217";a="104130986" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 09 Dec 2014 19:31:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB9JVmRr003117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 19:31:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.39]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 13:31:48 -0600 From: "Pascal Thubert (pthubert)" To: Jonathan Simon Thread-Topic: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan Thread-Index: AQHQE9tW0TeAimkCfUGoaRpnApOoa5yICmuA Date: Tue, 9 Dec 2014 19:31:47 +0000 Message-ID: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AE731AF8FE24426494B4A6A06F756F97ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ZBUUc5ipzru8KGyJqd6Yj3-9jFs Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 19:31:56 -0000 --_000_AE731AF8FE24426494B4A6A06F756F97ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBKb25hdGhhbg0KDQpJIHRyaWVkIHRvIHByb3Bvc2UgdGV4dCB0aGF0IGlzIGluZGVw ZW5kZW50IG9uIHRoYXQgZGVjaXNpb24gdGhpcyBtb3JuaW5nIGJ1dCBJIHN0cm9uZ2x5IGZhdm9y IHVzaW5nIGEga2V5IHRvIGRpZmZlcmVudGlhdGUgbmV0d29ya3MgaWYgYXQgYWxsIHBvc3NpYmxl Lg0KDQpUaGUgYXJndW1lbnQgb2YgZmFzdGVyIHJlam9pbiBJIGhhdmUgYSBoYXJkIHRpbWUgYWNj ZXB0aW5nIHNpbmNlIEkgc2VlIHRoZSB2YWx1ZSBvZiBhIGpvaW4gbGluayB0aGF0IGlzIG5vdCB0 YWtlbiBmcm9tIHRoZSBwcm9kdWN0aW9uIHNjaGVkdWxlIGFuZCB1c2VzIGEgZGlmZmVyZW50IHBy ZWZpeC4gU28gdGhlIHJlam9pbiB3b3JrcyBpZiB5b3Ugc3RpbGwgaGF2ZSBhIGtleSBhbmQgYXRl IHN0aWxsIGluIHN5bmMsIGFuZCBpbiB0aGF0IGNhc2UgeW91IGNhbiByZXN0YXJ0IGZyb20gdGhl IFJTL1JBIGluIG15IGZsb3cuDQoNCkFub3RoZXIgYXNwZWN0IG9mIHRoZSBqb2luIGxpbmsgd291 bGQgYmUgYSBzbG93ZXIgaG9waW5nIHNjaGVkdWxlIHRvIGFjY29tbW9kYXRlIHJlam9pbiBvZiBh IG5vZGUgd2l0aCBsaW1pdGVkIFJUQyBjYXBhYmlsaXRpZXMgYWZ0ZXIgYSBkYXkncyBzbGVlcC4g VGhpcyBpcyBzb21ldGhpbmcgb2YgZGVlcCBpbnRlcmVzdCBpbiBOQU4gYXBwbGljYXRpb25zIGFu ZCB3b3VsZCBtYWtlIDZUaVNDSCBhIHN0cm9uZyBjb250ZW5kZXIuDQoNCkNhbiB0aGF0IGJlIGFj Y29tbW9kYXRlZD8NCg0KDQoNClBhc2NhbA0KDQpMZSA5IGTDqWMuIDIwMTQgw6AgMTI6MDksIEpv bmF0aGFuIFNpbW9uIDxqc2ltb25AbGluZWFyLmNvbTxtYWlsdG86anNpbW9uQGxpbmVhci5jb20+ PiBhIMOpY3JpdCA6DQoNCkkgYW0ga2luZCBvZiBiYWZmbGVkIGF0IHRoZSBkaXJlY3Rpb24gdGhp cyBncm91cCBzZWVtcyB0byBoYXZlIHRha2VuLg0KDQpXZSBhbGwgYWdyZWVkIHRoYXQgdG91Y2hs ZXNzIG9wZXJhdGlvbiBpcyB0aGUgZ29hbC4gIFNvIGJlYWNvbnMgbmVlZCB0byBiZSBhdXRoZW50 aWNhdGVkIHdpdGggYSB3ZWxsLWtub3duIGtleSAoeWVzLCBJIGtub3cgdGhpcyBkb2VzIG5vdGhp bmcgZm9yIHNlY3VyaXR5IC0gdGhpcyBwcm92aWRlcyBmb3IgcHJvdG9jb2wgc2VwYXJhdGlvbiBv bmx5KS4gIE1peGluZyBvZiB1bmF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgZnJhbWVz IGlzIGEgbm9uLWlzc3VlLCBzaW5jZSBldmVyeXRoaW5nIGlzIGF1dGhlbnRpY2F0ZWQuICAgSSBk b27igJl0IHVuZGVyc3RhbmQgdGhlIHZhbHVlIG9mIHNhdmluZyBhIGJlYWNvbiBrZXkgY29uZmln dXJlZCBhdCBhIGhpZ2hlciBsYXllciwgYXMgYSkgdGhlIG5ldHdvcmsgaGFzIHRvIHNlbmQgdGhl IGJlYWNvbnMgdW5lbmNyeXB0ZWQgZm9yIHRvdWNobGVzcyBvcGVyYXRpb24sIGIpIHlvdSBkb27i gJl0IGdldCBhbnkgc2VjdXJpdHkgYmVuZWZpdCBpZiBhIGRldmljZSBpcyBnb2luZyB0byBhY2Nl cHQgdGhlIGJlYWNvbiBjb250ZW50cyByZWdhcmRsZXNzLCBhbmQgYykgYSBkZXZpY2UgaGFzIHRv IGJlIGFibGUgdG8gZmFsbCBiYWNrIHRvIHRoZSB3ZWxsLWtub3duIGtleSBhbnkgdGltZSwgc2lu Y2UgdGhlIHNhdmVkIGtleSBtYXkgYmUgc3RhbGUgKG5vZGUgbW92ZWQsIG5vZGUgc2xlcHQgd2hp bGUga2V5IHdhcyBjaGFuZ2luZywgbm9kZSBpcyBhbGxvd2VkIGluIG11bHRpcGxlIG92ZXJsYXBw aW5nIG5ldHdvcmtzIHVzaW5nIGRpZmZlcmVudCBrZXlzLCBldGMuKQ0KDQpUaGlzIGlzIGFsbCBk aXN0cmFjdGlvbiBmcm9tIHRoZSByZWFsIHByb2JsZW0gd2UgaGF2ZSB0byBzb2x2ZTogIGhvdyBk byB3ZSBhZ3JlZSBvbiBzZXNzaW9uIGtleXMgdGhhdCBhbGxvdyBhIGRldmljZSBhbmQgYSBQQ0Ug dG8gZXhjaGFuZ2UgTUFDIGNvbmZpZ3VyYXRpb24gbWVzc2FnZXMgaW4gYSBtaW5pbWFsIG51bWJl ciBvZiBmcmFtZXMsIGFuZCBkbyBzbyBpbiBhIHRvdWNobGVzcyB3YXkuICBFdmVyeXRoaW5nIGVs c2UgaXMgZWl0aGVyIGlycmVsZXZhbnQsIG9yIGFwcGxpY2F0aW9uIHBvbGljeS4NCg0KLS0NCkpv bmF0aGFuIFNpbW9uLCBQaC4gRA0KanNpbW9uQGxpbmVhci5jb208bWFpbHRvOmpzaW1vbkBsaW5l YXIuY29tPg0KDQpPbiBEZWMgOSwgMjAxNCwgYXQgOTo0NiBBTSwgS3JpcyBQaXN0ZXIgPGtzanBA YmVya2VsZXkuZWR1PG1haWx0bzprc2pwQGJlcmtlbGV5LmVkdT4+IHdyb3RlOg0KDQpTbyB0aGUg aWRlYSBpcyB0aGF0IG1pc2ludGVycHJldGluZyBhIGZyYW1lIGZyb20gYSBjb21wbGV0ZWx5IGRp ZmZlcmVudCB0eXBlIG9mIG5ldHdvcmsNCmlzIG5vdCBhIHByb2JsZW0/DQpJIGd1ZXNzIHRoYXQg aXQgd2lsbCBqdXN0IGNhdXNlIHRoZSBqb2luaW5nIG5vZGUgdG8gdHJ5IHRvIGluaXRpYXRlIGFu IGF1dGhlbnRpY2F0aW9uIGV4Y2hhbmdlDQp0aGF0IHdvbid0IGdvIGFueXdoZXJlLiAgTWF5YmUg dGhhdCdzIG9rLCBidXQgaXQgbGVhdmVzIHVzIG9wZW4gdG8gKnVuaW50ZW50aW9uYWwqIGRlbmlh bA0Kb2Ygc2VydmljZSBhdHRhY2tzLg0KDQpJJ2QgZmVlbCBhIGxpdHRsZSBiZXR0ZXIgYWJvdXQg aXQgaWYgdGhlIHByb3BvbmVudHMgb2YgIm5vIGZha2Uga2V5cyIgd291bGQgYWNrbm93bGVkZ2UN CnRoZSBjb25jZXJucyBvZiB0aGUgIndlbGwta25vd24ga2V5IiBnYW5nLiAgV2UndmUgc2FpZCBy ZXBlYXRlZGx5IHRoYXQgIndlbGwga25vd24iDQppcyBub3QgYWJvdXQgc2VjdXJpdHksIGl0J3Mg YWJvdXQgYXZvaWRpbmcgdW5pbnRlbnRpb25hbCBtaXNpbnRlcnByZXRhdGlvbiBvZiBmb3JlaWdu IHBhY2tldHMuDQpXZSBnZXQgdGhhdCBhIHdlbGwga25vd24ga2V5IHByb3ZpZGVzIHplcm8gc2Vj dXJpdHkuDQpEbyB5b3UgZ2V0IHRoYXQgdGhlIGFldGhlciBpcyBmaWxsZWQgd2l0aCBwYWNrZXRz IHRoYXQgZG9uJ3QgYWJpZGUgYnkgNmxvd3BhbiBkaXNwYXRjaCBieXRlcywNCm9yIGV2ZW4gSUVF RSBNQUMgaGVhZGVyIGNvbnZlbnRpb25zPw0KDQprc2pwDQoNCk9uIDEyLzgvMjAxNCA2OjAwIFBN LCBSZW5lIFN0cnVpayB3cm90ZToNClBEIHN1bW1hcml6ZWQgdGhhdCB1c2luZyB1bnNlY3VyZWQg ZnJhbWVzLCByYXRoZXIgdGhhbiAiZmFrZSIgc2VjdXJpdHkgd2l0aCAiZGVmYXVsdCBrZXlzIiwg c2hvdWxkIGJlIGFkb3B0ZWQsIHdoaWNoIHdhcyBjb25zZW5zdXMgb24gdGhlIGNhbGwuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo2dGlzY2gtc2Vj dXJpdHkgbWFpbGluZyBsaXN0DQo2dGlzY2gtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNj aC1zZWN1cml0eUBpZXRmLm9yZz4NCmh0dHA6Ly9jcC5tY2FmZWUuY29tL2QvMkRSUG9zODFOSjV4 NVY1d3N5WWVkVGRFSzNDa1BxYndWQllTeVVlZDdhYXI5RVZkS2ZmZmVjbktyNHFpbEgwNTdPeC1O VnNTdmE3WDdCUHI4VlpBc1lNX1ItNzNBa243S0xzS0NPTnZBbTROUFh6ZmJuakl5Q0d6dHpCZ1kt RjZsSzFGSjRTeXJMT2IyclBVVjV4Y1FzQ1hDT3NWSGtpUDJEaS1yTDAwczRSdHh4WUdqQjFTS2Vq QmlOY0xqWGROQmNJcnNEYUJ5cHVEU3J6YXBvS2dHVDJUUTFrTENYTTA0U1Zzc3lyMXZGNnkwUUpL akJpTmNMalhkTkJjSXFuamgwcWEzNjZ5MnhZeTllcEV3Sm1jdkplbG82eUFRZzJWeDE4UWc2eXht azZWX2dRZ2x0ZDQwOXJZUWcxVFNkNDJvMUN5MWVXYjAxQ3kwUXNXR3E4MUVvMTlFd0pGVlZFRmQ0 MGJaOFFnNnl5NWoxRXdjaUNqZDQ2QXZ3eEZFRmQ0MGJaOFFnaXdwQmZQaDBYbTlFd3NEYUJ5cEV3 RlpDVU9DbWQ0NUpmZmQ0MDlyWVFnMVRTWmt4WWpoMEMwcEV3akt5TTBwRXdkN2VHQ3kwcTYwaXE4 M3poMFZHRkV3Mk1NMmpoMHNxODZsQmpoMDVKemF4RXdlZDQyYWFPRkV3MHpsSndyamh2ZEJPN18N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZ0aXNj aC1zZWN1cml0eSBtYWlsaW5nIGxpc3QNCjZ0aXNjaC1zZWN1cml0eUBpZXRmLm9yZzxtYWlsdG86 NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82dGlzY2gtc2VjdXJpdHkNCg== --_000_AE731AF8FE24426494B4A6A06F756F97ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <53A16134A8F9164DB7960E7ECB78E287@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4N CjxkaXY+DQo8ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2PkkgYWdyZWUgSm9u YXRoYW4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdHJpZWQgdG8gcHJv cG9zZSB0ZXh0IHRoYXQgaXMgaW5kZXBlbmRlbnQgb24gdGhhdCBkZWNpc2lvbiB0aGlzIG1vcm5p bmcgYnV0IEkgc3Ryb25nbHkgZmF2b3IgdXNpbmcgYSBrZXkgdG8gZGlmZmVyZW50aWF0ZSBuZXR3 b3JrcyBpZiBhdCBhbGwgcG9zc2libGUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGUgYXJndW1lbnQgb2YgZmFzdGVyIHJlam9pbiBJIGhhdmUgYSBoYXJkIHRpbWUgYWNjZXB0aW5n IHNpbmNlIEkgc2VlIHRoZSB2YWx1ZSBvZiBhIGpvaW4gbGluayB0aGF0IGlzIG5vdCB0YWtlbiBm cm9tIHRoZSBwcm9kdWN0aW9uIHNjaGVkdWxlIGFuZCB1c2VzIGEgZGlmZmVyZW50IHByZWZpeC4g U28gdGhlIHJlam9pbiB3b3JrcyBpZiB5b3Ugc3RpbGwgaGF2ZSBhIGtleSBhbmQgYXRlIHN0aWxs IGluIHN5bmMsIGFuZCBpbiB0aGF0IGNhc2UNCiB5b3UgY2FuIHJlc3RhcnQgZnJvbSB0aGUgUlMv UkEgaW4gbXkgZmxvdy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFub3RoZXIgYXNw ZWN0IG9mIHRoZSBqb2luIGxpbmsgd291bGQgYmUgYSBzbG93ZXIgaG9waW5nIHNjaGVkdWxlIHRv IGFjY29tbW9kYXRlIHJlam9pbiBvZiBhIG5vZGUgd2l0aCBsaW1pdGVkIFJUQyBjYXBhYmlsaXRp ZXMgYWZ0ZXIgYSBkYXkncyBzbGVlcC4gVGhpcyBpcyBzb21ldGhpbmcgb2YgZGVlcCBpbnRlcmVz dCBpbiBOQU4gYXBwbGljYXRpb25zIGFuZCB3b3VsZCBtYWtlIDZUaVNDSCBhIHN0cm9uZyBjb250 ZW5kZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DYW4gdGhhdCBiZSBhY2NvbW1v ZGF0ZWQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8YnI+DQo8YnI+DQpQ YXNjYWwNCjxkaXY+PGJyPg0KTGUgOSBkw6ljLiAyMDE0IMOgIDEyOjA5LCBKb25hdGhhbiBTaW1v biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpzaW1vbkBsaW5lYXIuY29tIj5qc2ltb25AbGluZWFyLmNv bTwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5k ZTsiPkkgYW0ga2luZCBvZiBiYWZmbGVkIGF0IHRoZSBkaXJlY3Rpb24gdGhpcyBncm91cCBzZWVt cyB0byBoYXZlIHRha2VuLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdy YW5kZTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdyYW5k ZTsiPldlIGFsbCBhZ3JlZWQgdGhhdCB0b3VjaGxlc3Mgb3BlcmF0aW9uIGlzIHRoZSBnb2FsLiZu YnNwOyBTbyBiZWFjb25zIG5lZWQgdG8gYmUgYXV0aGVudGljYXRlZCB3aXRoIGEgd2VsbC1rbm93 biBrZXkgKHllcywgSSBrbm93IHRoaXMgZG9lcyBub3RoaW5nIGZvciBzZWN1cml0eSAtIHRoaXMg cHJvdmlkZXMgZm9yIHByb3RvY29sIHNlcGFyYXRpb24gb25seSkuJm5ic3A7IE1peGluZyBvZiB1 bmF1dGhlbnRpY2F0ZWQNCiBhbmQgYXV0aGVudGljYXRlZCBmcmFtZXMgaXMgYSBub24taXNzdWUs IHNpbmNlIGV2ZXJ5dGhpbmcgaXMgYXV0aGVudGljYXRlZC4gJm5ic3A7IEkgZG9u4oCZdCB1bmRl cnN0YW5kIHRoZSB2YWx1ZSBvZiBzYXZpbmcgYSBiZWFjb24ga2V5IGNvbmZpZ3VyZWQgYXQgYSBo aWdoZXIgbGF5ZXIsIGFzIGEpIHRoZSBuZXR3b3JrIGhhcyB0byBzZW5kIHRoZSBiZWFjb25zIHVu ZW5jcnlwdGVkIGZvciB0b3VjaGxlc3Mgb3BlcmF0aW9uLCBiKSB5b3UgZG9u4oCZdCBnZXQNCiBh bnkgc2VjdXJpdHkgYmVuZWZpdCBpZiBhIGRldmljZSBpcyBnb2luZyB0byBhY2NlcHQgdGhlIGJl YWNvbiBjb250ZW50cyByZWdhcmRsZXNzLCBhbmQgYykgYSBkZXZpY2UgaGFzIHRvIGJlIGFibGUg dG8gZmFsbCBiYWNrIHRvIHRoZSB3ZWxsLWtub3duIGtleSBhbnkgdGltZSwgc2luY2UgdGhlIHNh dmVkIGtleSBtYXkgYmUgc3RhbGUgKG5vZGUgbW92ZWQsIG5vZGUgc2xlcHQgd2hpbGUga2V5IHdh cyBjaGFuZ2luZywgbm9kZSBpcyBhbGxvd2VkDQogaW4gbXVsdGlwbGUgb3ZlcmxhcHBpbmcgbmV0 d29ya3MgdXNpbmcgZGlmZmVyZW50IGtleXMsIGV0Yy4pPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogTHVjaWRhR3JhbmRlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogTHVjaWRhR3JhbmRlOyI+VGhpcyBpcyBhbGwgZGlzdHJhY3Rpb24gZnJvbSB0aGUgcmVh bCBwcm9ibGVtIHdlIGhhdmUgdG8gc29sdmU6ICZuYnNwO2hvdyBkbyB3ZSBhZ3JlZSBvbiBzZXNz aW9uIGtleXMgdGhhdCBhbGxvdyBhIGRldmljZSBhbmQgYSBQQ0UgdG8gZXhjaGFuZ2UgTUFDIGNv bmZpZ3VyYXRpb24gbWVzc2FnZXMgaW4gYSBtaW5pbWFsIG51bWJlciBvZiBmcmFtZXMsIGFuZCBk byBzbyBpbiBhIHRvdWNobGVzcw0KIHdheS4mbmJzcDsgRXZlcnl0aGluZyBlbHNlIGlzIGVpdGhl ciBpcnJlbGV2YW50LCBvciBhcHBsaWNhdGlvbiBwb2xpY3kuPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogTHVjaWRhR3JhbmRlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IGFwcGxlLWNvbnRl bnQtZWRpdGVkPSJ0cnVlIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJv cmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGJvcmRlci1zcGFjaW5nOiAwcHg7Ij4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8c3BhbiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnTHVjaWRhIEdyYW5kZSc7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246 IC13ZWJraXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IGJvcmRlci1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6ICdMdWNpZGEgR3JhbmRlJzsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgYm9yZGVyLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiPg0KLS08YnI+DQpKb25hdGhhbiBTaW1vbiwgUGguIEQ8YnI+DQo8YSBocmVmPSJtYWlsdG86 anNpbW9uQGxpbmVhci5jb20iPmpzaW1vbkBsaW5lYXIuY29tPC9hPjxicj4NCjxicj4NCjwvZGl2 Pg0KPC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxk aXY+T24gRGVjIDksIDIwMTQsIGF0IDk6NDYgQU0sIEtyaXMgUGlzdGVyICZsdDs8YSBocmVmPSJt YWlsdG86a3NqcEBiZXJrZWxleS5lZHUiPmtzanBAYmVya2VsZXkuZWR1PC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+U28gdGhlIGlkZWEgaXMgdGhhdCBtaXNpbnRlcnByZXRpbmcgYSBmcmFt ZSBmcm9tIGEgY29tcGxldGVseSBkaWZmZXJlbnQgdHlwZSBvZiBuZXR3b3JrPGJyPg0KaXMgbm90 IGEgcHJvYmxlbT88YnI+DQpJIGd1ZXNzIHRoYXQgaXQgd2lsbCBqdXN0IGNhdXNlIHRoZSBqb2lu aW5nIG5vZGUgdG8gdHJ5IHRvIGluaXRpYXRlIGFuIGF1dGhlbnRpY2F0aW9uIGV4Y2hhbmdlPGJy Pg0KdGhhdCB3b24ndCBnbyBhbnl3aGVyZS4gJm5ic3A7TWF5YmUgdGhhdCdzIG9rLCBidXQgaXQg bGVhdmVzIHVzIG9wZW4gdG8gKnVuaW50ZW50aW9uYWwqIGRlbmlhbDxicj4NCm9mIHNlcnZpY2Ug YXR0YWNrcy48YnI+DQo8YnI+DQpJJ2QgZmVlbCBhIGxpdHRsZSBiZXR0ZXIgYWJvdXQgaXQgaWYg dGhlIHByb3BvbmVudHMgb2YgJnF1b3Q7bm8gZmFrZSBrZXlzJnF1b3Q7IHdvdWxkIGFja25vd2xl ZGdlPGJyPg0KdGhlIGNvbmNlcm5zIG9mIHRoZSAmcXVvdDt3ZWxsLWtub3duIGtleSZxdW90OyBn YW5nLiAmbmJzcDtXZSd2ZSBzYWlkIHJlcGVhdGVkbHkgdGhhdCAmcXVvdDt3ZWxsIGtub3duJnF1 b3Q7PGJyPg0KaXMgbm90IGFib3V0IHNlY3VyaXR5LCBpdCdzIGFib3V0IGF2b2lkaW5nIHVuaW50 ZW50aW9uYWwgbWlzaW50ZXJwcmV0YXRpb24gb2YgZm9yZWlnbiBwYWNrZXRzLjxicj4NCldlIGdl dCB0aGF0IGEgd2VsbCBrbm93biBrZXkgcHJvdmlkZXMgemVybyBzZWN1cml0eS48YnI+DQpEbyB5 b3UgZ2V0IHRoYXQgdGhlIGFldGhlciBpcyBmaWxsZWQgd2l0aCBwYWNrZXRzIHRoYXQgZG9uJ3Qg YWJpZGUgYnkgNmxvd3BhbiBkaXNwYXRjaCBieXRlcyw8YnI+DQpvciBldmVuIElFRUUgTUFDIGhl YWRlciBjb252ZW50aW9ucz88YnI+DQo8YnI+DQprc2pwPGJyPg0KPGJyPg0KT24gMTIvOC8yMDE0 IDY6MDAgUE0sIFJlbmUgU3RydWlrIHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PlBEIHN1bW1hcml6ZWQgdGhhdCB1c2luZyB1bnNlY3VyZWQgZnJhbWVzLCByYXRoZXIgdGhhbiAm cXVvdDtmYWtlJnF1b3Q7IHNlY3VyaXR5IHdpdGggJnF1b3Q7ZGVmYXVsdCBrZXlzJnF1b3Q7LCBz aG91bGQgYmUgYWRvcHRlZCwgd2hpY2ggd2FzIGNvbnNlbnN1cyBvbiB0aGUgY2FsbC48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCjZ0aXNjaC1zZWN1cml0eSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnIj42dGlzY2gtc2VjdXJpdHlAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL2NwLm1jYWZlZS5jb20vZC8yRFJQb3M4MU5KNXg1 VjV3c3lZZWRUZEVLM0NrUHFid1ZCWVN5VWVkN2FhcjlFVmRLZmZmZWNuS3I0cWlsSDA1N094LU5W c1N2YTdYN0JQcjhWWkFzWU1fUi03M0FrbjdLTHNLQ09OdkFtNE5QWHpmYm5qSXlDR3p0ekJnWS1G NmxLMUZKNFN5ckxPYjJyUFVWNXhjUXNDWENPc1ZIa2lQMkRpLXJMMDBzNFJ0eHhZR2pCMVNLZWpC aU5jTGpYZE5CY0lyc0RhQnlwdURTcnphcG9LZ0dUMlRRMWtMQ1hNMDRTVnNzeXIxdkY2eTBRSktq QmlOY0xqWGROQmNJcW5qaDBxYTM2NnkyeFl5OWVwRXdKbWN2SmVsbzZ5QVFnMlZ4MThRZzZ5eG1r NlZfZ1FnbHRkNDA5cllRZzFUU2Q0Mm8xQ3kxZVdiMDFDeTBRc1dHcTgxRW8xOUV3SkZWVkVGZDQw Ylo4UWc2eXk1ajFFd2NpQ2pkNDZBdnd4RkVGZDQwYlo4UWdpd3BCZlBoMFhtOUV3c0RhQnlwRXdG WkNVT0NtZDQ1SmZmZDQwOXJZUWcxVFNaa3hZamgwQzBwRXdqS3lNMHBFd2Q3ZUdDeTBxNjBpcTgz emgwVkdGRXcyTU0yamgwc3E4NmxCamgwNUp6YXhFd2VkNDJhYU9GRXcwemxKd3JqaHZkQk83XyI+ aHR0cDovL2NwLm1jYWZlZS5jb20vZC8yRFJQb3M4MU5KNXg1VjV3c3lZZWRUZEVLM0NrUHFid1ZC WVN5VWVkN2FhcjlFVmRLZmZmZWNuS3I0cWlsSDA1N094LU5Wc1N2YTdYN0JQcjhWWkFzWU1fUi03 M0FrbjdLTHNLQ09OdkFtNE5QWHpmYm5qSXlDR3p0ekJnWS1GNmxLMUZKNFN5ckxPYjJyUFVWNXhj UXNDWENPc1ZIa2lQMkRpLXJMMDBzNFJ0eHhZR2pCMVNLZWpCaU5jTGpYZE5CY0lyc0RhQnlwdURT cnphcG9LZ0dUMlRRMWtMQ1hNMDRTVnNzeXIxdkY2eTBRSktqQmlOY0xqWGROQmNJcW5qaDBxYTM2 NnkyeFl5OWVwRXdKbWN2SmVsbzZ5QVFnMlZ4MThRZzZ5eG1rNlZfZ1FnbHRkNDA5cllRZzFUU2Q0 Mm8xQ3kxZVdiMDFDeTBRc1dHcTgxRW8xOUV3SkZWVkVGZDQwYlo4UWc2eXk1ajFFd2NpQ2pkNDZB dnd4RkVGZDQwYlo4UWdpd3BCZlBoMFhtOUV3c0RhQnlwRXdGWkNVT0NtZDQ1SmZmZDQwOXJZUWcx VFNaa3hZamgwQzBwRXdqS3lNMHBFd2Q3ZUdDeTBxNjBpcTgzemgwVkdGRXcyTU0yamgwc3E4NmxC amgwNUp6YXhFd2VkNDJhYU9GRXcwemxKd3JqaHZkQk83XzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPjZ0aXNjaC1zZWN1cml0eSBtYWlsaW5nIGxpc3Q8 L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOjZ0aXNjaC1zZWN1cml0eUBpZXRmLm9y ZyI+NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaC1zZWN1cml0eSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gtc2VjdXJpdHk8L2E+ PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AE731AF8FE24426494B4A6A06F756F97ciscocom_-- From nobody Tue Dec 9 15:19:49 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8081A6ED9 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_qwNpFeRH6J for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:19:42 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3D11A0074 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 15:19:42 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so1610673ier.14 for <6tisch-security@ietf.org>; Tue, 09 Dec 2014 15:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=qKBz+dZ6QVX7OId788lEeOkQEHDml1UDJiNsC2v1VJY=; b=IlCJCaa6kvCIFZIKvZ8I0Imz8YAX8wqYlLYEEmRwkpAEsl0L1xbx+HN2MpXCz1xpqE dFjtxmK+UILdVY6tMbk09e5v2lJoQvlLX4IVwdYZvNFPY99a0tkegE3WM+r4GiV3HEma WyudO8Iri32Cng8rwuLfKwogIoKSYDn0EK8mLeMqT/W1cezBfZmiceuBcuWObcB863bv hax8wBh5BQOZJjQ5i0+o03eZz38/OGQI1+O+lFHLOCriAlodHlxg/U8q6dMk9ySwfWQi kYFDLtVDn2u/AXeajs8KwDZybjYl2FkkQ2HOopeuNCc8XUkZA22AaRcOmokXDo2jrcN/ wd1A== X-Received: by 10.50.3.67 with SMTP id a3mr22557662iga.42.1418167181120; Tue, 09 Dec 2014 15:19:41 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id n36sm1314197ioe.4.2014.12.09.15.19.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 15:19:40 -0800 (PST) Message-ID: <54878389.7020905@gmail.com> Date: Tue, 09 Dec 2014 18:19:37 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp, tisch-security <6tisch-security@ietf.org> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> Content-Type: multipart/alternative; boundary="------------050308050803040109080201" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/bL6B1D3m4DwPCAue9HmM6AbPyps Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:19:47 -0000 This is a multi-part message in MIME format. --------------050308050803040109080201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Yoshi: According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine). Best regards, Rene [excerpt of 802.15.4e-2012, Clause 5.2.4.1] IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload elements. On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp wrote: > > I think all PAN Descriptor fields are either contained in the visible > part of Beacon frame or obtained as associated information of the > frame. Some TSCH-related IEs, such as TSCH Synchronization, TSCH > Slotframe and Link, TSCH Timeslot, Channel Hopping > > Sequence IEs, are contained as Payload IEs, and are not accessible > from joining node if they are encrypted. > > Of course, if the Beacon frame is authenticated-only and unencrypted, > then all information is visible to joining node, but joining node has > to process AES-CCM* encoded cleartext information even if key is not > available (I am not sure if existing implementation supports this kind > of processing). > > Yoshihiro Ohba > > *From:*Rene Struik [mailto:rstruik.ext@gmail.com] > *Sent:* Tuesday, December 9, 2014 11:22 AM > *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ) > *Cc:* tisch-security > *Subject:* Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST > call) Re: (now with agenda) Re: invite for 6tisch security call Tue > December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan > > Hi Yoshi: > > The passive scan language in the 802.15.4-2011 spec is in Clause > 5.1.2.1.2. I think one should also look at the PAN descriptor and see > which elements of the enhanced beacon that are in the PAN descriptor > table are visible to a "newbee" device. Would you like to give this a > look? > > Best regards, Rene > > On 12/8/2014 8:48 PM, Rene Struik wrote: > > Hi Yoshi: > > Good point (and I remember we discussed this, while going over > Slide 20, but I forgot to include this in the minutes [I will > correct this]). > > The idea is that if a joining device receives a secured beacon > frame, it can still extract the visible portion of the frame, even > if it cannot do proper incoming security processing (obviously, it > cannot really rely on this data at this point, then). > > With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active > Channel Scan), of which the excerpt from p. 174 of the spec > describes the corresponding behavior: > > If a protected beacon frame is received, i.e., the Security > Enabled subfield in the Frame Control field is set to one, the > device shall attempt to unsecure the beacon frame using the > unsecuring process described in 7.5.8.2.3. > The security-related elements of the PAN descriptor > corresponding to the beacon (see Table 55) shall be set to the > corresponding parameters returned by the unsecuring process. > The SecurityFailure element of the PAN descriptor shall be set > to SUCCESS if the status from the unsecuring process is > SUCCESS and set to one of the other status codes indicating an > error in the security processing otherwise. The information > from the unsecured frame shall be recorded in the PAN > descriptor even if the status from the unsecuring process > indicated an error. > > I did not check yet whether the later spec 802.15.4-2011 changed > this behavior or whether 802.15.4e-2012 did, but if I remember > correctly the 802.15.4e spec did not modify any of this, so the > remaining check would be 2006 --> 2011. > > Best regards, Rene > > > On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp > wrote: > > Hi Rene, > > I would like to double check the meaning of “exempt statusâ€. > I thought the “exempt status†is maintained by higher layer > and is different from the “Exempt†flag of 802.15.4-2011 > DeviceDescriptor of Security-related PIB attributes. > > I am asking this because, while the “Exempt†flag of > 802.15.4-2011 DeviceDescriptor of Security-related PIB > attributes allows unsecured frames to be passed to higher > layer, the flag solely does not help for joining node’s higher > layer to process authenticated-only secured beacons. > > Yoshihiro Ohba > > *From:*6tisch-security > [mailto:6tisch-security-bounces@ietf.org] *On Behalf Of *Rene > Struik > *Sent:* Tuesday, December 9, 2014 8:09 AM > *Cc:* 6tisch-security@ietf.org > *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am > EST call) Re: (now with agenda) Re: invite for 6tisch security > call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = > 11pm Japan > > Dear colleagues: > > Please find below the minutes of the 6TiSCH Security conf call > as of December 2, 2014, 9am EST. > > Minutes 6TiSCH Security conf call, Tue December 2, 2014, > 9-10am EST > {note taker: Rene Struik} > {recording: > https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} > {slides discussed (and referenced in minutes): > https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} > > 1. Attendance: > Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene > Struik > > 2. Agenda > The suggested agend was approved. > > 3. Join process - desirable vs. realizable properties > RS went over the desirable properties of the join process > (Slide 6). MR raised point that privacy of the device identity > of the joining node might not be required. . SD suggested that > it is fine to include privacy in list of "desiderata"; > evaluation metrics might consider these in "grey tones" vs. as > "black and white" requirement. RS suggested that merit of > privacy might depend on deployment scenario, but is on the > radar in lots of IETF groups (in terms of > traceability/tracking); if privacy can be easily offered as > additional feature, this would be a plus. After asking, there > was no further discussion on properties listed. > > 4. Join process - MAC behavior. > RS went over some MAC security aspects of the 802.15.4-2011 > and 802.15.4e-2012 specifications (Slides 19-22). The main > premise here was that a recipient device that expects secured > traffic, will reject all incoming unsecured traffic, unless > this originates from a device with so-called "exempt status". > This "exempt status" construct allows receipt of incoming > unsecured data frames from a joining node that does not have > network-specific keying material yet. How to switch on/off > this "exempt status" parameter was also discussed (see Slide > 20). Furthermore, there was some discussion on how this > compares to the use of so-called "default keys" (aka "fake" > keys) (see also Slide 22). > > PG mentioned that 802.15.4 does not allow the use of the > default key. SD suggested that an important point in not using > default keys is that all incoming processing with keys will be > treated transparently, irrespective of exceptions. RS > explained that even if default keys were to be used, this > would mess up local security state (e.g., frame counters), > which is not the case if one would send unsecured traffic and > use the "exempt status" construct instead. PD summarized that > using unsecured frames, rather than "fake" security with > "default keys", should be adopted, which was consensus on the > call. > > PG came back to the "exempt flag" topic and suggested that > details hereof are in the "device descriptor lookup table". RS > suggested that we all have a closer look at specification > details, so that switching this feature on/off could be easily > codified for 6TiSCH use. > > 5. Join process - non-MAC behavior. > Given remaining time on the call would not allow full > discussion of non-MAC aspects (Slides 23-25) and given that MR > had to drop off the call, it was decided to revisit those > topics at the next conf call. > > 6. AOB Conf call scheduling. > SD suggested he was confused about having two call times in > email traffic (one at 9am EST and one at 11am EST) and > suggested that other groups, such as, e.g., IEEE, often use > cyclic schedule, so as to accommodate participants from around > the world and who may be at widely different time zones. RS > volunteered to look into this topic and obtain feedback on > such a schedule. > > Best regards, Rene > > On 12/1/2014 11:55 AM, Rene Struik wrote: > > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and > 2), to be discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: > > Dear colleagues: > > > I have set up a conf call for Tuesday December 2, 2014 > at a time that tries and accommodate people in > different time zones to the largest extent possible, > without trying to discriminate against various parts > of the world. > > > Please see dial-in information below. > > > Agenda to follow Monday around noon. > > > Looking forward to a collaborative meeting, in good > spirit. > > Best regards, Rene > > == > > 1. Please join my meeting. > > https://global.gotomeeting.com/join/594299061 > > 2. Use your microphone and speakers (VoIP) - a > headset is recommended. Or, call in using your telephone. > > Dial +1 (647) 497-9351 > > Access Code: 594-299-061 > > Audio PIN: Shown after joining the meeting > > Meeting Password: collaborate > > Meeting ID: 594-299-061 > > GoToMeeting® > > Online Meetings Made Easy® > > Not at your computer? Click the link to join this > meeting from your iPhone®, iPad®, Android® or Windows > Phone® device via the GoToMeeting app. > > > > > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. > This should allow people to have their private time in > the 12am-6am time window. {Other groups do a much > better job at this...} > > > On 11/28/2014 10:39 AM, Michael Richardson wrote: > > Subir Das wrote: > > > Thanks for arranging the calls. It would be good to accommodate Asian time > > > zone for broader participation. I would suggest choosing a time that is > > > > I'm happy to do this at another time; the original choice of 11am Eastern was > > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > > > >From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. > > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > > or > > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > > > I am also happy to alternate. > > Shall I put up a doodle poll? > > > > > > > > _______________________________________________ > > 6tisch-security mailing list > > 6tisch-security@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch-security > > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > -- > > email:rstruik.ext@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------050308050803040109080201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp wrote:

I think all PAN Descriptor fields are either contained in the visible part of Beacon frame or obtained as associated information of the frame.  Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and Link, TSCH Timeslot, Channel Hopping

Sequence IEs, are contained as Payload IEs, and are not accessible from joining node if they are encrypted.

 

Of course, if the Beacon frame is authenticated-only and unencrypted, then all information is visible to joining node, but joining node has to process AES-CCM* encoded cleartext information even if key is not available (I am not sure if existing implementation supports this kind of processing).

 

Yoshihiro Ohba

 

 

 

 

 

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Tuesday, December 9, 2014 11:22 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: tisch-security
Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik wrote:

Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:

If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of “exempt statusâ€.  I thought the “exempt status†is maintained by higher layer and is different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node’s higher layer to process authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired properties
b) realizable properties

2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

==

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate Asian time
    > zone for broader participation. I would suggest choosing a time that is
 
I'm happy to do this at another time; the original choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.  
 
>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
 
I am also happy to alternate.
Shall I put up a doodle poll?
 





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





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





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





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




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




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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------050308050803040109080201-- From nobody Tue Dec 9 15:28: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 381421A8871 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 af8rsWEyP0B4 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:28:17 -0800 (PST) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) by ietfa.amsl.com (Postfix) with ESMTP id D2F0D1A6F22 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 15:28:16 -0800 (PST) Received: from [10.0.1.55] ([50.172.118.112]) by p3plsmtpa11-07.prod.phx3.secureserver.net with id RbUE1p0082RbJC201bUFbo; Tue, 09 Dec 2014 16:28:16 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_D112E542-D826-4A43-9F88-74939BD801BA" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Pat Kinney In-Reply-To: <54878389.7020905@gmail.com> Date: Tue, 9 Dec 2014 17:28:14 -0600 Message-Id: <099BF16F-1ACD-465C-A720-EBD2031F387B@kinneyconsultingllc.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> <54878389.7020905@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/42aqKbpA_bWSk2CBR5_ZbLahqsc Cc: tisch-security <6tisch-security@ietf.org>, yoshihiro.ohba@toshiba.co.jp Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:28:22 -0000 --Apple-Mail=_D112E542-D826-4A43-9F88-74939BD801BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The Payload IEs are indeed encrypted if the frame is encrypted, that was = part of the intent of having two types of IEs. Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com = On 9, Dec2014, at 17:19, Rene Struik wrote: Hi Yoshi: According to Section 5.2.4.1, Payload Information Elements do not seem = to be encrypted (cf. below). Curiously, though, this seems to be = inconsistent with the incoming and outgoing security processing in = 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure = 802.15.4-2012 did not redefine). Best regards, Rene [excerpt of 802.15.4e-2012, Clause 5.2.4.1] IEs may be either part of the MAC Header or MAC payload. Header IEs are = used by the MAC to process the frame immediately, i.e., they cover security, addressing, etc., and are = part of the MAC Header. Payload IEs are destined for another layer or SAP and are part of the MAC payload = (but like command IDs they may not be encrypted). If IEs are contained in a frame, they always occur before = other unstructured MAC payload elements. On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp = wrote: > I think all PAN Descriptor fields are either contained in the visible = part of Beacon frame or obtained as associated information of the frame. = Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and = Link, TSCH Timeslot, Channel Hopping > Sequence IEs, are contained as Payload IEs, and are not accessible = from joining node if they are encrypted. > =20 > Of course, if the Beacon frame is authenticated-only and unencrypted, = then all information is visible to joining node, but joining node has to = process AES-CCM* encoded cleartext information even if key is not = available (I am not sure if existing implementation supports this kind = of processing). > =20 > Yoshihiro Ohba > =20 > =20 > =20 > =20 > =20 > From: Rene Struik [mailto:rstruik.ext@gmail.com = ]=20 > Sent: Tuesday, December 9, 2014 11:22 AM > To: ohba yoshihiro(=E5=A4=A7=E5=A0=B4 =E7=BE=A9=E6=B4=8B = =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=AE=EF=BC=B3=EF=BC=AC) > Cc: tisch-security > Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST = call) Re: (now with agenda) Re: invite for 6tisch security call Tue = December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan > =20 > Hi Yoshi: >=20 > The passive scan language in the 802.15.4-2011 spec is in Clause = 5.1.2.1.2. I think one should also look at the PAN descriptor and see = which elements of the enhanced beacon that are in the PAN descriptor = table are visible to a "newbee" device. Would you like to give this a = look? >=20 > Best regards, Rene >=20 > On 12/8/2014 8:48 PM, Rene Struik wrote: > Hi Yoshi: >=20 > Good point (and I remember we discussed this, while going over Slide = 20, but I forgot to include this in the minutes [I will correct this]). >=20 > The idea is that if a joining device receives a secured beacon frame, = it can still extract the visible portion of the frame, even if it cannot = do proper incoming security processing (obviously, it cannot really rely = on this data at this point, then). >=20 > With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active = Channel Scan), of which the excerpt from p. 174 of the spec describes = the corresponding behavior: > If a protected beacon frame is received, i.e., the Security Enabled = subfield in the Frame Control field is set to one, the device shall = attempt to unsecure the beacon frame using the unsecuring process = described in 7.5.8.2.3. > The security-related elements of the PAN descriptor corresponding to = the beacon (see Table 55) shall be set to the corresponding parameters = returned by the unsecuring process. The SecurityFailure element of the = PAN descriptor shall be set to SUCCESS if the status from the unsecuring = process is SUCCESS and set to one of the other status codes indicating = an error in the security processing otherwise. The information from the = unsecured frame shall be recorded in the PAN descriptor even if the = status from the unsecuring process indicated an error. >=20 > I did not check yet whether the later spec 802.15.4-2011 changed this = behavior or whether 802.15.4e-2012 did, but if I remember correctly the = 802.15.4e spec did not modify any of this, so the remaining check would = be 2006 --> 2011. >=20 > Best regards, Rene >=20 >=20 > On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp = wrote: > Hi Rene, > =20 > I would like to double check the meaning of =E2=80=9Cexempt status=E2=80= =9D. I thought the =E2=80=9Cexempt status=E2=80=9D is maintained by = higher layer and is different from the =E2=80=9CExempt=E2=80=9D flag of = 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes. > =20 > I am asking this because, while the =E2=80=9CExempt=E2=80=9D flag of = 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows = unsecured frames to be passed to higher layer, the flag solely does not = help for joining node=E2=80=99s higher layer to process = authenticated-only secured beacons. > =20 > Yoshihiro Ohba > =20 > =20 > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org = ] On Behalf Of Rene Struik > Sent: Tuesday, December 9, 2014 8:09 AM > Cc: 6tisch-security@ietf.org > Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) = Re: (now with agenda) Re: invite for 6tisch security call Tue December = 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan > =20 > Dear colleagues: >=20 > Please find below the minutes of the 6TiSCH Security conf call as of = December 2, 2014, 9am EST. >=20 > Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST > {note taker: Rene Struik} > {recording: = https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=3Dsh= aring = } > {slides discussed (and referenced in minutes): = https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=3Dsh= aring = } >=20 > 1. Attendance: > Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik >=20 > 2. Agenda > The suggested agend was approved. >=20 > 3. Join process - desirable vs. realizable properties > RS went over the desirable properties of the join process (Slide 6). = MR raised point that privacy of the device identity of the joining node = might not be required. . SD suggested that it is fine to include privacy = in list of "desiderata"; evaluation metrics might consider these in = "grey tones" vs. as "black and white" requirement. RS suggested that = merit of privacy might depend on deployment scenario, but is on the = radar in lots of IETF groups (in terms of traceability/tracking); if = privacy can be easily offered as additional feature, this would be a = plus. After asking, there was no further discussion on properties = listed. >=20 > 4. Join process - MAC behavior. > RS went over some MAC security aspects of the 802.15.4-2011 and = 802.15.4e-2012 specifications (Slides 19-22). The main premise here was = that a recipient device that expects secured traffic, will reject all = incoming unsecured traffic, unless this originates from a device with = so-called "exempt status". This "exempt status" construct allows receipt = of incoming unsecured data frames from a joining node that does not have = network-specific keying material yet. How to switch on/off this "exempt = status" parameter was also discussed (see Slide 20). Furthermore, there = was some discussion on how this compares to the use of so-called = "default keys" (aka "fake" keys) (see also Slide 22). >=20 > PG mentioned that 802.15.4 does not allow the use of the default key. = SD suggested that an important point in not using default keys is that = all incoming processing with keys will be treated transparently, = irrespective of exceptions. RS explained that even if default keys were = to be used, this would mess up local security state (e.g., frame = counters), which is not the case if one would send unsecured traffic and = use the "exempt status" construct instead. PD summarized that using = unsecured frames, rather than "fake" security with "default keys", = should be adopted, which was consensus on the call. >=20 > PG came back to the "exempt flag" topic and suggested that details = hereof are in the "device descriptor lookup table". RS suggested that we = all have a closer look at specification details, so that switching this = feature on/off could be easily codified for 6TiSCH use. >=20 > 5. Join process - non-MAC behavior. > Given remaining time on the call would not allow full discussion of = non-MAC aspects (Slides 23-25) and given that MR had to drop off the = call, it was decided to revisit those topics at the next conf call. >=20 > 6. AOB Conf call scheduling. > SD suggested he was confused about having two call times in email = traffic (one at 9am EST and one at 11am EST) and suggested that other = groups, such as, e.g., IEEE, often use cyclic schedule, so as to = accommodate participants from around the world and who may be at widely = different time zones. RS volunteered to look into this topic and obtain = feedback on such a schedule. >=20 > Best regards, Rene >=20 > On 12/1/2014 11:55 AM, Rene Struik wrote: > Proposed agenda: >=20 > 0) Agenda bashing >=20 > 1) Join protocol details > a) desired properties > b) realizable properties > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. >=20 > I will prepare material to facilitate discussion on 1) and 2), to be = discussed during the call. >=20 > Best regards, Rene >=20 >=20 > On 11/28/2014 11:02 AM, Rene Struik wrote: > Dear colleagues: >=20 > I have set up a conf call for Tuesday December 2, 2014 at a time that = tries and accommodate people in different time zones to the largest = extent possible, without trying to discriminate against various parts of = the world. >=20 > Please see dial-in information below. >=20 > Agenda to follow Monday around noon. >=20 > Looking forward to a collaborative meeting, in good spirit. > =20 > Best regards, Rene > =3D=3D > =20 > 1. Please join my meeting. > https://global.gotomeeting.com/join/594299061 = > =20 > 2. Use your microphone and speakers (VoIP) - a headset is = recommended. Or, call in using your telephone. > =20 > Dial +1 (647) 497-9351 > Access Code: 594-299-061 > Audio PIN: Shown after joining the meeting > =20 > Meeting Password: collaborate > Meeting ID: 594-299-061 > =20 > GoToMeeting=C2=AE > Online Meetings Made Easy=C2=AE > =20 > Not at your computer? Click the link to join this meeting from your = iPhone=C2=AE, iPad=C2=AE, Android=C2=AE or Windows Phone=C2=AE device = via the GoToMeeting app. >=20 >=20 >=20 > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This = should allow people to have their private time in the 12am-6am time = window. {Other groups do a much better job at this...}=20 >=20 >=20 > On 11/28/2014 10:39 AM, Michael Richardson wrote: > Subir Das wrote: > > Thanks for arranging the calls. It would be good to accommodate = Asian time > > zone for broader participation. I would suggest choosing a time = that is > =20 > I'm happy to do this at another time; the original choice of 11am = Eastern was > to accomodate Pacific Time Zone People who couldn't meet before 8am. =20= > =20 > >=46rom long experience, our choices essentially are at 15:00 UTC or = 03:00 UTC. > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > or > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > =20 > I am also happy to alternate. > Shall I put up a doodle poll? > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security = >=20 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --=20 email: rstruik.ext@gmail.com | Skype: = rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 _______________________________________________ 6tisch-security mailing list 6tisch-security@ietf.org https://www.ietf.org/mailman/listinfo/6tisch-security --Apple-Mail=_D112E542-D826-4A43-9F88-74939BD801BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The Payload IEs are indeed encrypted if the frame is = encrypted, that was part of the intent of having two types of IEs.

Pat

Pat= Kinney
Kinney = Consulting LLC
IEEE 802.15 WG vice chair, = TG chair
ISA100.11a WG chair
O: = +1.847.960.3715
pat.kinney@kinneyconsultingllc.com
=






On 9, Dec2014, at 17:19, Rene Struik = <rstruik.ext@gmail.com> wrote:

=20 =20
Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp<= /a> wrote:

I = think all PAN Descriptor fields are either contained in the visible part of Beacon frame or obtained as associated information of the frame.  Some TSCH-related IEs, such = as TSCH Synchronization, TSCH Slotframe and Link, TSCH Timeslot, Channel Hopping

Sequence IEs, are contained as Payload IEs, and are not accessible from joining node if they are encrypted.

 

Of course, if the Beacon frame is authenticated-only and unencrypted, then all information is visible to joining node, but joining node has to process AES-CCM* encoded cleartext information even if key is not available (I am not sure if existing implementation supports this kind of processing).

 

Yoshihiro Ohba

 

 

 

 

 

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Tuesday, December 9, 2014 11:22 = AM
To: ohba yoshihiro(=E5=A4=A7=E5=A0=B4 =E7=BE=A9=E6=B4=8B =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=AE=EF=BC=B3=EF=BC=AC)
Cc: tisch-security
Subject: Re: [6tisch-security] = (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan

 

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik wrote:

Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:

If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of =E2=80=9Cexempt status=E2=80=9D.  I thought the =E2=80=9Cexempt = status=E2=80=9D is maintained by higher layer and is different from the =E2=80=9CExempt=E2=80= =9D flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the =E2=80=9CExempt=E2=80=9D = flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node=E2=80=99s higher layer to process = authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 = 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] = (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm = Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/vi= ew?usp=3Dsharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/vi= ew?usp=3Dsharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable = properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a = plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) = desired properties
b) realizable properties

2) Next steps:
        a) consensus = on 1#a and 1#b
        b) form = tiger team to work out details
        =     - project phases
        =     - communication of sub-results
        c) what to = squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

=3D=3D

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting=C2=AE

Online Meetings Made Easy=C2=AE

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson = wrote:

Subir =
Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It =
would be good to accommodate Asian time
= 
    > zone for broader participation. I =
would suggest choosing a time that is
 
I'm =
happy to do this at another time; the original choice of 11am Eastern =
was
to =
accomodate Pacific Time Zone People who couldn't meet before 8am.  =

 
>=46r=
om long experience, our choices essentially are at 15:00 UTC or 03:00 =
UTC.
    07:00 Pacific/10:00 Eastern / 17:00 =
Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 =
Helsinki/10:00 Beijing
 
I am =
also happy to alternate.
Shall =
I put up a doodle poll?
 





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





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





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





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




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




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


--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security

= --Apple-Mail=_D112E542-D826-4A43-9F88-74939BD801BA-- From nobody Tue Dec 9 15:31:26 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 4A8251A88A1 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrCcZcBBJG7C for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:31:19 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6496A1A00E8 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 15:31:18 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl2so5488327igb.11 for <6tisch-security@ietf.org>; Tue, 09 Dec 2014 15:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=y6SYY1bBzkddee3LABlN2U51pohLpiv2vIDpuVCo7TY=; b=P8zVtmIMLa1REkWxbQs7H5QXRYgen3nOO/GTw38/mnnS/4QtunMKxJGhukhMhZnaAM fvPxoN2avWKq5Rjx4ATR1t6Sd26nT2pAVBoGECD7oAjgJU3Uig7TIEeeJ4ki2ZSxttEz w+j34IqfWHpAUjC4KgVJ0rbmeJtH/15B/n5VfltJ9mwjSkQKoskqb4jBR9waDDHrUEQP fs5J4Yva1Q6qug8j4ymXx0cN5oLwLr0RYalQlT3mrLzYgBJ8waqpDYS2jR6YxIifDgmt nbNjT8hyj7/SC0MD6vOSmusvAf0El7C0iCW0Ti6NwvymHHcCmztwUm20ILWc57L0ytyU LeXA== X-Received: by 10.50.128.129 with SMTP id no1mr1392825igb.32.1418167877453; Tue, 09 Dec 2014 15:31:17 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id l2sm1311708ioe.34.2014.12.09.15.31.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 15:31:16 -0800 (PST) Message-ID: <54878641.1010603@gmail.com> Date: Tue, 09 Dec 2014 18:31:13 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Pat Kinney References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> <54878389.7020905@gmail.com> <099BF16F-1ACD-465C-A720-EBD2031F387B@kinneyconsultingllc.com> In-Reply-To: <099BF16F-1ACD-465C-A720-EBD2031F387B@kinneyconsultingllc.com> Content-Type: multipart/alternative; boundary="------------060305040509010108000804" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/sngH3b2rw2mPBbStvDNL2_ZnK7U Cc: tisch-security <6tisch-security@ietf.org>, yoshihiro.ohba@toshiba.co.jp Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:31:24 -0000 This is a multi-part message in MIME format. --------------060305040509010108000804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The current language is not entirely clear; hence, my note. Rene On 12/9/2014 6:28 PM, Pat Kinney wrote: > The Payload IEs are indeed encrypted if the frame is encrypted, that > was part of the intent of having two types of IEs. > > Pat > > Pat Kinney > */Kinney Consulting LLC/* > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com > > > > > > > > On 9, Dec2014, at 17:19, Rene Struik > wrote: > > Hi Yoshi: > > According to Section 5.2.4.1, Payload Information Elements do not seem > to be encrypted (cf. below). Curiously, though, this seems to be > inconsistent with the incoming and outgoing security processing in > 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure > 802.15.4-2012 did not redefine). > > Best regards, Rene > > [excerpt of 802.15.4e-2012, Clause 5.2.4.1] > IEs may be either part of the MAC Header or MAC payload. Header IEs > are used by the MAC to process the > frame immediately, i.e., they cover security, addressing, etc., and > are part of the MAC Header. Payload IEs > are destined for another layer or SAP and are part of the MAC payload > (but like command IDs they may not > be encrypted). If IEs are contained in a frame, they always occur > before other unstructured MAC payload > elements. > > On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp wrote: >> >> I think all PAN Descriptor fields are either contained in the visible >> part of Beacon frame or obtained as associated information of the >> frame. Some TSCH-related IEs, such as TSCH Synchronization, TSCH >> Slotframe and Link, TSCH Timeslot, Channel Hopping >> >> Sequence IEs, are contained as Payload IEs, and are not accessible >> from joining node if they are encrypted. >> >> Of course, if the Beacon frame is authenticated-only and unencrypted, >> then all information is visible to joining node, but joining node has >> to process AES-CCM* encoded cleartext information even if key is not >> available (I am not sure if existing implementation supports this >> kind of processing). >> >> Yoshihiro Ohba >> >> *From:*Rene Struik [mailto:rstruik.ext@gmail.com] >> *Sent:* Tuesday, December 9, 2014 11:22 AM >> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ) >> *Cc:* tisch-security >> *Subject:* Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST >> call) Re: (now with agenda) Re: invite for 6tisch security call Tue >> December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan >> >> Hi Yoshi: >> >> The passive scan language in the 802.15.4-2011 spec is in Clause >> 5.1.2.1.2. I think one should also look at the PAN descriptor and see >> which elements of the enhanced beacon that are in the PAN descriptor >> table are visible to a "newbee" device. Would you like to give this a >> look? >> >> Best regards, Rene >> >> On 12/8/2014 8:48 PM, Rene Struik wrote: >> >> Hi Yoshi: >> >> Good point (and I remember we discussed this, while going over >> Slide 20, but I forgot to include this in the minutes [I will >> correct this]). >> >> The idea is that if a joining device receives a secured beacon >> frame, it can still extract the visible portion of the frame, >> even if it cannot do proper incoming security processing >> (obviously, it cannot really rely on this data at this point, then). >> >> With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active >> Channel Scan), of which the excerpt from p. 174 of the spec >> describes the corresponding behavior: >> >> If a protected beacon frame is received, i.e., the Security >> Enabled subfield in the Frame Control field is set to one, >> the device shall attempt to unsecure the beacon frame using >> the unsecuring process described in 7.5.8.2.3. >> The security-related elements of the PAN descriptor >> corresponding to the beacon (see Table 55) shall be set to >> the corresponding parameters returned by the unsecuring >> process. The SecurityFailure element of the PAN descriptor >> shall be set to SUCCESS if the status from the unsecuring >> process is SUCCESS and set to one of the other status codes >> indicating an error in the security processing otherwise. The >> information from the unsecured frame shall be recorded in the >> PAN descriptor even if the status from the unsecuring process >> indicated an error. >> >> I did not check yet whether the later spec 802.15.4-2011 changed >> this behavior or whether 802.15.4e-2012 did, but if I remember >> correctly the 802.15.4e spec did not modify any of this, so the >> remaining check would be 2006 --> 2011. >> >> Best regards, Rene >> >> >> On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp >> wrote: >> >> Hi Rene, >> >> I would like to double check the meaning of “exempt statusâ€. >> I thought the “exempt status†is maintained by higher layer >> and is different from the “Exempt†flag of 802.15.4-2011 >> DeviceDescriptor of Security-related PIB attributes. >> >> I am asking this because, while the “Exempt†flag of >> 802.15.4-2011 DeviceDescriptor of Security-related PIB >> attributes allows unsecured frames to be passed to higher >> layer, the flag solely does not help for joining node’s >> higher layer to process authenticated-only secured beacons. >> >> Yoshihiro Ohba >> >> *From:*6tisch-security >> [mailto:6tisch-security-bounces@ietf.org] *On Behalf Of *Rene >> Struik >> *Sent:* Tuesday, December 9, 2014 8:09 AM >> *Cc:* 6tisch-security@ietf.org >> *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am >> EST call) Re: (now with agenda) Re: invite for 6tisch >> security call Tue December 2, 2014, 9am EST = 6am PST = 3pm >> Paris = 11pm Japan >> >> Dear colleagues: >> >> Please find below the minutes of the 6TiSCH Security conf >> call as of December 2, 2014, 9am EST. >> >> Minutes 6TiSCH Security conf call, Tue December 2, 2014, >> 9-10am EST >> {note taker: Rene Struik} >> {recording: >> https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing} >> {slides discussed (and referenced in minutes): >> https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing} >> >> 1. Attendance: >> Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, >> Rene Struik >> >> 2. Agenda >> The suggested agend was approved. >> >> 3. Join process - desirable vs. realizable properties >> RS went over the desirable properties of the join process >> (Slide 6). MR raised point that privacy of the device >> identity of the joining node might not be required. . SD >> suggested that it is fine to include privacy in list of >> "desiderata"; evaluation metrics might consider these in >> "grey tones" vs. as "black and white" requirement. RS >> suggested that merit of privacy might depend on deployment >> scenario, but is on the radar in lots of IETF groups (in >> terms of traceability/tracking); if privacy can be easily >> offered as additional feature, this would be a plus. After >> asking, there was no further discussion on properties listed. >> >> 4. Join process - MAC behavior. >> RS went over some MAC security aspects of the 802.15.4-2011 >> and 802.15.4e-2012 specifications (Slides 19-22). The main >> premise here was that a recipient device that expects secured >> traffic, will reject all incoming unsecured traffic, unless >> this originates from a device with so-called "exempt status". >> This "exempt status" construct allows receipt of incoming >> unsecured data frames from a joining node that does not have >> network-specific keying material yet. How to switch on/off >> this "exempt status" parameter was also discussed (see Slide >> 20). Furthermore, there was some discussion on how this >> compares to the use of so-called "default keys" (aka "fake" >> keys) (see also Slide 22). >> >> PG mentioned that 802.15.4 does not allow the use of the >> default key. SD suggested that an important point in not >> using default keys is that all incoming processing with keys >> will be treated transparently, irrespective of exceptions. RS >> explained that even if default keys were to be used, this >> would mess up local security state (e.g., frame counters), >> which is not the case if one would send unsecured traffic and >> use the "exempt status" construct instead. PD summarized that >> using unsecured frames, rather than "fake" security with >> "default keys", should be adopted, which was consensus on the >> call. >> >> PG came back to the "exempt flag" topic and suggested that >> details hereof are in the "device descriptor lookup table". >> RS suggested that we all have a closer look at specification >> details, so that switching this feature on/off could be >> easily codified for 6TiSCH use. >> >> 5. Join process - non-MAC behavior. >> Given remaining time on the call would not allow full >> discussion of non-MAC aspects (Slides 23-25) and given that >> MR had to drop off the call, it was decided to revisit those >> topics at the next conf call. >> >> 6. AOB Conf call scheduling. >> SD suggested he was confused about having two call times in >> email traffic (one at 9am EST and one at 11am EST) and >> suggested that other groups, such as, e.g., IEEE, often use >> cyclic schedule, so as to accommodate participants from >> around the world and who may be at widely different time >> zones. RS volunteered to look into this topic and obtain >> feedback on such a schedule. >> >> Best regards, Rene >> >> On 12/1/2014 11:55 AM, Rene Struik wrote: >> >> Proposed agenda: >> >> 0) Agenda bashing >> >> 1) Join protocol details >> >> a) desired properties >> b) realizable properties >> >> 2) Next steps: >> a) consensus on 1#a and 1#b >> b) form tiger team to work out details >> - project phases >> - communication of sub-results >> c) what to squeeze into architecture draft, etc. >> >> I will prepare material to facilitate discussion on 1) >> and 2), to be discussed during the call. >> >> Best regards, Rene >> >> >> On 11/28/2014 11:02 AM, Rene Struik wrote: >> >> Dear colleagues: >> >> >> I have set up a conf call for Tuesday December 2, >> 2014 at a time that tries and accommodate people in >> different time zones to the largest extent possible, >> without trying to discriminate against various parts >> of the world. >> >> >> Please see dial-in information below. >> >> >> Agenda to follow Monday around noon. >> >> >> Looking forward to a collaborative meeting, in good >> spirit. >> >> Best regards, Rene >> >> == >> >> 1. Please join my meeting. >> >> https://global.gotomeeting.com/join/594299061 >> >> 2. Use your microphone and speakers (VoIP) - a >> headset is recommended. Or, call in using your >> telephone. >> >> Dial +1 (647) 497-9351 >> >> Access Code: 594-299-061 >> >> Audio PIN: Shown after joining the meeting >> >> Meeting Password: collaborate >> >> Meeting ID: 594-299-061 >> >> GoToMeeting® >> >> Online Meetings Made Easy® >> >> Not at your computer? Click the link to join this >> meeting from your iPhone®, iPad®, Android® or Windows >> Phone® device via the GoToMeeting app. >> >> >> >> >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. >> This should allow people to have their private time >> in the 12am-6am time window. {Other groups do a much >> better job at this...} >> >> >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >> >> Subir Das wrote: >> >> > Thanks for arranging the calls. It would be good to accommodate Asian time >> >> > zone for broader participation. I would suggest choosing a time that is >> >> >> >> I'm happy to do this at another time; the original choice of 11am Eastern was >> >> to accomodate Pacific Time Zone People who couldn't meet before 8am. >> >> >> >> >From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC. >> >> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >> >> or >> >> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >> >> >> >> I am also happy to alternate. >> >> Shall I put up a doodle poll? >> >> >> >> >> >> >> >> _______________________________________________ >> >> 6tisch-security mailing list >> >> 6tisch-security@ietf.org >> >> https://www.ietf.org/mailman/listinfo/6tisch-security >> >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> -- >> >> email:rstruik.ext@gmail.com | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> >> >> -- >> email:rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------060305040509010108000804 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
The current language is not entirely clear; hence, my note.

Rene

On 12/9/2014 6:28 PM, Pat Kinney wrote:
The Payload IEs are indeed encrypted if the frame is encrypted, that was part of the intent of having two types of IEs.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715






On 9, Dec2014, at 17:19, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp wrote:

I think all PAN Descriptor fields are either contained in the visible part of Beacon frame or obtained as associated information of the frame.  Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and Link, TSCH Timeslot, Channel Hopping

Sequence IEs, are contained as Payload IEs, and are not accessible from joining node if they are encrypted.

 

Of course, if the Beacon frame is authenticated-only and unencrypted, then all information is visible to joining node, but joining node has to process AES-CCM* encoded cleartext information even if key is not available (I am not sure if existing implementation supports this kind of processing).

 

Yoshihiro Ohba

 

 

 

 

 

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Tuesday, December 9, 2014 11:22 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: tisch-security
Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik wrote:

Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:

If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of “exempt statusâ€.  I thought the “exempt status†is maintained by higher layer and is different from the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the “Exempt†flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node’s higher layer to process authenticated-only secured beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired properties
b) realizable properties

2) Next steps:
        a) consensus on 1#a and 1#b
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

==

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting®

Online Meetings Made Easy®

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. It would be good to accommodate Asian time
    > zone for broader participation. I would suggest choosing a time that is
 
I'm happy to do this at another time; the original choice of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet before 8am.  
 
>From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
 
I am also happy to alternate.
Shall I put up a doodle poll?
 





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





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





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





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




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




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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch-security mailing list
6tisch-security@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch-security



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------060305040509010108000804-- From nobody Tue Dec 9 15:50:13 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A881A1A4A for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Lb1T6dwmRWYq for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 15:50:05 -0800 (PST) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF991A1A48 for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 15:50:05 -0800 (PST) Received: from [10.0.1.55] ([50.172.118.112]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id Rbq21p00K2RbJC201bq3vf; Tue, 09 Dec 2014 16:50:04 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1C5E7C3-CB5C-4DEB-91B7-E754B465AA94" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Pat Kinney In-Reply-To: <54878641.1010603@gmail.com> Date: Tue, 9 Dec 2014 17:50:02 -0600 Message-Id: <8572CE65-747B-4B87-AF94-0AEE4AC9111A@kinneyconsultingllc.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> <54878389.7020905@gmail.com> <099BF16F-1ACD-465C-A720-EBD2031F387B@kinneyconsultingllc.com> <54878641.1010603@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/WTKSVRDxbd4AhEIQzH46CXVL-_g Cc: tisch-security <6tisch-security@ietf.org>, yoshihiro.ohba@toshiba.co.jp Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:50:10 -0000 --Apple-Mail=_B1C5E7C3-CB5C-4DEB-91B7-E754B465AA94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To help clarify the procedure, Tero Kivinen is drawing state diagrams = for the 802.15.4 revision Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 pat.kinney@kinneyconsultingllc.com = On 9, Dec2014, at 17:31, Rene Struik wrote: The current language is not entirely clear; hence, my note.=20 Rene On 12/9/2014 6:28 PM, Pat Kinney wrote: > The Payload IEs are indeed encrypted if the frame is encrypted, that = was part of the intent of having two types of IEs. >=20 > Pat >=20 > Pat Kinney > Kinney Consulting LLC > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com = >=20 >=20 >=20 >=20 >=20 >=20 > On 9, Dec2014, at 17:19, Rene Struik > wrote: >=20 > Hi Yoshi: >=20 > According to Section 5.2.4.1, Payload Information Elements do not seem = to be encrypted (cf. below). Curiously, though, this seems to be = inconsistent with the incoming and outgoing security processing in = 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure = 802.15.4-2012 did not redefine). >=20 > Best regards, Rene >=20 > [excerpt of 802.15.4e-2012, Clause 5.2.4.1] > IEs may be either part of the MAC Header or MAC payload. Header IEs = are used by the MAC to process the > frame immediately, i.e., they cover security, addressing, etc., and = are part of the MAC Header. Payload IEs > are destined for another layer or SAP and are part of the MAC payload = (but like command IDs they may not > be encrypted). If IEs are contained in a frame, they always occur = before other unstructured MAC payload > elements. >=20 > On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp = wrote: >> I think all PAN Descriptor fields are either contained in the visible = part of Beacon frame or obtained as associated information of the frame. = Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and = Link, TSCH Timeslot, Channel Hopping >> Sequence IEs, are contained as Payload IEs, and are not accessible = from joining node if they are encrypted. >> =20 >> Of course, if the Beacon frame is authenticated-only and unencrypted, = then all information is visible to joining node, but joining node has to = process AES-CCM* encoded cleartext information even if key is not = available (I am not sure if existing implementation supports this kind = of processing). >> =20 >> Yoshihiro Ohba >> =20 >> =20 >> =20 >> =20 >> =20 >> From: Rene Struik [mailto:rstruik.ext@gmail.com = ]=20 >> Sent: Tuesday, December 9, 2014 11:22 AM >> To: ohba yoshihiro(=E5=A4=A7=E5=A0=B4 =E7=BE=A9=E6=B4=8B = =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=AE=EF=BC=B3=EF=BC=AC) >> Cc: tisch-security >> Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST = call) Re: (now with agenda) Re: invite for 6tisch security call Tue = December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan >> =20 >> Hi Yoshi: >>=20 >> The passive scan language in the 802.15.4-2011 spec is in Clause = 5.1.2.1.2. I think one should also look at the PAN descriptor and see = which elements of the enhanced beacon that are in the PAN descriptor = table are visible to a "newbee" device. Would you like to give this a = look? >>=20 >> Best regards, Rene >>=20 >> On 12/8/2014 8:48 PM, Rene Struik wrote: >> Hi Yoshi: >>=20 >> Good point (and I remember we discussed this, while going over Slide = 20, but I forgot to include this in the minutes [I will correct this]). >>=20 >> The idea is that if a joining device receives a secured beacon frame, = it can still extract the visible portion of the frame, even if it cannot = do proper incoming security processing (obviously, it cannot really rely = on this data at this point, then). >>=20 >> With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active = Channel Scan), of which the excerpt from p. 174 of the spec describes = the corresponding behavior: >> If a protected beacon frame is received, i.e., the Security Enabled = subfield in the Frame Control field is set to one, the device shall = attempt to unsecure the beacon frame using the unsecuring process = described in 7.5.8.2.3. >> The security-related elements of the PAN descriptor corresponding to = the beacon (see Table 55) shall be set to the corresponding parameters = returned by the unsecuring process. The SecurityFailure element of the = PAN descriptor shall be set to SUCCESS if the status from the unsecuring = process is SUCCESS and set to one of the other status codes indicating = an error in the security processing otherwise. The information from the = unsecured frame shall be recorded in the PAN = descriptor even if the status from the unsecuring process indicated an = error. >>=20 >> I did not check yet whether the later spec 802.15.4-2011 changed this = behavior or whether 802.15.4e-2012 did, but if I remember correctly the = 802.15.4e spec did not modify any of this, so the remaining check would = be 2006 --> 2011. >>=20 >> Best regards, Rene >>=20 >>=20 >> On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp = wrote: >> Hi Rene, >> =20 >> I would like to double check the meaning of =E2=80=9Cexempt = status=E2=80=9D. I thought the =E2=80=9Cexempt status=E2=80=9D is = maintained by higher layer and is different from the =E2=80=9CExempt=E2=80= =9D flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB = attributes. >> =20 >> I am asking this because, while the =E2=80=9CExempt=E2=80=9D flag of = 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows = unsecured frames to be passed to higher layer, the flag solely does not = help for joining node=E2=80=99s higher layer to process = authenticated-only secured beacons. >> =20 >> Yoshihiro Ohba >> =20 >> =20 >> From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org = ] On Behalf Of Rene Struik >> Sent: Tuesday, December 9, 2014 8:09 AM >> Cc: 6tisch-security@ietf.org >> Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) = Re: (now with agenda) Re: invite for 6tisch security call Tue December = 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan >> =20 >> Dear colleagues: >>=20 >> Please find below the minutes of the 6TiSCH Security conf call as of = December 2, 2014, 9am EST. >>=20 >> Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST >> {note taker: Rene Struik} >> {recording: = https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=3Dsh= aring = } >> {slides discussed (and referenced in minutes): = https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=3Dsh= aring = } >>=20 >> 1. Attendance: >> Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik >>=20 >> 2. Agenda >> The suggested agend was approved. >>=20 >> 3. Join process - desirable vs. realizable properties >> RS went over the desirable properties of the join process (Slide 6). = MR raised point that privacy of the device identity of the joining node = might not be required. . SD suggested that it is fine to include privacy = in list of "desiderata"; evaluation metrics might consider these in = "grey tones" vs. as "black and white" requirement. RS suggested that = merit of privacy might depend on deployment scenario, but is on the = radar in lots of IETF groups (in terms of traceability/tracking); if = privacy can be easily offered as additional feature, this would be a = plus. After asking, there was no further discussion on properties = listed. >>=20 >> 4. Join process - MAC behavior. >> RS went over some MAC security aspects of the 802.15.4-2011 and = 802.15.4e-2012 specifications (Slides 19-22). The main premise here was = that a recipient device that expects secured traffic, will reject all = incoming unsecured traffic, unless this originates from a device with = so-called "exempt status". This "exempt status" construct allows receipt = of incoming unsecured data frames from a joining node that does not have = network-specific keying material yet. How to switch on/off this "exempt = status" parameter was also discussed (see Slide 20). Furthermore, there = was some discussion on how this compares to the use of so-called = "default keys" (aka "fake" keys) (see also Slide 22). >>=20 >> PG mentioned that 802.15.4 does not allow the use of the default key. = SD suggested that an important point in not using default keys is that = all incoming processing with keys will be treated transparently, = irrespective of exceptions. RS explained that even if default keys were = to be used, this would mess up local security state (e.g., frame = counters), which is not the case if one would send unsecured traffic and = use the "exempt status" construct instead. PD summarized that using = unsecured frames, rather than "fake" security with "default keys", = should be adopted, which was consensus on the call. >>=20 >> PG came back to the "exempt flag" topic and suggested that details = hereof are in the "device descriptor lookup table". RS suggested that we = all have a closer look at specification details, so that switching this = feature on/off could be easily codified for 6TiSCH use. >>=20 >> 5. Join process - non-MAC behavior. >> Given remaining time on the call would not allow full discussion of = non-MAC aspects (Slides 23-25) and given that MR had to drop off the = call, it was decided to revisit those topics at the next conf call. >>=20 >> 6. AOB Conf call scheduling. >> SD suggested he was confused about having two call times in email = traffic (one at 9am EST and one at 11am EST) and suggested that other = groups, such as, e.g., IEEE, often use cyclic schedule, so as to = accommodate participants from around the world and who may be at widely = different time zones. RS volunteered to look into this topic and obtain = feedback on such a schedule. >>=20 >> Best regards, Rene >>=20 >> On 12/1/2014 11:55 AM, Rene Struik wrote: >> Proposed agenda: >>=20 >> 0) Agenda bashing >>=20 >> 1) Join protocol details >> a) desired properties >> b) realizable properties >> 2) Next steps: >> a) consensus on 1#a and 1#b >> b) form tiger team to work out details >> - project phases >> - communication of sub-results >> c) what to squeeze into architecture draft, etc. >>=20 >> I will prepare material to facilitate discussion on 1) and 2), to be = discussed during the call. >>=20 >> Best regards, Rene >>=20 >>=20 >> On 11/28/2014 11:02 AM, Rene Struik wrote: >> Dear colleagues: >>=20 >> I have set up a conf call for Tuesday December 2, 2014 at a time that = tries and accommodate people in different time zones to the largest = extent possible, without trying to discriminate against various parts of = the world. >>=20 >> Please see dial-in information below. >>=20 >> Agenda to follow Monday around noon. >>=20 >> Looking forward to a collaborative meeting, in good spirit. >> =20 >> Best regards, Rene >> =3D=3D >> =20 >> 1. Please join my meeting. >> https://global.gotomeeting.com/join/594299061 = >> =20 >> 2. Use your microphone and speakers (VoIP) - a headset is = recommended. Or, call in using your telephone. >> =20 >> Dial +1 (647) 497-9351 >> Access Code: 594-299-061 >> Audio PIN: Shown after joining the meeting >> =20 >> Meeting Password: collaborate >> Meeting ID: 594-299-061 >> =20 >> GoToMeeting=C2=AE >> Online Meetings Made Easy=C2=AE >> =20 >> Not at your computer? Click the link to join this meeting from your = iPhone=C2=AE, iPad=C2=AE, Android=C2=AE or Windows Phone=C2=AE device = via the GoToMeeting app. >>=20 >>=20 >>=20 >> [excerpt email as of Thu November 27, 2014, 9.42pm EST] >> I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This = should allow people to have their private time in the 12am-6am time = window. {Other groups do a much better job at this...}=20 >>=20 >>=20 >> On 11/28/2014 10:39 AM, Michael Richardson wrote: >> Subir Das wrote: >> > Thanks for arranging the calls. It would be good to accommodate = Asian time >> > zone for broader participation. I would suggest choosing a time = that is >> =20 >> I'm happy to do this at another time; the original choice of 11am = Eastern was >> to accomodate Pacific Time Zone People who couldn't meet before 8am. =20= >> =20 >> >=46rom long experience, our choices essentially are at 15:00 UTC or = 03:00 UTC. >> 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing >> or >> 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing >> =20 >> I am also happy to alternate. >> Shall I put up a doodle poll? >> =20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security = >>=20 >>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>=20 >>=20 >>=20 >> --=20 >> email: rstruik.ext@gmail.com | Skype: = rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 >=20 > --=20 > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security = >=20 --=20 email: rstruik.ext@gmail.com | Skype: = rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --Apple-Mail=_B1C5E7C3-CB5C-4DEB-91B7-E754B465AA94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To help clarify the procedure, Tero Kivinen is drawing state = diagrams for the 802.15.4 revision

Pat= Kinney
Kinney = Consulting LLC
IEEE 802.15 WG vice chair, = TG chair
ISA100.11a WG chair
O: = +1.847.960.3715
pat.kinney@kinneyconsultingllc.com
=






On 9, Dec2014, at 17:31, Rene Struik = <rstruik.ext@gmail.com> wrote:

=20 =20
The current language is not entirely clear; hence, my note.

Rene

On 12/9/2014 6:28 PM, Pat Kinney wrote:
The Payload IEs are indeed encrypted if the frame is encrypted, that was part of the intent of having two types of IEs.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
pat.kinney@kinneyconsultingllc.com






On 9, Dec2014, at 17:19, Rene Struik <rstruik.ext@gmail.com> wrote:

Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
= IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, yoshihiro.ohba@toshiba.co.jp<= /a> wrote:

I = think all PAN Descriptor fields are either contained in the visible part of Beacon frame or obtained as associated information of the frame.  Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and Link, TSCH Timeslot, Channel Hopping

Sequence IEs, are contained as Payload IEs, and are not accessible from joining node if they are encrypted.

 

Of = course, if the Beacon frame is authenticated-only and unencrypted, then all information is visible to joining node, but joining node has to process AES-CCM* encoded cleartext information even if key is not available (I am not sure if existing implementation supports this kind of processing).

 

Yoshihiro Ohba

 
 
 
 
 

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Tuesday, December 9, 2014 11:22 AM
To: ohba = yoshihiro(=E5=A4=A7=E5=A0=B4 =E7=BE=A9=E6=B4=8B =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=AE=EF=BC=B3=EF=BC=AC)
Cc: tisch-security
Subject: Re: = [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan

 

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik = wrote:

Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:

If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
= The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene


On 12/8/2014 7:03 PM, yoshihiro.ohba@toshiba.co.jp wrote:

Hi Rene,

 

I would like to double check the meaning of =E2=80=9Cexempt = status=E2=80=9D.  I thought the =E2=80=9Cexempt status=E2=80=9D is = maintained by higher layer and is different from the =E2=80=9CExempt=E2=80=9D flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

 

I am asking this because, while the =E2=80=9CExempt=E2=80=9D = flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node=E2=80=99s higher layer to process authenticated-only secured = beacons.

 

Yoshihiro Ohba

 

 

From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf Of Rene = Struik
Sent: Tuesday, December = 9, 2014 8:09 AM
Cc: 6tisch-security@ietf.org
Subject: = [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm = Japan

 

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/vi= ew?usp=3Dsharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/vi= ew?usp=3Dsharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, = this  would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
= RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter was also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table". RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik = wrote:

Proposed agenda:

0) Agenda bashing

1) Join protocol details

a) desired = properties
b) realizable properties

2) Next steps:
        a) = consensus on 1#a and 1#b
        = b) form tiger team to work out details
        =     - project phases
        =     - communication of sub-results
        c) = what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik = wrote:

Dear colleagues:


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


Please see dial-in information below. =


Agenda to follow Monday around = noon.


Looking forward to a collaborative meeting, in good spirit.

 

Best regards, Rene

=3D=3D

 

1.  Please join my meeting.

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

 

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

 

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the = meeting

 

Meeting Password: collaborate

Meeting ID: 594-299-061

 

GoToMeeting=C2=AE

Online Meetings Made Easy=C2=AE

 

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




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


On 11/28/2014 10:39 AM, Michael Richardson wrote:

Subir Das <subirdas21@gmail.com> wrote:
    > Thanks for arranging the calls. =
It would be good to accommodate Asian time
    > zone for broader participation. I =
would suggest choosing a time that is
 
I'm happy to do this at another time; the original choice =
of 11am Eastern was
to accomodate Pacific Time Zone People who couldn't meet =
before 8am.  
 
>=46rom long experience, our choices essentially are =
at 15:00 UTC or 03:00 UTC.
    07:00 Pacific/10:00 Eastern / 17:00 =
Helsinki/22:00 Beijing
or
    19:00 Pacific/22:00 Eastern / 05:00 =
Helsinki/10:00 Beijing
 
I am also happy to alternate.
Shall I put up a doodle poll?
 





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





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





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





-- =

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




-- =

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




-- =

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


--=20
email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
= 6tisch-security mailing list
6tisch-security@ietf.org
https://www= .ietf.org/mailman/listinfo/6tisch-security



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

= --Apple-Mail=_B1C5E7C3-CB5C-4DEB-91B7-E754B465AA94-- From nobody Thu Dec 11 02:58:03 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797241ACDF1 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 02:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=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 Odv5gTWBVFAY for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 02:57:56 -0800 (PST) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id D90FF1A878C for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 02:57:54 -0800 (PST) Received: from mail-pa0-f51.google.com ([209.85.220.51]) by smtpcmd02.ad.aruba.it with bizsmtp id SAxp1p01S1788JR01Axr7D; Thu, 11 Dec 2014 11:57:52 +0100 Received: by mail-pa0-f51.google.com with SMTP id ey11so4807444pad.24 for ; Thu, 11 Dec 2014 02:57:50 -0800 (PST) X-Received: by 10.68.162.100 with SMTP id xz4mr15998586pbb.138.1418295470209; Thu, 11 Dec 2014 02:57:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.79.10 with HTTP; Thu, 11 Dec 2014 02:57:20 -0800 (PST) In-Reply-To: <20141211104151.3519.5838.idtracker@ietfa.amsl.com> References: <20141211104151.3519.5838.idtracker@ietfa.amsl.com> From: Giuseppe Piro Date: Thu, 11 Dec 2014 11:57:20 +0100 Message-ID: To: 6tisch-security@ietf.org, "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=047d7ba96d9cb044a60509eea51d Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/BDRmDoBRTBQ4110wwXFrLDHhD0g Cc: Gennaro Boggia , Alfredo Grieco , Giuseppe Piro Subject: [6tisch-security] Fwd: New Version Notification for draft-piro-6tisch-security-issues-03.txt 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, 11 Dec 2014 10:57:58 -0000 --047d7ba96d9cb044a60509eea51d Content-Type: text/plain; charset=UTF-8 Dear all, a new version of our draft draft-piro-6tisch-security-issues has been submitted. We are still focusing the attention on L2 security aspects (i.e., how generating the key, how storing keys and related attributes within MAC PIB tables, and so on). However, we have revised some concepts by using the terminology introduced by Michael in its ID draft-richardson-6tisch--security-6top, like "production network", "joining node", "production network key", "per-peer L2 key", and so on. Basing on the recent/future discussions in 6tisch security meetings (like those related to the adoption, or not, of the master-fake key, the creation of device descriptors elements, etc.) we will update the document accordingly. We are looking forward to receive comments on that document. Many thanks for your attention and best regards Gennaro, Alfredo, Giuseppe. ---------- Forwarded message ---------- From: Date: Thu, Dec 11, 2014 at 11:41 AM Subject: New Version Notification for draft-piro-6tisch-security-issues-03.txt To: Giuseppe Piro , Gennaro Boggia < gennaro.boggia@poliba.it>, Luigi Alfredo Grieco A new version of I-D, draft-piro-6tisch-security-issues-03.txt has been successfully submitted by Giuseppe Piro and posted to the IETF repository. Name: draft-piro-6tisch-security-issues Revision: 03 Title: Layer-2 security aspects for the IEEE 802.15.4e MAC Document date: 2014-12-10 Group: Individual Submission Pages: 27 URL: http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues-03.txt Status: https://datatracker.ietf.org/doc/draft-piro-6tisch-security-issues/ Htmlized: http://tools.ietf.org/html/draft-piro-6tisch-security-issues-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-piro-6tisch-security-issues-03 Abstract: The aim of this Internet Draft is to define standard compliant procedures for configuring layer-2 security services in IEEE 802.15.4e-based Low-power and Lossy Networks. In particular, it provides a review of security aspects presented in both IEEE 802.15.4-2011 and IEEE 802.15.4e-2012 specifications, the classification of secure network configurations and layer-2 keys, the description of a set of consecutive steps required to establish a layer-2 secure link, and a lightweight Key Management Protocol designed for negotiating a layer-2 one-hop link key. As the final goal, the document would describe how security MAC attributes can by initialized and updated in order to offer layer-2 security services in real networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- *Giuseppe Piro, PhD* Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: peppe@giuseppepiro.com phone: +39 080 5963301 web: g iuseppepiro.com --047d7ba96d9cb044a60509eea51d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Dear all,
a new version of our draft draft-piro-6tisch-sec= urity-issues has been submitted. We are still focusing the attention on L2 = security aspects (i.e., how generating the key, how storing keys and relate= d attributes within MAC PIB tables, and so on).=C2=A0
However, we have revised = some concepts by using the terminology introduced by Michael in its ID draf= t-richardson-6tisch--security-6top, like "production network", &q= uot;joining node", "production network key", "per-peer = L2 key", and so on.

Basing on the recent/future discussions in 6tisch sec= urity meetings (like those related to the adoption, or not, of the master-f= ake key, the creation of device descriptors elements, etc.) we will update = the document accordingly.=C2=A0

We are looking forward to receive comments on = that document.=C2=A0

Many thanks for your attention and best regards

Gennaro, Alf= redo, Giuseppe.


---------- Forwarded message= ----------
From: &= lt;internet-drafts@ietf.org= >
Date: Thu, Dec 11, 2014 at 11:41 AM
Subject: New Version = Notification for draft-piro-6tisch-security-issues-03.txt
To: Giuseppe P= iro <giuseppe.piro@poliba.it<= /a>>, Gennaro Boggia <gen= naro.boggia@poliba.it>, Luigi Alfredo Grieco <alfredo.grieco@poliba.it>



A new version of I-D, draft-piro-6tisch-security-issues-03.txt
has been successfully submitted by Giuseppe Piro and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-piro-6tisch-security-is= sues
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Layer-2 security aspects for the I= EEE 802.15.4e MAC
Document date:=C2=A0 2014-12-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-piro-6tisch-security-issues-03= .txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-piro-6tisch-security-issues/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.or= g/html/draft-piro-6tisch-security-issues-03
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-piro-6tisch-security-issues-03
Abstract:
=C2=A0 =C2=A0The aim of this Internet Draft is to define standard compliant=
=C2=A0 =C2=A0procedures for configuring layer-2 security services in IEEE =C2=A0 =C2=A0802.15.4e-based Low-power and Lossy Networks. In particular, i= t
=C2=A0 =C2=A0provides a review of security aspects presented in both IEEE =C2=A0 =C2=A0802.15.4-2011 and IEEE 802.15.4e-2012 specifications, the
=C2=A0 =C2=A0classification of secure network configurations and layer-2 ke= ys, the
=C2=A0 =C2=A0description of a set of consecutive steps required to establis= h a
=C2=A0 =C2=A0layer-2 secure link, and a lightweight Key Management Protocol=
=C2=A0 =C2=A0designed=C2=A0 for negotiating a layer-2 one-hop link key. As = the final
=C2=A0 =C2=A0goal, the document would describe how security MAC attributes = can by
=C2=A0 =C2=A0initialized and updated in order to offer layer-2 security ser= vices
=C2=A0 =C2=A0in real networks.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Po= litecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: peppe@giuseppepiro.com=
phone: +39 080 5963301
web: giuseppepiro.com
--047d7ba96d9cb044a60509eea51d-- From nobody Thu Dec 11 04:53:12 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8ED1ACE47 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 04:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpPR2G_Kwg4w for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 04:53:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 26D501ACEB6 for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 04:53:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBBCqvJE025365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Dec 2014 14:52:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBBCqsaS000191; Thu, 11 Dec 2014 14:52:54 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21641.37798.317532.721073@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 14:52:54 +0200 From: Tero Kivinen To: In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/ZwUHAbI8LaaTsezPKCfsD7RYkSo Cc: rstruik.ext@gmail.com, 6tisch-security@ietf.org Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 12:53:09 -0000 yoshihiro.ohba@toshiba.co.jp writes: > I am asking this because, while the =E2=80=9CExempt=E2=80=9D flag of = 802.15.4-2011 > DeviceDescriptor of Security-related PIB attributes allows unsecured = frames to > be passed to higher layer, the flag solely does not help for joining = node=E2=80=99s > higher layer to process authenticated-only secured beacons. Beacons are special cases, and during the scanning process security processing failures for them are ignored and all data from the beacon is stored regardless whether security processing was successfull or not. In P802.15.4-REVc-DF2 the section "6.3.1.2 Active and passive scan" has text which says: =09If a protected Beacon frame is received, i.e., the Security =09Enabled field is set to one, the device shall attempt to =09unsecure the Beacon frame using the unsecuring process =09described in 9.2.3. =09The security-related elements of the PAN descriptor =09corresponding to the beacon, as defined in Table 68, shall be =09set to the corresponding parameters returned by the unsecuring =09process. The SecurityStatus element of the PAN descriptor =09shall be set to SUCCESS if the Status from the unsecuring =09process is SUCCESS and set to one of the other Status codes =09indicating an error in the security processing otherwise. =09The information from the frame to be unsecured shall be =09recorded in the PAN descriptor even if the Status from the =09unsecuring process indicated an error. Same text was also presented in the -2011 version in section 5.1.2.1.2. Only difference is that in -DF2 we changed the "from the unsecured frame" to "from the frame to be unsecured" in the last paragraph, so it will match the terms used in the security section. So beacons during the active or passive scan are processed regradless their security level and information from there are stored to the PAN Descriptor table regardless whether the bacon was secured or not, and whether we actually managed to verify the security of the beacon frame or not. So for beacons you do not need exempt flag, it is needed only for other frame types where you still want to enforce the security on the MAC layer.=20 --=20 kivinen@iki.fi From nobody Thu Dec 11 05:08:17 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD191ACE47 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCZo3xqjdYm3 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:08:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 76E061A86FE for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 05:08:10 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBBD80Vn017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Dec 2014 15:08:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBBD7xji024038; Thu, 11 Dec 2014 15:07:59 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21641.38703.437570.432580@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 15:07:59 +0200 From: Tero Kivinen To: Kris Pister In-Reply-To: <54873561.9030106@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 6 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/J5x4NAkRShKlRFJqhdZIBpaMsfo Cc: Rene Struik , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:08:11 -0000 Kris Pister writes: > So the idea is that misinterpreting a frame from a completely > different type of network is not a problem? I guess that it will > just cause the joining node to try to initiate an authentication > exchange that won't go anywhere. Maybe that's ok, but it leaves us > open to *unintentional* denial of service attacks. I think it is much better to leave joining process open for attacks, than leave the whole production network completely open to all kind of attacks. > I'd feel a little better about it if the proponents of "no fake > keys" would acknowledge the concerns of the "well-known key" gang. > We've said repeatedly that "well known" is not about security, it's > about avoiding unintentional misinterpretation of foreign packets. > We get that a well known key provides zero security. Do you get that > the aether is filled with packets that don't abide by 6lowpan > dispatch bytes, or even IEEE MAC header conventions? The problem with using well known keys with beacons is that then beacons do not have any security at all for anybody. I.e. attacker who is not part of the network can easily fake beacons and mess up the whole network for everybody. If beacons use real network key (not well known, but group key distributed to valid members of the network), then network users can actually verify that beacons are coming from the network members, not from attackers. The joining nodes cannot verify this yet, as they do not have the key, but I think it is much more important to protect the production network, than to try to protect joining nodes for accidents. The TSCH beacons have several IEs already, and if you are really concerned about mixing random radio interference with real beacon, it might be better to just add one more IE that has network magic cookie or something that joining nodes can verify... If you could create completely separate another joining network with their own set of beacons and schedules and most likely radio channels, then joining network having well-known keys would work, but I do not think that is what is done here. -- kivinen@iki.fi From nobody Thu Dec 11 05:18:12 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF611A8969 for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWn97ZFRd1eq for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:18:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 BA0231A88B0 for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 05:18:07 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBBDI5T7022848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Dec 2014 15:18:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBBDI5Yd009279; Thu, 11 Dec 2014 15:18:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21641.39309.532797.197552@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 15:18:05 +0200 From: Tero Kivinen To: Jonathan Simon In-Reply-To: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/WIf8Vb5m10pobG7f2X309pbm0gA Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:18:10 -0000 Jonathan Simon writes: > We all agreed that touchless operation is the goal. So beacons need = to be > authenticated with a well-known key (yes, I know this does nothing fo= r > security - this provides for protocol separation only). Mixing of > unauthenticated and authenticated frames is a non-issue, since everyt= hing is > authenticated. I don=E2=80=99t understand the value of saving a bea= con key > configured at a higher layer, as a) the network has to send the beaco= ns > unencrypted for touchless operation, True. > b) you don=E2=80=99t get any security benefit if a device is going to= accept > the beacon contents regardless, and False. Joining node needs to ccept beacon contents regardless. Nodes already part of the network DO want to verify that the ASN and other parameters inside the beacon are accepted only from valid sources. They can verify that if the beacon content is authenticated (not encrypted) using the key which is not well-known. > c) a device has to be able to fall back to the well-known key any > time, since the saved key may be stale (node moved, node slept while > key was changing, node is allowed in multiple overlapping networks > using different keys, etc.) In which case it is again joining node, and start joining process from the beginning. Note, that even then node needs to remember last ASN it has uesd for each key it has, and it needs to make sure ASN never goes backwards even if he rejoins the networks. Most likely it will want to remove all old keys before evn starting to rejoin. Also the joining protocol needs to be so that it make sure it cannot be replayed in such way that even if attacker do not know the contents of the frames, the exchange cannot result in same keys to be group keys to be transmitted to the joining peer. For example protocol that would send group keys to the peer by encrypting them with the public key of the peer would be unsafe, as then attacker could trick the node to rejoin attackers network and replay the joining frames from the real network to the node, and then node would have the real group key (after decrypting the key object sent to it). Attacker could do all this even when it does not know the contents of the objetcs. The attacker could have also stored the old beacons from the real coordinators and replay them to the node, so node would think he is part of the real network, and would start trasnmitting using the old ASN. Immediately when it does this the attacker now have two packets encrypted with same key (which attacker does not know) and with same ASN + source address =3D=3D same CCM nonce, and then it would be able t= o get information out from the packets.=20 --=20 kivinen@iki.fi From nobody Thu Dec 11 05:22:57 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F391A896B for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_M6MZDgQ0Ci for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 05:22:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 9C93F1A88B0 for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 05:22:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBBDMoxh002587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Dec 2014 15:22:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBBDMo95023930; Thu, 11 Dec 2014 15:22:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21641.39594.272076.699817@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 15:22:50 +0200 From: Tero Kivinen To: Rene Struik In-Reply-To: <54878641.1010603@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0E91D@TGXML210.toshiba.local> <54865507.6080609@gmail.com> <54865CAE.6030308@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D0EB52@TGXML210.toshiba.local> <54878389.7020905@gmail.com> <099BF16F-1ACD-465C-A720-EBD2031F387B@kinneyconsultingllc.com> <54878641.1010603@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 3 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/Iy0ntWo5KqOU_q2_Tp2s2MOLRb0 Cc: yoshihiro.ohba@toshiba.co.jp, tisch-security <6tisch-security@ietf.org>, Pat Kinney Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:22:55 -0000 Rene Struik writes: > The current language is not entirely clear; hence, my note. This will be fixed during the maintenance work. We had several comments about this during the balloting and 15-14-0704-02 already propses fix for that (see page 5, CID 1026, 1145, 1146, 1148, 1147 for more information). Also the outbound statemachine step f and inbound statemachine step i have been modified to match (those state machines are also in the same document). https://mentor.ieee.org/802.15/dcn/14/15-14-0704-02-0mag-lb97-resolutions-kivinen.pdf -- kivinen@iki.fi From nobody Thu Dec 11 08:03:39 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4151A6FBC for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN2sXWMjhrpB for <6tisch-security@ietfa.amsl.com>; Thu, 11 Dec 2014 08:03:35 -0800 (PST) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEE41A1AAD for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 08:03:34 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c11o144.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 350c9845.0.24009.00-260.68004.p01c11o144.mxlogic.net (envelope-from ); Thu, 11 Dec 2014 09:03:34 -0700 (MST) X-MXL-Hash: 5489c056381b57b3-79c03f68975796d46c0377e0fc1ecbb5c4e76301 Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 2154774096 for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 08:03:30 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so5024309iec.2 for <6tisch-security@ietf.org>; Thu, 11 Dec 2014 08:03:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.7.3 with SMTP id om3mr11874812icb.97.1418313811133; Thu, 11 Dec 2014 08:03:31 -0800 (PST) Received: by 10.107.46.95 with HTTP; Thu, 11 Dec 2014 08:03:31 -0800 (PST) In-Reply-To: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2014 08:03:31 -0800 Message-ID: From: Jonathan Simon To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=bcaec5161a77e48a0a0509f2eaa1 X-AnalysisOut: [v=2.1 cv=D+pTK5hj c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=pGLkceISAAAA:8 a=YlVTAMxIAAAA:8 a=1XWaLZrsAA] X-AnalysisOut: [AA:8 a=A92cGCtB03wA:10 a=P5YnWnONoaYiY7TfdaQA:9 a=-oiBcQQX] X-AnalysisOut: [VV3uLyZk:21 a=jEbukNDUVd2tEwWS:21 a=QEXdDO2ut3YA:10 a=19wC] X-AnalysisOut: [D08tTksA:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_d] X-AnalysisOut: [s0YA:10 a=Frmm7fnqYgNdIFbATKYA:9 a=Ly1Z0zO1B4AJEcy3:21 a=q] X-AnalysisOut: [SXyT-a-oi09QSMO:21 a=On3FznqRc5Aat5j4:21] X-Spam: [F=0.5500000000; CM=0.500; MH=0.550(2014121107); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/LN9EyEgShXp0iDyg3fAxkTdfw1s Subject: [6tisch-security] Fwd: (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jsimon@linear.com List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:03:38 -0000 --bcaec5161a77e48a0a0509f2eaa1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tero - I think my point got missed. I'm not trying to say that if you could use an instance-specific key to secure beacons that it would have no value. Clearly that is preferable. But I think it costs us touchless behavior, at least in some cases. Imagine a sleepy node. It first joins with the well-known key. It gets assigned a new Beacon key #1 as you describe. It goes to sleep, and meanwhile, the Beacon key is changed to key #2. The node wakes up and hears the Beacon. It tries key #1 and fails, and tries the WKK and fails. The proposal has been that the node should accept the Beacon contents, but now we don't even know if it is a Beacon, or some other protocol that looks like a Beacon. A touchless node in general doesn't know how it will be deployed, so once you start changing Beacon keys, you may wind up worse off than if you use always a well known key. If your key rotation schedule cycled through a list of keys, you could restrict the node to the configured key for a period of time before falling back, but then we wind up a) describing policy that is best left to the vendor, and b) ensuring that the node may remain unavailable until the network returned to the configured key. I see a lot of complexity, and little upside. Jonathan On Thu, Dec 11, 2014 at 5:18 AM, Tero Kivinen wrote: > Jonathan Simon writes: > > We all agreed that touchless operation is the goal. So beacons need to > be > > authenticated with a well-known key (yes, I know this does nothing for > > security - this provides for protocol separation only). Mixing of > > unauthenticated and authenticated frames is a non-issue, since > everything is > > authenticated. I don=E2=80=99t understand the value of saving a beaco= n key > > configured at a higher layer, as a) the network has to send the beacons > > unencrypted for touchless operation, > > True. > > > b) you don=E2=80=99t get any security benefit if a device is going to a= ccept > > the beacon contents regardless, and > > False. Joining node needs to ccept beacon contents regardless. Nodes > already part of the network DO want to verify that the ASN and other > parameters inside the beacon are accepted only from valid sources. > They can verify that if the beacon content is authenticated (not > encrypted) using the key which is not well-known. > > > c) a device has to be able to fall back to the well-known key any > > time, since the saved key may be stale (node moved, node slept while > > key was changing, node is allowed in multiple overlapping networks > > using different keys, etc.) > > In which case it is again joining node, and start joining process from > the beginning. Note, that even then node needs to remember last ASN it > has uesd for each key it has, and it needs to make sure ASN never goes > backwards even if he rejoins the networks. Most likely it will want to > remove all old keys before evn starting to rejoin. Also the joining > protocol needs to be so that it make sure it cannot be replayed in > such way that even if attacker do not know the contents of the frames, > the exchange cannot result in same keys to be group keys to be > transmitted to the joining peer. > > For example protocol that would send group keys to the peer by > encrypting them with the public key of the peer would be unsafe, as > then attacker could trick the node to rejoin attackers network and > replay the joining frames from the real network to the node, and then > node would have the real group key (after decrypting the key object > sent to it). Attacker could do all this even when it does not know the > contents of the objetcs. > > The attacker could have also stored the old beacons from the real > coordinators and replay them to the node, so node would think he is > part of the real network, and would start trasnmitting using the old > ASN. Immediately when it does this the attacker now have two packets > encrypted with same key (which attacker does not know) and with same > ASN + source address =3D=3D same CCM nonce, and then it would be able to > get information out from the packets. > > -- > kivinen@iki.fi > --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION** *****Internet Email Confidentiality Notice***** This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION** *****Internet Email Confidentiality Notice***** This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. --bcaec5161a77e48a0a0509f2eaa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tero - I think my point got missed.=C2=A0 I'm not tryi= ng to say that if you could use an instance-specific key to secure beacons = that it would have no value. Clearly that is preferable. But I think it cos= ts us touchless behavior, at least in some cases.

Imagine a sleepy node. It first joins= with the well-known key.=C2=A0 It gets assigned a new Beacon key #1 as you= describe. It goes to sleep, and meanwhile, the Beacon key is changed to ke= y #2.=C2=A0 The node wakes up and hears the Beacon.=C2=A0 It tries key #1 a= nd fails, and tries the WKK and fails.=C2=A0 The proposal has been that the= node should accept the Beacon contents, but now we don't even know if = it is a Beacon, or some other protocol that looks like a Beacon.
<= br>
A touchless node in general doesn't know how it will be d= eployed, so once you start changing Beacon keys, you may wind up worse off = than if you use always a well known key. If your key rotation schedule cycl= ed through a list of keys, you could restrict the node to the configured ke= y for a period of time before falling back, but then we wind up a) describi= ng policy that is best left to the vendor, and b) ensuring that the node ma= y remain unavailable until the network returned to the configured key.=C2= =A0 I see a lot of complexity, and little upside.

Jonath= an

On Thu, Dec 11, 2014 at 5:18 AM, Tero Kivinen <kivinen@iki.fi>= wrote:
Jonathan Simon writes:
> We all agreed that touchless operation is the goal.=C2=A0 So beacons n= eed to be
> authenticated with a well-known key (yes, I know this does nothing for=
> security - this provides for protocol separation only).=C2=A0 Mixing o= f
> unauthenticated and authenticated frames is a non-issue, since everyth= ing is
> authenticated.=C2=A0 =C2=A0I don=E2=80=99t understand the value of sav= ing a beacon key
> configured at a higher layer, as a) the network has to send the beacon= s
> unencrypted for touchless operation,

True.

> b) you don=E2=80=99t get any security benefit if a device is going to = accept
> the beacon contents regardless, and

False. Joining node needs to ccept beacon contents regardless. Nodes
already part of the network DO want to verify that the ASN and other
parameters inside the beacon are accepted only from valid sources.
They can verify that if the beacon content is authenticated (not
encrypted) using the key which is not well-known.

> c) a device has to be able to fall back to the well-known key any
> time, since the saved key may be stale (node moved, node slept while > key was changing, node is allowed in multiple overlapping networks
> using different keys, etc.)

In which case it is again joining node, and start joining process from
the beginning. Note, that even then node needs to remember last ASN it
has uesd for each key it has, and it needs to make sure ASN never goes
backwards even if he rejoins the networks. Most likely it will want to
remove all old keys before evn starting to rejoin. Also the joining
protocol needs to be so that it make sure it cannot be replayed in
such way that even if attacker do not know the contents of the frames,
the exchange cannot result in same keys to be group keys to be
transmitted to the joining peer.

For example protocol that would send group keys to the peer by
encrypting them with the public key of the peer would be unsafe, as
then attacker could trick the node to rejoin attackers network and
replay the joining frames from the real network to the node, and then
node would have the real group key (after decrypting the key object
sent to it). Attacker could do all this even when it does not know the
contents of the objetcs.

The attacker could have also stored the old beacons from the real
coordinators and replay them to the node, so node would think he is
part of the real network, and would start trasnmitting using the old
ASN. Immediately when it does this the attacker now have two packets
encrypted with same key (which attacker does not know) and with same
ASN + source address =3D=3D same CCM nonce, and then it would be able to get information out from the packets.

--
kivinen@iki.fi



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

**LINEAR TECHNOLOGY=C2=A0CORPORATION**=C2=A0<= br> *****Internet Email Confidentiality=C2=A0Notice*****=C2=A0
=C2=A0This e-mail transmission, and any=C2=A0documents, files or previous= =20 e-mail=C2=A0messages attached to it may contain=C2=A0confidential informati= on that is=C2=A0legally privileged. If you are not the=C2=A0intended recipient, or= a=20 person=C2=A0responsible for delivering it to the=C2=A0intended recipient, you are hereby=C2=A0notified that any disclosure,=20 copying,=C2=A0distribution or use of any of the=C2=A0information contained = in or=20 attached=C2=A0to this transmission is STRICTLY=C2=A0PROHIBITED. If you have= =20 received this=C2=A0transmission in error, please=C2=A0immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original=C2=A0transmission and its atta= chments=C2=A0without reading or saving in any=C2=A0manner. Thank you.



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

**LINEAR TECHNOLOGY=C2=A0CORPORATION**=C2=A0<= br> *****Internet Email Confidentiality=C2=A0Notice*****=C2=A0
=C2=A0This e-mail transmission, and any=C2=A0documents, files or previous= =20 e-mail=C2=A0messages attached to it may contain=C2=A0confidential informati= on that is=C2=A0legally privileged. If you are not the=C2=A0intended recipient, or= a=20 person=C2=A0responsible for delivering it to the=C2=A0intended recipient, you are hereby=C2=A0notified that any disclosure,=20 copying,=C2=A0distribution or use of any of the=C2=A0information contained = in or=20 attached=C2=A0to this transmission is STRICTLY=C2=A0PROHIBITED. If you have= =20 received this=C2=A0transmission in error, please=C2=A0immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original=C2=A0transmission and its atta= chments=C2=A0without reading or saving in any=C2=A0manner. Thank you.
--bcaec5161a77e48a0a0509f2eaa1-- From nobody Fri Dec 12 02:37:18 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417A91ACCE2 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 02:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YgOTfqLcMFm0 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 02:37:14 -0800 (PST) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8821ACC92 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 02:37:13 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so6920742pde.15 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 02:37:13 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=5cRpU3x8heYQNy3rqTXH9WXpjCuQXNnhzS9O8VRmHTg=; b=XH5Wn2I3ktGOvBEjhXSWb/AuMCOx1cQHm1OrxhIQPjvjG2CC3wY1B5qTU7huiCn/DS 3PIeHlYUr2w9/4RnR9266J845OBIClKlNh0K/FWQH0vI16fZgXlxFVASDOWZ6RP1dWAf cj7pbd+2fbCcRRJiyd7ph4LW3VyZLeMQftsSyqay0WCrSiqKrKPL3Q44TvMjW0QSkigm EG9E0wxAkHqN/R7QeEcHEcVbCF9rnep8+vEG05HPfxIV5j3G7kakknuFDbn2C0lj1kJ2 +qgsZlXQmEhfIaEy8yH4qV5iZdD19jZU0EDsRaRXzg9mRHzQzSYJY3pkKLgAH+idioV6 oQ9g== X-Gm-Message-State: ALoCoQlJAzeqpbCTfDJyZmkdsta/poYhjx5FYNiSH37Zp+XLPIZ6Jf03NX+pgALx8L1lg508tPSs X-Received: by 10.66.66.135 with SMTP id f7mr24893927pat.81.1418380632162; Fri, 12 Dec 2014 02:37:12 -0800 (PST) Received: from [10.0.0.3] ([98.210.76.194]) by mx.google.com with ESMTPSA id qc8sm1173101pdb.70.2014.12.12.02.37.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 02:37:11 -0800 (PST) Message-ID: <548AC511.6090402@berkeley.edu> Date: Fri, 12 Dec 2014 02:36:01 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.38703.437570.432580@fireball.kivinen.iki.fi> In-Reply-To: <21641.38703.437570.432580@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/cp5mqLewwF0_U8Ix6WycE225MjU Cc: Rene Struik , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:37:16 -0000 > I think it is much better to leave joining process open for attacks, > than leave the whole production network completely open to all kind of > attacks. Tero - you and I are clearly talking about different things. If using a well-known key for the MIC on a beacon opened the production network to any attacks, then there is no way that WiHART would have passed repeated security reviews over a period of many years. > The problem with using well known keys with beacons is that then > beacons do not have any security at all for anybody. I'm pretty sure that everyone on this list agrees that a well-known key provides no security. Many would disagree that it is a problem. > attacker [...] can easily fake beacons and mess up the whole network for everybody An attacker can easily fake beacons: yes. and mess up the whole network: no. Can you explain why you think that it will mess up the whole network for everybody? ksjp On 12/11/2014 5:07 AM, Tero Kivinen wrote: > Kris Pister writes: >> So the idea is that misinterpreting a frame from a completely >> different type of network is not a problem? I guess that it will >> just cause the joining node to try to initiate an authentication >> exchange that won't go anywhere. Maybe that's ok, but it leaves us >> open to *unintentional* denial of service attacks. > I think it is much better to leave joining process open for attacks, > than leave the whole production network completely open to all kind of > attacks. > >> I'd feel a little better about it if the proponents of "no fake >> keys" would acknowledge the concerns of the "well-known key" gang. >> We've said repeatedly that "well known" is not about security, it's >> about avoiding unintentional misinterpretation of foreign packets. >> We get that a well known key provides zero security. Do you get that >> the aether is filled with packets that don't abide by 6lowpan >> dispatch bytes, or even IEEE MAC header conventions? > The problem with using well known keys with beacons is that then > beacons do not have any security at all for anybody. I.e. attacker who > is not part of the network can easily fake beacons and mess up the > whole network for everybody. If beacons use real network key (not well > known, but group key distributed to valid members of the network), > then network users can actually verify that beacons are coming from > the network members, not from attackers. The joining nodes cannot > verify this yet, as they do not have the key, but I think it is much > more important to protect the production network, than to try to > protect joining nodes for accidents. > > The TSCH beacons have several IEs already, and if you are really > concerned about mixing random radio interference with real beacon, it > might be better to just add one more IE that has network magic cookie > or something that joining nodes can verify... > > If you could create completely separate another joining network with > their own set of beacons and schedules and most likely radio channels, > then joining network having well-known keys would work, but I do not > think that is what is done here. From nobody Fri Dec 12 02:51:50 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170BA1ACCF4 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 02:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YZt1gYXEtWKg for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 02:51:47 -0800 (PST) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638111ACCF3 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 02:51:47 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id g10so4994730pdj.20 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 02:51:47 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=OW1cd1rkm4yfTUrUuqMeA0CeFCKEbxI/AjTTvRAtPmU=; b=ea4EBSLYMpZ37iuWRmsA/TARJZvFiWD8jgLLB2zEgxSlUu3+7NYdPCLPeCwkLl5Kw6 CXsQyty3v/iN0//xVore9csAdZSiwdkSpo6GF4nhMeGZo6DFTjxoKS/rbTeLi8Uu/1FH OEVD+fhfjSBZcPu0PsLsJCdw4x1JUpR6NI561R18xhoypHR+tf2yZx542tSoLc8BNPdX LfpQdd8GHQryobY7pxMYL1ZiCpwoE6amSICNnvbBfplib8f5PTTN9i/vN/pzdbDS0xQH Bd9fG0kPEct44D6/JAEsiyBMoTEKnJiPg9pNr9xRHUWfmS5kbnIjBw0v++dR3WChhQKV uRxw== X-Gm-Message-State: ALoCoQlGDb4m6HEfHq5SHyyyxY+G0gAbQKcv7+R4DOAbFgS1URxuCbIjIPhjbSczgihNt+iNS9VZ X-Received: by 10.70.43.68 with SMTP id u4mr26193460pdl.6.1418381506975; Fri, 12 Dec 2014 02:51:46 -0800 (PST) Received: from [10.0.0.3] ([98.210.76.194]) by mx.google.com with ESMTPSA id op10sm1198115pbc.90.2014.12.12.02.51.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 02:51:45 -0800 (PST) Message-ID: <548AC87B.7010306@berkeley.edu> Date: Fri, 12 Dec 2014 02:50:35 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen , Jonathan Simon References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> In-Reply-To: <21641.39309.532797.197552@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/cpBH_GZKxlsp_t78qbXeu-33alc Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:51:49 -0000 Tero - again I feel like we have a different understanding of what is going on. Nodes in the network will keep track of ASN. They will not in general be listening to beacons, because beacons are not, and can not be, protected with symmetric means. ksjp On 12/11/2014 5:18 AM, Tero Kivinen wrote: > Jonathan Simon writes: >> We all agreed that touchless operation is the goal. So beacons need to be >> authenticated with a well-known key (yes, I know this does nothing for >> security - this provides for protocol separation only). Mixing of >> unauthenticated and authenticated frames is a non-issue, since everything is >> authenticated. I don’t understand the value of saving a beacon key >> configured at a higher layer, as a) the network has to send the beacons >> unencrypted for touchless operation, > True. > >> b) you don’t get any security benefit if a device is going to accept >> the beacon contents regardless, and > False. Joining node needs to ccept beacon contents regardless. Nodes > already part of the network DO want to verify that the ASN and other > parameters inside the beacon are accepted only from valid sources. > They can verify that if the beacon content is authenticated (not > encrypted) using the key which is not well-known. > >> c) a device has to be able to fall back to the well-known key any >> time, since the saved key may be stale (node moved, node slept while >> key was changing, node is allowed in multiple overlapping networks >> using different keys, etc.) > In which case it is again joining node, and start joining process from > the beginning. Note, that even then node needs to remember last ASN it > has uesd for each key it has, and it needs to make sure ASN never goes > backwards even if he rejoins the networks. Most likely it will want to > remove all old keys before evn starting to rejoin. Also the joining > protocol needs to be so that it make sure it cannot be replayed in > such way that even if attacker do not know the contents of the frames, > the exchange cannot result in same keys to be group keys to be > transmitted to the joining peer. > > For example protocol that would send group keys to the peer by > encrypting them with the public key of the peer would be unsafe, as > then attacker could trick the node to rejoin attackers network and > replay the joining frames from the real network to the node, and then > node would have the real group key (after decrypting the key object > sent to it). Attacker could do all this even when it does not know the > contents of the objetcs. > > The attacker could have also stored the old beacons from the real > coordinators and replay them to the node, so node would think he is > part of the real network, and would start trasnmitting using the old > ASN. Immediately when it does this the attacker now have two packets > encrypted with same key (which attacker does not know) and with same > ASN + source address == same CCM nonce, and then it would be able to > get information out from the packets. > From nobody Fri Dec 12 04:58:03 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816441A82E2 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 04:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYFv1ijsv-YB for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 04:57:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 D2B3A1A1B3D for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 04:57:57 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBCCviJ4005978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Dec 2014 14:57:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBCCvisB019013; Fri, 12 Dec 2014 14:57:44 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21642.58952.350447.597806@fireball.kivinen.iki.fi> Date: Fri, 12 Dec 2014 14:57:44 +0200 From: Tero Kivinen To: Kris Pister In-Reply-To: <548AC511.6090402@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.38703.437570.432580@fireball.kivinen.iki.fi> <548AC511.6090402@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 40 min X-Total-Time: 19 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/tz9KxARa6DpiquQl7EZadT-WcPA Cc: Rene Struik , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 12:58:01 -0000 Kris Pister writes: > > I think it is much better to leave joining process open for attacks, > > than leave the whole production network completely open to all kind of > > attacks. > > Tero - you and I are clearly talking about different things. If using a > well-known key > for the MIC on a beacon opened the production network to any attacks, > then there is no way that WiHART would have passed repeated security reviews > over a period of many years. I have no idea how WiHART is doing things, but on the other hand most of the security reviews are not really that through. Using well-known key for beacons allows attackers to fake beacons, which will allow them to modify the ASN. AES-CCM security needs ASN to be global for the network, and if it can be faked to be different in different parts of the network there is problems. Also there used to be text in the 15.4e which used short addresses instead of extended addresses for the nonce generation (we did get rid of that in the maintenance), and if that is used that allows another set of security vulnerabilitys. Someone claimed me that, the requirement for short addresses to be used in nonce generation came from somewhere outside, and I have assumed WiHART might have been one of those sources, but as I have no idea what WiHART does and how it works (I have never seen any of its specifications), I do not know if they use it or not. So I have no idea whether WiHART is secure or not, and having it passing security reviews does not mean anything. It means those reviews didn't find any obvious holes, it does not mean there isn't any security holes there. Seeing how many other protocols have gone through repeated security reviews, and still have all kind of problems found later, does just point out how little you can trust to security reviews. There are ways to try to limit the damage caused by someone able to fake beacons. For example each device can always remember the last ASN they have seen / used and store that to stable storage every time they go to sleep. That will make it sure the device will not get tricked to smaller ASN than before. Another kind of attack for network is to advance the ASN forward a lot. I.e. if you have attacker in the network sending out beacons having much bigger ASN than the real ASN is, that will cause all nodes trusting that beacon to jump forward. Now even when the attacker goes away the network will NOT recover from that. Those nodes things the ASN is high and will send packets out which others cannot decrypt because ASN is wrong. Those nodes having wrong ASN cannot decrypt / verify frames sent by the real noeds, as they have wrong ASN. Even when those frames realize they have been tricked to use wrong ASN, they cannot go back down to real ASN, as that would mean that they would violate the nonce uniqueness later when the real ASN reaches the value of the wrong ASN, and then if they would send packets out with same ASN twice, that would break the security. Again there is ways for devices to be security against that, i.e. they can keep their own count of ASN, and make sure it will never jump forward or backwards at all, i.e. if they have accurate enough clock they can calculate what value ASN should be for any given moment even if they have been sleeping, thus they will make sure they will not trust beacons with wrong ASN. This again sets up another requirement for devices which is not needed if ASN from the beacon can be trusted because it is authenticated. > > The problem with using well known keys with beacons is that then > > beacons do not have any security at all for anybody. > > I'm pretty sure that everyone on this list agrees that a well-known > key provides no security. Many would disagree that it is a problem. Good. I also claim that if the beacons in the network is protected with well-known key it will lower the security a lot. This is because that will mean that the beacons are not protected. When beacons are not proteced this will cause problems. > > attacker [...] can easily fake beacons and mess up the whole network > for everybody > > An attacker can easily fake beacons: yes. > and mess up the whole network: no. > > Can you explain why you think that it will mess up the whole network for > everybody? I gave just few examples with ASN above. With ASN it is possible to break the security of the network. Another thing attackers can do they can give out different schedule for the TSCH causing nodes to talk over each other, or be out of sync, thus they cannot hear each other as they are not receiving / transmitting right time on right channel. This allows all kind of denial of service attacks. Can you explain how do you plan to protect against faking ASNs if the beacons are protected with key that attacker knows (i.e. well-known key)? If it requires devices to keep accurate enough clocks and verify that ASN has right value, then that requirement needs to be mentioned somewhere. -- kivinen@iki.fi From nobody Fri Dec 12 05:05:31 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FABA1A887B for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 05:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJV00m3EYfZn for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 05:05:19 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBDC1A8706 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 05:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6964; q=dns/txt; s=iport; t=1418389518; x=1419599118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O/4I3yqbSJ+mB0jf0hftB28Xbto0E0BzyHNVH+l2eQA=; b=HxS7FKTJjIw6tgjkf4Rjkzhb5HWym0BXShQO1nvLudK1o/q5NhIE5JhG 7onQXesim/8MgAgobVrUP0YE6P279JJ8D4+GMnmAwF9dLsKzngsrfWwIU QzP8E71uSqCShr5BFSWteRwS2mo0AKAQiheC29laZLfTIwyXtltQggLog c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAFHnilStJA2B/2dsb2JhbABZgwZSWASDAsBXghsKhSRKAhx5FgEBAQEBfYQMAQEBBAEBASAROgsMBAIBCBEEAQEDAgYZBAMCAgIlCxQBCAgCBAENBQiIJA3BQpZMAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYsjAYJ8MQcGgmIugRMFjX+JeohAhDSDOCKCMIE8boEFHyF+AQEB X-IronPort-AV: E=Sophos;i="5.07,563,1413244800"; d="scan'208";a="105153424" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 12 Dec 2014 13:05:15 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBCD5EhM019773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 13:05:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.39]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 07:05:13 -0600 From: "Pascal Thubert (pthubert)" To: Tero Kivinen , Jonathan Simon Thread-Topic: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan Thread-Index: AQHQFUTl0TeAimkCfUGoaRpnApOoa5yL6K8A Date: Fri, 12 Dec 2014 13:05:13 +0000 Deferred-Delivery: Fri, 12 Dec 2014 13:05:00 +0000 Message-ID: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> In-Reply-To: <21641.39309.532797.197552@fireball.kivinen.iki.fi> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.161.221] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/UhKnSIqsC_Ie2T4IFnZUS1WkNFE Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:05:26 -0000 SGVsbG8gVGVybzoNCg0KVGhlIG9uZSB0aGluZyBJIGRpc2FncmVlIHVwb24gaXMgeW91ciBhc3N1 bXB0aW9uIHRoZSBhY3R1YWwgcHJvZHVjdGlvbiBpbmZvcm1hdGlvbiBpcyBwcmVzZW50IGluIHRo ZSBqb2luIGJlYWNvbi4gWW91ciBkZXJpdmUgeW91ciBtb2RlbCBmcm9tIHRoYXQgYXNzdW1wdGlv biBhbmQgdGhhdCBpcyBjZXJ0YWlubHkgYSBzb3VyY2Ugb2YgZGlzYWdyZWVtZW50Lg0KDQpUaGUg a2V5IGlzIHRoYXQgVFNDSCBhbGxvd3MgdXMgdG8gaGF2ZSBhIGNodW5rIG9mIGNlbGxzIGZvciBq b2luIHRoYXQgaXMgZGlzdGluY3QgZnJvbSB0aGUgY2h1bmtzIG9mIGNlbGxzIHVzZWQgaW4gcHJv ZHVjdGlvbiwgZS5nLiBmb3IgbXVsdGljYXN0IG9yIG1pbmltYWwgUlBMLiBJZiB3ZSBsZWFrIHBy b2R1Y3Rpb24gaW5mb3JtYXRpb24gdGhlbiBhbiBhdHRhY2tlciBjYW4gbXVjaCBlYXNpZXIgcGVy Zm9ybSB2ZXJ5IGRpc2NyZXRlIFBIWSBhdHRhY2tzLCBhbmQvb3IgRG9TIHByb2R1Y3Rpb24gdGlt ZSBzbG90cy4NCg0KVGhlIHdheSBJIHNlZSBpdCwgc2luY2UgdGhlIGpvaW4gaW5mb3JtYXRpb24g aXMgKGFzIGdvb2QgYXMpICBpbiB0aGUgY2xlYXIsIGl0IHNob3VsZCBsZWFrIGFzIGxpdHRsZSBp bmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBhYm91dCB0aGUgcmVhbCBuZXR3b3JrIG9wZXJhdGlvbi4g Tm8gZ2xvYmFsIHByZWZpeCwgbm8gYWN0dWFsIGRhdGEgc2NoZWR1bGUuIEl0IHNob3VsZCBqdXN0 IGdpdmUgdGhlIG1pbmltYWwgc2NoZWR1bGUgaW5mb3JtYXRpb24gdG8gYWxsb3cgdGhlIEpOIHRv IHRhbGsgdG8gdGhlIEpBIGFuZCB0aHJvdWdoIHRoYXQgZ2V0IHRoZSBrZXlzIGlmIGl0IGNhbiwg YW5kIHRoYXQgY291bGQgYmUgYmFuZHdpZHRoIHRoYXQgdmFyaWVzIG92ZXIgdGltZSwgYSBsb3Qg YXQgdGhlIG5ldHdvcmsgYnJpbmcgdXAgYW5kIGEgbG90IGxlc3MgaW4gcnVuIHRpbWUuIA0KDQpB ZnRlciB0aGUga2V5cyBhcmUgb2J0YWluZWQsIHdoZXRoZXIgdGhlIG5vZGUgam9pbnMgZm9yIHRo ZSBmaXJzdCB0aW1lIG9yIHJlam9pbnMgbGF0ZXIsIGl0IGNhbiB1c2UgdGhhdCBjcnlwdG8gbWF0 ZXJpYWwgdG8gb2J0YWluIG9yIHJldmFsaWRhdGUgdGhlIHJlYWwgcHJvZHVjdGlvbiBpbmZvcm1h dGlvbiwgYm90aCBhdCBNQUMgbGF5ZXIgYW5kIElQIGxheWVyLiBUeXBpY2FsbHksIHRoZSBub2Rl IHRoYXQgb2J0YWluZWQga2V5IG1hdGVyaWFsIHdpbGwgc2VuZCBhIHByb3RlY3RlZCBtdWx0aWNh c3QgUlMgb3ZlciB0aGUgam9pbiBzY2hlZHVsZSwgYW5kIGEgcm91dGVyIHdpbGwgYW5zd2VyIHdp dGggYSB1bmljYXN0IFJBLiBUaGlzIGlzIHRoZSBhcHByb3ByaWF0ZSB0aW1lIHRvIHByb3ZpZGUg cHJvZHVjdGlvbiBzY2hlZHVsZSBpbmZvcm1hdGlvbiwgYXMgd2VsbCBhcyB0aGUgcmVhbCBwcm9k dWN0aW9uIHByZWZpeCwgYWxsIGVuY3J5cHRlZC4gRnJvbSB0aGVyZSwgdGhlIG5vZGUgY2FuIHVz ZSA2TG9XUEFOIE5EIGFuZCBSUEwgdG8gcGFydGljaXBhdGUgdG8gdGhlIHByb2R1Y3Rpb24gbmV0 d29yay4NCg0KSW4gdGhhdCBzY2VuYXJpbywgeW91ciBjb250cmFkaWN0aW9uIHRvIHBvaW50IEIg ZG9lcyBub3QgYXBwbHkuDQoNCk1ha2VzIHNlbnNlPw0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiA2dGlzY2gtc2VjdXJpdHkgW21haWx0bzo2dGlzY2gt c2VjdXJpdHktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFRlcm8gS2l2aW5lbg0K PiBTZW50OiBqZXVkaSAxMSBkw6ljZW1icmUgMjAxNCAwNzoxOA0KPiBUbzogSm9uYXRoYW4gU2lt b24NCj4gQ2M6IHRpc2NoLXNlY3VyaXR5DQo+IFN1YmplY3Q6IFJlOiBbNnRpc2NoLXNlY3VyaXR5 XSAody8gc2xpZ2h0IGNvcnJlY3Rpb24pIEZ3ZDogKG1pbnV0ZXMgb2YgVHVlIERlYyAyLA0KPiAy MDE0LCA5YW0gRVNUIGNhbGwpIFJlOiAobm93IHdpdGggYWdlbmRhKSBSZTogaW52aXRlIGZvciA2 dGlzY2ggc2VjdXJpdHkgY2FsbCBUdWUNCj4gRGVjZW1iZXIgMiwgMjAxNCwgOWFtIEVTVCA9IDZh bSBQU1QgPSAzcG0gUGFyaXMgPSAxMXBtIEphcGFuDQo+IA0KPiBKb25hdGhhbiBTaW1vbiB3cml0 ZXM6DQo+ID4gV2UgYWxsIGFncmVlZCB0aGF0IHRvdWNobGVzcyBvcGVyYXRpb24gaXMgdGhlIGdv YWwuICBTbyBiZWFjb25zIG5lZWQNCj4gPiB0byBiZSBhdXRoZW50aWNhdGVkIHdpdGggYSB3ZWxs LWtub3duIGtleSAoeWVzLCBJIGtub3cgdGhpcyBkb2VzDQo+ID4gbm90aGluZyBmb3Igc2VjdXJp dHkgLSB0aGlzIHByb3ZpZGVzIGZvciBwcm90b2NvbCBzZXBhcmF0aW9uIG9ubHkpLg0KPiA+IE1p eGluZyBvZiB1bmF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgZnJhbWVzIGlzIGEgbm9u LWlzc3VlLCBzaW5jZQ0KPiBldmVyeXRoaW5nIGlzDQo+ID4gYXV0aGVudGljYXRlZC4gICBJIGRv buKAmXQgdW5kZXJzdGFuZCB0aGUgdmFsdWUgb2Ygc2F2aW5nIGEgYmVhY29uIGtleQ0KPiA+IGNv bmZpZ3VyZWQgYXQgYSBoaWdoZXIgbGF5ZXIsIGFzIGEpIHRoZSBuZXR3b3JrIGhhcyB0byBzZW5k IHRoZQ0KPiA+IGJlYWNvbnMgdW5lbmNyeXB0ZWQgZm9yIHRvdWNobGVzcyBvcGVyYXRpb24sDQo+ IA0KPiBUcnVlLg0KPiANCj4gPiBiKSB5b3UgZG9u4oCZdCBnZXQgYW55IHNlY3VyaXR5IGJlbmVm aXQgaWYgYSBkZXZpY2UgaXMgZ29pbmcgdG8gYWNjZXB0DQo+ID4gdGhlIGJlYWNvbiBjb250ZW50 cyByZWdhcmRsZXNzLCBhbmQNCj4gDQo+IEZhbHNlLiBKb2luaW5nIG5vZGUgbmVlZHMgdG8gY2Nl cHQgYmVhY29uIGNvbnRlbnRzIHJlZ2FyZGxlc3MuIE5vZGVzIGFscmVhZHkNCj4gcGFydCBvZiB0 aGUgbmV0d29yayBETyB3YW50IHRvIHZlcmlmeSB0aGF0IHRoZSBBU04gYW5kIG90aGVyIHBhcmFt ZXRlcnMgaW5zaWRlDQo+IHRoZSBiZWFjb24gYXJlIGFjY2VwdGVkIG9ubHkgZnJvbSB2YWxpZCBz b3VyY2VzLg0KPiBUaGV5IGNhbiB2ZXJpZnkgdGhhdCBpZiB0aGUgYmVhY29uIGNvbnRlbnQgaXMg YXV0aGVudGljYXRlZCAobm90DQo+IGVuY3J5cHRlZCkgdXNpbmcgdGhlIGtleSB3aGljaCBpcyBu b3Qgd2VsbC1rbm93bi4NCj4gDQo+ID4gYykgYSBkZXZpY2UgaGFzIHRvIGJlIGFibGUgdG8gZmFs bCBiYWNrIHRvIHRoZSB3ZWxsLWtub3duIGtleSBhbnkNCj4gPiB0aW1lLCBzaW5jZSB0aGUgc2F2 ZWQga2V5IG1heSBiZSBzdGFsZSAobm9kZSBtb3ZlZCwgbm9kZSBzbGVwdCB3aGlsZQ0KPiA+IGtl eSB3YXMgY2hhbmdpbmcsIG5vZGUgaXMgYWxsb3dlZCBpbiBtdWx0aXBsZSBvdmVybGFwcGluZyBu ZXR3b3Jrcw0KPiA+IHVzaW5nIGRpZmZlcmVudCBrZXlzLCBldGMuKQ0KPiANCj4gSW4gd2hpY2gg Y2FzZSBpdCBpcyBhZ2FpbiBqb2luaW5nIG5vZGUsIGFuZCBzdGFydCBqb2luaW5nIHByb2Nlc3Mg ZnJvbSB0aGUNCj4gYmVnaW5uaW5nLiBOb3RlLCB0aGF0IGV2ZW4gdGhlbiBub2RlIG5lZWRzIHRv IHJlbWVtYmVyIGxhc3QgQVNOIGl0IGhhcyB1ZXNkDQo+IGZvciBlYWNoIGtleSBpdCBoYXMsIGFu ZCBpdCBuZWVkcyB0byBtYWtlIHN1cmUgQVNOIG5ldmVyIGdvZXMgYmFja3dhcmRzIGV2ZW4gaWYN Cj4gaGUgcmVqb2lucyB0aGUgbmV0d29ya3MuIE1vc3QgbGlrZWx5IGl0IHdpbGwgd2FudCB0byBy ZW1vdmUgYWxsIG9sZCBrZXlzIGJlZm9yZQ0KPiBldm4gc3RhcnRpbmcgdG8gcmVqb2luLiBBbHNv IHRoZSBqb2luaW5nIHByb3RvY29sIG5lZWRzIHRvIGJlIHNvIHRoYXQgaXQgbWFrZSBzdXJlDQo+ IGl0IGNhbm5vdCBiZSByZXBsYXllZCBpbiBzdWNoIHdheSB0aGF0IGV2ZW4gaWYgYXR0YWNrZXIg ZG8gbm90IGtub3cgdGhlIGNvbnRlbnRzDQo+IG9mIHRoZSBmcmFtZXMsIHRoZSBleGNoYW5nZSBj YW5ub3QgcmVzdWx0IGluIHNhbWUga2V5cyB0byBiZSBncm91cCBrZXlzIHRvIGJlDQo+IHRyYW5z bWl0dGVkIHRvIHRoZSBqb2luaW5nIHBlZXIuDQo+IA0KPiBGb3IgZXhhbXBsZSBwcm90b2NvbCB0 aGF0IHdvdWxkIHNlbmQgZ3JvdXAga2V5cyB0byB0aGUgcGVlciBieSBlbmNyeXB0aW5nDQo+IHRo ZW0gd2l0aCB0aGUgcHVibGljIGtleSBvZiB0aGUgcGVlciB3b3VsZCBiZSB1bnNhZmUsIGFzIHRo ZW4gYXR0YWNrZXIgY291bGQNCj4gdHJpY2sgdGhlIG5vZGUgdG8gcmVqb2luIGF0dGFja2VycyBu ZXR3b3JrIGFuZCByZXBsYXkgdGhlIGpvaW5pbmcgZnJhbWVzIGZyb20gdGhlDQo+IHJlYWwgbmV0 d29yayB0byB0aGUgbm9kZSwgYW5kIHRoZW4gbm9kZSB3b3VsZCBoYXZlIHRoZSByZWFsIGdyb3Vw IGtleSAoYWZ0ZXINCj4gZGVjcnlwdGluZyB0aGUga2V5IG9iamVjdCBzZW50IHRvIGl0KS4gQXR0 YWNrZXIgY291bGQgZG8gYWxsIHRoaXMgZXZlbiB3aGVuIGl0IGRvZXMNCj4gbm90IGtub3cgdGhl IGNvbnRlbnRzIG9mIHRoZSBvYmpldGNzLg0KPiANCj4gVGhlIGF0dGFja2VyIGNvdWxkIGhhdmUg YWxzbyBzdG9yZWQgdGhlIG9sZCBiZWFjb25zIGZyb20gdGhlIHJlYWwgY29vcmRpbmF0b3JzDQo+ IGFuZCByZXBsYXkgdGhlbSB0byB0aGUgbm9kZSwgc28gbm9kZSB3b3VsZCB0aGluayBoZSBpcyBw YXJ0IG9mIHRoZSByZWFsIG5ldHdvcmssDQo+IGFuZCB3b3VsZCBzdGFydCB0cmFzbm1pdHRpbmcg dXNpbmcgdGhlIG9sZCBBU04uIEltbWVkaWF0ZWx5IHdoZW4gaXQgZG9lcyB0aGlzDQo+IHRoZSBh dHRhY2tlciBub3cgaGF2ZSB0d28gcGFja2V0cyBlbmNyeXB0ZWQgd2l0aCBzYW1lIGtleSAod2hp Y2ggYXR0YWNrZXINCj4gZG9lcyBub3Qga25vdykgYW5kIHdpdGggc2FtZSBBU04gKyBzb3VyY2Ug YWRkcmVzcyA9PSBzYW1lIENDTSBub25jZSwgYW5kDQo+IHRoZW4gaXQgd291bGQgYmUgYWJsZSB0 byBnZXQgaW5mb3JtYXRpb24gb3V0IGZyb20gdGhlIHBhY2tldHMuDQo+IA0KPiAtLQ0KPiBraXZp bmVuQGlraS5maQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gNnRpc2NoLXNlY3VyaXR5IG1haWxpbmcgbGlzdA0KPiA2dGlzY2gtc2VjdXJp dHlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlz Y2gtc2VjdXJpdHkNCg== From nobody Fri Dec 12 05:11:59 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73121A6FFA for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 05:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLkT5ilfwhZ5 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 05:11:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 A6C251A0169 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 05:11:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBCDBpjB022514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Dec 2014 15:11:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBCDBpF3019007; Fri, 12 Dec 2014 15:11:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21642.59798.976272.723585@fireball.kivinen.iki.fi> Date: Fri, 12 Dec 2014 15:11:50 +0200 From: Tero Kivinen To: Kris Pister In-Reply-To: <548AC87B.7010306@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> <548AC87B.7010306@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 13 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/_BrRvY4Nt7PZysNugkH4a38S25E Cc: Jonathan Simon , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 13:11:58 -0000 Kris Pister writes: > Tero - again I feel like we have a different understanding of what > is going on. Nodes in the network will keep track of ASN. They will > not in general be listening to beacons, because beacons are not, and > can not be, protected with symmetric means. There is way to authenticate that the sender of the beacon is part of the network, and because of that there can be somewhat trusted what it says. When I have been reading the 802.15.4 I have not understood that TSCH do require accurate clock to keep the ASN up to date even over sleeping for long periods time and that only new joining devices care about ASN sent in the beacon. If all TSCH nodes do require accurate clock, then that will solve the ASN problem, but I have understood that there are other parameters in the beacon too which affect the network. As far as I know those parameters can also be changed during the runtime of the network, or is that also some of those false assumptions I have made by just reading the 802.15.4 and not vendors specifications (i.e. of course if vendors make their products so that they will ignore beacons completely after the initial join to the network, then protecting beacons have no value). -- kivinen@iki.fi From nobody Fri Dec 12 08:53:57 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50FD1ACEE5 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 08:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YlU80Bfa6XHU for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 08:53:55 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AD61A1A42 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 08:53:55 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id eu11so7591566pac.39 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 08:53:55 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=irxS/Oyny+zWhBRJbwumvqZe4DksWWOT1g7qTFQe2UA=; b=Po7pX8td74B1dV54ZgatiBgdDElMj+ddZn6zjbVcXZ6dqPyM6hLoUvXYN7YOD1jp47 RMvvDDouuAdI4FFYicXxclRhQMX8BD7SNmvELKiIiznjjOwId/QRSjrS2Vh6cMN8RJyq lqCrkidMZiQrckzRgMKX1bgd5Kuzeee8cW/kZOYev/oKi99ZFgO2jsPTZDBtMZzJR+SY jlDlwKscn8V/hAAwqIdAYBc2rg09sH5bfJ3yw2vIrXRRqz6YatfJ7dKR0p8NtEQfipBb LEp24cY0IhlL/7/lKqmUYLOphWX3mSIDOQc3/24LRnNml+aJf+KgJK+uhOrriqsALxux 508g== X-Gm-Message-State: ALoCoQkmWCqou+wPz02G+WVzUpm4EykRGOGik7HVOPZvbOql22EdE+wWp/KB0pDMKQECa3hmvM9n X-Received: by 10.66.142.166 with SMTP id rx6mr28666081pab.33.1418403234844; Fri, 12 Dec 2014 08:53:54 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id j5sm2028259pdp.9.2014.12.12.08.53.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 08:53:54 -0800 (PST) Message-ID: <548B1DB6.7090901@berkeley.edu> Date: Fri, 12 Dec 2014 08:54:14 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.38703.437570.432580@fireball.kivinen.iki.fi> <548AC511.6090402@berkeley.edu> <21642.58952.350447.597806@fireball.kivinen.iki.fi> In-Reply-To: <21642.58952.350447.597806@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/xR3sYoaYTkIbZQsHQmaTV7qbnYs Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:53:57 -0000 > If it requires devices to keep accurate enough clocks and verify > that ASN has right value, then that requirement needs to be mentioned somewhere. Tero - indeed, that is the key piece of information that differs in our understanding. Now I understand your concern. You are absolutely correct that if nodes *in* the network use beacons to get the ASN, then the beacons must be protected. That is not how *existing* TSCH networks work - maybe it should be in the future. Looking through the 6TiSCH documents, I can see that it is not at all clear that in a secure network the use of beacons for synchronization is not allowed. Indeed, in at least one document it says "[...] take into account whether EBs are used as the only mechanism to synchronize devices, or whether a Keep-Alive (KA) mechanism is also used." So it's not surprising that you came to the conclusion that we need secure beacons. I still have concerns about going that way, but it's certainly a reasonable assumption for you to have made. ksjp On 12/12/2014 4:57 AM, Tero Kivinen wrote: > If it requires devices to keep accurate enough clocks and verify > that ASN has right value, then that requirement needs to be mentioned > somewhere. From nobody Fri Dec 12 09:17:49 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287EA1A009E for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 09:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EZQK5u8h3XhL for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 09:17:45 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD821A8725 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 09:17:44 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so7535135pdb.32 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 09:17:44 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=Low46w7UcQAYNvxE7UxxviCouVdgL2qgm9FrX9de04s=; b=IQ/rDHhmIjPoEmVtB+vqY0kCH/0VHMFW1z+T8GdAkNPvrWd+9+Xy0psS3SLZGlMiut lraPhQavfmnVZnsj8JJD1a6cCyaDgAr7RrBEDdeFuykm7c2KxKhzEMXYR1s40lSfgyfe PCn1EPWApopDRaddFU4WxPq7x9BTtfBhJD3fv2f2H2u6ZQNbSRw/ywKkQjxE2jpWDZ5m pLF6R7uAaCSMpL7iWfH42niWUoRZRcSLL1mBGM3ihlw0waiH5H535wqEUPWcubM83NW/ GrAX5TBYswEoEAwujx22QL19TIPbAgKgUdothi68HjQpXu0HzKjSSC+cDn6V/hEVgpN3 HdUQ== X-Gm-Message-State: ALoCoQk47ssdCUo2NKp4VVIq/xE46HfXNc7uB5gQjQIGMQs2ICrPlzM0q5Fa1rUPtZ8kNrHuI0Wq X-Received: by 10.70.137.238 with SMTP id ql14mr24495555pdb.94.1418404664281; Fri, 12 Dec 2014 09:17:44 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id fr1sm2048947pbb.32.2014.12.12.09.17.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 09:17:43 -0800 (PST) Message-ID: <548B234A.4060303@berkeley.edu> Date: Fri, 12 Dec 2014 09:18:02 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> <548AC87B.7010306@berkeley.edu> <21642.59798.976272.723585@fireball.kivinen.iki.fi> In-Reply-To: <21642.59798.976272.723585@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/d7if-4pa2dPE4z2oFfGWAmlOxp4 Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:17:47 -0000 > There is way to authenticate that the sender of the beacon is part of > the network, and because of that there can be somewhat trusted what it says. Agree. If I understand correctly, your point is that 1) we should authenticate EBs with the network key, thereby enabling nodes already in the network to trust EBs for a) synchronization b) DIO and other "piggybacks" (not sure if you are suggesting this, or if its a good idea, but we've discussed the possibility and its in the architecture draft) 2) Joining nodes which hear an EB will not be able to authenticate it, but a) authentication would not be secure for a joining node in any case (as we all exhaustively agree), and b) as Rene pointed out in a private email, there is probably enough structure in the enhanced beacon packet that it is extremely unlikely that random packets sent by other networks will be misinterpreted as EBs by our network, and the consequences of that misinterpretation are not fatal in any case. Regarding 2b, I think that Rene is probably right. The EB for Minimal MUST * be a beacon * contain a sync IE, with 2 header bytes that must be exactly 0x1a06 * contain a Timeslot IE, with 2 header bytes that must be 0x1c01 * contain a channel hopping IE, header bytes 0x1d01 * contain some frame and link IEs with more specific byte values ksjp On 12/12/2014 5:11 AM, Tero Kivinen wrote: > Kris Pister writes: >> Tero - again I feel like we have a different understanding of what >> is going on. Nodes in the network will keep track of ASN. They will >> not in general be listening to beacons, because beacons are not, and >> can not be, protected with symmetric means. > There is way to authenticate that the sender of the beacon is part of > the network, and because of that there can be somewhat trusted what it > says. > > When I have been reading the 802.15.4 I have not understood that TSCH > do require accurate clock to keep the ASN up to date even over > sleeping for long periods time and that only new joining devices care > about ASN sent in the beacon. > > If all TSCH nodes do require accurate clock, then that will solve the > ASN problem, but I have understood that there are other parameters in > the beacon too which affect the network. > > As far as I know those parameters can also be changed during the > runtime of the network, or is that also some of those false > assumptions I have made by just reading the 802.15.4 and not vendors > specifications (i.e. of course if vendors make their products so that > they will ignore beacons completely after the initial join to the > network, then protecting beacons have no value). From nobody Fri Dec 12 10:16:57 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA091A8AC1 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 10:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Fecy9ZTuExE8 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 10:16:51 -0800 (PST) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B731A8743 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 10:16:49 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c12o145.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 1113b845.2b332e449940.5279.00-559.14864.p01c12o145.mxlogic.net (envelope-from ); Fri, 12 Dec 2014 11:16:49 -0700 (MST) X-MXL-Hash: 548b3111134e400e-625cc8803a6d2695fe1b29aea424f603db5bcced Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p01c12o145.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id df03b845.0.5045.00-389.14211.p01c12o145.mxlogic.net (envelope-from ); Fri, 12 Dec 2014 11:16:33 -0700 (MST) X-MXL-Hash: 548b310149db382f-5391b0708c34c43be980a7270dd557d9446c17c5 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 07EB2740AA; Fri, 12 Dec 2014 10:16:26 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFA0DC45-A992-4491-A66A-F981CA88D8A5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: <548B1DB6.7090901@berkeley.edu> Date: Fri, 12 Dec 2014 10:16:05 -0800 Message-Id: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.38703.437570.432580@fireball.kivinen.iki.fi> <548AC511.6090402@berkeley.edu> <21642.58952.350447.597806@fireball.kivinen.iki.fi> <548B1DB6.7090901@berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=OoRbykPt c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=SyYMxH9GAAAA:8 a=PTUIpknUN4U7JoSkrSkA:9 a=pILNOxqG] X-AnalysisOut: [KmIA:10 a=19wCD08tTksA:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA] X-AnalysisOut: [:10 a=p-HxVa_ds0YA:10 a=6fCzC8ZzSwfLsf2kc6kA:9 a=cApEGtRm6] X-AnalysisOut: [2Cuir5b:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014121215); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/kgVr_fQTAmY6MIM7pPVLwyHpn58 Cc: tisch-security <6tisch-security@ietf.org>, Tero Kivinen Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:16:54 -0000 --Apple-Mail=_BFA0DC45-A992-4491-A66A-F981CA88D8A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I see the disconnect now too. We=92re talking about 2 different = beacons. Enhanced Beacons used to advertise a network: For an unsynchronized = node, the content of the beacon tells it what ASN it is, when it can = send a frame to the beaconer, and when it can expect a response from the = beaconer. There was a suggestion to add DAG rank to the contents. This = is the frame that I was suggesting be authenticated with a well known = key to provide protocol separation. =20 Frames used for synchronization in-network: There are 2 mechanisms for = maintaining synchronization. All frames in this context are assumed to = be authenticated and or encrypted with a mutable link-layer key assigned = by a PCE. 1) node sends a frame to a time parent and gets a time correction in the = enhanced acknowledgement. Contents of the outgoing frame are not used = for timekeeping. 2) node gets a frame from a time parent, and uses the time of arrival = relative to when expected to trim its clock. The contents of the frame = are not used for timekeeping. Frame type isn=92t important, so this = could be an Enhanced Beacon, but since TSCH is generally described as a = non-beaconing PAN, this isn=92t the mechanism I=92d assume. --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION**=20 *****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2936, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you.=20 On Dec 12, 2014, at 8:54 AM, Kris Pister wrote: > > If it requires devices to keep accurate enough clocks and verify > > that ASN has right value, then that requirement needs to be = mentioned somewhere. >=20 > Tero - indeed, that is the key piece of information that differs in = our understanding. > Now I understand your concern. You are absolutely correct that if = nodes *in* the > network use beacons to get the ASN, then the beacons must be = protected. > That is not how *existing* TSCH networks work - maybe it should be in = the future. >=20 > Looking through the 6TiSCH documents, I can see that it is not at all = clear that > in a secure network the use of beacons for synchronization is not = allowed. Indeed, > in at least one document it says > "[...] take into account whether EBs are used as the only mechanism = to > synchronize devices, or whether a Keep-Alive (KA) mechanism is also = used." >=20 > So it's not surprising that you came to the conclusion that we need = secure beacons. > I still have concerns about going that way, but it's certainly a = reasonable assumption > for you to have made. >=20 > ksjp >=20 > On 12/12/2014 4:57 AM, Tero Kivinen wrote: >> If it requires devices to keep accurate enough clocks and verify >> that ASN has right value, then that requirement needs to be mentioned >> somewhere. >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > = http://cp.mcafee.com/d/1jWVIidEI8Lcnpjpd79KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVV= NyZPoziiJo0E-kfSfbCPVg_oYKrsR14wYM_R-j7cKnpLRXBQSkkuvKej73DemKzp5dl55DBgY-= F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaB= ypuDSrzapoKgGT2TQ1kLCXM04SU-MCr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEwJ= mcvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJF= VVEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45J= ffd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05Jz= axEwed42aaOFEw0zlJwrjhvdFLAR --Apple-Mail=_BFA0DC45-A992-4491-A66A-F981CA88D8A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I see = the disconnect now too.  We=92re talking about 2 different = beacons.

Enhanced Beacons used to advertise a = network: For an unsynchronized node, the content of the beacon tells it = what ASN it is, when it can send a frame to the beaconer, and when it = can expect a response from the beaconer.  There was a suggestion to = add DAG rank to the contents.  This is the frame that I was = suggesting be authenticated with a well known key to provide protocol = separation.  

Frames used for = synchronization in-network:  There are 2 mechanisms for maintaining = synchronization. All frames in this context are assumed to be = authenticated and or encrypted with a mutable link-layer key assigned by = a PCE.
1) node sends a frame to a time parent and gets a time = correction in the enhanced acknowledgement.  Contents of the = outgoing frame are not used for timekeeping.
2) node gets a = frame from a time parent, and uses the time of arrival relative to when = expected to trim its clock. The contents of the frame are not used for = timekeeping. Frame type isn=92t important, so this could be an Enhanced = Beacon, but since TSCH is generally described as a non-beaconing PAN, = this isn=92t the mechanism I=92d = assume.


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

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

On Dec 12, 2014, at 8:54 AM, Kris Pister <ksjp@berkeley.edu> = wrote:

> If it requires devices to keep accurate enough clocks = and verify
> that ASN has right value, then that requirement needs = to be mentioned somewhere.

Tero - indeed, that is the key piece = of information that differs in our understanding.
Now I understand = your concern.  You are absolutely correct that if nodes *in* = the
network use beacons to get the ASN, then the beacons must be = protected.
That is not how *existing* TSCH networks work - maybe it = should be in the future.

Looking through the 6TiSCH documents, I = can see that it is not at all clear that
in a secure network the use = of beacons for synchronization is not allowed.  Indeed,
in at = least one document it says
 "[...]  take into account = whether EBs are used as the only mechanism to
=   synchronize devices, or whether a Keep-Alive (KA) mechanism = is also used."

So it's not surprising that you came to the = conclusion that we need secure beacons.
I still have concerns about = going that way, but it's certainly a reasonable assumption
for you to = have made.

ksjp

On 12/12/2014 4:57 AM, Tero Kivinen = wrote:
If it requires devices to keep = accurate enough clocks and verify
that ASN has right value, then that = requirement needs to be = mentioned
somewhere.

______________________________= _________________
6tisch-security mailing list
6tisch-security@ietf.org
h= ttp://cp.mcafee.com/d/1jWVIidEI8Lcnpjpd79KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVN= yZPoziiJo0E-kfSfbCPVg_oYKrsR14wYM_R-j7cKnpLRXBQSkkuvKej73DemKzp5dl55DBgY-F= 6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBy= puDSrzapoKgGT2TQ1kLCXM04SU-MCr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEwJm= cvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJFV= VEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45Jf= fd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05Jza= xEwed42aaOFEw0zlJwrjhvdFLAR

= --Apple-Mail=_BFA0DC45-A992-4491-A66A-F981CA88D8A5-- From nobody Fri Dec 12 11:31:12 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846C41A1ADF for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:31:10 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA7-ZKrbbUmv for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:31:08 -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 D8E5D1A6F01 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 11:31:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A4AA3203AA for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 14:34:53 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 24086637F5; Fri, 12 Dec 2014 14:31:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 06C1063745 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 14:31:01 -0500 (EST) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> In-Reply-To: <21641.39309.532797.197552@fireball.kivinen.iki.fi> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> 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/j3Lgvxt0rtJIwRmwTFgU9aoer4I Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:31:10 -0000 --=-=-= Tero Kivinen wrote: > remove all old keys before evn starting to rejoin. Also the joining > protocol needs to be so that it make sure it cannot be replayed in > such way that even if attacker do not know the contents of the frames, > the exchange cannot result in same keys to be group keys to be > transmitted to the joining peer. > For example protocol that would send group keys to the peer by > encrypting them with the public key of the peer would be unsafe, as > then attacker could trick the node to rejoin attackers network and > replay the joining frames from the real network to the node, and then > node would have the real group key (after decrypting the key object > sent to it). Attacker could do all this even when it does not know the > contents of the objetcs. I think public-key (chain) authenticated DTLS (probably with PFS) is good enough to keep the key secure. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVItCcoCLcPvd0N1lAQKaJAf/foUKECUKYWI0pXv64N1RiXo03n/rcvEm ++3n6pR5CBcv8Pu7NuowXybR6F6+eeNt3jZeRA81g5qxLGhDv5TFjo0b4RCEY8lt xuvRI1N1kw53O6Vvdr8T+h4uHXU5byjKAwcCqxhWJIiJ2WOjtEd8vzSKKO9ePIW9 x9NW8me+KMjb4T9442QdpcnxkShSlivsWbJ8vzgatvDti0Vsewgkz2cp76fiPnNT afTeyU8rgFC80Uv+N/U5ZZCLDChn8DxtF3yfmsG2N71cql7mcaeUmA/BrMfv8FV3 6HFBDw6NCHYK2C3sMoCD0opRHYnFH9dlo4uzvczZ4+GMVpBGRjve8g== =JnW/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 12 11:49:44 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3721A8947 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:49:43 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NHjQaXwuOuf for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:49:42 -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 DD74A1A88CC for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 11:49:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6AC61203AF; Fri, 12 Dec 2014 14:53:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B5EF5637F5; Fri, 12 Dec 2014 14:49:40 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9B40063745; Fri, 12 Dec 2014 14:49:40 -0500 (EST) From: Michael Richardson To: jsimon@linear.com In-Reply-To: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> 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/Z5PBJEQHVt4nfj5qGSkVxk8oXfA Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] Fwd: (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:49:43 -0000 --=-=-= Jonathan Simon wrote: > Imagine a sleepy node. It first joins with the well-known key. It gets I think it's more the sleepy; I think it's in a coma. That's okay. > assigned a new Beacon key #1 as you describe. It goes to sleep, and > meanwhile, the Beacon key is changed to key #2. The node wakes up and > hears the Beacon. It tries key #1 and fails, and tries the WKK and fails. > The proposal has been that the node should accept the Beacon contents, but > now we don't even know if it is a Beacon, or some other protocol that looks > like a Beacon. First, I would claim once enrolled, the node never goes back to unenrolled state. If it would do that, then when fake-beacon-that-pretends-to-have-key#2 is heard, that the node would fall off the network. Second, if the beacon key changed, and do in a time such that not all nodes got the new key (in advance), then the network is broken, period. Tero suggested that we have up to 16 key identifiers for this, to give us lots of time/space to get new keys out. How often would we change the beacon key? I think we have to change the beacon key when the ASN threatens to roll-over. the ASN is...5 bytes.. and I think we have 100 slottimes per ASN? And slottimes are on the order of 10s, I think? So that means we have 1,099,511,627,776,000s between needing to roll the beacon key due to ASN? Probably my inputs are wrong here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVItG0YCLcPvd0N1lAQJdjQgAnjc0qkUskR1HpX2VCiY/hLJIIAyqse3v lH+sCZVdy9y2rUo6n3JMk4HZIXki/U9L3kA4L4tf9fnnwIfLNcb7jEsS9dWpfJTX Dvp596NZy2azFqrUMz9Tslr7juslMbtyNyKEc7T3pvAf6Cdvxhr4h8kHpUFDpTFa vTDCtfnVhi9OL01TWzv1PgViX3HJPZXySn/Gmw3tbrQ+bDbndDNmpfDRB5iAAXQX uaNvur16crUSoJ55m2nkhHm1DcyTOdAtg77qwHagANu5RZDQjgzNt1pTA56FR6UM gqGm5hz+IMO3h/RcJdRN7WuK3lK1xgdduk4KtKk3eOU2tDOPlZfQ2w== =V7Fe -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 12 11:54: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 BC14E1ACD24 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:54:23 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEyjkbzbEowX for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:54:22 -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 58E681ACD03 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 11:54:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E36FF203AF; Fri, 12 Dec 2014 14:58:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7DB98637F5; Fri, 12 Dec 2014 14:54:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 667E063745; Fri, 12 Dec 2014 14:54:21 -0500 (EST) From: Michael Richardson To: Kris Pister In-Reply-To: <54873561.9030106@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> 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/t1lnZN6ACrUvUPa5MTmGFh_zAVU Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:54:23 -0000 --=-=-= Kris Pister wrote: > I'd feel a little better about it if the proponents of "no fake keys" would > acknowledge > the concerns of the "well-known key" gang. We've said repeatedly that "well > known" Kris, this has not been about no fake keys. The debate has not been about that. Rather the question has been: can we actually support well-known keys? Can the join assistant, for instance, which has to participate in both networks, actually do that? I had assumed that the join network would have a completely different schedule, and it's own set of beacons seperate from the production network. I was told that this was essentially impossible. Can you tell us what WirelessHART does? Does it have a beacon? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVItH6oCLcPvd0N1lAQKUbQgAph4QTEBATk0nJ/V8mjd3pZ2OXTQVzbon 7jcjg6ZIjYdUxprBR8/R11sSVhNzmqCEBMezNCh9hBwcJJfWQ7sM9nPstu2/KLZ4 l22Y/FXQgOHbkcym2C6YEt50+MFm5VsyHSk/HBG6IYU+Ey3e/X5/taCa7BloA7Bg tllDR3h3sylUaWplCZLC/BuEJU2yH6XlngoXFzImRbOJJTQzT4v6oG9wV3QN3naw aa6kMc49071xsoPCsjDZiLTxHkrf0rXYcRVWcXyjYLKfzXoLv9atoLPyxhi0eryO Tvoy8ovZSDKc67mvWWN0BeiruaSXtWeb+tNzwmYkUPY3F8V/Td9cmw== =RQjX -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 12 11:58:56 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 E89E21A6EFF for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Vz-euFeXNFpp for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:58:53 -0800 (PST) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF3A1A1B07 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 11:58:52 -0800 (PST) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o145.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 5f84b845.0.7706.00-304.21878.p02c11o145.mxlogic.net (envelope-from ); Fri, 12 Dec 2014 12:58:52 -0700 (MST) X-MXL-Hash: 548b48fc051d2822-05e99970db3554c952684c15dcda1a694c4e9574 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id A32B674096; Fri, 12 Dec 2014 11:58:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FDD7BABB-5D4C-4A56-B0E5-41974FF6E111" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jonathan Simon In-Reply-To: <23374.1418413780@sandelman.ca> Date: Fri, 12 Dec 2014 11:58:22 -0800 Message-Id: <680434F1-FD21-4B8A-889F-5F05FA9216E1@linear.com> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> <23374.1418413780@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-AnalysisOut: [v=2.1 cv=F+pDd8RN c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==] X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=SyYMxH9GAAAA:8 a=9WLwucGthkKcFe3-v0kA:9 a=yRa4N1Js] X-AnalysisOut: [jnidZzgZ:21 a=ev0F5PBYlZaPs4_x:21 a=pILNOxqGKmIA:10 a=19wC] X-AnalysisOut: [D08tTksA:10 a=vsVyj9psLt0A:10 a=qVizmW-ZYBIA:10 a=p-HxVa_d] X-AnalysisOut: [s0YA:10 a=BS-iwoSB_qI2oaZI_KgA:9 a=A_uKWecj6b3XxR2o:21 a=a] X-AnalysisOut: [-_k8ROTjTXvwV4b:21 a=NR22t3FKSdOE5s6v:21 a=_W_S_7VecoQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014121216); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/uHCUrHkTVPTg4HRS7k2tieRPAWM Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:58:55 -0000 --Apple-Mail=_FDD7BABB-5D4C-4A56-B0E5-41974FF6E111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 10 ms but yeah it=92s 100=92s of years. The point was they key rotation is policy, not mechanism. We shouldn't = have a mechanism that requires a particular policy. =20 --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION**=20 *****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2936, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you.=20 On Dec 12, 2014, at 11:49 AM, Michael Richardson = wrote: >=20 > Jonathan Simon wrote: >> Imagine a sleepy node. It first joins with the well-known key. It = gets >=20 > I think it's more the sleepy; I think it's in a coma. That's okay. >=20 >> assigned a new Beacon key #1 as you describe. It goes to sleep, and >> meanwhile, the Beacon key is changed to key #2. The node wakes up = and >> hears the Beacon. It tries key #1 and fails, and tries the WKK and = fails. >> The proposal has been that the node should accept the Beacon = contents, but >> now we don't even know if it is a Beacon, or some other protocol that = looks >> like a Beacon. >=20 > First, I would claim once enrolled, the node never goes back to = unenrolled > state. If it would do that, then when = fake-beacon-that-pretends-to-have-key#2 > is heard, that the node would fall off the network. >=20 > Second, if the beacon key changed, and do in a time such that not all = nodes > got the new key (in advance), then the network is broken, period. = Tero > suggested that we have up to 16 key identifiers for this, to give us = lots of > time/space to get new keys out. >=20 > How often would we change the beacon key? I think we have to change = the > beacon key when the ASN threatens to roll-over. the ASN is...5 bytes.. = and I > think we have 100 slottimes per ASN? And slottimes are on the order of = 10s, I > think? So that means we have 1,099,511,627,776,000s between needing = to roll the > beacon key due to ASN? Probably my inputs are wrong here. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > = http://cp.mcafee.com/d/FZsS71MQ839J5x5Vx5AsYMrKrhs7cFCQn1PbVJ5MsqekkSjhOrs= uuusoLsS8QAHm0afB3ZzOVI-kfSfbCTA7623P3_nV6X31EVjWZOWrbb79Tov7nVqWtAklrEIYG= 7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrA= VkIjbQ-Pspjb5O5mUm-waBYTu00CNObRPobZ8Qg6BJOsGm9BWvpKcFBziWq81sMwAq83hgoMQg= kfAh9Pd45GNzZFOH0QkCy0nc896y0QkaOwTfW6y2HFEw1bvCy0e-NEwj0cQg9Tho0cQg6zDljh= 0d309d45Jffd59Ew1vF6y0QkgGod41ykOpEwQzY4dd59Ew1vF6y2k3cF-q87qNd43AVkIjd45f= IT6kONEwJFVVEw1bvCy0e-TGAfyq84M3d42tQm03d41EVRkQg3gM2jh0sq87dld40m60iq83zh= 0OIGq80JIpkd41NEwhhmld404qJI3qqtPrzfH --Apple-Mail=_FDD7BABB-5D4C-4A56-B0E5-41974FF6E111 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 10 ms = but yeah it=92s 100=92s of years.

The point was they = key rotation is policy, not mechanism.  We shouldn't have a = mechanism that requires a particular policy.  
-- 
Jonathan Simon, Ph. D
Director of = Systems Engineering
Linear Technology, Dust Networks product = group
32990 Alvarado-Niles Road, Suite 910
Union City, CA = 94587
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com

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

On Dec 12, 2014, at 11:49 AM, Michael Richardson <mcr+ietf@sandelman.ca> = wrote:


Jonathan Simon <jsimon@linear.com> = wrote:
Imagine a sleepy node. It first = joins with the well-known key.  It gets

I think = it's more the sleepy; I think it's in a coma. That's = okay.

assigned a new Beacon key #1 as = you describe. It goes to sleep, and
meanwhile, the Beacon key is = changed to key #2.  The node wakes up and
hears the Beacon. =  It tries key #1 and fails, and tries the WKK and fails.
The = proposal has been that the node should accept the Beacon contents, = but
now we don't even know if it is a Beacon, or some other protocol = that looks
like a Beacon.

First, I would claim = once enrolled, the node never goes back to unenrolled
state.  If = it would do that, then when = fake-beacon-that-pretends-to-have-key#2
is heard, that the node would = fall off the network.

Second, if the beacon key changed, and do = in a time such that not all nodes
got the new key (in advance), then = the network is broken, period.  Tero
suggested that we have up = to 16 key identifiers for this, to give us lots of
time/space to get = new keys out.

How often would we change the beacon key? I think = we have to change the
beacon key when the ASN threatens to roll-over. = the ASN is...5 bytes.. and I
think we have 100 slottimes per ASN? And = slottimes are on the order of 10s, I
think?  So that means we = have 1,099,511,627,776,000s between needing to roll the
beacon key = due to ASN?  Probably my inputs are wrong = here.


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



_______________________________________________
6ti= sch-security mailing list
6tisch-security@ietf.org
h= ttp://cp.mcafee.com/d/FZsS71MQ839J5x5Vx5AsYMrKrhs7cFCQn1PbVJ5MsqekkSjhOrsu= uusoLsS8QAHm0afB3ZzOVI-kfSfbCTA7623P3_nV6X31EVjWZOWrbb79Tov7nVqWtAklrEIYG7= DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrAV= kIjbQ-Pspjb5O5mUm-waBYTu00CNObRPobZ8Qg6BJOsGm9BWvpKcFBziWq81sMwAq83hgoMQgk= fAh9Pd45GNzZFOH0QkCy0nc896y0QkaOwTfW6y2HFEw1bvCy0e-NEwj0cQg9Tho0cQg6zDljh0= d309d45Jffd59Ew1vF6y0QkgGod41ykOpEwQzY4dd59Ew1vF6y2k3cF-q87qNd43AVkIjd45fI= T6kONEwJFVVEw1bvCy0e-TGAfyq84M3d42tQm03d41EVRkQg3gM2jh0sq87dld40m60iq83zh0= OIGq80JIpkd41NEwhhmld404qJI3qqtPrzfH

= --Apple-Mail=_FDD7BABB-5D4C-4A56-B0E5-41974FF6E111-- From nobody Fri Dec 12 11:59: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 D8ECF1A1B07 for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:59:22 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwLZ2zRJMVci for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 11:59: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 EF8E61A6EFF for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 11:59:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FCDC203AF; Fri, 12 Dec 2014 15:03:08 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2B2B0637F5; Fri, 12 Dec 2014 14:59:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 16E8363745; Fri, 12 Dec 2014 14:59:16 -0500 (EST) From: Michael Richardson To: Jonathan Simon In-Reply-To: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> 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/ul-oWW-pzct9g_J8nWLmhWzdR8Y Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:59:23 -0000 --=-=-= Jonathan Simon wrote: > We all agreed that touchless operation is the goal. So beacons need to > be authenticated with a well-known key (yes, I know this does nothing > for security - this provides for protocol separation only). Mixing of In the model we were discussing, a single set of beacons go out. They go out in the "clear" --- whether that means unencrypted or with a well known key, we can leave aside for a moment. The beacons are authenticated with MIC (authentication header in IPsec-speak). This lets the nodes which are already part of the production network authenticate them, and facilities the sleepy node which comes back to life, and needs to catch up on the ASN. Joining nodes see the beacon, can look inside since it is in the "clear", but can not validate the MIC. There was a discussion about whether or not this was possible in the specification. As such, joining nodes can synchronize to the timeslot schedule and can find the Aloha part, and do their work at that point. > This is all distraction from the real problem we have to solve: how do > we agree on session keys that allow a device and a PCE to exchange MAC > configuration messages in a minimal number of frames, and do so in a > touchless way. Everything else is either irrelevant, or application > policy. I think that this part is easy; but I don't have running code to prove that, at least not yet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVItJDoCLcPvd0N1lAQIwSwgAqI/sy8dMIIY62ThS78uJvAF6VFHta2nn MdERnmCNy0IAFkIQJ6XsIOWBipPhj8dZiuUTkn5RyXNY5TV+oR1VoXQdN8qKl6NE JtB4JC6mAF7/5WmwSHt0nGN2+oqaRJV1fAQPdLPetvo416sMr3jznmUKHXZgeeRn WVkjqHmx9XSYcEYitHBRyQitP4Urakr7aF4lhkcyxOpDGvDcLlF6h8VLaVrjKAPv h0DWS1Qwou2CFWcJ0mDt+eglBADwrnpZMMtAyAklubkIZQPy+a9IszNfuhf9sRjD zgDN1CMS2riMcmVLV4V+bqRh5CDwpj6BeH8qBDrqs4P2gQ/elHYWXQ== =Tzoy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 12 15:56: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 5A7F61A03AA for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 15:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ST0SLi_kEn for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 15:56:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A57B1A1A8A for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 15:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4795; q=dns/txt; s=iport; t=1418428602; x=1419638202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uIYKHGde3oKUqWz02OoTHUqIK8N6wlS0I/ezhx8I9I8=; b=mjVVp0UseLzw1UtcGyeEPMbuHGLvClLBm3K9wvrUn8uD+n6es84m7XMI rN2fxcG/WjjWrFR8xHC6nkXKQW4UX1T6v6cspwuKd+kkWMGbrfY/v0xAs VuYCbqjL0v8E1G2B6gsNHwSt0bgdFvpjb99ftkcmcxkEIvgeMNqfpu36e U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAGCAi1StJV2c/2dsb2JhbABZDoJ4UlgEw1qCGwqFKEoCgRUWAQEBAQF9hAwBAQEEAQEBawsMBAIBCA4DAQMBAQEKGQQHJwsUAwYIAgQBDQUIiCQN2CsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIxEAYJLEQEfMQcGgxCBEwWJE4RsiXqIQIQ0gzgigX4eFH89boEMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,567,1413244800"; d="scan'208";a="379923643" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 12 Dec 2014 23:56:41 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBCNueY7025762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 23:56:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.39]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 17:56:40 -0600 From: "Pascal Thubert (pthubert)" To: Kris Pister , Tero Kivinen Thread-Topic: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan Thread-Index: AQHQFi+V0TeAimkCfUGoaRpnApOoa5yMm/aw Date: Fri, 12 Dec 2014 23:56:38 +0000 Deferred-Delivery: Fri, 12 Dec 2014 23:45:00 +0000 Message-ID: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> <548AC87B.7010306@berkeley.edu> <21642.59798.976272.723585@fireball.kivinen.iki.fi> <548B234A.4060303@berkeley.edu> In-Reply-To: <548B234A.4060303@berkeley.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.247.184] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/gL_pJZBEgJSkc_TFMNUjM9rm-iM Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:56:43 -0000 Hello Kris: Regarding Ren=E9's point 2b, it is not only about differentiating protocols= but also instances IOW different networks like different SSIDs tell you wh= ich network, all of them Wi-Fi.=20 For that purpose, I buy Tero's point that we could also get a new 'SSID' IE= , and should we favor that path, we can see with the interest group whether= there is space and time in the 2015 edit for this. About the PSK operation, we still need to support the case were the network= secret key is provisioned and the device starts from there. This is hardly= differentiable from the case where that PSK is a weak secret used to diffe= rentiate networks as a well-known SSID. So at the end of the day, it is an = operational issue, not a protocol one. I see how we could recommend operati= ons, but not how we could bar the use as SSID. Do I miss something? Also, with classical implementations, the operational schedule comes from t= he network manager or system manager, so it does not leak anyway. With our = distributed operation, some of the operational schedule may be passed in th= e clear and that troubles me. I think that another operational recommendati= on should be to keep the join cell separate from the data ones, as LTE does= for instance. Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Kris Pister > Sent: vendredi 12 d=E9cembre 2014 11:18 > To: Tero Kivinen > Cc: tisch-security > Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tu= e Dec 2, > 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security = call Tue > December 2, 2014, 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan >=20 > > There is way to authenticate that the sender of the beacon is part of = > the > network, and because of that there can be somewhat trusted what it says. > Agree. >=20 > If I understand correctly, your point is that > 1) we should authenticate EBs with the network key, thereby enabling node= s > already in the network to trust EBs for > a) synchronization > b) DIO and other "piggybacks" (not sure if you are suggesting this, or = if its a > good idea, but we've discussed the possibility and its in the architectur= e draft) >=20 > 2) Joining nodes which hear an EB will not be able to authenticate it, bu= t > a) authentication would not be secure for a joining node in any case (a= s we all > exhaustively agree), and > b) as Rene pointed out in a private email, there is probably enough str= ucture in > the enhanced beacon packet that it is extremely unlikely that random pack= ets > sent by other networks will be misinterpreted as EBs by our network, and = the > consequences of that misinterpretation are not fatal in any case. >=20 > Regarding 2b, I think that Rene is probably right. The EB for Minimal MU= ST > * be a beacon > * contain a sync IE, with 2 header bytes that must be exactly 0x1a06 > * contain a Timeslot IE, with 2 header bytes that must be 0x1c01 > * contain a channel hopping IE, header bytes 0x1d01 > * contain some frame and link IEs with more specific byte values >=20 > ksjp >=20 > On 12/12/2014 5:11 AM, Tero Kivinen wrote: > > Kris Pister writes: > >> Tero - again I feel like we have a different understanding of what is > >> going on. Nodes in the network will keep track of ASN. They will not > >> in general be listening to beacons, because beacons are not, and can > >> not be, protected with symmetric means. > > There is way to authenticate that the sender of the beacon is part of > > the network, and because of that there can be somewhat trusted what it > > says. > > > > When I have been reading the 802.15.4 I have not understood that TSCH > > do require accurate clock to keep the ASN up to date even over > > sleeping for long periods time and that only new joining devices care > > about ASN sent in the beacon. > > > > If all TSCH nodes do require accurate clock, then that will solve the > > ASN problem, but I have understood that there are other parameters in > > the beacon too which affect the network. > > > > As far as I know those parameters can also be changed during the > > runtime of the network, or is that also some of those false > > assumptions I have made by just reading the 802.15.4 and not vendors > > specifications (i.e. of course if vendors make their products so that > > they will ignore beacons completely after the initial join to the > > network, then protecting beacons have no value). >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Fri Dec 12 17:54:44 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA5E1A8BBF for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 17:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 82qfZA0jQMiv for <6tisch-security@ietfa.amsl.com>; Fri, 12 Dec 2014 17:54:42 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17201A8BBE for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 17:54:41 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so7663728pab.19 for <6tisch-security@ietf.org>; Fri, 12 Dec 2014 17:54:41 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=sk+wBHeq0hI2TodNz0+6PoQZoAjTYx7bPgruStM+DAY=; b=kLDSmxsHy1lwVZJe8dE5xtmxRAAcIBo0wTHtLgvcWgE8zF/ALb60/XwWjDWTQ3X5KF fXYH5nkRIlfRopr29zLPSFwu61nTnbLeO1DsycUlA2nWfRn25mycH1/XqUxu5iB5SGNW +b02OKGWKpTkssEpl0aZg9aLOaSGMxxzsXMeUDN6yijosi7Pwu3RXlEBebuOjBeusUBU cjW8NgRKTfp7SPWYSxVK8mF7Wlhw+yL6cyTZTIE1ezRB3ElnAKcD37Sn7SwX/o4yx/nr 7z1WfyJ/X3u0jISLY+R7QYOnA15tXSIMx1dg/MDB3hUX6Frq3nfxZNbvKBjfJp8PHq2s YsgQ== X-Gm-Message-State: ALoCoQm8oTvbaXzKvUV3vcz4aHCzflaxVrt6SUl4U61o+DDZ+p0p6ojg2nhr4WqYNi4KDrXABWVX X-Received: by 10.66.162.37 with SMTP id xx5mr32008310pab.10.1418435681541; Fri, 12 Dec 2014 17:54:41 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id ut7sm2673389pbc.8.2014.12.12.17.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 17:54:40 -0800 (PST) Message-ID: <548B9C74.401@berkeley.edu> Date: Fri, 12 Dec 2014 17:55:00 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <25233.1418414061@sandelman.ca> In-Reply-To: <25233.1418414061@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/f6T53-6oWYbIkmtOmKa6wWjB0ME Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 01:54:44 -0000 Good to hear. Not sure if everyone will agree with you. If the question is "can we actually support well-known keys?" the answer is of course yes, the hardware will happily do that. Wireless HART does roughly what we're talking about. (The terminology in HART is a little different, so I have converted HART terms to ours.) The Join Assistant is a part of a production network where there are no beacons. All nodes are synchronized using ACKs on packets to time parents. Sometimes the packets are just Keepalives, sent for the sole purpose of getting that synchronizing ACK. The Join Assistant gets its schedule from the PCE via an end-to-end management-layer security session with a high-entropy unique key. All such packets are encrypted and authenticated (4B MIC). All MAC layer messages in the production network are authenticated with a single network-wide high-entropy key (4B MIC). All keys are 128 bit. The Join Assistant has a completely different schedule for sending Enhanced Beacons. The Join Assistant calculates a MIC for those beacons using a well-known, fake, bogus, entirely non-secure, zero entropy key. When it receives a response from a joining node, it checks the MIC to make sure that it was calculated with the W-KFBEN-SZE key. If the MIC is incorrect, the packet is thrown away. (This actually happens, and it gets logged, and reported.) If the MIC is correct, and the *type* of the packet is correct (join request) then the packet from the joining node is forwarded over the production network to the JCE, which makes its own determinations. If a packet comes back from the JCE to the Join Assistant for delivery to the joining node, this packet comes over the production network. The Join Assistant transfers it to its local join network, puts a MAC MIC on it with the W-KFBEN-SZE key, and sends it down to the joining node. The ACK that the Join Assistant receives from the Joining Node does not affect its timing at all - the joining node is not a time parent of the Join Assistant. The ACK from the Join Assistant to the joining node is used to keep the joining node synchronized. The joining node may even send keepalives over the local joining network until such time as it has left quarantine and gotten the production network MAC key, at which point any packets that it sends will be on the production network (until such time as it may become a Joining Assistant itself). Between sending Enhanced Beacons and receiving join request responses, the Joining Assistant may send or receive many packets on the production network. ksjp On 12/12/2014 11:54 AM, Michael Richardson wrote: > Kris Pister wrote: > > I'd feel a little better about it if the proponents of "no fake keys" would > > acknowledge > > the concerns of the "well-known key" gang. We've said repeatedly that "well > > known" > > Kris, this has not been about no fake keys. The debate has not been about that. > Rather the question has been: can we actually support well-known keys? > > Can the join assistant, for instance, which has to participate in both > networks, actually do that? > > I had assumed that the join network would have a completely different > schedule, and it's own set of beacons seperate from the production network. > I was told that this was essentially impossible. Can you tell us what > WirelessHART does? Does it have a beacon? > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Dec 15 05:36:36 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77011A6EFF for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km5VApvPLUfW for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:36:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 6C6C91A6F0E for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 05:36:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBFDa960005382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 15:36:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBFDa7R7014084; Mon, 15 Dec 2014 15:36:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21646.58311.525563.576401@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2014 15:36:07 +0200 From: Tero Kivinen To: Jonathan Simon In-Reply-To: References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.38703.437570.432580@fireball.kivinen.iki.fi> <548AC511.6090402@berkeley.edu> <21642.58952.350447.597806@fireball.kivinen.iki.fi> <548B1DB6.7090901@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 29 min X-Total-Time: 31 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/zW-wNEfe1piqKxACyLKJ_VoDmOo Cc: Kris Pister , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:36:34 -0000 Jonathan Simon writes: > I see the disconnect now too. We=E2=80=99re talking about 2 differen= t beacons. Ah, and the other is not beacon at all. I.e. the beacons are only used for joining and other timekeeping is done on other frames. This is not very clear in the 6tisch document, and of course the 802.15.4 does not give any details of this level, so it is impossible to know that from there...=20 > Enhanced Beacons used to advertise a network: For an unsynchronized > node, the content of the beacon tells it what ASN it is, when it can > send a frame to the beaconer, and when it can expect a response from > the beaconer. There was a suggestion to add DAG rank to the > contents. This is the frame that I was suggesting be authenticated > with a well known key to provide protocol separation. So enhanced beacons do not have any security critical information in them, thus they can be allowed to be received without security, right=3F= =20 > Frames used for synchronization in-network: There are 2 mechanisms f= or > maintaining synchronization. All frames in this context are assumed t= o be > authenticated and or encrypted with a mutable link-layer key assigned= by a > PCE. The question I have here how do you configure the security PIB of the 802.15.4 to only allow certain information elements from the certain nodes, and ignore them from others. For data and multipurpose frames I could see that MAC could simply not process the information elements at all, and they will be passed to the upper layer in the MCPS-DATA.indication and then upper layer can do the filtering, but how do you do that filtering on the Enh-Acks or beacons=3F In those frames I think the MAC parses the information elements directly and acts based on those. So if the frame type and key is allowed by the inbound security state machine, then those information elements are processed. > 1) node sends a frame to a time parent and gets a time correction in = the > enhanced acknowledgement. Contents of the outgoing frame are not use= d for > timekeeping. > 2) node gets a frame from a time parent, and uses the time of arrival= relative > to when expected to trim its clock. The contents of the frame are not= used for > timekeeping. Frame type isn=E2=80=99t important, so this could be an = Enhanced Beacon, > but since TSCH is generally described as a non-beaconing PAN, this is= n=E2=80=99t the > mechanism I=E2=80=99d assume. So how do you filter out Time Correlation IEs from frames which come from other nodes than your time parent=3F Or how you even filter out Time Correlation IEs from frames which do not have valid network group key=3F We had short discussion about this (i.e. how we filter based on the information elements) in the sc-maintenance BRC and I would like to know how this is supposedly done=3F Note that Exempt flag does not help there, as if you make Exempt for the joining node, and allow it to send joining request, how do you filter out which information elements in that joining request are acted upon, and which are ignored. --=20 kivinen@iki.fi From nobody Mon Dec 15 05:41:59 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7451A6FC8 for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJiw5pV8jZwE for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:41:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 9290E1A6FC7 for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 05:41:52 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBFDfo9A001343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 15:41:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBFDfo4l002252; Mon, 15 Dec 2014 15:41:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21646.58653.965473.953421@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2014 15:41:49 +0200 From: Tero Kivinen To: Jonathan Simon In-Reply-To: <680434F1-FD21-4B8A-889F-5F05FA9216E1@linear.com> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <21641.39309.532797.197552@fireball.kivinen.iki.fi> <23374.1418413780@sandelman.ca> <680434F1-FD21-4B8A-889F-5F05FA9216E1@linear.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/YfZ2CkJKdKzCOD500umKySpRfpU Cc: Michael Richardson , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:41:54 -0000 Jonathan Simon writes: > 10 ms but yeah it=E2=80=99s 100=E2=80=99s of years. With 10 ms timeslot that would be 348 years, but macTsTimeslotLength is configurable from 1 =C2=B5s increments. If someone defines network w= here the macTsTimeslotLength would be 1 =C2=B5s then ASN would wrap around i= n 12 days. Of course I do not think there is any PHYs that could actually use such short timeslot length yet, but that does not mean that there would not be one in the future... Anyways rekeying the network key every now and then would also be needed if you ever want to remove any devices from the network, for eaxmple beacuse you have replaced them with new ones and sold old ones forward. In that case the old devices could still remember the network key in their stable memory, thus changing the key would be useful feature.=20 --=20 kivinen@iki.fi From nobody Mon Dec 15 05:52:10 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 CDEF71A6FD8 for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQUsTNLQtChK for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 05:52:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 522401A6FCB for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 05:52:07 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBFDq057007856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 15:52:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBFDq0jJ018895; Mon, 15 Dec 2014 15:52:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21646.59263.924143.61806@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2014 15:51:59 +0200 From: Tero Kivinen To: Kris Pister In-Reply-To: <548B9C74.401@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <25233.1418414061@sandelman.ca> <548B9C74.401@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 8 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/nFFpym1emvzZHaVkzDKF5yLtPMo Cc: Michael Richardson , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:52:09 -0000 Kris Pister writes: > Good to hear. Not sure if everyone will agree with you. > > If the question is "can we actually support well-known keys?" the answer > is of course yes, the hardware will happily do that. I think the confusion there was that people were talking about having two sets of beacons, one with well-known keys and another for the production network. I.e. one device would be sending two sets of enhanced-beacons out and their difference would be the key used. As far as I have understood the devices only support sending one set of beacons at one time. Now when it was clarified, that there is only one set of enhanced beacons sent by devices, and those are only used by the joining nodes, and the production network does not use enhanced beacons at all, but instead use other frames for their syncronization then that is much clearer... > Wireless HART does roughly what we're talking about. (The > terminology in HART is a little different, so I have converted HART > terms to ours.) The Join Assistant is a part of a production network > where there are no beacons. All nodes are synchronized using ACKs on > packets to time parents. Sometimes the packets are just Keepalives, > sent for the sole purpose of getting that synchronizing ACK. > > The Join Assistant gets its schedule from the PCE via an end-to-end > management-layer security session with a high-entropy unique key. > All such packets are encrypted and authenticated (4B MIC). All MAC > layer messages in the production network are authenticated with a > single network-wide high-entropy key (4B MIC). All keys are 128 bit. Are that schedule etc delivered from the PCE to the Join Assistant over information elements, or some data / multipurpose frames (i.e. upper layer protocol)? > The Join Assistant has a completely different schedule for sending > Enhanced Beacons. The Join Assistant calculates a MIC for those > beacons using a well-known, fake, bogus, entirely non-secure, zero > entropy key. When it receives a response from a joining node, it > checks the MIC to make sure that it was calculated with the > W-KFBEN-SZE key. If the MIC is incorrect, the packet is thrown away. > (This actually happens, and it gets logged, and reported.) If the > MIC is correct, and the *type* of the packet is correct (join > request) then the packet from the joining node is forwarded over the > production network to the JCE, which makes its own determinations. > If a packet comes back from the JCE to the Join Assistant for > delivery to the joining node, this packet comes over the production > network. The Join Assistant transfers it to its local join network, > puts a MAC MIC on it with the W-KFBEN-SZE key, and sends it down to > the joining node. The ACK that the Join Assistant receives from the > Joining Node does not affect its timing at all - the joining node is > not a time parent of the Join Assistant. Again, how do you filter that enh-ack so that IEs in there are not processed or not trusted, as it is still using valid key configured to the security PIB (i.e. the well-known key)? This filtering needs to be done by the MAC (I think), but there is not a feature in 802.15.4 security (that I know of) that would allow you do that... -- kivinen@iki.fi From nobody Mon Dec 15 08:42:31 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6F21A802F for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 08:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTdoQmUTyPnc for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 08:42:28 -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 9CD651A7D85 for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 08:42:28 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80FAF2009E; Mon, 15 Dec 2014 11:46:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CBAF6637F5; Mon, 15 Dec 2014 11:42:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B501063740; Mon, 15 Dec 2014 11:42:25 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <21646.59263.924143.61806@fireball.kivinen.iki.fi> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <25233.1418414061@sandelman.ca> <548B9C74.401@berkeley.edu> <21646.59263.924143.61806@fireball.kivinen.iki.fi> 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/7IjFOSF1Z7hlDo1LqdFBqcaMAn4 Cc: Kris Pister , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:42:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> The Join Assistant gets its schedule from the PCE via an end-to-end >> management-layer security session with a high-entropy unique key. A= ll >> such packets are encrypted and authenticated (4B MIC). All MAC layer >> messages in the production network are authenticated with a single >> network-wide high-entropy key (4B MIC). All keys are 128 bit. > Are that schedule etc delivered from the PCE to the Join Assistant ov= er > information elements, or some data / multipurpose frames (i.e. upper > layer protocol)? When there is a PCE, the schedule is delivered via the 6top protocol, which runs over CoAP/DTLS. This uses the locally significant (LDevID) certificat= es and anchors that the JCE installed. When there is no PCE, then the minimal schedule is used, and updates to the= =20 may be schedule may be delivered over Information Elements. In this situation, the layer-2 security MUST be node to node. It has been observed that the minimal situation while conceptually simpler, requires more (code/ram) resources from each node, while the PCE situation permits somewh= at simpler firmware. Perhaps this should be unsurprising: the PCE is offloading work from the constrained nodes, they can can be slightly more constrained. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVI8PboCLcPvd0N1lAQJgQwf/V8d0On5H9IAzbJzmtBfhkADOJmjh19QF 7/cssZUV2neuyGuDLvV6KrKC4S050mFwewn7+bhYfpzo4V1HTaKXUp5me4nOWMlD /Sj/So41QaSw3GSI4tTTR+B3W08tPktbFZg6YX8buB/jZIYxwD4pfRT5oXiXQ08R sNDkiMtbWttcO+Po7/puG/mF3DygKFynndNa7gEOzI1SfcqB9Myt1qDW52gDebm5 9YGXhXrtqdTCSq5iQGnFmhEZG0XTGYiH8j9Pw41GUY8Itlre5E3El+y6gV8hLpOI 3OsWWbnXPkC8j8kXjA/u5YtF+D+JtwN+3kLjgMmt9qJbXPk1OnyqmQ== =ZYfl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 15 11:21:47 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2A1A875D for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 11:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xCzF0RlqvR9O for <6tisch-security@ietfa.amsl.com>; Mon, 15 Dec 2014 11:21:42 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8708E1A0143 for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 11:21:42 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so12358523pad.23 for <6tisch-security@ietf.org>; Mon, 15 Dec 2014 11:21:42 -0800 (PST) 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:references:in-reply-to:content-type :content-transfer-encoding; bh=5lHuaTaqPdSj9tROVVySouWP8xL3uQgzOTADWahhaP0=; b=j9J3/dU4Hp3o+WbCdfyMNq/Mb01j4WEPKb03vkPuZ+5v7h+RktJ/O6dhOfrw9GdYtr tsW/XkKwyCQKbTrpo1rbLGG2SLDxenVTVtr2nSS2GiQPMtBZC+ZqO5DLkqrawAUY9Wyx tHysVzSJoK0jYOsOks5bBVH9RQCoBtE5uEdxYycGW6IRTrV42m9qm+ARVjIZIFfncR60 ndgqbiEKPJXZto/sP/QTm70Ul9grKImwK9mtYGEHdqTpznmKMdHptAvF2HqDDjHwaD5Z 91fv9oKyQWg7lc81dpDpU3/jmIhQKSka4iKpGrpymNSXdap7lZqZvEqCaO3pESQ1/7Zr uhGA== X-Gm-Message-State: ALoCoQmqMFnbv6Lf6johagrDyVe4a9AwEsRIT3P17NbH4/IXnnhh9ICx6g8A3A7ZCdiar2o1T0B8 X-Received: by 10.68.246.164 with SMTP id xx4mr54217431pbc.64.1418671302130; Mon, 15 Dec 2014 11:21:42 -0800 (PST) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id v4sm10008129pdc.61.2014.12.15.11.21.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 11:21:41 -0800 (PST) Message-ID: <548F34C4.4000803@berkeley.edu> Date: Mon, 15 Dec 2014 11:21:40 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , Tero Kivinen References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <25233.1418414061@sandelman.ca> <548B9C74.401@berkeley.edu> <21646.59263.924143.61806@fireball.kivinen.iki.fi> <8871.1418661745@sandelman.ca> In-Reply-To: <8871.1418661745@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/tHCL3L6d22Ca-HxeXZYv06Xs5dA Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 19:21:45 -0000 Just in case Tero was asking specifically about WiHART: In HART we didn't have information elements to work with since they didn't exist yet (HART 7.0 came out in 2007), so HART uses an upper layer protocol. ksjp On 12/15/2014 8:42 AM, Michael Richardson wrote: > Tero Kivinen wrote: > >> The Join Assistant gets its schedule from the PCE via an end-to-end > >> management-layer security session with a high-entropy unique key. All > >> such packets are encrypted and authenticated (4B MIC). All MAC layer > >> messages in the production network are authenticated with a single > >> network-wide high-entropy key (4B MIC). All keys are 128 bit. > > > Are that schedule etc delivered from the PCE to the Join Assistant over > > information elements, or some data / multipurpose frames (i.e. upper > > layer protocol)? > > When there is a PCE, the schedule is delivered via the 6top protocol, which > runs over CoAP/DTLS. This uses the locally significant (LDevID) certificates > and anchors that the JCE installed. > > When there is no PCE, then the minimal schedule is used, and updates to the > may be schedule may be delivered over Information Elements. In this > situation, the layer-2 security MUST be node to node. It has been observed > that the minimal situation while conceptually simpler, requires more > (code/ram) resources from each node, while the PCE situation permits somewhat > simpler firmware. Perhaps this should be unsurprising: the PCE is > offloading work from the constrained nodes, they can can be slightly more > constrained. > > > > > > From nobody Tue Dec 16 06:21:39 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890351A1B6F for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 06:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPOM1WxjZWKB for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 06:21:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 EB29C1A1B7A for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 06:21:18 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sBGEJZG8020634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Dec 2014 16:19:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBGEJYjG005183; Tue, 16 Dec 2014 16:19:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21648.16246.205592.59220@fireball.kivinen.iki.fi> Date: Tue, 16 Dec 2014 16:19:34 +0200 From: Tero Kivinen To: Kris Pister In-Reply-To: <548F34C4.4000803@berkeley.edu> References: <54862F96.5040508@gmail.com> <548657C3.8030308@gmail.com> <54873561.9030106@berkeley.edu> <25233.1418414061@sandelman.ca> <548B9C74.401@berkeley.edu> <21646.59263.924143.61806@fireball.kivinen.iki.fi> <8871.1418661745@sandelman.ca> <548F34C4.4000803@berkeley.edu> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 3 min Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/jAoFF2ECjQk4cbgyzWO-r64z5Hs Cc: Michael Richardson , tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 14:21:29 -0000 Kris Pister writes: > Just in case Tero was asking specifically about WiHART: > In HART we didn't have information elements to work with since they > didn't exist yet > (HART 7.0 came out in 2007), so HART uses an upper layer protocol. Ok, thanks. As future versions might be using information elements for transmitting all kind of information, I think we are going to need some security policy mechanisms for them, i.e. some kind of security PIB that will say which key and which security level is needed for information element to be trusted from given node. This is something we are going to be discussing during the 802.15.4 maintenance work. -- kivinen@iki.fi From nobody Tue Dec 16 06:22:07 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1501A1B66 for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 06:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0j1cWp8cUXf for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 06:21:55 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6721A1B6E for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 06:21:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so13000303ieb.3 for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 06:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=dnAF3L/a8OCqneMPN1p/MmJE24RdkRU2EVuF5FIAy1c=; b=Nt96TaAITYr2WVcJ/EmRscP9SpWai53S1BkRvzQ+ztcUfhYUeRjl2wTcb6kbtI4TXp IVN4ZNfb9XSyzt8O+qiKrYSZCIUncxQbYXpW6py99fIRm3R1mj3W2/z84jxAsU210pxu 9zdD7nIhUh1cbsMkv22n113KWqtlsMFUUc8grq0/YILVQBuNV8ymZ1M024ttk0PIsplE kJjONzRaQaTjTxtAXPiMzxklMxEwvVtQBAvnEf2Q6rEH5sYlPMhF32+hMIbhb+uqiDsN 9PzSmp6TImkQIGUHBQFNoys1B/0sB/a9QV5dClCzPRF7N2asr7pU0SOfA+HLFDv4+Fbu awtg== X-Received: by 10.43.12.198 with SMTP id pj6mr32479901icb.46.1418739691243; Tue, 16 Dec 2014 06:21:31 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id hi15sm6371837igb.19.2014.12.16.06.21.30 for <6tisch-security@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 06:21:30 -0800 (PST) Message-ID: <54903FE0.2000306@gmail.com> Date: Tue, 16 Dec 2014 09:21:20 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: tisch-security <6tisch-security@ietf.org> References: <54862348.4020909@gmail.com> In-Reply-To: <54862348.4020909@gmail.com> X-Forwarded-Message-Id: <54862348.4020909@gmail.com> Content-Type: multipart/alternative; boundary="------------080408080500020200010902" Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/jmBfXgZf2T-BTqDMZOlsy1HbJNw Subject: [6tisch-security] Suggested agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom) 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, 16 Dec 2014 14:21:59 -0000 This is a multi-part message in MIME format. --------------080408080500020200010902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: I propose we continue the discussion where we left off last week. Agenda: 1) administrativia {agenda bashing/minutes} 2) join protocol details -- a) (brief!) status update MAC behavior -- b) continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this 3) input 6tisch security to other 6tisch documents Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}. Dial-in info at end of this email. Best regards, Rene -------- Forwarded Message -------- Subject: suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom) Date: Mon, 08 Dec 2014 17:16:40 -0500 From: Rene Struik To: tisch-security <6tisch-security@ietf.org> Dear colleagues: For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now. This leads to the following suggested agenda for this week (essentially a continuation of last week's one): Same as last week's, except with #1a-b) focus on routing/communication flow related aspects join protocol; #2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects #2c) {as consequence of two items above} what to squeeze into architecture draft The detailed agenda and dial-in info is below (#A, resp. #B). Best regards, Rene _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_ Proposed agenda: 0) Agenda bashing 1) Join protocol details a) desired properties b) realizable properties #1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST). For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call) Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf)) 2) Next steps: a) consensus on 1#a and 1#b #2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects #2c) {as consequence of two items above} what to squeeze into architecture draft b) form tiger team to work out details - project phases - communication of sub-results c) what to squeeze into architecture draft, etc. I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call. _B) Dial-in information:_ English : New York Time 6tisch security Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00) Meeting number: 641 709 118 Meeting password: joinjoin Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 709 118 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6 The etherpad we have used is at: http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt -- email:rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080408080500020200010902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear colleagues:

I propose we continue the discussion where we left off last week.

Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this
3) input 6tisch security to other 6tisch documents

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next call, on January 6, 2014) is also at 5pm EST (see schedule till half of January 2015)}.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: suggested agenda for 6tisch security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom)
Date: Mon, 08 Dec 2014 17:16:40 -0500
From: Rene Struik <rstruik.ext@gmail.com>
To: tisch-security <6tisch-security@ietf.org>


Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some material and posted prior to the call. During the call, we discussed all MAC-related aspects relevant for the join protocol and did not discuss higher-layer aspects I prepared material for yet. I suggest we continue the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

A) Suggested agenda Tue Dec 9, 2014, 9am EST call

Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties

#1a-b) focus on routing/communication flow related aspects join protocol (we discussed MAC-related join-relevant aspects during the conf call of Tue Dec 2, 2014, 9am EST).
For slides, see https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing (same slides as sent out prior to Dec 2, 2014, 9am EST call)
Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but also in excerpt (pdf))
2) Next steps:
        a) consensus on 1#a and 1#b
#2a): confirm consensus on MAC (as discussed last week) and routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into architecture draft
        b) form tiger team to work out details
            - project phases
            - communication of sub-results
        c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

B) Dial-in information:
English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
      1-877-668-4493 Call-in toll free number (US/Canada)
      1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
        https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
       http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt



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


--------------080408080500020200010902-- From nobody Tue Dec 16 08:51:27 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 0BE5D1A6F52 for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSA_VA3nZQwx for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 08:51:16 -0800 (PST) Received: from sjmda15.webex.com (sjmda15.webex.com [64.68.124.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CDC1A6FA0 for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 08:51:16 -0800 (PST) Received: from jva2tc111.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-5.webex.com [64.68.121.240]) by sjmda15.webex.com (Postfix) with ESMTP id 90555403F8 for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 16:51:16 +0000 (GMT) Received: from jva2tc111.webex.com (localhost [127.0.0.1]) by jva2tc111.webex.com (Postfix) with ESMTP id 3823D1BF23D for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 16:51:16 +0000 (GMT) Date: Tue, 16 Dec 2014 16:51:16 +0000 (GMT) From: Michael Richardson To: 6tisch-security@ietf.org Message-ID: <454908433.10115.1418748676228.JavaMail.nobody@jva2tc111.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_10113_1327192358.1418748676227" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/8BigRKwGXtUfWG0kT2zYSNP0vQA Subject: [6tisch-security] WebEx meeting rescheduled: 6tisch security X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mcr+nomcom@sandelman.ca List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 16:51:24 -0000 ------=_Part_10113_1327192358.1418748676227 Content-Type: multipart/Alternative; boundary="----=_Part_10114_209319517.1418748676227" ------=_Part_10114_209319517.1418748676227 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTWljaGFlbCBSaWNoYXJkc29uIGNoYW5nZWQgdGhlIHRpbWUgZm9yIHRoaXMgV2Vi RXggbWVldGluZy4KCgo2dGlzY2ggc2VjdXJpdHkKRXZlcnkgVHVlc2RheSwgZnJvbSBUdWVzZGF5 LCBEZWNlbWJlciAxNiwgMjAxNCwgdG8gVHVlc2RheSwgRmVicnVhcnkgMywgMjAxNQo1OjAwIHBt ICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6MDApICB8ICAxIGhy CgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW04MzIzOWY0ZGNmM2RjOGYwZWE0MTcyOTA4OWY4Yzc4YwpNZWV0aW5nIG51bWJlcjogNjQx IDcwOSAxMTgKTWVldGluZyBwYXNzd29yZDogam9pbmpvaW4KCg0KSk9JTiBCWSBQSE9ORQ0KMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDEg NzA5IDExOAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWE2YzUyMzIxMDU5ZTkzNGUxNGQ5MDMxNjMyYjMzMDZhDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21j CgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLgo= ------=_Part_10114_209319517.1418748676227 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBNaWNo YWVsIFJpY2hhcmRzb24gY2hhbmdlZCB0aGUgdGltZSBmb3IgdGhpcyBXZWJFeCBtZWV0aW5nLgog ICAgICAgICAgICAgICAgCSAgICAgICAgICAgPC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgoK Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6 MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUi PgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHg7IGNvbG9yOiM0 RDRENEQiPgoJCQkJCQkJCQk8Yj42dGlzY2ggc2VjdXJpdHk8L2I+CgkJCQkJCQkJPC90ZD4KCQkJ CQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD5FdmVy eSBUdWVzZGF5LCBmcm9tIFR1ZXNkYXksIERlY2VtYmVyIDE2LCAyMDE0LCB0byBUdWVzZGF5LCBG ZWJydWFyeSAzLCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5 bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD41OjAwIHBtJm5ic3A7Jm5ic3A7fCZuYnNwOyZu YnNwO0Vhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTowMCkmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3Rh YmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3 aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRk IHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTgzMjM5ZjRkY2YzZGM4ZjBl YTQxNzI5MDg5ZjhjNzhjIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2Zv bnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0 aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv dGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRh bnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBh ZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3Rk PgoJCQkJCQkJCTx0ZD42NDEgNzA5IDExOAoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBw YXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5qb2luam9pbjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48 dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJn aW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3Mg Y29kZTombmJzcDs2NDEgNzA5IDExODwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMw MEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFi bGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0i aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxl PSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bWE2YzUyMzIxMDU5ZTkzNGUxNGQ5MDMxNjMyYjMzMDZhIiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1l ZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9u dC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAg IENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAg ICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJ CUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwv dHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_10114_209319517.1418748676227-- ------=_Part_10113_1327192358.1418748676227 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEyMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEyMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86NnRpc2NoLXNlY3VyaXR5QGlldGYub3JnCk9SR0FO SVpFUjtDTj0iTWljaGFlbCBSaWNoYXJkc29uIjpNQUlMVE86bWNyK25vbWNvbUBzYW5kZWxtYW4u Y2EKRFRTVEFSVDtUWklEPSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjE2VDE3MDAwMApEVEVORDtUWklE PSJFYXN0ZXJuIFRpbWUiOjIwMTQxMjE2VDE4MDAwMApSUlVMRTpGUkVRPVdFRUtMWTtJTlRFUlZB TD0xO0JZREFZPVRVO0NPVU5UPTgKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm ClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MwpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4wNDU2 NjgwLTMxMjA3MzU1Ny1TVT1pZXRmCkRUU1RBTVA6MjAxNDEyMTZUMjIwMDAwWgpERVNDUklQVElP TjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW04MzIzOWY0ZGNmM2RjOGYwZWE0MTcyOTA4OWY4Yzc4Y1xuTWVldGluZyBudW1i ZXI6IDY0MSA3MDkgMTE4XG5NZWV0aW5nIHBhc3N3b3JkOiBqb2luam9pblxuXG5cbkpPSU4gQlkg UEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRh KSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2Vz cyBjb2RlOiA2NDEgNzA5IDExOFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxu aHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5c bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10 ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJ WkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tODMyMzlmNGRjZjNkYzhmMGVhNDE3MjkwODlmOGM3OGMiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIy IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJ CTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj42NDEgNzA5IDExODwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPmpvaW5qb2luPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJS PjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2 OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEp PC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51 bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0MSA3MDkgMTE4PC9GT05UPiZuYnNw OyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0 aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9s bC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+ PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNw OzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFO VCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRp byBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVj b3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpv aW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVj b3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNz IHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48 L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOjZ0aXNjaCBzZWN1cml0eQpQUklPUklUWTo1CkNMQVNTOlBV QkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQxME0KQUNUSU9OOkRJU1BMQVkKREVTQ1JJUFRJ T046UmVtaW5kZXIKRU5EOlZBTEFSTQpFTkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIK ------=_Part_10113_1327192358.1418748676227-- From nobody Tue Dec 16 08:52:50 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7F1A6FD9 for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 08:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwJ1JwcUoVll for <6tisch-security@ietfa.amsl.com>; Tue, 16 Dec 2014 08:52:47 -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 A39221A1BEE for <6tisch-security@ietf.org>; Tue, 16 Dec 2014 08:52:46 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B121C200A1; Tue, 16 Dec 2014 11:56:51 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C2393637F5; Tue, 16 Dec 2014 11:52:45 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AF4B563740; Tue, 16 Dec 2014 11:52:45 -0500 (EST) From: Michael Richardson To: Rene Struik In-Reply-To: <54903FE0.2000306@gmail.com> References: <54862348.4020909@gmail.com> <54903FE0.2000306@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/JnvsZg6Z9pd6QVGKNffB1MloKdI Cc: tisch-security <6tisch-security@ietf.org> Subject: Re: [6tisch-security] Suggested agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom) 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, 16 Dec 2014 16:52:49 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Rene Struik wrote: > Conf call time: 5pm EST =3D 7am Japan =3D 2pm PST =3D 11pm Paris time= . {The > next call, on January 6, 2014) is also at 5pm EST (see schedule till > half of January 2015)}. > Dial-in info at end of this email. I have to tweak the webex each time, since recurring times at different tim= es don't work. I have done that. (see you at 5pm) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVJBjXYCLcPvd0N1lAQKr7QgAnhbRmLJlRHu1wM1djVHGezRHo04jowOU Txt3kNjG+CbJM+FJTbD+hhrHIVR7jkSNvg9halVJSEp4Ttz3PRcxXOpbg7uuGeSP aJGEB4fBE1nKm2t74yoLthGVm/jfcer6LID95y7dD5qDDk6MJHkKARcRsMnMn35d fiIlOpi3EyXbHsf2E45BHUMn5w4gBpNag+HXCmw+KSPpNy5BOVR1HfvJn4VvSlzA ruh+i8H4o5p3Ll/obgkAJVPrZ02gEeu+GMJaXC84s9OUPnqhuzoQFlwqC77Sg8FB 0P7fiV2c+Dkc3gkMUOaeAM9NcSXRhkRtupeiMIGzWXVX8pL6m9FW5g== =i6l6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 18 02:20:34 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6981A079A for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 02:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAeeCgCrphnG for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 02:20:30 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E241A07BE for <6tisch-security@ietf.org>; Thu, 18 Dec 2014 02:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2384; q=dns/txt; s=iport; t=1418898032; x=1420107632; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=66QTuGS54p7QMT/kqYB99mc56NmwVii9H/iRaGKAKZ4=; b=erexQ8nDe4Su1pMNefaSAAnpkhqPTdqPk4+bL0+Ahe7LB51arQ2f6D+V 5MK/GPllBo6jKvdacGwMkiye70hKxGpiIi2hgHoJH/S4nvRl0SRY3YW05 xW13b5fks3bTAculoJX6iS9xWUzolACChMATHwNr34i51200281A76/oW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAHOpklStJA2I/2dsb2JhbABXA4MGUlgEtliNH4IbCoVyAoEeFgEBAQEBfYQMAQEBBAEBAUYfAwMXBAIBCBEEAQELHQchBgsUBwEBBQMCBBMIE4d9AxENzw8NhUsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjUoKgTwRAR8LBBIPCAYLgwWBEwWEK4RvgxeBVoM+gX2BcQGCTTCCMYgBghuDOCKDbG+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,600,1413244800"; d="scan'208";a="377870515" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 18 Dec 2014 10:20:31 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBIAKTlT022039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tisch-security@ietf.org>; Thu, 18 Dec 2014 10:20:30 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 04:20:29 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [IoT-DIR] IETF 92 Bits-n-Bites Thread-Index: AQHQGiAwAIJ6RrL45U+aIGDjGwZLwpyVI4qw Date: Thu, 18 Dec 2014 10:20:29 +0000 Deferred-Delivery: Thu, 18 Dec 2014 10:20:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/kwMy_NmeJRR7-r1YvAb02RYXSRY Subject: [6tisch-security] FW: [IoT-DIR] IETF 92 Bits-n-Bites 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, 18 Dec 2014 10:20:33 -0000 -----Original Message----- From: IoT-DIR [mailto:iot-dir-bounces@ietf.org] On Behalf Of Stephanie McCa= mmon Sent: mercredi 17 d=E9cembre 2014 18:22 To: Aaron Falk; Zach Shelby; Gabriel.Montenegro@microsoft.com; denghui02@ho= tmail.com; margaretw42@gmail.com; iot-dir@ietf.org; Stephen Farrell; Kathle= en Moriarty Cc: Ray Pelletier; Alexa Morris Subject: [IoT-DIR] IETF 92 Bits-n-Bites Hello Everyone, We are gearing up for IETF 92 BnB in Dallas and one thing that needs to be = finalized is the event theme. A suggestion that has come up several times i= s the topic of security for IoT devices. This is certainly an important top= ic, and one that should generate a lot of interest, but what we don't know = - and why we are contacting all of you - is if it's viable from a demonstra= tion perspective. We need your input and expertise in order to determine if= this topic is mature enough to be the focus of an IETF BnB event. Some of = our questions are:=20 - What are the main known security issues with IoT devices? - Are there demonstrable solutions that can be featured? - What companies / organizations are working in this space and might be abl= e to showcase their technology?=20 We realize that most of you are probably working diligently to wrap up vari= ous projects in time for the holidays, and that this is therefore unlikely = to be a top priority at the moment. We understand and are are hoping to sch= edule a short conference call after the New Year, perhaps the 2nd week of J= anuary, to discuss this further. If you are interested and willing to help = out, please complete the Doodle poll below so that we can find a date and t= ime that works best for everyone.=20 http://doodle.com/8qd5xx94482mkhkq In the meantime, please feel free to chime in with your thoughts via email,= as any opinions and information you share between now and the January conf= erence call will help us with our planning.=20 Thanks and Happy Holidays! Stephanie McCammon IETF Project Manager 48377 Fremont Blvd, Ste. 117 Fremont, CA 94538 T: +1.510.492.4081 F: +1.510.492.4001 Association Management Solutions (AMS) Forum Management, Meeting, and Event Planning www.amsl.com _______________________________________________ IoT-DIR mailing list IoT-DIR@ietf.org https://www.ietf.org/mailman/listinfo/iot-dir From nobody Thu Dec 18 06:37:31 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690E71A89F1 for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 06:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS1toEgAC051 for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 06:37:26 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8CC1A8A1C for <6tisch-security@ietf.org>; Thu, 18 Dec 2014 06:37:24 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so1074049iga.2 for <6tisch-security@ietf.org>; Thu, 18 Dec 2014 06:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ECFLOScN1vRIYRS/XGp9TxnQY1r+AIUvSGBqItM5gLQ=; b=ZQKSaaF1K91/d6ItU5wAfy3s5kMlfxfEeDCEi/YIzr65Or2WagKCe9Ock5GVuUsX0G GkZ6HXl97J8wusf8nSq28OVuJxRp+rIFsvKNbWBkBVEoCUJz/8KaJYz/DraJ4DG/ylgD Q4kSaTUrE0o1l+RivyLaomumoC3IHl5x7EzBc06fqGp4rzSXOdLL9E8bMUoI/xgEMkr0 dWWDaqEz3Wb9bGw+rA2Ufphada6YWOW+J+0INSOlI//CPlAK/CCtTuzlGOFgPy38reRA ZMDKT1+k1VtdZvZOXPcguKr9AsTYq+6tbQ99BXUXKlIWhC2m+ZgnZFZQSrNDzIn7I97g 38/w== X-Received: by 10.50.28.20 with SMTP id x20mr2413983igg.27.1418913443521; Thu, 18 Dec 2014 06:37:23 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id i184sm3230327ioi.33.2014.12.18.06.37.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Dec 2014 06:37:23 -0800 (PST) Message-ID: <5492E6A2.9030001@gmail.com> Date: Thu, 18 Dec 2014 09:37:22 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/4flyyXNS40-nij6QvpjXylJcB6g Subject: Re: [6tisch-security] FW: [IoT-DIR] IETF 92 Bits-n-Bites 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, 18 Dec 2014 14:37:29 -0000 Hi Pascal: It may be somewhat early to demonstrate solutions that span the entire device lifecycle (to my knowledge, there are none, at least not ones that make this a convenient, semi-automatic matter). I do not think that 6tisch security will be in prototype demo stage by March. Nevertheless, of course, we could indicate how things are supposed to work there and borrow also from examples of how 802.15, wHART, ISA SP100 fit into the mix. This could also have a pointer to IPv6 address privacy provisions on 6man. Not sure whether this is in scope, but I could give a presentation on crypto and security technologies that together hold the promise to be a good "tool box" for addressing full lifecycle secure deployments. This includes support for semi-automatic provisioning, implementation security aspects esp. on cheap devices open to physical attacks, secure key storage and random number generation, etc. Some of this is not material that will end up with an IETF draft (but hooks would be good to have), but nevertheless helps in significantly hardening devices and networks, when viewed from a system perspective. Best regards, Rene On 12/18/2014 5:20 AM, Pascal Thubert (pthubert) wrote: > -----Original Message----- > From: IoT-DIR [mailto:iot-dir-bounces@ietf.org] On Behalf Of Stephanie McCammon > Sent: mercredi 17 décembre 2014 18:22 > To: Aaron Falk; Zach Shelby; Gabriel.Montenegro@microsoft.com; denghui02@hotmail.com; margaretw42@gmail.com; iot-dir@ietf.org; Stephen Farrell; Kathleen Moriarty > Cc: Ray Pelletier; Alexa Morris > Subject: [IoT-DIR] IETF 92 Bits-n-Bites > > > Hello Everyone, > > We are gearing up for IETF 92 BnB in Dallas and one thing that needs to be finalized is the event theme. A suggestion that has come up several times is the topic of security for IoT devices. This is certainly an important topic, and one that should generate a lot of interest, but what we don't know - and why we are contacting all of you - is if it's viable from a demonstration perspective. We need your input and expertise in order to determine if this topic is mature enough to be the focus of an IETF BnB event. Some of our questions are: > > - What are the main known security issues with IoT devices? > - Are there demonstrable solutions that can be featured? > - What companies / organizations are working in this space and might be able to showcase their technology? > > We realize that most of you are probably working diligently to wrap up various projects in time for the holidays, and that this is therefore unlikely to be a top priority at the moment. We understand and are are hoping to schedule a short conference call after the New Year, perhaps the 2nd week of January, to discuss this further. If you are interested and willing to help out, please complete the Doodle poll below so that we can find a date and time that works best for everyone. > > http://doodle.com/8qd5xx94482mkhkq > > In the meantime, please feel free to chime in with your thoughts via email, as any opinions and information you share between now and the January conference call will help us with our planning. > > Thanks and Happy Holidays! > > Stephanie McCammon > IETF Project Manager > 48377 Fremont Blvd, Ste. 117 > Fremont, CA 94538 > T: +1.510.492.4081 > F: +1.510.492.4001 > > Association Management Solutions (AMS) > Forum Management, Meeting, and Event Planning www.amsl.com > > > > > _______________________________________________ > IoT-DIR mailing list > IoT-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/iot-dir > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Dec 18 07:08:38 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B071A8A7F for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 07:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHxWzgcb8Y3R for <6tisch-security@ietfa.amsl.com>; Thu, 18 Dec 2014 07:08:32 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD52A1A1B37 for <6tisch-security@ietf.org>; Thu, 18 Dec 2014 07:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4769; q=dns/txt; s=iport; t=1418915278; x=1420124878; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cONMWls9K9ZbxNag9QWticC4e0GhrcU/nkQdhgcsS8I=; b=GxBwwMVaRmVEy99lZp286EhFZvxJ7VvGgSMGhfvS1E6J13xox+i3JwRc df52tLfHNLQWDLwq+tj8t7T9b03mQAmUIOQne2VuYePwlE3udUvNjvwWG Jobxi4xYVZPx7QRweii+2sby+kcpOCnSDbQWuBe8jY+TAWZ4MBIgwdWYE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAG/tklStJV2Z/2dsb2JhbABXA4MGUlgEtliNH4IbCoUoSgKBHBYBAQEBAX2EDAEBAQQBAQFGHwMDBhEEAgEIDgMEAQEBCh0HIQYLFAgBCAIEARIIE4d9AxENzxINhTQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjEQBgQUKgTwRAQcYCxYXBguDBYETBYQrhG+CDoJigz6BfYFxAYJQMIIxiAGCG4M4IoNsb4EECBcifgEBAQ X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="106595520" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 18 Dec 2014 15:07:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBIF7vA8021819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 15:07:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 09:07:57 -0600 From: "Pascal Thubert (pthubert)" To: Rene Struik , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] FW: [IoT-DIR] IETF 92 Bits-n-Bites Thread-Index: AQHQGiAwAIJ6RrL45U+aIGDjGwZLwpyVI4qwgACtDgD//6MUUA== Date: Thu, 18 Dec 2014 15:07:56 +0000 Deferred-Delivery: Thu, 18 Dec 2014 15:07:00 +0000 Message-ID: References: <5492E6A2.9030001@gmail.com> In-Reply-To: <5492E6A2.9030001@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/OdBD4WSCPZPIHMiRf0DY5WpGFHI Subject: Re: [6tisch-security] FW: [IoT-DIR] IETF 92 Bits-n-Bites 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, 18 Dec 2014 15:08:36 -0000 All good, Ren=E9, and I'd love to see your presentation.=20 Maybe early next year we could dedicate a 6TiSCH call to this? I did not expect 6TiSCH sec to demo at B'n'B but I wanted to make sure ever= yone on the list was aware of this, and would eventually use that informati= on. All the best, Pascal > -----Original Message----- > From: Rene Struik [mailto:rstruik.ext@gmail.com] > Sent: jeudi 18 d=E9cembre 2014 15:37 > To: Pascal Thubert (pthubert); 6tisch-security@ietf.org > Subject: Re: [6tisch-security] FW: [IoT-DIR] IETF 92 Bits-n-Bites >=20 > Hi Pascal: >=20 > It may be somewhat early to demonstrate solutions that span the entire de= vice > lifecycle (to my knowledge, there are none, at least not ones that make t= his a > convenient, semi-automatic matter). >=20 > I do not think that 6tisch security will be in prototype demo stage by Ma= rch. > Nevertheless, of course, we could indicate how things are supposed to wor= k > there and borrow also from examples of how 802.15, wHART, ISA SP100 fit i= nto > the mix. This could also have a pointer to > IPv6 address privacy provisions on 6man. >=20 > Not sure whether this is in scope, but I could give a presentation on cry= pto and > security technologies that together hold the promise to be a good "tool b= ox" for > addressing full lifecycle secure deployments. This includes support for s= emi- > automatic provisioning, implementation security aspects esp. on cheap dev= ices > open to physical attacks, secure key storage and random number generation= , > etc. Some of this is not material that will end up with an IETF draft (bu= t hooks > would be good to have), but nevertheless helps in significantly hardening= devices > and networks, when viewed from a system perspective. >=20 > Best regards, Rene >=20 >=20 > On 12/18/2014 5:20 AM, Pascal Thubert (pthubert) wrote: > > -----Original Message----- > > From: IoT-DIR [mailto:iot-dir-bounces@ietf.org] On Behalf Of Stephanie > > McCammon > > Sent: mercredi 17 d=E9cembre 2014 18:22 > > To: Aaron Falk; Zach Shelby; Gabriel.Montenegro@microsoft.com; > > denghui02@hotmail.com; margaretw42@gmail.com; iot-dir@ietf.org; > > Stephen Farrell; Kathleen Moriarty > > Cc: Ray Pelletier; Alexa Morris > > Subject: [IoT-DIR] IETF 92 Bits-n-Bites > > > > > > Hello Everyone, > > > > We are gearing up for IETF 92 BnB in Dallas and one thing that needs to= be > finalized is the event theme. A suggestion that has come up several times= is the > topic of security for IoT devices. This is certainly an important topic, = and one > that should generate a lot of interest, but what we don't know - and why = we are > contacting all of you - is if it's viable from a demonstration perspectiv= e. We need > your input and expertise in order to determine if this topic is mature en= ough to > be the focus of an IETF BnB event. Some of our questions are: > > > > - What are the main known security issues with IoT devices? > > - Are there demonstrable solutions that can be featured? > > - What companies / organizations are working in this space and might be= able > to showcase their technology? > > > > We realize that most of you are probably working diligently to wrap up = various > projects in time for the holidays, and that this is therefore unlikely to= be a top > priority at the moment. We understand and are are hoping to schedule a sh= ort > conference call after the New Year, perhaps the 2nd week of January, to d= iscuss > this further. If you are interested and willing to help out, please compl= ete the > Doodle poll below so that we can find a date and time that works best for > everyone. > > > > http://doodle.com/8qd5xx94482mkhkq > > > > In the meantime, please feel free to chime in with your thoughts via em= ail, as > any opinions and information you share between now and the January > conference call will help us with our planning. > > > > Thanks and Happy Holidays! > > > > Stephanie McCammon > > IETF Project Manager > > 48377 Fremont Blvd, Ste. 117 > > Fremont, CA 94538 > > T: +1.510.492.4081 > > F: +1.510.492.4001 > > > > Association Management Solutions (AMS) Forum Management, Meeting, and > > Event Planning www.amsl.com > > > > > > > > > > _______________________________________________ > > IoT-DIR mailing list > > IoT-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/iot-dir > > > > _______________________________________________ > > 6tisch-security mailing list > > 6tisch-security@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch-security >=20 >=20 > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Dec 19 03:48:53 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5231A6EE0 for <6tisch-security@ietfa.amsl.com>; Fri, 19 Dec 2014 03:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lkSC-QoSbpj for <6tisch-security@ietfa.amsl.com>; Fri, 19 Dec 2014 03:48:48 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c: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 747C21A8ADA for <6tisch-security@ietf.org>; Fri, 19 Dec 2014 03:48:48 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so1100599wgg.10 for <6tisch-security@ietf.org>; Fri, 19 Dec 2014 03:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=G9A2FvQ4rUBX3fk7ayg8FD7BQ3sO0SyJ+YvenF8upX4=; b=c4ZtKDCimqHxkVrcv1EY7ijVP4P+HxHMCvEwMzeea1FnaXvmVpqVBZH+KvQTSpwnL4 IOxCNDz4dMnxFELIoCG4Yp4WQS+p4Bqf98rNl3IzLA24QA1VlgOeKoNlU4awVloN0waV MXPHlvMJw+nZYW9ZjwdMy5bGCJFJI/nQKwUVfk/9OR2LTXFVHUm73z1P3NfHU9ouAL6U r5Xe744HcTQVVNllJ1mrJL2Xv73kjurHUiExQP+gEE0jK9staxVAKozBnhq3MobapiMC kv8LfOfDoVai7tJBJDXjJVwZd8EGDaKNz+arS+sQR1CACRmbqHmt3r3esIWFMEYQuc8t aLHg== X-Received: by 10.180.198.164 with SMTP id jd4mr5022019wic.42.1418989727052; Fri, 19 Dec 2014 03:48:47 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.68.199 with HTTP; Fri, 19 Dec 2014 03:48:26 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 19 Dec 2014 12:48:26 +0100 X-Google-Sender-Auth: I9AZKz1NcUQCvE4Ucv6GKc9tFww Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7b6047069efb70050a904a45 Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/jCPC4EvZHyjUArzgf9cfzBMI29s Cc: Michael Richardson , Rene Struik , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] Proposed text for archie 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, 19 Dec 2014 11:48:51 -0000 --047d7b6047069efb70050a904a45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pascal, How does this compare (both in contents and purpose) to the text sent out by Michael in http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html? Supersedes? Side-by-side? Different purpose? Thanks, Thomas On Tue, Dec 9, 2014 at 5:37 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > > Dear all: > > > > Please find my summary of our recent discussions with the sort of level I > would expect for the archi spec at this stage. > > > > =E2=80=9C > > > > The join process is the process by which a node, virtually out of the box= , > will discover a network, get authenticated and authorized in the network, > obtain credentials to participate to the network, and obatin reachability > through the network. > > > > The architecture specifies 3 logical elements to describe the join proces= s: > > - a Joining Node (JN), that is yet not authenticated to participate to th= e > network, > > - a Join Assistant (JA), that is already participating to the network, an= d > is reachable over the network > > - a Join Coordination Entity, that is the front end for authentication an= d > authorization for the JA. > > > > The text below makes a difference between a join IPv6 link and other IPv6 > links in the production network. With 6TiSCH, an IPv6 link is associated = in > each node with a particular bundle of cells for multicast transmissions. > The production network can be a multilink subnet of such IPv6 links. In > some networks, the join process may happen on that bundle, using the > production prefix, but this exposes production information and may not be > desirable. In a more secure mode, a separate IPv6 link, and associated > bundle is defined in each individual JA. A particular ULA prefix t is > locally assigned by the JA for use in that IPv6 link and is not exposed t= o > the routing fabric in the production network. The ULA prefix uniquely > indicates the particular join link on which it is exposed. > > > > > > At the beginning of times, the JA exposes a joining set of information in > a beacon. This information includes link information for the bundle that > can be used to join (schedule IE=E2=80=A6) and routing information (RA me= ssage). > The JN scans the network till it gets such message. The message is signed > and may be encrypted with a well-known key, but for all practical purpose > it is considered in the clear. The prefix in the RA exposes the ULA prefi= x > when that mode is used, as opposed to the production prefix. > > > > Upon reception of the beacon, the JN forms an address from the prefix in > the RA. This address is not injected in the routing fabric, and no state = is > formed in the network for that particular address. The JN contacts the JA > to join the network using that address, and the JA relays the request to > the JCE by encapsulating it in a JA-to-JCE message. At this stage, a DoS > attack by a rogue JN can only be local to the JA. The JA may throttle joi= n > requests or perform additional checks to defeat such attacks. The size of > the join bundle for that particular JA is another constraint that limits > DoS attack. The JN may store an ND cache mapping the ULA address of the J= N > with the MAC address of the JN, but it does not need to. > > > > Upon reception of the join request from the JA, the JCE stores the reques= t > to be processed asynchronously or dropped. When the JCE decides to respon= d, > it contacts the JN directly and establishes an end-to-end JCE-to-JN DTLS > connection. At that point of time, the JA can reach the JN=E2=80=99s addr= ess over > the join bundle, but the JN address is not advertised over the routing > fabric, so it cannot be reached directly from the JCE. To reach the JN, t= he > JCE sets the destination address in the IP packet as the JA, and inserts = a > RH type 2 indicating the address of the JN, which only the JA can route t= o. > The JA receives the packet, processes the RH2. The prefix (e.g. a ULA) > indicates which IPv6 link (which bundle) can be used to reach the JN. The > JA resolves the MAC address of the JN (either using an NS/NA exchange or > implicitly if the IID is based on MAC-64), and forwards the packet to the > JN. > > > > When the exchange between the JN and the JCE is completed, the JN owns a > network key that it can use in the production network. The JN contacts th= e > JA again using an encrypted RS message. The JA responds with an encrypted > RA message with information on the production network. The relevant IEs a= re > passed with the RA message so the JN may now form an address in the > production network. At that point, the JN uses efficient ND to validate i= ts > address, and the 6LR =E2=80=93typically but not necessarily the JA) injec= ts that > address in the LLN using RPL, as discussed earlier in the architecture. > > > > =E2=80=9C > > > > Does this reflect a common consensus? > > > > Pascal > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7b6047069efb70050a904a45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pascal,

How does this compare (both in = contents and purpose) to the text sent out by Michael in=C2=A0http://www= .ietf.org/mail-archive/web/6tisch/current/msg02690.html?

=
Supersedes? Side-by-side? Different purpose?

Thanks,
Thomas

On Tue, Dec 9, 2014 at 5:37 PM, Pascal Thubert (pt= hubert) <pthubert@cisco.com> wrote:

Dear all:

=C2=A0

Please find my summary of our recent discussions wit= h the sort of level I would expect for the archi spec at this stage.=

=C2=A0

=E2=80=9C

=C2=A0

The join process is the process by which a node, vir= tually out of the box, will discover a network, get authenticated and autho= rized in the network, obtain credentials to participate to the network, and= obatin reachability through the network.

=C2=A0

The architecture specifies 3 logical elements to des= cribe the join process:

- a Joining Node (JN), that is yet not authenticated= to participate to the network, =C2=A0

- a Join Assistant (JA), that is already participati= ng to the network, and is reachable over the network

- a Join Coordination Entity, that is the front end = for authentication and authorization for the JA.

=C2=A0

The text below makes a difference between a join IPv= 6 link and other IPv6 links in the production network. With 6TiSCH, an IPv6= link is associated in each node with a particular bundle of cells for mult= icast transmissions. The production network can be a multilink subnet of such IPv6 links. In some networks, th= e join process may happen on that bundle, using the production prefix, but = this exposes production information and may not be desirable. In a more sec= ure mode, a separate IPv6 link, and associated bundle is defined in each individual JA. A particular ULA p= refix t is locally assigned by the JA for use in that IPv6 link and is not = exposed to the routing fabric in the production network. The ULA prefix uni= quely indicates the particular join link on which it is exposed.

=C2=A0

=C2=A0

At the beginning of times, the JA exposes a joining = set of information in a beacon. This information includes link information = for the bundle that can be used to join (schedule IE=E2=80=A6) and routing = information (RA message). The JN scans the network till it gets such message. The message is signed and may be encryp= ted with a well-known key, but for all practical purpose it is considered i= n the clear. The prefix in the RA exposes the ULA prefix when that mode is = used, as opposed to the production prefix.

=C2=A0

Upon reception of the beacon, the JN forms an addres= s from the prefix in the RA. This address is not injected in the routing fa= bric, and no state is formed in the network for that particular address. Th= e JN contacts the JA to join the network using that address, and the JA relays the request to the JCE by encapsulat= ing it in a JA-to-JCE message. At this stage, a DoS attack by a rogue JN ca= n only be local to the JA. The JA may throttle join requests or perform add= itional checks to defeat such attacks. The size of the join bundle for that particular JA is another constraint t= hat limits DoS attack. The JN may store an ND cache mapping the ULA address= of the JN with the MAC address of the JN, but it does not need to.<= u>

=C2=A0

Upon reception of the join request from the JA, the = JCE stores the request to be processed asynchronously or dropped. When the = JCE decides to respond, it contacts the JN directly and establishes an end-= to-end JCE-to-JN DTLS connection. At that point of time, the JA can reach the JN=E2=80=99s address over the = join bundle, but the JN address is not advertised over the routing fabric, = so it cannot be reached directly from the JCE. To reach the JN, the JCE set= s the destination address in the IP packet as the JA, and inserts a RH type 2 indicating the address of the JN, which= only the JA can route to. The JA receives the packet, processes the RH2. T= he prefix (e.g. a ULA) indicates which IPv6 link (which bundle) can be used= to reach the JN. The JA resolves the MAC address of the JN (either using an NS/NA exchange or implicitly if= the IID is based on MAC-64), and forwards the packet to the JN.<= /u>

=C2=A0

When the exchange between the JN and the JCE is comp= leted, the JN owns a network key that it can use in the production network.= The JN contacts the JA again using an encrypted RS message. The JA respond= s with an encrypted RA message with information on the production network. The relevant IEs are passed with th= e RA message so the JN may now form an address in the production network. A= t that point, the JN uses efficient ND to validate its address, and the 6LR= =E2=80=93typically but not necessarily the JA) injects that address in the LLN using RPL, as discussed earlier in= the architecture.

=C2=A0

=E2=80=9C

=C2=A0

Does this reflect a common consensus?

=C2=A0

Pascal


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

--047d7b6047069efb70050a904a45-- From nobody Fri Dec 19 04:48:31 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538BF1A8AD1 for <6tisch-security@ietfa.amsl.com>; Fri, 19 Dec 2014 04:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU3SoStb8QfX for <6tisch-security@ietfa.amsl.com>; Fri, 19 Dec 2014 04:48:25 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3E11A8755 for <6tisch-security@ietf.org>; Fri, 19 Dec 2014 04:48:24 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so1647843wid.12 for <6tisch-security@ietf.org>; Fri, 19 Dec 2014 04:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SrBWp0wmR3x2yDQwfWDdYc1HUcjt1qmcipRhXR9+jrk=; b=JMfezWwwIPiBACqi84ooNdkdUHopd6kuenE+zUHfTEsoa4RCegnvE9NYloNeEwsF/m KpxCfnTU+N91htj9tljqD70IS4474s+l5i4eatKz0HQu5WTQOUZXFVsHpg0OkoncYCNt qJPQAVM8agkcHc4Jzyt0Q9Vmib4TzkNyS4NuGb15Y32YlflZDeZtPTuXsLJEwu6x0vzy nm7pL/PnZiqsaOO2+Xeke89pKbSUo6BE4AK5YwNJdUj1arEPK29XzzUEQKSgTj+abIV6 A6IMiYfHLZtmUG5+4hL0+rPFeLrau4SNTlG589c4UwDQvXPqCP4oMMM6PvHnsTkZPHvM y35g== X-Received: by 10.194.93.5 with SMTP id cq5mr14013711wjb.84.1418993303604; Fri, 19 Dec 2014 04:48:23 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.68.199 with HTTP; Fri, 19 Dec 2014 04:48:03 -0800 (PST) In-Reply-To: <54862F96.5040508@gmail.com> References: <316.1416522601@sandelman.ca> <16128.1417135503@sandelman.ca> <1758.1417189169@sandelman.ca> <54789C85.1080505@gmail.com> <547C9D91.4010400@gmail.com> <54862F96.5040508@gmail.com> From: Thomas Watteyne Date: Fri, 19 Dec 2014 13:48:03 +0100 X-Google-Sender-Auth: Ed3priRogeaqoUukDEUiJAwSlZo Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=047d7bb04da6ccd651050a911ffe Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/oSxeJ4ME7shq316G81BN7bmUz5w Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 12:48:28 -0000 --047d7bb04da6ccd651050a911ffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rene, FYI, I have archived those minutes at https://bitbucket.org/6tisch/meetings/wiki/141202a_webex_security. All, Note that all minutes, attendance, recordings and meeting material is archived at https://bitbucket.org/6tisch/meetings/. Please speak up if you see something is missing. Thomas On Tue, Dec 9, 2014 at 12:09 AM, Rene Struik wrote: > > Dear colleagues: > > Please find below the minutes of the 6TiSCH Security conf call as of > December 2, 2014, 9am EST. > > Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST > {note taker: Rene Struik} > {recording: > https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=3Ds= haring > } > {slides discussed (and referenced in minutes): > https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=3Ds= haring > } > > 1. Attendance: > Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik > > 2. Agenda > The suggested agend was approved. > > 3. Join process - desirable vs. realizable properties > RS went over the desirable properties of the join process (Slide 6). MR > raised point that privacy of the device identity of the joining node migh= t > not be required. . SD suggested that it is fine to include privacy in lis= t > of "desiderata"; evaluation metrics might consider these in "grey tones" > vs. as "black and white" requirement. RS suggested that merit of privacy > might depend on deployment scenario, but is on the radar in lots of IETF > groups (in terms of traceability/tracking); if privacy can be easily > offered as additional feature, this would be a plus. After asking, there > was no further discussion on properties listed. > > 4. Join process - MAC behavior. > RS went over some MAC security aspects of the 802.15.4-2011 and > 802.15.4e-2012 specifications (Slides 19-22). The main premise here was > that a recipient device that expects secured traffic, will reject all > incoming unsecured traffic, unless this originates from a device with > so-called "exempt status". This "exempt status" construct allows receipt = of > incoming unsecured data frames from a joining node that does not have > network-specific keying material yet. How to switch on/off this "exempt > status" parameter was also discussed (see Slide 20). Furthermore, there w= as > some discussion on how this compares to the use of so-called "default key= s" > (aka "fake" keys) (see also Slide 22). > > PG mentioned that 802.15.4 does not allow the use of the default key. SD > suggested that an important point in not using default keys is that all > incoming processing with keys will be treated transparently, irrespective > of exceptions. RS explained that even if default keys were to be used, th= is > would mess up local security state (e.g., frame counters), which is not t= he > case if one would send unsecured traffic and use the "exempt status" > construct instead. PD summarized that using unsecured frames, rather than > "fake" security with "default keys", should be adopted, which was consens= us > on the call. > > PG came back to the "exempt flag" topic and suggested that details hereof > are in the "device descriptor lookup table". RS suggested that we all hav= e > a closer look at specification details, so that switching this feature > on/off could be easily codified for 6TiSCH use. > > 5. Join process - non-MAC behavior. > Given remaining time on the call would not allow full discussion of > non-MAC aspects (Slides 23-25) and given that MR had to drop off the call= , > it was decided to revisit those topics at the next conf call. > > 6. AOB Conf call scheduling. > SD suggested he was confused about having two call times in email traffic > (one at 9am EST and one at 11am EST) and suggested that other groups, suc= h > as, e.g., IEEE, often use cyclic schedule, so as to accommodate > participants from around the world and who may be at widely different tim= e > zones. RS volunteered to look into this topic and obtain feedback on such= a > schedule. > > Best regards, Rene > > On 12/1/2014 11:55 AM, Rene Struik wrote: > > Proposed agenda: > > 0) Agenda bashing > > 1) Join protocol details > > a) desired properties > b) realizable properties > > 2) Next steps: > a) consensus on 1#a and 1#b > b) form tiger team to work out details > - project phases > - communication of sub-results > c) what to squeeze into architecture draft, etc. > > I will prepare material to facilitate discussion on 1) and 2), to be > discussed during the call. > > Best regards, Rene > > > On 11/28/2014 11:02 AM, Rene Struik wrote: > > Dear colleagues: > > > I have set up a conf call for Tuesday December 2, 2014 at a time that > tries and accommodate people in different time zones to the largest exten= t > possible, without trying to discriminate against various parts of the wor= ld. > > > Please see dial-in information below. > > > Agenda to follow Monday around noon. > > > Looking forward to a collaborative meeting, in good spirit. > > > Best regards, Rene > > =3D=3D > > > 1. Please join my meeting. > > https://global.gotomeeting.com/join/594299061 > > > > 2. Use your microphone and speakers (VoIP) - a headset is recommended. = Or, > call in using your telephone. > > > > Dial +1 (647) 497-9351 > > Access Code: 594-299-061 > > Audio PIN: Shown after joining the meeting > > > > Meeting Password: collaborate > > Meeting ID: 594-299-061 > > > > GoToMeeting=C2=AE > > Online Meetings Made Easy=C2=AE > > > > Not at your computer? Click the link to join this meeting from your > iPhone=C2=AE, iPad=C2=AE, Android=C2=AE or Windows Phone=C2=AE device via= the GoToMeeting app. > > > > [excerpt email as of Thu November 27, 2014, 9.42pm EST] > I suggest 9am EST =3D 6am PST =3D 3pm Paris =3D 11pm Japan. This should a= llow > people to have their private time in the 12am-6am time window. {Other > groups do a much better job at this...} > > > On 11/28/2014 10:39 AM, Michael Richardson wrote: > > Subir Das wrote: > > Thanks for arranging the calls. It would be good to accommodate Asi= an time > > zone for broader participation. I would suggest choosing a time tha= t is > > I'm happy to do this at another time; the original choice of 11am Eastern= was > to accomodate Pacific Time Zone People who couldn't meet before 8am. > > >From long experience, our choices essentially are at 15:00 UTC or 03:00 = UTC. > 07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing > or > 19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing > > I am also happy to alternate. > Shall I put up a doodle poll? > > > > > _______________________________________________ > 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/= mailman/listinfo/6tisch-security > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security > > --047d7bb04da6ccd651050a911ffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rene,<= div>
All,
Note that all minutes, attendance, record= ings and meeting material is archived at https://bitbucket.org/6tisch/meetings/. Please speak u= p if you see something is missing.

Thomas

On Tue, Dec 9,= 2014 at 12:09 AM, Rene Struik <rstruik.ext@gmail.com> w= rote:
=20 =20 =20
Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of December 2, 2014, 9am EST.

Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
{note taker: Rene Struik}
{recording: https://drive.google.com/file/d/0B2a6Ilx= u1XfCUmU4RWFfb1FJSHc/view?usp=3Dsharing}
{slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilx= u1XfCZnZzdlQ5V1hkNEk/view?usp=3Dsharing}

1. Attendance:
Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik

2. Agenda
The suggested agend was approved.

3. Join process - desirable vs. realizable properties
RS went over the desirable properties of the join process (Slide 6). MR raised point that privacy of the device identity of the joining node might not be required. . SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metr= ics might consider these in "grey tones" vs. as "black and= white" requirement. RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this=C2=A0 would be a plus. After asking, there was no further discussion on properties listed.

4. Join process - MAC behavior.
RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "ex= empt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet. How to switch on/off this "exempt status" parameter wa= s also discussed (see Slide 20). Furthermore, there was some discussion on how this compares to the use of so-called "default keys"= (aka "fake" keys) (see also Slide 22).

PG mentioned that 802.15.4 does not allow the use of the default key. SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions. RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construc= t instead. PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be ad= opted, which was consensus on the call.

PG came back to the "exempt flag" topic and suggested that = details hereof are in the "device descriptor lookup table". RS sugg= ested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

5. Join process - non-MAC behavior.
Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

6. AOB Conf call scheduling.
SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones. RS volunteered to look into this topic and obtain feedback on such a schedule.

Best regards, Rene

On 12/1/2014 11:55 AM, Rene Struik wrote:
=20
Proposed agenda:

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 a) consensus on 1#a and 1#b =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b) form tiger team to wo= rk out details
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - project = phases
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - communic= ation of sub-results
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 c) what to squeeze into archi= tecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be discussed during the call.

Best regards, Rene


On 11/28/2014 11:02 AM, Rene Struik wrote:
=20
=20

Dear colleagues:


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


Please see dial-in information below.


Agenda to follow Monday around noon.


Looking forward to a collaborative meeting, in good spirit.


Best regards, Rene

=3D=3D=


1.=C2=A0 Please join my meeting.

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

=C2=A0

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

=C2=A0

Dial +1 (647) 497-9351

Access Code: 594-299-061

Audio PIN: Shown after joining the meeting

=C2=A0

Meetin= g Password: collaborate

Meetin= g ID: 594-299-061

=C2=A0

GoToMe= eting=C2=AE

Online Meetings Made Easy=C2=AE

=C2=A0

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

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


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


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

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

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

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




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



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



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



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

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

--047d7bb04da6ccd651050a911ffe-- From nobody Sun Dec 21 12:42:39 2014 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2A1A87C7; Sun, 21 Dec 2014 12:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2go63_KJQEX5; Sun, 21 Dec 2014 12:42:36 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353A21A87C1; Sun, 21 Dec 2014 12:42:36 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so5326418wgh.31; Sun, 21 Dec 2014 12:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=yJUiz32cjhbSf1s2o8oRDsZfhTbczYyUW6y/4Kk9P08=; b=IlfXiTE2G7A6QiAfima+HgRZj0NKaKlY138t/T/nQIOqj+dUNlkgDZ0NS/Ly0LmzIC fC3T1EUkSCoN8ImAlAGXK6CoNLg5l6U9hjQZhA6QpGjksQdmyZpcUYTfK6+1NmBpTEKU j5VnHl8u85KvoYmHaA1NovxEZEBGVnTJwBpZwNB1mNLA0AbSc5knqLmuVote0HeLirrt rrYUkf0+RCBNLyZTOxkB1zqsjVHX5HvzxQPjGmYvLLd9NkNZ79Q/xeKYvSL26zMeKVE1 RduZrthPRNoer4eNG3XbEWTZW7rk97R5yLOSwqiVDExQCfoy+NQtETV0z9EEfzdEHwzQ eL3w== X-Received: by 10.194.19.4 with SMTP id a4mr34736127wje.3.1419194555002; Sun, 21 Dec 2014 12:42:35 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.194.68.199 with HTTP; Sun, 21 Dec 2014 12:42:14 -0800 (PST) From: Thomas Watteyne Date: Sun, 21 Dec 2014 21:42:14 +0100 X-Google-Sender-Auth: KkYyBwdiC6niibKBE2dA1aajjrk Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org> Content-Type: multipart/alternative; boundary=047d7b5d619451774b050abffb7a Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/UAUsfBsyOhPeffIF7945F8VQfiQ Subject: [6tisch-security] FYI: no 6TiSCH-security calls in next two weeks X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 20:42:37 -0000 --047d7b5d619451774b050abffb7a Content-Type: text/plain; charset=UTF-8 All, Per http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00315.html, please note that there will NOT be any 6TiSCH-security calles in the next 2 weeks. Weekly 6TiSCH-security calls will resume on *6 January 2015*. Thomas --047d7b5d619451774b050abffb7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Per=C2=A0http://www.ie= tf.org/mail-archive/web/6tisch-security/current/msg00315.html, please n= ote that there will NOT be any 6TiSCH-security calles in the next 2 weeks.<= /div>

Weekly 6TiSCH-security calls will resume on 6 J= anuary 2015.

Thomas
--047d7b5d619451774b050abffb7a--