Re: [Anima-bootstrap] minutes from meetings since IETF97

These are the previous meeting minutes:
      https://www.ietf.org/mail-archive/web/anima-bootstrap/current/msg00328.html" rel="nofollow">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" rel="nofollow">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/" rel="nofollow">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" rel="nofollow">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 =-