CHAP
periodically verifies the identity of the client by using a three-way handshake.
This is done upon initial link establishment, and MAY be repeated anytime after
the link has been established.
CHAP life
cycle looks like following.
1. Once the
link is established between a node and authenticator (assume it like server),
authenticator sends a challenge message to the node.
2. Node
responds with a value calculated using a "one-way hash" function.
3. The
authenticator checks the response against its own calculation of the expected
hash value. If the values match, the
authentication is acknowledged; otherwise the connection SHOULD be terminated.
Note
This
authentication method depends upon a "secret" known only to the
authenticator and that Node. The secret
is not sent over the link. But both the Node and authenticator know it.
CHAP with Radius
1. Radius
client generates a random challenge and sends it to the user.
2. User
returns a CHAP response along with a CHAP ID and CHAP username.
3. Radius
client then sends an Access-Request packet to the RADIUS server with the CHAP
username as the User-Name and with the CHAP ID and CHAP response as the
CHAP-Password.
Note:
The random challenge can either be
included in the CHAP-Challenge attribute or, if it is 16 octets long, it can be
placed in the Request Authenticator field of the Access-Request packet. The NAS MAY include the Attributes
Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS
server that PPP service is expected.
4. The
RADIUS server looks up a password based on the User-Name, encrypts the challenge
using MD5 on the CHAP ID octet, that password, and the CHAP challenge (from the
CHAP-Challenge attribute if present, otherwise from the Request Authenticator),
and compares that result to the CHAP-Password.
If they match, the server sends back an Access-Accept, otherwise it
sends back an Access-Reject.
No comments:
Post a Comment