[Danish] Hospital use case ... RE: Charter Text and the Problem Statement

[Hannes Tschofenig <[e-mail]>]

Hi Wes,


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

https://mailarchive.ietf.org/arch/msg/danish/OkQzlyZoKlEar5-GU6HgtSz3ebY/

Thanks for the pointer to the hospital use case.

Here is the relevant text:

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

Network access authentication is often misunderstood. The use of TLS for network access authentication was a convenience rather than a necessity.
This means that there is functionality in TLS that is neither needed nor particularly useful for network access authentication.

On the web, you want to use a PKI because a browser can access many different websites. Any browser should be able to access any website, ideally.

The network access authentication model is different. There you have a one-to-one relationship. One user with their device has credentials to access one home AAA server.
Why is that? It has to do with authorization. The home AAA grants access to the visiting network via the backend AAA infrastructure. Only the home AAA server knows about the user's authorization information.

In that model, there is not much benefit of a PKI. All you need is a raw public key.

Why are people still using a complex PKI infrastructure for network access authentication? Well. I fear that most network administrators don't get the point that they do not need to model their organizational hierarchy into the PKI infrastructure.

So, what do we do? We offer them with solutions to compress certificates, cache certificates, etc. (see draft-ietf-emu-eaptlscert) when the correct answer would be different.

Hence, the guidance you are mentioning above is actually pointing in the right direction.

If you go into the other direction and basically let the supplicant tap into your browser trust anchor store then you have actually opened up the attack possibility substantially because you can make regular web server certificates verify correctly during the EAP-TLS authentication.

Ciao
Hannes

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.