pppd plugin development

pppd plugin development

[Greg]

Hi guys,

I'm trying to develop a module that will allow me to authenticate via a 
script.
a simple call to execute script and it's return value says whether or 
not to authenticate.

If someone had already coded something like that, please let me know.
Otherwise, Is there any documentation? (besides the man page)

-- 
Thank you,
Greg Borbonus
*Nix Server administrator

Re: pppd plugin development

[Greg]

I've been able to code a basic plugin. The problem I'm having now is 
that I can't seem to figure out how to retrieve the password from the 
chap_verify_hook.

I've gotten my code to work with the hook, but the password appears to 
be fully encrypted. Does anyone know how I can get the original 
password, or an MD5 version of the password entered?

Thank you,
Greg Borbonus
*Nix Server administrator

On 3/8/2014 10:20 PM, Greg wrote:
> Hi guys,
>
> I'm trying to develop a module that will allow me to authenticate via 
> a script.
> a simple call to execute script and it's return value says whether or 
> not to authenticate.
>
> If someone had already coded something like that, please let me know.
> Otherwise, Is there any documentation? (besides the man page)
>

PPPD plugin development

[Greg]

hey guys,

as stated before, I'm trying to write a plugin to authenticate against 
an external script. So far, I've only managed to get it to write a bit 
information to a log file on the server.

I'm trying to use the digest->code to determine the type of digest used. 
I figured that if I can find out which type it's using then I could then 
move forward with converting it or determining how to store the 
encrypted password to do a comparison.

I've also made it return 1 so that no matter what I enter, it should 
show authenticated.

digest->code writes as blank.
When using it as a switch->case scenario, it goes to default:
switch (digest->code) {
         case CHAP_MICROSOFT:
         {
           codemess = "MIC";
         }
         case CHAP_MICROSOFT_V2:
         {
           codemess = "MV2";
         }
         default:
           codemess = "Default";
}


The return 1 appears to work, but then I get the message:
MPPE required, but keys are not available.  Possible plugin problem?


I REALLY wish this was a documented better. Though I code in other 
scripting languages, C is not something I'm used to coding. So please 
feel free to give me a hard time, I'm muddling my way through C just to 
get the basics right.


-- 
Thank you,
Greg Borbonus
*Nix Server administrator

Re: PPPD plugin development

[James Carlson]

On 03/10/14 08:31, Greg wrote:
> as stated before, I'm trying to write a plugin to authenticate against
> an external script. So far, I've only managed to get it to write a bit
> information to a log file on the server.

It would help if you could provide details -- the code you're using, the
debug log messages, the configuration options in use, and any other
information related to your system.

At this point, I'm not even really sure whether you're attempting to
write authenticator or authenticatee code.  The two are different.
Details on the problem to be solved would help -- "authenticate against
an external script" is a chosen solution to some issue, not a problem
statement.

> I'm trying to use the digest->code to determine the type of digest used.
> I figured that if I can find out which type it's using then I could then
> move forward with converting it or determining how to store the
> encrypted password to do a comparison.

digest->code will have the PPP code number for the digest type, which
will be CHAP_MD5 (0x05), CHAP_MICROSOFT (0x80), or CHAP_MICROSOFT_V2 (0x81).

You can see all of the registered chap_digest_type objects by grepping
the code for chap_register_digest.

I don't believe it can end up being anything else, given the current design.

> I've also made it return 1 so that no matter what I enter, it should
> show authenticated.
> 
> digest->code writes as blank.

"writes"?

> When using it as a switch->case scenario, it goes to default:
> switch (digest->code) {
>         case CHAP_MICROSOFT:
>         {
>           codemess = "MIC";
>         }
>         case CHAP_MICROSOFT_V2:
>         {
>           codemess = "MV2";
>         }
>         default:
>           codemess = "Default";
> }

At a guess, that should mean that digest->code is CHAP_MD5, though I'm
really not sure without more information.  A debug trace would likely
show more, as would a copy of your code.

> The return 1 appears to work, but then I get the message:
> MPPE required, but keys are not available.  Possible plugin problem?

If you return 1 when MS-CHAP is enabled, then you're required to set up
keys and set the mppe_keys_set flag.  It's a bit ugly, but MPPE and
MS-CHAP are deeply intertwined.

