PAP authentication - Why this happens?

Post by k***@gmail.com
What will happen if a ppp peer receives a PAP authenticate
Ack with an identifier different from the one it sent in PAP
authenticate request?

It's supposed to ignore it silently. It's also not supposed to happen
at all, so it probably doesn't matter.

Post by k***@gmail.com
Can somebody explain me the behavior from the below log?
Is the behavior correct one?

It looks like it to me.

Post by k***@gmail.com
rcvd [LCP ConfReq id=0x1 <auth pap>]

This system demands that the peer authenticate itself to the local
system.

Post by k***@gmail.com
sent [LCP ConfReq id=0x1 <auth pap>]

The peer also demands that you authenticate to it. You're using
bidirectional authentication.

This is legal, but highly unusual.

Post by k***@gmail.com
sent [LCP ConfAck id=0x1 <auth pap>]
rcvd [LCP ConfAck id=0x1 <auth pap>]

Both agree.

Post by k***@gmail.com
sent [PAP AuthReq id=0x1 user="root" password=<hidden>]

The system sends an authentication request, as demanded by the peer.

Post by k***@gmail.com
sent [PAP AuthReq id=0x2 user="root" password=<hidden>]

After a timeout, the local system sends another message. The first
must have been dropped.

Post by k***@gmail.com
rcvd [PAP AuthAck id=0x3 "login ok"]

The peer responds with bogus ID number.

Post by k***@gmail.com
Remote message: login ok
PAP authentication succeeded

The local system accepts that. Oh, well. Not a big failing.

Post by k***@gmail.com
sent [LCP TermReq id=0x2 "Authentication failed"]
sent [LCP TermReq id=0x3 "Authentication failed"]

The remote system is broken. It never bothered to send a PAP
Authentication-Request, even though it *agreed* to do so above.
That's what caused the failure.

I suspect you might have "requirepap" in your configuration, and that
you don't really want it.

--
James Carlson 42.703N 71.076W <***@workingcode.com>

Unruh

2006-12-02 02:31:13 UTC

Post by k***@gmail.com
What will happen if a ppp peer receives a PAP authenticate
Ack with an identifier different from the one it sent in PAP
authenticate request?
The below is the log of what actually happened. I am simulating
one of the peer and using pppd in Linux as the other peer.
The log is that of the pppd.
Can somebody explain me the behavior from the below log?
Is the behavior correct one?

You do not have time stamps on this. Always include the time stamps from
the logs. Many things ae time sensitive.

Both the local and the remote systems demand that the other authenticate
themselves. Both agree. You send them an authentication which succeeds, they never send
one to you. Thus after a while your system will say they have failed, which
it does.

Note that if the remote side is an ISP, they almost never willl
authenticate themselves to you. In they case they say they will, but don't.
I have no idea what "I am simulating
one of the peer and using pppd in Linux as the other peer" means. If this
is you playing silly buggers, then it is not surprising that all kinds of
nonesense can happen.

Post by k***@gmail.com
====
Using interface ppp0
Connect: ppp0 <--> /dev/pts/10
rcvd [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfAck id=0x1 <auth pap>]
rcvd [LCP ConfAck id=0x1 <auth pap>]
sent [PAP AuthReq id=0x1 user="root" password=<hidden>]
sent [PAP AuthReq id=0x2 user="root" password=<hidden>]
rcvd [PAP AuthAck id=0x3 "login ok"]
Remote message: login ok
PAP authentication succeeded
sent [LCP TermReq id=0x2 "Authentication failed"]
sent [LCP TermReq id=0x3 "Authentication failed"]
Connection terminated.

k***@gmail.com

2006-12-04 05:25:14 UTC

I removed the require-pap from the options file of pppd. Now I am
using unidirectional authentication. The authentication succeeds
and goes to the IPCP phase.

I am interested in knowing about why the pppd accepts the PAP
Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
packet and continue sending PAP Auth-Req till it receives a PAP
Auth-Ack with a valid identifier or the maximum times it is configured
to send Auth-Req before terminating the connection.

How do I make the logs to include timestamps? By saying "I am
simulating
one of the peer " what I mean is that I am sending the PPP packets from
my
own program.

Thanks,
Sriram K

log:
===
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
rcvd [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfReq id=0x1]
sent [LCP ConfAck id=0x1 <auth pap>]
rcvd [LCP ConfAck id=0x1]
sent [PAP AuthReq id=0x1 user="root" password=<hidden>]
sent [PAP AuthReq id=0x2 user="root" password=<hidden>]
rcvd [PAP AuthAck id=0x3 "login ok"]
Remote message: login ok
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x2 "No network protocols running"]
sent [LCP TermReq id=0x3 "No network protocols running"]
Connection terminated.

You do not have time stamps on this. Always include the time stamps from
the logs. Many things ae time sensitive.
Both the local and the remote systems demand that the other authenticate
themselves. Both agree. You send them an authentication which succeeds, they never send
one to you. Thus after a while your system will say they have failed, which
it does.
Note that if the remote side is an ISP, they almost never willl
authenticate themselves to you. In they case they say they will, but don't.
I have no idea what "I am simulating
one of the peer and using pppd in Linux as the other peer" means. If this
is you playing silly buggers, then it is not surprising that all kinds of
nonesense can happen.

Unruh

2006-12-04 07:25:34 UTC

Post by k***@gmail.com
I removed the require-pap from the options file of pppd. Now I am
using unidirectional authentication. The authentication succeeds
and goes to the IPCP phase.
I am interested in knowing about why the pppd accepts the PAP
Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
packet and continue sending PAP Auth-Req till it receives a PAP
Auth-Ack with a valid identifier or the maximum times it is configured
to send Auth-Req before terminating the connection.
How do I make the logs to include timestamps? By saying "I am
simulating

put
daemon.* /var/log/daemonlog
into /etc/sysconfig.conf

Then run
killall -1 syslogd
Then post the lines from /var/log/daemonlog after you have tried to
connect.

Post by k***@gmail.com
one of the peer " what I mean is that I am sending the PPP packets from
my
own program.

Again I have no idea what you are saying.

Post by k***@gmail.com
Thanks,
Sriram K
===
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
rcvd [LCP ConfReq id=0x1 <auth pap>]
sent [LCP ConfReq id=0x1]
sent [LCP ConfAck id=0x1 <auth pap>]
rcvd [LCP ConfAck id=0x1]
sent [PAP AuthReq id=0x1 user="root" password=<hidden>]
sent [PAP AuthReq id=0x2 user="root" password=<hidden>]
rcvd [PAP AuthAck id=0x3 "login ok"]
Remote message: login ok
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x2 "No network protocols running"]
sent [LCP TermReq id=0x3 "No network protocols running"]
Connection terminated.

You do not have time stamps on this. Always include the time stamps from
the logs. Many things ae time sensitive.
Both the local and the remote systems demand that the other authenticate
themselves. Both agree. You send them an authentication which succeeds, they never send
one to you. Thus after a while your system will say they have failed, which
it does.
Note that if the remote side is an ISP, they almost never willl
authenticate themselves to you. In they case they say they will, but don't.
I have no idea what "I am simulating
one of the peer and using pppd in Linux as the other peer" means. If this
is you playing silly buggers, then it is not surprising that all kinds of
nonesense can happen.

k***@gmail.com

2006-12-04 08:17:51 UTC

I build the PPP packet with whatever options I want using a socket
program
and put it on the wire.
Thanks,
Sriram K

put
daemon.* /var/log/daemonlog
into /etc/sysconfig.conf
Then run
killall -1 syslogd
Then post the lines from /var/log/daemonlog after you have tried to
connect.

Post by k***@gmail.com
one of the peer " what I mean is that I am sending the PPP packets from
my
own program.

Again I have no idea what you are saying.

You do not have time stamps on this. Always include the time stamps from
the logs. Many things ae time sensitive.
Both the local and the remote systems demand that the other authenticate
themselves. Both agree. You send them an authentication which succeeds, they never send
one to you. Thus after a while your system will say they have failed, which
it does.
Note that if the remote side is an ISP, they almost never willl
authenticate themselves to you. In they case they say they will, but don't.
I have no idea what "I am simulating
one of the peer and using pppd in Linux as the other peer" means. If this
is you playing silly buggers, then it is not surprising that all kinds of
nonesense can happen.

James Carlson

2006-12-04 15:12:18 UTC

Post by k***@gmail.com
I am interested in knowing about why the pppd accepts the PAP
Auth-Ack packet with the bogus identifier.

Because, quite simply, it doesn't do that. Look at the code in
upap_input and upap_rauthack -- it does not do the check you're asking
about.

What more do you need to know?

Post by k***@gmail.com
Shouldn't it ignore that
packet and continue sending PAP Auth-Req till it receives a PAP
Auth-Ack with a valid identifier or the maximum times it is configured
to send Auth-Req before terminating the connection.

