Subject: PKINIT issues, proposals

From: Brian Tung <[email-masked]>
Date: Mon, 12 Jul 2004 15:40:30 -0700

There has been much discussion on various PKINIT issues over the last
few weeks, but it seems (at least to us) that no clear consensus has
been reached.  In an attempt to foster enough consensus to proceed, we
make the following proposals.  We emphasize that these proposals are not
intended to suppress any particular viewpoint, or predicated on absolute
certainties--only that our principal goal is to move the draft ahead
based on available information.

1.  We propose to withdraw the OCSP mechanism from PKINIT.  Although it
    has potential benefit, it is not integral to the operation of PKINIT.
    It also represents an additional point of potential delay for
    advancement.

    In the absence of an overriding argument one way or the other, we
    feel that given a choice between including OCSP and not including
    it, it is better to be conservative and withdraw it from the PKINIT
    draft.  We do not believe this strikes a damaging blow to the
    mechanism itself, since there seems to be significant support within
    the working group for laying down a specification for it.  We simply
    think it is better done in a separate draft.

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

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

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

    Therefore, whether and how DH key derivation needs to be modified
    should not affect the specification of PKINIT.  If there is a need
    to change the key derivation procedure, this should be done in the
    Kerberos crypto draft, allowing the change to be re-usable outside
    PKINIT.

    Furthermore, until this time there had been no evidence to indicate
    that the currently specified DH key derivation was not sufficiently
    secure.

Brian Tung <[email-masked]>
Sasha Medvinsky <[email-masked]>
Eric Rosenfeld <[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Jul 2004 13:59:56 -0400

>>>>> "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.

    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.

    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).

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Jul 2004 23:12:41 +0200 (MET DST)

Hi,

>     It also represents an additional point of potential delay for

Now THAT confuses me!

I thought we had consensus that OCSP revocation checking was a good
and valuable thing to have and that having the KDC include a
cached OCSP response along with his own certificate would be
a much simpler and much more robust approach.

Why do you suddenly want to drop OCSP revocation checking altogether?

It makes me feel that someone already had OCSP tunneling implemented
and would have been happy to get it rubber stamped the existing
implementation, but our much better suited approach would mean some
amount of work for everybody (and a level playing field).

I'm really puzzled why a feature that seemed to be very important
has lost all interest AFTER a significantly less complex solution
has been proposed.

What is the problem in defining where the cached OCSP response
should be put in the KDC handshake reply?

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 14 Jul 2004 18:24:06 -0400

> a much simpler and much more robust approach.

Some people thought that.  In my opinion a concensus had not been reached.
I would _very_ much like the working group to reach a concensus on this 
issue, one way or the other.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 18:43:29 -0500

> issue, one way or the other.

I don't know who Brian meant by "we" -- I strongly support that there be
a way for PKINIT clients and servers to exchange OCSP responses for
their certs.

I just posted, to this list, an I-D that specifies a method for doing
just that in a way that through a pre-authentication that is separate
from PKINIT's, this way we can remove all mentions of OCSP from the
PKINIT I-D.

This I-D is surprisingly simple, and I'm confident that it will still be
simple by the time it survives last-call.

Cheers,

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Wed, 14 Jul 2004 17:08:27 -0700

Nicolas Williams wrote:
> I don't know who Brian meant by "we"

I meant "the authors."