WLC 4400: EAP-TLS

[Jaaazman777]

Good day!

I tried to set up the EAP-TLS according to

- http://cciew.wordpress.com/2010/06/10/eap-tls-on-the-wlc/

- http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml

- Jeremy video about EAP-TLS

The main question is about certificates.

Tell me if I am wrong -  There are two types of certificates that we need to upload to the WLC:

1) Device certificate - this is quite clear, OpenSSL, Certificate Request and e.t.c.

2) CA Root certificate - if there is only one CA Root than clear, but if we have the following chain

Root CA -> Intermediate CA -> WLC

a) Do we need to upload the whole chain "Root CA -> Intermediate CA" to the WLC ?

b) If yes, what format is it going to be? maybe smth like this

------BEGIN CERTIFICATE------
*Intermediate CA cert *
------END CERTIFICATE--------
------BEGIN CERTIFICATE------
*Root CA cert *
------END CERTIFICATE------

[Nicolas Darchis]

http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml

In your example you don't need to provide the Root CA certificate because we suppose that the client already knows and trust this root CA. so you only need to bundle the intermediate CA with the WLC certificate.

[Jaaazman777]

Nicolas, thank you for your reply!

1)

I've already seen the article, but now notice some interesting fact:

"Note: Chained certificates are supported for web authentication only; they are not supported for the management certificate."

Regarding this note, do we need to bundle any certificates for EAP-TLS scheme?

2)

On the WLC we have an opportunity to download two types of Certificates:

- Vendor Device Certificate - it is made of CSR request and then uploaded to the WLC in .pem format

- Vendor CA Certificate - this is more interesting:

  Yesterday I bundled Root and Intermediate CA Certificates in one .pem file, then uploaded it to the WLC as "Vendor CA Certificate" - the result was suсcessful! During the EAP-TLS auth process SSL Handshake completed sucessfully and I connected to my EAP WLAN!

In the controller Client Properties I saw the EAP TLS>

Everything seems to be ok, strange...

May be, the chain of Root and Intermediate CA Certificates is the redundant information, but the scheme seems to be working!

[Jaaazman777]

One strange thing about the EAP-TLS process

In why scheme Local EAP uses LDAP server for its backend database

(EAP WLAN uses 802.1x as its Layer 2 Security)

During the EAP-TLS connection process in the WLC debug,  I can see the following:

1. Good variant:
   • EAP sends user credential request to LDAP
   • LDAP answers
     • Handling LDAP response Success 
     • Returning AAA Success for mobile ...   
   • Everything is OK, the process goes further   
2. Bad variant:
   • EAP sends user credential request to LDAP
   • LDAP answers
     • Handling LDAP response Authentication Failed 
     • Returning AAA Error 'Authentication Failed'  
   • Everything is NOT OK, but still the process goes further and the EAP-TLS auth appears to be successfull

So we can see, that even if the LDAP check is NOT successfull the whole EAP-TLS auth is OK - it is very strange and not very secure!

Is that right?

[Nicolas Darchis · Accepted solution]

My poitn of view is that there is no credentials for EAP-TLS.

The verification of EAP-TLS is just making sure that the client is presenting a trusted certificate. And trusted means that the WLC can verify its CA.

So we don't care about credentials verification since there isn't any, right ?

[Jaaazman777]

Yes, it makes sence

But what about the feature "Local EAP using LDAP server as its backend database"?

in what situation do we need this?

[Jaaazman777]

Nicolas, good day!

I'd like to return to the ldap - EAP-TLS question

In Cisco doc http://www.cisco.com/en/US/docs/wireless/controller/4.1/configuration/guide/c41sol.html#wp1172157

we can see the following:

The LDAP backend database supports only these local EAP methods: EAP-TLS ...

so, I guess, this feature allows the WLC to get user credentials from certificate and send them to LDAP server for user validity

Besides, in WLS logs I can see that process

My question is, why does the EAP-TLS allow access to users that are not stored in AD?

[Nicolas Darchis]

The password equivalent is presenting a trusted cert but also the username is verified, because maybe you only want a subset of people to get access on the WLC. So that's why you do local eap+ eaptls.

What do you mean that users not on AD get access ?

[Jaaazman777]

What do you mean that users not on AD get access ?

1. For example, I purposely provide the LDAP Server with the wrong settings (ex. wrong Base DN)
2. Client iniates the session
3. In the WLC debug I can see that controller sends user credential request to LDAP
4. The reply is Returning AAA Error 'Authentication Failed'
5. But inspite of failed auth the whole auth process is fine, and user get the access!

For what purpose do we need user verification if it doesn't influence the final result?

[Jaaazman777]

Dear Nicolas, I suggest you to go on the conversation!

Let's examine the situation:

• The employee has the valid account in AD.
  • He can get the valid certificate from CA
  • With this certificate he can get access to LAN though EAP-TLS
• Suppose, that the user is dismissed.
  • The user's account is deleted from AD, but he still has the certificate 
  • According to the EAP-TLS verification process, he is still able to get access to LAN though EAP-TLS (!)

According to the situation, there are two main questions:

1. How can WLC prevent such user from getting access to the LAN though EAP-TLS?
2. Can the WLC check whether the certificate is revoked or not?

[Nicolas Darchis]

the WLC is not a complete radius server. Local eap feature is supposed to be used as a backup so it does not support revocation list. So yes the situation you describe would be a problem.

It's like using the WLC for DHCP and complaining it cannot do lots of stuff that DHCP servers do. That's true, but it's not supposed to be a full DHCP/RADIUS etc ...

[Jaaazman777]

Dear Nicolas,

The thing is not about the WLC cannot be the complete radius or DHCP server

Local eap feature is supposed to be used as a backup so it does not support revocation list.

I agree with you, there is no need to the WLC to know something about revocation list.

But what prevents WLC from taking the user credentials from certificate and check this credentials in AD? (!)

Besides, from wlc debug we can see that local eap can send user credentials to LDAP server, but has no influence on the whole EAP-TLS auth process

[Nicolas Darchis]

"taking the user credentials from certificate"

There is no password on a certificaite ... only a "CN" that can (or not) be equal to a username.

What the LDAP query does is to fetch the additional attributes of that user because this is not happening with the certificate validation.

[Jaaazman777]

"taking the user credentials from certificate"

My fault, I meant just username without the password

Let's return to the certificate validity.

We cannot check it straightly with the revocation list, because it is not supported - that's clear

You've wrote:

The password equivalent is presenting a trusted cert but also the username is verified, because maybe you only want a subset of people to get access on the WLC.

step be step:

1. As we cleared up, WLC can retrieve the CN/username from the certificate.
2. Then WLC sends CN/username (and also some attributes) to the LDAP server
3. Now we have two variants:

• the first one: there is the user in LDAP server database - all the auth process is successful - that is clear
• the second: there is no such user in LDAP server database - what decision/conclusion does the wlc make in such situation?

The general question is, why WLC cannot just retrieve the CN/username from cert and ask the LDAP server, whether this user exists in LDAP database or not?

And If there is no user in LDAP database, the whole auth process must be unsuccessful!

Dear, Nicolas, this question is really very important for our organisation

I just try to make sure that there is/no solution for the problem

[Nicolas Darchis]

You are right, I misphrased in previous posts.

The LDAP query is only for attribute retrieval, my bad.

It would be a feasible enhancement request to check the username existence, indeed.

Nicolas