Password expiration

[James F.Hranicky]

On Fri, 7 Mar 2003 21:56:40 -0600
Steve Langasek <vorlon at dodds.net> wrote:

> If the application in question is one that the user must type their
> password into directly, there's no particular advantage to making it
> Kerberos-aware instead of just making it PAM-aware, really (this is the
> niche pam_krb5 is aimed at, in fact).  OTOH, apps like ssh that
> communicate using a client-server model definitely are better off with
> Kerberos (GSSAPI) support.

I know, but I just don't know how my userbase will react to the need to 
have Kerberized clients around. Again, if I could get a set of clients
put up on my ftp site that 

	- use tickets
	- will prompt users for a password when there's no ticket/an
	  expired ticket, and obtain a new one
	- put the ticket in the appropriate place so all the other
	  clients will use them
	- install easily on multple platforms

I may be able to swing it.

I just turned off my last unencrypted network protocols (pop3, ftp) in December,
and getting people used to importing our site x509 certificate to prevent
the "untrusted site" warning message from popping up took some doing. Telling
them "ok, first get this kerberos software, ok, now when you want to log in,
run kinit" ... etc, seems unlikely. 

> > > - sshd - If we did use it, we would require GSSAPI/Kerberos 5 authentication,
> > >   and that would push the authentication back to the client.
> 
> > I understand the reasoning, but ssh clients would then really need to be
> > able to prompt for the Kerberos password and get tickets for users, as
> > well as do proper password expiration, before *I* would feel comfortable
> > having my userbase use it.

> ... or you could require the use of a Kerberized client OS, such as Win2K,
> so that they already have the tickets they need. :-)  A Kerberized ssh
> client is still a must here, of course.  My own deployments have involved
> ssh with the gssapi patches, plus pam_krb5 for backwards-compatible
> password auth.

Yes, much more I-dotting and T-crossing. Plus, I have little control over
remote sites, which is really the whole point.

And realistically, what are my Kerberized options for even reading IMAP mail?
How about Kerberized SMTP for SMTP auth? Does Outlook even support tickets yet? 
My server (courier) doesn't, nor do my most popular Unix clients (sylpheed, 
netscape). My only option is making everyone use pine and moving to UW-IMAP, 
which I'm not prepared to do.

In the end, without clients that make it easy, and without having *everything*
Kerberized (meaning something still has to send the username/password over
the network, albeit over an encrypted channel), I'm not going to be in a hurry
to push Kerberized clients on my userbase. Turning off telnet 6 years ago in
favor of SSH causes all sorts of headaches for people behind corporate firewalls,
and I'm in no hurry to do that again unless a nice, user-friendly packaged 
solution exists, and all my remote users have to do is ask remote network admins 
to allow Kerberos through.

However, I'm not opposed to slowly working on such solutions, in fact, I see it as
critical for widespread Kerberos acceptance (apart from what's in Win2K, in which
little seems to be Kerberized). It may amount to little more than writing some
library code that can be dropped relatively easily into as many clients and servers 
as possible to make Kerberizing applications easy. It may amount to more than that,
but hey, that's why we're having this conversation :-> I guess a good start
would be anything using SASL (postfix, for one) because it already has code for
GSSAPI auth.

So, where do we begin? SASL? Hmmm...sylpheed, courier, and postfix all use or
can use sasl...hmmm...

Jim