Subject: [Anima] FWD: ACME for devices side meeting

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jul 2019 00:00:15 +0200

Owen sent the following nice notes about the side meeting.
Will comment separately. Bcc'ing the original recipients.

On Wed, Jul 24, 2019 at 08:26:20PM +0000, Owen Friel (ofriel) wrote:
> Minutes from today's meeting.
> 
> General consensus that figuring out how to use ACME for issuance of device/client certs is a good idea
> 
> There are (at least) three related drafts in this space
> - draft-yusef-acme-3rd-party-device-attestation
> - draft-friel-acme-integrations
> - draft-moriarty-acme-client
> 
> draft-moriarty-acme-client
> - outlines several use cases for client and device certs
> - as Kathleen could not make the meeting, we didn't discuss this in detail
> 
> draft-yusef-acme-3rd-party-device-attestation and subsections of draft-friel-acme-integrations are trying to solve similar problems:
> - leverage a cloud service to assist in ownership proofs for devices
> - use ACME to issue LDevID certificates to devices
> 
> draft-yusef-acme-3rd-party-device-attestation
> - assumes devices have self-signed certs, not certs signed by a manufacturer private CA
> - The BRSKI-ACME flow Rifaat presented uses a vendor default BRSKI registrar, and is a reasonable starting point for device's getting certs from ACME
> - This flow is not currently documented in Rifaat's draft
> - We can probably avoid the need for ACME to understand the vendor's JWT
> 
> draft-friel-acme-integrations
> - documents (partially) the BRSKI-ACME flow but uses a local domain registrar, not the vendor default registrar
> 
> draft-ietf-anima-bootstrapping-keyinfra
> - underspecifies how the MASA should handle Voucher Requests directly from the Pledge i.e. the Cloud Registrar use case
> - Toerless suggests that this clarification could be a small standalone document
> 
> No draft currently sufficiently specifies how the pledge/device should generate a CSR subject/SAN that will keep ACME happy
> 
> The EST/BRSKI sections of draft-friel-acme-integrations, and draft-yusef-acme-3rd-party-device-attestation, probably need to be combined by a new draft
> - if the device is going to use a self-signed cert, then how the EST RA validates device identity needs to be specified as this is a change from BRSKI
> 
> The ACME subdomain use case needs to be split out from draft-friel-acme-integrations into a separate small document
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jul 2019 00:34:32 +0200

Some thoughts about draft-friel-acme-integration also after the ACME side meeting.

Talking to Owen after ANIMA, he explained the use case for his draft,
which would be great to include into a rev. At least i hope i wasn't
the only one to whom it wasn't completely obvious even without being
stated ;-))

The way i would desribe the use-case is this:

You are an enterprise or home, you may have some BRSKI like
infrastructure (cloud-based, local, whatever) that helps to auto-enroll
any type of devices you want to use in your network, but: Many of these
devices will have a web-server to access/control/use them, and when
you access them via a browser there is the issue that web browsers
will complain unless the device is enrolled with a certificate signed
by a public PKI CA (in the browsers TA list) and can be used to 
authenticate the domain name the device is using.

This is where ACME comes in because the key thing separating itself from
EST is that it has the mechanisms so RA (registrars) can provide proof
of ownership of a DNS domain/prefixes for which they can then request
certificates. At least thats how i understood the explanation given to me.

So, i would certainly welcome if we made sure BRSKI<->ACME can be made
to work well.

Another thing coming to mind: devices that have a web-server will
support TCP, so they won't pose the problem of having to change the
basic transport protocol to use for BRSKI, unlike the constrained "iot"
devices, where we have to use protocols like CoAP. And given how
we made sure that the ANI certificate pieces do not conflict with any
type of certifictes attributes required for "web certificates", this
should also all work well with not only BRSKI but even ANI (using
certificates with the ACP rfc822Name). At least this would be my hope,
and certainly something i would like to verify with ACME.

Cheer
    Toerless

On Thu, Jul 25, 2019 at 12:00:15AM +0200, Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 19:03:42 -0400

I was asked to decode words mangled at the mic at Tuesday morning's ANIMA
meeting.
The word was "MACsec", and 
    https://en.wikipedia.org/wiki/IEEE_802.1AE
    https://1.ieee802.org/security/802-1ae/        

provides a reasonable description, and probably the getieee mechanism
might get you a copy for free, but IEEE doesn't have a URL that
leads to the actual document.  I did read it once.
(One of the URLs in the wikipedia page leads to 404)

    https://ieeexplore.ieee.org/document/8585421
might get you the document if you have a valid password, which
I used to, but apparently not anymore.

Given my newly acquired understanding that MACsec applies on a per-port
basis, not on a per-VLAN basis, this means that it would be rather difficult
to do peer discovery and security for a L2-bridged LAN.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jul 2019 16:36:32 +0200

First of all, there is obviously an ability to filter out packets
NOT to encrypt. Otherwise you would have a lot of problems negotiating
the encryption keys. To the best of knowledge, what MUST be supported
in ethernet chips is such filtering based on ethertype because thats
whats being used also in 802.1x, the basic security architecture. See
ACP draft section A.10.2

