> > There is nothing wrong with this. A properly installed telnetd
> > supporting the telnet AUTH option will be configured to either allow
> > this behavior or not depending on the administrator's preferences.
> > There are four levels of acceptable login:
>
> Yes, but, I think Michael was writing in the context of /bin/login,
> PAMified, instead of login.krb5.
how does the use of PAM in /bin/login change the security issues?
> I think we need to have a liblogin and a /bin/login based on that, that
> liblogin needs to be PAMified, that telnetd should use liblogin and so
> on. The crucial issues include: how to communicate to login, and thence
> PAM, just how the user was authenticated, if at all, with what system
> and to which principal; we also need to be able to inform login, and
> PAM, about the security of the TTY.
>
> Then we could push handling of valid/user/other/unknown to PAM, where it
> belongs.
how does this belong in PAM? PAM does not support any equivalent
concept. If authentication is being perform by telnetd/sshd/ftpd then
PAM is not involved for authentication.
Authorization is perform via the krb5_kuserok() function. If the
installer wants PAM to be used for authorization then this function
needs to be modified, not telnetd.
> > > And the only reliable solution to this is to have login's
> > > functionality built-in to telnetd, so that it will have full
> > > control for tickets _and_ usernames.
> >
> > I am leaning in this direction for other reasons.
>
> I think that is a good thing to do, and if there's a liblogin, then base
> /bin/login on liblogin.
you are assuming that /bin/login can be replaced. I'm not. I'm
working on the assumption that I do not want each and every
application to require its own version of /bin/login. I want the
telnetd/sshd/... packages separated from the Kerberos tree so that
they can be supported independently. Part of the problem with secure
telnet right now is that there are too many versions that have forked
in different directions. I want one package that can support any/all
of the authentication methods as selected by the administrator.
(K4,K5,SRP,TLS,SKIPJACK,...)
> Yes, but, plenty of code exists that could be fashioned into what we've
> been talking about. We can specify liblogin and its interaction with
> PAM, we can turn a PAMified login into liblogin, and we can take one of
> the various PAM_KRB5 modules, touch it up and fit it in.
I am not of the belief that PAM should be involved in services that
perform non-interactive (protocol based) logins. PAM can be
configured to require multiple passwords for multiple authentication
modules. This is incompatible with non-interactive authentication as
supported by telnetd/sshd/ftpd/...
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * kermit-support@kermit-project.org