> I REALLY wish this was a documented better. Though I code in other
> scripting languages, C is not something I'm used to coding. So please
> feel free to give me a hard time, I'm muddling my way through C just to
> get the basics right.

The plug-in interface just is not designed for use by someone without a
deep understanding of the existing code and a healthy amount of C
experience.  I somewhat doubt that a plug-in shared library type
interface, regardless of the depth of the documentation, could get
around that.

Normally, when folks want to do external authentication, they do it with
RADIUS or some other AAA protocol like that.  It might help to know what
problem you're trying to solve.

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

Re: PPPD plugin development

[Greg]

[-- Attachment #1: Type: text/plain, Size: 3820 bytes --]

I'm attempting to authenticate a user who is trying to connect to pptp 
via an external means.

They would sign up on the site and have the username and password stored 
in a database(I do not want direct database access).  The password would 
be encrypted(MD5).


On 3/10/2014 9:01 AM, James Carlson wrote:
> On 03/10/14 08:31, Greg wrote:
>> as stated before, I'm trying to write a plugin to authenticate against
>> an external script. So far, I've only managed to get it to write a bit
>> information to a log file on the server.
> It would help if you could provide details -- the code you're using, the
> debug log messages, the configuration options in use, and any other
> information related to your system.
>
> At this point, I'm not even really sure whether you're attempting to
> write authenticator or authenticatee code.  The two are different.
> Details on the problem to be solved would help -- "authenticate against
> an external script" is a chosen solution to some issue, not a problem
> statement.
I'm attempting to write an authenticator on the server itself.

As for the debugging, how can I provide that for you?

The code is attached.


>> I'm trying to use the digest->code to determine the type of digest used.
>> I figured that if I can find out which type it's using then I could then
>> move forward with converting it or determining how to store the
>> encrypted password to do a comparison.
> digest->code will have the PPP code number for the digest type, which
> will be CHAP_MD5 (0x05), CHAP_MICROSOFT (0x80), or CHAP_MICROSOFT_V2 (0x81).
>
> You can see all of the registered chap_digest_type objects by grepping
> the code for chap_register_digest.
>
> I don't believe it can end up being anything else, given the current design.
It's empty.

>> I've also made it return 1 so that no matter what I enter, it should
>> show authenticated.
>>
>> digest->code writes as blank.
> "writes"?
I'm writing the output of the variables to a file.
I've tried writing the value of digest->code to a file. it's empty or 
being interpreted in such a way that it's not writing anything to the file.


>
>> When using it as a switch->case scenario, it goes to default:
>> switch (digest->code) {
>>          case CHAP_MICROSOFT:
>>          {
>>            codemess = "MIC";
>>          }
>>          case CHAP_MICROSOFT_V2:
>>          {
>>            codemess = "MV2";
>>          }
>>          default:
>>            codemess = "Default";
>> }
> At a guess, that should mean that digest->code is CHAP_MD5, though I'm
> really not sure without more information.  A debug trace would likely
> show more, as would a copy of your code.
I missed that one, but added it to the check and it to still shows default.
>> The return 1 appears to work, but then I get the message:
>> MPPE required, but keys are not available.  Possible plugin problem?
> If you return 1 when MS-CHAP is enabled, then you're required to set up
> keys and set the mppe_keys_set flag.  It's a bit ugly, but MPPE and
> MS-CHAP are deeply intertwined.
>
>> I REALLY wish this was a documented better. Though I code in other
>> scripting languages, C is not something I'm used to coding. So please
>> feel free to give me a hard time, I'm muddling my way through C just to
>> get the basics right.
> The plug-in interface just is not designed for use by someone without a
> deep understanding of the existing code and a healthy amount of C
> experience.  I somewhat doubt that a plug-in shared library type
> interface, regardless of the depth of the documentation, could get
> around that.
>
> Normally, when folks want to do external authentication, they do it with
> RADIUS or some other AAA protocol like that.  It might help to know what
> problem you're trying to solve.
>

Thank you,
Greg Borbonus
*Nix Server administrator


[-- Attachment #2: external_auth.c.txt --]
[-- Type: text/plain, Size: 1877 bytes --]

#include "pppd.h"
#include "chap-new.h"
#include "chap_ms.h"
#ifdef MPPE
#include "md5.h"
#endif
#include "fsm.h"
#include "ipcp.h"
#include <syslog.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
#include <ctype.h>

/**
        static int external_chap_check(void);
        static int external_chap_verify(char *user, char *ourname, int id,
                    struct chap_digest_type *digest,
                    unsigned char *challenge,
                    unsigned char *response,
                    char *message, int message_space);
**/
        static int external_chap_check(void){
          return 1;
        }
        static int external_auth_hook(char *user, char *ourname, int id,
                    struct chap_digest_type *digest,
                    unsigned char *challenge,
                    unsigned char *response,
                    char *message, int message_space)
        {
char *codemess;
switch (digest->code) {
        case CHAP_MICROSOFT:
        {
          codemess = "MIC";
        }
        case CHAP_MICROSOFT_V2:
        {
          codemess = "MV2";
        }
        case CHAP_MD5:
        {
          codemess = "MD5";
        }
        default:
          codemess = "Default";
}

        FILE *f = fopen("/tmp/auth.pppd.log", "w");
if (f == NULL)
{
    printf("Error opening file!\n");
    exit(1);
}



fprintf(f, "User: %s\n", user);
fprintf(f, "Challenge: %s\n",challenge);
fprintf(f, "Response: %s\n", response);
fprintf(f, "CODE: %s\n",codemess);

fclose(f);


        return 1;
        }


void plugin_init(void) {
        dbglog("PLUGIN: Initializing authenticaton plugin.");


        chap_check_hook=external_chap_check;
        chap_verify_hook=external_auth_hook;

        return;
}

Re: PPPD plugin development

[James Carlson]

On 03/10/14 10:23, Greg wrote:
> I'm attempting to authenticate a user who is trying to connect to pptp
> via an external means.
> 
> They would sign up on the site and have the username and password stored
> in a database(I do not want direct database access).  The password would
> be encrypted(MD5).

MD5 isn't encryption.  It's hashing.  The big difference is that hashes
are (by design) not reversible.

What you're describing just cannot be done because it's architecturally
flawed.  PAP, by design, passes the raw password on the wire, which
means that the recipient (the authenticator) can do the usual sort of
hashed password comparison: look up the stored hashed password, compute
a hash based on the input, and compare results.

CHAP doesn't work that way.  With CHAP, the authenticator presents a
Challenge to the authenticatee.  That authenticatee then computes a hash
and sends it back.  The authenticator then must look up the CLEAR TEXT
passphrase, compute a hash based on the CLEAR TEXT and the challenge,
and compare results.

Note that important part in the previous paragraph: with PAP, the server
need not store the original password, but with CHAP, it MUST.  This is
exactly how it's designed.  See RFC 1994.

Of course, MS-CHAP is a little different.  What it does is compute an
intermediate passphrase based on an MD4 (not MD5) hash of what the user
believes to be the password.  This intermediate passphrase is then used
as the actual passphrase for the challenge/response handshake.  (Indeed,
there's no need for either side to know the original user's password;
storing just the intermediate value works as well.  You can do the same
with regular CHAP so why the MD4 part is written into the protocol is
beyond me.  Individual submissions are strange like that.)

I guess that whoever designed that database didn't take that wrinkle
into account.

That issue aside, PPTP as I understand it generally requires the MS-CHAP
variant and MPPE.  So, if you're the autenticator, you should have
"require-mschap" or (more likely) "require-mschapv2", plus
"require-mppe" among your configuration options.

> I'm attempting to write an authenticator on the server itself.
> 
> As for the debugging, how can I provide that for you?

Text works.  Use the "debug" option and make sure that syslog
"daemon.debug" is directed to a file.

Or if syslog isn't an option for some reason, then use the "logfile
/tmp/pppd.log" option to direct the log messages to the specified file.
 (You can choose any file name you like, of course.)

> The code is attached.

In your code, "challenge" and "response" are not strings, so printing
them that way (even for debug) isn't going to work so well.  These are
arrays of bytes.

>> I don't believe it can end up being anything else, given the current
>> design.
> It's empty.

I still don't understand.  Integers aren't "empty."

>>> I've also made it return 1 so that no matter what I enter, it should
>>> show authenticated.
>>>
>>> digest->code writes as blank.
>> "writes"?
> I'm writing the output of the variables to a file.
> I've tried writing the value of digest->code to a file. it's empty or
> being interpreted in such a way that it's not writing anything to the file.

Does the file get created at all?  If so, does it have zero length?

Not writing anything to the file doesn't suggest that digest->code is
empty.  It suggests that something in your code is falling apart.

There's at least one obvious bug here: that switch statement doesn't
work because it lacks "break;" between the cases.  Thus, everything
falls down to just "Default."  Instead of this:

        case CHAP_MICROSOFT:
        {
          codemess = "MIC";
        }
        case CHAP_MICROSOFT_V2:
        {
          codemess = "MV2";
        }
        case CHAP_MD5:
        {
          codemess = "MD5";
        }
        default:
          codemess = "Default";
}

Try this:

        case CHAP_MICROSOFT:
        {
          codemess = "MIC"; break;
        }
        case CHAP_MICROSOFT_V2:
        {
          codemess = "MV2"; break;
        }
        case CHAP_MD5:
        {
          codemess = "MD5"; break;
        }
        default:
          codemess = "Default";
}

I don't know what else might be wrong.

For what it's worth, I suggest using the logging functions in util.c
(fatal, error, warn, notice, info, dbglog) rather than rolling your own
with fprintf.  Even with "just" debug code, I think it's easier to use
the existing infrastructure.

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

Re: PPPD plugin development

[Greg]

Thanks guys for help. James you have especially helped.

Update: I've managed to get everything working. I had to ditch the 
notion of stored password hashes and went with an encrypted password 
with salts.

Ran into an issue with allowed ips, but quickly fixed that with a 
function within the plugin.

One last thing left to do, I need to execute a function when the user 
disconnects. I believe I need to use the "add_notifier" function and set 
"ip_down_notifier" to a local function within the plugin.

Does anyone know how I might obtain the username from that function? It 
seems the notifier functions are used even less than the verify hook 
I've been working with.

Thank you,
Greg Borbonus
*Nix Server administrator

On 3/10/2014 10:14 AM, James Carlson wrote:
> On 03/10/14 10:23, Greg wrote:
>> I'm attempting to authenticate a user who is trying to connect to pptp
>> via an external means.
>>
>> They would sign up on the site and have the username and password stored
>> in a database(I do not want direct database access).  The password would
>> be encrypted(MD5).
> MD5 isn't encryption.  It's hashing.  The big difference is that hashes
> are (by design) not reversible.
>
> What you're describing just cannot be done because it's architecturally
> flawed.  PAP, by design, passes the raw password on the wire, which
> means that the recipient (the authenticator) can do the usual sort of
> hashed password comparison: look up the stored hashed password, compute
> a hash based on the input, and compare results.
>
> CHAP doesn't work that way.  With CHAP, the authenticator presents a
> Challenge to the authenticatee.  That authenticatee then computes a hash
> and sends it back.  The authenticator then must look up the CLEAR TEXT
> passphrase, compute a hash based on the CLEAR TEXT and the challenge,
> and compare results.
>
> Note that important part in the previous paragraph: with PAP, the server
> need not store the original password, but with CHAP, it MUST.  This is
> exactly how it's designed.  See RFC 1994.
>
> Of course, MS-CHAP is a little different.  What it does is compute an
> intermediate passphrase based on an MD4 (not MD5) hash of what the user
> believes to be the password.  This intermediate passphrase is then used
> as the actual passphrase for the challenge/response handshake.  (Indeed,
> there's no need for either side to know the original user's password;
> storing just the intermediate value works as well.  You can do the same
> with regular CHAP so why the MD4 part is written into the protocol is
> beyond me.  Individual submissions are strange like that.)
>
> I guess that whoever designed that database didn't take that wrinkle
> into account.
>
> That issue aside, PPTP as I understand it generally requires the MS-CHAP
> variant and MPPE.  So, if you're the autenticator, you should have
> "require-mschap" or (more likely) "require-mschapv2", plus
> "require-mppe" among your configuration options.
>
>> I'm attempting to write an authenticator on the server itself.
>>
>> As for the debugging, how can I provide that for you?
> Text works.  Use the "debug" option and make sure that syslog
> "daemon.debug" is directed to a file.
>
> Or if syslog isn't an option for some reason, then use the "logfile
> /tmp/pppd.log" option to direct the log messages to the specified file.
>   (You can choose any file name you like, of course.)
>
>> The code is attached.
> In your code, "challenge" and "response" are not strings, so printing
> them that way (even for debug) isn't going to work so well.  These are
> arrays of bytes.
>
>>> I don't believe it can end up being anything else, given the current
>>> design.
>> It's empty.
> I still don't understand.  Integers aren't "empty."
>
>>>> I've also made it return 1 so that no matter what I enter, it should
>>>> show authenticated.
>>>>
>>>> digest->code writes as blank.
>>> "writes"?
>> I'm writing the output of the variables to a file.
>> I've tried writing the value of digest->code to a file. it's empty or
>> being interpreted in such a way that it's not writing anything to the file.
> Does the file get created at all?  If so, does it have zero length?
>
> Not writing anything to the file doesn't suggest that digest->code is
> empty.  It suggests that something in your code is falling apart.
>
> There's at least one obvious bug here: that switch statement doesn't
> work because it lacks "break;" between the cases.  Thus, everything
> falls down to just "Default."  Instead of this:
>
>          case CHAP_MICROSOFT:
>          {
>            codemess = "MIC";
>          }
>          case CHAP_MICROSOFT_V2:
>          {
>            codemess = "MV2";
>          }
>          case CHAP_MD5:
>          {
>            codemess = "MD5";
>          }
>          default:
>            codemess = "Default";
> }
>
> Try this:
>
>          case CHAP_MICROSOFT:
>          {
>            codemess = "MIC"; break;
>          }
>          case CHAP_MICROSOFT_V2:
>          {
>            codemess = "MV2"; break;
>          }
>          case CHAP_MD5:
>          {
>            codemess = "MD5"; break;
>          }
>          default:
>            codemess = "Default";
> }
>
> I don't know what else might be wrong.
>
> For what it's worth, I suggest using the logging functions in util.c
> (fatal, error, warn, notice, info, dbglog) rather than rolling your own
> with fprintf.  Even with "just" debug code, I think it's easier to use
> the existing infrastructure.
>

Re: PPPD plugin development

[Greg]

Hey guys,

Once again, Thanks for all the help.

I've managed to get it to work completely. I had to globalize a USERID 
variable, and from there I was able to set it in the verify function and 
call it from the ip_down notifier. This allowed me to do all the 
updating I needed.

Thanks again for all your help.

Thank you,
Greg Borbonus
*Nix Server administrator

On 3/10/2014 11:56 PM, Greg wrote:
> Thanks guys for help. James you have especially helped.
>
> Update: I've managed to get everything working. I had to ditch the 
> notion of stored password hashes and went with an encrypted password 
> with salts.
>
> Ran into an issue with allowed ips, but quickly fixed that with a 
> function within the plugin.
>
> One last thing left to do, I need to execute a function when the user 
> disconnects. I believe I need to use the "add_notifier" function and 
> set "ip_down_notifier" to a local function within the plugin.
>
> Does anyone know how I might obtain the username from that function? 
> It seems the notifier functions are used even less than the verify 
> hook I've been working with.
>
> Thank you,
> Greg Borbonus
> *Nix Server administrator
>
> On 3/10/2014 10:14 AM, James Carlson wrote:
>> On 03/10/14 10:23, Greg wrote:
>>> I'm attempting to authenticate a user who is trying to connect to pptp
>>> via an external means.
>>>
>>> They would sign up on the site and have the username and password 
>>> stored
>>> in a database(I do not want direct database access).  The password 
>>> would
>>> be encrypted(MD5).
>> MD5 isn't encryption.  It's hashing.  The big difference is that hashes
>> are (by design) not reversible.
>>
>> What you're describing just cannot be done because it's architecturally
>> flawed.  PAP, by design, passes the raw password on the wire, which
>> means that the recipient (the authenticator) can do the usual sort of
>> hashed password comparison: look up the stored hashed password, compute
>> a hash based on the input, and compare results.
>>
>> CHAP doesn't work that way.  With CHAP, the authenticator presents a
>> Challenge to the authenticatee.  That authenticatee then computes a hash
>> and sends it back.  The authenticator then must look up the CLEAR TEXT
>> passphrase, compute a hash based on the CLEAR TEXT and the challenge,
>> and compare results.
>>
>> Note that important part in the previous paragraph: with PAP, the server
>> need not store the original password, but with CHAP, it MUST. This is
>> exactly how it's designed.  See RFC 1994.
>>
>> Of course, MS-CHAP is a little different.  What it does is compute an
>> intermediate passphrase based on an MD4 (not MD5) hash of what the user
>> believes to be the password.  This intermediate passphrase is then used
>> as the actual passphrase for the challenge/response handshake. (Indeed,
>> there's no need for either side to know the original user's password;
>> storing just the intermediate value works as well.  You can do the same
>> with regular CHAP so why the MD4 part is written into the protocol is
>> beyond me.  Individual submissions are strange like that.)
>>
>> I guess that whoever designed that database didn't take that wrinkle
>> into account.
>>
>> That issue aside, PPTP as I understand it generally requires the MS-CHAP
>> variant and MPPE.  So, if you're the autenticator, you should have
>> "require-mschap" or (more likely) "require-mschapv2", plus
>> "require-mppe" among your configuration options.
>>
>>> I'm attempting to write an authenticator on the server itself.
>>>
>>> As for the debugging, how can I provide that for you?
>> Text works.  Use the "debug" option and make sure that syslog
>> "daemon.debug" is directed to a file.
>>
>> Or if syslog isn't an option for some reason, then use the "logfile
>> /tmp/pppd.log" option to direct the log messages to the specified file.
>>   (You can choose any file name you like, of course.)
>>
>>> The code is attached.
>> In your code, "challenge" and "response" are not strings, so printing
>> them that way (even for debug) isn't going to work so well. These are
>> arrays of bytes.
>>
>>>> I don't believe it can end up being anything else, given the current
>>>> design.
>>> It's empty.
>> I still don't understand.  Integers aren't "empty."
>>
>>>>> I've also made it return 1 so that no matter what I enter, it should
>>>>> show authenticated.
>>>>>
>>>>> digest->code writes as blank.
>>>> "writes"?
>>> I'm writing the output of the variables to a file.
>>> I've tried writing the value of digest->code to a file. it's empty or
>>> being interpreted in such a way that it's not writing anything to 
>>> the file.
>> Does the file get created at all?  If so, does it have zero length?
>>
>> Not writing anything to the file doesn't suggest that digest->code is
>> empty.  It suggests that something in your code is falling apart.
>>
>> There's at least one obvious bug here: that switch statement doesn't
>> work because it lacks "break;" between the cases.  Thus, everything
>> falls down to just "Default."  Instead of this:
>>
>>          case CHAP_MICROSOFT:
>>          {
>>            codemess = "MIC";
>>          }
>>          case CHAP_MICROSOFT_V2:
>>          {
>>            codemess = "MV2";
>>          }
>>          case CHAP_MD5:
>>          {
>>            codemess = "MD5";
>>          }
>>          default:
>>            codemess = "Default";
>> }
>>
>> Try this:
>>
>>          case CHAP_MICROSOFT:
>>          {
>>            codemess = "MIC"; break;
>>          }
>>          case CHAP_MICROSOFT_V2:
>>          {
>>            codemess = "MV2"; break;
>>          }
>>          case CHAP_MD5:
>>          {
>>            codemess = "MD5"; break;
>>          }
>>          default:
>>            codemess = "Default";
>> }
>>
>> I don't know what else might be wrong.
>>
>> For what it's worth, I suggest using the logging functions in util.c
>> (fatal, error, warn, notice, info, dbglog) rather than rolling your own
>> with fprintf.  Even with "just" debug code, I think it's easier to use
>> the existing infrastructure.
>>
>

Re: PPPD plugin development

[James Carlson]

On 03/11/14 05:55, Greg wrote:
> Hey guys,
> 
> Once again, Thanks for all the help.
> 
> I've managed to get it to work completely. I had to globalize a USERID
> variable, and from there I was able to set it in the verify function and
> call it from the ip_down notifier. This allowed me to do all the
> updating I needed.

I would have done this with the existing /etc/ppp/auth-down script,
which should be invoked with $PEERNAME set in the environment if the
user was authenticated.

But, if you've got your scheme working, then that sounds great.  Glad to
hear that it's working out.

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