Subject: [Danish] Charter Text and the Problem Statement

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Jun 2021 11:11:35 +0000

Hi all,

I have been reading through the charter text in an attempt to understand the problem statement.

Two problems are mentioned:

1)  Challenges with naming collisions in the IoT space.

2)  Credential issuance is time consuming.

Ad 1: Reading through the text it feels like naming collisions are a big thing in IoT. I have not heard about those problems. Could you elaborate?

You add that "In response to the challenges related to

ambiguity between identities issued by different CAs, application owners

frequently choose to onboard IoT devices to a single CA.". Is that a good or a bad development?

Ad 2: Is it really true that credential issuance is time consuming? Why is that? For whom is it time consuming?

Ciao
Hannes

PS: You use the term "Certificate Authority (CA)". It is actually called "Certification Authority".

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Ash Wilson <[email-masked]>
Date: Wed, 16 Jun 2021 14:27:48 -0700

Hi Hannes,
Thanks for the questions, and apologies for keeping you waiting on
answers/clarification.

On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig <[email-masked]>
wrote:

> Certainly. I'll use a hospital as an example environment.

Within a hospital, it is desirable to implement 802.1x authentication using
EAP-TLS for access to protected networks. EAP-TLS enables the use of
PKI-based identity to authenticate an entity for network access.

When implementing EAP-TLS for network access, RADIUS is a common
protocol/server used for authentication behind the switch or wireless
access point. Guidance for configuring RADIUS recommends the use of only
one CA certificate for authenticating supplicant certificates. This
guidance can be found in the wild in Freeradius configuration files for
EAP-TLS, related to the 'ca_file' configuration directive.

CAs guarantee the uniqueness of an entity's name within the scope of the
CA, but have no method for enforcing name uniqueness across other CAs. For
instance, CA1 and CA2 may both sign certificates for entities with the same
name. If CA1 and CA2 are both trusted by the RADIUS server, and two
entities named "medicaldevice123" exist, one per CA, then the resulting
ambiguity makes it difficult to appropriately apply access controls. This
ambiguity is mitigated by operating a single organizational PKI, and
requiring identities issued by that single organizational PKI for EAP-TLS
authentication.

Onboarding devices to organizational PKI requires time and effort.
Oftentimes some sort of skilled labor and/or dedicated infrastructure for
automating the onboarding process is involved. DANE allows us to bind a DNS
name to a public key, and mitigates the ambiguities introduced by the use
of multiple CAs. An organization can only issue working identities within
its own namespace in DNS. Since naming ambiguity can be mitigated using
DANE, we may now choose to use manufacturer-issued PKI, represented in DNS,
for authenticating entities.

>From the hospital's standpoint, the IT staff no longer needs to manage the
process of onboarding devices to organizational PKI. The device arrives
on-site with an identity which can be immediately used for
network authentication.

> You add that “In response to the challenges related to
>
> frequently choose to onboard IoT devices to a single CA.”. Is that a good or a bad development?
>
> It is a good development if the organization really wants to directly
manage all of the credentials for all of the application participants. The
effort and rationale behind BRSKI (RFC 8995) suggests a desire to make
onboarding to organizational PKI easier to automate.

If a supplier issues a trustworthy identity for a device, and DNS prevents
another PKI from issuing working credentials under the same name, then
issuing another identity via organizational PKI becomes superfluous. This
is where we think that time and effort can be saved, because the skills
required for onboarding do not need to include the management and issuance
of identities under organizational PKI.

> that? For whom is it time consuming?
Credential issuance very often requires the device and the person
bootstrapping the identity to be in the same place. Some platforms and
protocols exist to make that process easier (like BRSKI) or less
human-involving. The time investment seems to be on the part of both the
manufacturer (in issuing the IDevID) as well as the organizational IT
staff, who manage the organizational PKI.

>
>
> Ciao
>
> Hannes
>
>
>
> PS: You use the term “Certificate Authority (CA)”. It is actually called
> “Certification Authority”.
>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> --
> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish
>

-- 

*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: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Jun 2021 18:00:50 -0400

On Wed, Jun 16, 2021 at 02:27:48PM -0700, Ash Wilson wrote:

> CA, but have no method for enforcing name uniqueness across other CAs.

Uniqueness is not the property you're looking for.  It doesn't matter
how many keys a CA binds the same name to, so long as all those keys are
legitimately associated with the same entity.  Overlap is perfectly
normal, e.g. across renewals CAs don't typically revoke the (soon(ish) to
expire) previous certificate.

Nor does it matter if more CAs assign the same name to some subset of
the same keys, provided they're expected/authorised to do so.

All that matters is whether the verifier is willing to trust a given CA
to for names in a given namespace, and it is here that it is quite
reasonable to not place trust in every CA on the planet when
provisioning cameras, electronic locks, uranium isotope centrifuges, ...

This is not about "uniqueness", rather it is about assurance, sometimes
you need to run your own CA, because the CA/B forum CAs don't provide
the required assurance levels and sometimes are presumed actively
hostile.

> For instance, CA1 and CA2 may both sign certificates for entities with
> the same name. If CA1 and CA2 are both trusted by the RADIUS server,
> and two entities named "medicaldevice123" exist, one per CA, then the
> resulting ambiguity makes it difficult to appropriately apply access
> controls.

No, the problem only happens when the two are not the same, but CAs
issuing certificates from publically trusted keys should only sign
assertions about globally valid names, so there are no "collisions",
there is only authorised or unauthorised issuance.

> This ambiguity is mitigated by operating a single organizational PKI,
> and requiring identities issued by that single organizational PKI for
> EAP-TLS authentication.

There is no ambiguity or uniqueness problem.  There is only a trust /
authorisation problem.

> of multiple CAs.

No, rather DANE gives a natural global namespace, with natural name
constraints, so that only the signing keys of the authoritative zone
(and potentially its parent zones if compelled to transfer domain
control, or hypotheticall, but much less likely forge non-delegated
responses) can be used to sign TLSA RRsets for a given name.

So with DANE there is a natural single naming authority, that is absent
with WebPKI.

> An organization can only issue working identities within its own
> namespace in DNS. Since naming ambiguity can be mitigated using DANE,
> we may now choose to use manufacturer-issued PKI, represented in DNS,

We're converging to the same observations, but your terminology is sadly
misleading and regrettable.  Please remove all referce to uniqueness and
ambiguity, and instead clarify the actual desire for a single naming
authority trusted by the verifier.  It can be the device manufacturer
(if not trusted, why use the device), but in some environments, the user
may elect to reconfigure the device with their own keys and DNS name and
avoid reliance on outside parties.

> From the hospital's standpoint, the IT staff no longer needs to manage
> the process of onboarding devices to organizational PKI. The device
> arrives on-site with an identity which can be immediately used for
> network authentication.

Perhaps so, though some equipment is sufficiently critical that it will
need to remain working even if the outside vendor is no longer reachable
or even in business.  In which case one would want to use one's own
internal DNS servers proximate to the devices in question.

> another PKI from issuing working credentials under the same name,

DNSSEC provides natural name constraints.  It is then up to the user
whether to trust the device vendor for authenticity and availability
during or beyond the initial device onboarding.

> then issuing another identity via organizational PKI becomes
> superfluous. This is where we think that time and effort can be saved,
> because the skills required for onboarding do not need to include the
> management and issuance of identities under organizational PKI.

You might also simplify onboarding, but the device is then promptly
reconfigured with an internal name and keys.  It suffices to wipe the
TLSA RRs from DNS when the device is deprovisioned, the keys are then no
longer sensitive (after the TLSA RRSIGs expire), but wiping those too
is generally prudent.

-- 
    Viktor.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Jun 2021 06:43:21 +0000

Thanks for your feedback, Ash.

It is interesting that you mention the network access authentication use case. Do you envision EAP-TLS in combination with Danish to work architecturally differently than the current EAP-TLS-based approach?

You write:
“Credential issuance very often requires the device and the person bootstrapping the identity to be in the same place”

Binding the user to his or her device typically takes some time. It often requires the user to log into some service and to “add” the new device often by demonstrating physical possession. Of course, this is the way how it works for end consumer products, where scalability is less of an issue because you are probably not going to buy thousands of smart coffee machines. For a commercial setup, the process often works different but it very much depends on the type of industry vertical you are in. There is often a non-irrelevant configuration step involved as well. For example, with commercial indoor lighting professionals need to configure different lighting themes.

I don’t see any of this user-related interaction being covered as part of the chartered work.

Ciao
Hannes

From: Ash Wilson <[email-masked]>
Sent: Wednesday, June 16, 2021 11:28 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

Hi Hannes,
Thanks for the questions, and apologies for keeping you waiting on answers/clarification.

On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Within a hospital, it is desirable to implement 802.1x authentication using EAP-TLS for access to protected networks. EAP-TLS enables the use of PKI-based identity to authenticate an entity for network access.

When implementing EAP-TLS for network access, RADIUS is a common protocol/server used for authentication behind the switch or wireless access point. Guidance for configuring RADIUS recommends the use of only one CA certificate for authenticating supplicant certificates. This guidance can be found in the wild in Freeradius configuration files for EAP-TLS, related to the 'ca_file' configuration directive.

CAs guarantee the uniqueness of an entity's name within the scope of the CA, but have no method for enforcing name uniqueness across other CAs. For instance, CA1 and CA2 may both sign certificates for entities with the same name. If CA1 and CA2 are both trusted by the RADIUS server, and two entities named "medicaldevice123" exist, one per CA, then the resulting ambiguity makes it difficult to appropriately apply access controls. This ambiguity is mitigated by operating a single organizational PKI, and requiring identities issued by that single organizational PKI for EAP-TLS authentication.

Onboarding devices to organizational PKI requires time and effort. Oftentimes some sort of skilled labor and/or dedicated infrastructure for automating the onboarding process is involved. DANE allows us to bind a DNS name to a public key, and mitigates the ambiguities introduced by the use of multiple CAs. An organization can only issue working identities within its own namespace in DNS. Since naming ambiguity can be mitigated using DANE, we may now choose to use manufacturer-issued PKI, represented in DNS, for authenticating entities.

