From nobody Thu Dec 1 04:48:56 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24738129430 for <6tisch-security@ietfa.amsl.com>; Thu, 1 Dec 2016 04:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TshdpPkUjVJg for <6tisch-security@ietfa.amsl.com>; Thu, 1 Dec 2016 04:48:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 102AC12969B for <6tisch-security@ietf.org>; Thu, 1 Dec 2016 04:48:52 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uB1Cmnwu019578 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <6tisch-security@ietf.org>; Thu, 1 Dec 2016 14:48:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB1CmnQf022166; Thu, 1 Dec 2016 14:48:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22592.7216.968126.340725@fireball.acr.fi> Date: Thu, 1 Dec 2016 14:48:48 +0200 From: Tero Kivinen To: <6tisch-security@ietf.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 28 min Archived-At: Subject: [6tisch-security] Short address assignment, nonces, and TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 12:48:55 -0000 During the teleconf I pointed out about the issues with the short address assignments and security. This email provides background information and explains the situation bit more. In all of this discussions I assume we are using IEEE Std. 802.15.4-2015 security. When not using TSCH the nonce is generated using Source address + Frame counter and security level. As Frame counter is separate for each device, that means that only thing that makes sure the nonces are different is the Source address. Because of this the Source address must be extended address, as short addresses are only unique during certain time, not globally. When using TSCH the situation is bit different as Frame counter is replaced with network global ASN. This means that Source address part needs to be unique for that timeslot. This means that coordinator assigining the short address must make sure that same short address is not given to multiple nodes at the same time, but it can give short address to node A, and when it is sure that node A does not use the short address anymore, it can give the same short address to node B. This means it can reuse the short addresses and it will not run out of short addresses unless it has more than 65k nodes in network. Now, if the short address assinged to the node A does not have any timeframe how long it is valid, the coordinator does not know when the node A stops using the short address, thus it cannot reuse the address. It cannot assume that all nodes will contact it before going away and send release for the address lease, so it must use some other mechanism to guarantee that. Easiest way would be to send the lifetime along the short address. As we do have global time in the network (ASN), we can use that as a global time frame, so the coordinator can send node A a short address of 0x1234, and say that node A is allowed to use it until ASN 0x12345678a0. After that ASN is reached the node A would need to contact coordinator again to renew the short address lease (or most likely it would contact bit earlier and renew the lease so it gets the same address again). This is explained in the IEEE Std. 802.15.4-2015 section 9.3.2.2: ---------------------------------------------------------------------- 9.3.2.2 CCM* nonce for TSCH mode =09When TSCH mode is enabled, the nonce shall be formatted as =09shown in Figure 9-2. =09 +----------------+--------+ =09 | Octets: 8 | 5 | =09 +----------------+--------+ =09 | Source Address | ASN | =09 +----------------+--------+ =09 Figure 9-2=E2=80=94CCM* nonce in TSCH mode =09The Source Address shall either be set to the extended address =09of the device originating the frame or shall be formatted as =09illustrated in Figure 9-3. =09 +-----------------+------+--------+---------------+ =09 | Octets: 3 | 1 | 2 | 2 | =09 +-----------------+------+--------+---------------+ =09 | IEEE 802.15 CID | 0x00 | PAN ID | Short address | =09 +-----------------+------+--------+---------------+ Figure 9-3=E2=80=94Source Address field for TSCH mode with short a= ddressing =09The IEEE 802.15 CID field contains the CID for IEEE 802.15. =09 =09The PAN ID field contains the PAN ID. =09 =09The Short Address field contains the short address of the =09device originating the frame. =09 =09NOTE=E2=80=94When using short addresses in the nonce, it is importan= t =09that the coordinator assign unique short addresses. =09 =09The ASN shall be set to the ASN of the timeslot during which =09the frame is sent. ---------------------------------------------------------------------- PAN ID is added, as large networks might use multiple PANs, but still use same secret key (it does not matter whether the ASNs are in sync or not). --=20 kivinen@iki.fi From nobody Fri Dec 2 02:07:16 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EE7129BC0 for <6tisch-security@ietfa.amsl.com>; Fri, 2 Dec 2016 02:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M0iyUCJBnoo for <6tisch-security@ietfa.amsl.com>; Fri, 2 Dec 2016 02:07:11 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43ADA129BB5 for <6tisch-security@ietf.org>; Fri, 2 Dec 2016 02:07:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,729,1477954800"; d="scan'208";a="202584372" Received: from unknown (HELO [128.93.84.195]) ([128.93.84.195]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2016 11:07:09 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <22592.7216.968126.340725@fireball.acr.fi> Date: Fri, 2 Dec 2016 11:07:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <163CC403-7DDC-4895-A2EA-A8C1D8396B5F@inria.fr> References: <22592.7216.968126.340725@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] Short address assignment, nonces, and TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 10:07:14 -0000 Thanks, Tero, for this summary email. Before adding the lease time to = the join response, I would like to make sure that the problem you = describe cannot be solved by simply avoiding to reuse the address. 65K = should give more than enough space for the coordinator not to have to = reuse the address it had once assigned. Then, the question becomes = whether we need a mechanism to detect nodes that are no longer present = in the network. In case we use the lease time as you propose, to have = such a mechanism useful, we would need to set it to a fairly small value = (24h or less), but then we require the whole network to =E2=80=98rejoin=E2= =80=99 in the same time frame, which is quite an overhead. I am thinking = whether we could achieve the same functionality by having neighboring = nodes report to JCE that a node left the network upon the removal from = the neighbor table. What do you think? Mali=C5=A1a > On 01 Dec 2016, at 13:48, Tero Kivinen wrote: >=20 > During the teleconf I pointed out about the issues with the short > address assignments and security. This email provides background > information and explains the situation bit more. >=20 > In all of this discussions I assume we are using IEEE Std. > 802.15.4-2015 security. >=20 > When not using TSCH the nonce is generated using Source address + > Frame counter and security level. As Frame counter is separate for > each device, that means that only thing that makes sure the nonces are > different is the Source address. Because of this the Source address > must be extended address, as short addresses are only unique during > certain time, not globally. >=20 > When using TSCH the situation is bit different as Frame counter is > replaced with network global ASN. This means that Source address part > needs to be unique for that timeslot. This means that coordinator > assigining the short address must make sure that same short address is > not given to multiple nodes at the same time, but it can give short > address to node A, and when it is sure that node A does not use the > short address anymore, it can give the same short address to node B. > This means it can reuse the short addresses and it will not run out of > short addresses unless it has more than 65k nodes in network. >=20 > Now, if the short address assinged to the node A does not have any > timeframe how long it is valid, the coordinator does not know when the > node A stops using the short address, thus it cannot reuse the > address. It cannot assume that all nodes will contact it before going > away and send release for the address lease, so it must use some other > mechanism to guarantee that. >=20 > Easiest way would be to send the lifetime along the short address. As > we do have global time in the network (ASN), we can use that as a > global time frame, so the coordinator can send node A a short address > of 0x1234, and say that node A is allowed to use it until ASN > 0x12345678a0. After that ASN is reached the node A would need to > contact coordinator again to renew the short address lease (or most > likely it would contact bit earlier and renew the lease so it gets the > same address again). >=20 > This is explained in the IEEE Std. 802.15.4-2015 section 9.3.2.2: > ---------------------------------------------------------------------- > 9.3.2.2 CCM* nonce for TSCH mode >=20 > When TSCH mode is enabled, the nonce shall be formatted as > shown in Figure 9-2. >=20 > +----------------+--------+ > | Octets: 8 | 5 | > +----------------+--------+ > | Source Address | ASN | > +----------------+--------+ > Figure 9-2=E2=80=94CCM* nonce in TSCH mode >=20 > The Source Address shall either be set to the extended address > of the device originating the frame or shall be formatted as > illustrated in Figure 9-3. >=20 > +-----------------+------+--------+---------------+ > | Octets: 3 | 1 | 2 | 2 | > +-----------------+------+--------+---------------+ > | IEEE 802.15 CID | 0x00 | PAN ID | Short address | > +-----------------+------+--------+---------------+ > Figure 9-3=E2=80=94Source Address field for TSCH mode with short = addressing >=20 > The IEEE 802.15 CID field contains the CID for IEEE 802.15. > =09 > The PAN ID field contains the PAN ID. > =09 > The Short Address field contains the short address of the > device originating the frame. > =09 > NOTE=E2=80=94When using short addresses in the nonce, it is = important > that the coordinator assign unique short addresses. > =09 > The ASN shall be set to the ASN of the timeslot during which > the frame is sent. > ---------------------------------------------------------------------- > PAN ID is added, as large networks might use multiple PANs, but still > use same secret key (it does not matter whether the ASNs are in sync > or not). > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Fri Dec 2 05:56:50 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D453D1296C8 for <6tisch-security@ietfa.amsl.com>; Fri, 2 Dec 2016 05:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRpxBq4RhOH3 for <6tisch-security@ietfa.amsl.com>; Fri, 2 Dec 2016 05:56:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8D0711296BF for <6tisch-security@ietf.org>; Fri, 2 Dec 2016 05:56:33 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uB2DuTnf014677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 15:56:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB2DuTaQ000061; Fri, 2 Dec 2016 15:56:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22593.32141.375714.870333@fireball.acr.fi> Date: Fri, 2 Dec 2016 15:56:29 +0200 From: Tero Kivinen To: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <163CC403-7DDC-4895-A2EA-A8C1D8396B5F@inria.fr> References: <22592.7216.968126.340725@fireball.acr.fi> <163CC403-7DDC-4895-A2EA-A8C1D8396B5F@inria.fr> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min Archived-At: Cc: 6tisch-security@ietf.org Subject: Re: [6tisch-security] Short address assignment, nonces, and TSCH X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 13:56:39 -0000 Mali=C5=A1a Vu=C4=8Dini=C4=87 writes: > Thanks, Tero, for this summary email. Before adding the lease time > to the join response, I would like to make sure that the problem you > describe cannot be solved by simply avoiding to reuse the address. > 65K should give more than enough space for the coordinator not to > have to reuse the address it had once assigned. If you have network which is static and where there is no mobile nodes joining, then perhaps. On the other hand you still need to implement some mechanism to cope the situation someone manages to use all addresses. I.e., what will the coordinator do when it do run out of address (lets say because someone managed to make attack that consumed addresses). Only thing it can really do is to tear down the whole network and rebuild it from the scratch using different keys, i.e., start the bootstrap from the beginning again. On the other hand lots of devices might be such that they do not allow running the bootstrap procedure second time unless some manual intervention is needed (press reset button, power down the device etc). Rekeying the K2 would also work, but that means that every single node still needs to talk to the JCE separately, and reallocate the short address again. > Then, the question becomes whether we need a mechanism to detect > nodes that are no longer present in the network. In case we use the > lease time as you propose, to have such a mechanism useful, we would > need to set it to a fairly small value (24h or less), Why=3F The only reason for the lease time is to allow JCE to clean up unused short addresses, and as there is 65k of them, it could be also much longer time, lets say a year or so. If the JCE ever starts running out of addresses (i.e., more than half of the address space is in use), it can shorten the lifetime to a day or so for new devices. As far as I have understood the networks are supposed to be up and running for years, thus having life time of one year etc is not an issue. On the other hand TSCH nodes, are required to keep constant communication with their timekeeping neighbors (i.e., send packet every few minutes), thus the extra power consumption used for renewal of the address every day or so is negligible.=20 > but then we require the whole network to =E2=80=98rejoin=E2=80=99 in = the same time > frame, which is quite an overhead. I am thinking whether we could > achieve the same functionality by having neighboring nodes report to > JCE that a node left the network upon the removal from the neighbor > table. What do you think=3F JCE could of course also use the routing table to find out which nodes are still in the network, but that requires whole routing table to be known to the JCE (I am not familiar with the routing protocol used, so I do not know whether it is true or not). On the other hand having lease time for address is standard thing we have used to solve this issue, and I think it works fine here too. Anyways we are going to need some kind of renewal method, i.e., where node comes back to JCE and says he wants to use same address he had before. This is needed if the node is temperarely disconnect from the network, and when he rejoins the network he needs to go back to the JCE and verify his address is not given out to anybody else while he was away. So as this mechanism is needed regardless whether we have lease time or not if want to cope with JCE reusing addresses, then requiring nodes to do it periodically based on the lease time is not really big overhead.=20 > Mali=C5=A1a >=20 > > On 01 Dec 2016, at 13:48, Tero Kivinen wrote: > >=20 > > During the teleconf I pointed out about the issues with the short > > address assignments and security. This email provides background > > information and explains the situation bit more. > >=20 > > In all of this discussions I assume we are using IEEE Std. > > 802.15.4-2015 security. > >=20 > > When not using TSCH the nonce is generated using Source address + > > Frame counter and security level. As Frame counter is separate for > > each device, that means that only thing that makes sure the nonces = are > > different is the Source address. Because of this the Source address= > > must be extended address, as short addresses are only unique during= > > certain time, not globally. > >=20 > > When using TSCH the situation is bit different as Frame counter is > > replaced with network global ASN. This means that Source address pa= rt > > needs to be unique for that timeslot. This means that coordinator > > assigining the short address must make sure that same short address= is > > not given to multiple nodes at the same time, but it can give short= > > address to node A, and when it is sure that node A does not use the= > > short address anymore, it can give the same short address to node B= =2E > > This means it can reuse the short addresses and it will not run out= of > > short addresses unless it has more than 65k nodes in network. > >=20 > > Now, if the short address assinged to the node A does not have any > > timeframe how long it is valid, the coordinator does not know when = the > > node A stops using the short address, thus it cannot reuse the > > address. It cannot assume that all nodes will contact it before goi= ng > > away and send release for the address lease, so it must use some ot= her > > mechanism to guarantee that. > >=20 > > Easiest way would be to send the lifetime along the short address. = As > > we do have global time in the network (ASN), we can use that as a > > global time frame, so the coordinator can send node A a short addre= ss > > of 0x1234, and say that node A is allowed to use it until ASN > > 0x12345678a0. After that ASN is reached the node A would need to > > contact coordinator again to renew the short address lease (or most= > > likely it would contact bit earlier and renew the lease so it gets = the > > same address again). > >=20 > > This is explained in the IEEE Std. 802.15.4-2015 section 9.3.2.2: > > -------------------------------------------------------------------= --- > > 9.3.2.2 CCM* nonce for TSCH mode > >=20 > > =09When TSCH mode is enabled, the nonce shall be formatted as > > =09shown in Figure 9-2. > >=20 > > =09 +----------------+--------+ > > =09 | Octets: 8 | 5 | > > =09 +----------------+--------+ > > =09 | Source Address | ASN | > > =09 +----------------+--------+ > > =09 Figure 9-2=E2=80=94CCM* nonce in TSCH mode > >=20 > > =09The Source Address shall either be set to the extended address > > =09of the device originating the frame or shall be formatted as > > =09illustrated in Figure 9-3. > >=20 > > =09 +-----------------+------+--------+---------------+ > > =09 | Octets: 3 | 1 | 2 | 2 | > > =09 +-----------------+------+--------+---------------+ > > =09 | IEEE 802.15 CID | 0x00 | PAN ID | Short address | > > =09 +-----------------+------+--------+---------------+ > > Figure 9-3=E2=80=94Source Address field for TSCH mode with shor= t addressing > >=20 > > =09The IEEE 802.15 CID field contains the CID for IEEE 802.15. > > =09 > > =09The PAN ID field contains the PAN ID. > > =09 > > =09The Short Address field contains the short address of the > > =09device originating the frame. > > =09 > > =09NOTE=E2=80=94When using short addresses in the nonce, it is impo= rtant > > =09that the coordinator assign unique short addresses. > > =09 > > =09The ASN shall be set to the ASN of the timeslot during which > > =09the frame is sent. > > -------------------------------------------------------------------= --- > > PAN ID is added, as large networks might use multiple PANs, but sti= ll > > use same secret key (it does not matter whether the ASNs are in syn= c > > or not). > > --=20 > > kivinen@iki.fi > >=20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > 6tisch-security mailing list > > 6tisch-security@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch-security >=20 --=20 kivinen@iki.fi From nobody Mon Dec 5 18:46:29 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCB12966D for <6tisch-security@ietfa.amsl.com>; Mon, 5 Dec 2016 18:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFthVYyA_XWB for <6tisch-security@ietfa.amsl.com>; Mon, 5 Dec 2016 18:46:25 -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 C33F412940C for <6tisch-security@ietf.org>; Mon, 5 Dec 2016 18:46:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AE4C200A5 for <6tisch-security@ietf.org>; Mon, 5 Dec 2016 22:03:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 69F4E63768 for <6tisch-security@ietf.org>; Mon, 5 Dec 2016 21:46:24 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 05 Dec 2016 21:46:24 -0500 Message-ID: <24987.1480992384@obiwan.sandelman.ca> Archived-At: Subject: [6tisch-security] extra call tomorrow X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 02:46:28 -0000 <#part sign=pgpmime> Just a reminder that we agreed to have an extra call on Tuesday Dec. 6 to continue last week's discussion. http://etherpad.tools.ietf.org:9000/p/6tischSecurity?useMonospaceFont=true https://ietf.webex.com/ietf/j.php?MTID=m64b407a7cdbb11b8c41f8ce0cfb3a6d6 Access code: 644 081 620 Meeting password: animalhouse -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Tue Dec 6 09:53:15 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545A1129A45; Tue, 6 Dec 2016 09:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo7JDNgGOuXp; Tue, 6 Dec 2016 09:53:08 -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 47CC6129421; Tue, 6 Dec 2016 09:53:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AE818200A3; Tue, 6 Dec 2016 13:10:30 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C7C2B63768; Tue, 6 Dec 2016 12:53:06 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org, 6tisch-security@ietf.org In-Reply-To: <72f491eeb444448daa34196c9ac656ea@xs4all.nl> References: <31466.1480551529@obiwan.sandelman.ca> <72f491eeb444448daa34196c9ac656ea@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6tisch <6tisch@ietf.org>, sandeep kumar Subject: Re: [6tisch-security] [6tisch] xxx-bootstrap X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 17:53:10 -0000 protocol="application/pgp-signature" -------- --=-=-= Content-Type: text/plain replying to three of your messages, and trying to repoint the thread at 6tisch-security. peter van der Stok wrote: > all in favor of one approach to merge the push/pull aspects. (I have to > understand the protocol exchange below, but it looks feasibale) > I am not sure about understanding EDHOC, but may be that is not important. I think it is. > I still see all the mime formats. is that phase 1? They are HTTP content-types really. That's part of of the phase 2. > Is phase 2 then switching to OSCOAP with a single format containing binary > encoding? No, we would use EDHOC to create a secure session, and then we would run our EST-CoAP-variant over that. No DTLS at all. peter van der Stok wrote: > I don't think EDHOC is meant to replace EST or the anima work. EDHOC doesn't replace EST, it replaces DTLS. peter van der Stok wrote: > As discussed earlier, having a push/pull agnostic protocol would be > nice. (and probably feasible) > As stated earlier, I think that discovery and which node starts the bootstrap > protocol (BRSKI) is very much installation/technology dependent, and should > be done in another document. I feel very much like I am the holdout for having the JCE initiate the join protocol. > My intention was to reduce the coding effort of the registrar by making 1) > and 2) as similar as can be hoped for; > while payload considerations are of secondary importance. > My hope being that a manufacturer will deliver a registrar box supporting > both coap and http versions. > When the consensus is that adding coap is already such an extra effort that > code sharing between http and coap versions does not alleviate the effort, > then any solution for coap that concentrates on payload reduction is fine by > me. I can see an implementation where a front-end requests/processes the PKCS format messages in traditional EST and the CoAP push/pull variants, and then feeds it into the same engine. I think that the biggest interoperability problem that we are going to have is in the step where the Registrar/JCE tells the Pledge what to put in it's CSR. This is because this part probably involves doing real ASN.1 work, and pledges will want none of that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" --=-=-=-- From nobody Tue Dec 6 10:50:47 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76905129A8F for <6tisch-security@ietfa.amsl.com>; Tue, 6 Dec 2016 10:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40mF2cVYYdBv for <6tisch-security@ietfa.amsl.com>; Tue, 6 Dec 2016 10:50:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3FF129A98 for <6tisch-security@ietf.org>; Tue, 6 Dec 2016 10:50:42 -0800 (PST) X-AuditID: c1b4fb30-037da980000054c8-69-584708809a55 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 59.F2.21704.08807485; Tue, 6 Dec 2016 19:50:40 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.128]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Tue, 6 Dec 2016 19:50:30 +0100 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "6tisch-security@ietf.org" <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] [6tisch] xxx-bootstrap Thread-Index: AQHSSuDPU1xNoBfYBUWdkIQa1WBi/qDyKnSAgACSKYCACHAPAIAAIM3w Date: Tue, 6 Dec 2016 18:50:29 +0000 Message-ID: <9584A7BF-03DF-4385-86DB-4B0A0F931026@ericsson.com> References: <31466.1480551529@obiwan.sandelman.ca> <72f491eeb444448daa34196c9ac656ea@xs4all.nl>, <13358.1481046786@obiwan.sandelman.ca> In-Reply-To: <13358.1481046786@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2J7uG4Dh3uEQf8SM4vmlYvYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX1FD0vBHrGKm5f7WRsYG4S6GDk5JARMJFYsncDUxcjFISSw jlFibkcLI4SzmFGi93QPI0gVm4CrxIEH75hAbBEBS4ntq/+xdTFycAgLmEocfaMKETaT2Dj9 PCNIWETATWJVvxpImEVAReJizxtmEJtXwF7iwZ9rrBDjtzNKHGqfApbgFDCWeLr1P9h4RgEx ie+n1oDZzALiEreezGeCOFRAYsme88wQtqjEy8f/WCFq9CRuTJ3CBmFrSyxb+BpqmaDEyZlP WCYwCs9CMmoWkpZZSFpmIWlZwMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwxA9u+W2w g/Hlc8dDjAIcjEo8vAWX3CKEWBPLiitzDzFKcDArifD6s7lHCPGmJFZWpRblxxeV5qQWH2KU 5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cDIIcjcuJX3x9bpiacXbbptrbFl/6O7Zy9u 8fpvNuF+VLqFYKL7vUSV6s0m0xWDE/4WMf86pThRc9viaxHO2ZZx3C8tPbus2xweSPa7PDh/ b2YVU77kSa3Gykrjmd/C3MI+VbeKzt0t9qxJ87/NaX6Ta3KP5QK2l7jW3jf/GLRY5O/nhclt VkZKLMUZiYZazEXFiQA07wPAbQIAAA== Archived-At: Subject: Re: [6tisch-security] [6tisch] xxx-bootstrap X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:50:45 -0000 > On 6 Dec 2016, at 18:53, Michael Richardson wrote= : >=20 >=20 > replying to three of your messages, and trying to repoint the thread at > 6tisch-security. >=20 > peter van der Stok wrote: >> all in favor of one approach to merge the push/pull aspects. (I have to >> understand the protocol exchange below, but it looks feasibale) >> I am not sure about understanding EDHOC, but may be that is not importan= t. >=20 > I think it is. >=20 >> I still see all the mime formats. is that phase 1? >=20 > They are HTTP content-types really. > That's part of of the phase 2. >=20 >> Is phase 2 then switching to OSCOAP with a single format containing bina= ry >> encoding? >=20 > No, we would use EDHOC to create a secure session, and then we would run > our EST-CoAP-variant over that. No DTLS at all. >=20 > peter van der Stok wrote: >> I don't think EDHOC is meant to replace EST or the anima work. >=20 > EDHOC doesn't replace EST, it replaces DTLS. >=20 > peter van der Stok wrote: >> As discussed earlier, having a push/pull agnostic protocol would be >> nice. (and probably feasible) >=20 >> As stated earlier, I think that discovery and which node starts the boot= strap >> protocol (BRSKI) is very much installation/technology dependent, and sho= uld >> be done in another document. >=20 > I feel very much like I am the holdout for having the JCE initiate the jo= in > protocol. >=20 >> My intention was to reduce the coding effort of the registrar by making = 1) >> and 2) as similar as can be hoped for; >> while payload considerations are of secondary importance. >> My hope being that a manufacturer will deliver a registrar box supportin= g >> both coap and http versions. >=20 >> When the consensus is that adding coap is already such an extra effort t= hat >> code sharing between http and coap versions does not alleviate the effor= t, >> then any solution for coap that concentrates on payload reduction is fin= e by >> me. >=20 > I can see an implementation where a front-end requests/processes the PKCS > format messages in traditional EST and the CoAP push/pull variants, and t= hen > feeds it into the same engine. >=20 > I think that the biggest interoperability problem that we are going to ha= ve > is in the step where the Registrar/JCE tells the Pledge what to put in it= 's > CSR. This is because this part probably involves doing real ASN.1 work, a= nd > pledges will want none of that. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Wed Dec 7 11:37:50 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A03129AA2; Wed, 7 Dec 2016 11:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqmbnRRalV-h; Wed, 7 Dec 2016 11:37:46 -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 CCCBB129584; Wed, 7 Dec 2016 11:37:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B19203AE; Wed, 7 Dec 2016 14:55:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71E6A63768; Wed, 7 Dec 2016 14:37:34 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" , 6tisch@ietf.org, 6tisch-security@ietf.org, anima-bootstrap@ietf.org In-Reply-To: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [6tisch-security] [Ace] EST over CoAP in ACE wg X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ace@ietf.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:37:49 -0000 --=-=-= Content-Type: text/plain I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch environment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (author of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind up with a relatively straight forward description of how to run EST over COAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touch) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over OSCOAP with EDHOC keying. Ideally, it would also permit the process to be managed/initiated from the new device (the pledge), or from the JCE (Registrar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with PSKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhIZP4ACgkQgItw+93Q 3WXOWQf+KBR6EmPppxIOwna8SV1Urd6mO40e5GVek2gMe/waBEc9koF1smIztedO +V149y098pwPFKmUPMKpWDu4uffFYxJX/aA8X5xWQnJRh3V5fDJJqPXYOPkKDs6o XlKZNiMKloERRwDqVo6dvdi3q1RoLvkO95/SRDu6bzBNnIN9McoqgxxKUs7ofuL+ azR6bsragScPy7PjZcZZwALQYsfw/xZdmO/ztbM/fJ48yxxmzNHPZupLoXxJLVbZ 39BuOkICn+DZ57rMDr2gP8Oh/iwmCUYtrsHnNPaQ5EZqJ1cC6RZZGbh9LZaB5i/S CUvQyN/LCy+OwlHH+y9i9YukNUuJrw== =pTHt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 8 00:12:28 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B2512956A for <6tisch-security@ietfa.amsl.com>; Thu, 8 Dec 2016 00:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8LRm37gQS1k for <6tisch-security@ietfa.amsl.com>; Thu, 8 Dec 2016 00:12:23 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83774129B58 for <6tisch-security@ietf.org>; Thu, 8 Dec 2016 00:12:16 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud6.xs4all.net with ESMTP id HLCE1u0034CYHle01LCEJ8; Thu, 08 Dec 2016 09:12:14 +0100 Received: from 2001:983:a264:1:e4b5:c90e:f42d:52ed by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 08 Dec 2016 09:12:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Dec 2016 09:12:14 +0100 From: peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> Message-ID: <5ac94ac231bc766afdb72776f6ea5e0f@xs4all.nl> X-Sender: stokcons@xs4all.nl (hXPlVLSW7/ja0OkiFMaSjBRy1n/Lryw4) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch@ietf.org, anima-bootstrap@ietf.org, 6tisch-security@ietf.org Subject: Re: [6tisch-security] [Ace] EST over CoAP in ACE wg X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 08:12:25 -0000 Hi Michael, > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the > process > to be managed/initiated from the new device (the pledge), or from the > JCE > (Registrar, which might also be the AS in ACE terminology). > About yesterday I started to understand the approach you suggest. Just some more information, to be absolutely sure about what you propose. Do you propose to keep the content formats used by EST unchanged? and keep all the different modes specified in EST RFC? Greetings, Peter From nobody Thu Dec 8 22:04:34 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204631293EE; Thu, 8 Dec 2016 22:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eYOuGX8pPXes; Thu, 8 Dec 2016 22:04:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6932128B38; Thu, 8 Dec 2016 22:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4048; q=dns/txt; s=iport; t=1481263463; x=1482473063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tk/ObWcHBerR5Y0U6HMtC5vA9NyrCvWbZRnEXovn0dU=; b=ZY7ganrAcPhPWjoyFHMNAEUZAaFXyXLgB0cJHPR9TCxVvroRtnMfgcvc RefdqFsFZB0/ZKklZPXgSTOUHWMcZSn1HRN1vTi71AXP604PlZViBUKv8 hOIMELa8CZFMxFxe+J7AVqxJxmpicSC47gjwTK6MLtypxHUWQAG+HqzAj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQCDSEpY/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgywLAQEBAQEfWoEGB41ClxOVAoIJKYJCgmxKAoF8PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBDpLBAIBCBEEAQEfCQcyFAkIAQEEARIIiGMOqVmLLAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhj6EW4QaEAIBTYUvBZprAYlehziBfIhGhguOC4QNAR8?= =?us-ascii?q?3YTyDXRyBXXIBiAuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="184901328" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 06:04:22 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB964MGk012495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 06:04:22 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 00:04:21 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 00:04:22 -0600 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg Thread-Index: AdJD/4dN3nkys8JpRuSDXvz8bQBVcAM9B64AADuYMdA= Date: Fri, 9 Dec 2016 06:04:21 +0000 Message-ID: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.216.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [6tisch-security] [Anima-bootstrap] [Ace] EST over CoAP in ACE wg X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list 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, 09 Dec 2016 06:04:26 -0000 Hi Michael, This are interesting good points. IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not n= ecessarily need to define one transport mechanism. COAPS (over DTLS) is one= obvious option but running over OSCOAP with EDHOC is another. One of the g= oals of these drafts (would need to be merged) is the binding between COAP = messages and BRSKI / EST APIs for all the bootstrapping and cert enrollment= transactions defined in the anima-bootstrapping-keyinfra doc and RFC7030. = draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS = as transport mechanism right now, but could be expanded to define more than= one transports. If the WG finds that as a better idea, normative language = would need to be carefully of course and maybe an MTI option would need to = be chosen. I am curious about your workflow in https://www.ietf.org/mail-archive/web/6= tisch/current/msg05020.html You are envisioning for the JCE to initiate the= bootstrapping to the pledge, but wouldn't that better be defined in the an= ima-bootstrapping-keyinfra doc? About 'simple system that can be used with PSKs as authentication', I was c= urious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with PSK/RP= K/Cert? Anything more detail about these usecases? A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That messag= e would require the private key to be included with the cert since the pled= ge did not generate it by himself. EST defines CMS for this message. PKCS12= could suffice here as well with the challenge if the passphrase provisioni= ng being the problem. Rgs, Panos -----Original Message----- From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Wednesday, December 07, 2016 2:38 PM To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstra= p@ietf.org Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch en= vironment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (auth= or of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touc= h) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying. Ideally, it would also permit the process to be= managed/initiated from the new device (the pledge), or from the JCE (Regis= trar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is= where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Dec 9 00:13:08 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4812A19D; Fri, 9 Dec 2016 00:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sandeep.de 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 kNhzJcuRi0G2; Fri, 9 Dec 2016 00:12:59 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 19FDA12A192; Fri, 9 Dec 2016 00:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481271175; l=11443; s=domk; d=sandeep.de; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=jZDElEKRS7vQYNdGdqvR7hCMzGJAC8RutihCTnJS2EE=; b=V8+A0P22Q9NLu1+4NyfRFWMDHb2gKl7ngweypAzI5rmyHRELq2BqiHHxQQQ43ACmMY lZuVmKpJpuIoGjncZCvTOpJolySySNWs9yMm7hdYdRIVzwdo19rk6OszotvFqOmneYNh KYpScTMYWKORhbmFLjctrTtU24Jz9Wj+qzmVA= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQRFYQZmh2f X-RZG-CLASS-ID: mo00 Received: from mail-qk0-f173.google.com ([209.85.220.173]) by smtp.strato.de (RZmta 39.10 AUTH) with ESMTPSA id t03c5asB98CsJck (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified); Fri, 9 Dec 2016 09:12:54 +0100 (CET) Received: by mail-qk0-f173.google.com with SMTP id q130so10398010qke.1; Fri, 09 Dec 2016 00:12:54 -0800 (PST) X-Gm-Message-State: AKaTC01EtXvCHh9f8C0ipQipDiR64G6BR6iKoAwCl4yAXxoQ5tudctDbYHJDvSd+biflWJ7F1G2erXhtj2r0tA== X-Received: by 10.55.43.29 with SMTP id r29mr66929057qkh.211.1481271173885; Fri, 09 Dec 2016 00:12:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.33 with HTTP; Fri, 9 Dec 2016 00:12:53 -0800 (PST) In-Reply-To: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> From: Sandeep Kumar Date: Fri, 9 Dec 2016 09:12:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=001a1147e8e422baba05433552f8 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , Sandeep Kumar , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" Subject: Re: [6tisch-security] [Ace] [Anima-bootstrap] EST over CoAP in ACE wg X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:13:06 -0000 --001a1147e8e422baba05433552f8 Content-Type: text/plain; charset=UTF-8 HI Michael Just to add, 6tisch has decided to use OSCOAP as the transport but other external standards like Fairhair and Thread have already decided to use DTLS as the transport for EST since it is already there and does not break the workflow the way it might in 6tisch. So these draft on DTLS transport do solve the problem for some, not for everyone. Kind regards Sandeep On Fri, Dec 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Hi Michael, > > This are interesting good points. > > IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not > necessarily need to define one transport mechanism. COAPS (over DTLS) is > one obvious option but running over OSCOAP with EDHOC is another. One of > the goals of these drafts (would need to be merged) is the binding between > COAP messages and BRSKI / EST APIs for all the bootstrapping and cert > enrollment transactions defined in the anima-bootstrapping-keyinfra doc and > RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est > address DTLS as transport mechanism right now, but could be expanded to > define more than one transports. If the WG finds that as a better idea, > normative language would need to be carefully of course and maybe an MTI > option would need to be chosen. > > I am curious about your workflow in https://www.ietf.org/mail- > archive/web/6tisch/current/msg05020.html You are envisioning for the JCE > to initiate the bootstrapping to the pledge, but wouldn't that better be > defined in the anima-bootstrapping-keyinfra doc? > > About 'simple system that can be used with PSKs as authentication', I was > curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with > PSK/RPK/Cert? Anything more detail about these usecases? > > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert since > the pledge did not generate it by himself. EST defines CMS for this > message. PKCS12 could suffice here as well with the challenge if the > passphrase provisioning being the problem. > > Rgs, > Panos > > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Wednesday, December 07, 2016 2:38 PM > To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; > anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg > > > I have read: > draft-pritikin-coap-bootstrap > and draft-vanderstock-core-coap-est > > and over in the 6tisch security design team we have been trying to adapt > the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the > 6tisch environment as a zero-touch enrollment process. > (Yes, I am an author involved in both WGs) > > Peter (one of the authors of draft-vanderstock-core-coap-est) and Max > (author of draft-pritikin-coap-bootstrap) are involved. > > Both documents have good content, and we could combine them easily and > wind up with a relatively straight forward description of how to run EST > over COAPS. > But I don't think that this really solves the problems that we have. > > However, the movement in > draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) > and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, > zero-touch) > [both of which are being considered for adoption] > > is to move away from DTLS and towards OSCOAP and EDHOC. > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the process > to be managed/initiated from the new device (the pledge), or from the JCE > (Registrar, which might also be the AS in ACE terminology). > > We want to initiate from the JCE so that we can: > a) simplify the constrained device. > b) manage the order and priority of join activities to avoid > network congestion in constrained (mesh) networks. > > On the other hand, some want a really simple system that can be used with > PSKs as authentication, with the new nodes initiating. > > I wrote this email last week to explain some of what I have in mind. > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html > > I don't know if the EST work fits into ACE's charter, but given that ACE > is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1147e8e422baba05433552f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI Michael

