Re: ISE 2.3 with OCSP - Authentication an Authorization

paul46 · ‎03-04-2018

Hi Folks,

I have successfully authenticated machine using certificate (EAP-TLS) and having an interesting issue. I have configured OCSP server (external CA) and tested same machine with expired certificate. not sure why it's successfully authenticating? Also, I used CERTIFICATE:Is Expired=True authorization condition but it would not trigger. It's bypassing this condition and going further and executes the one which provides full corporate access!

I would expect failed authentication if certificate is not valid then why it's even going to the authorization phase?

I have ensured that firewall is not an issue between ISE and OCSP server.

Has anyone got similar experience before? Not sure if it does require any configuration at OCSP server end. I have asked external CA to confirm this. Meanwhile, just thought to put it here for further discussion.

Octavian Szolga · ‎03-05-2018

Hi Paul,

You can easly check what's wrong by just looking at radius live logs. Just click (magnifier glass button I think) on a succesfully authenticated session and you will get some extra info regarding that session. You will see also some OCSP info that will be relevant to your question.

Thanks,

Octavian

paul46 · ‎03-05-2018

Thanks Octavian

I had a look into Radius live logs and not sure why the machine with expired certificate is passing the authentication? According to logs, it looks for machine hostname in AD and hence passing the authentication but the certificate is expired!

Have a look at the log from number 22072 onward.

Cisco Identity Services Engine

12807	Prepared TLS Certificate message
	12808	Prepared TLS ServerKeyExchange message
	12810	Prepared TLS ServerDone message
	12811	Extracted TLS Certificate message containing client certificate
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12318	Successfully negotiated PEAP version 0
	12812	Extracted TLS ClientKeyExchange message
	12813	Extracted TLS CertificateVerify message
	12804	Extracted TLS Finished message
	12801	Prepared TLS ChangeCipherSpec message
	12802	Prepared TLS Finished message
	12816	TLS handshake succeeded
	12310	PEAP full handshake finished successfully
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12313	PEAP inner method started
	11521	Prepared EAP-Request/Identity for inner EAP method
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	11522	Extracted EAP-Response/Identity for inner EAP method
	11806	Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	11808	Extracted EAP-Response containing EAP-MSCHAP challenge-response for inner method and accepting EAP-MSCHAP as negotiated
	15041	Evaluating Identity Policy
	15048	Queried PIP - Radius.Called-Station-ID
	22072	Selected identity source sequence - Identity_Source_Seq
	15013	Selected Identity Source - AD
	24431	Authenticating machine against Active Directory - AD
	24325	Resolving identity - host/machine_name@company.com
	24313	Search for matching accounts at join point - company.com
	24319	Single matching account found in forest - company.com
	24323	Identity resolution detected single matching account
	24343	RPC Logon request succeeded - machine_name$@company.com
	24470	Machine authentication against Active Directory is successful - AD
	22037	Authentication Passed

Octavian Szolga · ‎03-07-2018

Hi,

If your tests were with an expired cert, then OCSP is not related to the issue. Any system can check for expired certs (date/time comparison). If your cert was revoked, then OCSP should be investigated.

Can you please double check? Maybe your time and date is wrong or you haven't considered the timezone when you ran the test?

Thanks,

Octavian

paul46 · ‎03-07-2018

That was helpful Octavian. Let me revoke the cert and put my findings here.

RE- Expired cert issue

I have just checked my ISE is successfully synced with NTP server. Both CLI and GUI time looks good. I will keep troubleshooting. Meanwhile, if you know anything I can check, plz let me know.

jan.nielsen · ‎03-14-2018

From the logs you posted, your client is not running EAP-TLS, it is clearly using PEAP-MSCHAP see id 11808, which uses username/password to authenticate not certificates, the TLS it mentions is the tunnel that is built using a trusted cert on ISE, not a cert on the client. Either your windows supplicant is incorrectly configured, or you didn't configure it at all. Once that is correctly configured, you should also check that your authentication policy allows EAP-TLS. Jan

paul46 · ‎03-14-2018

Thanks jan.

It looks like we have spotted the issue. We are not using EAP-Chaining so no supplicant is configured on client machine such as Cisco AnyConnect. I guess machine uses default in-built supplicant.

Also, this now explains why a machine with expired client certificate is passing the authentication. It uses PEAP-MSCHAPv2 and finds domain user in the Active Directory.

Now, to fix this, I have unchecked "Allow EAP-MS-CHAPv2" (see below) and checked EAP-TLS

It seems the inbuilt windows supplicant demands for MSCHAP protocol. From below, can we deduce that client supplicant need to change to EAP-TLS or something wrong at ISE end?

For certificate authentication profile it uses SUBJECT ALTERNATIVE NAME as certificate atrribute to match from Active Directory

As per your suggestion, I have put below authentication condition for EAP-TLS but it fails as client is asking for MSCHAP, not EAP-TLS.

I would like your and other's thoughts on this.

Update - I can see OCSP in logs now. Please check my lastest update on this thread below.

paul46 · ‎03-14-2018

I can now see OCSP in logs but issue is not resolved.

