Comments on the use of plugins - useof pkinit_kdc_hostname

[Douglas E. Engert]

I think what I am asking for is a better way to handle the current
Windows KDCs, until they support full RFC 4556.

  Section 3.2.4  says:

    In addition, unless the client
    can otherwise verify that the public key used to verify the KDC's
    signature is bound to the KDC of the target realm, the KDC's X.509
    certificate MUST contain a Subject Alternative Name extension
    [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
    defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
    matches the name of the TGS of the target realm (as defined in
    Section 7.3 of [RFC4120]).


The Windows enterprise CA will have signed certs for KDCs in its realm
or realms in the forest.  It adds the extensions with the "domaincontroller"
and the DNS name of the KDC, but not the realm. But since Windows ties the
realm to the DNS domain, the realm could be derived from the DNS extension.
(I believe this is always the case.)

So how about something like pkinit_eku_checking = W2k which checks for the
Windows KDC extensions but does not require the pkinit_kdc_hostmame?


Sam Hartman wrote:
>>>>>> "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 1.3.6.1.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
> password.
> 
> 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.
> 
> --Sam
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444