Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 17:28:41 -0500

<#secure method=pgpmime mode=sign>

Hi Ash,
   I AM NOT A PKIX FAN.
   I hate it, BUT:

Ash Wilson <ash.wilson=[email-masked]> wrote:
    > application, hosted in the cloud. All sensors will use the city's
    > municipal wifi to connect to edge nodes.  I do not want to be bound to
    > selecting the same vendor for all sensors (I want best-of-breed), and I
    > do not want to operate my own CA. For my risk model, it's OK to use
    > mfr-issued device certificates for all of my sensors.

Could you explain a bit more about "operate my own CA".
What infrastructure are you willing to operate?

    >   Network access use case: I use cert-based EAP-TLS to provide network
    > access control for the networks my sensors and edge nodes connect
    > to.

But, which certificates do you use? The IDevID ones?
If so, do you just have a database which each EE certificate pinned?

    > In order to prevent the possibility of naming collision across
    > suppliers (which creates an opportunity for device impersonation,
    > improper network access, and unreliable data) I need to onboard all of
    > my devices to a single CA.

    > If I use DANE for device identity, I don't
    > need my own private CA, rather I only need to provide my RADIUS server
    > with a list of allowed device DNS names for the municipal sensor
    > network, regardless of device mfr or identity provider.

How is this different than providing a database of EE or public keys?

    >   Session security use case: My sensors connect to my edge nodes using
    > TLS.  With traditional PKI, I need to make sure that the trust store in
    > every sensor has a CA cert for my edge nodes. My edge nodes need CA
    > certs to accommodate all sensors which might need to connect to
    > them. Without DANE for client identity, I need to either copy around CA
    > certs from all of my suppliers (name collision risk), or manage my own
    > CA and onboard all of those devices, which can be costly. With DANE for
    > TLS client identity, I can configure each sensor with the name of its
    > upstream edge server (use DANE as it is now), and I can configure each
    > edge server with the names of its allowed clients (use DANE for client
    > ID). My sensors use mDNS to discover edge node IP addresses, and use
    > DANE to authenticate the discovered edge nodes for establishing a TLS
    > session.

I dunno, it feels like you are willing to jump through a lot of hoops to
avoid running a CA.  CAs are only hard if you are public and have CPS.

    >   Message/object security use case: I want my edge nodes to forward

This seems moot.  Either way, you can use object security if you can track
the signature to an identity.

-- 
]               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: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 17:32:55 -0500

Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
    > My understanding is that your solution is applicable to any scenario
    > that uses client certificates. Obviously IoT might be one application
    > area for this, but there are many other uses of client authentication
    > with certificates. I don't have any strong opinions about whether this
    > is useful or not. But it might be good to have a separate focused DANE
    > working group for these drafts if there is strong demand for such a
    > solution.

I disagree.
1) there is not a strong demand outside of IoT.
2) "focused DANE working group" seems like an oxymoron based upon previous experience.

I think that this work probably belongs in TLS with a dotted-line to IOTOPS.

    > Also, I didn't understand how would server authentication work? I
    > probably did not listen to your presentation carefully enough but I
    > suppose you cannot use DANE for server authentication in scenarios
    > where the client device does not yet have Internet connectivity.
    
    > So how
    > would server authentication work in EAP-TLS/SIM card/IoT bootstrapping
    > scenarios you discussed?

That's a good question.
I assumed it was authenticated with some WebPKI anchored certificate.

Fundmentally, how is the server authenticated, and whether the authorized owner is
authenticated, is what BRSKI's RFC8366 voucher is about.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 17:34:08 -0500