From the hospital's standpoint, the IT staff no longer needs to manage the process of onboarding devices to organizational PKI. The device arrives on-site with an identity which can be immediately used for network authentication.

frequently choose to onboard IoT devices to a single CA.”. Is that a good or a bad development?
It is a good development if the organization really wants to directly manage all of the credentials for all of the application participants. The effort and rationale behind BRSKI (RFC 8995) suggests a desire to make onboarding to organizational PKI easier to automate.

If a supplier issues a trustworthy identity for a device, and DNS prevents another PKI from issuing working credentials under the same name, then issuing another identity via organizational PKI becomes superfluous. This is where we think that time and effort can be saved, because the skills required for onboarding do not need to include the management and issuance of identities under organizational PKI.

Ad 2: Is it really true that credential issuance is time consuming? Why is that? For whom is it time consuming?
Credential issuance very often requires the device and the person bootstrapping the identity to be in the same place. Some platforms and protocols exist to make that process easier (like BRSKI) or less human-involving. The time investment seems to be on the part of both the manufacturer (in issuing the IDevID) as well as the organizational IT staff, who manage the organizational PKI.

Ciao
Hannes

PS: You use the term “Certificate Authority (CA)”. It is actually called “Certification Authority”.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Danish mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/danish

--
Ash Wilson | Technical Director
e: [email-masked]<mailto:[email-masked]>
[https://hosted-packages.s3-us-west-1.amazonaws.com/Valimail+Logo.png]

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: Wes Hardaker <[email-masked]>
Date: Thu, 17 Jun 2021 08:17:04 -0700

> misleading and regrettable.

That could have probably been phrased in a more polite manner (regardless
of whether you're right or not).
-- 
Wes Hardaker
USC/ISI

---

From: Ash Wilson <[email-masked]>
Date: Thu, 17 Jun 2021 11:21:44 -0700

Hi Hannes,
Great questions, responses in-line below...

On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig <
[email-masked]> wrote:

> It is interesting that you mention the network access authentication use
> case. Do you envision EAP-TLS in combination with Danish to work
> architecturally differently than the current EAP-TLS-based approach?
>

We hope to minimize the amount of work required to enable DANE client ID
for EAP-TLS. Some challenges remain with EAP-TLS in conjunction with TLS
1.3: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-16.
Supporting TLS 1.2 for EAP-TLS and DANE would likely be more
straightforward, but I do not know whether there's much interest in
updating TLS 1.2 to cover this use case.

DANE server authentication with EAP-TLS brings another challenge: the
absence of IP connectivity prior to authentication. This could be remedied
by
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07,
if the work on that draft were to continue. There are also challenges with
validating the chain, tied to root key rotation. Devices which remain
unplugged too long may not be able to authenticate. On the other hand, it
is a best practice to ensure that a device is patched before putting it
into production, and updating roots of trust fits within the scope of that
sort of activity.

If only DANE for client authentication is supported in EAP-TLS, which is
the likely initial outcome, the challenge of getting the authentication
server's CA certificate onto the device still exists. This still represents
a reduction in effort on the part of the IT staff, but not a perfect
zero-touch onboarding unless the supplier also provisions the CA certs for
the authentication server... and in the case of WiFi, the SSID to associate
with. Still, we think this represents a substantial improvement in the
onboarding experience for the implementer.

>
> You write:
>
> “Credential issuance very often requires the device and the person
> bootstrapping the identity to be in the same place”
>
>
>
> Binding the user to his or her device typically takes some time. It often
> requires the user to log into some service and to “add” the new device
> often by demonstrating physical possession. Of course, this is the way how
> it works for end consumer products, where scalability is less of an issue
> because you are probably not going to buy thousands of smart coffee
> machines. For a commercial setup, the process often works different but it
> very much depends on the type of industry vertical you are in. There is
> often a non-irrelevant configuration step involved as well. For example,
> with commercial indoor lighting professionals need to configure different
> lighting themes.
>
>
>

DANE can be useful for home IoT. I think that it could reduce the
complexity of automation wherever private PKI is being managed in the
consumer's environment, and accelerate and simplify the onboarding
experience. IETF is accessible and wide-reaching, and seems like the right
place to present and refine the design pattern that might be adopted later
by other standards (like CHIP/Matter). I'm also operating under the
assumption that enterprise IoT has a more recognized need for
interoperability and simpler secure onboarding processes. That is a big
assumption, and only based on my observations thus far. I'm open to
including the home consumer's perspective in this effort, if you think it's
worthwhile.

As far as describing the general onboarding experience for the implementer,
I had hoped to include that in the architecture document along with
examples of how DANE might interface with and support other standards in
the broader ecosystem. In trying to keep the charter concise, I think we
left out some important information.

You bring up an interesting point, with the configuration of lighting
profiles during fixture installation. The expectation is that with DANE as
the authentication protocol, the variety of suppliers producing devices for
a given application might be able to agree on a format for representing
configuration information, and devices can securely retrieve it from the
system that manages the application's configuration. I think that it would
be especially useful to show how DANE works with other discovery protocols
(mDNS, for instance) in the process of retrieving the device's
configuration. Where do you think this fits best? In the architecture
document, or would another format be a better fit for this?

>
> Ciao
>
> Hannes
>
>
>
> *From:* Ash Wilson <[email-masked]>
> *Sent:* Wednesday, June 16, 2021 11:28 PM
> *To:* Hannes Tschofenig <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Danish] Charter Text and the Problem Statement
>
>
>
> Hi Hannes,
>
> On Wed, Jun 16, 2021 at 4:12 AM Hannes Tschofenig <
> [email-masked]> wrote:
>
> Hi all,
>
>
>
> Within a hospital, it is desirable to implement 802.1x authentication
> using EAP-TLS for access to protected networks. EAP-TLS enables the use of

--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Jun 2021 16:13:59 -0400

On Thu, Jun 17, 2021 at 11:21:44AM -0700, Ash Wilson wrote:

> by https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07,
> if the work on that draft were to continue.

That seems rather unlikely in the short term, but in the meantime

    https://datatracker.ietf.org/doc/draft-dukhovni-tls-dnssec-chain/

will soon be published via the ISE.

> There are also challenges with validating the chain, tied to root key
> rotation. Devices which remain unplugged too long may not be able to
> authenticate.  On the other hand, it is a best practice to ensure that
> a device is patched before putting it into production, and updating
> roots of trust fits within the scope of that sort of activity.

Indeed a device that's been on the shelf for O(1 year) or more may well
find that the root key has been rolled.  There is therefore a need for a
mechanism to allow it to "catch up" by updating its software and trust
anchors.  Secure update of dormant devices is a tricky problem, that may
not have a one size fits all solution, there's likely a continuum of
tradeoffs between convenience and security.

-- 
    Viktor.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Jun 2021 12:47:39 +0000

Hi Ash,

If the network access authentication use case with EAP-TLS is important to you then I believe it would be good to add it as a milestone on the charter. You cannot use an implementation of draft-ietf-emu-eap-tls13 and assume any of the DANE functionality to work. You would indeed have to rely on draft-ietf-tls-dnssec-chain-extension because not having network connectivity is the main reason why you would be running the EAP-TLS exchange in the first place.

Regarding “best practice to ensure that a device is patched before putting it into production, and updating roots of trust fits within the scope of that sort of activity”: I don’t think there is any expectation that the device will be updated before it is put in production (i.e. powered on for the first time). You can assume that the device, when it comes online for the first time and reaches out to the device management server, gets a firmware update. Having that firmware update happen before it is connected to the network is extremely unlikely.

EAP-TLS is also not an IoT device onboarding protocol. From the charter text I am also not assuming that you are attempting to define a new IoT onboarding protocol or do you?

Regarding the home IoT environment: I would not count on CHIP/Matter re-using your work. My understanding is that they are creating their own solutions. Since the home environment is very fragmented, it might not be the easiest place to start. Of course, your company may play and that field and so you might have a way to get the outcome of DANISH deployed there.

I am still trying to figure out how DANISH fits into the larger picture and hence I am looking forward to read an architecture document. Is the a pre-draft available already?

Ciao
Hannes

From: Ash Wilson <[email-masked]>
Sent: Thursday, June 17, 2021 8:22 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

Hi Hannes,

On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for your feedback, Ash.

We hope to minimize the amount of work required to enable DANE client ID for EAP-TLS. Some challenges remain with EAP-TLS in conjunction with TLS 1.3: https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-16. Supporting TLS 1.2 for EAP-TLS and DANE would likely be more straightforward, but I do not know whether there's much interest in updating TLS 1.2 to cover this use case.

DANE server authentication with EAP-TLS brings another challenge: the absence of IP connectivity prior to authentication. This could be remedied by https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-07, if the work on that draft were to continue. There are also challenges with validating the chain, tied to root key rotation. Devices which remain unplugged too long may not be able to authenticate. On the other hand, it is a best practice to ensure that a device is patched before putting it into production, and updating roots of trust fits within the scope of that sort of activity.

If only DANE for client authentication is supported in EAP-TLS, which is the likely initial outcome, the challenge of getting the authentication server's CA certificate onto the device still exists. This still represents a reduction in effort on the part of the IT staff, but not a perfect zero-touch onboarding unless the supplier also provisions the CA certs for the authentication server... and in the case of WiFi, the SSID to associate with. Still, we think this represents a substantial improvement in the onboarding experience for the implementer.

You write:

DANE can be useful for home IoT. I think that it could reduce the complexity of automation wherever private PKI is being managed in the consumer's environment, and accelerate and simplify the onboarding experience. IETF is accessible and wide-reaching, and seems like the right place to present and refine the design pattern that might be adopted later by other standards (like CHIP/Matter). I'm also operating under the assumption that enterprise IoT has a more recognized need for interoperability and simpler secure onboarding processes. That is a big assumption, and only based on my observations thus far. I'm open to including the home consumer's perspective in this effort, if you think it's worthwhile.

As far as describing the general onboarding experience for the implementer, I had hoped to include that in the architecture document along with examples of how DANE might interface with and support other standards in the broader ecosystem. In trying to keep the charter concise, I think we left out some important information.

You bring up an interesting point, with the configuration of lighting profiles during fixture installation. The expectation is that with DANE as the authentication protocol, the variety of suppliers producing devices for a given application might be able to agree on a format for representing configuration information, and devices can securely retrieve it from the system that manages the application's configuration. I think that it would be especially useful to show how DANE works with other discovery protocols (mDNS, for instance) in the process of retrieving the device's configuration. Where do you think this fits best? In the architecture document, or would another format be a better fit for this?

Ciao
Hannes

From: Ash Wilson <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 16, 2021 11:28 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Danish] Charter Text and the Problem Statement

