[ On Saturday, September 13, 2003 at 02:36:55 (-0400), Roland Dowdeswell wrote: ]
> Subject: Re: BSD auth for NetBSD 
>
> A lot of the main consumers of the client side API are in basesrc.
> I think that to some degree this is going overboard---we need to
> decide on what API that authentication clients are going to use
> and stick with it rather than maintaining both.

You might think it's "overboard", but as someone who's seen these things
come and go I can assure you that having the ability to put common
wrapper APIs around things that do authentication actually makes
maintaining the base OS a lot easier.

This was already done for getpw* and hostnames, and it only makes sense
to do it again for the one remaining "A" in the "A&A" problem area:
Authentication.

>  As I see it we
> have a choice between PAM which is used in Solaris, FreeBSD, Linux,
> etc, or BSD Auth which is used in OpenBSD and BSDI.  BSDI is
> officially unsupported [soon].  Given the size of OpenBSD's userbase,
> if we decide to use BSD Auth we will continue to be in the unfortunate
> position that hardly anything in pkgsrc will support our authentication
> mechanisms.  This appears on first inspection to be a losing
> proposition.

I don't wish to turn this into a personal attack but your logic really
does seem to me to border on that of the worst unthinking sale droid.
Hopefully such market-_focused_ reasoning continues to be lowest and
least important of all NetBSD's overall goals.

I'm waiting now to see what you might say now that you've hopefully seen
through the veneer of your "first inspection"!  ;-)

I'm still stumbling over the idea that we would really ever care whether
anything third party supports _our_ authentication mechanisms.  Of
course I may be thinking of different things than you're thinking of.

To me it really doesn't matter one hoot if anyone else but NetBSD and
OpenBSD users write new authenticators for BSD Auth.  Those are so easy
to write that they really don't need third party support.  All we need
from third parties are command-line applications or libraries that can
interface with whatever tools might be used to do

As for things that make authentication requests, well there's been such
a cry for a standard API for making authentication requests in certain
application areas that major third-party software groups have already
collaborated to create one:  RFC 2222 (SASL).

Authentication APIs are really quite easy in theory.  You simply need
some way to ask some authoritative source whether the entity being
authenticated is who he or she or what says he or she or it is.  This
means taking an identity identifier, and possibly a secret, from the
entity and passing it to the authenticator, possibly along with an
indication of how the authenticator can interact with the entity for
further challenges, and then wait for a binary "yay" or "nay" answer
from the authenticator.  (There have been authenticators which return a
"maybe" answer too which might contain a pointer to some qualifier, such
as "If authenticator B also says "yes", though in theory that can all be
hidden from the application servers by having A invoke B directly, or
with a wrapper that runs in a loop until it gets a firm answer or runs
out of options.)

So the point I'm trying to make is that worrying over which framework
has third party support without knowing all the details of how important
such support might be is pointless.

Now while BSD Auth may be sufficient for NetBSD (despite what Todd tried
to say but said so obtusely), there are still good reasons to "hide" the
actual framework used to implement authenticators behind an API in libc
that can be made run-time configurable to support multiple frameworks.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>