Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 25 May 2005 18:32:10 -0700

If I already pre-shared the KDC's public key with the client, why am I
required to process the Kerberos TGS otherName? Or worse, if it is not
present, do I have to require the Kerb TGS name be present?

I am ok to say if the TGS Kerberos other name is present in the KDC's
x.509 certificate, and then it must match with the TGS of the target
realm, but not more than that. 

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 5:06 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]; Paul
Leach; [email-masked]; Stefan Santesson
Subject: Re: PKINIT-26 changes: identifying the kdc certificates

Liqiang\ wrote:
> 
> The current text says if you have already verified the binding, you
can
> skip the check for the Kerberos TGS name; otherwise, it is REQUIRED to
> process the Kerberos TGS name. 
> 
> IMO, the current text in -26 is sufficient.

If the information is present in the certificate then it would be
a pretty bad idea to require only a fraction of clients to verify it
and allow some to entirely ignore it.

If it is to be a requirement, it is to be a requirement for everybody,
and it is extremely beneficial if the check can not be skipped by
anyone.

Otherwise we will run into the problem that someone starts with
a homogeneous (i.e. single-source) Kerberos infrastructure that has
some proprietary means to verify the binding an skip the otherwise
REQUIRED check to work inspite of an incorrectly configured certificate.

The problem will only surface when one tries to add a different-source
kerberos client into the landscape that does not know or implement
that particular proprietary alternative to verify the binding and
skip the check.  So it will perform the REQUIRED check and fail.

For the novice this will look like the different-source product is
defective (although it isn't), and it will take an expert to figure
out why there is a failure only with the different-source product.
(>= 3 weeks of battle even with the golden support level).

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 May 2005 22:03:01 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> If I already pre-shared the KDC's public key with
    Liqiang(Larry)> the client, why am I required to process the
    Liqiang(Larry)> Kerberos TGS otherName? 

I don't think you should be required to do so.  Who is saying you
should?

Or worse, if it is not
    Liqiang(Larry)> present, do I have to require the Kerb TGS name be
    Liqiang(Larry)> present?

No I don't think so.