[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nifty control over S/Key usage



This is pretty much exactly Wietse Venema's logdaemon package's
login program.  There are a number of limitations with it.

1) You may not want to support JUST skey, you may also want kerberos
   and a challenge response (there is a logdaemon alternative for DES
   chal/resp devices submitted by Bill LeFebre).
2) If you use anything else (like wu-ftpd with skey), you use the same
   config file.  This may/maynot be desirable.

I'd LIKE to say (of the top of my head), 
   "for network INSIDE, allow plain passwords ALWAYS"
   "for service DEFAULT; use skey"
   "for telnet, user=Bob, use snk" (secure net key, a des device)
   "for ftp, user Bob, use kerberos"

Reasonable solutions are something like BSDi and FreeBSD's
login.conf, which can say "try kerberos, then skey, then snk"
for auth.

I had hacked the logdaemon's login to use the TIS FWTK
authentication daemon, sort of.  Then the user management hit
"tis.access" and if it wanted extra auth (more than a plain
password), it used the Authdaemon, which supports s/key and SNK
and plain.  I'm not really satisfied with it; I'd like to pass
the service (telnet/ftp/http?) and also allow kerberos IV or 5
tickets.  It *is* nice in that you can have 1 authdaemon on one
machine and have many machines auth against that.

Again, no ideals, but I think the login.conf type solution
(and/or a whole PAM implementation?) allows us the most
flexibility.

Okay, now you all can say how stupid I am and what a bad idea this is.


chuck

Quoting Matthew Patton (patton@sysnet.net):
> FreeBSD has this nifty file /etc/skey.access which influences login's
> behavior. I didn't see it mentioned in the OpenBSD docs. Anyone interested?
> 
> <begin quote>
> The configuration file /etc/skey.access can be used to configure
> restrictions on the use of UNIX passwords based
> on the host name, user name, terminal port, or IP address of a login
> session. The complete format of the file is
> documented in the skey.access(5) manual page; there are also some security
> cautions there which should be read
> before depending on this file for security.
> 
> If there is no /etc/skey.access file (which is the default state as FreeBSD
> is shipped), then all users will be