[Anima-bootstrap] minutes from meetings since IETF97
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 10 March 2017 02:24 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 845A4126579 for <anima-bootstrap@ietfa.amsl.com>; Thu, 9 Mar 2017 18:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 pILXPxDFa64G for <anima-bootstrap@ietfa.amsl.com>; Thu, 9 Mar 2017 18:24:57 -0800 (PST)
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 6F0A51294B2 for <anima-bootstrap@ietf.org>; Thu, 9 Mar 2017 18:24:51 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AFA622054E for <anima-bootstrap@ietf.org>; Thu, 9 Mar 2017 21:10:00 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8FA736381A for <anima-bootstrap@ietf.org>; Thu, 9 Mar 2017 20:47:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
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-sha256"; protocol="application/pgp-signature"
Date: Thu, 09 Mar 2017 20:47:13 -0500
Message-ID: <30346.1489110433@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/7VYnW-9vFsUxqrCrKWPIo6oM_UY>
Subject: [Anima-bootstrap] minutes from meetings since IETF97
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: Fri, 10 Mar 2017 02:24:59 -0000
These are the previous meeting minutes: https://www.ietf.org/mail-archive/web/anima-bootstrap/current/msg00328.html If I've posted a summary since, I can't find it in the archives. 0) we continue to meet at 15:00UTC each Tuesday. Please see meeting details at: https://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap the members on the web site say: Max Pritikin (editor), Michael Richardson (editor) Jason Coleman, Sandeep Kumar, Michael Behringer, Alper Yegin, Bing Liu, Brian Carpenter Kent Watson Sheng Jiang (wg chair), Toerless Eckert (wg chair) Typically we have the following people participate in the weekly calls. Michael Richardson Max Pritikin Kent Watson We are frequently joined by Toerless Eckert. We would welcome additional people/viewpoints. But there are a number in the above list which we haven't seen recently. Please chime in and tell us what you are up to, and what your take on the current situation is. The webex link is valid until IETF98. We expect to meet on March 14, but note that north american clocks will have changed, so it will be 11am EDT. We keep running minutes using the etherpad. Yes there is a typo in the link. 1) we posted -04 of anima-bootstrap prior to IETF97, and have been working on the -05, which will get posted this weekend. 2) since October, we posted three versions of draft-ietf-anima-voucher (some under the previous names draft-kwatsen-netconf-voucher, and draft-kwatsen-anima-voucher). 3) all of the drafts are revision controlled in git, and hosted on github.com, at https://github.com/anima-wg/ The bootstrap git tree contains a subdirectory minutes, which is the raw dump from the etherpad. These minutes are organized by topic with ideas taken from the raw minutes, rather than chronologically. TERMINOLOGY =========== We agreed to the terminology proposed from the 6tisch-security design team, and have made the changes in -05. Another email went to this list on that topic. HACKATHON ========= We discussed very early on what we would like to have to interoperate with at the hackathon. We concluded that exchange of vouchers and certificates would make the most sense, even if we were using USB keys or web pastebins for transport rather than HTTPS. As of March 7, after many discussions that lead many places, we have concluded that for IETF98, we will exchange JSON encoded vouchers in PKCS7 containers such are easily produced by cli tools. VOUCHER ======= The voucher format is described at: https://tools.ietf.org/html/draft-ietf-anima-voucher-00#section-4.2 and looks like: { "ietf-voucher:voucher": { "assertion": "logged", "trusted-ca-certificate": "base64-encoded X.509 DER", "owner-id": "Registrar3245", "unique-id": "JADA123456789", "created-on": "2016-10-07T19:31:42Z", "nonce": "987987623489567" } } The following table is now in the dtbootstrap-anima-keyinfra-05, section 2.2: |Assertion |Registrar ID |Pledge ID | Validity | |Log-|Veri- |Trust |CN-ID or|serial | RTC | Nonce | | ged| fied |Anchor |DNS-ID |number | | | --------------------------------------------------------------------| Audit | X | | X | | X | | X | -------------|----|-------|-------|--------|----------|-----|-------| Nonceless | X | | X | | X | | | Audit | | | | | | | | -------------|----|-------|-------|--------|----------|-----|-------| Owner Audit | X | X | X | | X | | X | Owner Role | X | ? | X | X | X | | X | -------------|----|-------|-------|--------|----------|-----|-------| Owner ID | | X | ? | X | X | X | | -------------|----|-------|----------------|----------|-------------| BearerVoucher| X | | wildcard | X | ? | -------------|----|-------|----------------|----------|-------------| MasterVoucher| | | wildcard | wildcard | X | | -------------|------------|----------------|----------|-----|-------| we had a lot of discussion about how each kind of voucher can be used, and what they mean. We have come dangerously close to writing a Use Case / Requirements section/document. REVOCATION of VOUCHERS ====================== Nonceless Vouchers can be issued in advance and stored for many years and used when a device is finally deployed. Reference to the owner by CA+DN (rfc7093 provides a way) permits the registrar's key to be cycled many times. The question has remained: do we need a way to revoke vouchers? If the answer is yes, we considered that maybe the vouchers should be cast in PKIX format as if they were certificates, such that we could use the same kind of CRL or OCSP mechanisms. We are not yet convinced of this; but we do think that we could include a serial number in each voucher such that we could, even if the voucher was not in PKIX format, use OCSP with that serial number. This discussion remains open. What definitely came out of this is that we need more text to explain how each voucher-type should be used to address particular deployment scenarios. From that, we also need to better define the deployment scenarios, probably giving them easily discussed names. BEARER VOUCHER ============== After much discussion, we decided that the operational security problems with providing for a bearer token lead us to conclude that we do not want to standardize one. We think that there are other ways to do almost the same thing. JWT / CWT ========= We discussed having the voucher be in JWT format, as described in RFC7519, RFC7517, etc. This would also permit switch to CWT format as described in draft-ietf-ace-cbor-web-token. This discussion is not over, but for the purposes of IETF98, this is out of scope. A JWT/CWT might look like: { "iss":"Registrar3245", "iat": 1478854302, "nbf": 1478824302, "exp": 9999999999, "cti": "987987623489567" "logged": "true", "aud": "base64-encoded X.509 DER", "sub": "JADA123456789", } CONCURRENT REGISTRATION ======================= We had a discussion over a few meetings about the how much we needed to say about pledges that see multiple Join Proxies, and which have the CPU/RAM to attempt to enroll over all proxies at the same time. One of the reasons to do this is because it eliminates concern where an attacker (operating a rogue proxy, or a fake JRC) attempts to sabotage the enrollment process by very slow TCP communications. The goal would be to annoy the operator who them chooses a less secure alternate mechanism, or the vendor provides some kind of backdoor. Setting "appropriate" timeouts could (and should) be done, but this may result in failures when the network is simply very congested. Doing the work concurrently avoids having any one attempt hold up the others; but as soon as one attempt succeeds, other attempts would be abandonned. We did not figure out how much text we need add about this, but we feel that there are no protocol concerns with concurrent join attempts. mDNS ==== AI: The M_FLOOD vs mDNS initial discovery discussion is not over, and we should invite the DNSSD/mDNS folks to come and make the case. This remains an Action Item, and we need to reach out to the proponents of mDNS to more clearly articulate the reasoning behind their preferences, and also to clearly explain how they would use mDNS. A major difference seems to be that mDNS would not support a passive (listen-only) mode for the pledge. It would have to do a multicast discovery for the service, announcing itself to the entire network. CoAP ==== We have removed the CoAP mechanism until we prepared to properly define it. IPIP ==== We have added an appendix to explain the IPIP proxy mechanism. It is no longer a MUST. Continued GRASP Proxy/Registrar discussion ========================================== A thread was posted to the list already about how we should properly do discovery of the registrar by the Join Proxy. CLOSING LIST? ============= Our WG chair has suggested that it is time to close the anima-bootstrap list. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima-bootstrap] minutes from meetings since IET… Michael Richardson
- Re: [Anima-bootstrap] minutes from meetings since… Michael H. Behringer