systematic Kerberization
Simon Wilkinson
simon at sxw.org.uk
Fri May 14 21:47:04 UTC 2004
I'm coming somewhat late to this party, having been pointed at the
discussion by a colleague. Apologies for the length of this mail.
I developed the authentication and directory services infrastructure for
the Division of Informatics at the University of Edinburgh, as part of
this work I wrote the SSHv2 GSSAPI implementation in OpenSSH, along with
investigating and patching numerous other pieces of Kerberos code.
Laptops are a key part of the computing infrastructure here, and we have
looked into the disconnected authentication problem in some detail.
The key missing piece, for us, is web applications. There are a number
of solutions floating around, from that recently implemented in Mozilla
(Microsoft's Negotiate solution), to UMICH's kx509 technology.
Unforunately, most web applications use their own in built
authentication methods, making it hard to substitute new technologies.
In addition, delegation is of critical importance to services which
interface against other Kerberized backends (webmail, for example), and
doesn't appear to be cleanly supported by any of the current solutions.
Its also critical to assess the correctness of a given applications
Kerberos implementation. There are 'Kerberised protocols' which merely
perform a Kerberos handshake upon connection establishment, and then
allow the rest of the conversation to occur unprotected. These are
obviously vulnerable to MITM attacks unless carried over an already
encrypted _and authenticated_ channel. (HTTP Negotiate, and postgres's
Kerberos authentication are both examples of this).
The killer application is probably still email. It would be good to see
a wide spread of Kerberised IMAP and POP clients, along with MUAs which
support SMTP-AUTH. The criticial application here for us is Mozilla.
CUPS is worrying, as it seems that the authentication options are a step
backwards from those available with LPRng.
The SSH support that's now in OpenSSH is suitable for small sites, but
the lack of key exchange makes it hard to deploy over large sites, who
are trying to avoid having to manage yet another set of key material.
I'm trying to find the time at present to update my key exchange patches
to both the newest releast of the I-D, and the current OpenSSH code base.
It would also be really nice to have a better solution for securing the
nss -> LDAP server link with GSSAPI. Ideally, it would be possible to
run a caching daemon on each machine which would manage Kerberos
credentials for contacting the LDAP server, which the nss libraries
would go through to gain access.
Onto disconnected operation ...
Locally, we've put a lot of time and effort into making disconnected use
of our machines 'just work'. From an authentication and directory
services point of view we've got fairly far along that path.
We take the view that there are two different 'tokens' that a user must
have in order to access a machine - the first provides local access, and
the second to network services. At the moment, these 'tokens' are
identical - the user has the same password for both local and network
access.
The decision to combine the two was arrived at for operational and
usability reasons. We can envisage having a large number of disconnected
machines, possibly more than one per user. Expecting users to remember
different 'local' passwords for every machine and to change them all at
the same time seemed like a nightmare. In addition, managing these local
accounts centrally means that its easier to guarantee that password
strength requirements are met.
We provide a tool for renewing credentials which works like 'kinit', but
uses the PAM stack in order to allow the chaining of other
authentication mechanisms (such as kx509). Users who have logged in
whilst their machine is disconnected must use it after reconnecting
their machine, and before accessing network resources.
Disconnected directory services are a hard problem, which I don't think
we've got right yet. We currently mirror substantial chunks of our LDAP
service to the local machine, which just isn't scalable as the volume of
directory information grows. However, not having it there creates
problems when increasing chunks of the machine depend on it.
Hope all thats of use!
Cheers,
Simon.
More information about the fedora-devel-list
mailing list