[Iotops] fully defined constrained onboarding vs toolkit approach for draft-ietf-anima-constrained-voucher
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 29 April 2022 16:23 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CAFC15EE38; Fri, 29 Apr 2022 09:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGXQ4u-FleJI; Fri, 29 Apr 2022 09:23:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1B7C1854AB; Fri, 29 Apr 2022 09:22:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A0EEA39232; Fri, 29 Apr 2022 12:34:56 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UTJ4U9E4TZdo; Fri, 29 Apr 2022 12:34:55 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57DA539231; Fri, 29 Apr 2022 12:34:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1651250095; bh=t4kjAZJBHw+jezv3f/hgajUAKfrLZXYHE1PjP1I6tlM=; h=From:To:Reply-To:cc:Subject:Date:From; b=ADqwZ8IL3qV06KWTPe3aOy5lIUWqR8EU6rUXg+/66anAD+56TsJ5Ou40pcgw2N73B kjUNhRwPAsBJOJIsNAr4tIYx1PJf9d9FFJe9XY/7KJvHJny5M7F7HnxgDt5/8oJQDp Wm1E6Tywcx8lVMjxeest2SLCMZThn1OqSuTEbOtxJidozy8e9lXVTh3pfs+MJy3wLC /E1XlHcJ8qkuepLcnMu8J6B8Iz+nKsBQ2rg6x2NlJvefSmj6Ip27dVepRKekTDxWN7 dT8WO85yRWKYwW3dqRrtpymNAiWqTkIMQu3dOeV0LuW1xoYqu6oD9OP6W13V6uZqPF 2aNO/xniLLedw==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AD493E6; Fri, 29 Apr 2022 12:22:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
Reply-To: anima@ietf.org
cc: 6tisch@ietf.org, iotops@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 29 Apr 2022 12:22:05 -0400
Message-ID: <22450.1651249325@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/nqmVvWP40LPL6BwXfwlDMrRvS4U>
Subject: [Iotops] fully defined constrained onboarding vs toolkit approach for draft-ietf-anima-constrained-voucher
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2022 16:23:40 -0000
In discussions Thursday at the BRSKI design team meeting the following concerns arose. In the various deployment scenarios describe by draft-ietf-anima-constrained-voucher, section 10 (_Deployment-specific Discovery Considerations_) are we providing a complete (batteries included) solution, or is anima-constrained-voucher just a piece in a toolkit? This is in some ways the topic of draft-richardson-enrollment-roadmap. In section 10, we mention 6TISCH. A better reference to RFC9031 will be added. That would at present, provide for a one-touch PSK deployment that provides the network PSK via CoJP. It has been envisioned that the same channel could provide for onboarding using EDHOC to key OSCORE, and then CoJP to get the network PSK. (see draft-selander-ace-ake-authz ). But that's not ready yet. 10.2 is about GRASP. That could work fine for an ACP situation, but in the case of 802.15.4 (of any flavour), or 802.1x, how does the device get onto the network? One good answer is that it uses the certificate with EAP-TLS. Another answer is that it uses the resulting certificate with one of the 802.15.9 methods to establish per-node-pair keying. 10.3 is about mDNS. Same consideration as above. 10.4 Thread/MLE. Thread has its own commissioning protocol for network keys, so BRSKI is actually used for application onboarding. The answer is pretty good. 10.5 Non-mesh/CoAP If there is a network key, unclear how the device gets it. About half of the review comments on constrained-join-proxy are really confusion about where/how the join proxy is deployed and the rest of this context. The question to the ANIMA WG is whether we should be trying to solve all these situations, some of them, or none of the them. Maybe not a great question to have during WGLC, but better now than later. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Iotops] fully defined constrained onboarding vs … Michael Richardson