Comments on the use of plugins - useof pkinit_kdc_hostname
hartmans at MIT.EDU
Mon Jun 18 11:01:15 EDT 2007
>>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
Douglas> Sam Hartman wrote:
>>>>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:
Douglas> The pkinit_kdc_hostname, in effect duplicates, the
Douglas> hostnames as used in kdc = or in the DNS SRV records. We
Douglas> really like to use the dns_lookup_kdc=1 option so we
Douglas> don't have to have the names of the KDCs in the
Douglas> krb5.conf. Having to add the hostnames for
Douglas> pkinit_kdc_hostnames defeats this goal!
Douglas> If the concern is that the cert may be valid but not be
Douglas> from a KDC, I would hope that some more Windows friendly
Douglas> code could be added. It looks like Windows adds the
Douglas> extension 184.108.40.206.311.20.2 with a value of
Douglas> DomainController (utf8?) to the cert as well as a SAN for
Douglas> DNS. (But windows being windows the host part of the DNS
Douglas> name XXXXXX below is in uppercase!)
>> No, the issue is that without trusting DNS, you don't know
>> that the SRV record returned the right cert.
Douglas> This DNS trust issue is the same problem you have without
Douglas> PKINIT, and is related to IP spoofing, i.e. how does the
Douglas> client know it is talking to the real KDC?
No. I can trust the KDC because only it knows my password. (That's
different from the system i'm logging into trusting me, which requires
that it have a host key.) But normal Kerberos does not depend on the
security of the DNS. If your DNS is returning the wrong information
you can get denial of service, but you cannot make a trusted local
user believe they are talking to a KDC that does not know their
host to realm of course is entirely different.
Douglas> other realm in the AD-forest.
Douglas> But without PKINIT one should be using the
Douglas> krb5_verify_init_creds to make sure the client got
Douglas> tickets from the real KDC. I would assume that
Douglas> krb5_verify_init_creds is still recommended with PKINIT,
Douglas> and it would catch any DNS or spoofing attack including a
Douglas> cert from the wrong realm.
Possibly. I honestly haven't worked through this in sufficient detail
to convince myself one way or another.
Douglas> What I am saying is having to add pkinit_kdc_hostnames is
Douglas> too much configuration management in an environment that
Douglas> has lived without it. I would like to see something
Douglas> else. I would expect eventually the Microsoft KDCs will
Douglas> have certs with the extensions defined in the PKINIT RFC.
I'd like to see something else too. I'm quite certain it is insecure
to do something else with kinit from the command line or with anything
that does not include a keytab. The current code structure also
doesn't allow you to know when verifying the cert whether you are
going to end up checking against a keytab.
However if we convince ourselves that relying on a keytab is safe,
then we could look at ways to get that information to the right place
in the code.
More information about the krbdev