Subject: Re: bin/953: login.c changes to sanify s/key use
To: None <netbsd-bugs@NetBSD.ORG>
From: Ty Sarna <firstname.lastname@example.org>
Date: 04/11/1995 16:25:04
In article <199504111125.VAA01324@splode.mame.mu.OZ.AU>,
matthew green <email@example.com> wrote:
> doesn't the "standard" S/Key have a file that lets you configure
> which users can and can't login with or without skey ?
"standard skey" is an oxymoron. There are what, 5 different versions not
couting NetBSD's and the different hash-algorithm flavors of each (which
often don't distinguish themselves as such)?
However, logdaemon's S/Key does have a way to say wether logins from
some specific combination of user, group, port, host, etc. must use
S/Key. It also has a way to restrict which users/groups can log in from
which ports/hosts. Unfortunately, these two very similar features use
different files with different syntaxes. I've been planning to do
something about this.
Also, there is some work being done by NRL on a system called OPIE
(One-time Passwords In Everything) that is backwards-compatible with
S/Key but provides better handling of MD4/MD5/SHA selection, among other
things. It also gets away from the problematic S/Key name. Bellcore
owns a trademark on S/Key, and doesn't want it used as "skey" since it
weakens their claim. Of course, S/Key is pretty hard to represent as a
filename on Unix (directory /usr/bin/S with filename key?) and even
Bellcore uses "skey" in there source files. The "OPIE" name doesn't have
those problems, which is why it was chosen. It also has the possibility
of finally unifying all the different variants.
Therefore, I'd reccommend that rather than making small incremental
improvements to our own variant, we wait and see what happens with OPIE
and adopt it, if possible. I'd be happy to do the work when it's time. I
also follo the relevants lists and try to keep up with all of the