Subject: Re: PKINIT-22 comments

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Jan 2005 23:16:34 -0600

On Tue, Feb 01, 2005 at 03:16:41AM +0100, Martin Rex wrote:
> Only if the KDC happens to have not only the users certificate,
> but also all certificates from intermediate CAs in the KDC database,
> then the optimization of the client not sending the full path
> will not cause a PKINIT failure.  So if you can propose a means
> for the client to reliably know the KDC has full access to those
> certificates (read *NO* (directory) lookup of intermediate CA certs),
> then such an optimization is OK for the PKINIT spec.
> 
> The client shouldn't guess about the KDCs capabilities; if it doesn't
> know for sure that the KDC has access to those certs, it MUST send the
> full path.

To be fair, the client could try, get an error indicating that the full
cert chain is needed, then try again.

For clients w/o persistent writable storage that would.... well, it
might not be fun :)

So such clients should definitely send the whole cert chain.

But all of this is besides the point, Sam's point, which I took to be:
the spec has to be clear, as in RFC2119 clear, on what's expected so as
to guarantee interop.

Some degree of configuration is OK IMO, but in the open PK KDC case it's
best to just configure the clients to send the whole cert chain.  The
only good reason not to send the cert chain is really traffic and/or
footprint optimization... premature optimization and all that.

So I think: clients SHOULD send the cert chain, and KDCs MUST be
configurable to be able to find and validate missing cert chains, and
there should be an error code to indicate that the KDC expects the
client to send a cert chain.

> Why should PKINIT preclude a mapping based on a subjectAltName extension
> that does not require user certificates to be stored in the KDC database?

It doesn't.  I'll re-read the I-D soon, and if I think it says this I'll
object too, as I'm sure others here will.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 14:44:01 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> So I think: clients SHOULD send the cert chain, and KDCs
    Nicolas> MUST be configurable to be able to find and validate
    Nicolas> missing cert chains, and there should be an error code to
    Nicolas> indicate that the KDC expects the client to send a cert
    Nicolas> chain.

For the third time: this suggestion is not sufficient to meet my
interoperability requirement.

If you add something like clients MUST support configuration of a full
cert chain, then I think you are closer.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 13:54:05 -0600

> cert chain, then I think you are closer.

But not close enough?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 13:58:39 -0600

> cert chain, then I think you are closer.

BTW, I said as much in another post today.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 15:03:15 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Feb 01, 2005 at 02:44:01PM -0500, Sam Hartman
    Nicolas> wrote:
    >> If you add something like clients MUST support configuration of
    >> a full cert chain, then I think you are closer.

    Nicolas> But not close enough?

I can think of no reason at this time why that would be insufficient.
But I have not thought carefully about it.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Feb 2005 14:04:47 -0600

> But I have not thought carefully about it.

Oh, and, even small footprint clients?

I.e., should that be a MUST or a SHOULD?

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Feb 2005 23:22:17 +0100 (MET)

> I.e., should that be a MUST or a SHOULD?

I would strongly prefer a MUST.

The issue I have with some of Larry's proposals is that they
have serious awful consequences.  The amount of flexibility that
Larry is asking for provides significant lock-in provisions
for a vendor, which is a really bad characteristic for an IETF spec.

For me, interoperability is not only whether vendor A's client can
talk to vendor B's KDC or vice versa, it is just as much whether
the end user will be able to painlessly replace vendor A's KDC
with vendor B's KDC while retaining the rest of the infrastructure.

Now if inflate the protocol complexity so that the KDC may cover up
for even the most serious shortcomings in clients, then a vendor
may "add value" to the KDC to support insanely complex certification
hierarchies (and dynamically mutating hierarchies) with the most
braindead hardware tokens.

That way we're going to lock-in end-users of the protocol into
solutions, have them end-up with insecure hardware devices that
can't be used with other vendors Kerberos KDCs, or client implementations
that cannot be replaced with other vendors clients despite the
claimed "openness" of the underlying protocol.

But if we come to the conclusion that there are protocol features
that would be nice-to-have despite their lock-in potential, then
we should probably try to standardize some obvious (ab)uses so
that at least everyone can implement it in the same fashion.

The use of CMS or CMS-style approaches in flexibility is more
from the code bloat and kitchen-sink category and hostile to
small footprint clients (where the entire client is small, not the
fat client (PC/TabletPC/PDA) with a small hardware token attached.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 20:00:44 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Feb 01, 2005 at 03:03:15PM -0500, Sam Hartman
    Nicolas> wrote:
    >> >>>>> "Nicolas" == Nicolas Williams <[email-masked]>
    >> writes: >> If you add something like clients MUST support
    >> configuration of >> a full cert chain, then I think you are
    >> closer.
    >> 
    >>  I can think of no reason at this time why that would be
    >> insufficient.  But I have not thought carefully about it.

    Nicolas> Oh, and, even small footprint clients?

    Nicolas> I.e., should that be a MUST or a SHOULD?

interoperability cannot be a should.  We are required to deliver
interoperable specs.  All clients must support a configuration that
interoperates with a configuration of all servers.

Or with more qualifiers:

\forall x \in {clients}\exists y {client_configs}\forall a \in {servers}
    \exists b\in{server_configs}: x_y\interop a_b

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 22:50:21 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> interoperability cannot be a should.  We are required to
    Sam> deliver interoperable specs.  All clients must support a
    Sam> configuration that interoperates with a configuration of all
    Sam> servers.

    Sam> Or with more qualifiers:

    Sam> \forall x \in {clients}\exists y {client_configs}\forall a
    Sam> \in {servers} \exists b\in{server_configs}: x_y\interop a_b

I wrote that out mostly as a joke but managed to get something
important wrong and in the process realize that I am unclear in what I
ask for.  The statement above only requires pair-wise
interoperability.  Each KDC and client must work together, but for
example the configuration that a Microsoft client and Heimdal KDC
share may be different than the configuration that a MIT client and
Heimdal KDC share.  That's no good.
So restated:

\exists c\in{client_configs} \exists  k\in{kdc_configs}\forall x\in{clients}
    \forall y\in{kdcs}: x_c \interop y_k