Subject: RE: PKINIT issues, proposals

From: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 14 Jul 2004 12:50:44 -0600

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2004 12:00 PM
To: Brian Tung
Cc: [email-masked]
Subject: Re: PKINIT issues, proposals

>>>>> "Brian" == Brian Tung <[email-masked]> writes:

    Brian> 2.  We propose to include the AD-INITIAL-VERIFIED-CAs
    Brian> structure into the PKINIT specification.  There seems to be
    Brian> some confusion about whether it is permissible for this
    Brian> structure to be empty--that is, for it to contain no CAs at
    Brian> all.  We don't believe that there is a significant problem
    Brian> with it being blank, and it seems to be part of the
    Brian> original intent of Nico's specification to permit it to be
    Brian> empty.

Yes, Nico's original proposal was intended to allow the field to be
empty only in the case where no CAs were used to validate the
certificate.  That is the certificate is known to the KDC.  This is
similar but not entirely overlapping with self-signed certificates.

[ERIC] I seem to remember a different proposal. I don't recall
restricting the empty field to only the case where no CAs were used. I
do recall allowing it to be blank, based on KDC policy.

Regarding your recollection of Nico's original proposal; can you
elaborate on which certificates have to be known ahead of time? The Root
certificate? The CA cert? Or the End Entity cert? I just don't
understand how filling in the field with a list of CA certs accomplishes
anything (other than additional, unnecessary complexity). Certs and PKIs
are based on chains of trust back to a Root, which must be trusted ahead
of time. If the KDC properly validates the chain of trust through a set
of CA certs, why must it always fill in the object? Consistent with the
original proposal at the Interim meeting last September, I believe this
should be left to policy as no one has provided a good security reason
for requiring that it be filled in.

    Brian>     One potential issue with an empty field is that it
    Brian> takes away the application server's ability to make
    Brian> authorization decisions based on the content of the CA
    Brian> list.  That server is then placed in the unusual situation
    Brian> of trusting the KDC's packaging of the ticket, but not on
    Brian> its verification of the user's certificate chain.  We don't
    Brian> think this necessarily leads to a security hole, provided
    Brian> that these implications are carefully explained; decisions
    Brian> on whether to allow the CA list to be empty (and, for the
    Brian> application server, on whether to authorize service based
    Brian> on an empty CA list) can then be relegated to local policy.

It does lead to a difference between how pkinit works and how the rest
of Kerberos works.  I do not believe that this inconsistency serves
the Kerberos community.

[ERIC] Not sure that I agree.

    Brian> 3.  We propose that no changes be made to the
    Brian> Diffie-Hellman key agreement text in PKINIT.  PKINIT
    Brian> currently refers to the Kerberos crypto draft as to how a
    Brian> session key is derived from DH key agreement.  The crypto
    Brian> draft determines how many bits of the shared secret are
    Brian> passed into a random-to-key fnction and what that
    Brian> random-to-key function is.

We seem to have convinced ourselves that the current text is secure.
However it does not allow for DH parameters to be cached.  Microsoft
believes this is an important feature; I agreed to help them specify
it but have not had time to work on text (and will not have this time
before the draft deadline).

[ERIC] Sam, when can you commit to drafting some text for review by the
WG?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jul 2004 15:38:01 -0400

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:

    Eric> [ERIC] I seem to remember a different proposal. I don't
    Eric> recall restricting the empty field to only the case where no
    Eric> CAs were used. I do recall allowing it to be blank, based on
    Eric> KDC policy.

    Eric> Regarding your recollection of Nico's original proposal; can
    Eric> you elaborate on which certificates have to be known ahead
    Eric> of time? The Root certificate? The CA cert? Or the End
    Eric> Entity cert? 

The end entity cert needs to be known to the KDC in order to leave the
field black.

    Eric> I just don't understand how filling in the
    Eric> field with a list of CA certs accomplishes anything (other
    Eric> than additional, unnecessary complexity). Certs and PKIs are
    Eric> based on chains of trust back to a Root, which must be
    Eric> trusted ahead of time. If the KDC properly validates the
    Eric> chain of trust through a set of CA certs, why must it always
    Eric> fill in the object? Consistent with the original proposal at
    Eric> the Interim meeting last September, I believe this should be
    Eric> left to policy as no one has provided a good security reason
    Eric> for requiring that it be filled in.

