[Anima-bootstrap] minutes from 2016-05-03 design team meeting

[Michael Richardson <[e-mail]>]

Our regular meetings have resumed after a break around IETF95.
They are now Tuesdays at 17:00 Paris time.
(That's 11am EDT, 9am Mountain, and 8am Pacific for now)
The webex details are:
    https://cisco.webex.com/ciscosales/j.php?MTID=m0c4d4685fe5013c21cf8a36226ce4620
etherpad:
    http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true
    (note typo in boostrapping)


2016-05-03
People present:
       Michael Richardson
       Max Pritikin
       Toerless Eckert
       Michael Behringer
       Peter van der Stok.

Proposed agenda:
Agenda:
    1) recap ownership voucher discussion from list [delay w/o Kent]
    2) what elements go in (LDevID) cert to support ACP (see notes from 4/5)

Some discussion about name of protocol and desire to pronounce it "brewski",
i.e. BRSKI --- proposed name: "Bootingstraping Remote Secure Key Infrastructure"

ownership discussion:

1) clarify exactly which brski message the onwership voucher occurs: s5.3

in anima the client is always authenticated so we only send a single
audittoken/ownershipvoucher

this constrasts with netconf where client is NOT always authenticated so we
send a list of ownershipvouchers
     - netconf does this to allow the endpoint device to hide its identity
     (but really, it is just being vague about identity)

ACTION ITEM: need a clear discussion of the privacy model in each case

if we support a list format can we minimize the amount of different
processing that occurs. is it: token1, token2, token3
           or
           tokenlist (1,2,3)

   - is the token encrypted in some format? for example lookup the public in
     a db and use it or use a known symetric key doing this might allow
     responses to unauthenticated clients w/o violating infrastructure
     privacy?

 - by hiding the device identity during DNS-SD/DHCP the device either has to
   do brski style multiple attempts or leak some hints to DNS-SD/DHCP which
   is both an information leak and adds complexity to these protocols [max's
   editorial comment]


2) elements w/in cert to support ACP
    ]] humour insert due to mishearing: no, not elephants. we want snakes on
        the ACP plane. (the snakes in spain fall mostly on the ACP plane) [[

we had some discussion about what we were talking about.
Some confusion that we were speaking about the LDevID contents that will be
provided back to the client.  The confusion is because we are talking about
things that show up in the IDevID that might need to be added to the LDevID,
and how much of this can be a) trusted by the domain, b) rendered into the
LDevID certificate in a fashion that is unique within the domain.

ACTION ITEM: we need some clear algorithm/explantion of who (client vs domain
       registar) is in control of which parts of the resulting LDevID.

       section 5.1 discussion of 802.1AR as client identity w/ certain
       subfields detailed.

The specific concern was that the CN would be overused in the IDevID, and
contain things that would be useful to have in the LDevID, but the registrar
would replace the CN with a locally meaningful name.  The conclusion was that
things that needed to be preserved would have to be properly placed in other
subjectAltName OIDs.

I looked back through the notes to see if I could find the IDevID/LDevID
certificate example from Toerless, finally found it:

Example certificate (IDevID, I think) from before:

   Certificate
     Status: Available
     Certificate Serial Number (hex): 138Bxxxxxxxxxxxxxx7A
     Certificate Usage: General Purpose
     Issuer:
       cn=Cisco Manufacturing CA
       o=Cisco Systems
     Subject:
       Name: C819HWD-A-K9
       Serial Number: PID:C819HWD-A-K9 SN:FTX1XXXXZ
           (this is the x500 serialnumber attribute under the subject name)

    CRL Distribution Points:
       http://www.cisco.com/security/pki/crl/cmca.crl
     Validity Date:
       start date: 20:38:14 MET Apr 12 2013
       end   date: 20:48:14 MET Apr 12 2023
     Associated Trustpoints: CISCO_IDEVID_SUDI

{MCR had expressed surprise to see "marketing" web site www.cisco.com being
part of the CRL Distribution URL, but that's not relevant}


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-