Felix writes:
> I am clueless: I try to connect a Cisco router from a customer of
> us. This router use Chap in both directions. I don't really
> unterstand the protocol in detail, but this seems to be a little
> unusual:

A little unusual, but only if you're used to the PC/dial-up world.
The protocol was *designed* to handle mutual authentication, even if
it's not often used that way.

> I have to authenticate at the cisco and afterwards (or before?) the
> cisco authenticate itself at my machine.

Actually, it's at the same time. Both authenticate each other
simultaneously.

> Dec 12 12:46:55 schnaps ipppd[3459]: ChapSendChallenge: Sent id 1.
> Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveChallenge: Rcvd id 36.
> Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveChallenge: received name field: 'XXXXXX'
> Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveFailure: Rcvd id 36.
> Dec 12 12:46:55 schnaps ipppd[3459]: Remote message: Authorization failed

Looks like the peername and/or secret for authenticating yourself to
your peer is bad.

> Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][CHAP Challenge id=0x24 <422bf9c04b19ef3940eabe742b9debdb>, name = "XXXCustomerXXX"]
> Dec 12 12:46:55 schnaps ipppd[3459]: sent [0][CHAP Response id=0x24 <31006c0b05096be5a6caf9caca17092f>, name = "XXXweXXX"]

Your configuration should have this:

name XXXweXXX

And your chap-secrets file should have:

XXXweXXX XXXCustomerXXX 'to customer' *
XXXCustomerXXX XXXweXXX 'from customer' *

The 'to customer' secret is the one that's used for proving your
identity to this customer, and the 'from customer' one is the one
that's used to prove this customer's identity to you. The way to
remember this is that the first field is the "client" of the
authentication (authenticatee), and the second is the "server"
(authenticator).

These two should not be the same, and based on the logs above, it's at
least the 'to customer' one that's wrong.

> Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][CHAP Failure id=0x24 "Authorization failed"]

The peer doesn't believe you. Either the user name you're supplying
to him or the secret you're using is incorrect.

> Secrets are ok. If I change these, I get another error. It seems to
> me, that my machine doesn't expect a challenge from the cisco.

I disagree. Your machine is responding just fine. It's just that the
Cisco doesn't like the response.

If your machine didn't expect that challenge, it would have refused to
authenticate itself via CHAP.

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Hello,

thank you very much for the detailed answer.

The difficulty with this kind of problem is: only one side is under my control. If the customers cisco-admin tells me, on his side is the configuration as usual and in best oder, I have to look over my configs over and over again.


> Your configuration should have this:
>
> name XXXweXXX
>
> And your chap-secrets file should have:
>
> XXXweXXX XXXCustomerXXX 'to customer' *
> XXXCustomerXXX XXXweXXX 'from customer' *

My configuration is exactly this way. BUT the "to_customer" and "from_customer" secrets ARE actually the same. You wrote
> These two should not be the same
Is this "only" a security concern? Or does the protocol depend on the difference of the secret?
Our customers admin told me, that he is not able to use different secrets for both directions...

I discovered someting interesting:
If I change the "to customer" secret on my side (to a wrong one), I get an "Authentication failure". With the correct "to customer" and the probably correct "from customer" or a ramdomly choosen "from customer", I get an "Authorization failure".

What is the difference between "authentication" and "authorization"?

Felix
--
Felix Enning System Administration / Software Development
mailto:felix.enning@dimedis.de [GnuPG Public Key on request]
dimedis GmbH i. Gr., Dillenburger Str. 83, 51105 Köln, +49 221 921260-32
http://www.dimedis.de [supporting: http://www.hausfrauenseite.de]

Felix writes:

]Hello Group,
]
]I am clueless: I try to connect a Cisco router from a customer of us. This router use Chap in both directions. I don't really unterstand the protocol in detail, but this seems to be a little unusual:
]I have to authenticate at the cisco and afterwards (or before?) the cisco authenticate itself at my machine.

Authentication is entirely under the control of the machine asking the
othr side for authentication. Thus the cisco authenticates itself to
your machine ONLY if your machine asks for it. There is no mechanism
under the protocol for a machine to demand to be authenticated.

]
]I'm using Debian woody with default ipppd.
]

ipppd???? All Linuxes have anu pppd as the default.

Unles this machine is 20 years old, I would strongly suggest you use
pppd.

]I have detailed logs from my machine and the cisco. Here is an excerpt:
]
]my machine
]/var/log/message:
]Dec 12 12:46:50 schnaps ipppd[3459]: Connect[0]: /dev/ippp0, fd: 8
]Dec 12 12:46:52 schnaps kernel: ippp0: dialing 1 0234XXXXXXXX...
]Dec 12 12:46:55 schnaps kernel: isdn_net: ippp0 connected
]Dec 12 12:46:55 schnaps ipppd[3459]: Local number: 221XXXXXXX, Remote number: 0234XXXXXXX, Type: outgoing
]Dec 12 12:46:55 schnaps ipppd[3459]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 8
]Dec 12 12:46:55 schnaps ipppd[3459]: ChapSendChallenge: Sent id 1.
]Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveChallenge: Rcvd id 36.
]Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveChallenge: received name field: 'XXXXXX'
]Dec 12 12:46:55 schnaps ipppd[3459]: ChapReceiveFailure: Rcvd id 36.

