CWP PAP

  • 3
  • Question
  • Updated 5 years ago
  • Answered
Helo
We using CWP for our students to logon by a RADIUS server. It works well. The only thing is that we have to use the PAP authentication protocol instead of the CHAP when we use the CWP (otherwise we can use the CHAP protocol).
Following questions I have:
- Is this a problem/acceptable?
- is this because we use a self-signed certificate?
- I believe that the password is, altough we using PAP, sended encrypted to the authentication server?

Thx!!

Kind regards

hans
Photo of Hans Matthé

Hans Matthé

  • 42 Posts
  • 2 Reply Likes

Posted 5 years ago

  • 3
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Due to the fact user credentials in username and password form normally give you access to other things, It is not something that is usually acceptable from a security perspective to pass them over the wire in naked RADIUS via PAP, CHAP or CHAPv2. Rather, a secure TLS protected EAP type like EAP-PEAP or EAP-TTLS should be used to protect them.

(The only generally acceptable use case for PAP, CHAP or CHAPv2 for access points and switches is MAC address authentication due to the nature of what you are authenticating to begin with.)

It is a security concern that needs to be addressed by many vendors in their products. If security is important to you in this regard, you might consider opening a support case with Aerohive seeking consideration of the issue for potential resolution in their future code. (I do not use this area of HiveOS as I am philosophically opposed to CWPs and always use 802.1X or PPSKs. I would have otherwise done so myself already.)

Using 802.1X terminology to explain things, HiveOS should conceptually be acting as both the supplicant and authenticator where a CWP is being used with an external RADIUS server. It should not be sending credentials unprotected or weakly/superficially protected unless explicitly configured to do so, with warnings.
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hi Hans,

There should be no reason why you would be forced to use PAP over CHAP or MS-CHAPv2 when using our CWP. I have tested this in the lab (as well as time and time again in customer scenarios) and was able to authenticate through a User Auth CWP using MS-CHAPv2, CHAP and PAP. The only catch with CHAP is that I did have to do the following:

1) Set the Authentication Method Constraint to allow Encrypted Authentication (CHAP) in NPS (keep in mind that I had to do this for both PAP and MS-CHAPv2)
2) Enable "Store password using reversible encryption" in the account options for my test user
3) After performing step 2, I had to reset the user's password so it would be stored using reversible encryption (this is not automatic)

After these three steps I was able to authenticate my test user using CHAP against our User Auth CWP.

Now, having said all of this, Nick is correct in his statement that passing the user's credentials using PAP, CHAP or MS-CHAPv2 outside of a protected EAP type such as PEAP is not recommended when other options are available. However, if you require your users to authenticate through the CWP as opposed to direct 802.1X/RADIUS authentication through the client, then it is what it is currently; just be aware that there are limitations to the security afforded by these methods.

Hope this helps
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Thanks for the clarification, Brian.

This issue constututes a security concern in the CWP implementation:

https://www.cloudcracker.com/blog/201...
https://www.cloudcracker.com/

You can reverse CHAPv2 handshakes relatively cheaply at the second link.

It would be in many deployment scenarios relatively easy to capture behind an access point with a hub or small managed switch with port mirroring enabled and Wireshark acquiring the bits necessary to reverse user credentials. Those credentials, of course, should have been entered over HTTPS (TLS) to begin with via the CWP so you have a notable weak link in the authentication process chain in the RADIUS packets. (This assumes the authentication took place to the intended domain and the certificate was properly validated by the browser.)

Because there is no identity privacy, you could discriminate and target just the users that had access to sensitive systems or information via their credentials.
Photo of Hans Matthé

Hans Matthé

  • 42 Posts
  • 2 Reply Likes
Nick and Brian, thx for the nice feedback. I have planned a 'finetune' day with an Aerohive specialist to sort this out.
Photo of Hans Matthé

Hans Matthé

  • 42 Posts
  • 2 Reply Likes
Brian
One more question, is using the reversible encryption policy not a security risk by itself and so not more secure as PAP?
Thx for the reply.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
That was my point. There is a higher barrier to entry with CHAPv2 as you need to reverse it via brute force, but it is realistically achievable where there is a will to do so.

The secure TLS based EAP types were created to correct this issue. (PEAPv0, for example, arrived with Windows XP SP1 back in 2002.)

This is by no means an Aerohive specific issue, it is an industry wide problem due to poor security practices.
Photo of Hans Matthé

Hans Matthé

  • 42 Posts
  • 2 Reply Likes
Nick
Does this mean that the CWP can not be used in a secure level? 802.1x by EAP is still be used to do the authentication, right (or is this wrong)?
Thx!!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I am not quite sure what you are asking...

It does mean that conceptually a CWP cannot be used in a secure way for even secondary authentication if you have first authenticated via 802.1X and then go on to use a CWP but it is not exclusively because of this. CWPs in general are vulnerable to other issues too on the browser side, for example the HTTP to HTTPS redirection is intrinsically insecure.
(Do Aerohive even support a secondary authentication in this way anyway? I should read the docs!)

(Just to confirm: You are not using 802.1X if you are using a CWP alone where the CWP then uses an EAP type to authenticate to a RADIUS server.)

In abstract, where you are carrying out a conceptual secondary authentication via a CWP, via ARP poisoning in the same broadcast domain, a login can be hijacked/stripped so the login remains over HTTP or redirected to a different URL, many users will not notice the address they end up on if it via HTTPS. You have a chicken and egg problem for new users - how are they supposed to know where they are meant to be?

(Where you only use a CWP as a single method of authentication on an open network, which is what most people have, it is in addition vulnerable to the same issue via a rogue access point too.)

You will have to use 802.1X alone if you want to do user authentication securely in a robust way based on account credentials therefore. If you decide it is not a risk that is of sufficient concern to you and the utility of a CWP outweighs the negatives, then stick with it.

802.1X alone is not perfect as it requires configuration of the supplicant so that the login is secure by validating the certificate appropriately, but it can be made to be at least.

You could also choose to use PPSKs alone that you map to users, but this is then not using direct user credentials and this can create other logistical issues. It is a fantastic half way house though and is a really enabling feature to have.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I have updated my answer as I am not sure if you are confusing a CWP using an EAP type with 802.1X or mean that you are using a CWP as a secondary authentication mechanism after first carrying out 802.1X?