Hi Hannes,

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 16:28:01 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > Regarding “best practice to ensure that a device is patched before
    > putting it into production, and updating roots of trust fits within the
    > scope of that sort of activity”: I don’t think there is any expectation
    > that the device will be updated before it is put in production
    > (i.e. powered on for the first time). You can assume that the device,
    > when it comes online for the first time and reaches out to the device
    > management server, gets a firmware update. Having that firmware update
    > happen before it is connected to the network is extremely unlikely.

One can onboard onto a quarantine network on which firmware updates can
occur, and then move to the production network.

    > EAP-TLS is also not an IoT device onboarding protocol. From the charter
    > text I am also not assuming that you are attempting to define a new IoT
    > onboarding protocol or do you?

Yes, but several people are trying to do EAP-TEAP-BRSKI.

    > I am still trying to figure out how DANISH fits into the larger picture
    > and hence I am looking forward to read an architecture document. Is the
    > a pre-draft available already?

I don't think so, but maybe that would be a good direction to consider.

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

---

From: Ash Wilson <[email-masked]>
Date: Sat, 19 Jun 2021 21:47:12 -0700

On Sat, Jun 19, 2021 at 5:47 AM Hannes Tschofenig <[email-masked]>
wrote:

> Hi Ash,
>
>
>
> If the network access authentication use case with EAP-TLS is important to
> you then I believe it would be good to add it as a milestone on the
> charter. You cannot use an implementation of draft-ietf-emu-eap-tls13 and
> assume any of the DANE functionality to work. You would indeed have to rely
> on draft-ietf-tls-dnssec-chain-extension because not having network
> connectivity is the main reason why you would be running the EAP-TLS
> exchange in the first place.
>
The process of using DANE for authenticating an EAP-TLS supplicant, from
the authentication server's perspective, is expected to be more
straightforward. It is not unnatural for the authentication server to have
the IP connectivity required to retrieve the TLSA record for authenticating
the client's certificate. The complexity of getting DANE to work for
allowing the supplicant to authenticate the authentication server is
certainly more complicated, and also introduces a dependency on the DNSSEC
chain extension.

>
>
> Regarding “best practice to ensure that a device is patched before putting
> it into production, and updating roots of trust fits within the scope of
> that sort of activity”: I don’t think there is any expectation that the
> device will be updated before it is put in production (i.e. powered on for
> the first time). You can assume that the device, when it comes online for
> the first time and reaches out to the device management server, gets a
> firmware update. Having that firmware update happen before it is connected
> to the network is extremely unlikely.
>

> onboarding protocol or do you?
We are being very careful with the scope of the charter, to stay focused on
client authentication in the TLS handshake and public key discovery for
authenticating messages. Addressing the nuances of EAP-TLS, especially for
supporting TLS 1.3, seems like the sort of work we may want to re-charter
to accomplish unless there's enough interest in the beginning to bring it
in-scope. I'm very happy to hear that you're interested in how EAP-TLS
will fit with this effort and I have no objection to including this in the
charter, as long as the chairs are OK with it.

>
>
> Regarding the home IoT environment: I would not count on CHIP/Matter
> re-using your work. My understanding is that they are creating their own
> solutions. Since the home environment is very fragmented, it might not be
> the easiest place to start. Of course, your company may play and that field
> and so you might have a way to get the outcome of DANISH deployed there.
>

> and hence I am looking forward to read an architecture document. Is the a
> pre-draft available already?
>
 The architecture document is very rough and not ready even for pre-draft
review.  I will prioritize improving this document and share it with you
ASAP.

> *Sent:* Thursday, June 17, 2021 8:22 PM
> As far as describing the general onboarding experience for the
> implementer, I had hoped to include that in the architecture document along
> with examples of how DANE might interface with and support other standards
> in the broader ecosystem. In trying to keep the charter concise, I think we

--

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Jun 2021 08:12:37 +0000

Hi Michael,

You mention "EAP-TEAP-BRSKI", another technology where I do not precisely know how it is supposed to fit into the DANISH work (if at all).

I started with a simple task: I read through the charter text. I didn't understood the problem statement. Then, I looked through the mailing list and at the slides presented at the last meeting. I can find a lot of solution discussions but little discussion about the problem.

I believe I should understand the problem since I have been working in this domain for many years. It is most likely that the problem has been solved already many times before (since IoT is not really a new field anymore). Maybe the proposed solution gives a new spin to it. Maybe not.

