Hi Evgeniy,
The details of PPP CHAP authentication can be found in RFC 1994 as the authoritative document. In short, the actual challenge packet sent by one PPP peer to another consists of several fields, quoting the RFC 1994:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Code field identifies the type of the entire packet - whether it is a Challenge Packet or a Response Packet. The Identifier field is a counter that increments each time a Challenge is sent. When a router responds to a particular Challenge, it copies the value of the Identifier from the Challenge Packet over to the Response Packet. The Length indicates the entire packet's length. The Value-Size field identifies the size of the actual challenge (if the packet is a Challenge Packet) or the resulting MD5 hash value (if the packet is a Response Packet) that is itself carried in the Value field. Finally, the Name field advertises the hostname, or for that matter, the username of the device that is authenticating itself to the other party.
The computation of the MD5 hash sum is performed as follows, quoting the RFC 1994 again:
The Response Value is the one-way hash calculated over a stream of
octets consisting of the Identifier, followed by (concatenated
with) the "secret", followed by (concatenated with) the Challenge
Value. The length of the Response Value depends upon the hash
algorithm used (16 octets for MD5).
To restate this, the value is computed as MD5(Identifier+Secret+Challenge), with the + operator representing string concatenation.
From many source, i have read that both sides sends hash value.
I believe this is somewhat of a misunderstanding. With unidirectional CHAP authentication when R1 authenticates (that is, proves its identity) to R2, R2 sends a challenge and R1 responds with a hash of this challenge and other data as described above. So with unidirectional CHAP, only the party that authenticates itself to the other peer sends a hash.
Even with bidirectional CHAP when both parties authenticate to each other, the entire process is simply two overlapping unidirectional CHAP authentications occurring at the same time, each one in opposite direction, and there is no relation between them - the challenges and the hashes in each direction are independent. This is very important so I restate it once again: In mutual CHAP authentication like the one you have configured, two independent unidirectional CHAP authentications take place, each one using its own independent challenges.
Your configuration fails because you have not configured your routers with username commands that associate the neighboring router's hostname with the proper password. The ppp chap password command on the interface defines only a password that is used when sending a Response to a Challenge. However, when verifying whether the Response of a peer has been constructed using a proper password, the router looks into the username commands to associate the neighbor's hostname (carried in the Name field) with the password that should be used to compute the hash locally and compare it with the received hash from the neighbor. The password in the ppp chap password command is not used to verify the received Responses - for that, the password must be extracted from the username commands which you are missing.
I hope this helps but please feel welcome to ask further!
Best regards,
Peter
