Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Michael Richardson <[e-mail]>]

On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote:
> This is also related to ongoing anima discussions about RFC 8366, and how it can bootstrap trust when the pinned domain cert is a public PKI CA, and not a private CA, and hence additional domain (or realm or FQDN) info is also needed in order for the peer to verify the identity of the server.

While I'm familiar with this conversation, which I'm right now inspired
to call the the "Maria" problem
("How do solve a problem like Maria.  How do you a cloud certificate and
pin it down?")

I don't really understand what it has to do with the problem of an EAP
client, **which is not doing initial onboarding**, to validate a
certificate that it has received as part of EAP-TLS*.
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about bootstrapping a supplicant onto an 802.1X network - after a supplicant completes DPP and gets provisioned with a trust anchor - what if that trust anchor is a public PKI? It’s the same problem.

I agree that this is the Maria problem, because the client has to pin
*a* CA and a SubjectDN (specifically a dnsName SubjectAltName), and you
want to allow the server to change public CAs.


>> -----Original Message-----
>> From: Emu <[e-mail]> On Behalf Of Jan-Frederik Rieckers
>>
>> Thank you for your feedback.
>>
>> I was unaware of RFC 7585. I had a brief look on it and it seems that the
>> certificate part could be used for the goal I try to achieve.
>>
>> I'm not quite sure if the naiRealm should be used for validation on supplicants
>> for EAP-TLS. I would assume it would not be a security issue, but I don't have
>> enough experience to be sure about that.
>>
>> The main reason why I submitted this draft is my experience from the
>> deployment of eduroam at University Bremen.
>> With expiry of the used root CA and the needed migration, we have forced all
>> our users to use one specific outer Identity, to be sure the users configure their
>> devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org)
>> instead of a manual configuration, because in our experience manual configured
>> devices almost always lacked configuration for certificate checking.
>> But I just have experience in local deployment, the federation connections are
>> done at higher levels (country research networks), I don't have an insight there.

I skimmed your document before and I didn't understand it based upon my
quick read. Your text here helps me a bit.
In eduroam, the supplicant sees the TLSServerCertificate of the local
institution's Authentication Server, correct?
Is it not the case that for this to be validated that there needs to be
a path to the eduroam's root certificate,
which the client would have pinned?

You need to set the NAI correctly, because we have essentially an
SNI-like issue, in that the Authentication Server
needs to answer with it's eduroam certificate for eduroam clients, and
it might use a different certificate for other clients?

As I understand it, your ran into an issue because the root certificate
expired, and clients had pinned it, but they could find a new
certificate in DNS?