No idea what these messages mean. It seems that you are not successfully
authenticating yourself to the remote end.

]Dec 12 12:46:55 schnaps ipppd[3459]: Remote message: Authorization failed
]Dec 12 12:46:55 schnaps ipppd[3459]: LCP terminated by peer
]Dec 12 12:46:55 schnaps ipppd[3469]: Can't execute /etc/ppp/auth-fail: No such file or directory
]Dec 12 12:46:56 schnaps ipppd[3459]: Modem hangup
]Dec 12 12:46:56 schnaps ipppd[3459]: Connection terminated.
]Dec 12 12:46:56 schnaps ipppd[3459]: taking down PHASE_DEAD link 0, linkunit: 0
]Dec 12 12:46:56 schnaps ipppd[3459]: LCP is down
]Dec 12 12:46:56 schnaps ipppd[3459]: closing fd 8 from unit 0
]Dec 12 12:46:56 schnaps ipppd[3459]: link 0 closed , linkunit: 0
]Dec 12 12:46:56 schnaps ipppd[3459]: reinit_unit: 0
]Dec 12 12:46:56 schnaps ipppd[3459]: Connect[0]: /dev/ippp0, fd: 8
]Dec 12 12:46:56 schnaps kernel: ippp0: remote hangup
]Dec 12 12:46:56 schnaps kernel: ippp0: Chargesum is 0
]
]/var/log/debug
]
]Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][LCP ConfAck id=0x1 ]
]Dec 12 12:46:55 schnaps ipppd[3459]: lcp layer is UP
]Dec 12 12:46:55 schnaps ipppd[3459]: sent [0][CHAP Challenge id=0x1 <82b368c0d9d19b6fef2c12d0aca75bcd737d95d559ea217ff0 ed5d2e271ddacbf6>, name = "XXXweXXX"]

You ask the remote machine to authenticate itself to you You tell it
that your machine name is XXXweXXX so it can find the correct reponse.

]Dec 12 12:46:55 schnaps kernel: isdn_ppp_poll: minor: 128
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_ioctl: minor: 0 cmd: 8004745a state: 3
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_ioctl: minor: 0 cmd: 40047459 state: 3
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_ioctl: minor: 0 cmd: 40047452 state: 3
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_ioctl: minor: 0 cmd: 8004745a state: 3
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_ioctl: minor: 0 cmd: 40047459 state: 3
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_poll: minor: 128
]Dec 12 12:46:55 schnaps kernel: ippp_receive: is:cefa4000 lp:cf9e4e00 slot:0 unit:0 len:32
]Dec 12 12:46:55 schnaps kernel: [0/0].receive[0]: ff 03 c2 23 01 24 00 1c 10 42 2b f9 c0 4b 19 ef
]Dec 12 12:46:55 schnaps kernel: [0/0].receive[1]: 39 40 ea be 74 2b 9d eb db 42 4f 43 34 35 30 30
]Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][CHAP Challenge id=0x24 <422bf9c04b19ef3940eabe742b9debdb>, name = "XXXCustomerXXX"]
]Dec 12 12:46:55 schnaps ipppd[3459]: sent [0][CHAP Response id=0x24 <31006c0b05096be5a6caf9caca17092f>, name = "XXXweXXX"]

These are all fine. The remote machine has asked you to authenticate
yourself, you have responded.

]Dec 12 12:46:55 schnaps kernel: isdn_ppp_poll: minor: 128
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_poll: minor: 128
]Dec 12 12:46:55 schnaps kernel: ippp_receive: is:cefa4000 lp:cf9e4e00 slot:0 unit:0 len:28
]Dec 12 12:46:55 schnaps kernel: [0/0].receive[0]: ff 03 c2 23 04 24 00 18 41 75 74 68 6f 72 69 7a
]Dec 12 12:46:55 schnaps kernel: [0/0].receive[1]: 61 74 69 6f 6e 20 66 61 69 6c 65 64
]Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][CHAP Failure id=0x24 "Authorization failed"]

The remote machine tells you that your response was incorrect.

The cisco logs reflect the same thing.


This has nothing to do with your asking it to authenticate itself
(although why your would do so is a bit obscure to me).

]Dec 12 12:46:55 schnaps ipppd[3459]: rcvd [0][LCP TermReq id=0x52]
]Dec 12 12:46:55 schnaps ipppd[3459]: sent [0][LCP TermAck id=0x52]
]Dec 12 12:46:55 schnaps kernel: isdn_ppp_poll: minor: 128
]
]
]

]Secrets are ok. If I change these, I get another error. It seems to me, that my machine doesn't expect a challenge from the cisco.
]

The secret is NOT ok.
That is what chap failure means.


]Anybody have an idea? Or a pointer to another group or FAQ?


a) Use pppd (If on an older kernel use 2.3.11, on a 2.4 level kernel use
2.4.1)
b)Get rid of your request that the cisco authenticate itself to you.
c) Put in the correct secret.

