From nobody Mon Jun 6 11:31:11 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64012D528; Mon, 6 Jun 2016 11:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 AOS5qbpBEA_O; Mon, 6 Jun 2016 11:31:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4602112D0ED; Mon, 6 Jun 2016 11:31:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 098EF2015D; Mon, 6 Jun 2016 14:38:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18B7D638BF; Mon, 6 Jun 2016 14:31:05 -0400 (EDT) From: Michael Richardson To: Samuel Erdtman , anima-bootstrap@ietf.org, anima@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Anima-bootstrap] [Ace] Constrained Environment PKI enrollment X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:31:08 -0000 --=-=-= Content-Type: text/plain Samuel Erdtman wrote: > The company I previously worked for where looking into adopting EST for > this purpose, the benefit of EST compared to cmp or scep was that it > defined the process for server side generated keys, which could be > beneficial if key generation would be to cumbersome for the device or > if you don't trust the > device to generate a "good" key. Hi, these are definitely important considerations. I would invite you to read the ANIMA bootstrap keying documents, and possibly join the design team. At this point I believe the bootstrap is out of scope for ACE. We are considering whether to use OSCOAP for 6tisch though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1XBZoCLcPvd0N1lAQLTuQgAtuaOs6hVleoaAsZoicJbXplyQssSdPSf ALSBHxtzq4dqyYqw4v0SSQ0cT4H2KTNINbdLND3VBocqNU9XiqmZgmvlOkpbCwZ+ KyzlOBhuWh8f+S8cnZk4DboUbeXPAiR7NQP3ROZoTcHk75x5EYjpav4LK8qM0W3w oOaKdh0Q/Ui9sUqTAIxyplA72Nk15F4UBZxm83HlktQIlL6fTTFvRMNH8Y8xHyJq EHZbe/3erD+M2jGXUFNdO4gEYCZ7HG1YbLwHYN8sX6o/SWbKK5cnxE1d0rPXyYR2 MrY8O+3TA9vBIJj38lvU0FFiGIa40bGRhBgC3+u4OFs2pWGm1t/qPw== =iS1x -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 6 11:31:51 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D646712D537; Mon, 6 Jun 2016 11:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 G2kmdUhbck1c; Mon, 6 Jun 2016 11:31:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D786012D528; Mon, 6 Jun 2016 11:31:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D49E2015D; Mon, 6 Jun 2016 14:38:48 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 185C7638BF; Mon, 6 Jun 2016 14:31:45 -0400 (EDT) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org>, anima-bootstrap 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: [Anima-bootstrap] [Ace] Constrained Environment PKI enrollment (fwd) Shahid Raza: Re: [Ace] Constrained Environment PKI enrollment X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:31:48 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain A thread from ACE that you may not have seen. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=191 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Sun, 05 Jun 2016 13:16:27 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Fri, 03 Jun 2016 19:08:34 -0400 X-Sieve: CMU Sieve 2.4 Received: from colo4.roaringpenguin.com (colo4.roaringpenguin.com [IPv6:2607:f748:1200:107::4]) by tuna.sandelman.ca (Postfix) with ESMTPS id 64A7B200A5 for ; Fri, 3 Jun 2016 19:08:34 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1900:3001:11::2c]) by colo4.roaringpenguin.com (8.14.4/8.14.4/Debian-8) with ESMTP id u53N1cV9005348 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 3 Jun 2016 19:01:39 -0400 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA1128B44; Fri, 3 Jun 2016 16:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1464994897; bh=KJqmQljfAdt4wljMAMtlQGlXffOzb8VAC/eBG3OttR0=; h=From:In-Reply-To:Date:References:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=q68Gm8MoMywUecAcsK/EMp+cGx++p35Zbmu98xGvYjvUcjJtB0BpWBPo4cy1tpgtQ o6Q541lDt7Q+EadbMJ3nefpOTJRDVe7sDY+raQAw5DA14nw1ZptXWrUWqyB/fBcLTe 6T978TzmCHTYExcZleYOW3NDQ8f++MC84NcdTvc4= X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3CA12B01F for ; Fri, 3 Jun 2016 16:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: 0.00 () [Hold at 5.10] HEADER_FROM_DIFFERENT_DOMAINS:0.001,HTML_MESSAGE:0.001,SPF(pass:0),DKIM(pass:0) X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.20150623.gappssmtp.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 FW7XMBWe5L_3 for ; Fri, 3 Jun 2016 16:01:33 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305BE128B44 for ; Fri, 3 Jun 2016 16:01:33 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id s64so63344165lfe.0 for ; Fri, 03 Jun 2016 16:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=K+ZQObFdPteRUTicFYna1ZiQ9PAetrInHlb4Blupqs8=; b=EkHoh2f9Bc8JxA2YPsopxydAt04Mh/7ub0zPaB1LSe3Y4bxz53E1Pq/fsy2KV+BwsM vXshtUBywHtwt3OJLyHxBGa1mYTjiR8SPNU5yoHejTE49XjcBhA1sjSi0GlTy8mlwoyg Hc0/yXZdOYQ0skPNF2LhHr24UDtPV55a6Ir4xmGT59eNbkxWjLi/yoPVqtrrA+g+xjvP yZDb94Yy942KN0vN/YffzieYN+kF8G5Ke1E5rmP/Z+feyduvkgejRLUArM5MVODkxFek SRxBJY5zeWVDsGPNHszJ924bKS395ADzT/aTAwo0/fb0xa44DGybn+0BQA+fH59+ButC buMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=K+ZQObFdPteRUTicFYna1ZiQ9PAetrInHlb4Blupqs8=; b=EDA1g2Jbbr7dmGyPpVufTNV+Z67TTobVxx9AHyrtTGyjjwia5L/7OH2yJ9CLrRSGXg HSN1WOPQFNtFedKML1IRwZbUQaCrinIMJRITpINqMfwfdu0upDyLVP3U0eMcWGduk1tR vHzk9zGZyGNUSupAKsb+d+uGv4d3NLrEFMmUWhPCEu+ZJCNb2pYijklF1y00vkAkNWCE nhnZrCHUQsPl7nrxoOjk0QA7j2U3UqVUkUjUZYxsNM7u65lp07zRCwTkh2lrfGujrjT5 TBU+Cy9BCLLNIMO4oosPXWfI+fi4f9uZNCpaVOq2EGM5F7BOAn+TFouRVjYqlo3ldaXC fb0w== X-Gm-Message-State: ALyK8tKsWaFcpoHkA4onla/gRDqbbGGn5i4iRMRPv7wiPGmSyhjLcrOW/j+NP/VH0bbDl6Ld X-Received: by 10.25.18.167 with SMTP id 39mr1882922lfs.118.1464994891318; Fri, 03 Jun 2016 16:01:31 -0700 (PDT) Received: from [192.168.0.15] (c83-251-26-38.bredband.comhem.se. [83.251.26.38]) by smtp.gmail.com with ESMTPSA id y124sm724659lfd.0.2016.06.03.16.01.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 16:01:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shahid Raza In-Reply-To: Date: Sat, 4 Jun 2016 01:01:29 +0200 Message-Id: <0EB38F45-003A-42DA-92F6-E166D9642010@sics.se> References: To: Samuel Erdtman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Ace] Constrained Environment PKI enrollment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8891537821965744600==" Errors-To: ace-bounces@ietf.org Sender: "Ace" X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-CanIt-Geo: ip=2001:1900:3001:11::2c; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 02R2n1DWP - d78953f113cb - 20160603 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?i=02R2n1DWP&m=d78953f113cb&t=20160603&c=f X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?i=02R2n1DWP&m=d78953f113cb&t=20160603&c=n X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?i=02R2n1DWP&m=d78953f113cb&t=20160603&c=p X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?i=02R2n1DWP&m=d78953f113cb&t=20160603&c=s X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: pass (colo4.roaringpenguin.com: domain of ace-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) receiver=colo4.roaringpenguin.com; client-ip=2001:1900:3001:11::2c; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) --===============8891537821965744600== Content-Type: multipart/alternative; boundary="Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD" --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We (SICS and neXus) have been working on this since September last year = and designed and implemented an enrollment protocol over secure CoAP. = Both the specifications and the Contiki source code will be available = soon. This is done under the umbrella of a Swedish project called CEBOT: = Certificate Enrollment in Billions of Things. Regards, Shahid > On 03 Jun 2016, at 17:08, Samuel Erdtman wrote: >=20 > The company I previously worked for where looking into adopting EST = for this purpose, the benefit of EST compared to cmp or scep was that it = defined the process for server side generated keys, which could be = beneficial if key generation would be to cumbersome for the device or if = you don't trust the device to generate a "good" key. >=20 > Maybe Shahid could give sold more updates since he was helping us with = this project >=20 > On Thursday, 2 June 2016, Julien Vermillard > wrote: > Hi, > In industrial or enterprise M2M/IoT application we often use PSK for = authentication, but more and more user want to enroll the device on = their public key infrastructure like they does with some routers using = SCEP/CMP. >=20 > I wonder if it was explored to enroll devices, and renew certificates = on PKI only using CoAP and not HTTP? >=20 > -- > Julien Vermillard > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We (SICS and neXus) have been working on this since September = last year and designed and implemented an enrollment protocol over = secure CoAP. Both the specifications and the Contiki source code will be = available soon. This is done under the umbrella of a Swedish project = called CEBOT: Certificate Enrollment in Billions of Things.

