Subject: Re: Centralized User and Password Management
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Tillman Hodgson <firstname.lastname@example.org>
Date: 12/05/2004 17:49:48
On Sun, Dec 05, 2004 at 05:20:40PM -0500, Greg A. Woods wrote:
> [ On Thursday, November 25, 2004 at 16:18:25 (-0600), Tillman Hodgson wrote: ]
> > Subject: Re: Centralized User and Password Management
> > Kerberos. But it's only "in sync" to within a 5 minute window, and even
> > that is configurable in the config file.
> No, it's definitely one of NIS or NIS+ or both that's also highly
> reliant on clock synchronisation. NIS+ probalby since it's usually
> crypto key stuff that's got timestamps in it -- just as in Kerberos.
Kerberos does have a 5 minute window, see RFC 1510 and the
KRB_AP_ERR_SKEW error. Secure RPC may possibly have one as well, as you
mentioned, though I haven't worked with it enough to know offhand.
> In a secure computing environment it's not uncommon to have the tickets
> expire every ten _minutes_, and even that is a huge window if _every_
> user is not careful and aware enough to manually invalidate it
> themselves each and _every_ time they _might_ leave their terminal
That can be automated to a certain degree. xlock, for example, could
wipe the ticket and acquire a new one. That's a red herring solution of
sorts, though, because I believe that this is a policy problem, not a
The general principle you're talking about is a breech at the human
layer. The examples of security problems in the human layer are
endless, and mostly irrelevant. That's in the realm of HR, not IT.
"You cannot apply a technological solution to a sociological problem."
-- Edwards' Law
> > I use an old SparcStation 10 running NetBSD to act as my KDC. Securing
> > it is dirt simple: I run no services on it other than the KDC itself and
> > access it through a serial console. Your slowest, oldest machine is more
> > than adequate to the task. A 25Mhz DECStation (ah, I miss mine) will
> > easily support tens of thousands of users.
> Yeah, OK, but try that in the typical IT shop that doesn't even know how
> to write a proper security policy in the first place. It's rarely, if
> _ever_, done right. I've seen the dregs more than once. I've even seen
> a KDC sitting in a guy's cubicle -- the same guy who was usually off
> visiting some other desk to help someone.
In my experience, if an organization is clued in enough to use Kerberos
(including the Active Directory version), they're clued-in enough to do
it right. I see very few bad deployments. If an organization has bad
security it's generally been because they had no security architecture at
> The problem is when it's done wrong then it's worse (i.e. far less
> secure) than just using the old-fashioned passwords on every system.
> (and almost infinitely less secure than properly using unique one-time
> passwords on every system).
Passwords are only one of the problems in security that an
infrastructure needs to solve.
For example, Kerberos gives you a central way to track authentication
attempts. Developing a complicated (and thus fragile in the same way
that you're claiming Kerberos to be fragile) secure central logging
system for all hosts is necessary to develop a decent auditing system.
Getting this step wrong is easier than getting Kerberos wrong IMO -- and
it's only one of the extra pieces that you'd have to develop.
One-time passwords also don't address data encryption, MITM attacks, or
reverse authentication (host verifying itself to the user). It also
doesn't scale to thousands of hosts, handle shared accounts, understand
trust relationships, or provide centralized management. Pushing those
issues up the stack to the application layer means that they likely
won't all be solved to a reasonable level.
I would summarize your argument as "Kerberos is complex, and therefore
fragile". I agree with that, except that I'd generalize it a bit:
"Security is complex, and therefore fragile". Doing security wrong
isn't a Kerberos problem, it's a PEBCAK problem. Kerberos is a fine
tool in the security toolbox for those environments that can implement
If you scramble about in search of inner peace, you will lose your inner