[Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 16 August 2016 19:27 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C208212B00B; Tue, 16 Aug 2016 12:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id d-JyCUaPcFOw; Tue, 16 Aug 2016 12:27:14 -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 83BBD12D739; Tue, 16 Aug 2016 12:27:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id A5D98200A5; Tue, 16 Aug 2016 15:38:15 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 01C58639DC; Tue, 16 Aug 2016 15:27:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap <anima-bootstrap@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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 16 Aug 2016 15:27:12 -0400
Message-ID: <13187.1471375632@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eXGcXxkKHVGAInUybF1IDrIauyE>
Cc: netconf <netconf@ietf.org>
Subject: [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: anima-bootstrap <anima-bootstrap@ietf.org>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2016 19:27:17 -0000

We return to weekly meetings after a few weeks off for vacations and IETF96.

WEEKLY INVITE, SEE ANIMA BOOTSTRAP WIKI: https://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap

    present: mcr, max, kent, toerless, P. Kampanakis

We had three items on our agenda:
   1) recap on, do we need/want to write up an example ownership voucher.
   2) the level of detail/protocol around getting   the pledge to put the
      "right things" into the CSR.
   3) draft-pritikin-coap-bootstrap-00

I think that Kampanakis joined after I asked he was joining our team, being a
co-author of coap-bootstrap.  He is a Cisco person with ties to the EST
implementations at Cisco.

We started on item one, which was the question as to whether or not we needed
to have a standards track document that defined the onwership voucher.

The tl;dr conclusion was that we do need a document, but that it could be
Informational.  That it should be a WG product, not an independent
submission.  We did not rule out a standards track document as yet.

The ownership voucher, as conceived by

is created by the manufacturer, "signed" with a key the manufacturer possesses,
and then is verified by the device which the manufacturer created.  The word
"signed" is in quotes, because it does not have to be asymmetrically signed.
The exact details are essentially private to the manufacturer.

The netconf ownership voucher, as explained at:

describes a sample voucher in YANG.  Netconf is mostly consistent with the
view that voucher is a private matter, however there are some situations in
netconf where it may be necessary to distinguish one voucher from another.
In most cases (DHCP, HTTP) it is possible for the provider of boot
information to return a voucher specific to the device asking, but in the
DNSSD situation, the responder can not really provide customized replies,
so the likely reply is a set of group vouchers.  This requires that the
booting device be able to sort through the replies looking for one which
applies to it.  This requires some structure to the voucher, even if most
of the voucher can be proprietary.

In the ANIMA situation, there is an additional situation where we something
very similiar to the voucher, which is in the log provided by the MASA!
The MASA audit log is essentially a record of vouchers which have been

In discussion, we further acknowledge that in order to debug things in the
field, knowing what is in the voucher would aid greatly in diagnosing

We further discussed the question as to whether or not there were
confidentiality or privacy issues.  We conclude that:
   We believe there is no confidentiality requirement for vouchers.

   i.e. nothing breaks in the micro-cosm of a single device enrollment.

In the macro-cosm of thousands of devices and thousands of ownership
vouchers being observed, there are quite possibly privacy issues.

We do not think that we can or should encrypt the vouchers themselves; the
key management problem is large if each are encrypted seperately, and
if asymmetrically encrypted, then diagnostics are out.

We came up with three possible actions:
   3 paths forward:
     a) treat this as a hard requirement
     b) try to leave the door open for future work here
     c) declare totally out of scope.

proposed decision: (b) try to keep the door open but not address at this time.

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