Regards,
Shahid

On = 03 Jun 2016, at 17:08, Samuel Erdtman <samuel@erdtman.se> = wrote:

The = company I previously worked for where looking into adopting EST for this = purpose, the benefit of EST compared to cmp or scep was that it defined = the process for server side generated keys, which could be beneficial if = key generation would be to cumbersome for the device or if you don't = trust the device to generate a "good" key.

Maybe Shahid could give sold more = updates since he was helping us with this = project

On Thursday, 2 June 2016, Julien = Vermillard <jvermillard@gmail.com> wrote:
Hi,
In industrial or = enterprise M2M/IoT application we often use PSK for authentication, but = more and more user want to enroll the device on their public key = infrastructure like they does with some routers using SCEP/CMP.

I wonder if it was explored to enroll = devices, and renew certificates on PKI only using CoAP and not HTTP?

--
Julien = Vermillard
_______________________________________________
Ace = mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

= --Apple-Mail=_8BA7334F-4C74-4F42-86F9-5B1C6ACCB4AD-- --===============8891537821965744600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --===============8891537821965744600==-- --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1XBjYCLcPvd0N1lAQKbywgAsrl4HOPCsXmB9wwFYrcjYCKVMNBKR74F 55APEECFvEv5MytmZ4X+CNw1gPtW73yv0jxYijmTIDZkJqBHTI9mAX9DNxAcH5IB vkdX5gVW/IuCm8TNlwmOZs4QcJwggI7LJRBJZLVdf6cfFgObh812RFp3N+LUI+Dw vCywHaPp05liWz6fExmOWA5tes5EvWvBJYbsY7gqw3PKVng9cvQP/K987yo4zHyi OJ6m1nop3uZHPEHhzp3jUFr6hF+Uz6tOOgnC9yuotGdnHyMuZy5wpoN7q4PTgdUE jR5plN2f8OaNxZpUpaasS6imORsK2wOboQuG17ydLxcP2i0Q5YoBaQ== =fuMv -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Jun 7 18:16:57 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451AB12D93C; Tue, 7 Jun 2016 18:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 ycthcSqfL4pu; Tue, 7 Jun 2016 18:16:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4344012D93A; Tue, 7 Jun 2016 18:16:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A04BF2009E; Tue, 7 Jun 2016 21:23:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30E75638BF; Tue, 7 Jun 2016 21:16:48 -0400 (EDT) From: Michael Richardson To: 6tisch-security@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.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 Archived-At: Cc: anima-bootstrap@ietf.org Subject: [Anima-bootstrap] goals for this 6tisch design team -- zero-touch vs one-touch X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:16:53 -0000 --=-=-= Content-Type: text/plain There has been a fair bit of discussion, much if it 1:1 offlist about what the goals of this design team is. Our charter says: https://datatracker.ietf.org/wg/6tisch/charter/ ... The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH. ... - Produce a specification for a secure 6TiSCH network bootstrap, adapted to the constraints of 6TiSCH nodes and leveraging existing art when possible. Zero-touch vs one-touch is not mentioned. In https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-05 Based upon conversation that lead to the 2014 era work, I had written: 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. This is in alignment with the ANIMA bootstrap work. Recently the desire for a "one-touch" provisioning system has been expressed. Rationals include: simpler, less code, less complex, lower energy, etc. (My goal is not to dispute any of these points here) This is to be constrasted with a zero-touch system where unique PreSharedKeys (PSKs) are provisioned during manufacturing and are provided to the end-customer in some fashion. A one-touch system would involve some kind of special provisioning room: * customer plugs in cable to device and installs a PSK (whether unique per node, or per-network) * customer turns on device in faraday cage, uses well-known PSK to take ownership and install a per-node unique PSK * some other model The customer then puts the device back into a box and puts it into inventory to be deployed as appropriate. I'm told that this is exactly the model that the electric metering (AMI) people use. I don't know if the special provisioning room/cable is done centrally or on-site, but I do know that the meters have standard-ish fiber optic connections for doing this. (Fiber to avoid electrical shock: cf: ANSI C12.18) It seems that there are an innumerable number of ways that the "touch" for a one-touch system could be done, and if there is real desire to accomodate such a process, we need to state some assumptions about the touch process. As such, a document is surely needed. Some questions I have: 1) is it physical? (vs radio. vs a BNC/etc cable plugged instead of antenna) 2) is it encrypted? 3) does it run IP? 4) how many bits can be transmitted/received? 5) is the target CPU alive, or is this JTAG or JTAG-like? If we are using (D)TLS, then to me, then a way to do one-touch without any asymmetric crypto would be to create a TLS session resumption ticket . Not via the NewSessionTicket exchange, but directly. The controller (JCE) would actually have knowledge of the ticket format (section 4). The format would not be "Recommended" but rather standardized, moving all of the heavy work from the device to the JCE. The device would simply be told the "master key". Would this work, I don't know yet, because I don't know what one-touch setup can do. If this is the direction we need to go, great, but someone has to step up to write this document. The advantage of what I would propose is that a zero-touch and one-touch solution would be identical, except for how the TLS session is initiated. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1dx/YCLcPvd0N1lAQK65wf/Q3WWgglNM9vRvYieysWcw39LgDQ+Gobh UsqxMesONVgbiTDKNhLLk44saTGtEGCg69CGfN2GhP9fpmYypay8ticnOgK5rnmv jLAhgGup9QrIQGyxRwL5aBThoEJhl+0pnO7xqzBxVWG8x8qOyt3KBJhBT90HWHzz AoC7Duyr3vTRRPJr0O0mwnxcx2adDdOMe7bFffP2SxPr3uEkBDWuo38GmH941fDI O7k35Ju9EZRFf2FTQQOeuWInyVKtMIEEwf5BflMRGtOVBJPrT6VXvyMiBUICOvbt QyqjhGyDWwUZAGzel4hJWyMAP6yz9m4knm4JzVZgOtsGCJ8/Tw4DsQ== =r+da -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 8 00:00:17 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727FD12D812 for ; Wed, 8 Jun 2016 00:00:12 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 2oDmWRAmagya for ; Wed, 8 Jun 2016 00:00:10 -0700 (PDT) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75F12D11E for ; Wed, 8 Jun 2016 00:00:10 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id u5870840059240 for ; Wed, 8 Jun 2016 03:00:08 -0400 Received: (qmail 17564 invoked by uid 0); 8 Jun 2016 07:00:08 -0000 X-TCPREMOTEIP: 213.208.239.114 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?172.20.1.19?) (rturner@amalfisystems.com@213.208.239.114) by 0 with ESMTPA; 8 Jun 2016 07:00:07 -0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_7D22AC77-2AA9-4AB8-ADF6-670C1768A99A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randy Turner In-Reply-To: <14614.1465348608@obiwan.sandelman.ca> Date: Wed, 8 Jun 2016 02:59:58 -0400 Message-Id: References: <14614.1465348608@obiwan.sandelman.ca> To: 6tisch-security@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:00:12 -0000 --Apple-Mail=_7D22AC77-2AA9-4AB8-ADF6-670C1768A99A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The only ANIMA document I can find with =E2=80=9Cbootstrap=E2=80=9D in = the title specifically precludes its=E2=80=99 application in constrained = environments=E2=80=A6 The entire solution described in this document is aimed in general at non-constrained (i.e. class 2+) devices operating on a non-Challenged network. The entire solution described here is not intended to be useable as-is by constrained devices operating on challenged networks (such as 802.15.4 LLNs). So I=E2=80=99m assuming we can =E2=80=9Cborrow=E2=80=9D ideas from ANIMA = but reuse it =E2=80=A6 Randy > On Jun 7, 2016, at 9:16 PM, Michael Richardson = wrote: >=20 >=20 > There has been a fair bit of discussion, much if it 1:1 offlist about = what > the goals of this design team is. >=20 > Our charter says: > https://datatracker.ietf.org/wg/6tisch/charter/ >=20 > ... > The WG will continue working on securing the join process and = making > that fit within the constraints of high latency, low throughput and > small frame sizes that characterize IEEE802.15.4 TSCH. > ... > - Produce a specification for a secure 6TiSCH network bootstrap, = adapted > to the constraints of 6TiSCH nodes and leveraging existing art when > possible. >=20 > Zero-touch vs one-touch is not mentioned. >=20 > In = https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-05 > Based upon conversation that lead to the 2014 era work, I had written: > 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. >=20 > 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. >=20 > This is in alignment with the ANIMA bootstrap work. >=20 > Recently the desire for a "one-touch" provisioning system has been = expressed. > Rationals include: simpler, less code, less complex, lower energy, = etc. > (My goal is not to dispute any of these points here) >=20 > This is to be constrasted with a zero-touch system where unique = PreSharedKeys > (PSKs) are provisioned during manufacturing and are provided to the = end-customer in > some fashion. >=20 > A one-touch system would involve some kind of special provisioning = room: > * customer plugs in cable to device and installs a PSK (whether = unique > per node, or per-network) > * customer turns on device in faraday cage, uses well-known PSK to > take ownership and install a per-node unique PSK > * some other model > The customer then puts the device back into a box and puts it into = inventory > to be deployed as appropriate. I'm told that this is exactly the = model that > the electric metering (AMI) people use. I don't know if the special > provisioning room/cable is done centrally or on-site, but I do know = that the > meters have standard-ish fiber optic connections for doing this. = (Fiber to > avoid electrical shock: cf: ANSI C12.18) >=20 > It seems that there are an innumerable number of ways that the "touch" = for a > one-touch system could be done, and if there is real desire to = accomodate > such a process, we need to state some assumptions about the touch = process. > As such, a document is surely needed. Some questions I have: > 1) is it physical? (vs radio. vs a BNC/etc cable plugged instead of = antenna) > 2) is it encrypted? > 3) does it run IP? > 4) how many bits can be transmitted/received? > 5) is the target CPU alive, or is this JTAG or JTAG-like? >=20 > If we are using (D)TLS, then to me, then a way to do one-touch without = any > asymmetric crypto would be to create a TLS session resumption ticket > . Not via the NewSessionTicket = exchange, > but directly. The controller (JCE) would actually have knowledge of = the > ticket format (section 4). The format would not be "Recommended" but = rather > standardized, moving all of the heavy work from the device to the JCE. = The > device would simply be told the "master key". Would this work, I = don't know > yet, because I don't know what one-touch setup can do. >=20 > If this is the direction we need to go, great, but someone has to step = up to > write this document. >=20 > The advantage of what I would propose is that a zero-touch and = one-touch > solution would be identical, except for how the TLS session is = initiated. >=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 --Apple-Mail=_7D22AC77-2AA9-4AB8-ADF6-670C1768A99A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The only ANIMA document I can find with =E2=80=9Cbootstrap=E2=80= =9D in the title specifically precludes its=E2=80=99 application in = constrained environments=E2=80=A6

