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

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2015 12:36:56 -0500

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Dec 2015 16:01:42 -0500

> 2. DISCOVERY MECHANISM         2015-12-17.

I hope that Toerless or Michael B, can articulate more clearly what is meant
by PROTOCOL STACK, as I have many possible interpretations.

Details to connect:
        https://ietf.webex.com/ietf/j.php?MTID=m09ce76fb7e9ae7af015d3033b42c54c2

meeting number:   649 770 742
Meeting password: bootstrap
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)

We will use the etherpad at:
   http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true
   (note typo in boostrapping)

I sent an ical invite to the list which is probably lost in list moderation.
This link might help:
  https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MHR0ajRtbDM2MnU1NmU2YW9ocWtrNGY2ZG9fMjAxNTEyMTBUMTYwMDAwWiBtY2hhcmxlc3JAbQ&tmsrc=mcharlesr%40gmail.com

It's at 1600UTC.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 10 Dec 2015 23:25:44 +0000

We ended up spending most of the 12-10 time on the “discovery mechanism” and will discuss protocol stack at the next meeting. 

M.Richardson, what I mean by that is: If GRASP depends on ACP and ACP depends on credentials and credentials depends on bootstrapping and bootstrapping depends on GRASP… then we have a circular dependency. Cutting this short somewhere means either finding adding the correct option statements to all of these protocols to cover secure and insecure states or (my preference) defining bootstrapping to _not_ depend any other anima protocol. (I recognize the value arguments and this is what we’ll discuss further next week).

- max

> On Dec 9, 2015, at 2:01 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap