[Anima-bootstrap] MB review of Bootstrap charter (was: a repost of summary)
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 25 June 2015 18:07 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45CD1A8AB9 for <anima-bootstrap@ietfa.amsl.com>; Thu, 25 Jun 2015 11:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MkM9_4jh5YU for <anima-bootstrap@ietfa.amsl.com>; Thu, 25 Jun 2015 11:07:45 -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 0C2D11A8A7F for <anima-bootstrap@ietf.org>; Thu, 25 Jun 2015 11:07:45 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CECE200A3 for <anima-bootstrap@ietf.org>; Thu, 25 Jun 2015 14:22:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A642A63AE8; Thu, 25 Jun 2015 14:07:43 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A10963AD9 for <anima-bootstrap@ietf.org>; Thu, 25 Jun 2015 14:07:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3C98@xmb-rcd-x14.cisco.com>
References: <11466.1435154789@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3C98@xmb-rcd-x14.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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-sha1"; protocol="application/pgp-signature"
Date: Thu, 25 Jun 2015 14:07:43 -0400
Message-ID: <19137.1435255663@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/bF9hxDKhZsHkdyFyEpJn8OzM3Bg>
Subject: [Anima-bootstrap] MB review of Bootstrap charter (was: a repost of summary)
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 18:07:47 -0000
Michael Behringer (mbehring) <mbehring@cisco.com> wrote: mb> - Probably a nit: I'm missing the words "trust infrastructure". To me, mb> we're setting up a trust infrastructure, and we also need to discuss mb> the setup of the registrar, CA, not only the bootstrapping mb> elements. The word "trust" is completely missing - is there are reason mb> for it? The document does discuss registrar, CA, etc, but we have not been discussing those in our meeting. I think that the interface to those things are relatively well described by current specifications: but there will be profile work require, I'm sure. mb> - Goal 1: Is this the certificate format and fields? I wasn't sure what "Goal" text you are referring to here, then I realized that you were referring to the DT Charter text that says: > Goal one: Provide a normative definition for the concept of a > Domain's Identity. I'm not sure that we have really much work to do in certificate format and fields. The IDevID 802.1AR document is woefully underspecified on what goes into the SubjectAltName, and I think we need to be more precise here, and maybe that will require a new document. (such as: https://tools.ietf.org/html/draft-richardson-6tisch-idevid-cert-01 which is entirely stolen from RFC3779 ) mb> - Goal 2: I think security needs to also be discussed in the reference mb> model, we need to see how we can split that? Or do you see that the mb> bootstrap doc would cover that all? Here is the text from the charter: > Goal two: Define the target underlying security model of an autonomic > network, in which autonomic devices are enrolled with a local > certificate (e.g: IEEE 802.1AR LDevID) identifying the autonomic > domain that they belong to by hash of the public key of the trust > anchor. I think that the important part for the reference model is that: "Devices have 802.1AR IDevIDs, with replaceable LDevIDs" Should the reference model/framework include ideas of device resell, and the problems of supply chain management? If so, then I would love to have a place to put those considerations. mb> - I think there is overlap with the netconf zero-touch work, and we mb> should probably be explicit: Do we want to find common groud (would mb> hope so), or is it too late? Since that has been discussed, we should mb> be explicit about this point I think. Which other groups do you have in mb> mind when talking about "adjacent IETF WGs"? Can we list them? I think that netconf zero-touch work is useful and interesting, but I also see it as in some ways completely unrelated. That might be just how I regard the work, as a kind of uber-secure, NAT and end-user friendly replacement for DHCPv4+TFTP to get configuration files/boot images. As such, in the netconf situation, devices show up on (preconfigured) networks, and call home (for various definitions of "home") to get a configuration has been determined by mechanisms out of scope. In ANIMA, devices only call home to establish ownership and to affect delegation of of trust. The network that they are "plugged" into may be hostile, may be unconfigured or mis-configured... Further, the goal of the bootstrap is not to establish the configuration of the device, but rather to build a trust relationship with other devices so that each device can derive it's own configuration. Having said, this the bootstrap work could be used to provide security to the zero-touch work, or the netconf zero-touch process could be used to install the locally significant certificates that bootstrap is about. Or EST or 6top or.. mb> - somewhere the charter should state more explicitly: Define protocols mb> and data models for the bootstrap process. I guess that's goal 3, but mb> it sounds cryptic. To me, we need 1) requirements, 2) a protocol, 3) a mb> data model, including certificate format and fields. Goal 3 is about how to use the LDevID; this might mean explaining how it fits into TLS, DTLS, IKEv2, DHCPv6, SEND or some other protocol that the signaling system might base it's security on. mb> - in the reference model I'm referring to the bootstrap process in a mb> new way, in the ASA thinking. There is an ASA for a new element, one mb> for the proxy, and one for the registrar. (Previously those functions mb> were included in the infrastructure, but logically they should be mb> ASAs). Do you agree with this thinking, and if so, should we adopt mb> this wording here as well? If you are saying that the proxy and the registrar are functions that the network should realize that it needs to provide, and therefore should be described as ASAs, then I agree. This implies that we have to run the signaling protocol recursively, and that we have to have more than one instance of the signaling protocol: one insecure instance, and possibly multiple secure instances. One shouldn't assume there is a single network being assembled.. after all, a field can contain many picnics: https://www.pinterest.com/pin/216595063299304430/ mb> - Do we want to include downloading a config? (I read "optimized mb> configuration distribution) - somehow that doesn't seem to be in scope, mb> in my reading. Can we exclude that? To me, the process ends when the mb> device has a domain cert. Max, can you say more about Goal five? mb> - The milestone is very cryptic. Are we planning a new spin of mb> draft-pritikin before the IETF? Or is this a completely new draft? mb> you say "draft(s)" - what does that mean? Yes, spin it. > Michael >> the charter for the WG, and the result is at: >> https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap Charter: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima-bootstrap] a repost of summary Michael Richardson
- Re: [Anima-bootstrap] a repost of summary Michael Behringer (mbehring)
- [Anima-bootstrap] MB review of Bootstrap charter … Michael Richardson
- [Anima-bootstrap] Crypto parameters [Re: a repost… Brian E Carpenter
- Re: [Anima-bootstrap] Crypto parameters [Re: a re… Michael Richardson