The entire solution described in this document is =
aimed in general at
   non-constrained (i.e. class 2+) devices operating on a non-Challenged
   network.  The entire solution described here is not intended to be
   useable as-is by constrained devices operating on challenged networks
   (such as 802.15.4 LLNs).

So I=E2=80=99m assuming we can =E2=80=9Cborrow=E2=80=9D = ideas from ANIMA but reuse it =E2=80=A6

Randy


On Jun 7, 2016, at 9:16 PM, = Michael Richardson <mcr+ietf@sandelman.ca> wrote:


There has been a fair bit of discussion, much if it 1:1 = offlist about what
the goals of this design team is.

Our charter says:
=    https://datatracker.ietf.org/wg/6tisch/charter/

   ...
=    The WG will continue working on securing the join = process and making
   that fit within the = constraints of high latency, low throughput and
=    small frame sizes that characterize IEEE802.15.4 = TSCH.
   ...
=    - Produce a specification for a secure 6TiSCH network = bootstrap, adapted
   to the constraints = of 6TiSCH nodes and leveraging existing art when
=    possible.

Zero-touch vs = one-touch is not mentioned.

In https://tools.ietf.org/html/draft-richardson-6tisch--security-6= top-05
Based upon conversation that lead to the 2014 = era work, I had written:
  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.

