spn alias

[Jeffrey Hutzelman]

On Thu, Mar 6, 2025, 19:16 Michael B Allen <ioplex at gmail.com> wrote:

> On Thu, Mar 6, 2025 at 5:57 PM Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
>
>> Years ago we patched Cyrus SASL to avoid this problem by allowing any
>> principal whose keys appear in the keytab, but that unfortunately was never
>> merged.
>>
>
> I thought that's how kerberos worked by default - just use the spn in the
> ap-req to lookup the base key from the keytab or wherever.
>
> Sounds gssapi got in the way of itself.
>

GSSAPI makes it easy to do this right, and that's the advice we've been
giving for at least 20 years. Unfortunately, or also makes it easy to get
the idea that servers have to acquire a credential to accept connections.

** RFC 4120 specifically said not to rely on insecure DNS queries for this,
>> but that advice is unfortunately frequently ignored, by applications and
>> libraries in ways that are hard to avoid. Fortunately, everyone seems to
>> follow the corresponding advice for TLS and X.509 PKI, which essentially
>> means that as long as you use ldaps and validate certificates, the reverse
>> DNS lookup before calling SASL/GSS/Kerberos doesn't introduce any problem.
>>
>
> Deploying CA certs is annoying.
>
> I've been thinking about adding a utility to my toolchain that does an
> LDAP bind with Kerberos and, if and only if mutual is successful, grab the
> CA cert from the SSL layer and offer to install it (like
> into jre/lib/security/cacerts for java in my case).
>

That seems reasonable, if you trust the server to send the right CA cert.
It would also work to use a Kerberos authenticated ssh connection, or set
up something behind https://www.eyrie.org/~eagle/software/remctl/ to
provide a CA cert. I agree, deploying CA certs or anything you can trust is
annoying. Once you've done that once, better to make use of it for others.

>