If the problem cannot be described properly then there will be a lot of problems later in this group. The problem description will also help to understand who in the ecosystem needs to do something to turn this into a reality.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Saturday, June 19, 2021 10:28 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

    > happen before it is connected to the network is extremely unlikely.

One can onboard onto a quarantine network on which firmware updates can occur, and then move to the production network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Jun 2021 08:18:32 +0000

Hi Ash,

I believe you and others in the group have a vision that somehow relates to IoT where the use of DANE for client authentication in TLS fits in there. What has not been done yet is to put this vision in writing. It may be that this vision is more solution oriented than problem oriented but, if you want to attract others in the work (assuming you want that), you will have to somehow explain how these small building blocks enable something bigger.

Ciao
Hannes

From: Ash Wilson <[email-masked]>
Sent: Sunday, June 20, 2021 6:47 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

On Sat, Jun 19, 2021 at 5:47 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ash,

If the network access authentication use case with EAP-TLS is important to you then I believe it would be good to add it as a milestone on the charter. You cannot use an implementation of draft-ietf-emu-eap-tls13 and assume any of the DANE functionality to work. You would indeed have to rely on draft-ietf-tls-dnssec-chain-extension because not having network connectivity is the main reason why you would be running the EAP-TLS exchange in the first place.
The process of using DANE for authenticating an EAP-TLS supplicant, from the authentication server's perspective, is expected to be more straightforward. It is not unnatural for the authentication server to have the IP connectivity required to retrieve the TLSA record for authenticating the client's certificate. The complexity of getting DANE to work for allowing the supplicant to authenticate the authentication server is certainly more complicated, and also introduces a dependency on the DNSSEC chain extension.

EAP-TLS is also not an IoT device onboarding protocol. From the charter text I am also not assuming that you are attempting to define a new IoT onboarding protocol or do you?
We are being very careful with the scope of the charter, to stay focused on client authentication in the TLS handshake and public key discovery for authenticating messages. Addressing the nuances of EAP-TLS, especially for supporting TLS 1.3, seems like the sort of work we may want to re-charter to accomplish unless there's enough interest in the beginning to bring it in-scope. I'm very happy to hear that you're interested in how EAP-TLS will fit with this effort and I have no objection to including this in the charter, as long as the chairs are OK with it.

I am still trying to figure out how DANISH fits into the larger picture and hence I am looking forward to read an architecture document. Is the a pre-draft available already?
 The architecture document is very rough and not ready even for pre-draft review.  I will prioritize improving this document and share it with you ASAP.

Ciao
Hannes

Hi Hannes,

You write:

Ciao
Hannes

Hi Hannes,

Ciao
Hannes

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 20 Jun 2021 07:48:24 -0700

Ash Wilson <ash.wilson=[email-masked]> writes:

> I'm very happy to hear that you're interested in how EAP-TLS will fit
> with this effort and I have no objection to including this in the

It does seem to me that EAP-TLS should be considered after the other
parts of the problem space have a good start, unless that someone has a
good case for why they have to be simultaneously worked on.  And there
is nothing wrong with making charter items that outline a series of
things to do.  I'd suggest that based on discussions to date, it sounds
like there are now three major sections, none of which are huge, to work
on:

1. An architecture document
2. Base protocol documents
3. EAP-TLS and other immediate follow on items, if there are agreements
now this this really should be the next step (otherwise rechartering
when 1 and 2 are done and decide on priorities then)

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 20 Jun 2021 07:51:23 -0700

Hannes Tschofenig <[email-masked]> writes:

> If the problem cannot be described properly then there will be a lot
> of problems later in this group.

I think starting with a problem statement and architecture document
makes a lot of sense to me.

In particular, during the last BOF there was an overview example that
included a car driving into a home that reasonably explained the space.
And recently on the list there was a description of onboarding a device
in a hospital, that also sounded like a reasonable place to start.
IMHO, it would be really nice to get these two, and possible other
examples, fully flushed out with example DNS queries and documented some
place that we could refer to them.

But...  the charter also needs a suitable shortened problem description,
and that might be trickier since it seems like a longer description is
almost necessary for most people to grasp the space.

-- 
Wes Hardaker
USC/ISI

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Jun 2021 16:13:47 +0000

Hi Wes

Talking about a specific use case makes a lot of sense.
I guess you are referring to the taxi dash cam retention scenario from https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof-slides-02

The example raises a few questions:
* how does the network access authentication and authorization work? This is key because it secures the subsequent mDNS exchange as well.
* how does the taxi car know that it has to talk to recorder56 in that garage?
* how does the recorder recognize that car54 is allowed to upload video data (and to potentially access data)?

I can easily see concerns about listing IoT devices in the DNS (publically visible).

How the device would obtain operational credentials since you rarely use the same (manufacturer-provisioned) key for all services?

Ciao
Hannes

PS: I missed the example of onboarding a device in a hospital.

-----Original Message-----
From: Danish <[email-masked]> On Behalf Of Wes Hardaker
Sent: Sunday, June 20, 2021 4:51 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

> of problems later in this group.

I think starting with a problem statement and architecture document makes a lot of sense to me.

In particular, during the last BOF there was an overview example that included a car driving into a home that reasonably explained the space.
And recently on the list there was a description of onboarding a device in a hospital, that also sounded like a reasonable place to start.
IMHO, it would be really nice to get these two, and possible other examples, fully flushed out with example DNS queries and documented some place that we could refer to them.

But...  the charter also needs a suitable shortened problem description, and that might be trickier since it seems like a longer description is almost necessary for most people to grasp the space.

--
Wes Hardaker
USC/ISI

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Jun 2021 17:39:45 -0400

> when 1 and 2 are done and decide on priorities then)

I agree 100% with this approach.
I think that using EAP-TLS with client side certificates for network access
could be a really useful thing.  But, that it should come afterward as a
milestone.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Jun 2021 17:41:31 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > You mention "EAP-TEAP-BRSKI", another technology where I do not
    > precisely know how it is supposed to fit into the DANISH work (if at
    > all).

It isn't.  The point is that there is work in EAP to do onboarding.
If you use DANISH, then you don't need to onboard the device (i.e. enroll it
with a new certificate), because you already have secure access to the
correct certificate via DNS(SEC).

    > I started with a simple task: I read through the charter text. I didn't
    > understood the problem statement. Then, I looked through the mailing
    > list and at the slides presented at the last meeting. I can find a lot
    > of solution discussions but little discussion about the problem.

Fair enough.  I agree that we need improvements in the charter text, and I
appreciate your comments.

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 20 Jun 2021 17:00:03 -0700

Hannes Tschofenig <[email-masked]> writes:

> I guess you are referring to the taxi dash cam retention scenario from
> https://datatracker.ietf.org/meeting/110/materials/slides-110-danish-danish-bof-slides-02
> 

Many questions will come from examples, hence the need for them :-)

Reminder: step one is getting the charter done and the WG formed *then*
we can solve the problems.  So we shouldn't go too far down this path at
this time -- but we should agree on the problem space being tackled.

> PS: I missed the example of onboarding a device in a hospital.

https://mailarchive.ietf.org/arch/msg/danish/OkQzlyZoKlEar5-GU6HgtSz3ebY/
-- 
Wes Hardaker
USC/ISI

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Jun 2021 05:04:28 +0000

Hi Wes,

> Reminder: step one is getting the charter done and the WG formed *then* we can solve the problems.  So we shouldn't go too far down this path at this time -- but we should agree on the problem space being tackled.

In the good old days, we tried to figure out what problem to solve first and then formed a working group.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Jun 2021 05:10:37 +0000

Hi Michael,

One remark:

> If you use DANISH, then you don't need to onboard the device (i.e. enroll it with a new certificate), because you already have secure access to the correct certificate via DNS(SEC).

In the past we used different keys for different purposes. A manufacturer provided key was used for a relatively small number of tasks (typically for obtaining operational keys). For use with application services we used a different key. We used yet another key for firmware updates and again another for attestation.

What has changed?

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Jun 2021 10:40:39 -0400

Hannes Tschofenig <[email-masked]> wrote:
    >> If you use DANISH, then you don't need to onboard the device
    >> (i.e. enroll it with a new certificate), because you already have secure
    >> access to the correct certificate via DNS(SEC).

    > In the past we used different keys for different purposes. A
    > manufacturer provided key was used for a relatively small number of
    > tasks (typically for obtaining operational keys). For use with
    > application services we used a different key. We used yet another key
    > for firmware updates and again another for attestation.

    > What has changed?

As you know I'm a big proponent of using an IDevID with an onboarding
protocol to obtain an LDevID.
I think that this is still an important path.  But, it's not the only path!

While I think your next comment might be about divergent paths causing market
confusion,  I think that we are already there.   There are presently a number
of incompatible systems out there that deliver keys from the factory to be
used in production.

I think that the DANISH might be an interesting way to publish *LDevID*s.
While I might onboard a device into my network, in the future, imagine that
different operational networks might need to interact without having an
ownership relationship.  For instance, any personal wearables you might have
interacting with a variety of building or vehicle systems that you are in.
How will I give you permission to turn on the lights in my house?
I'd surely prefer to list that authorization by DNS name, rather than hash,
right?

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Jun 2021 15:26:12 +0000

Hi Michael,

I was not necessarily thinking about IEEE 802.1AR and the way BRSKI uses it. BRSKI is kind of special in the way it is designed.

In general, in security there is the idea to use different keys for different purposes. If that has changed then I completed missed it.

Regarding the management of access with wearables and smart home deployments using standardized protocols I thought that this is why we did all the work in ACE.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Monday, June 21, 2021 4:41 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

    > What has changed?

As you know I'm a big proponent of using an IDevID with an onboarding protocol to obtain an LDevID.
I think that this is still an important path.  But, it's not the only path!

While I think your next comment might be about divergent paths causing market
confusion,  I think that we are already there.   There are presently a number
of incompatible systems out there that deliver keys from the factory to be used in production.

