should retransmitted PPP CHAP Response trigger retransmitted PPP CHAP Success? - PPP

This is a discussion on should retransmitted PPP CHAP Response trigger retransmitted PPP CHAP Success? - PPP ; I have a situation where a PPTP client (Mac OS X 10.3.7) is usually failing to connect to a PPTP server (cisco VPN 3030, software 4.1.7C) The server requires the client to authenticate using MS-CHAPv2. It appears the client ignores ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: should retransmitted PPP CHAP Response trigger retransmitted PPP CHAP Success?

  1. should retransmitted PPP CHAP Response trigger retransmitted PPP CHAP Success?

    I have a situation where a PPTP client (Mac OS X 10.3.7) is usually
    failing to connect
    to a PPTP server (cisco VPN 3030, software 4.1.7C)

    The server requires the client to authenticate using MS-CHAPv2.

    It appears the client ignores the PPP CHAP Success message sent by the
    server.
    (I'm unclear why, and this may be a client bug, but this isn't what
    I'm interested in here.)

    At this point, although the server has started IPCP and CCP
    negotiation,
    the client is still trying to complete authentication.
    Since the client feels it hasn't received a PPP CHAP Success message
    yet,
    it keeps retransmitting its last PPP CHAP Response message.
    The server sees that message, and decides to NOT respond to it.

    My question is: should the server ignore the retransmitted PPP CHAP
    Response messages
    received while it believes it is negotiating IPCP and CCP?
    It seems to me that each should trigger the server to retransmit the
    PPP CHAP Success message.

    --

    Here's the sequence of events:

    PPTP call setup happens normally.

    PPP negotiation begins fine, LCP negotiation appears to
    proceed satisfactorily until late in authentication.

    The server wants the client to authenticate using MS-CHAPv2, and the
    client agrees to do so.

    Server logs that LCP layer is UP.

    The MS-CHAPv2 authentication appears to proceed normally,
    until....

    Client sends PPP CHAP Response.

    Server sends PPP CHAP Success.

    Server logs that IPCP Layer Started.
    Server logs that CCP Layer Started.

    Server sends PPP IPCP Config Request.
    Server sends PPP CCP Config Request.

    Client receives PPP CCP Config Request, PPP IPCP Config Request,
    and PPP CHAP Success (in that order).
    Apparently the three packets have been re-ordered on their way across
    the network,
    so that the PPP CHAP Success arrives after the other two.

    Client appears to ignore the PPP CHAP Success.

    (Client also ignores the PPP CCP Config Request, PPP PPP IPCP Config
    Request.
    I assume that's because the client still thinks its doing
    authentication.)

    Loop:

    1) Client retransmits its PPP CHAP Response about 3 seconds after
    it last sent this packet.

    2) When server receives the retransmitted PPP CHAP Response,
    it logs an error "PPP_AuthLogErr() illegal fsm event received".
    Server does *not* retransmit PPP CHAP Success.

    3) Server retransmits its PPP IPCP Config Request and PPP CCP Config
    Request,
    each about 3 seconds after it last sent each packet.

    4) Client ignores the retransmitted PPP IPCP Config Request and
    PPP CCP Config Request.


    We remain in this loop until the server's timed and out retransmitted
    its
    PPP IPCP Config Request and PPP CCP Config Request several times (about
    30 seconds total). The server tears down the connection by sending
    a PPTP Call-Clear-Request.

    --

    I don't know why the client ignored the PPP CHAP Success message.
    (My guess is that there is a client bug causing this, perhaps triggered
    by the arrival of the PPP IPCP Config Request and PPP CCP Config
    Request
    messages before the arrival of the PPP CHAP Success message.
    Since this client (Mac OS X 10.3.7) doesn't seem to provide a way to
    enable really detailed debugging of the PPTP client, I can't tell.)

    But that's not the problem I'm trying to diagnose here.

    What I'm trying to understand is: is it correct for the server to
    ignore the
    retransmitted PPP CHAP Response it receives from the client?
    Shouldn't each trigger the server to retransmit the PPP CHAP Success?
    The "PPP_AuthLogErr() illegal fsm event received" logged by the client
    suggests to me that the client doesn't believe it's acceptable
    for it to receive a PPP CHAP Response at this point in the
    conversation.

    --

    I don't see anything in RFC2759 (MS-CHAPv2) or RFC2433 (MS-CHAP).
    RFC1994 (PPP CHAP) section 4.1 does seem to address this directly:

    "Whenever a Response packet is received, the authenticator compares
    the Response
    Value with its own calculation of the expected value. Based on this
    comparison,
    the authenticator MUST send a Success or Failure packet (described
    below).

    Implementation Notes: Because the Success might be lost, the
    authenticator MUST
    allow repeated Response packets during the Network-Layer Protocol
    phase after
    completing the Authentication phase. To prevent discovery of
    alternative Names
    and Secrets, any Response packets received having the current
    Challenge
    Identifier MUST return the same reply Code previously returned for
    that specific
    Challenge (the message portion MAY be different). Any Response
    packets received
    during any other phase MUST be silently discarded."

    It seems to me that this says the server should indeed accept the PPP
    CHAP Response
    the client retransmitted (unless there were something wrong with it),
    and
    retransmit a PPP CHAP Success.
    Have I got that right? Or am I confused?

    --


  2. Re: should retransmitted PPP CHAP Response trigger retransmitted PPP CHAP Success?

    "Irwin Tillman" writes:
    > I have a situation where a PPTP client (Mac OS X 10.3.7) is usually
    > failing to connect
    > to a PPTP server (cisco VPN 3030, software 4.1.7C)
    >
    > The server requires the client to authenticate using MS-CHAPv2.
    >
    > It appears the client ignores the PPP CHAP Success message sent by the
    > server.
    > (I'm unclear why, and this may be a client bug, but this isn't what
    > I'm interested in here.)


    I think you probably should be interested in it. MS-CHAPv2 includes
    "S=" in its proprietary Success message format. This
    *must* be authenticated by the client.

    If the client is ignoring the MS-CHAPv2 Success message, I'd bet that
    either the authenticator is wrong or the client has a bug in handling
    authentication.

    > At this point, although the server has started IPCP and CCP
    > negotiation,
    > the client is still trying to complete authentication.
    > Since the client feels it hasn't received a PPP CHAP Success message
    > yet,
    > it keeps retransmitting its last PPP CHAP Response message.
    > The server sees that message, and decides to NOT respond to it.


    Heh.

    > My question is: should the server ignore the retransmitted PPP CHAP
    > Response messages
    > received while it believes it is negotiating IPCP and CCP?
    > It seems to me that each should trigger the server to retransmit the
    > PPP CHAP Success message.


    There's unfortunately just no standard.

    RFC 2759 (Informational, not Standards-Track) describes MS-CHAPv2.
    It's a proprietary protocol, and was *NOT* subjected to any sort of
    peer review within the IETF. It was just published as an individual
    submission.

    Informational RFCs vary widely in quality, but the key attribute of
    them is that they're not subjected to the usual sorts of review and
    independent implementation tests. This means that if there are holes
    in the protocol, that's just too bad.

    In the case of MS-CHAPv2, as best I can tell, it's not defined what
    the client should do if it misses the special Success message. I
    think resending the Response is somewhat reasonable, *although* it's
    certainly the case that the design intent of standard CHAP is supposed
    to have it be driven by the authenticator (not authenticatee), and
    thus retransmitting a Response message is a little strange (though
    still legal).

    If I were implementing it, I'd be tempted to build in a timeout on the
    client side and just shut down the link if the timer went off *or* if
    any illegal MS-CHAPv2 Success message (bad authenticator) were seen.
    There's little else (other than perhaps restarting LCP) that can be
    done.

    CHAP should probably just never have been twisted in this direction.

    > Client receives PPP CCP Config Request, PPP IPCP Config Request,
    > and PPP CHAP Success (in that order).
    > Apparently the three packets have been re-ordered on their way across
    > the network,
    > so that the PPP CHAP Success arrives after the other two.


    That part's fine.

    > Client appears to ignore the PPP CHAP Success.


    That's broken.

    > (Client also ignores the PPP CCP Config Request, PPP PPP IPCP Config
    > Request.


    That part is fine -- the other side will resend.

    > 1) Client retransmits its PPP CHAP Response about 3 seconds after
    > it last sent this packet.


    That seems ok, but see above.

    > 2) When server receives the retransmitted PPP CHAP Response,
    > it logs an error "PPP_AuthLogErr() illegal fsm event received".
    > Server does *not* retransmit PPP CHAP Success.


    Heh.

    > 3) Server retransmits its PPP IPCP Config Request and PPP CCP Config
    > Request,
    > each about 3 seconds after it last sent each packet.


    That's correct.

    > 4) Client ignores the retransmitted PPP IPCP Config Request and
    > PPP CCP Config Request.


    Assuming the client never got the MS-CHAPv2 message it wanted, that's
    correct.

    > I don't know why the client ignored the PPP CHAP Success message.
    > (My guess is that there is a client bug causing this, perhaps triggered
    > by the arrival of the PPP IPCP Config Request and PPP CCP Config
    > Request
    > messages before the arrival of the PPP CHAP Success message.


    That's entirely possible. Implementation bugs are not uncommon.

    > Since this client (Mac OS X 10.3.7) doesn't seem to provide a way to
    > enable really detailed debugging of the PPTP client, I can't tell.)
    >
    > But that's not the problem I'm trying to diagnose here.


    Er ... it's the one I'd be worried about.

    > What I'm trying to understand is: is it correct for the server to
    > ignore the
    > retransmitted PPP CHAP Response it receives from the client?


    Sure. In at least standard CHAP, there's no actual reason for the
    client to retransmit anything. (You can just drive on if you receive
    any NCP messages as though you got CHAP Success. You don't have to
    wait for CHAP Success at all.)

    > Shouldn't each trigger the server to retransmit the PPP CHAP Success?
    > The "PPP_AuthLogErr() illegal fsm event received" logged by the client
    > suggests to me that the client doesn't believe it's acceptable
    > for it to receive a PPP CHAP Response at this point in the
    > conversation.


    It does seem a bit draconian to me. The server ought to be more
    lenient to allow for compatibility. Compatibility is always more
    important than *anything* the documents have to say.

    > It seems to me that this says the server should indeed accept the PPP
    > CHAP Response
    > the client retransmitted (unless there were something wrong with it),
    > and
    > retransmit a PPP CHAP Success.
    > Have I got that right? Or am I confused?


    That's right ... it should. But it sounds to me like something else
    is wrong here.

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

+ Reply to Thread