[Freeipa-devel] About private ssh host keys in IPA

[Simo Sorce]

This is about Ticket 1978 (originally rhbz746036).

This RFE asks for storing private SSH Host Keys in FreeIPA.

We have been triaging this ticket today, and I have to admit I am biased
toward simply closing down the ticket.

However we want to reach out community and interested parties that
opened the tick to understand if there are reasons strong enough to
consider implementing it.

The reason I am against this is that in FreeIPA we already provide
public Key integration. This means that when the host is re-installed
new keys are loaded in IPA and clients do not get the obnoxious warning
message that keys have changed, because enrolled clients (with the
appropriate integration bits) trust FreeIPA so they do not need to ask
the user to confirm on a key change.

Storing Private Keys poses various liability issues, in order to be able
to restore keys you need to give access to those keys to an admin, as
there is no other way to authenticate just the host itself (it was just
blown away and reinstalled).
This means any admin account that can perform reinstalls need to have
access to *read* private keys out of LDAP, which means that
A) The central tenet of Asymetric authentication is that private keys
are 'private'.
B) keys are readable from LDAP to some accounts, any slight error in
ACIs would risk exposing all private keys.
C) most probably low level (junior admin) accounts will have read access
to pretty much all private keys, because those admins are the one tasked
with re-installs. However those admins are also the ones less trusted,
yet by giving them access to private keys they are enabled to perform
MITM attacks against pretty much any of the machines managed by FreeIPA.

For these reasons I am against storing SSH Private Keys. I would like to
know what are the reasons to instead implement this feature and the
security considerations around those reasons.
>From my point of view the balance between feature vs security issues
trips in disfavor of implementing the feature but I am willing to be
convinced otherwise if there are good reasons to, and security issues
can be properly addressed with some clever scheme.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York