Date: Mon, 1 Jun 1998 19:46:35 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Eivind Eklund <eivind@yes.no>, "J.A. Terranson" <sysadmin@mfn.org>, "freebsd-security@FreeBSD.ORG" <freebsd-security@FreeBSD.ORG> Subject: Re: MD5 v. DES? Message-ID: <Pine.BSF.3.96.980601192403.6508C-100000@fledge.watson.org> In-Reply-To: <5630.896731049@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jun 1998, Poul-Henning Kamp wrote:
> >I personally dislike this idea -- where does this leave one-time-password
> >users, etc?
>
> Perfectly safe as always. All it does is to make sure that you don't have
> to modify, ftpd, telnetd, login, popper, and uhm... what is the last one,
> I keep forgetting, Hmm.....
This works fine for all authentication systems where username + something
allows authentication. But I'd like to have a more extensible system that
provides a context for challenge/response, if we are going to break from
the pack of do-it-yourself-crypt-foo. I have problems with the
implementation of linux-style PAM, but the general concept of having
multiple authentication support with a series of challenges/responses does
make sense. triple of (username,password,context) breaks down as soon as
you need the s/key challenge from the auth module.
It would also be nice to have the policy for authentication in a seperate
independant location (as you hint with the context field). It would be
cool to be able to have the following policies:
Accept kerberosIV, local passwords, one-time-passwords when using ssh or
kerberized rlogin.
Accept one-time-passwords only when using telnet, ftp (and other
unencrypted daemons).
The "context" would probably be something a little more sophisticated --
perhaps a two part field, the first with the daemon name, and the second
with a classifying field, such as telnetd/kerberized, or httpd/ssl or
something. To allow a more flexible policy in the policy subsystem
without it having to have more access to the daemon than necessary.
For the sake of the library/etc, it might be nice to have the uid of the
authenticating process be part of the context. In a nice modular
environment, it might be desirable to have an "authentication daemon" that
listens on a unix domain socket (or such). Daemons like CMU's imapd
already make use of this so that the daemon itself can run non-root yet
still take advantage of username/password authentication. The daemon
might take into account the identity of the requestor, refusing to provide
information about username/password authentication to normal user
processes, but allowing it for the www user (or something like that).
On should also be careful to not restrict oneself to nul-terminated
strings -- allowing a kerberos authenticator in might be useful, and it
can contain nuls.
> Basically what I'm saying is that if all the places which have to
> authenticate a user, had a call where they could say:
>
> "Is password <foo> acceptable for user <bar> in context <program>"
>
> Then you can implement this function whichever way you want, rather than
> have to modify twenty-odd programs which all do the
>
> wp = getpwbyname(...);
> getpassword(buffer);
> if (strcmp(pw->pw_passwd, crypt(pw->pw_password, buffer))) {
> sorry...
> }
But I'm saying that when I add one-time-password support with
challenge/response, I'm going to have to go modify all of those daemons
again to do the challenge. This is a much harder problem that some people
address (possibly badly) through PAM, and for which a better solution
should be found. It might also be useful if the authentication system
could pass back "tickets" or "tokens" that might be useful to the daemon,
if the daemon chose to accept them (that is, it knew what to do with
them). For samba, this would be useful in environments using Coda or AFS.
For login, this would allow the acquisition of kerberos tickets, etc --
the authentication manager would return these as optional data to the
authenticating process where it deemed appropriate.
My feeling is that we might as well leave things as they are until a
rigorous authentication management system is defined, and then use that.
Of course, if you write the code you describe, I'll use it, but... :-)
Robert N Watson
----
Carnegie Mellon University http://www.cmu.edu/
Trusted Information Systems http://www.tis.com/
SafePort Network Services http://www.safeport.com/
robert@fledge.watson.org http://www.watson.org/~robert/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980601192403.6508C-100000>