PPP Encapsulation and Configured PPP With Authentication

PPP Encapsulation and Authentication Process
An incoming PPP request requires no authentication, then PPP progresses to the next level. If an incoming PPP request requires authentication, then it can be authenticated using either the local database or a security server. As illustrated in the flowchart, successful authentication progresses to the next level, while an authentication failure will disconnect and drop the incoming PPP request.
f the authentication failed, a CHAP failure packet is built from the following components:
04 = CHAP failure message type
id = copied from the response packet
"Authentication failure" or some such text message, which is meant to be a user-readable explanation
The ppp authentication Command
To specify the order in which the CHAP or PAP protocols are requested on the interface, use the ppp authentication interface configuration command, as shown in the figure. Use the no form of the command to disable this authentication.
After you have enabled CHAP or PAP authentication, or both, the local router requires the remote device to prove its identity before allowing data traffic to flow. This is done as follows:
PAP authentication requires the remote device to send a name and password to be checked against a matching entry in the local username database or in the remote TACACS/TACACS+ database.
CHAP authentication sends a challenge to the remote device. The remote device must encrypt the challenge value with a shared secret and return the encrypted value and its name to the local router in a response message. The local router uses the name of the remote device to look up the appropriate secret in the local username or remote TACACS/TACACS+ database. It uses the looked-up secret to encrypt the original challenge and verify that the encrypted values match.
Note: AAA/TACACS is a dedicated server used to authenticate users. AAA stands for "authentication, authorization and accounting". TACACS clients send a query to a TACACS authentication server. The server can authenticate the user, authorize what the user can do and track what the user has done.
You may enable PAP or CHAP or both. If both methods are enabled, the first method specified is requested during link negotiation. If the peer suggests using the second method or simply refuses the first method, the second method is tried. Some remote devices support CHAP only and some PAP only. The order in which you specify the methods is based on your concerns about the ability of the remote device to correctly negotiate the appropriate method as well as your concern about data line security. PAP usernames and passwords are sent as clear-text strings and can be intercepted and reused. CHAP has eliminated most of the known security holes.
Configuring PPP Authentication
The procedure outlined in the table describes how to configure PPP encapsulation and PAP/CHAP authentication protocols. Correct configuration is essential, because PAP and CHAP use these parameters to authenticate.
The figure is an example of a two-way PAP authentication configuration. Both routers authenticate and are authenticated, so the PAP authentication commands mirror each other. The PAP username and password that each router sends must match those specified with the username name password password command of the other router.
PAP provides a simple method for a remote node to establish its identity using a two-way handshake. This is done only on initial link establishment. The hostname on one router must match the username the other router has configured. The passwords must also match.
CHAP periodically verifies the identity of the remote node using a three-way handshake. The hostname on one router must match the username the other router has configured. The passwords must also match. This occurs on initial link establishment and can be repeated any time after the link has been established. The figure is an example of a CHAP configuration.
Troubleshooting a PPP Configuration with Authentication
Authentication is a feature that needs to be implemented correctly or the security of your serial connection may be compromised. Always verify your configuration with the show interfaces serial command, in the same way as you did without authentication.
Never assume your authentication configuration works without testing it. Debugging allows you to confirm your configuration and correct any deficiencies. The command for debugging PPP authentication is debug ppp authentication.
In the last line, the code = 4 means a failure has occurred. Other code values are as follows:
1 = Challenge
2 = Response
3 = Success
4 = Failure
id = 3 is the ID number per LCP packet format.
len = 48 is the packet length without the header.


Post a Comment


NBA Live Streaming. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com | Distributed by Blogger Templates Blog