=C2=A0Just to add, 6tisch has decided to us= e OSCOAP as the transport but other external standards like Fairhair and Thread have already decided = to use DTLS as the transport for EST since it is already there and does not br= eak the workflow the way it might in 6tisch. So these draft on DTLS transport do so= lve the problem for some, not for everyone.

=C2=A0Kind regards

Sandeep

=C2=A0


On Fri, Dec= 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) <pkampana@cisco.com&= gt; wrote:
Hi Michael,

This are interesting good points.

IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-es= t do not necessarily need to define one transport mechanism. COAPS (over DT= LS) is one obvious option but running over OSCOAP with EDHOC is another. On= e of the goals of these drafts (would need to be merged) is the binding bet= ween COAP messages and BRSKI / EST APIs for all the bootstrapping and cert = enrollment transactions defined in the anima-bootstrapping-keyinfra doc and= RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS as transport mechanism right now, but could be expanded= to define more than one transports. If the WG finds that as a better idea,= normative language would need to be carefully of course and maybe an MTI o= ption would need to be chosen.

I am curious about your workflow in https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.h= tml You are envisioning for the JCE to initiate the bootstrapping to th= e pledge, but wouldn't that better be defined in the anima-bootstrappin= g-keyinfra doc?

About 'simple system that can be used with PSKs as authentication',= I was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth wit= h PSK/RPK/Cert? Anything more detail about these usecases?