Jan was right. The supplicant on windows machine used PEAP (MSCHAPv2) as default. I changed it to use certificate and also updated authentication policy for EAP-TLS (see below)

ISE successfully authenticates machine using PEAP (EAP-TLS) now and got below logs.

RADIUS Logs

12568	Lookup user certificate status in OCSP cache - certificate for <machinename>
	12569	User certificate status was not found in OCSP cache - certificate for <machinename>
	12988	Take OCSP servers list from OCSP service configuration - certificate for <machinename>
	12550	Sent an OCSP request to the primary OCSP server for the CA - External OCSP Server
	12561	Connection to OCSP server failed - certificate for <machinename>
	12552	Conversation with OCSP server ended with failure - certificate for <machinename>
	12572	OCSP response not cached - certificate for <machinename>

As shown above, not sure why connection to OCSP fails. I have verified again and again that there is no firewall issue.

The next thing

1. I am checking with CA is to make sure that OCSP services are running or not.

2. Any idea why logs indicates "user" certificate. I think it should be "machine?

If you have any idea from the logs, plz let me know.

Investigation continues :-)

I will keep posting you all. Appreciate your time guys.

ajc · ‎03-15-2018

Even though the following link is related to ACS, check if that helps you.

https://supportforums.cisco.com/t5/aaa-identity-and-nac/acs-5-4-ocsp-debug/td-p/2163279

INCLUDING THE FOLLOWING PART:

In my case it turned out that the OCSP responder URL was incorrect. In fact I was missing the /ocsp suffix.

ACS logs can be somewhat ambiguous, so best try to query the OSCP responder with openssl and look for any hints in the response:
openssl ocsp -issuer "path to issuing ca certificate" -cert "path to certificate you want to verify" -url "OSCP responder URL"

Hoping that helps

paul46 · ‎03-19-2018

Final update: there is no issue at ISE end. OCSP is not working as there is some issue on OCSP server

As an alternate workaround, I tried CRL but ISE was not downloading CRL with cisco ISE 2.3 patch 1. After troubleshooting, I found that it is due to a bug (see below link). Cisco has release 2.3 patch 2 on 25th Jan 2018. After installing the patch, CRL is working.

https://supportforums.cisco.com/t5/cisco-bug-discussions/cscvc17726-ise-2-1-could-not-download-certificate-revocation/m-p/3351281#M6839

Thanks all for your time. Appreciate it.

ajc · ‎03-08-2018

Looks like the OCSP configuration on ISE is not completed. Take a look on the following link

https://wifidiversity.com/2017/09/04/cisco-ise-ocsp-settings/

paul46 · ‎03-08-2018

Thanks Abraham

I have verified OSCP client profile config and it looks good. But not sure if I the OCSP profile is applied correctly or not. One thing that confuses me and want to confirm is this

The root chain is like ROOT CA -> INTERMEDIATE CA -> MACHINE CERT

As per your link, I have bind OCSP client profile to INTERMEDIATE CA. As far as I am aware, I don't need to apply OCSP to ROOT CA or any other individual cert? I am not seeing any OSCP status in RADIUS logs at the moment. So, it looks like the profile is fine but applying to the right place.

ajc · ‎03-09-2018

Clarification:

The certificate to revoke or expire manually is the INTERMEDIATE one if you want to test the EAP-TLS authentication under that scenario.

The enduser device cert has a chain which contains that Intermediate Cert, so ISE based on OCSP has internally cached the information about the expiration/revoke process on that Intermediate Cert. Therefore, when the enduser device presents the cert, ISE validates it and because the intermediate in the chain is expired/revoked then ISE rejects the EAP-TLS authentication.

How you can check the cert chain??. See next

On the example below, the Intermediate CA in the chain is EntISSUE

paul46 · ‎03-12-2018

Hi Abraham,

I thought the expired or revoke cert would be an individual machine cert. I have just revoked a machine certificate (Not Intermediate) and still not seeing anything related to OCSP. It is still passing the authentcation phase.

I will test Intermediate cert with expired and revoke but just some questions

1). If an individual machine is comprised from security perspective, doesn't it make more sense to disable machine (individual) cert?

2). Intermediate cert is part of root chain who is published by Root CA and usually managed by External CA. Just to test OCSP, if they revoke or expire intermediate Cert, won't it break the root chain for all the machines? or if I install a root chain with expired/ revoked intermediate on a machine to test OCSP.

Thanks you and all who are assisting me to get deep understanding on this. In next post, I will post my result with expired and revoked Intermediate cert and see if I can see any OCSP related logs in ISE RADIUS

Octavian Szolga · ‎03-13-2018

Hi,

My understanding is the same. You don't have to revoke the intermediate CA cert to test EAP-TLS OCSP services. The point in having OCSP applied to an intermediate or root cert is to check the status of the client cert.

So, if a laptop is stolen/lost, one should revoke the machine cert so that ISE would check online its status. So it makes sense not to revoce the intermediate cert but the machine/user cert.

Have you tried a telnet on OCSP port? Or to check if OCSP url is correct? (compare it with the one inside the cert?

Thanks,

Octavian