This is = in alignment with the ANIMA bootstrap work.

Recently the desire for a "one-touch" provisioning system has = been expressed.
Rationals include: simpler, less code, = less complex, lower energy, etc.
(My goal is not to = dispute any of these points here)

This is = to be constrasted with a zero-touch system where unique PreSharedKeys
(PSKs) are provisioned during manufacturing and are provided = to the end-customer in
some fashion.

A one-touch system would involve some kind of special = provisioning room:
   * customer plugs in = cable to device and installs a PSK (whether unique
=      per node, or per-network)
=    * customer turns on device in faraday cage, uses = well-known PSK to
     take = ownership and install a per-node unique PSK
=    * some other model
The customer then = puts the device back into a box and puts it into inventory
to be deployed as appropriate.  I'm told that this is = exactly the model that
the electric metering (AMI) people = use.  I don't know if the special
provisioning = room/cable is done centrally or on-site, but I do know that the
meters have standard-ish fiber optic connections for doing = this. (Fiber to
avoid electrical shock: cf: ANSI = C12.18)

It seems that there are an = innumerable number of ways that the "touch" for a
one-touch = system could be done, and if there is real desire to accomodate
such a process, we need to state some assumptions about the = touch process.
As such, a document is surely needed. =  Some questions I have:
  1) is it = physical? (vs radio. vs a BNC/etc cable plugged instead of antenna)
  2) is it encrypted?
=   3) does it run IP?
  4) how many = bits can be transmitted/received?
  5) is the = target CPU alive, or is this JTAG or JTAG-like?

If we are using (D)TLS, then to me, then a way to do = one-touch without any
asymmetric crypto would be to create = a TLS session resumption ticket
<https://tools.ietf.org/html/rfc5077>. Not via the = NewSessionTicket exchange,
but directly.  The = controller (JCE) would actually have knowledge of the
ticket= format (section 4).  The format would not be "Recommended" but = rather
standardized, moving all of the heavy work from the = device to the JCE.  The
device would simply be told = the "master key".  Would this work, I don't know
yet, = because I don't know what one-touch setup can do.

If this is the direction we need to go, great, but someone = has to step up to
write this document.

The advantage of what I would propose is that a zero-touch = and one-touch
solution would be identical, except for how = the TLS session is initiated.

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


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