Shumon Huque <[email-masked]> wrote:
    > I assume we can cover this at tomorrow's side meeting. I'm not fully
    > informed of the details of the network access authentication use case
    > specifically (I'm sure Ash will elaborate), but I assume there are
    > other possibilities for authenticating the server side in those
    > environments, such as straight PKIX auth with a pre-provisioned small
    > trust anchor set.

Any summary of that discussion for the ML?

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Dec 2020 18:19:46 -0500

Eliot Lear <lear=[email-masked]> wrote:
    > We also discussed a non-WG forming BOF to look at, as Ted put it, the
    > broader context for onboarding.  To give people a feel for the sort of
    > related work that is available, here are a list of related activities:

Hi, I was asked to reboot:
            Device Enrollment in IETF protocols -- A Roadmap
                 draft-richardson-enrollment-roadmap-03

as a place to keep track of all sorts of these efforts.
It had been turned into a wiki entry, but frankly, I hate trying to edit
stuff in a browser. (Wasn't WEBDAV supposed to solve this problem?)

I could add these two DANE documents into the roadmap, but frankly, I'm not
sure where they go.

---

From: Ash Wilson <[email-masked]>
Date: Thu, 3 Dec 2020 11:26:03 -0500

> What infrastructure are you willing to operate?

As an application owner, my priority is operating only what's required to
securely and reliably deliver my application's functionality. If I can get
broadly useful device identity from the device supplier, that represents a
reduction in the footprint of the application I'm responsible for
maintaining.

If the supplier ships devices with certificates or raw public keys already
in DNS, I may not need to re-key to my own PKI. This makes a handful of
assumptions, including that keys are provisioned in an appropriately secure
manner (which
https://tools.ietf.org/html/draft-richardson-t2trg-idevid-considerations-01 can
help with).

This process could require the supplier to manage the DNS namespace for the
devices they ship with this type of identity. Alternatively, I could give
the supplier a list of names I would like to have assigned to devices, and
then receive an archive of all the device certificates to bulk-upload into
a DNS zone which I maintain.

I can run my own CA if I need to... But the need to do so diminishes if
DANE allows me to avoid name collisions and to perform mutual auth without
having to distribute CA certificates.

> If so, do you just have a database which each EE certificate pinned?

This depends on the configuration of the TLSA record. If the certificate
usage is 3 (DANE-EE), then the certificate or public key is validated
against the device's TLSA record(s) and PKIX validation is not required.
In this use case, the RADIUS server just needs a list of permitted
identities. If the supplicant can prove possession of a private key
associated with a DANE identity on the RADIUS server's 'allow' list, the
device is allowed onto the network. This can be an IDevID or LDevID
certificate, as long as it has a name in DNS.

The database which associates names to public keys is DNS, and the RADIUS
server only needs a list of permitted DNS names.

> How is this different than providing a database of EE or public keys?

This actually is providing a database of public keys, but the database is
DNS and identities can be maintained by whoever the application owner
trusts to do so (mfr, implementer, etc...). The same database (DNS) can be
used to support authenticating network access as well as message signature
verification.

> avoid running a CA.  CAs are only hard if you are public and have CPS.

I agree that CAs don't have to be difficult to operate. There are a number
of providers who have great user interfaces and provide useful APIs and
integrations. As an application owner, I want to focus on the core
functionality of my application, and if I can purchase/lease devices with
immediately useful identities, then I don't need to maintain a CA component
(as-a-service or otherwise) as a part of my application footprint.

> the signature to an identity.

This is all about simplifying the process of discovering public keys. If
the message bears the sending entity's DANE/DNS name, the recipient can use
DNS to retrieve the public key.
This improves:
* Network bandwidth consumption: No need for the message sender to also
transmit a certificate.
* Removal of implied trust: No need to base trust for message integrity and
attribution on middleware if the message can be independently verified.
* Systems integration: You don't need to integrate with a proprietary API
to retrieve certificates for message authentication. Rather, DNS can become
the discovery API for every CA that wishes to participate.

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2020 13:43:55 -0500

Hi, I don't want to religate the email again.

> having to distribute CA certificates.

This seems to imply that running a private CA is at least an order of
magnitude harder than managing a DNS zone containing TLSA records,
and which is probably DNSSEC signed.

It is unclear to that your application needs either: it seems like it just
needs a database of public keys which are authorized, and you already seem to
assume the existence of a radius server with a database backend.
I think that radius servers can be as complex as signed DNS zones, or simple private CAs.

I'm sorry to be obtuse here: others will ask the question.

It sounds like your application is primarily a mp2p data flow (device->cloud).
I'm finding it difficult to see why a DNS zone full of TLSA records is even
required.

If we get into e2e  (m2m) data flows, then the ability for one device to
validate another device without directly communicating with a third party is
a win.  For that, a private CA or a DNS zone of TLSA keys, particularly, as
you say, that DNSSEC record cache proposal, makes perfect sense to me.

My proposal going forward:
   section 2 of draft-huque-dane-client-cert

needs to expand to a couple of pages.

The SMTP use case should probably get it's own section; perhaps its own
document actually.

I think that:
       TLS Extension for DANE Client Identity
           draft-huque-tls-dane-clientid-03

is clear and simple, and once we figure out where huque-dane-client-cert
goes, then I think that this document should just be referred to the TLS WG.
The previous document should then provide adequate explanation of the
context.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ash Wilson <[email-masked]>
Date: Fri, 4 Dec 2020 14:28:30 -0500

> I'm sorry to be obtuse here: others will ask the question.

I really appreciate your feedback. The more questions we answer now, the
fewer we will need to answer later on.
I agree- RADIUS can be quite complicated. The hope is that if the CA and
DNS are operated by the manufacturer/supplier, the amount of configuration
complexity required for RADIUS or other EAP-TLS authentication server (if
operated by the application owner or network manager) might be reduced.

We can't eliminate all complexity, but there may be an opportunity to
simplify and shift some complexity up the supply chain and away from the
application owner. By allowing the supplier to take on some of the
responsibility for identity (via PKI and DNS), the application owner may
more easily (or less expensively) use strong device identity. I'm making
the assumptions that the application owner (1) has influence on security
aspects of the application design, (2) wants to build a secure
application, and (3) wants to minimize complexity in implementation. The
hope is that reducing the application owner's complexity (authentication
infrastructure) and expense (human labor) for PKI-based authentication will
encourage broader adoption.

> I'm finding it difficult to see why a DNS zone full of TLSA records is even

The simplification gains are definitely greater as the application
becomes more complex/decoupled/m2m.
If the communication pattern is directly device-to-cloud, then it may make
more sense to just work with traditional PKI, private CA, etc... This is
certainly not a silver bullet for all IoT authentication needs :-)

There's a point of complexity where it makes more sense to take the DANE
approach, and I suspect that it will be driven by a few aspects:
* How many device suppliers will my application have?
* Can my suppliers ship devices with identities already in DNS?
* Does my application make use of messaging middleware, like MQTT brokers
and message queues?
  * How much do I trust the middleware to resist unauthorized
access/behavior? (level of comfort with implied trust)
  * What is the potential impact of message sender impersonation in my
application?
  * Should I be signing messages to help prevent sending device
impersonation?

--