On Mon, Dec 06, 2004 at 01:55:45PM -0500, Greg A. Woods wrote:
> [ On Sunday, December 5, 2004 at 17:49:48 (-0600), Tillman Hodgson wrote: ]
>
> [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.

I would call this single sign on, as you "sign on" a single time.

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

I would call this "centrally managed authentication".  There's nothing
in NIS, for example, that forces you to have the same password for all
hosts -- any given field can be over-riden, allowing per host passwords
if desired.

That would be a royal pain to manage, though. Heh.

In many ways I wouldn't even call NIS an authentication system but
rather an authorization system.  Because the password field can be
over-riden, I use NIS to provide the users meta-data (home directory,
shell, etc) but use Kerberos for the actual authentication mechanism
(as Kerberos doesn't provide meta info).

LDAP blurs the lines even moreso.

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

To generalize what you're saying:  The hype about X usually exceeds the
level of clue about X.  Clueful environments should still consider X a
useful tool.

Deploying something that one doesn't understand isn't a problem with
Kerberos itself.

Kerberos could really use some better documentation and a more visible
user community, that's true.  The recent O'Reilly book is a step in the
right direction, and I've been working on the getting the FreeBSD
Handbook chapter up to snuff.  It's an interesting comment that the
most commonly documented task seems to be itneroperability with Active
Directory.

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

That's not a bad thing ;-)

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

Sure it does.

A regular password identifies a user to a service: that's "forwards"
authentication. The user doesn't actually know that they're giving their
password to the right host.  Kerberos also checks the reverse
authentication, which is a very handy thing.

Probably the easiest way to explain it is to take a look at step 3 in
http://www.computerworld.com/computerworld/records/images/pdf/kerberos_chart.pdf

Step 4 also shows why data encryption is so easily obtained "for free"
with Kerberos.

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

Yup, IPsec can provide it for protocols that don't have it built-in. I
use IPsec with NIS for that very reason.  IPsec also prevents in-transit
tampering with the data, another issue with NIS.

I sometimes run Kerberos in an IPsec (transport mode) local environment.
It works well, though it's a higher crypto load on the hosts.  It saves
a user if they were to type `telnet -a somehost` rather than `telnet -x
somehost` (for those users that haven't aliased "telnet" to
"/usr/local/krb5/bin telnet -x", that is).

> >  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 like one time passwords.  I use them a lot in VPN architectures, for
example.  A pet peeve of mine is that Kerberos doesn't have good support
for RSA tokens (or other two-factor tools).

> > 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!  :-)

Excellent, it's time to get back to beer-drinking then ;-)

-T


-- 
A new scientific truth does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually
die, and a new generation grows up that is familiar with it.
    -- Max Planck, _Scientific Autobiography_