The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

I've received a response to the Win10/AddTrust analysis from our team lead deploying new infrastructure:

We obviously don’t have control over external CA’s processes at all, or operating system certificate trust stores, and the only resolution would be to use an alternative (non UAF standard) certificate issue process from another CA entirely.....We have established is that a non-CAT assisted connection from Win10 operates as expected and we just reconfirmed this as well.  From our perspective, this is an issue that will need to be resolved via the CAT tool since it appears to be specific to CAT’s ability to process certificates and the stated issue does not impact the ability for Win10 machines to join the network without CAT.

and my reply:

No one's saying the certificate chain in ISE is "wrong" or needs to be changed. What is being claimed is that an intermediate certificate in that chain may be viewed/trusted as root CA by the Windows supplicants [because it has been issued as a self-signed root CA in the past and may have root trust in the client's trusted certificate store], and that in turn causes the supplicant to incorrectly not trust the server certificate. [We've NOT determined that that is the issue we encountered, but the limited evidence points in that direction.]

 

CAT does not process or validate certificates or signatures. The supplicant does. The CAT installer adds exactly the root CA we designate; the profile installed requires the server cert presented to the supplicant to be trusted by verifying the trust chain ending in that root CA we designated and the CAT installer downloaded to the client. This is what the eduroam folks call "locking down" the eduroam configuration to our authentication servers. When a different (now intermediate) rootCA is also a trusted root in the client store, the chain - from Windows client standpoint - does not properly terminate in the root CA we designated in the profile; thus the supplicant refuses to talk further, as intended. That is the suggested, plausible, but not verified analysis.

 

The fact that we can connect to the wireless network by simply providing UA credentials means the Win native supplicant (like others) can connect without the additional security the CAT profiles provide by forcing validation of certificate-based trust to the specific root CA we designate. That native supplicant configuration is evidently more "open" to validate a server certificate chain ending in ANY trusted root CA; that in turn allows some additional attack surface for servers impersonating our ISEs. Opinions will vary on whether that simple native config is "good enough" as is, needs to generate a caution to users, or needs to be resolved in some fashion.

 This triggers my follow-up questions:

Is my restatement of the issue above more or less correct, or importantly incorrect?

Yes, it is very much correct.

What work-around(s) can we propose for Windows clients?

If you can still change the supplier of the server certificate: going to any other CA than AddTrust would of coure make the problem moot.

As others have responded already, using your own private CA achieves the same or superior level of security and is as easy to deploy with CAT installers. Reading your conversations with your team, I guess it would take some amount of pursuasion to make them believe that this statement of level of security is true. You can always inspire yourself at our published argumentation at https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations . Consideration 1 goes into a lot of explanatory detail there.

Finally ...

Would adding a second rootCA in the configuration (the one now used as intermediate) enable the Win supplicant to trust the server cert chain?

... this is probably also an option. It would make the trust issue in 802.1X go away. You should carefully examine if there are any side effects elsewhere on the user device. After all, the root variant of the CA certificate is historic and meant to go away. You might be prolonging a transition situation where ideally you shouldn't.

(and what would be the impact on Android clients said somewhere to require only a single root CA in the profile)

We haven't seen issues with other supplicants on the AddTrust question. If one implements CA certificate chain checks correctly (as per RFC5280), as most supplicants do, then the chain can be observed to end in two alternate roots; and if one of those succeeds, the certificate is valid. To my knowledge, only Windows does not behave like that.

How are other institutions getting around this issue? In my scan for Universities' eduroam onboading documentation I saw a couple emphasize strongly that Windows be fully updated / patched before running the CAT installers; is that in some way related and a mitigation of this problem?

Keeping up to date is always a good idea. I can't tell at all if this advice is being given just as a generic one, or if it relates to other issues on the system (Wi-Fi drivers are still a problem sometimes, and updates do help there), or if it is indeed about the AddTrust situation.

Greetings,

Stefan Winter

Thank you for ongoing insight and assistance.

David Bantz

U Alaska

On Wed, Oct 31, 2018 at 12:02 AM Stefan Winter <stefan.winter AT restena.lu> wrote:

Hello,

oh dear. This appears to be AddTrust all over again. I had hoped this
problem had withered out over time. The issue has been brought up four
or five times now and is mighty annoying.

I'm pasting below a post from 2015 with a very similar or even the exact
problem, depending on how InCommon's chain building is done from the
AddTrust External CA Root.

The core of the issue is that there is an intermediate CA certificate
which hasn't always been an intermediate. It used to be a self-signed
root, but then during some company merger was re-issued as an
intermediate under AddTrust.

Windows devices which have the self-signed variant installed fall over
if they see the identical certificate as an intermediate in their EAP
conversation.

The self-signed variant is not shipped in all Windows installs (Windows
has an updater for its trust store and this may or may not have been
dynamically added in the device you test with).

Can you take a look at the system trust store of this particular Win 10
device and see if any of the intermediates in the chain (as sent in the
EAP conversation) are registered as root CAs in the system? If so, does
removing the root variant help?

Greetings,

Stefan Winter

-------- Weitergeleitete Nachricht --------
Betreff: Re: [cat-users] problem detected with installer from
cat.eduroam.org
Datum: Wed, 21 Jan 2015 15:53:58 +0000
Von: Louis Twomey <louis.twomey AT heanet.ie>
An: cat-users AT geant.net, stefan Winter <stefan.winter AT restena.lu>

This is perhaps the same problem that I have encountered with Windows
7 and 8 machines locally.

I replaced our Radius server cert recently, both new and old certs
were from TCS, the new one is signed by "TERENA SSL CA 2". All
existing wireless supplicants handled the new cert without incident,
except for Windows 7 and 8 devices. They consistently failed on
certificate verification.

When I looked into it I discovered that the chaining on those Windows
devices was broken, they chained my cert as follows:

  USERTrust RSA Certification Authority > TERENA SSL CA 2 >
eduroam-idp.heanet.ie

That "USERTrust RSA Certification Authority" is a root cert, so as
such the chain is complete but it doesn't match the chain the client
is configured to expect, which is:

  AddTrust External CA Root > USERTrust RSA Certification Authority >
TERENA SSL CA 2 > eduroam-idp.heanet.ie

When I checked the local Windows certificate store on a problem
device, it had 2 certificates with the same name of "USERTrust RSA
Certification Authority", one is the root cert, the other is the
intermediate CA cert that TCS uses, it is choosing to chain via the
root one. Deleting or disabling the root USERTrust cert in the local
store solves the problem, the client chains correctly and server
validation succeeds.

So the issue is this extra(?) root cert, it exists on each of the 5
Windows laptops I have looked at here and they all chain to it. I
assume that either this root cert doesn't exist on *every* Windows
laptop, or perhaps is there but is not chained to on every such device
- otherwise eduroam connectivity would, I presume, be failing for any
Windows device where the home site uses a cert signed by the new TCS
chain.

Does anyone else have that root cert in the Third-Party Root
Certificates store of their Windows device I wonder?  These are the
details of the cert:

 Version:  V3
 Serial number:  01 fd 6d 30 fc a3 ca 51 a8 1b bc 64 0e 35 03 2d
 Signature algorithm:  sha384RSA
 Signature hash algorithm:  sha384
 Issuer:  USERTrust RSA Certification Authority
 Valid from:  01 February 2010 00:00:00
 Valid to:  18 January 2038 23:59:59
 Subject:  USERTrust RSA Certification Authority
 Public key:  RSA (4096 Bits)
 Subject key Identifier:  53 79 bf 5a aa 2b 4a cf 54 80 e1 d8 9b c0 9d
f2 b2 03 66 cb
 Key Usage:  Certificate Signing, Off-line CRL Signing, CRL Signing (06)
 Basic Constraints:  Subject Type=CA, Path Length Constraint=None
 Thumbprint algorithm:  sha1
 Thumbprint:  2b 8f 1b 57 33 0d bb a2 d0 7a 6c 51 f7 0e e9 0d da b9 ad 8e
 Friendly name:  USERTrust

Regards,
Louis.

On 21/01/2015 12:21, Stefan Winter wrote:
> Hi,
>
>> just two comments... Stefan, please note that Marcos is from
>> esci.upf.edu, not upf.edu (two different organizations).
>
> Okay. Sorry for being confused :-)
>
>> I explained Marcos that the SecureW2 installer is only used for
>> Win XP, and it should'nt be used by default for win 7 and 8.x
>> (if PEAP+MSCHAPv2 is selected as first option as is the case)...
>> am I right?
>>
>> Of course you could use it in further windows versions too, but
>> given the priority of methods allowed in the profile and their
>> order (1. PEAP-MSCHAPv2, 2. TTLS-MSCHAPv2, 3. TTLS+PAP), I guess
>> the installer for win 7 and win 8.1 is not based on SecureW2...
>
> Yes, with that priority, Vista and above would not trigger
> SecureW2 installation.
>
> And the built-in supplicant which is then used is of course bound
> to Microsoft's built-in TLS validation routines... which are on the
> SHA-1 sunset crusade.
>
>> Also I have to say, I checked this morning and the profile looked
>> fine to me.
>
> Maybe he is still sending the (superfluous) old TERENA intermediate
> CA and Microsoft is (unrightfully) upset about that. Or he is
> missing the second intermediate (IIRC) and the supplicants can't
> complete the chain.
>
> Stefan
>

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature