Can I execute a script _after_ PAP authentication is complete? - PPP

This is a discussion on Can I execute a script _after_ PAP authentication is complete? - PPP ; I'm using mgetty to answer the phone for a dial-in PPP connection. It recognizes caller ID and puts the caller's phone number in $CALLER_ID. So far so good. I want to set up security based on the combination of caller's ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: Can I execute a script _after_ PAP authentication is complete?

  1. Can I execute a script _after_ PAP authentication is complete?

    I'm using mgetty to answer the phone for a dial-in PPP connection. It
    recognizes caller ID and puts the caller's phone number in $CALLER_ID.
    So far so good.

    I want to set up security based on the combination of caller's phone
    number and user name but the program invoked by /AutoPPP/ in mgetty's
    login.config doesn't know the user. If I put the PPP users into
    /etc/passwd, I could use login and a custom shell which checked the
    user ID and caller ID and acted accordingly. But I'd really prefer to
    keep my PPP users and system users separate so I have my PPP users only
    in pap-secrets (and I use papcrypt and require-pap in my options file).

    So, it there any way to have a script invoked _after_ PAP
    authentication? Presumably at that point, CALLER_ID would still be in
    the environment and, I'd hope, the PPP user name would be available
    somehow so I could act on the combination of those two values.

    Chris


  2. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > So, it there any way to have a script invoked _after_ PAP
    > authentication? Presumably at that point, CALLER_ID would still be in
    > the environment and, I'd hope, the PPP user name would be available
    > somehow so I could act on the combination of those two values.


    There are at least two ways to do this. One is listed in the pppd man
    page -- see the "/etc/ppp/auth-up" script.

    The other is to write a program (a "plugin" dynamically linked module)
    that uses the existing 'pap_auth_hook' feature in pppd.

    I suspect it's really this latter one that you'll want to use.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: Can I execute a script _after_ PAP authentication is complete?

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > So, it there any way to have a script invoked _after_ PAP
    > > authentication? Presumably at that point, CALLER_ID would still be in
    > > the environment and, I'd hope, the PPP user name would be available
    > > somehow so I could act on the combination of those two values.

    >
    > There are at least two ways to do this.


    At least. I found a third, possibily kludgey way: ip-up. ;-)

    > One is listed in the pppd man page -- see the "/etc/ppp/auth-up" script.


    Thanks. I found that now. I was looking in the Files section, not
    Scripts.

    > The other is to write a program (a "plugin" dynamically linked module)
    > that uses the existing 'pap_auth_hook' feature in pppd.
    >
    > I suspect it's really this latter one that you'll want to use.


    Why the latter? Building a binary plug-in seems a *lot* more work than
    writing a script. Is it just that it's a more secure mechanism (the
    code can't be read, even if the file can be seen)? Also, while I said
    "after PAP authentication" I really meant just authentication; I'm
    using PAP now but I'd rather be flexible in case I add/use another
    method later.

    It seems to me that by using ip-up, I can secure against
    misconfiguration or hacking so that if someone gets in without
    authentication I can trap it and drop the link in ip-up. If I put my
    code in auth-up then if noauth gets into the mix my code won't get
    executed. Right?

    So this is what I've done. Since ip-up "runs in a deliberately
    restricted environment to enhance security" (http://tinyurl.com/nx2dg),
    I had to do some calisthenics to get CALLER_ID from mgetty to ip-up. I
    added two lines to the standard /etc/ppp/ppplogin:

    #!/bin/sh
    stty -echo
    echo "CALLER_ID=$CALLER_ID;export CALLER_ID" >/etc/ppp/cid.$DEVICE
    /usr/sbin/pppd silent auth -chap +pap
    rm /etc/ppp/cid.$DEVICE

    I haven't yet coded the logic to act on the information but so far my
    ip-up has:

    #!/bin/sh
    . /etc/ppp/cid.`basename $DEVICE`
    echo "Remote user \"$PEERNAME\" logged in from phone number
    \"$CALLER_ID\""

    I imagine the same code could be in auth-up.

    Chris


  4. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > > > authentication? Presumably at that point, CALLER_ID would still be in
    > > > the environment and, I'd hope, the PPP user name would be available
    > > > somehow so I could act on the combination of those two values.

    [...]
    > > I suspect it's really this latter one that you'll want to use.

    >
    > Why the latter? Building a binary plug-in seems a *lot* more work than
    > writing a script. Is it just that it's a more secure mechanism (the
    > code can't be read, even if the file can be seen)? Also, while I said


    No, that's not the reason.

    The reason is that it sounds like you want to make the access decision
    based on a combination of factors -- the authentication data supplied
    by the peer *plus* some additional factors.

    In order to do that correctly, you need to be synchronous with the
    rest of the framework operation. If you use auth-up (or, worse,
    ip-up), then the "bad" user who authenticates correctly but is calling
    from the wrong location will be able to gain access for a short period
    of time before your script runs, you find the problem, and you kill
    off the connection.

    You're introducing an unnecessary race condition.

    > "after PAP authentication" I really meant just authentication; I'm
    > using PAP now but I'd rather be flexible in case I add/use another
    > method later.


    Sure. auth-up works for both, though it's not what you really need
    here.

    > It seems to me that by using ip-up, I can secure against
    > misconfiguration or hacking so that if someone gets in without
    > authentication I can trap it and drop the link in ip-up. If I put my
    > code in auth-up then if noauth gets into the mix my code won't get
    > executed. Right?


    How exactly does "noauth" get "into the mix?" It needs to be added by
    someone with root privileges -- all of the files that can specify that
    option are writable only by root. If it's getting "into the mix," I
    think it means that you have a root user who is vandalizing the
    system. All bets are off if that happens, as such a user can scribble
    on /dev/kmem.

    In any event, if you want to use it with "noauth" (relying on just
    some external data to authenticate the connection, and nothing else),
    then the same sorts of issues apply, though the regular PAP auth hook
    won't work. I think you'll need to modify the main pppd code to do
    that correctly.

    > echo "CALLER_ID=$CALLER_ID;export CALLER_ID" >/etc/ppp/cid.$DEVICE


    Nit: use /var instead. I also suggest that you just write the value
    itself into the file, and read it back, rather than using "." to
    execute that file. Executing dynamically-created content can be a bit
    hazardous.

    > /usr/sbin/pppd silent auth -chap +pap


    That might not do what you're expecting. "+pap" is the deprecated
    (obsolete) alias of the "require-pap" option. It causes pppd to
    demand PAP from the peer.

    However, "-chap" is "refuse-chap." That means that if the peer asks
    us to identify *ourselves* using CHAP, we'll refuse. Do your clients
    ask your server for authentication? That's not often done.

    The +/- flags here are not at all symmetric in operation.

    Also note that "silent" likely doesn't do anything good here. This
    should *not* have to be done. If it does, then it sounds like there
    are bugs somewhere.

    > I imagine the same code could be in auth-up.


    The problem is (still) that those scripts are fired off by pppd when
    the event occurs, but that the PPP link itself intentionally isn't
    "paused" to wait for them to complete.

    If you're trying to add another authentication factor, this isn't the
    place to do it.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  5. Re: Can I execute a script _after_ PAP authentication is complete?

    James Carlson wrote:
    > "Chris Nelson" writes:
    > The reason is that it sounds like you want to make the access decision
    > based on a combination of factors -- the authentication data supplied
    > by the peer *plus* some additional factors.
    >
    > In order to do that correctly, you need to be synchronous with the
    > rest of the framework operation. ...


    OK. I see what you're saying.

    > > echo "CALLER_ID=$CALLER_ID;export CALLER_ID" >/etc/ppp/cid.$DEVICE

    >
    > Nit: use /var instead.


    OK.

    > I also suggest that you just write the value
    > itself into the file, and read it back, rather than using "." to
    > execute that file. Executing dynamically-created content can be a bit
    > hazardous.


    A valid point. What I showed was an first draft. Thanks.

    >...
    > > I imagine the same code could be in auth-up.

    >
    > The problem is (still) that those scripts are fired off by pppd when
    > the event occurs, but that the PPP link itself intentionally isn't
    > "paused" to wait for them to complete.
    >
    > If you're trying to add another authentication factor, this isn't the
    > place to do it.


    OK. So I'm writing a plugin to set the ppp_auth_hook. My code uses
    stdbool.h which conflicts with pppd.h's bool typedef. Any thoughts...?


  6. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > > If you're trying to add another authentication factor, this isn't the
    > > place to do it.

    >
    > OK. So I'm writing a plugin to set the ppp_auth_hook. My code uses
    > stdbool.h which conflicts with pppd.h's bool typedef. Any thoughts...?


    Two possibilities:

    - split your code into two or more .c files, with dedicated pppd
    glue logic in one file, and the internals of your implementation
    in another, and then 'ld -r' them into a single module.

    - "don't do that" (i.e., just don't use stdbool.h)

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: Can I execute a script _after_ PAP authentication is complete?

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > > If you're trying to add another authentication factor, this isn't the
    > > > place to do it.

    > >
    > > OK. So I'm writing a plugin to set the ppp_auth_hook. My code uses
    > > stdbool.h which conflicts with pppd.h's bool typedef. Any thoughts...?

    >
    > Two possibilities:
    >
    > - split your code into two or more .c files, with dedicated pppd
    > glue logic in one file, and the internals of your implementation
    > in another, and then 'ld -r' them into a single module.


    I guess.

    > - "don't do that" (i.e., just don't use stdbool.h)


    Thanks. :-/

    Is there some reason pppd doesn't use stdbool.h?


    Another question: certain users should be called back. I've got a
    sketch of a ppp_auth_hook that looks like:

    // search my users for a record with a matching user
    // if not found, return NOT_AUTHENTICATED

    // compare passwords
    // if password doesn't match, return NOT_AUTHENTICATED

    // if no callback and no caller id, return AUTHENTICATED

    // if caller ID and numbers don't match, return NOT_AUTHENTICATED

    // if callback
    // FIXME - what to do?

    It seems that even if I'm going to call back, the user is
    authenticated. I can use system() to invoke another program to call
    back but I don't quite see how to make pppd drop the line. I don't
    think the idle hook would come into play but maybe I don't understand
    it yet.


  8. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > Thanks. :-/
    >
    > Is there some reason pppd doesn't use stdbool.h?


    It's historical: pppd greatly predates that file being part of any
    standard (as well as Linux and a number of other things). It's still
    that way as a portability issue, but if someone wanted to work through
    those issues and contribute well-tested fixes, I'm sure we'd be happy
    to have them.

    > Another question: certain users should be called back. I've got a
    > sketch of a ppp_auth_hook that looks like:


    For what it's worth, we have _only_ the client portion of Microsoft's
    proprietary CBCP in pppd. If you need the server side of CBCP, you'll
    need to do more work here.

    > It seems that even if I'm going to call back, the user is
    > authenticated. I can use system() to invoke another program to call
    > back but I don't quite see how to make pppd drop the line. I don't
    > think the idle hook would come into play but maybe I don't understand
    > it yet.


    No, none of that will work. pppd just isn't currently designed to do
    the server side of callback.

    There are at least two ways this can be done.

    - Classic callback comes in two minor flavors:

    - One involves just noting the calling party information, waiting
    a few moments, and then calling that party back. There's just
    one PPP link, and no authentication (other than the telco-
    supplied calling party data, if you trust that) on the
    initiating dial.

    - The other involves doing the authentication (and authorization)
    checks (PPP or otherwise), dropping the line, waiting a couple
    of seconds for the telephone link to recover, and then
    initiating a regular call back to the user.

    - Windows proprietary callback involves doing the same, but then
    running CBCP negotiation after authenticating but before dropping
    the link. After doing CBCP, you hang up, wait a while, and then
    call the user back. I think you're supposed to avoid doing CBCP
    on the callback itself.

    In any case, you should redo the authentication on the callback, so
    that if the telephone link is compromised, you don't accidentally
    allow an attacker in without authentication.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  9. Re: Can I execute a script _after_ PAP authentication is complete?

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > Thanks. :-/
    > >
    > > Is there some reason pppd doesn't use stdbool.h?

    >
    > It's historical: pppd greatly predates that file being part of any
    > standard (as well as Linux and a number of other things). It's still
    > that way as a portability issue, but if someone wanted to work through
    > those issues and contribute well-tested fixes, I'm sure we'd be happy
    > to have them.


    Not this week.

    > > Another question: certain users should be called back. I've got a
    > > sketch of a ppp_auth_hook that looks like:

    > ...
    > > It seems that even if I'm going to call back, the user is
    > > authenticated. I can use system() to invoke another program to call
    > > back but I don't quite see how to make pppd drop the line. I don't
    > > think the idle hook would come into play but maybe I don't understand
    > > it yet.

    >
    > No, none of that will work. pppd just isn't currently designed to do
    > the server side of callback.
    >
    > There are at least two ways this can be done.
    >
    > - Classic callback comes in two minor flavors:
    >
    > - One involves just noting the calling party information, waiting
    > a few moments, and then calling that party back. There's just
    > one PPP link, and no authentication (other than the telco-
    > supplied calling party data, if you trust that) on the
    > initiating dial.
    >
    > - The other involves doing the authentication (and authorization)
    > checks (PPP or otherwise), dropping the line, waiting a couple
    > of seconds for the telephone link to recover, and then
    > initiating a regular call back to the user.
    > ...


    I don't understand "none of that will work" unless you mean that the
    idle hook isn't relevant.

    I was thinking along the lines of your second suggestion above. My
    problem is in dropping the line. If I return AUTHENTICATED (1) from my
    ppp_auth_hook, pppd isn't going to drop the line and if I return
    NOT_AUTHENTICATED (0), then pppd's going to lie to the caller and say
    authentication failed, no? Or is pppd going to send *msgp to the
    caller so I can do something like

    strcpy(*msgp, "Authorization succeeded. Stand-by for callback");
    return 0; // Pretend authenication failed so pppd hangs up.

    ?

    > In any case, you should redo the authentication on the callback, so
    > that if the telephone link is compromised, you don't accidentally
    > allow an attacker in without authentication.


    Yes, of course. Which leaves me with the problem -- with a symetric
    protocol like PAP -- of determining whether this all of pap_auth_hook
    is for an incoming or outgoing call.


  10. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > I don't understand "none of that will work" unless you mean that the
    > idle hook isn't relevant.


    Right; that's what I mean.

    > I was thinking along the lines of your second suggestion above. My
    > problem is in dropping the line. If I return AUTHENTICATED (1) from my
    > ppp_auth_hook, pppd isn't going to drop the line and if I return
    > NOT_AUTHENTICATED (0), then pppd's going to lie to the caller and say
    > authentication failed, no? Or is pppd going to send *msgp to the
    > caller so I can do something like
    >
    > strcpy(*msgp, "Authorization succeeded. Stand-by for callback");
    > return 0; // Pretend authenication failed so pppd hangs up.


    Ick!

    No, I was suggesting modifying pppd itself because the plugin doesn't
    quite have the right scope to do this correctly.

    You should be sending auth_peer_success() to note the success, and
    then terminating using lcp_close().

    One plausible alternative here would be to return 1 for success, but
    call lcp_close(unit, "Stand by for callback") before returning. That
    should cause pppd to shut down the link without providing any real
    authentication reply to the peer. You'll also need to set up a timer
    that kicks you back into gear to generate the callback. It may be
    possible to do this entirely from within the plugin, but I'd worry a
    bit about the resulting code quality.

    The big issue is with interoperability. You'll have quite a road
    ahead of you working with client implementations on various timing and
    operational scenarios. It's not something that anyone has done yet
    with pppd, and when I worked on similar issues with a commercial
    dial-in platform (I used to work at Xylogics/Bay), I recall it being
    "hard" to get right.

    > > In any case, you should redo the authentication on the callback, so
    > > that if the telephone link is compromised, you don't accidentally
    > > allow an attacker in without authentication.

    >
    > Yes, of course. Which leaves me with the problem -- with a symetric
    > protocol like PAP -- of determining whether this all of pap_auth_hook
    > is for an incoming or outgoing call.


    PAP isn't symmetric. It's asymmetric -- one side (the authenticatee)
    sends PAP Authenticate-Request messages, and the other side (the
    authenticator) sends Authenticate-Ack or -Nak messages.

    The symmetric part is PPP itself, which allows each side to
    authenticate the other, if desired. Typical deployments of PPP,
    though, don't do this, because this isn't what Windows does.

    When doing a call back, it's the caller that usually needs to demand
    authentication.

    Note that pap_auth_hook() is called _ONLY_ on the authenticator's
    side. The other side -- if the peer is authenticating us and we're
    the authenticatee (i.e., the typical call-to-your-ISP case) -- goes
    through pap_passwd_hook.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  11. Re: Can I execute a script _after_ PAP authentication is complete?

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > I was thinking along the lines of your second suggestion above. My
    > > problem is in dropping the line. If I return AUTHENTICATED (1) from my
    > > ppp_auth_hook, pppd isn't going to drop the line and if I return
    > > NOT_AUTHENTICATED (0), then pppd's going to lie to the caller and say
    > > authentication failed, no? Or is pppd going to send *msgp to the
    > > caller so I can do something like
    > >
    > > strcpy(*msgp, "Authorization succeeded. Stand-by for callback");
    > > return 0; // Pretend authenication failed so pppd hangs up.

    >
    > Ick!
    >
    > No, I was suggesting modifying pppd itself because the plugin doesn't
    > quite have the right scope to do this correctly.


    Ick back at ya! I can't get into modifying the daemon at this point.

    > You should be sending auth_peer_success() to note the success, and
    > then terminating using lcp_close().


    auth_peer_success()? Is that what pppd do that if ppp_auth_hook
    returns 1?

    > One plausible alternative here would be to return 1 for success, but
    > call lcp_close(unit, "Stand by for callback") before returning. That
    > should cause pppd to shut down the link without providing any real
    > authentication reply to the peer. You'll also need to set up a timer
    > that kicks you back into gear to generate the callback. It may be
    > possible to do this entirely from within the plugin, but I'd worry a
    > bit about the resulting code quality.


    Or -- and I realize I'm looking at timing issues here -- spawn a thread
    to call lcp_close() a couple of seconds after ppp_auth_hook returns?

    > The big issue is with interoperability. You'll have quite a road
    > ahead of you working with client implementations on various timing and
    > operational scenarios. It's not something that anyone has done yet
    > with pppd, and when I worked on similar issues with a commercial
    > dial-in platform (I used to work at Xylogics/Bay), I recall it being
    > "hard" to get right.


    Just to be sure I understand, the interoperability is with my ppp
    server on one platform and the various clients that may call in (not
    with my implementation moved to other platforms).

    > > > In any case, you should redo the authentication on the callback, so
    > > > that if the telephone link is compromised, you don't accidentally
    > > > allow an attacker in without authentication.

    > >
    > > Yes, of course. Which leaves me with the problem -- with a symetric
    > > protocol like PAP -- of determining whether this all of pap_auth_hook
    > > is for an incoming or outgoing call.

    >
    > PAP isn't symmetric. It's asymmetric -- one side (the authenticatee)
    > sends PAP Authenticate-Request messages, and the other side (the
    > authenticator) sends Authenticate-Ack or -Nak messages.


    Yes. What I meant is that (at least potentially), both sides
    authenticate each other without a clear (overall) client and server
    role.

    > The symmetric part is PPP itself, which allows each side to
    > authenticate the other, if desired. Typical deployments of PPP,
    > though, don't do this, because this isn't what Windows does.


    Sorry. You kinda lost me there. Do you mean that 'Windows doesn't
    authenticate the called system so most PPP installations don't either;
    only the called system validates the peer (the calling system)?

    > When doing a call back, it's the caller that usually needs to demand
    > authentication.
    >
    > Note that pap_auth_hook() is called _ONLY_ on the authenticator's
    > side. The other side -- if the peer is authenticating us and we're
    > the authenticatee (i.e., the typical call-to-your-ISP case) -- goes
    > through pap_passwd_hook.


    But if both authenticate then ppp_auth_hoo() gets called on the
    callback, too. Right?


  12. Re: Can I execute a script _after_ PAP authentication is complete?

    "Chris Nelson" writes:
    > > Ick!
    > >
    > > No, I was suggesting modifying pppd itself because the plugin doesn't
    > > quite have the right scope to do this correctly.

    >
    > Ick back at ya! I can't get into modifying the daemon at this point.


    ;-}

    It's really not _that_ bad.

    > > You should be sending auth_peer_success() to note the success, and
    > > then terminating using lcp_close().

    >
    > auth_peer_success()? Is that what pppd do that if ppp_auth_hook
    > returns 1?


    Yes. auth.c:check_passwd() calls pap_auth_hook(). If that returns
    -1 (plugin uninterested), it continues with normal PAP processing. If
    it returns 0, then that function returns UPAP_AUTHNAK to its caller,
    otherwise, if greater than zero, it returns UPAP_AUTHACK.

    check_passwd is called by upap.c:upap_rauthreq(). For UPAP_AUTHACK,
    it calls auth_peer_success() to tell the state machine that we've
    passed authentication and can continue. For UPAP_AUTHNAK, it calls
    auth_peer_fail() to tell the state machine that we've hit the end of
    the road.

    Note that you may want to set remote_number[] and *permitted_numbers
    from within your plugin, depending on what you're trying to do. (Or
    perhaps they should be set by the command line options.)

    > > One plausible alternative here would be to return 1 for success, but
    > > call lcp_close(unit, "Stand by for callback") before returning. That
    > > should cause pppd to shut down the link without providing any real
    > > authentication reply to the peer. You'll also need to set up a timer
    > > that kicks you back into gear to generate the callback. It may be
    > > possible to do this entirely from within the plugin, but I'd worry a
    > > bit about the resulting code quality.

    >
    > Or -- and I realize I'm looking at timing issues here -- spawn a thread
    > to call lcp_close() a couple of seconds after ppp_auth_hook returns?


    pppd is intentionally a single-threaded design with a event loop. If
    you spawn a separate thread, you're on your own. ;-}

    There's no internal locking on any of the data structures.

    > > The big issue is with interoperability. You'll have quite a road
    > > ahead of you working with client implementations on various timing and
    > > operational scenarios. It's not something that anyone has done yet
    > > with pppd, and when I worked on similar issues with a commercial
    > > dial-in platform (I used to work at Xylogics/Bay), I recall it being
    > > "hard" to get right.

    >
    > Just to be sure I understand, the interoperability is with my ppp
    > server on one platform and the various clients that may call in (not
    > with my implementation moved to other platforms).


    Yes, exactly.

    > > PAP isn't symmetric. It's asymmetric -- one side (the authenticatee)
    > > sends PAP Authenticate-Request messages, and the other side (the
    > > authenticator) sends Authenticate-Ack or -Nak messages.

    >
    > Yes. What I meant is that (at least potentially), both sides
    > authenticate each other without a clear (overall) client and server
    > role.


    That's correct, at least from the protocol point of view.

    In actual deployment, it's different.

    > > The symmetric part is PPP itself, which allows each side to
    > > authenticate the other, if desired. Typical deployments of PPP,
    > > though, don't do this, because this isn't what Windows does.

    >
    > Sorry. You kinda lost me there. Do you mean that 'Windows doesn't
    > authenticate the called system so most PPP installations don't either;
    > only the called system validates the peer (the calling system)?


    Windows (as best I can tell) operates in only two modes: "server" or
    "client." In "server" mode, the peer must be authenticated. In
    "client" mode, the system must offer credentials to the peer. As best
    I can tell, there's no way to tell it to do both.

    > > When doing a call back, it's the caller that usually needs to demand
    > > authentication.
    > >
    > > Note that pap_auth_hook() is called _ONLY_ on the authenticator's
    > > side. The other side -- if the peer is authenticating us and we're
    > > the authenticatee (i.e., the typical call-to-your-ISP case) -- goes
    > > through pap_passwd_hook.

    >
    > But if both authenticate then ppp_auth_hoo() gets called on the
    > callback, too. Right?


    Yes.

    It's more a question of options than of hooks. On the callback, you
    may need to _disable_ authentication via the equivalent of 'noauth'
    (programmatically: setting auth_required to 0) and asserting the known
    peer's identity via the equivalent of 'remotename' (filling in the
    remote_name[] array).

    "May." As I said, I don't think anyone's seriously tried to do what
    you're doing with pppd.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  13. PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    First, thanks, James, for your patient and detailed feedback. I think
    I'm getting somewhere.

    James Carlson wrote:
    > "Chris Nelson" writes:
    > Note that you may want to set remote_number[] and *permitted_numbers
    > from within your plugin, depending on what you're trying to do. (Or
    > perhaps they should be set by the command line options.)


    OK. I'll keep that in mind.

    > ...
    > > Or -- and I realize I'm looking at timing issues here -- spawn a thread
    > > to call lcp_close() a couple of seconds after ppp_auth_hook returns?

    >
    > pppd is intentionally a single-threaded design with a event loop. If
    > you spawn a separate thread, you're on your own. ;-}
    >
    > There's no internal locking on any of the data structures.


    Not to mention that my hook is in a .so and I'd have to find the thread
    library somehow and ... I've given up on that route.

    > ...
    > > > The symmetric part is PPP itself, which allows each side to
    > > > authenticate the other, if desired. Typical deployments of PPP,
    > > > though, don't do this, because this isn't what Windows does.

    > >
    > > Sorry. You kinda lost me there. Do you mean that 'Windows doesn't
    > > authenticate the called system so most PPP installations don't either;
    > > only the called system validates the peer (the calling system)?

    >
    > Windows (as best I can tell) operates in only two modes: "server" or
    > "client." In "server" mode, the peer must be authenticated. In
    > "client" mode, the system must offer credentials to the peer. As best
    > I can tell, there's no way to tell it to do both.


    So my callback mechanism is unlikely to be usable with 'Windows systems
    because if a 'Windows system is set up to dial into my server, it won't
    be prepared to answer my call back. I kinda like that. It simplifies
    my life because I only can/have to implement call back for non-Windows
    callers.

    > > > When doing a call back, it's the caller that usually needs to demand
    > > > authentication.
    > > >
    > > > Note that pap_auth_hook() is called _ONLY_ on the authenticator's
    > > > side. The other side -- if the peer is authenticating us and we're
    > > > the authenticatee (i.e., the typical call-to-your-ISP case) -- goes
    > > > through pap_passwd_hook.

    > >
    > > But if both authenticate then ppp_auth_hoo() gets called on the
    > > callback, too. Right?

    >
    > Yes.
    >
    > It's more a question of options than of hooks. On the callback, you
    > may need to _disable_ authentication via the equivalent of 'noauth'
    > (programmatically: setting auth_required to 0) and asserting the known
    > peer's identity via the equivalent of 'remotename' (filling in the
    > remote_name[] array).
    >
    > "May." As I said, I don't think anyone's seriously tried to do what
    > you're doing with pppd.


    OK. I've played with this some more, decided threads aren't happening,
    and this is what I'm going forward with -- until you tell me I'm nuts
    or I hit a roadblock:

    - I set up a pap-auth-hook and a phase change notifier proc.

    - If my pap-auth-hook determines that this user should be called back,
    it sets a module static with some information about who to call back

    - When the phase change notifier gets called with PHASE_NETWORK _and_
    the module static is set, it calls lcp_close() and spawns a new process
    to do the callback after a suitable delay.

    What do you think?


  14. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    I wrote:
    > ...
    > - When the phase change notifier gets called with PHASE_NETWORK _and_
    > the module static is set, it calls lcp_close() and spawns a new process
    > to do the callback after a suitable delay.
    > ...


    This technique seems to be bolstered by RFC 1570 which says:

    When Callback is successfully negotiated, and authentication is
    complete, the Authentication phase proceeds directly to the
    Termination phase, and the link is disconnected.

    Or am I missing something?


  15. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)


    Chris Nelson wrote:
    > I wrote:
    > > ...
    > > - When the phase change notifier gets called with PHASE_NETWORK _and_
    > > the module static is set, it calls lcp_close() and spawns a new process
    > > to do the callback after a suitable delay.
    > > ...

    >
    > This technique seems to be bolstered by RFC 1570 which says:
    >
    > When Callback is successfully negotiated, and authentication is
    > complete, the Authentication phase proceeds directly to the
    > Termination phase, and the link is disconnected.
    >
    > Or am I missing something?


    Arg, I posted too quickly. I meant to add that maybe my notifier proc
    should react to auth_up, not phase change. I see code in auth.c that
    says the optional CBCP support goes to phase CALLBACK right after
    notifying AUTH_UP.


  16. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    "Chris Nelson" writes:
    > > Windows (as best I can tell) operates in only two modes: "server" or
    > > "client." In "server" mode, the peer must be authenticated. In
    > > "client" mode, the system must offer credentials to the peer. As best
    > > I can tell, there's no way to tell it to do both.

    >
    > So my callback mechanism is unlikely to be usable with 'Windows systems
    > because if a 'Windows system is set up to dial into my server, it won't
    > be prepared to answer my call back. I kinda like that. It simplifies
    > my life because I only can/have to implement call back for non-Windows
    > callers.


    I don't follow.

    Windows does indeed support both server and client side callback.

    What it doesn't support (as best I can tell; I'm no Windows user) is
    negotiating authentication in both directions of a PPP link. It
    negotiates in one direction only. pppd (like most other
    implementations) does not have that limitation.

    > OK. I've played with this some more, decided threads aren't happening,
    > and this is what I'm going forward with -- until you tell me I'm nuts
    > or I hit a roadblock:
    >
    > - I set up a pap-auth-hook and a phase change notifier proc.
    >
    > - If my pap-auth-hook determines that this user should be called back,
    > it sets a module static with some information about who to call back
    >
    > - When the phase change notifier gets called with PHASE_NETWORK _and_
    > the module static is set, it calls lcp_close() and spawns a new process
    > to do the callback after a suitable delay.
    >
    > What do you think?


    That sounds good, provided that you're able to get this process to
    exit in a timely way so that the next one can get access to the serial
    port.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  17. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    "Chris Nelson" writes:
    > I wrote:
    > > ...
    > > - When the phase change notifier gets called with PHASE_NETWORK _and_
    > > the module static is set, it calls lcp_close() and spawns a new process
    > > to do the callback after a suitable delay.
    > > ...

    >
    > This technique seems to be bolstered by RFC 1570 which says:
    >
    > When Callback is successfully negotiated, and authentication is
    > complete, the Authentication phase proceeds directly to the
    > Termination phase, and the link is disconnected.
    >
    > Or am I missing something?


    Only that RFC 1570 describes a particular kind of callback. There are
    many.

    But, yes, that's essentially what's required.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  18. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    "Chris Nelson" writes:
    > Arg, I posted too quickly. I meant to add that maybe my notifier proc
    > should react to auth_up, not phase change. I see code in auth.c that
    > says the optional CBCP support goes to phase CALLBACK right after
    > notifying AUTH_UP.


    You're not referring to identifiers that are in the current code base,
    so that makes it a bit difficult to determine exactly what you're
    doing.

    If you're using new_phase_hook, you should be checking for
    PHASE_NETWORK. This is the point where we know that all of the
    necessary authentication has been performed, but before any network
    layer protocols have started running.

    Something like this:

    static bool callback_required;

    static void
    my_phase_change(int phase)
    {
    if (phase == PHASE_NETWORK && callback_required) {
    lcp_close(0, "Calling you back, %s", peer_authname);
    spawn_off_new_pppd();
    }
    }

    Note, though, that start_networks() just plows on after calling the
    phase change function. This means that you'll have a bit of a mess on
    your hands, as the state machine fur flies. Choices here include
    brutal hacks like this:

    /* we're calling back, so shut the rest down */
    for (protpp = protocols; (protp = *protpp++) != NULL; ) {
    protp->enabled_flag = 0;
    }

    .... or modifiying start_networks() so that it notices when the phase
    doesn't end up as expected.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  19. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    James Carlson wrote:
    > "Chris Nelson" writes:
    > > > Windows (as best I can tell) operates in only two modes: "server" or
    > > > "client." In "server" mode, the peer must be authenticated. In
    > > > "client" mode, the system must offer credentials to the peer. As best
    > > > I can tell, there's no way to tell it to do both.

    > >
    > > So my callback mechanism is unlikely to be usable with 'Windows systems
    > > because if a 'Windows system is set up to dial into my server, it won't
    > > be prepared to answer my call back. I kinda like that. It simplifies
    > > my life because I only can/have to implement call back for non-Windows
    > > callers.

    >
    > I don't follow.
    >
    > Windows does indeed support both server and client side callback.


    Duh! What I was missing was that callback isn't two sessions, it's a
    dial out that knows enough to wait for the return call. I was thinking
    that I'd have to set 'Windows up with a dialout connection _and_ a
    dialin connection and somehow have them coordinated. And I would with
    my home-grown drop-the-line-and-call-back mechanism. Ultimately, I got
    pppd 2.4.4b1 built which seems to have a workable CBCP implementation
    so I have my Linus system acting as a callback client (if that makes
    any sense :-/). There's a CBCP server patch for pppd but it's based on
    2.4.0 and I couldn't find a 2.4.0 base to compare against to merge into
    2.4.4b1 so I gave up on that avenue. (I'd still like to pursue that
    but there's no tag in pppd's CVS repository that looks like "V2_4_0" or
    anything.)

    >...
    > > OK. I've played with this some more, decided threads aren't happening,
    > > and this is what I'm going forward with -- until you tell me I'm nuts
    > > or I hit a roadblock:
    > >
    > > - I set up a pap-auth-hook and a phase change notifier proc.
    > >
    > > - If my pap-auth-hook determines that this user should be called back,
    > > it sets a module static with some information about who to call back
    > >
    > > - When the phase change notifier gets called with PHASE_NETWORK _and_
    > > the module static is set, it calls lcp_close() and spawns a new process
    > > to do the callback after a suitable delay.
    > >
    > > What do you think?

    >
    > That sounds good, provided that you're able to get this process to
    > exit in a timely way so that the next one can get access to the serial
    > port.


    I got the timing to pretty much work but since this approach didn't use
    1570 *or* CBCP, it seems completely incompatible with every other
    system so I abandoned it.


  20. Re: PPPD and callback (was Can I execute a script _after_ PAP authentication is complete?)

    "Chris Nelson" writes:
    > > Windows does indeed support both server and client side callback.

    >
    > Duh! What I was missing was that callback isn't two sessions, it's a
    > dial out that knows enough to wait for the return call. I was thinking
    > that I'd have to set 'Windows up with a dialout connection _and_ a
    > dialin connection and somehow have them coordinated. And I would with
    > my home-grown drop-the-line-and-call-back mechanism. Ultimately, I got


    That's another wrinkle to dial-back.

    On big commercial servers, it's not unusual to have one or two dial-in
    lines and a large number of dial-out lines. This is a helpful thing
    as it avoids glare.

    On smaller systems, using the same line for both dial-in and the
    call-back is common.

    > pppd 2.4.4b1 built which seems to have a workable CBCP implementation
    > so I have my Linus system acting as a callback client (if that makes
    > any sense :-/). There's a CBCP server patch for pppd but it's based on
    > 2.4.0 and I couldn't find a 2.4.0 base to compare against to merge into
    > 2.4.4b1 so I gave up on that avenue. (I'd still like to pursue that
    > but there's no tag in pppd's CVS repository that looks like "V2_4_0" or
    > anything.)


    I haven't heard of any interest in maintaining the server side of
    CBCP.

    > > That sounds good, provided that you're able to get this process to
    > > exit in a timely way so that the next one can get access to the serial
    > > port.

    >
    > I got the timing to pretty much work but since this approach didn't use
    > 1570 *or* CBCP, it seems completely incompatible with every other
    > system so I abandoned it.


    They're pretty much all incompatible. It's the nature of the beast. :-/

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread