[Anima-bootstrap] notes from 2015-12-03 design team meeting

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 07 December 2015 17:37 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 2DC141AD06B for <anima-bootstrap@ietfa.amsl.com>; Mon, 7 Dec 2015 09:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.18
X-Spam-Level: **
X-Spam-Status: No, score=2.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 zh9Hi3Pb_Y4L for <anima-bootstrap@ietfa.amsl.com>; Mon, 7 Dec 2015 09:37:04 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765E81AD071 for <anima-bootstrap@ietf.org>; Mon, 7 Dec 2015 09:37:02 -0800 (PST)
Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 99A8F22086 for <anima-bootstrap@ietf.org>; Mon, 7 Dec 2015 12:37:00 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 7380661F6E; Mon, 7 Dec 2015 12:36:56 -0500 (EST)
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.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 07 Dec 2015 12:36:56 -0500
Message-ID: <8242.1449509816@dooku.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/3PTrqZ6Jp6LmvAxMtT7ptJlKGMI>
Subject: [Anima-bootstrap] notes from 2015-12-03 design team meeting
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: Mon, 07 Dec 2015 17:37:06 -0000

This meeting occured at 2015-12-03 11:00 EST, 1600 UTC on a IETF webex,
(but, we forgot to hit record, I think)
and used the IETF etherpad for note taking and discussion.

Present were:
        Michael Richardson,
        Peter van der Stok,
        Carsten Bormann,
        Michael Behringer,
        Max Pritikin,
        Toerless Eckert,
        Robert Cragie

Topic for this week was contents of certificate that will be provisioned
via EST.
(Topics for next two weeks:
        1. PROTOCOL STACK              2015-12-10.
        2. DISCOVERY MECHANISM         2015-12-17.
)

We discussed some of the question as to what the new node does to get online
enough to get a connection to the Domain registry, and the text of
anima-bootstrap section 3.1.1 was posted, and then amended as follows at
REVISED311 below.