Felix writes:

]Hello,

]thank you very much for the detailed answer.

]The difficulty with this kind of problem is: only one side is under my control. If the customers cisco-admin tells me, on his side is the configuration as usual and in best oder, I have to look over my configs over and over again.


]> Your configuration should have this:
]>
]> name XXXweXXX
]>
]> And your chap-secrets file should have:
]>
]> XXXweXXX XXXCustomerXXX 'to customer' *
]> XXXCustomerXXX XXXweXXX 'from customer' *

]My configuration is exactly this way. BUT the "to_customer" and "from_customer" secrets ARE actually the same. You wrote
]> These two should not be the same
]Is this "only" a security concern? Or does the protocol depend on the difference of the secret?
]Our customers admin told me, that he is not able to use different secrets for both directions...

]I discovered someting interesting:
]If I change the "to customer" secret on my side (to a wrong one), I get an "Authentication failure". With the correct "to customer" and the probably correct "from customer" or a ramdomly choosen "from customer", I get an "Authorization failure".

]What is the difference between "authentication" and "authorization"?

Not having the logs I would say the difference is which machine is
refusing the authentication.
Ie, your machine uses the term "authentication" and the cisco uses
"authorisation".

a) Stop your machine from asking for authentication.
Eg, remove the "require-chap" or +chap from your list of options.
Then try it. Make that direction work first. Then when that is working
you can if you wish reisntitute authentication on your end.

Felix writes:
> The difficulty with this kind of problem is: only one side is under
> my control. If the customers cisco-admin tells me, on his side is
> the configuration as usual and in best oder, I have to look over my
> configs over and over again.

Yeah, that's not an uncommon problem.

> > XXXweXXX XXXCustomerXXX 'to customer' *
> > XXXCustomerXXX XXXweXXX 'from customer' *
>
> My configuration is exactly this way. BUT the "to_customer" and "from_customer" secrets ARE actually the same. You wrote
> > These two should not be the same
> Is this "only" a security concern? Or does the protocol depend on the difference of the secret?

No, the protocol doesn't depend on it. It's "merely" a security
issue. (As in: the link has little or no security if the two secrets
are the same. ;-})

> Our customers admin told me, that he is not able to use different
> secrets for both directions...

Hmm. I'd thought that Cisco had fixed that problem ... oh well.

> I discovered someting interesting:
> If I change the "to customer" secret on my side (to a wrong one), I get an "Authentication failure". With the correct "to customer" and the probably correct "from customer" or a ramdomly choosen "from customer", I get an "Authorization failure".
>
> What is the difference between "authentication" and "authorization"?

Authentication is something that proves a given identity.
Authorization is a set of things that you're allowed to do.

I can't say I've seen the "authorization failure" message out of a
Cisco machine, and the Cisco web site doesn't seem to mention it as a
possibility. I agree that since you're getting different behaviors in
these two cases, that there's something else amiss, but I have no idea
what that would be.

(Based just on the text, one could imagine that the PPP configuration
on that Cisco doesn't allow use of PPP on that port, or doesn't allow
the use of any network protocol. But that's just wild speculation.)

--
James Carlson, IP Systems Group
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Felix wrote:
> I am clueless: I try to connect a Cisco router from a customer of us. This
> router use Chap in both directions. I don't really unterstand the protocol
> in detail, but this seems to be a little unusual:
> I have to authenticate at the cisco and afterwards (or before?) the
> cisco authenticate itself at my machine.

According to the Cisco log it's PPP implementation is going to wait until
you authenticate yourself to it before it will authenticate itself to you.

> I'm using Debian woody with default ipppd.

> I have detailed logs from my machine and the cisco. Here is an excerpt:
....

> Cisco Log:
....

> .Dec 12 12:25:05.579: BR7:1 LCP: State is Open
> .Dec 12 12:25:05.579: BR7:1 PPP: Phase is AUTHENTICATING, by both
> .Dec 12 12:25:05.579: BR7:1 CHAP: O CHALLENGE id 36 len 28 from
> "XXXcustomerXXX".Dec 12 12:25:05.587: BR7:1 CHAP: I CHALLENGE id 1 len
> 45 from "XXXweXXX"
> .Dec 12 12:25:05.587: BR7:1 CHAP: Waiting for peer to authenticate first
> .Dec 12 12:25:05.603: BR7:1 CHAP: I RESPONSE id 36 len 28 from "XXXweXXX"
> .Dec 12 12:25:06.011: BR7:1 CHAP: O FAILURE id 36 len 24 msg is
> "Authorization failed"

The Cisco failed to authenticate you. In a later post you said that the
message changed to "Authentication failed" when the secret "to_customer"
in the first secrets line was changed so as to be incorrect.

This suggests to me that the Cisco PPP implementation first looks at a
list of secrets to see whether there is one that can be verified with
the CHAP Challenge, and if there is one then it looks for a name that
matches the one it receives with the Challenge. If so then that would
seem to mean that the name XXXmeXXX isn't in the Cisco (XXXcustomerXXX)
authentication database.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* 97.3% of all statistics are made up. */