[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 =-
- [Anima-bootstrap] notes from 2015-12-03 design te… Michael Richardson
- [Anima-bootstrap] anima bootstrap meeting: 2015-1… Michael Richardson
- Re: [Anima-bootstrap] anima bootstrap meeting: 20… Max Pritikin (pritikin)