Authenticating protocols provide a mechanism to the partnering systems to share secret information while reducing the opportunity for unauthorized individuals to participate in the negotiation process. Passwords can be the Achilles’ heel of security procedures.
Without authentication protocols to protect the process of interchanging secret data, the secret can be discovered and utilized for illegal or unethical activities.
Authentication protocols of the type discussed here originated from a requirement set forth by the communication standard Point-to-Point Protocol (PPP). PPP provides a standard method of encapsulating network layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), allowing nego-tiation of an authentication protocol for identifying its peer prior to network layer protocol transmission.
The PPP communication standard has three main components:
1. method for encapsulating datagrams
2. LCP for establishing, configuring, and testing the connection
3. Network Control Protocols (NCPs) for establishing and configuring different network layer protocols
To establish communications over a point-to-point link, the two systems must first send LCP packets to configure the data link. After the link has been established, PPP provides for an optional authentication phase before proceeding to the network layer protocol phase. By default, authentication is not mandatory.
The concept of setting up the connection with a remote system based on its attributes, and then allowing an authentication protocol to determine the user prior to allowing data to flow, is being considered by some in the IPSRA.
Password Authentication Protocol (PAP). The least effective authentication pro-tocol is Password Authentication Propro-tocol (PAP). PAP negotiates all data as cleartext without hashing or encryption to conceal or protect the secret information being shared. In essence, if someone were to intercept the communication at the time of authentication, the username or identifier and password would be clearly readable and identifiable.
Challenge Handshake Authentication Protocol (CHAP). The Challenge Hand-shake Authentication Protocol (CHAP) is used to systematically verify the identity of a remote user by means of a three-way handshake (see Exhibit 6-1). The handshake provides a layered authentication process that is difficult to repeat due, in part, to the authenticator sending a new challenge at random intervals. An example of a common application of CHAP is for use during authentication for a dial-in user. ISPs providing connectivity to the Internet require the remote user to authenticate to appropriately provide the desired access and bill accordingly. Typically, the user dials a phone number that allows his or her modem to establish a PPP session with a modem hosted by an ISP. The modems at an ISP can simply exist as a bank, or collection of modems tied to a router that provides access to the Internet. Once the PPP is established, a CHAP session can be initialized to request the username and password from the remote user.
The information gathered under the protection of CHAP can be verified against an authentication database, such as a RADIUS system.
As shown in Exhibit 6-1, the authenticating device (or authenticator) sends a “chal-lenge” to the system that wants to connect (a remote user). The challenge is a random value that is typically never repeated by the authenticator. The peer responds with a hashed result that the authenticator compares against its own calculated expected result.
If the two results match, the connection is authenticated and data is forwarded based on the access control applied to that user or group. The authenticator sends a new challenge at random to the peer and repeats the authentication process from the beginning. In most implementations, the user is not prompted for a username and password every time the authenticator sends a CHAP challenge. Instead, the cache of the peer system provides the information.
The authenticator’s challenge is a request for a username and password, and a randomly generated number that can be up to 16 bytes in length. The peer receives the challenge and generates a response value that is a hash calculated over a stream of bytes consisting of the challenge packet identifier, the secret, and the challenge.
When the authenticator receives the response that contains the hash and the username, it retrieves the password from its database and hashes the same values and compares Exhibit 6-1. Description of CHAP authentication.
Remote User:
the results. If the two hashes are identical, the corresponding known values (ID, secret, and challenge) are validated.
One advantage of CHAP is that it can provide protection against playback attack by an unauthorized system by the use of an incrementally changing packet identifier and a variable challenge value. To add further protection, the random challenges reduce the time the process is exposed to an attack. A disadvantage of CHAP is that it requires the secret be available in clear text in the database of the extended authentication system.
If the system is compromised, all the secret data contained within the system will be available.
RADIUS. The Remote Authentication Dial-in User Service (RADIUS) was specifically designed to manage dispersed serial line and modem pools for large numbers of users.
This relates to the origination of the PPP communication standard, in that common authentication systems provided authentication but did not address certain variables associated with remote access service. RADIUS has provided information critical to establishing communications and has become an intermediary for several types of authentication methods. RADIUS has support for the authentication protocols defined earlier, and it is utilized in many scenarios for extended authentication into larger databases.
One of the key features of RADIUS is the implementation of the client/server model. A network access system, such as a VPN device or router, operates as a client of RADIUS. The client is responsible for passing remote user information to its associated RADIUS server and acting accordingly, depending on the RADIUS server’s response.
Another feature of RADIUS that sets it apart from other common authentication systems is its support for configuration information provisioning. During the time RADIUS was being developed, remote access was limited to serial lines and modems.
RADIUS was developed to provide authentication and configuration information dependent on the user rights, times of the day, and access port, among other config-urable attributes.
RADIUS servers receive the user connection requests, authenticate the user, and then return all configuration information necessary for the client to deliver service to the remote user. The relationship between the RADIUS server and client is estab-lished by the use of a shared secret, and all data communications are encrypted. That shared secret is typically a password that is entered by an administrator on the client and RADIUS server, and is subsequently used to establish trust and keying material for encryption purposes.
X.500 and LDAP. Extensibility of authentication processes is the key to obtaining a desired path to match the growth of technology. The capability to provide support for future technology requirements is paramount. Lightweight Directory Access Protocol (LDAP) is a protocol that provides the access to directories of user information, such as NDS and AD.
LDAP is an access protocol that allows reading and updating of X.500-compliant directory information. A directory maintains a hierarchical organized set of objects that can be arranged to best accommodate organizational needs. These needs include wide area network (WAN) considerations, organizational structure, application structure, and
security policies. Within X.500 directories are layers of objects called containers, which essentially contain leaf objects that can represent servers, users, routers, or any object that warrants inclusion in the directory.
Each object can have scores of information associated with it. To further accentuate the relationship to VPNs, user objects can have remote access-specific information associated with them, which can allow an authentication process to include connection requirement data. Examples include keying material, IP allocation data, access control policies, routing information, and Internet service identification.
LDAP can be used to obtain detailed amounts of configuration-specific data to allow VPN implementations to reduce the complexity of the client. The client needs only enough information to get to the VPN gateway. After the gateway receives the request, LDAP is used to access a directory of information to push the approved and required configuration to the client.