Which of the following authentication protocols is the most widely used today?

EAP-MD5 CHAP

EAP-MD5 CHAP is an implementation of the same challenge-response system as MS-CHAP within the EAP infrastructure. It supports the same level of security as MS-CHAP v2, but clients must support EAP in order to authenticate with this protocol. Clients that support MS-CHAP but not EAP will require the non-EAP version of this protocol.

EAP-TLS

Transport Level Security (TLS) is an authentication protocol that uses public-key encryption. All messages between the client and server are securely encrypted. The encryption is similar to that used with the Internet Secure Sockets Layer (SSL) protocol. This is the highest level of security provided by Windows Server 2003’s authentication methods.

TEST DAY TIP

EAP-TLS also supports smart cards. These are hardware devices that implement public-key encryption. Smart cards answer challenges within the hardware and do not transmit the private key, so they provide higher security than simple password authentication. For more information about smart card authentication, see Chapter 7.

EAP-RADIUS

EAP-RADIUS is not a true authentication method. This option is an interface between EAP and RADIUS. When you select EAP-RADIUS, you specify an external RADIUS server, and all requests for authentication are forwarded to the RADIUS server for processing. This provides a way for clients that only support EAP to be authenticated using the RADIUS server.

14.8.1 General

The Extensible Authentication Protocol (EAP) is a protocol framework for performing authentication, typically between a UE and a network. It was first introduced in IETF for the Point-to-Point Protocol (PPP) in order to allow additional authentication methods to be used over PPP. Since then it has also been introduced in many other scenarios, for example as an authentication protocol for IKEv2, as well as for authentication in Wireless LANs using the IEEE 802.11i and 802.1x extensions.

EAP is extensible in the sense that it supports multiple authentication protocols and allows for new authentication protocols to be defined within the EAP framework. EAP is not an authentication method in itself, but rather a common authentication framework that can be used to implement specific authentication methods. These authentication methods are typically referred to as EAP methods.

The base EAP protocol is specified in IETF RFC 3748. It describes the EAP packet format as well as basic functions such as the negotiation of the desired authentication mechanism. It also specifies a few simple authentication methods, for example based on one-time passwords as well as a challenge-response authentication. It is possible to define additional EAP methods in addition to the EAP methods defined in IETF RFC 3748. Such EAP methods may implement other authentication mechanisms and/or utilize other credentials such as public key certificates or (U)SIM cards. A few of the EAP methods standardized by IETF are briefly described below:

EAP-TLS is based on TLS and defines an EAP method for authentication and key derivation based on public key certificates. EAP-TLS is specified in IETF RFC 5216.

EAP-AKA is defined for authentication and key derivation using the UMTS SIM card and is based on the UMTS AKA procedure. EAP-AKA is specified in IETF RFC 4187.

EAP-AKA′ is a small revision of EAP-AKA that provides for improved key separation between keys generated for different access networks. EAP-AKA′ is defined in IETF RFC 5448.

In addition to the standardized methods, there are also proprietary EAP methods that have been deployed, e.g., in corporate WLAN networks.

As further described in Chapter 8, 5GS makes extensive use of EAP-AKA′ for authentication over both 3GPP accesses and non-3GPP accesses.

Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)

MS-CHAP authentication is another form of authentication that does not transmit the actual password over the link. MS-CHAP is Microsoft’s implementation of CHAP, with a few improvements. For example, MS-CHAP has provisions built into the protocol to allow the remote access server to store passwords in a hashed format, instead of in the typical clear-text password store that is used by CHAP.

Initially, the remote access server sends a challenge to the client in the same fashion as CHAP. In return, the remote client must reply with the username, the challenge string in an encrypted form, an MD4 hash of the password, and the session identifier. In addition to the ability to store the password on the remote access server in a hashed format, MS-CHAP authentication provides a larger set of error codes than does CHAP, and provides capabilities for remote users to change their passwords during the authentication process. MS-CHAP also provides for Microsoft Point-to-Point Encryption (MPPE), an encryption technique based on the RSA/RC4 algorithm.

