ISE 2.4: EAP-TLS authentication trust full chain is not enforced

[Johannes Luther]

Hi ISE pros,

I have a question regarding the ISE behavior in combination with EAP-TLS with a PKI with multiple hierarchy levels.

Let's assume the following CA structure:

ROOT-CA

    |- SIGN-CA-1

    |- SIGN-CA-2

Client certificates are issued by SIGN-CA-1 and SIGN-CA-2.

From the years of deep and dark ISE administration I thought, that all CA certificates must be imported into the ISE trusted CA store and marked with "Trust for client authentication" to successfully authenticate a entity with EAP-TLS.

This also is documented in the Admin Guide:

>> If a certificate chain consists of a root CA certificate plus one or more intermediate CA certificates, to validate the authenticity of a user or device certificate, you must import the entire chain into the Trusted Certificates Store.

source: https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_0111.html

Today I have a EAP-TLS authentication in my RADIUS live log, with passed EAP-TLS authentication from a issuing CA, which is not in my trusted CA certificate list (in the example above SIGN-CA-2). However, the corresponding root CA (ROOT-CA) is in the trusted certificate store.

Is the documentation wrong? What's the expected behavior? What are your experiences?

Best regards

Johannes

[Arne Bier]

Clarifying question @Johannes Luther  - do you have a tcpdump of this occurrence?  AFAIK, in the web server world, a client can request the full CA cert chain from the server, in the case where the client doesn't have the full CA cert chain. Now, in your case where ISE is validating the client cert, is the "client" and it may request the full CA cert chain from the "server" (i.e. the supplicant).

I might be wrong, but the tcpdump might reveal whether there is some "supplementation" going on behind the scenes. And that might also validate the theory that only the Root CA is mandatory in any trust store. I have tried to research this myself. It seem the Root CA is the ultimate Anchor Point. And then all the "intermediates" (intermediate CA's) are optional in a trust store - BUT - they should be available upon request if they are not in the trust store.

[Johannes Luther]

Hi @Arne Bier ,

somehow I knew you'd respond to my question :) Thanks for that!

Regarding the tcpdump - unfortunately not, because it was a one time occurance in a production network.

But hell - you're right. It's "normal" TLS 1.0 (e.g. Win7) or TLS 1.2 (e.g. Win10) for all TLS based EAP methods. I know the behavior, that the TLS server may (and should) send the full certificate chain in the TLS server hello message. We see it day by day when using for example CWA. We have a CWA web certificate from a public intermediate signing CA, but the client has typically and most probably only the root CA.

I newer thought of the fact, that i might be the other way around as well.

If this would be the case (the client sends the whole chain in the "client hello" message) some interesting questions arise:

• Does the ISE perform OCSP checking? If yes, because of the AIA information or based on the root CA setting?
• Does the ISE perform CRL checking? Normally I would assume no, because the ISE does not support the CDP information embedded in the certificate, right?

In any case this should be documented :)

Let's check the RFC 5216 (EAP-TLS for any hints):

---

Since the EAP-TLS server is typically connected to the Internet, it
SHOULD support validating the peer certificate using RFC 3280
[RFC3280] compliant path validation, including the ability to
retrieve intermediate certificates that may be necessary to validate
the peer certificate.  For details, see Section 4.2.2.1 of [RFC3280].

---

Somehow the section 4.2.2.1 of RFC3280 (CRL RFC) is describing AiA (Authority Information Access).

I always thought this extenstion is only there to get the location of the OCSP server, but ...

---

The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. [...]

This profile defines two accessMethod OIDs: id-ad-caIssuers and
   id-ad-ocsp.

   The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates superior to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user.

   When id-ad-caIssuers appears as accessMethod, the accessLocation
   field describes the referenced description server and the access
   protocol to obtain the referenced description.  The accessLocation
   field is defined as a GeneralName, which can take several forms.
   Where the information is available via http, ftp, or ldap,
   accessLocation MUST be a uniformResourceIdentifier. 

