[ On Sunday, December 5, 2004 at 17:49:48 (-0600), Tillman Hodgson wrote: ]
> Subject: Re: Centralized User and Password Management
>
> 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

Yes, well, the the point I was trying to make though was that a balance
must be struck between the security policy requirements and how they are
implemented in the most politically acceptable way.  When one starts at
the top with a security policy document one must consider all facets of
the security problem, including both technology and human psychology
factors, environment, etc.

Using long-lived tickets to implement what I'll call "universal sign
on"[1] risks the threat that it's incredibly easy to distract a person
and cause them to leave their authorised sessions active at all times.
You and I might have security awareness first in mind most of the time,
but that's certainly not true of everyone -- apparently not even in the
military if you believe any of the stories the entertainment industry
tell us.  Your suggestion of xlock wiping the ticket assumes that the
user will run xlock and/or that there's some quite short timeout where
inactivity will run it for them.  That's probably a worse solution than
just giving the ticket a much shorter lifetime in the first place,
though that's just my non-empirical guess.  :-)

Using any other kind of system, including "single sign on"[2] risks the
threat that at least some users apparently get annoyed that they have to
reauthenticate themselves for every new session they open.


[1] "universal sign on":  i.e. where one types one's password once in
    the morning and so long as the ticket is never invalidated then the
    user can access all authorised objects and services and systems
    until they logout).  to some extent ssh-agent can do this for some
    purposes, and of course kerberos does this.

[2] "single sign on": the authentication data is centrally stored and
    maintained and all auth mechanisms share it so for each system
    identity there's only one common authentication needed (e.g. one
    common password).  NIS/NIS+, LDAP, etc. are in this category.

> 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 wish that were universally true.  Sadly the hype about Kerberos has
far exceeded the clue about it, and limited resources mean inexperienced
users are forced to implement it without knowing what they're doing.


> One-time passwords also don't address data encryption, MITM attacks

Kerberos authentication alone doesn't address those either.  It just so
happens that Kerberos implementers have addressed them and so users
often get their benefit "for free" when they choose to use Kerberos.

>  or
> reverse authentication (host verifying itself to the user).

Again it depends -- I'm not sure _exactly_ what you mean here, but
effectively this isn't really something Kerberos does either.  It's
something that's got to be done at several layers, perhaps in concert,
depending on exactly what's being authorised.  IPsec or SSH or similar
secure communications protocols are needed and how the authentication is
done before their connections are authorized is relatively secondary.


>  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.

Indeed one-time passwords are definitely not a universal solution!  ;-)


> 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
> security reasonably.

I can agree with that!  :-)

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>