The original version of MS-CHAP is referred to as version 1. It has been largely replaced by MS-CHAPv2, discussed in the next section. If you are using pre-Windows 95 clients for remote access connectivity, if you are using Windows 95 for dial-up remote access, or if you are using certain non-Microsoft clients, you may have to use MS-CHAP version 1 for authentication.

CHAP and MS-CHAP

CHAP was defined in RFC1994: PPP Challenge Handshake Authentication Protocol. CHAP (Challenge-Handshake Authentication Protocol) was initially used to verify client identity on PPP links using a three-way handshake. The handshake begins with the authenticator issuing a challenge to the client. The client responds with a digest calculated using a hashing function. The authenticator then verifies the response and acknowledges the connection if the match is successful, otherwise it terminates the connection. CHAP depends upon a secret known only to the authenticator and the client. The secret is not sent over the link.

MS-CHAP differs from CHAP in that MS-CHAP does not require that the shared secret be stored in cleartext at both ends of the link. The Microsoft client knows the hash method used by the server so it can reproduce it, effectively creating a “matching” password on both ends. The client proves its identity based on the fact that it can reproduce the hashed value of the password.

Password Authentication Protocol and Challenge Handshake Authentication Protocol

■

PAP PAP was used to authenticate users using usernames and passwords. PAP uses a two-way handshake and transmits the username and password in American Standard Code for Information Interchange (ASCII) without any encryption. PAP was replaced by CHAP to provide moresecurity.

CHAP CHAP is a remote access authentication protocol used in conjunction with PPP to provide security and authentication to users of remote resources. CHAP is used to periodically verify the identity of the peer using a three-way handshake. This is done upon initial link establishment and may be repeated anytime after the link has been established.

Using EAP

EAP (Extensible Authentication Protocol) is not itself an authentication protocol, but provides a framework that enables authentication using a variety of different methods, known as EAP types. The following are the EAP types supported by Windows Server 2003:

EAP-MD5 A challenge-response protocol similar to CHAP. This method uses reversible encryption to store passwords, and is thus vulnerable to the same security problems as CHAP.

EAP-TLS (Transport Level Security) A high-security protocol based on the SSL (Secure Sockets Layer) system used for Web server security. EAP-TLS uses encrypted certificates for authentication. It also supports mutual authentication, similar to MS-CHAP v2. This is considered the most secure authentication protocol supported by Windows Server 2003.

Test Day Tip

EAP-TLS is the most secure authentication method, but is not supported by all clients. Only Windows 2000, Windows XP, and Windows Server 2003 clients support this authentication method.

Per-Packet Authentication

EAP can support per-packet authentication and integrity protection, but this authentication and integrity protection is not extended to all types of EAP messages. For example, NAK (negative acknowledgment) and notification messages are not able to use per-packet authentication and integrity. Per-packet authentication and integrity protection works for the following (packet is encrypted unless otherwise noted):

TLS and IKE derive session key

TLS ciphersuite negotiations (not encrypted)

IKE ciphersuite negotiations

Kerberos tickets

Success and failure messages that use derived session key (through WEP)

Designing & Planning…

Authentication protocols and frameworks

An authentication protocol authenticates an identity claim over the network. Good security design assumes that a network eavesdropper may sniff all packets sent between a client and an authentication server: The protocol should remain secure. As we will see shortly, PAP fails this test, but CHAP and EAP pass.

Data Integrity Field (DIF)

DIF provides a standard data-checking mechanism to monitor the integrity of data. DIF sends a block of information with integrity checks to an HBA. The HBA validates the data and sends the data block with its integrity check across the Fibre Channel fabric to the storage array. The storage array in turn validates the metadata and writes the data to Redundant Array of Independent Disks (RAID) memory. The array then sends the block of data to the disk, which validates the information before writing it to disk. DIF pinpoints where in the process of writing data to disk that the corruption occurred.