A nit in " <--- CoAP POST /cert-----=C2=A0 =C2=A0 =C2=A0[PKCS7 Cert= ificate] ". That message would require the private key to be included = with the cert since the pledge did not generate it by himself. EST defines = CMS for this message. PKCS12 could suffice here as well with the challenge = if the passphrase provisioning being the problem.

Rgs,
Panos

-----Original Message-----
From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf Of Michael Rich= ardson
Sent: Wednesday, December 07, 2016 2:38 PM
To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstrap@ietf.org
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg


I have read:
=C2=A0 =C2=A0 draft-pritikin-coap-bootstrap
and draft-vanderstock-core-coap-est

and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tis= ch environment as a zero-touch enrollment process.
(Yes, I am an author involved in both WGs)

Peter (one of the authors of draft-vanderstock-core-coap-est) and Max = (author of draft-pritikin-coap-bootstrap) are involved.

Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS.
But I don't think that this really solves the problems that we have.
However, the movement in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vucinic-6tisch-minimal-securit= y (as phase 2, and one-touch)
and=C2=A0 =C2=A0draft-richardson-6tisch-dtsecurity-secure-join (as pha= se 1, zero-touch)
[both of which are being considered for adoption]

is to move away from DTLS and towards OSCOAP and EDHOC.

As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying.=C2=A0 Ideally, it would also permit the process = to be managed/initiated from the new device (the pledge), or from the JCE (= Registrar, which might also be the AS in ACE terminology).