Yes ... but since this just never happens, why do you care?

--
James Carlson 42.703N 71.076W <***@workingcode.com>

k***@gmail.com

2006-12-05 05:16:07 UTC

Thanks Carlson. One last thing, is it compliant with the RFC? Because
from what I have read I feel that it isn't.

Thank you.
Sriram K

Post by k***@gmail.com
I am interested in knowing about why the pppd accepts the PAP
Auth-Ack packet with the bogus identifier.

Because, quite simply, it doesn't do that. Look at the code in
upap_input and upap_rauthack -- it does not do the check you're asking
about.
What more do you need to know?

Yes ... but since this just never happens, why do you care?
--

James Carlson

2006-12-05 13:21:19 UTC

Post by k***@gmail.com
Thanks Carlson. One last thing, is it compliant with the RFC? Because
from what I have read I feel that it isn't.

Yes, it's compliant. RFC 1334 does not say that you must discard
Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
says only:

Identifier

The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate-Request which caused this
reply.

In other words, the authenticator is *required* to copy the Identifier
value from the Authenticate-Request message into the corresponding
reply. The authenticatee is under no obligation to validate this
field in any particular way.

Why do you feel that it is not compliant with the RFC? What
requirement is it violating?

Once again, I must ask: why do you care? What are you doing that
would produce this result, and why do you insist that there must be a
"purity test" here?

My take on it is that testing the received Identifier value would
actually be a bad thing to do, because it violates the cardinal rule:
"be conservative in what you send, liberal in what you expect."
Consider the case where you have a very slow external authentication
server: you send AuthReq ID=1, and before it can respond, you send
AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
would you want to discard that? And aren't you risking an unending
timing problem -- getting further and further behind as requests queue
up?

I can see no actual problem that is fixed by being overly picky about
the Identifier value, and several problems that may be caused by
adding such logic. (I can recommend a book that discusses some of the
pitfalls involved in PPP implementation, if you're interested.)

I could add logic as you suggest to pppd, but I see no reason to do
so.

--
James Carlson 42.703N 71.076W <***@workingcode.com>

k***@gmail.com

2006-12-06 04:25:35 UTC

Thanks once again Carlson. I am just a novice and in a learning curve.
Your detailed explanations has helped me. I would like to know the
book's
title and its author.

Thanks,
Sriram K

Post by k***@gmail.com
Thanks Carlson. One last thing, is it compliant with the RFC? Because
from what I have read I feel that it isn't.

Yes, it's compliant. RFC 1334 does not say that you must discard
Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate-Request which caused this
reply.
In other words, the authenticator is *required* to copy the Identifier
value from the Authenticate-Request message into the corresponding
reply. The authenticatee is under no obligation to validate this
field in any particular way.
Why do you feel that it is not compliant with the RFC? What
requirement is it violating?
Once again, I must ask: why do you care? What are you doing that
would produce this result, and why do you insist that there must be a
"purity test" here?
My take on it is that testing the received Identifier value would
"be conservative in what you send, liberal in what you expect."
Consider the case where you have a very slow external authentication
server: you send AuthReq ID=1, and before it can respond, you send
AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
would you want to discard that? And aren't you risking an unending
timing problem -- getting further and further behind as requests queue
up?
I can see no actual problem that is fixed by being overly picky about
the Identifier value, and several problems that may be caused by
adding such logic. (I can recommend a book that discusses some of the
pitfalls involved in PPP implementation, if you're interested.)
I could add logic as you suggest to pppd, but I see no reason to do
so.
--

Unruh

2006-12-08 18:06:10 UTC

Post by k***@gmail.com
Thanks once again Carlson. I am just a novice and in a learning curve.
Your detailed explanations has helped me. I would like to know the
book's
title and its author.

The author is one James Carlson. PPP Design and Debugging
He tends to be coy about it.

Post by k***@gmail.com
Thanks,
Sriram K

Post by k***@gmail.com
Thanks Carlson. One last thing, is it compliant with the RFC? Because
from what I have read I feel that it isn't.

James Carlson

2006-12-14 16:24:08 UTC

Post by k***@gmail.com
Thanks once again Carlson. I am just a novice and in a learning curve.
Your detailed explanations has helped me. I would like to know the
book's
title and its author.

The author is one James Carlson. PPP Design and Debugging
He tends to be coy about it.

Nah. I just figure that google and amazon searches are universally
available. ;-}

--
James Carlson 42.703N 71.076W <***@workingcode.com>

Unruh

2006-12-15 06:20:12 UTC