bidirectional chap connect ( linux -> cisco ) - PPP

This is a discussion on bidirectional chap connect ( linux -> cisco ) - PPP ; 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: ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: bidirectional chap connect ( linux -> cisco )

  1. bidirectional chap connect ( linux -> cisco )

    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.

    I'm using Debian woody with default ipppd.

    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.
    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"]
    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"]

    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"]
    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



    Cisco Log:

    ..Dec 12 12:25:04.991: %LINK-3-UPDOWN: Interface BRI7:1, changed state to up
    ..Dec 12 12:25:04.995: BR7:1 PPP: Treating connection as a callin
    ..Dec 12 12:25:04.995: BR7:1 PPP: Phase is ESTABLISHING, Passive Open
    Dec 12 12:25:04.999: BR7:1 LCP: State is Listen
    ..Dec 12 12:25:04.999: %ISDN-6-LAYER2UP: Layer 2 for Interface BR7, TEI 108
    chang
    ed to up
    ..Dec 12 12:25:05.555: BR7:1 LCP: I CONFREQ[Listen] id 1 len 23
    ..Dec 12 12:25:05.555: BR7:1 LCP: MRU 1500 (0x010405DC)
    ..Dec 12 12:25:05.555: BR7:1 LCP: AuthProto CHAP (0x0305C22305)
    ..Dec 12 12:25:05.555: BR7:1 LCP: MagicNumber 0xEF69ACCC (0x0506EF69ACCC)
    Dec 12 12:25:05.555: BR7:1 LCP: PFC (0x0702)
    ..Dec 12 12:25:05.555: BR7:1 LCP: ACFC (0x0802)
    ..Dec 12 12:25:05.555: BR7:1 LCP: O CONFREQ[Listen] id 81 len 15
    ..Dec 12 12:25:05.555: BR7:1 LCP: AuthProto CHAP (0x0305C22305)

    ..Dec 12 12:25:05.555: BR7:1 LCP: MagicNumber 0x7630CDB0 (0x05067630CDB0)
    ..Dec 12 12:25:05.555: BR7:1 LCP: O CONFACK[Listen] id 1 len 23
    ..Dec 12 12:25:05.555: BR7:1 LCP: MRU 1500 (0x010405DC)
    ..Dec 12 12:25:05.555: BR7:1 LCP: AuthProto CHAP (0x0305C22305)
    ..Dec 12 12:25:05.555: BR7:1 LCP: MagicNumber 0xEF69ACCC (0x0506EF69ACCC)
    ..Dec 12 12:25:05.555: BR7:1 LCP: PFC (0x0702)
    Dec 12 12:25:05.559: BR7:1 LCP: ACFC (0x0802)
    ..Dec 12 12:25:05.579: BR7:1 LCP: I CONFACK [ACKsent] id 81 len 15
    ..Dec 12 12:25:05.579: BR7:1 LCP: AuthProto CHAP (0x0305C22305)
    ..Dec 12 12:25:05.579: BR7:1 LCP: MagicNumber 0x7630CDB0 (0x05067630CDB0)
    ..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 f
    ailed"
    ..Dec 12 12:25:06.011: BR7:1 PPP: Phase is TERMINATING
    ..Dec 12 12:25:06.011: BR7:1 LCP: O TERMREQ [Open] id 82 len 4
    ..Dec 12 12:25:06.035: BR7:1 LCP: I TERMACK [TERMsent] id 82 len 4
    ..Dec 12 12:25:06.035: BR7:1 LCP: State is Closed
    Dec 12 12:25:06.035: BR7:1 PPP: Phase is DOWN
    ..Dec 12 12:25:06.035: BR7:1 PPP: Phase is ESTABLISHING, Passive Open
    ..Dec 12 12:25:06.035: BR7:1 LCP: State is Listen
    ..Dec 12 12:25:06.039: %ISDN-6-DISCONNECT: Interface BRI7:1 disconnected

    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.

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

    Thank you.

    Felix





  2. Re: bidirectional chap connect ( linux -> cisco )

    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

  3. Re: bidirectional chap connect ( linux -> cisco )

    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]

  4. Re: bidirectional chap connect ( linux -> cisco )

    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.




  5. Re: bidirectional chap connect ( linux -> cisco )

    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.


  6. Re: bidirectional chap connect ( linux -> cisco )

    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

  7. Re: bidirectional chap connect ( linux -> cisco )

    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. */

+ Reply to Thread