From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Oct 14 2004 - 11:11:50 GMT-3
Carlos,
Every authentication procedure consists of three parts, the
authentication request/challenge, the response, and the validation of
the response. What I mean is that both devices do not have to
authenticate.
In every example I've seen in a Cisco text or on CCO, the "ppp
authentication" command is configured on both ends of the link. In
addition to this, it's common practice for people to put some variation
of the "ppp authentication chap callin" or "ppp authentication chap
callout" command to stop a device from being the authenticator.
Instead, this should be accomplished by simply not issuing the ppp
authentication command.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Carlos G Mendioroz
> Sent: Thursday, October 14, 2004 5:00 AM
> To: Brian McGahan
> Cc: ccie2be; Gene Thorne; ccielab@groupstudy.com
> Subject: Re: Something New (the myths we believe)
>
> Brian,
> the "authentication" commands in R2 are the identity tokens
> (password/secret) that are in both of your examples in R2 config!
>
> Default authentication is "authenticate if needed" so to say, both
ways.
> R1 in your example requires R2 to authenticate.
>
> I was just curious about what you call a "two way process".
> Authentication is a security function about a peer. PAP and CHAP are
> implementations, and I would say PAP is a "one way process" because
the
> one who wants to be authenticated provides credentials and that's it.
> CHAP, on the other hand, I would call two way, because the one
> requesting authentication chalenges the other party, and the response
is
> the authentication. Response, per se, implies a two way process...
>
> All in all, I would say that in ppp all authentication are two way
> processes, because the authenticating peer requests the other to
> authenticate...
>
> I guess the whole confusion for me was the use of "process" in your
> statement.
>
> Brian McGahan wrote:
>
> > Tim,
> >
> > Ummm... interesting story, but here is what I really meant ;)
> > Below are PAP and CHAP configs for routers R1 and R2 connected via a
PPP
> > link with R1 authenticating R2:
> >
> > PAP
> > ---
> > R1:
> > username R2 password PAPPASS
> > !
> > interface PPPLINK
> > ppp authentication pap
> >
> > R2:
> > interface PPPLINK
> > ppp pap sent-username R2 password PAPPASS
> >
> >
> > CHAP
> > ----
> > R1:
> > username R2 password CHAPPASS
> > !
> > interface PPPLINK
> > ppp authentication chap
> >
> > R2:
> > username R1 password CHAPPASS
> >
> >
> >
> > Where are the "ppp authentication" commands on R2? Why does
> > this work?
> >
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> >
> >>-----Original Message-----
> >>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> >
> > Of
> >
> >>ccie2be
> >>Sent: Wednesday, October 13, 2004 5:39 PM
> >>To: Carlos G Mendioroz; Brian McGahan
> >>Cc: Gene Thorne; ccielab@groupstudy.com
> >>Subject: Re: Something New (the myths we believe)
> >>
> >>Assume r1 and r2 are connected via ppp (could be isdn, but it
doesn't
> >
> > have
> >
> >>to be).
> >>
> >>You can configure ppp authentication on r1 but not configure
> >>authentication
> >>on r2. If you do this, r2 has to authenticate before it can
> >
> > communicate
> >
> >>with R1, but r1 doesn't have to authenticate with r2 to communicate
> >
> > with
> >
> >>it.
> >>
> >>Think of it like this.
> >>
> >>Suppose you go to a free standing ATM machine in some mall somewhere
> >
> > to
> >
> >>take
> >>out some cash. You put your card in the slot and the atm machine
> >
> > tells
> >
> >>you
> >>to enter your pin, so you do.
> >>
> >>Then you get a message saying something like, "Sorry, but we can't
> >
> > reach
> >
> >>your bank to authenticate your identity. Please try again later."
> >>
> >>Quite possibly you have become a victim of a fraud. That ATM
machine
> >>"authenticated" you by getting your card # and pin, but you didn't
get
> >>your
> >>cash. And, even worse, in about 5 minutes your bank account is
clean
> >>out.
> >>
> >>All because you didn't authenticate that atm before giving up your
> >
> > pin.
> >
> >>HTH, Tim
> >>----- Original Message -----
> >>From: "Carlos G Mendioroz" <tron@huapi.ba.ar>
> >>To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> >>Cc: "Gene Thorne" <gthorne@netcogov.com>; <ccielab@groupstudy.com>
> >>Sent: Wednesday, October 13, 2004 6:01 PM
> >>Subject: Re: Something New (the myths we believe)
> >>
> >>
> >>
> >>>What do you mean by ppp authentication not being a two way process
?
> >>>
> >>>
> >>>Brian McGahan wrote:
> >>>
> >>>
> >>>>Better yet that you can't remove a line out of a numbered
> >
> > access-list
> >
> >>>>without destroying and recreating the entire list. (you can)
> >>>>
> >>>>"no arp frame-relay" stops inverse-arp replies (it doesn't)
> >>>>
> >>>>ppp authentication is a two way process (it's not)
> >>>>
> >>>>Don't start listing these behaviors as "gotchas" though, they
> >>>>are simply technologies that the fundamental behaviors are
> >>>>misunderstood. Most of these "myths" can be eliminated by simply
> >>
> >>trying
> >>
> >>>>the configuration out and seeing how it works firsthand on the
> >
> > command
> >
> >>>>line.
> >>>>
> >>>>Brian McGahan, CCIE #8593
> >>>>bmcgahan@internetworkexpert.com
> >>>>
> >>>>Internetwork Expert, Inc.
> >>>>http://www.InternetworkExpert.com
> >>>>Toll Free: 877-224-8987 x 705
> >>>>Outside US: 775-826-4344 x 705
> >>>>24/7 Support: http://forum.internetworkexpert.com
> >>>>Live Chat: http://www.internetworkexpert.com/chat/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> >
> > Behalf
> >
> >>>>Of
> >>>>
> >>>>
> >>>>>Gene Thorne
> >>>>>Sent: Wednesday, October 13, 2004 12:12 PM
> >>>>>To: ccielab@groupstudy.com
> >>>>>Subject: RE: Something New (the myths we believe)
> >>>>>
> >>>>>My favorite myth is that static routes pointing to an interface
> >
> > have
> >
> >>>>an
> >>>>
> >>>>
> >>>>>admin distance of 0, not 1.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> >
> > Behalf Of
> >
> >>>>>Joe Rinehart
> >>>>>Sent: Wednesday, October 13, 2004 12:02 PM
> >>>>>To: ccielab@groupstudy.com
> >>>>>Subject: Something New (the myths we believe)
> >>>>>
> >>>>>
> >>>>>Just when you think you have things halfway figured out you
> >
> > realize
> >
> >>>>how
> >>>>
> >>>>
> >>>>>far
> >>>>>off your perceptions can be. I had two "revelations" while
> >
> > working on
> >
> >>>>the
> >>>>
> >>>>
> >>>>>Netmaster DoIt lab #1 (its pretty grueling, in a good way).
There
> >>>>
> >>>>were
> >>>>
> >>>>
> >>>>>two
> >>>>>things that really bit me because I thought I knew these for
> >>>>
> >>>>certain....
> >>>>
> >>>>
> >>>>>Myth#1 A Catalyst 3550 cannot do BGP.
> >>>>>
> >>>>>When the lab asked for this I thought it was a joke, and to be
> >
> > honest
> >
> >>>>I
> >>>>
> >>>>
> >>>>>cannot remember where I picked this idea up, but a quick check on
> >
> > the
> >
> >>>>doc
> >>>>
> >>>>
> >>>>>CD
> >>>>>and I found my face turning red (proverbially speaking). I think
> >
> > I
> >
> >>>>was
> >>>>
> >>>>
> >>>>>relying on a "features not supported" on one of the CCIE Cisco
> >
> > Press
> >
> >>>>study
> >>>>
> >>>>
> >>>>>books... In any case there are some limitations but it does
> >
> > indeed
> >
> >>>>>support
> >>>>>BGP....
> >>>>>
> >>>>>Myth#2 Subinterfaces cannot coexist with natural interfaces on
the
> >>>>
> >>>>same
> >>>>
> >>>>
> >>>>>physical interface.
> >>>>>
> >>>>>This one blew me away. When I read the question I figured it was
> >
> > one
> >
> >>>>of
> >>>>
> >>>>
> >>>>>those "trick answers" that just had to be interpreted, so I did a
> >>>>>multipoint
> >>>>>subinterface and a point to point subinterface. When I was
> >
> > working
> >
> >>>>though
> >>>>
> >>>>
> >>>>>the answer key I was rather taken aback to see that it was on the
> >>>>
> >>>>physical
> >>>>
> >>>>
> >>>>>interface. Still a skeptic, I removed the multipoint
> >
> > subinterface,
> >
> >>>>put
> >>>>
> >>>>
> >>>>>the
> >>>>>code on the main interface (leaving the P2P subif) and then
> >
> > reloaded
> >
> >>>>the
> >>>>
> >>>>
> >>>>>router. I was shocked it worked.
> >>>>>
> >>>>>I think my reason for posting this is just to see if there have
> >
> > been
> >
> >>>>any
> >>>>
> >>>>
> >>>>>other experiences like this for other folks and what those
> >
> > assumptions
> >
> >>>>>were.
> >>>>>After all, there is a saying about assume.....
> >>>>>
> >>>>>Joe Rinehart, CCNP, CCDP
> >>>>>Data Network Consultant, AT&T Corporation
> >>>>>Pacific Northwest Enterprise Markets
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3