Secondly, i was told (and this is where i have not tried to validate),
that MacSec should equally be able to utilize multiple keypairs,
probably mapped by VLAN or ethertype. But the question of course is
whether you want/can expect that MACsec MIC chips have that feature.

So, the most simple solution would be to put all of ACP onto a separate
ethertype, run that all in software (including existing encryption)
and use MacSEC to HW encrypt all other traffic. 

If you wanted to then also accelerate encrypted ACP with MACsec
itself, you would not actually use the new ethertype to encapsulate
the secure channel packets, but just negotiate a separate VLAN for
that. In which case you just use IKEv2 from the scure channel protocol
(as an example) to negotiate keys but instead of IPsec/ESP you use
MACsec/VLAN).

CHeers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2019 19:33:41 -0400

> whats being used also in 802.1x, the basic security architecture. See

Yes, but the key management packets can be packets that are "special"
at the MACsec level.

    > whether you want/can expect that MACsec MIC chips have that feature.

The people in the line behind me did not agree.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jul 2019 00:09:21 +0200

> Yes, but the key management packets can be packets that are "special"

My point was that the "special at MACsec level" propoerty that can
expected to be supported by MACsec capacle MIC chips is ethertype and
hopefully VLAN tag. But i don't think nothing else.

> The people in the line behind me did not agree.

Hmm... Don't remember if anyone else stated that there can be one one
keypair. As i said in the other mail, both a single and a douple keypair
solution are possible to build, i just think it would be nicer if ACP
can be separately encrypted from data-plane, but as long as ACP is
responsible to manage the encryption key, it can equally encrypt both
ACP and data-plane. Its just that right now, ACP is not optimized for
fast reconvergence, so a data-plane could converge faster and then it
might still need to wait for ACP. But thats solely a matter of routing
protocol and aliveness parameters of ACP/data-plane.

Cheers
    toerless

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2019 22:46:33 -0400

> keypair. As i said in the other mail, both a single and a douple
    > keypair solution are possible to build, i just think it would be nicer

It's not about keypair, it's about what IPsec would call the SPD, which is a
way to select which traffic goes into which tunnel.  I would also have
expected it to be able to select based upon VLAN tag and destination ethernet
type, but people said that wasn't so.

I would love to be told I'm wrong.
I can see if one was building the minimum viable solution that can deal with
state-level attackers on point to point fiber runs, that just encrypting
everything works well.  

    > if ACP can be separately encrypted from data-plane, but as long as ACP
    > is responsible to manage the encryption key, it can equally encrypt
    > both ACP and data-plane. Its just that right now, ACP is not optimized
    > for fast reconvergence, so a data-plane could converge faster and then
    > it might still need to wait for ACP. But thats solely a matter of
    > routing protocol and aliveness parameters of ACP/data-plane.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jul 2019 22:41:58 +0200

> type, but people said that wasn't so.

I think my reference was more to what chips can do as to what
necessarily existing standaerds may say. There is this one issue of
having an 802.1ae capable switch port connected via a hub to multiple
host, in which case you could imagine to use a different set of keys to
each host but the public vendor documentation i found was quite
inconclusive whether this actually works in todays products.

Your reference to IPsec is also another big question. 
Right now, there is all this convoluted, 802.1x and AAA server MacSec
session setup mechanism.  Which natively is asymmetric, and AFAIK,
the extensions to make it symmetric whee either done only very recently or are
still TBD in ieee.  One solution is just to leverage all of this and
just declare that nodes need to use and trust their ACP domain
certificates - and be done. It would just be anothrer parallel ACP
secure channel mechanism beside IKEv2 and DTLS.

Personally i would love a simpler mechanism, but there is a different
simpler/nicer architectural solution and a simpler/nicer programmatic
solution: The simpler architectural mechanism is to tie MacSec into
IKEv2. But who would be the critical mass of people doing that work.
It's not easy. The simple pragmatic solution is to put ACP on top of
some ethertype like EAPoL and exclude it from 802.1x, build normal IPsec
ACP and then have small new ASA that simply auto-instantiate existing
MACsec for the data-plane.

> state-level attackers on point to point fiber runs, that just encrypting

The fiber runs in my apartment complex are in rooms open to the public.
No need to hire overpayed federal employees to plug a fiber snooping
device into them. And the city wide fibers are either on open poles or
in digging distance of shovels through somebody elses garden (learned
that from comcast workers that dug up those gardens too to find the
shovel made fiber cuts).

Sorry. not directly on-topic but hopefully entertaining. 

If we want the least overhead solution, then its the last option i
mentioned. We did program that in tcl in a week as small ASA (send
random generated PSK to direct neighbor, auto-configure existing
MACsec to neighbor. Done). Of course this expects ACP to already be in
place, and if you can't exclude ACP from the MacSec encryption you have
to have a bit of logic in the ASA to avoid shooting yourself into the
feet.

Cheers
    Toerless

-- 
---
[email-masked]