The flowchart in Figure 1 can be used to help understand the PPP authentication process when configuring PPP. The flowchart provides a visual example of the logic decisions made by PPP.
For example, if 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 disconnects and drops the incoming PPP request.
Follow the steps as the animation progresses in Figure 2 to view R1 establishing an authenticated PPP CHAP connection with R2.
Step 1. R1 initially negotiates the link connection using LCP with router R2 and the two systems agree to use CHAP authentication during the PPP LCP negotiation.
Step 2. R2 generates an ID and a random number, and sends that and its username as a CHAP challenge packet to R1.
Step 3. R1 uses the username of the challenger (R2) and cross references it with its local database to find its associated password. R1 then generates a unique MD5 hash number using the R2's username, ID, random number and the shared secret password. In this example, the shared secret password is boardwalk.
Step 4. Router R1 then sends the challenge ID, the hashed value, and its username (R1) to R2.
Step 5. R2 generates its own hash value using the ID, the shared secret password, and the random number it originally sent to R1.
Step 6. R2 compares its hash value with the hash value sent by R1. If the values are the same, R2 sends a link established response to R1.
If 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 similar text message, which is meant to be a user-readable explanation
The shared secret password must be identical on R1 and R2.