---

Wow - If I understand the whole bunch of text correctly, OCSP may be used to retrieve CA certificates. No clue if this happened here, but good to know.

However I would expect, that I see this information in the RADIUS live log details in the step data. I didn't see anything that points in this direction.

Let's continue in the EAP-TLS RFC:

   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, either it will need to be pre-configured with the
   necessary intermediate certificates to complete path validation or it
   will rely on the EAP-TLS peer to provide this information as part of
   the TLS handshake (see Section 7.4.6 of [RFC4346]).

This is the thing I thought in the first place. The TLS client may send the whole certificate chain as part of the client hello message ("certificate_list").

So in any way, the RFC provides ways to get the whole chain. Either using the AiA field or by using the full chain in the client hello TLS message. However, it's not documented if and what methods the ISE supports. As always, the Cisco documentation is very good in some parts, but is missing crucial details :) **bleep** (..or I couldn't find it ... :) But nagging around in the first place is more fun :))

I guess it'll make sense to open a TAC case for this. In the best case I'll get a new documentation bug ID.

Furthermore, I'll spend an hour or so in the lab to check this out (with my very limited self-built OpenSSL PKI).

Keep you posted. Please keep this discussion going in case you have more ideas or thoughts on this.

[Johannes Luther]

So, I did a couple of tests in my lab with a Windows 10 client performing (wired) EAP-TLS.

Base situation:

PKI structure

ROOT-CA
  |-- SERVER-SIGNING-CA-1      <-- Issuer for ISE EAP certificae
  |-- INTERMEDIATE-CA-1
  |     |-- CLIENT-SIGNING-CA-1    <-- Issuer for client certificates      

In the initial attempt I did everything as usual:

The ISE has all CAs in the trusted certificate list. The CA's ROOT, INTERMEDIATE-1 and CLIENT-1 are marked as "trust for client authentication.

EAP-TLS authentication attempts

Scenario 1: ISE trusts the whole client CA chain (imported CA certificates)

What I did in the fist place is to see if my lab works and attempt an EAP-TLS authentication of the Windows 10 client. I captured the EAP messages and checked them in Wireshark.

Interestingly, the Windows 10 client sends the full chain after the server hello message. So the dance is (shortened): Client Hello message, Server Hello message and then "TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages" (Content Type: Handshake (22)).

This message contains:

• The client certificate AND the intermediate and singning CA certificates (not the root, which makes sense)
• As expected the client key exchange and the change cipher spec stuff

So the Windows 10 client obviously does something :)

Scenario 2: ISE trusts only the ROOT CA certificate

So I deleted all the intermediate and signing CAs in the client path from the ISE trusted certificate store

==> Only the root CA remains in the store

Scenario 2a: Win10 client has the intermediate CAs in the local "Intermediate Certification Authorities" store

EAP-TLS authentication successful. However I didn't see, that the ISE attempts to perform certificate validation using OCSP or CRL checking, although the crlDistributionPoints and AiA (OCSP) extensions are present in the client certificate.

Scenario 2b: Win10 client has the intermediate CAs NOT in the local "Intermediate Certification Authorities" store

Before authentication I deleted the "CLIENT-SIGNING-CA-1" from the "Intermediate Certification Authorities" folder in the certificate store. I would assume, that the authentication attempt will fail.

EAP-TLS authentication is successful (strange). However, when checking the capture, the client still sends the "CLIENT-SIGNING-CA-1" along => Reboot of Windows 10 client / perhaps there is still something in the memory.

After the reboot of the client, EAP-TLS authentication failed (EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client certificates chain)

=> So this is the prove, that the ISE honors the CA certificates of the client handshake

When adding the CA certificate back to the intermediate CA store, authentication is successful again.

Summary

So I guess the ISE successfully authenticates an EAP-TLS client when not holding all CA certificates in the store if:

• The client sends the CA certificates in the EAP-TLS handshake
  Question: Can you be sure if the client actually does this? I checked a Win10 (1903) client here. Who knows how any other client behaves. The RFC states
  

  [...]
  certificate_list
    This is a sequence (chain) of X.509v3 certificates. The sender's
    certificate must come first in the list. Each following
    certificate must directly certify the one preceding it. Because
    certificate validation requires that root keys be distributed
    independently, the self-signed certificate that specifies the root
    certificate authority may optionally be omitted from the chain,
    under the assumption that the remote end must already possess it
    in order to validate it in any case.
  
  The same message type and structure will be used for the client's
  response to a certificate request message. Note that a client MAY
  send no certificates if it does not have an appropriate certificate
  to send in response to the server's authentication request.

  From my point of view, you cannot be sure if the client sends the CA certificates (even if they are in a local certificate store)
• The ROOT CA is in the ISE store

However what's still open to understand this completely is:

• Does the ISE perform CRL or OCSP checking of the client certificate? In my tests I didn't see any indication of this.
• Does the ISE support other ways to get the client CA chain? For example over the AiA extension?

I guess I'll open a TAC case for this - let's see what happens.

From my point of view the ISE documentation is not correct, because the admin guide states:

> If a certificate chain consists of a root CA certificate plus one or more intermediate CA certificates, to validate the authenticity of a user or device certificate, you must import the entire chain into the Trusted Certificates Store.

source: https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_0111.html

[hslai · Accepted solution]

In case you not got the answers back from TAC yet...

> Does the ISE perform CRL or OCSP checking of the client certificate? In my tests I didn't see any indication of this.

Yes. The CRL or OCSP needs configured in the page for the associated root CA object.

> Does the ISE support other ways to get the client CA chain? For example over the AiA extension?

Not for EAP-TLS.

[Johannes Luther]

Hi hslai,

thanks for your reply. One question regarding this

>> Yes. The CRL or OCSP needs configured in the page for the associated root CA object.

Problem is, how do you configure the CRL URL (CDP) within the root CA certificate?
Each intermediate/signing CA has its own CRL URL. Example:

CA-ROOT-01 (no CRL / offline)
- CA-INTERMEDIATE-1 (CRL URL: http://crl.somedomain.test/CA-INTERMEDIATE-1.crl)
  - CA-SIGN-1 (CRL URL: http://crl.somedomain.test/CA-SIGN-1.crl)
  - CA-SIGN-2 (CRL URL: http://crl.somedomain.test/CA-SIGN-2.crl)
  - CA-SIGN-3 (CRL URL: http://crl.somedomain.test/CA-SIGN-3.crl)

 Assuming there's only the CA-ROOT-01 in the trusted certificate store and the client certificates are issued by the CA-SIGN- CAs... How does the ISE know the URL of the CRL / CDP for any of the signing CAs, if they are not imported in the ISE?

[Arne Bier]

I have come to the conclusion that the subject of certificate revocation in general has been a flop. CRL’s are never available in time, and for the internet they don’t scale because the size of the CRL become too large. Then there is OCSP. Sounds great in theory but the OCSP responder becomes a point of failure in the design. OSCP with stapling sounds like the panacea. But I doubt ISE supports this. I have also noticed in other vendor forums that people don’t have much love for cert revocation. It appears that folks rather use the power of AD to block access rather than revoking a cert. maybe it’s the lazy way out. I would like to see cert revocation working effectively. But CRLs are not that smart, when you consider that a CRL download may only occur every two weeks. 

ISE doesn’t interpret the CDP properly. It will try and follow an LDAP URL if it’s o

[Arne Bier]

I couldn’t finish my sentence. Replies in iPhone Safari don’t work. Editing is broken somewhat. Anyway. If CDP contains an LDAP URL (as is the default in most MSoft CAs) then ISE chokes on that. You must always set the CRL URL manually. 

[Johannes Luther]

So, I have a documentation bug ID for this now: CSCvs59836