Re: [Danish] Charter Text and the Problem Statement

[Ash Wilson <[e-mail]>]

On Sat, Jun 19, 2021 at 5:47 AM Hannes Tschofenig <[e-mail]>
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.
>

>
> 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.

>
>
> 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?
>
 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
>
>
>
> *From:* Ash Wilson <[e-mail]>
> *Sent:* Thursday, June 17, 2021 8:22 PM
> *To:* Hannes Tschofenig <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Danish] Charter Text and the Problem Statement
>
>
>
> Hi Hannes,
>
> Great questions, responses in-line below...
>
>
>
> On Wed, Jun 16, 2021 at 11:43 PM Hannes Tschofenig <
> [e-mail]> wrote:
>
> 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?
>
>
>
> 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.
>
>
>
> I don’t see any of this user-related interaction being covered as part of
> the chartered work.
>
>
>
> 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 <[e-mail]>
> *Sent:* Wednesday, June 16, 2021 11:28 PM
> *To:* Hannes Tschofenig <[e-mail]>
> *Cc:* [e-mail]
> *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 <
> [e-mail]> wrote:
>
> 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?
>
> 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
>
> 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?
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/danish
>
>
>
>
> --
>
> *Ash Wilson* | Technical Director
>
> *e:* [e-mail]
>
> 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.
>
> 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.
>
>
>
>
> --
>
> *Ash Wilson* | Technical Director
>
> *e:* [e-mail]
>
> 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.
> 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.
>


-- 

*Ash Wilson* | Technical Director
*e:* [e-mail]

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.