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

[Michael Richardson <[e-mail]>]

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

2016-08-16:
    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
   draft-ietf-anima-bootstrapping-keyinfra-03#section-5.3

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:
    https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-09#appendix-A.1

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
observed.

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
systems.

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-