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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 07 May 2016 19:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0F112D0E6 for <anima-bootstrap@ietfa.amsl.com>; Sat, 7 May 2016 12:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
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 yjAU36hMrOdr for <anima-bootstrap@ietfa.amsl.com>; Sat, 7 May 2016 12:35:15 -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 CA4F712D0B9 for <anima-bootstrap@ietf.org>; Sat, 7 May 2016 12:35:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F0B0120183 for <anima-bootstrap@ietf.org>; Sat, 7 May 2016 15:40:33 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 20517638BD for <anima-bootstrap@ietf.org>; Sat, 7 May 2016 15:35: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.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: Sat, 07 May 2016 15:35:12 -0400
Message-ID: <2428.1462649712@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/MbC_UiEhrs-2oqEU5KevDJTpANs>
Subject: [Anima-bootstrap] minutes from 2016-05-03 design team meeting
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 07 May 2016 19:35:17 -0000

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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-