The good security reason is simple.  We want application servers to be
able to know what trust path the KDC used.  Traditionally in Kerberos,
the application server knows what entities are involved in the
authentication decision and can use this information for local
authentication policy.

So, if you trust a root cert and a CA cert, then both names need to be
in the trusted certifiers field.  If you happen to know the CA cert
dirctly and thus didn't need to check that the CA cert was signed by
the root cert, then you don't need to include the root cert in the
trusted certifiers.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 14:33:57 -0500

> do recall allowing it to be blank, based on KDC policy.

It's important to have a way for KDCs to display the validated chains to
acceptor principals so that they can apply additional policies as well,
particularly, but not only, when the acceptor principal is a cross-realm
TGS.

The reason it's important is the same reason that we have a transited
field in tickets for describing the Kerberos V realm path transited by
the client to get to the service.

We've settled on the names of the CA certs in the trust chain that was
validated.  For self-signed certs there are no such names, thus
emptiness is used to signal the use of self-signed certs.

Of course, any realm's KDCs can lie and claim that all client certs
for which it issues tickets using PKINIT are self-signed.  This is no
different than the situation with the transited path field in Kerberos V
tickets today, ...

...though we might want to address it later, when we have PKCROSS, by,
say, adding authorization data types for passing the client's and
transited path realm's certificates and a binding of the entire
transited path to the client's cert (or to the initial TGS', in
non-PKINIT cases), so that the entire transited path and every transited
certs's trust chain, as well as the client's, can be verified.

So it seems fine for a KDC to lie about the trust path verification, but
we hope they don't, intend to frown upon such a practice, and we hope to
be able to further address the problem in PKCROSS.

> for requiring that it be filled in.

We're talking about filling a field with the _names_ of the CA certs,
not the certs themselves, in the client cert's trusted path that was
validated by the KDC.

As to why we want this done, see above.

As for leaving it the matter to realm policy, it's clear that KDCs can
lie about this, and that it isn't useful to try to prevent this until we
have PKCROSS as we can't have a complete way to do that until we have
PKCROSS.  See above.

In other words: go ahead, let your KDCs lie about its clients having
self-signed certs, but let the PKINIT frown upon that.

> [ERIC] Not sure that I agree.

See above.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jul 2004 15:41:35 -0400

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

    Nicolas> Of course, any realm's KDCs can lie and claim that all
    Nicolas> client certs for which it issues tickets using PKINIT are
    Nicolas> self-signed.  This is no different than the situation
    Nicolas> with the transited path field in Kerberos V tickets
    Nicolas> today, ...

By can here, you mean that the code can be written, not that such
implementations conform to pkinit presumably.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 15:12:00 -0500

> implementations conform to pkinit presumably.

Right; "can" as in "it's feasible to," not as in "conformant
implemantions may."

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Wed, 14 Jul 2004 13:28:39 -0700

> self-signed certs, but let the PKINIT frown upon that.

In what language should PKINIT frown upon it?  "MUST"?  "SHOULD"?

Brian Tung <[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jul 2004 16:38:40 -0400

Brian> Nicolas Williams wrote:
    >> In other words: go ahead, let your KDCs lie about its clients
    >> having self-signed certs, but let the PKINIT frown upon that.

    Brian> In what language should PKINIT frown upon it?  "MUST"?
    Brian> "SHOULD"?

MUST include the correct information in trusted certifiers, just as
KDCs MUST fill in transited realms.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 15:40:58 -0500

> In what language should PKINIT frown upon it?  "MUST"?  "SHOULD"?

RFC1510/clarifications do not use RFC2119 terminology about the
transited field of Ticket, but I not that it's not an optional field and
that much the same considerations that apply to it apply here as well.

So I say "MUST."  Remember, "MUST" here does not make it infeasible for
a KDC to lie and claim that the client used a self-signed cert; it just
makes such a KDC non-conformant in a way that many users may not care
about.

Nico
--