On Tue, Apr 21, 2020, at 4:30 AM, Sumit Bose wrote:
On Mon, Apr 20, 2020 at 10:17:31AM -0400, James Cassell wrote:
>
> On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote:
> > Hi,
> >
> > I'm wondering why krb5_validate defaults to false in sssd-krb5, and
> > apparently it's the same default in the mit kerberos libraries (via
> > verify_ap_req_nofail). It should solve the KDC impersonation attack,
> > at the expense of a slightly more complicated setup (create the host
> > principal, extract key, create keytab). Is it because of this added
> > difficulty in setting up things, or does it not work on very common
> > scenarios/applications? Or just one of those hard to do transitions?
Hi,
the main reason why krb5_validate is not enable by default in the krb5
auth provider is basically mentioned below, you need a keytab. Since for
plain classical Kerberos authentication a host keytab is not needed and
might even not be available the validation is off by default. When using
the AD or IPA provider where a keytab is created while joining the
domain validation is switched on by default.
> >
>
> In my option, krb5_validate is broken. It chooses the name on first key in the
keytab to attempt validation, rather than either the newest or the one matching
ldap_sasl_authid (or an equivalent setting.) This causes issues where a host may have
previously had a service principal but it got reassigned to another host, or due to
renaming a host without removing the old name from the keytab. (RH support considered it
"not a bug.")
I think the most straight forward solution here is to add a new option
to give a principal which should be used for validation.
ldap_sasl_authid is not strictly related, the LDAP code might even use a
different keytab than libkrb5 would use for validation.
I agree having a separate option for configuration here would be useful. I'd never
considered that ldap might use a different keytab than kerberos. I wonder why that might
be done?
In general /etc/krb5.keytab should only contain entries which are
currently valid. Old entries especially with weak encryption types
should be removed. E.g. sshd is using /etc/krb5.keytab for GSSAPI based
authentication as well so attackers might be able to use information
about the old tickets to get access to your system.
I agree in principle. Practice is harder, especially when dealing with hundreds of legacy
systems... If there's a good/easy way to audit keytabs for weak encryption types, it
might be worth pursuing... otherwise, I'll pray that FIPS mode saves the day :P
V/r,
James Cassell