Controller Based WLANs

Product and Software: This article applies to all Aruba controllers and APs that run ArubaOS 2.5 and later.

One option in the captive portal authentication profile (aaa authentication captive-portal <profile name>) allows CHAP to be used for authentication with a backend server (such as RADIUS).

However, this implementation uses non-standard CHAP and is proprietary to one specific customer. Do not enable this option unless the backend infrastructure supports this mechanism.

This article explains why CHAP should not be used as the authentication method with Aruba captive portal against a standard RADIUS server.

Challenge Handshake Authentication Protocol (CHAP) is a type of authentication in which the authentication agent (typically a network server) sends the client program a random value that is used only once and an ID value. The sender and peer share a predefined secret. The peer concatenates the random value (or nonce), the ID and the secret and calculates a one-way hash using MD5. The hash value is sent to the authenticator, which in turn builds that same string on its side, calculates the MD5 sum itself and compares the result with the value received from the peer. If the values match, the peer is authenticated.

However, this proprietary implementation actually uses the MD5 hash of the user-supplied password (they call this CHAP-based) but send to the Radius as "PAP". That is, the username + MD5 hash of password. This is why you see the "non-standard" wording here. For real CHAP, the login page issues a "challenge" and then the browser returns a CHAP response that is NOT quite defined for HTML authentication.

Also, we just do not do "proxy CHAP" with captive portal. That is, we do not internally generate a challenge and calculate the response from the received cleartext password (protected by the HTTPS). At the end, the end-to-end protection of the password is not improved.