> On 27 Apr 2022, at 12:45 pm, Michael Ströder <[email protected]> wrote:
>
> But my concern is rather that I would not connect my KDC to the Internet (for
> now leaving aside approaches like proxy KCM).
>
> In general I'm leaning more towards using asymmetric keys for authc. On my
> personal to-do list is to implement a simple X.509-CA for issuing short-term
> client certs, with a CLI tool to directly manipulate Thunderbird and Firefox
> key/cert DB.
FWIW, both Heimdal and MIT KDCs support "pkinit", and it should be (but may not
yet)
be possible to disable symmetric-key AS requests (the TGS will still be keyed
with
a symmetric key, but it is independent of long-term user secrets, and the TGS
key
can be rotated from time to time).
That said, there is not yet support for "raw public key" AS requests, where the
KDC stores the user's public key, rather than either a symmetric key or a
trusted
issuer CA. This has probably been proposed, but I don't know of any current
RFCs
or implementations along these lines. Should be a relatively straight-forward
extension.
A KDC is basically an online CA, both store valuable secrets that if leaked
enable
impersonation. The main difference is that for a CA that's just one trust
anchor,
perhaps more readily replaced, but for a KDC there are also many principals
whose
shared secrets with the KDC need to be refreshed in the event of a compromise.
Either way a compromised CA or a compromise KDC is bad news...
--
Viktor.