I think that the DANISH might be an interesting way to publish *LDevID*s.
While I might onboard a device into my network, in the future, imagine that different operational networks might need to interact without having an ownership relationship.  For instance, any personal wearables you might have interacting with a variety of building or vehicle systems that you are in.
How will I give you permission to turn on the lights in my house?
I'd surely prefer to list that authorization by DNS name, rather than hash, right?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 21 Jun 2021 12:41:57 -0400

> On 21 Jun 2021, at 1:10 am, Hannes Tschofenig <[email-masked]> wrote:
> 

FWIW, nothing about DANE suggests using a single key for multiple
purposes.  On the contrary for server identity, DANE has a much
better story than WebPKI, because the server is authenticated by
port and name, not just name, which makes it easier (with DANE-EE(3))
to field a separate key for each service endpoint.

If we're extending DANE to client identities, we can again create
application-specific names, with a separate key for each application:

    _app1.device12345.example.com. IN TLSA 3 1 1 ...
    _app2.device12345.example.com. IN TLSA 3 1 1 ...
    ...

Just register appropriate special-use labels for each distinct
application-specific key, perhaps even multiple keys for a single
application where it makes sense to have key separation.

If the protocol in question is unrelated to TLS, one should consider
using a new record type, other than TLSA.  There may be additional
data beyond the key value or digest that would be beneficial to
return.

-- 
-- 
	Viktor.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Jun 2021 17:00:56 +0000

Hi Viktor,

Thanks for the clarification.

What other information do you envision storing in the DNS besides the public keys?

Ciao
Hannes

PS: Btw, I don't think the comparison to WebPKI is necessary because (a) the WebPKI is not used in the IoT context and (b) the WebPKI focuses on server certificates.

-----Original Message-----
From: Danish <[email-masked]> On Behalf Of Viktor Dukhovni
Sent: Monday, June 21, 2021 6:42 PM
To: [email-masked]
Subject: Re: [Danish] Charter Text and the Problem Statement

> In the past we used different keys for different purposes. A manufacturer provided key was used for a relatively small number of tasks (typically for obtaining operational keys). For use with appli…

FWIW, nothing about DANE suggests using a single key for multiple purposes.  On the contrary for server identity, DANE has a much better story than WebPKI, because the server is authenticated by port and name, not just name, which makes it easier (with DANE-EE(3)) to field a separate key for each service endpoint.

If we're extending DANE to client identities, we can again create application-specific names, with a separate key for each application:

Just register appropriate special-use labels for each distinct application-specific key, perhaps even multiple keys for a single application where it makes sense to have key separation.

If the protocol in question is unrelated to TLS, one should consider using a new record type, other than TLSA.  There may be additional data beyond the key value or digest that would be beneficial to return.

--
--
        Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 21 Jun 2021 13:20:07 -0400

> On 21 Jun 2021, at 1:00 pm, Hannes Tschofenig <[email-masked]> wrote:
> 

I don't have anything specific in mind.  Just noting that TLSA isn't necessarily
the only RR type to consider.  New RR types can be defined where it makes sense to
do so.  The TLSA RR type was intended for use with TLS (server) endpoints, but
can reasonably be extended to TLS client identities.

Other use-cases may warrant a different RRtype either because the relevant fields
are different, or because one specifically wants to avoid confusion with TLS.

Of course for client identity we get special-use labels to distinguish between
different application domains, so a common RRtype is OK if the fields (e.g. usage,
selector, mtype, data) work across multiple applications.

-- 
	Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jun 2021 20:38:25 -0400

Hannes Tschofenig <[email-masked]> wrote:
    > I was not necessarily thinking about IEEE 802.1AR and the way BRSKI
    > uses it. BRSKI is kind of special in the way it is designed.

It's not that special, actually :-)

DeviceAuthority has a similar design in their proprietary protocol.
  (I don't know many details, just presentations, they have NDAs)
The Intel-SDO, now FIDO IoT, is also very similiar.
It looks like CHIP/MATTER also arranges for an LDevID equivalent, but without
a voucher.

    > In general, in security there is the idea to use different keys for
    > different purposes. If that has changed then I completed missed it.

It's clearly better to do that if you can.

But, _better sometimes is often the enemy of good enough_ is a proverb I've
heard attributed to many cultures.  Better the keypair you overuse
than the factory default password you can never change, right?

My hope that the TLS subcerts mechanism will allow us to operationally use
different keys, while from an identity and authorization point of view, it's
all one virtual key.  But, first that has to get deployed ubiquitously.

    > Regarding the management of access with wearables and smart home
    > deployments using standardized protocols I thought that this is why we
    > did all the work in ACE.

Yes, that's true.  We did that all that stuff in ACE to allow the protocols
and the authorizations, but the specification and onboarding of identities
was specifically out of scope for ACE.  You might recall that I insisted on
that.
I wanted to do that, because I didn't want ACE to attempt to boil the same
ocean that ANIMA and others were also boiling.

Here in DANISH, we can now look forward to the situation where we can use
what is essentially the well-protected (in some TEEP) factory provisioned
key, with the DANE based identity in the authorization list.  *OR* we could
have the private PKI of one operator vertical to export to DANE for
interoperation with another vectical.  Or some hybrid mix.

What's the bottom line Hannes should take home:
       _billions and billions of new mbedTLS users_ :-)