We want to initiate from the JCE so that we can:
=C2=A0 a) simplify the constrained device.
=C2=A0 b) manage the order and priority of join activities to avoid
=C2=A0 =C2=A0 =C2=A0network congestion in constrained (mesh) networks.

On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating.

I wrote this email last week to explain some of what I have in mind.
=C2=A0 https://www.ietf.org/mail-<= wbr>archive/web/6tisch/current/msg05020.html

I don't know if the EST work fits into ACE's charter, but given tha= t ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a docu= ment here.

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



_______________________= ________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a1147e8e422baba05433552f8-- From nobody Mon Dec 12 19:54:52 2016 Return-Path: X-Original-To: 6tisch-security@ietfa.amsl.com Delivered-To: 6tisch-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8653F129551 for <6tisch-security@ietfa.amsl.com>; Mon, 12 Dec 2016 19:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4eNtV3M_mzh for <6tisch-security@ietfa.amsl.com>; Mon, 12 Dec 2016 19:54:49 -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 5AA6F1294D8 for <6tisch-security@ietf.org>; Mon, 12 Dec 2016 19:54:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 403C520567 for <6tisch-security@ietf.org>; Mon, 12 Dec 2016 23:12:34 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 42E4163770 for <6tisch-security@ietf.org>; Mon, 12 Dec 2016 22:54:48 -0500 (EST) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [6tisch-security] agenda for meeting Tuesday X-BeenThere: 6tisch-security@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 03:54:51 -0000 --=-=-= Content-Type: text/plain As per, https://www.ietf.org/mail-archive/web/6tisch-security/current/msg00629.html Dec. 13 is our second meeting according to two week schedule... but we added a meeting last week. The connect information is the same: Tuesday, November 29, 2016 9:00 am Eastern Standard Time (GMT-05:00) Recurrence: Every 2 weeks on Tuesday, from Tuesday, November 29, 2016, to Tuesday, March 21, 2017 Meeting number: 641 335 839 Meeting password: pledge Meeting link: https://ietf.webex.com/ietf/j.php?MTID=me98f12cebda5e6b55c1b8c66c095d0a9 PROPOSED AGENDA is: 1) the two EST over CoAP documents, and how to combine them into one, and how to make it able to be initiated from either end. If we have time, moving on to: 2) how do we edit the two new documents to avoid repetition? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhPcQcACgkQgItw+93Q 3WVCZggAtI8Vdu61lhNS2ZdBWRXpLfIBIE2xDCnjvqqRk4B2A+pVOTk3k15wBko9 2xkMJ4t4Z0PJ0y7bDR3IuxblmjFLYEiyvkKq7q5NwFBOUq8LtLHQ25pnAx08WvoL Zo5iLcy8d433t3DP4uoMcxAJ6E61wbK7xqZo380JJrlqZfyJVeRXpdwRWqZmcvLt AZetlyPeMan65+f2GeVDSI/HJmtvmfrUKb73u8ZC2b3TnChmHvzg50jYFqgsAAI4 RtR6IPizAT489TsGzHyuUuaPxyiYrbiqXazR60hFZdt5iQCwOP2iatmRTGkz+49f Wh64GhO7kVEddbR3LLYDbyxARbx7tw== =yI7Y -----END PGP SIGNATURE----- --=-=-=--