Authentication Protocols

ClearBox Server has built-in support for the following basic protocols (methods) used to authenticate users.

PAP

Under PAP (Password Authentication Protocol), the user (and change all other) negotiates with the NAS "in the clear." No encryption is used to send the password to the NAS.

NAS sends the password encrypted in RADIUS protocol using User-Password attribute, packet authenticator and shared secret.

On receiving access request, ClearBox Server has the password in clear text form and is able to make use of it for authentication.

CHAP

CHAP (Challenge Handshake Authentication Protocol) avoids sending passwords in clear text over any communication link.
Under CHAP, during password negotiations the NAS generates a "challenge" (a random string) and sends it to the user. The User's PPP client creates a "digest" (the password concatenated with the challenge), encrypts the digest using one-way MD5 encryption, and sends the digest to the NAS.

The NAS sends this digest as the password in the authentication request packet. Because the encryption is one-way, ClearBox Server cannot recover the password from the digest. What it can do is perform the identical digest operation using the NAS's challenge (provided in the request packet) and its own copy of the user's password. If the two digests match, the password is the same.

ClearBox Server must be able to perform the digest operation in order to support CHAP. Therefore, it must have access to its own copy of the user's password.

MS-CHAP and MS-CHAPv2

MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) is a Microsoft authentication protocol that, like CHAP, avoids sending passwords in clear text. ClearBox Server supports both 40-bit (version 1) and 128-bit (version 2) MS-CHAP methods.

ClearBox Server must be able to perform a digest operation similar to CHAP in order to support MS-CHAP. Therefore, it must have access to its own copy of the user's password.

An NT Domain controller provides MS-CHAP support, and will handle the digest operation itself once the server sends the username and password through; however, the user must be on the local domain for the password to be recognized.

ARAP

ARAP (Apple Remote Access Protocol) is an Apple authentication protocol which uses challenges and responses, like CHAP, to avoid sending clear text passwords through the network. Under ARAP, the NAS sends two random numbers to the dial-in client which should be DES encrypted with the user's password. Then the dial-in client sends this result, the user's name and two random numbers of its own back to the NAS. The NAS verifies the encrypted random numbers sent by the dial-in client. If they are right, it encrypts the dial-in client's challenge using the password and sends it back to the dial-in client.

The NAS sends his challenge, User's response and his challenge in authentication request packet. ClearBox Server must perform the identical encryption operation using the challenge of the NAS, User's response and challenge (provided in the request packet) and its own copy of the user's password. If the two digests match, the password is the same.

ClearBox Server must be able to perform the encryption operation in order to support ARAP. Therefore, it must have access to its own copy of the User's password.

SIP-Digest

Digest authentication scheme (RFC2617 [1]) is widely used in protocols such as SIP (RFC2543 [2]) and HTTP (RFC2616 [3]). Digest authentication was adapted to be performed by a RADIUS server.

An HTTP client sends to SIP/HTTP server an HTTP/SIP request with an authorization header. The SIP/HTTP server sends a RADIUS server Access-Request with special set of attributes (nonce, realm, URI, QOP, etc.). The RADIUS server calculates a digest with these values and responds to the SIP/HTTP server with a RADIUS Access-Accept/Access-Reject response. If credentials were accepted, the SIP/HTTP server receives an Access-Accept response, and the message sent from the HTTP client is considered authentic.

EAP

The Extensible Authentication Protocol (EAP), described in RFC 2284, provides a standard mechanism for support of additional
authentication protocols within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others.

The RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the RADIUS server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message attribute. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code, which can instead reside on the backend security server.

EAP-MD5

This protocol is similar to CHAP described above except for that is encapsulated in EAP packets transmitted by NAS between authenticated peer (client) and RADIUS server. First, RADIUS server receives EAP/Identity response from a peer. Then RADIUS server issues a challenge in EAP/MD5 Challenge request. Client generates a response from the challenge and his password and replies with EAP/MD5 Response. RADIUS server generates a MD5 hash using its copy of user password and the challenge. If they its hash and user response are identical, server issues EAP/Success packet, EAP/Failure otherwise.

ClearBox Server must be able to perform the digest operation in order to support EAP MD5. Therefore, it must have access to its own copy of the user's password.

EAP-TLS

EAP-TLS is an authentication protocol that encapsulates a TLS connection inside EAP. This provides cryptographically secure mutual authentication for both clients and servers. With EAP-TLS, the identities of both the client and the server are established using digital certificates.

EAP-TLS can work in standalone mode, or be tunneled inside of PEAP. The disadvantage to using EAP-TLS in standalone mode is that the client's certificate is visible to eavesdroppers, which allows adversaries to see the names of your network users. When tunneled inside of PEAP, users' identities are protected. The disadvantage to tunneled EAP-TLS is that the server must perform two full TLS handshakes per authentication, which is costly in terms of server performance.

EAP-TLS requires each user to have her own digital certificate. This in turn leads to the need for a Public Key Infrastructure (PKI). Since the requirements of maintaining a PKI are substantial, most organizations opt instead to use PEAP, which require a digital certificate for the server only.

PEAP

Protected Extensible Authentication Protocol (PEAP) is a protocol developed by Microsoft and Cisco as a means to allow clients to login to Wi-Fi networks using a username and password while keeping these login credentials protected with the use of encryption. It does not require that each user be issued a certificate. Instead, only the RADIUS authentication servers are issued certificates.

A client wishing to connect to the Wi-Fi network first establishes a connection to the selected access point. The access point forwards the connection request to a RADIUS server, which establishes a TLS connection between itself and the client. This TLS channel keeps all communications between the RADIUS server and the client encrypted, preventing eavesdroppers from examining data passed between the two hosts, which includes sensitive information such as passwords.

The TLS connection proves the identity of the server. During the establishment of the TLS connections, the RADIUS server sends its digital certificate, which the client may use to validate the server's identity. After the TLS connection is established, the client proves its identity to the RADIUS server by sending a username and password, or by sending its own digital certificate. This portion of the PEAP protocol happens inside the TLS channel, and is known as the inner identity phase. The inner identity phase can occur using one of several different protocols: EAP-MS-CHAP-V2, EAP-TLS, etc.