PPP authentication

I have been listening to the AT CoD and then working through the corresponding section in vol 1.  I wanted to see the serial link transition up and down while putting in the various commands for section 1.48.  I assigned the encapsulation and IP addresses for R4 & R5.  Verified conectivity good.  To the R4 serial interface added "ppp authentication pap chap" & "ppp chap hostname R4CHAP".  The protocol went down as expected. Added "username R5CHAP password 0 CISCO".To the R5 serial interdface added commands "ppp pap refuse" & "ppp chap hostname R5CHAP".  Exited interface and entered "username R4CHAP password 0 CISCO".  To my surprise, the lie protocol came up.  I must be missing something.  How did this link get authenticated? Neither side of the link has been told what to send for a password, only what to expect the password to be.  Again, what am I missing?  Thanks.

Configuration recap:

R4#sh run int s0/0/1
Building configuration...

Current configuration : 140 bytes
!
interface Serial0/0/1
 ip address 155.1.45.4 255.255.255.0
 encapsulation ppp
 ppp authentication pap chap
 ppp chap hostname R4CHAP
end

R4#sh run | i usern
username R5CHAP password 0 CISCO

R5#sh run int s0/1/0
Building configuration...

Current configuration : 145 bytes
!
interface Serial0/1/0
 ip address 155.1.45.5 255.255.255.0
 encapsulation ppp
 clock rate 64000
 ppp chap hostname R5CHAP
 ppp pap refuse
end

R5#sh run | i user 
username R4CHAP password 0 CISCO

Comments

  • The "send password" concept is a PAP command set requirement. 

    CHAP uses a shared secret approach - a hash value of the username and password-based shared secret is sent across the wire. This shared secret value must match on each device (which you have done). 

    On Mar 29, 2010, at 12:32 PM, dunhamdd wrote:

    I have been listening to the AT CoD and then working through the corresponding section in vol 1.  I wanted to see the serial link transition up and down while putting in the various commands for section 1.48.  I assigned the encapsulation and IP addresses for R4 & R5.  Verified conectivity good.  To the R4 serial interface added "ppp authentication pap chap" & "ppp chap hostname R4CHAP".  The protocol went down as expected. Added "username R5CHAP password 0 CISCO".To the R5 serial interdface added commands "ppp pap refuse" & "ppp chap hostname R5CHAP".  Exited interface and entered "username R4CHAP password 0 CISCO".  To my surprise, the lie protocol came up.  I must be missing something.  How did this link get authenticated? Neither side of the link has been told what to send for a password, only what to expect the password to be.  Again, what am I missing?  Thanks.

    Configuration recap:

    R4#sh run int s0/0/1
    Building configuration...

    Current configuration : 140 bytes
    !
    interface Serial0/0/1
     ip address 155.1.45.4 255.255.255.0
     encapsulation ppp
     ppp authentication pap chap
     ppp chap hostname R4CHAP
    end

    R4#sh run | i usern
    username R5CHAP password 0 CISCO

    R5#sh run int s0/1/0
    Building configuration...

    Current configuration : 145 bytes
    !
    interface Serial0/1/0
     ip address 155.1.45.5 255.255.255.0
     encapsulation ppp
     clock rate 64000
     ppp chap hostname R5CHAP
     ppp pap refuse
    end

    R5#sh run | i user  
    username R4CHAP password 0 CISCO




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • I think I understand.  If I had put "CISCO123" on either side on the username command, the line protocol would not have come up.  Correct?

  • Exactly David! Good job.

    As Anthony stated above - the shared secret must match exactly on each device, and it is never sent over the wire in order to attempt to eliminate "man in the middle" attacks. 

  • One of the instructors (Anthony, I think) stated a general rule to "never break the network" even for a short period of time.  I learned this rule the hard way one time with configuring Etherchannel "on-the-fly" into a server farm. [:$]  Glad I didn't do it this time, otherwise I would have missed an important concept.  I really appreciate the feedback.

  • Yeah that's Anthony's mantra!

    There's good reason for it, as you just realized.


    Glad We Could Help.

    --The TechEdit Team

     

Sign In or Register to comment.