= --Apple-Mail=_7D22AC77-2AA9-4AB8-ADF6-670C1768A99A-- From nobody Wed Jun 8 05:47:57 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DC112D1EA; Wed, 8 Jun 2016 05:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 p3i2o5bp2MdC; Wed, 8 Jun 2016 05:47:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EC812D09F; Wed, 8 Jun 2016 05:47:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD6492009E; Wed, 8 Jun 2016 08:55:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E4423638BF; Wed, 8 Jun 2016 08:47:51 -0400 (EDT) From: Michael Richardson To: Randy Turner In-Reply-To: References: <14614.1465348608@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap@ietf.org, 6tisch-security@ietf.org Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:47:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Randy Turner wrote: > The only ANIMA document I can find with =E2=80=9Cbootstrap=E2=80=9D i= n the title specifically > precludes its=E2=80=99 application in constrained environments=E2=80= =A6 Well, you might have noticed that I'm one of the authors. And while the *protocol* we intend to use in ANIMA bootstrap is inappropria= te for *6tisch* for a number of subtle reasons, we think: a) it will work for "class 3" devices with no UI in non-constrained net= works. b) the certificate, MIC, TPM, 802.1AR, MASA and registar are designed to be useable in both environments. > So I=E2=80=99m assuming we can =E2=80=9Cborrow=E2=80=9D ideas from AN= IMA but reuse it =E2=80=A6 Entire non-edge subsystems, just not the code at the edge. Back to the question though. Do you have one-touch process, and if so, wou= ld you want to describe it's capabilities? > It seems that there are an innumerable number of ways that the "touch" > for a one-touch system could be done, and if there is real desire to = accomodate > such a process, we need to state some assumptions about the touch > process. > As such, a document is surely needed. Some questions I have: > 1) is it physical? (vs radio. vs a BNC/etc cable plugged instead of > antenna) > 2) is it encrypted? > 3) does it run IP? > 4) how many bits can be transmitted/received? > 5) is the target CPU alive, or is this JTAG or JTAG-like? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV1gT9ICLcPvd0N1lAQJABAf/X42KPZgE1v/+rslk/5KG2lQm0uPVQtgi iKeXv3vJBQHFJck3fXsVQpYOlaeyz05eHDYZe2jbw8vA7ca4T7wDd8xlRx8i+YWw OO/dxGTbxmonxvcFPYVveXpaFprXdr23LyXWb47BmFRxT7DsDhI/ieg9ewU3QgIr J1r+zwUR3+SofH6RcXJTI0R4s6cRoeV8ikaoVjNL8OCzsC+YPOKj6SeqAZN1vzlR AHXV4vN667MD5agisLG8BbOhJLqmmtnlFgbnJfq1mbQGHU0LXMv4HUtNMwkrHLyR +YlncGEE9eKEx+r+jM0Vk9I09c09LHBmkaejcXF9o34aVuuju3SuzA== =7OAt -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 8 07:43:24 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8CD12D959 for ; Wed, 8 Jun 2016 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 U-s_KM4p5wBB for ; Wed, 8 Jun 2016 07:43:19 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91D12D5AE for ; Wed, 8 Jun 2016 07:43:16 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u58EhDeB023841 for ; Wed, 8 Jun 2016 10:43:14 -0400 Received: (qmail 24761 invoked by uid 0); 8 Jun 2016 14:43:13 -0000 X-TCPREMOTEIP: 213.208.239.114 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?172.20.1.19?) (rturner@amalfisystems.com@213.208.239.114) by 0 with ESMTPA; 8 Jun 2016 14:43:13 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Randy Turner In-Reply-To: <29992.1465390071@obiwan.sandelman.ca> Date: Wed, 8 Jun 2016 10:43:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06BD710B-9537-47DB-870B-0D193E187AD3@amalfisystems.com> References: <14614.1465348608@obiwan.sandelman.ca> <29992.1465390071@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: anima-bootstrap@ietf.org, 6tisch-security@ietf.org Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:43:22 -0000 We do not have zero or one-touch process, but we do have equivalent = 802.1AR device certs - that=E2=80=99s about the only thing we have in = common with your item (b) below=E2=80=A6 R. > On Jun 8, 2016, at 8:47 AM, Michael Richardson = wrote: >=20 >=20 > Randy Turner wrote: >> The only ANIMA document I can find with =E2=80=9Cbootstrap=E2=80=9D = in the title specifically >> precludes its=E2=80=99 application in constrained environments=E2=80=A6= >=20 > Well, you might have noticed that I'm one of the authors. > And while the *protocol* we intend to use in ANIMA bootstrap is = inappropriate > for *6tisch* for a number of subtle reasons, we think: > a) it will work for "class 3" devices with no UI in non-constrained = networks. > b) the certificate, MIC, TPM, 802.1AR, MASA and registar are = designed to > be useable in both environments. >=20 >> So I=E2=80=99m assuming we can =E2=80=9Cborrow=E2=80=9D ideas from = ANIMA but reuse it =E2=80=A6 >=20 > Entire non-edge subsystems, just not the code at the edge. >=20 > Back to the question though. Do you have one-touch process, and if = so, would > you want to describe it's capabilities? >=20 >> It seems that there are an innumerable number of ways that the = "touch" >> for a one-touch system could be done, and if there is real desire to = accomodate >> such a process, we need to state some assumptions about the touch >> process. >> As such, a document is surely needed. Some questions I have: >> 1) is it physical? (vs radio. vs a BNC/etc cable plugged instead of >> antenna) >> 2) is it encrypted? >> 3) does it run IP? >> 4) how many bits can be transmitted/received? >> 5) is the target CPU alive, or is this JTAG or JTAG-like? >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Thu Jun 9 06:22:16 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7112D67D; Thu, 9 Jun 2016 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 uOQ1VLCBl-u5; Thu, 9 Jun 2016 06:22:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B7F12D666; Thu, 9 Jun 2016 06:22:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3807C203BC; Thu, 9 Jun 2016 09:29:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B9892638BE; Thu, 9 Jun 2016 09:22:11 -0400 (EDT) From: Michael Richardson To: Randy Turner In-Reply-To: <06BD710B-9537-47DB-870B-0D193E187AD3@amalfisystems.com> References: <14614.1465348608@obiwan.sandelman.ca> <29992.1465390071@obiwan.sandelman.ca> <06BD710B-9537-47DB-870B-0D193E187AD3@amalfisystems.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: Cc: anima-bootstrap@ietf.org, 6tisch-security@ietf.org Subject: Re: [Anima-bootstrap] [6tisch-security] goals for this 6tisch design team -- zero-touch vs one-touch X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 13:22:15 -0000 Randy Turner wrote: > We do not have zero or one-touch process, but we do have equivalent > 802.1AR device certs - that=E2=80=99s about the only thing we have in= common > with your item (b) below=E2=80=A6 Does a technician have to touch the device before it can join the MESH? --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Tue Jun 14 16:34:13 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4C12D19B for ; Tue, 14 Jun 2016 16:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Bv79YIGNqy-f for ; Tue, 14 Jun 2016 16:34:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C192612B053 for ; Tue, 14 Jun 2016 16:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3138; q=dns/txt; s=iport; t=1465947250; x=1467156850; h=date:from:to:subject:message-id:mime-version; bh=0bPpMFbFgDFYfNGUzZaCiu9nkooYL3YokHF6r4oTHUc=; b=AiD8QfD0+x++a56rDRQliNeEIIju2Gvp00rNDwC12suJySEud/xw5OiR CNtcLnEDG+0O/ZCyx8OQNUxdnV+Qw1wEpCqhB43/XZK4tgZ8SbpF3fpbL gJFC7cuV27YZcJD6mrxojrP75nNj8LtCZdCea/88NRqlO+6vqnSW+Cniy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgCLk2BX/5NdJa1dgz6BU7s4I4FWh?= =?us-ascii?q?044FAEBAQEBAQFlJ4UMezQFXIgwnQGgawEKAQEBI48GDwIBhXcFjXB0iX+BMYx?= =?us-ascii?q?uCo8ij3QeNoQOHDKIU4E1AQEB?= X-IronPort-AV: E=Sophos;i="5.26,473,1459814400"; d="scan'208";a="113329152" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 23:34:09 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5ENY90S004153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Jun 2016 23:34:09 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5ENY8wZ017820 for ; Tue, 14 Jun 2016 16:34:08 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5ENY8tk017819 for anima-bootstrap@ietf.org; Tue, 14 Jun 2016 16:34:08 -0700 Date: Tue, 14 Jun 2016 16:34:08 -0700 From: Toerless Eckert To: anima-bootstrap@ietf.org Message-ID: <20160614233408.GI31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 23:34:12 -0000 Thanks for starting the discussion about how to encode the parameters needed for the ACP in the LDevID. Wanted to summarize so folks, especially those who where not on the weekly call can chime in, and propose one encoding as well: So, For the ACP we had agreed a long time ago that we would "somehow" encode the IPv6 address used by the ACP and the domain-name of the ACP into the LDevID. The IPv6 address is lifetime stable, aka: an identifier, so appropriate for the LDevID. One highly desirable goal of the AN certificate is that it could be used not only for ACP forming but also for other purposes. Therefore, in an ideal world the cert parameters used to encode domain-nae and IPv6 address should be newly defined parameters: This would allow that any other use of the certificate could freely choose its parameters in the cert and not be in conflict with the ACP IPv6/domain-name. During the call Max and MichaelR heavily chimed on a pragmatic approach where we would not define new parameters, because that could easily break any pre-existing ASN.1 parser in any code that would see the certificate. So we ended up discussing which existing parameter would least collide: 'subjectname' and 'ou' parameters are already heavily used so not good contenders when we want to avoid conflicting data. MichaelR suggested AltName, which is a list of "names", each one with a type. IP address and Domain-name are both types. We discussed how those could be used. - It is very likely that a Domain-Name might already be used for some other purpose. Of course it is possible to have multiple Domain-Names, but then it wuold be tricky to figure out which of the domain names is the one of the ACP (possible, but tricky). - An IPv6 address seems to be much less likely to be used, Max was saying some systems using certs to authenticate IPsec connections might use them though (if i remember correctly) There are a few other AlName types, but most of them where structured, eg: similar to subject-name with 'ou' fields or the like. So: My Favourite is actually the rfc822addr. Aka: An email-address: anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.org Aka: The domain part is simply the domain name for the ACP. The user-name part is a fixed username value of "anima.acp" followed by +, followed by the IPv6 ACP address. Not a new field but existing. Very little used. If it was ever used, it would most likely be informational, aka: not used in any protocol, except if it was a user-certificate, which is most likely exactly what an AN domain-certificate is not. Encoding is choosen to make it explicitly recognizeable by humans and machine process, in case there is actually another email address. Worst case: This address format could even be used as an email address, and given how the IPv6 address is after the +, it actually is to most modern email systems just a single user (anima.acp) with just a modifier part (ipv6 address), so easy to set it up to be routed to one mailbox if anyone desires to do so. Cheers Toerless From nobody Tue Jun 14 19:20:09 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95BF12DAF4 for ; Tue, 14 Jun 2016 19:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KBO6c-fZFVoH for ; Tue, 14 Jun 2016 19:20:06 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C3112DAED for ; Tue, 14 Jun 2016 19:20:06 -0700 (PDT) Received: by mail-pa0-x22d.google.com with SMTP id b13so2400128pat.0 for ; Tue, 14 Jun 2016 19:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0QVOjHiG1adW99alLTB4VolgNzwYhL+BiFwSVTytBk8=; b=lAUB06OlrzTzPEMktInBIIx1cpTd03L3KFTXgkK6ZOxe1JmZGl6WGlFLmMbB/0LSXY jzcBqxRRwXKqsvl4852qGnTwS8yIzzYV8pcFpzEELqUO7ta5sZP+n6qNQZgGsSFaU9fn pEipliU2lfL0u1g1uqLqAeI+RbvEbQHdM/zhF5qhshjUt0UwaIV6cnuL3exRdlNN3Grl kK5h2X2JpWRPekZg+9c2qAQpgHqIEuXY7oqeV026QLrEqyDNHcgr+8h8QGWONK95gQh6 6Dw8JWmmIbCkGL0zLCbxm+f0d5H2UKLiUjcUH0JF16UbfpHjOd4jhuwmgnaiPIlt8/5+ 87eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0QVOjHiG1adW99alLTB4VolgNzwYhL+BiFwSVTytBk8=; b=VXAvYWjHqMyMenZjEz0xPmJcaV1zkpDdGvvBDQ/cvxVU1dgNDEm4gVLM8cXzeoi8ao g4RZ9Rv/lk0TBc5zlBjKagV6WYZLkfEiqRfzNoW15XtKmJobMuLwXSrchwbGLGsNdQSR lJo6LKCtDSWhmCsyOY7Jn6CcXuQIUH49wDKpDjFJk/qyhjli1qhFqGIiXONP8SHP29qO ZRT/lwK9PBcvk8pBiNNvX7HpZmVxflN+SqN213INueljFIUOCI02UyFKnQdqMVm7EjLP i7GDhLBEiEwlNeMmUZrbe1240/bgqf0wmqXSXsW4KKOdml+G0IPUgZGt1hM42oyLlTZk ctcA== X-Gm-Message-State: ALyK8tKxyZ8NG4XLrXdH39OBitPMRgETCG0cHmVAulJGXosyYzJJZVOyUo15tNfqI+cocQ== X-Received: by 10.66.73.71 with SMTP id j7mr954369pav.109.1465957206023; Tue, 14 Jun 2016 19:20:06 -0700 (PDT) Received: from ?IPv6:2406:e007:6d1a:1:28cc:dc4c:9703:6781? ([2406:e007:6d1a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ym9sm18705263pac.25.2016.06.14.19.20.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2016 19:20:04 -0700 (PDT) To: Toerless Eckert , anima-bootstrap@ietf.org References: <20160614233408.GI31598@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 15 Jun 2016 14:20:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160614233408.GI31598@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 02:20:08 -0000 On 15/06/2016 11:34, Toerless Eckert wrote: ... > The IPv6 address is lifetime stable Define lifetime please. ... > So: My Favourite is actually the rfc822addr. Aka: An email-address: > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.org I've got no strong preference here but I want to add a constraint. It's essential that if we include a literal IP address, it is canonical so that text comparisons will always succeed. Therefore following RFC 5952 is a MUST (even though that RFC itself is only a SHOULD). Therefore your example should be anima.acp+fd99:b02d:8ec3:0:200:0:6400:1@example.org (and, btw, anima.acp+fd99:b02d:8ec3::200:0:6400:1@example.org would be incorrect even though it's the same binary address) Brian From nobody Tue Jun 14 19:24:46 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8312D866 for ; Tue, 14 Jun 2016 19:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 TU1j5WnfUaj2 for ; Tue, 14 Jun 2016 19:24:43 -0700 (PDT) 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 9A05112D53B for ; Tue, 14 Jun 2016 19:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1465957483; x=1467167083; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=yEN8DDp6H3bRUXmkU9J6bLbxTj7z2ZLrJH4WnxFHZNQ=; b=bRPLq9mC3jbNqE3u4psJ/PnvnKGyzcVKMIZq3ZyfITLXbREj837rVJm0 yYkyzGd4QXsN/hFwnRNdoTCjVoZl23f9TK5or2oZLvKYVEVPNrJ18AWWr cmWsLjRp1Hlur6XU2c8+6SdoCHycHDENoykJay++MaVEzOtz01aHMES4k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAru2BX/5BdJa1dgz6BU7s5gXmGF?= =?us-ascii?q?wKBMTgUAQEBAQEBAWUnhEwBAQQ6PxALGAklDwVJE4gwvWsBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEcinSEEhEBhXcFjmSEX4Ugjh8KgWmEUohnj3QeNoQOHDKIU4E1A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.26,474,1459814400"; d="scan'208";a="118840306" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 02:24:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5F2Ogu4014837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2016 02:24:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5F2OgX6022535; Tue, 14 Jun 2016 19:24:42 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5F2OfKo022534; Tue, 14 Jun 2016 19:24:41 -0700 Date: Tue, 14 Jun 2016 19:24:41 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20160615022441.GN31598@cisco.com> References: <20160614233408.GI31598@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 02:24:45 -0000 On Wed, Jun 15, 2016 at 02:20:07PM +1200, Brian E Carpenter wrote: > On 15/06/2016 11:34, Toerless Eckert wrote: > > ... > > The IPv6 address is lifetime stable > > Define lifetime please. As long as the cert is valid. > ... > > So: My Favourite is actually the rfc822addr. Aka: An email-address: > > > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.org > > I've got no strong preference here but I want to add a constraint. > It's essential that if we include a literal IP address, it is canonical > so that text comparisons will always succeed. Therefore following RFC 5952 > is a MUST (even though that RFC itself is only a SHOULD). > > Therefore your example should be > > anima.acp+fd99:b02d:8ec3:0:200:0:6400:1@example.org > > (and, btw, > anima.acp+fd99:b02d:8ec3::200:0:6400:1@example.org > would be incorrect even though it's the same binary address) Ack. I continue to copy & paste IPv6 addreses from some random Cisco IOS CLI, which alas is not RFC 5952 compliant ;-( Cheers. Toerless From nobody Mon Jun 20 00:41:56 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54112D804; Mon, 20 Jun 2016 00:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, 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 2FFT5ACHphsv; Mon, 20 Jun 2016 00:41:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C2212D5D2; Mon, 20 Jun 2016 00:41:49 -0700 (PDT) Received: from [192.168.10.132] ([80.92.114.100]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LmKOI-1bnPNM2Fgg-00ZxkC; Mon, 20 Jun 2016 09:41:42 +0200 To: Michael Richardson , Samuel Erdtman , anima-bootstrap@ietf.org, anima@ietf.org References: <14558.1465237865@obiwan.sandelman.ca> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <57679E36.1060806@gmx.net> Date: Mon, 20 Jun 2016 09:41:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <14558.1465237865@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO" X-Provags-ID: V03:K0:rML6Ak0rb3RQp27Z/FRXCbryheVgZDHOSFWdnfBTlxtta25ghQK OxLTBlYNvq1rUsmRN+pgH+abEviVjlFdIGpAD8qC5ACfozuBu2GGA+sziCNurF8xAxTvH0z S00/DbuW7KC7rPkPR/wOfFzPhsbygVUuz3hbqWZYq1jDNEXqq22pZ7BUMGEn7GyvHdDlPuy 6gnwBrhiVnD3QFmb3Iq8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:0FdlAYwqIoM=:GxhHeIiIbD1jtF2/ShrJmt rJMPqhUULR6INmujN/YmDyVopLSbnICQ3vr4Eugz4UTEzkqmocNI4fN56HLS4xdStTmrkTTgb kRVf5oY0ZP/wWYtUbjoDIA3rVII0pebDvWtWXlhC+DbQKOQee43QyO1VGypn2YiXivT8Zw4wf hpx6o8izvAzo620cg8olxfLv0A8sgHNDdUwD0zAZrJcztS4xnoMtkW1+OmfsSUX9tCQmP8FyH qCyf6uzqLJRETUf2Oec/hTkHZTecsZMle1jaGjbqK+Ow/JFily9dAQmV/8EuiZYBDip1dyjv4 nZhaDaYLPKzXrFUz3sW0W4aMmC7w97Xk0Dl6DSrrLQP4PccRfGQmvSswW3MoTIHobdRx/lzle DujlDzas8qZ77Oh7yMGMf/S1OshrgLos/nX/0rYuQI0FoYwdCLgHB8Gr9saGWyfsW9LIcnFd9 SwBIkE8h7K6St576Aq+KqPCe5WUc0mSyFusLtoLprtKI+1HmW8QrTysZvwep87eGonvVjht9g UbJ4ouxdTpKmX91107hdhf5YCpVZ3Zj2MYEdwH205pWxO9yi0/vAEfN5m5GUIW/FLj7XogKc6 Xr58B1PLoMXhIgsfkcynjazDNe6ogC8lT+gKbKjxWp/1atwKwDK5H40FYgoMOATD4eMxYkPYX SsUpXMGo8NeBWds3jF118XUT4Kp8eWdc5/HmiLb00fdMdcOP6OdeRtdAH1Hr2emyc2oUgVA1k NYyNYwc7btVwbPrWo4rQNKZlkxOuHy/r+yEyTc/cdbpQ0061zo0og529/8o= Archived-At: Cc: Julien Vermillard , Shahid Raza , "ace@ietf.org" Subject: Re: [Anima-bootstrap] [Anima] [Ace] Constrained Environment PKI enrollment X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 07:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Michael, it depends what "bootstrapping" means. We have a key distribution mechanism in the OAuth-ACE document (which is relevant to this specific discussion thread). Ciao Hannes On 06/06/2016 08:31 PM, Michael Richardson wrote: >=20 > Samuel Erdtman wrote: > > The company I previously worked for where looking into adopting E= ST for > > this purpose, the benefit of EST compared to cmp or scep was that= it > > defined the process for server side generated keys, which could b= e > > beneficial if key generation would be to cumbersome for the devic= e or > > if you don't trust the > > device to generate a "good" key. >=20 > Hi, these are definitely important considerations. > I would invite you to read the ANIMA bootstrap keying documents, and > possibly join the design team. > At this point I believe the bootstrap is out of scope for ACE. >=20 > We are considering whether to use OSCOAP for 6tisch though. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXZ542AAoJEGhJURNOOiAteIwH+wdjEKA6C8ccnpnRtazcPf0j 3m3loppRcCUECOaXIY/QY9jLneXkSLuFLZMPIwxEaQYsjF4CaA2zG3hFerSd1szV b8bLYYyVVVplLwHHP0uOgvfXOi/1bovx5Nd3s3XbzzA5A6qBoo4PcX5A6GZhsDGB 9NP+DcGE4Cg35yiymrK60E+rSlknCCcxZE+DeMgnuU8iOo/rD1vk6KcpWNIKsuvu uJfF5cw2IH0jK1hO/FjPkJj+lUAM9UTpG3knNmhs8Wy6XN+xjcj6lPq6qNYWgApF Fm7vXgWoqCGG4l6uS0J7xwrYVpPn/f3Vevo4lE223Jklg4ji191U0TIfdk5yRFk= =e8m7 -----END PGP SIGNATURE----- --LXwqBPRfDg5Q8hK7SDdwJht2FtKMOi7EO-- From nobody Mon Jun 20 10:25:43 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2FA12D839; Mon, 20 Jun 2016 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 V50z7WsFTRxl; Mon, 20 Jun 2016 10:25:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E35512D838; Mon, 20 Jun 2016 10:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2650; q=dns/txt; s=iport; t=1466443540; x=1467653140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hF4iKYZm1fgaXotTnw3uubQPoB6BopIJ4vgf3MGdHaM=; b=gYOfmWooGZpVHVvJdf07prFpFkfNWyDLCo4+hPrm43PLNzo3r0iU86vX xUmSXULNAwZ1SK0/P8RLx2dvl9v5duVQItu1k7CJfRDWy9YKIP393HrtH pnICF6jdOE6wlXDmtVlLiiQDP2qUhqmtWUo6ADpm2ph8nWi0MN87wj4aW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAPJmhX/5pdJa1dgz5WfQa6bYF6F?= =?us-ascii?q?wuCPoM3AoE0OBQBAQEBAQEBZSeESwEBAQMBAQEBawsFCwIBCBguJwslAgQOBYg?= =?us-ascii?q?WAw8IDsEeAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWIHgiCToJDgWcWgyyCLwWYd?= =?us-ascii?q?gGGBYgkCoFfh3+FOo92AR42g3BuiUl/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,499,1459814400"; d="scan'208";a="120601083" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 17:25:39 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5KHPdF7004967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 17:25:39 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 12:25:38 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 12:25:38 -0500 From: "Max Pritikin (pritikin)" To: Hannes Tschofenig Thread-Topic: [Anima-bootstrap] [Anima] [Ace] Constrained Environment PKI enrollment Thread-Index: AQHRysc5Ayl2YWl+EUKJLE6BGfIPoZ/y78kA Date: Mon, 20 Jun 2016 17:25:38 +0000 Message-ID: References: <14558.1465237865@obiwan.sandelman.ca> <57679E36.1060806@gmx.net> In-Reply-To: <57679E36.1060806@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , Shahid Raza , "anima-bootstrap@ietf.org" , "ace@ietf.org" , Julien Vermillard , Samuel Erdtman , "anima@ietf.org" Subject: Re: [Anima-bootstrap] [Anima] [Ace] Constrained Environment PKI enrollment X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 17:25:42 -0000 > On Jun 20, 2016, at 1:41 AM, Hannes Tschofenig wrote: >=20 > Michael, >=20 > it depends what "bootstrapping" means. >=20 > We have a key distribution mechanism in the OAuth-ACE document (which is > relevant to this specific discussion thread). >=20 > Ciao > Hannes Hannes, are referencing this statement? https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02 This framework supports a wide variety of communication security mechanisms between the ACE entities, such as client, AS, and RS. We assume that the client has been registered (also called enrolled or onboarded) to an AS using a mechanism defined outside the scope of this document. In practice, various techniques for onboarding have been used, such as factory-based provisioning or the use of commissioning tools. Regardless of the onboarding technique, this registration procedure implies that the client and the AS share credentials, and configuration parameters. These credentials are used to mutually authenticate each other and to protect messages exchanged between the client and the AS. My working definition of bootstrapping is exactly the things that are decla= red out-of-scope in the ace-oauth-authz doc.=20 If you meant a different doc could you provide a more specific reference? T= hanks, - max >=20 > On 06/06/2016 08:31 PM, Michael Richardson wrote: >>=20 >> Samuel Erdtman wrote: >>> The company I previously worked for where looking into adopting EST for >>> this purpose, the benefit of EST compared to cmp or scep was that it >>> defined the process for server side generated keys, which could be >>> beneficial if key generation would be to cumbersome for the device or >>> if you don't trust the >>> device to generate a "good" key. >>=20 >> Hi, these are definitely important considerations. >> I would invite you to read the ANIMA bootstrap keying documents, and >> possibly join the design team. >> At this point I believe the bootstrap is out of scope for ACE. >>=20 >> We are considering whether to use OSCOAP for 6tisch though. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap