All about PPP, PAP and CHAP
Objective:
Router London and Router Newyark connected by a serial link. PPP is running on this link. How to configure CHAP on the interface at London End.
London# config t
London(config)# interface s0
London(config-if)# encapsulation ppp
London(config-if)#ppp authentication chap (or) ppp authentication chap callin
London(config-if)#ppp chap hostname Newyark (the otherend host name)
London(config-if)#ppp chap password clinton(common for both routers
++++++++++++++++++++++++++++++++++++++++
Is it possible to turn off the authenticaion on PPP?
Yes. By default it is off. If you WANT authentication, then only you have to configure it.
++++++++++++++++++++++++++++++++++++++++
Which router will initiate the authentication process?
The called party will initiate the three-way-handshake authentication
+++++++++++++++++++++++++++++++++++++++++++++
What is"ppp authentication chap callin" ?
When a user tries to contact the isp, only the isp should worry whether the caller is a genuine person. The user need not worry about whether that isp is a genuine person. But there can be situations where both ends are important persons. In that case, first the CALLING party does the three-way-handshake and after that, the CALLED party also starts a three-way-handshake.
For one-way authentication, the command is
London(config-if)#ppp authentication chap callin
For two-way authentication, the command is
London(config-if)#ppp authentication chap
+++++++++++++++++++++++++++++++++++++++
How the challenge packet will look like?
Packet type: 01 (01 means challenge, 02 means response,03 means auth success, 04 means auth failed.)
my hostname: London-3605
random number : 856
id : 5 (sequence number which identifies the challenge)
The above information is sent to the other router which is the calling party.
At the calling end >>>
the router checks its table, picks the password for the user id London-3605.
Puts this password, id and random number into the md5 machine and gets the hash value. Note: MD5 is a one-way hash function.
The response packet is sent by the calling party to the authenticator. This response packet will look like this:
Packet type: 02 (01 means challenge, 02 means response)
my hostname: Newyark-3605
Output Hash value: 3456
id which i received from authenticator:5
+++++++++++++++++++++++++++++++++++++
In the above case, what is the importance of id field.
Before sending the challenge packet, the authenticator will store the random number and other details in a table. The record number of this entry is the ID. When the response is received by the authenticator, in the response packet, id is also available. With that id, it will pick up the correct record.Then verify whether the response is correct or not.
++++++++++++++++++++++++++++++++++++++++++
If the authenticator is satified then what he will do?
If authentication is successful, then the authentication sends a welcome message (packet type:3) or Failure message (packet type 4).
so now you know why it is called as three way handshake
+++++++++++++++++++++++++++++++++++++++++++++
Once CHAP authentication is successful, what happens next?
Now chap opens the door to the concerned NCP. For IP, the NCP is IPCP.IPCP asks about compression techniques, whether ip address is to be assigned, whether dns to be informed.. Then NCP opens the gate of IP.
++++++++++++++++++++++++++++++++++
To further understand the concept of PPP, put on the debug command:
debug ppp negotiation
The command displays all the activities happending during ppp nogotation. But to understand this output, the following knowledge is needed:
When debug commands are displayed, if you want to display the timestamp, then give the follownig command:
Router(config)# service timestamp debug datetime msec
++++++++++++++++++++++++++++++++++++++++++
BR0:1 PPP: Phase is DOWN >>> The physical link is NOT ON.
BR0:1 PPP: Phase is ESTABLISHING >> Link is OK and now PPP is listening
BR0:1 PPP: Phase is AUTHENTICATING >>>PPP or CHAP is also in ready position.
BR0:1 PPP: Phase is UP >>> Authentication is successful. Now traffic can go to NCP.
++++++++++++++++++++++++++++++++++++
LCP configuration negotation:
Router A knows PAP and CHAP.
It asks B "Shall we talk in PAP,My magic number is 845"
B says "Sorry, I know only CHAP,my magic number is 355"
A aks again "Shall we talk in CHAP"
B says "OK"
A says "Thank you"
This much of work is done at LCP. Now LCP is satisfied and open the connection.
+++++++++++++++++++++++++++++++++++++++++++++++++++++
A sample ppp negotation ouput from cisco.com is given here:
maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar 1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to
up
!--- The Physical Layer (BRI Interface) is up.
Only now can PPP
!--- negotiation begin.
*Mar 1 00:06:36.661: BR0:1 PPP: Treating connection
as a callin
*Mar 1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open
[0 sess, 0 load]
!--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.
*Mar 1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar 1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17
!--- This is the incoming CONFREQ. The ID field is 7.
*Mar 1 00:06:37.038: BR0:1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 00:06:37.042: BR0:1 LCP: MagicNumber 0x507A214D (0x0506507A214D)
*Mar 1 00:06:37.046: BR0:1 LCP: Callback 0 (0x0D0300)
!--- The peer has requested:
!--- Option: Authentication Protocol, Value: PAP
!--- Option: MagicNumber (This is used to detect loopbacks and is always
sent.)
!--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback
uses 6.)
*Mar 1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15
!--- This is an outgoing CONFREQ, with parameters
for the peer to implement.
!--- Note that the ID Field is 4, so this is not related to the previous
!--- CONFREQ message.
*Mar 1 00:06:37.058: BR0:1 LCP: AuthProto CHAP
(0x0305C22305)
*Mar 1 00:06:37.062: BR0:1 LCP: MagicNumber 0x1081E7E1 (0x05061081E7E1)
!--- This router requests:
!--- Option: Authentication Protocol, Value: CHAP
!--- Option: MagicNumber (This is used to detect loopbacks and is always
sent.)
*Mar 1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7
!--- This is an outgoing CONFREJ for message with
Field ID 7.
!--- This is the response to the CONFREQ received first.
*Mar 1 00:06:37.070: BR0:1 LCP: Callback 0 (0x0D0300)
!--- The option that this router rejects is Callback.
!--- If the router wanted to do MS Callback rather than PPP Callback,
it
!--- would have sent a CONFNAK message instead.
*Mar 1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15
!--- This is an incoming CONFACK for a message with Field ID 4.
*Mar 1 00:06:37.102: BR0:1 LCP: AuthProto CHAP
(0x0305C22305)
*Mar 1 00:06:37.106: BR0:1 LCP: MagicNumber 0x1081E7E1 (0x05061081E7E1)
!--- The peer can support all requested parameters.
*Mar 1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14
!--- This is an incoming CONFREQ message; the ID
field is 8.
!--- This is a new CONFREQ message from the peer in response to the CONFREJ
id:7.
*Mar 1 00:06:37.117: BR0:1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 00:06:37.121: BR0:1 LCP: MagicNumber 0x507A214D (0x0506507A214D)
!--- The peer has requested:
!--- Option: Authentication Protocol, Value: PAP
!--- Option: MagicNumber (This is used to detect loopbacks and is always
sent.)
*Mar 1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9
!--- This is an outgoing CONFNACK for a message with Field ID 8.
*Mar 1 00:06:37.129: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
!--- This router recognizes the option Authentication
Protocol,
!--- but does not accept the value PAP. In the CONFNAK message,
!--- it suggests CHAP instead.
*Mar 1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15
!--- This is an incoming CONFREQ message with Field ID 9.
*Mar 1 00:06:37.169: BR0:1 LCP: AuthProto CHAP
(0x0305C22305)
*Mar 1 00:06:37.173: BR0:1 LCP: MagicNumber 0x507A214D (0x0506507A214D)
!--- CHAP authentication is requested.
*Mar 1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15
!--- This is an outgoing CONFACK for a message with Field ID 9.
*Mar 1 00:06:37.181: BR0:1 LCP: AuthProto CHAP
(0x0305C22305)
*Mar 1 00:06:37.185: BR0:1 LCP: MagicNumber 0x507A214D (0x0506507A214D)
*Mar 1 00:06:37.189: BR0:1 LCP: State is Open
!--- This indicates that the LCP state is Open.
*Mar 1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]
!--- The PPP Phase is AUTHENTICATING. PPP Authentication
occurs now.
!--- Two-way authentication is now performed (indicated by the both keyword).
*Mar 1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"
!--- This is the outgoing CHAP Challenge.
!--- In LCP the routers had agreed upon CHAP as the authentication protocol.
*Mar 1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"
!--- This is an incoming Challenge message from the peer.
*Mar 1 00:06:37.229: BR0:1 CHAP: Waiting for peer
to authenticate first
*Mar 1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"
!--- This is an incoming response from the peer.
*Mar 1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4
!--- This router has successfully authenticated the peer.
*Mar 1 00:06:37.248: BR0:1 CHAP: Processing saved
Challenge, id 3
*Mar 1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar 1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4
!--- This is an incoming Success message. Each
side has
!--- successfully authenticated the other.
*Mar 1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]
!--- The PPP status is now UP. NCP (IPCP) negotiation begins.
*Mar 1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed]
id 4 len 10
*Mar 1 00:06:37.308: BR0:1 IPCP: Address 172.22.1.1 (0x0306AC160101)
!--- This is an outgoing CONFREQ message. It indicates
that
!--- the local machine address is 172.22.1.1.
*Mar 1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed]
id 4 len 4
*Mar 1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar 1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4
!--- These messages are for CDP Control Protocol (CDPCP).
*Mar 1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent]
id 4 len 10
*Mar 1 00:06:37.336: BR0:1 IPCP: Address 172.22.1.2 (0x0306AC160102)
!--- This is an incoming CONFREQ message that indicates
that the peer
!--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer
!--- does not have an address and requests the local router to provide
it
!--- with an address in IPCP negotiation.
*Mar 1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent]
id 4 len 10
*Mar 1 00:06:37.348: BR0:1 IPCP: Address 172.22.1.2 (0x0306AC160102)
*Mar 1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar 1 00:06:37.360: BR0:1 IPCP: Address 172.22.1.1 (0x0306AC160101)
*Mar 1 00:06:37.363: BR0:1 IPCP: State is Open
!--- The IPCP state is Open. Note that in the IPCP
negotiation, each side
!--- accepted the IP address of the peer, and one was assigned to the
peer.
*Mar 1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent]
id 4 len 4
*Mar 1 00:06:37.375: BR0:1 CDPCP: State is Open
!--- This indicates that the CDPCP state is Open.
*Mar 1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2
!--- A route to the peer is installed.
*Mar 1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line
protocol on Interface BRI0:1,
changed state to up
*Mar 1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected
to
maui-soho-03
No comments:
Post a Comment