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.