The core of the discussion was then around the question of what shows up in
the resulting Domain-specific certificate that the registry issues as the
LDevID. Is it related to the IDevID contents, and do we have a strong enough
specification in 802.1AR?
{{802.11AR drafts are at: http://www.ieee802.org/1/pages/802.1ar.html
           and if you enter your email address at:
           http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf

and section 7 details the contents, including:
     version, (certificate) serialNumber, signature, issuer,

7.2.8 subject
      The DevID subject field shall uniquely identify the device associated
      with the particular DevID credential within the issuer’s domain of
      significance. The formatting of this field shall contain a unique X.500
      Distinguished Name (DN). This may include the unique device serial
      number assigned by the manufacturer or any other suitable unique DN
      value that the issuer prefers. In the case of a third-party CA or a
      standards certification agency, this can contain the manufacturer’s
      identity information. The subject field’s DN encoding should include
      the “serialNumber” attribute with the device’s unique serial number.

7.2.9 subjectAltName
      The non-critical DevID subjectAltName extension may supplement the
      subject field identity information as specified in RFC 5280 by
      containing a hardwareModuleName as specified in RFC 4108 [B22].

So essentially 802.1AR says to have a DN, says nothing other than it should
include a serialNumber, but doesn't say anything about the format of that,
and then punts to RFC5280 and RFC4108.


An exaple was pasted in from a Cisco CPE device:

Certificate
  Status: Available
  Certificate Serial Number (hex): 138BA1550000002D9F7A
  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)
    cn=C819HWD-A-K9
    serialNumber=PID:C819HWD-A-K9 SN:FXXXXFZ
  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

NOTE: because the unique inforamtion is the vendor information (who signed
this cert) and the serial number (from the subjectname) these need to both be
moved, in some fasion, to create a unique identity within the domain. For
example: SHALL copy the "issuer o=Cisco Systems" into the subject of the
LDevID.

It was noted in the call that the serialNumber attribute in this example here
was not just a number, as one might expect from 7.2.8, but also includes the
model (which is redundant with the CN), and also text "SN:" and "PID:".

We would expect the Domain registrar to take this SN, and attach to it as
part of the DN, the vendor name, because the issuer will be the domain
registry.

So the resulting Domain (LDevID) Certificate subject name in this case will become:
    o=Cisco Systems, Serial Number: PID:C819HWD-A-K9 SN:FTXXXXXXX

Thus the 'o' field of the LDevID is the original issuer thus providing
   uniqueness for all certs.

subject name = "Cisco Systems; PID:C819HWD-A-K9 SN:FTX171585FZ"

It will be difficult to make a normative reference for this. Perhaps use the
'authoritykeyIdentifier' instead? Less human readable though.

802.1AR s7.2.4: "Because uniqueness cannot be guaranteed, the issued
        DevIDcredentials contain the authorityKeyIdentifier extension".

During discussion it was pointed out this could be mapped to a human readable
value by the registrar (e.g. authoritykeyIdentifier-X = Cisco and -Y=Juniper)

QUESTION: is there some mapping to the ip address issued?

PRIVACY OBSERVATION: with IKEv2, and TLS1.3 (but not TLS 1.2), the certificate
        contents are not visible to passive eavesdroppers during key agreement.

MCR wondered on the call if we should provide some guidance on how/where to
point for CRL distribution point for 802.1AR IDevID; is concerned about
vendors using their marketing web sites for critical infrastructure use.

Toerless pastes current LDevID has been assigning at Cisco Autonomic "lab":

Certificate
  Status: Available
  Certificate Serial Number (hex): 04
  Certificate Usage: General Purpose
  Issuer:
    cn=ANRA-CS
  Subject:
    Name: 0200.0000.6400-3
    Serial Number: PID:Unix SN:101
    ou=neat.org+serialNumber=PID:Unix SN:101   <-- should include the original vendor information for multi-vendor deployments
    cn=0200.0000.6400-3                        <-- mac address of the registar plus the serial number of the device "-3" (in this example)
  Validity Date:
    start date: 10:45:21 CET Dec 2 2015
    end   date: 10:45:21 CET Dec 1 2016
  Associated Trustpoints: AN-Domain


Explanation: "0200.0000.6400" is mac address of *registrarD* -3 is the third
             certificate issued, so it's unique.
    "PID:Unix SN:101" is what the product provided.


REVISED311:

    Current text of section 3.1.1 (with modifications here)
   1.  MUST: Obtains a link local address using either IPv4 or IPv6 methods
       as described in [[EDNOTE: we need a reference:]].https://tools.ietf.org/html/rfc3927: Dynamic Configuration of IPv4 Link-Local Addresses

    only ipv6 link local (not ipv4)
reorder to #1


   2.  MUST: Attempt to establish a D/TLS connection to the next hop
       neighbor at a well known AN port building on the [[EDNOTE: AN
       node discovery discussion, need a reference??]].  [Toerless to
       provide updated text]
       reorder to #??

   3.  MUST: unsecured-GRASP as a link local discovery method?
       [Toerless to provide updated text]
       reorder to #4

   4.  MAY: Performs DNS-based Service Discovery [RFC6763] over
       Multicast DNS [RFC6762] searching for the service
       "_bootstrapks._tcp.local."
reorder to #2.

MCR suggests "anycast" here as an alternative to mDNS or GRASP. [ref: RFC4786? RFC7094?]
          https://tools.ietf.org/html/rfc2526 and https://tools.ietf.org/html/rfc4291

          argument in favor of mDNS: the complexity addresses real problems that must be addressed for consistent operations.
          toerless is worried about the multiple DNS operations (chasing PTR records)

   5.  MAY: Performs DNS-based Service Discovery [RFC6763] over normal
       DNS operations.  In this case the domain is known so the service
       searched for is "_bootstrapks._tcp.example.com".

   6.  MAY: If no local bootstrapks service is located using the DNS-
       based Sevice Discovery methods the New Entity contacts a well
       known vendor provided bootstrapping server by perfoming a DNS
       lookup using a well known URI such as "bootstrapks.vendor-
       example.com".


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