You are here

Improve Host key management (subsumed into "wallet" #129)

Project ID: 
69
Current stage: 
Manager: 
Unit: 
What: 

Description: Improve the host key management system (kdcregister & associated utilities) so it no longer has dependencies on non-public MIT Kerberos header files

Deliverables: A host key management system that doesn't depend on non-public Kerberos header files

Why: 

Customer: Requested by the MPU

Case statement: Summary - how do we manage kerberos keytabs for "inf" level machines.

Current situation
-----------------
The "inf" level serves two purposes :-
1) a minimal development environment for MPU unit working on new platform
releases.
2) a means by which we can support legacy (or even additional) platforms
against DICE services, in a lightweight manner

The current "inf" level does not include kerberos host key creation
at install time. Instead, host keys are created in a manual process and
not necessarily for each machine. This is because the current implementation
of "kdcregister" relies upon kadmin interfaces which MIT have made private in
recent releases. This complicates the build process by requiring locally
built Kerberos RPMs in order to build kdcregister.

However, we have at least a couple of concerns with the current situation.
Firstly, one can't securely authenticate a user at login unless the
machine has a kerberos keytab. There's no trust path between the machine
and the KDC, which means the machine can't check the validity of the
response that its given. The only reason this still works for us is that
we're using an outdated pam_krb5 binary - when we upgrade this, Kerberos
logins to keytabless machines won't work any more.

Secondly is that we still have a long term plan of using LCFG
spanning maps to control which service principals can be issued (and to
delete those which are no longer in use). The adhoc creation of keytabs,
by running kdcregister manually, or by directly invoking kadmin, would
complicate the realisation of this cunning plan!

When: 

Status:

Timescales:

Priority: Relatively low priority, as the current kdcregister mechanism has been successfully ported to the FC6 and FC5/6 x86_64 platforms.

Time:

How: 

Proposal:

Resources:

Plan: We propose that in the medium term "kdcregister" is reimplemented using
a more portable and supportable technology.

We have a number of options here.

The simplest, quickest and lowest risk would be to reimplement kdcregister
using the same transport technology as the current X509 server certificate
signing system, sixkts. This a known local technology, which would have a
small implementation cost.

A more ambitous plan would be to investigate redesigning the entire mechanism
by which secure content is distributed to our machines, encompassing a
possible replacement for sixkts, as well as the systems for distributing
keytabs and SSH keys. To do this we'd deploy Stanford's remctl program, along
with their wallet technology. The primary benefit of this would be reducing
our dependence on a locally written protocol in a security critical role, but
it's not clear that the eventual result would be worth the development risks
involved.

A futher possibility is to work with MIT on defining the kadmin API in such
a way that they are prepared to support it as a public interface.

Meanwhile, kerberos keytabs should be created, manually, for all "inf" level
machines and appropriate "kerberos.keys" resources be set to flag machines
with active host keytabs.

Other: 

Dependencies: If we decide to work with MIT on refining the kadmin interface, we are
depedent on their argreement, and release management processes

Risks:

Milestones

Proposed date Achieved date Name Description