A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Wednesday, August 19, 2009

Secure Web Authentication

When you create a Web Authentication WLAN on your controller, users authenticate (open), associate, receive an IP address, then get blocked until they open a browser. The DNS query they initiate goes through the controller, and upon receiving the DNS answer, the controller redirects the user to the Web Authentication page, were credentials have to be entered...
It is this last part that I was looking at a few days ago... how are these credentials exchanged between the controller and the client? Post? Pull?
Actually the process is a PAP! When you enter the username and password, the username and password pair is sent over the air with a PAP Access Request message.
The controller validates the username and password pair, from a local list or through a RADIUS server, and grants (or refuses) access. Of course, PAP is a very weak protocol, and you might have jumped on chair while reading this... so is this process so weak that anyone could eavesdrop and read the sent username and password?
Not really, look at this capture of such an exchange. Client is 10.1.1.57 and Virtual gateway 1.1.1.1:



As you might have guessed, the process occurs via HTTPS, so the user credentials are protected by the TLS session... not very easy to hack.
Nevertheless, you could argue that if you were to sniff the exchange, you might be able to break it offline, and that PAP is therefore bad.

Okay, not a problem. You can replace PAP with CHAP. With CHAP, the username is sent through the TLS tunnel, and then the RADIUS or the controller returns a challenge. The client browser encrypts the challenge with the password, and sends the result back. The controller (or RADIUS) does the same on its side. If both results are the same, both sides used the same password and the authentication is successful without the password having been sent.
How do you change Web authentication from PAP to CHAP? Strangely enough, in Controller > General.


The controller natively supports these three modes. If you use an external RADIUS server, make sure it supports them. ACS supports both PAP and CHAP (but not MD5-CHAP as far as I know).

7 comments:

  1. Jerome - thanks

    Have you ever thought that the WLC should be able to capture HTTPS traffic from a client to redirect to web-login?
    It will only redirect HTTP as far as I know, not good enough for enterprise in my opinion! Any ideas?

    :)

    ReplyDelete
  2. Hi Guys,

    Its nice brifing here. I was wondering that when user get redirect towards web auth server(in case of external one) what code and setting it matches before it sends request to Active directory to confirm the user credintial?

    I believe you guys are here to share experience and knowledge base.

    I am on my way to towards CCIE wireless and wish to join you guys... cheers!!!

    ReplyDelete
  3. Hi Anonymous,

    Check here:
    http://www.cisco.com/en/US/docs/wireless/controller/5.1/configuration/guide/c51users.html#wp1049404

    The main fields you have to pay close attention to are username and password. Those 2 values are returned from the external Web server to the WLC. Then it all depends on your policy for this WLAN. IF you use an external RADIUS, this RADIUS can be linked to Active Directory to verify the username/password pair. If you use Local EAP, you can use an external LDAP server (but not Active Directory)...
    hth

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. Hi I enabled CHAP on WLC but win server sees these as MD5-CHAP on logs ...when using PAP all works fine..any ideas pls ?

    ReplyDelete
  6. What RADIUS (and which version) do you use on your Win server?

    ReplyDelete
  7. I have same problem using win 2008 server - all works fine using PAP on WLC but changing to CHAP - I get rejects from 2008 on wlc aaa debugs

    ReplyDelete