systematic Kerberization

[Simon Wilkinson]

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.