Alexander Clouter <[email protected]> wrote: > I am unable to find a description of what should go into the server > certificate or how, if at all, the client should authenticate it.
It's a huge problem in EAP-TLS, period, isn't it :-)
Solved only via explicit client configuration for the anchor.
> I rummaged around the mailing list but was unable to find anything
> though for some reason I recall discussion that the client would either
> completely ignore the server or did that get later changed to be a
> subject/SAN and/or usage OID check only?
For the purposes of IoT onboarding (using a variety of mechanism), the
relevant protocol would wind up programming/provisioning the appropriate
trust anchor. Until then, it's an unverified situation. In RFC8995, we call
this a "provisional TLS".
The human-operated systems that wind up on a portal-gated network, then what
I envision is that the portal interaction could wind up with a download of a
configuration file to the client.
It would be nice if we could standardize something like:
https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access?tabs=eap-tls%2Cserveruserprompt-eap-tls%2Ceap-sim#xml-profiles-for-eap
I think that there are several other bespoke systems like this.
I believe that most enterprises "solve" this problem with an MDM, but there is
still a challenge for BYOD, for personal devices that one does not want an MDM
on.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
