Subject: #507: PKINIT 015 - Indicating PKINIT support

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Sep 2004 18:30:42 -0400

>>> Sep, 2003 interim meeting <[email-masked]>
> Sam Hartman brought up the point that there's no way for the KDC to
> indicate that it does PKINIT, but it was decided that this would be
> discussed later.

Well, it is now "later" by about a year.  So I'd like to see some 
discussion so we can resolve this issue.

Is such a mechanism required?  Why or why not?
In what circumstances will it be used?
What are the requirements?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Sep 2004 17:43:34 -0500

> >indicate that it does PKINIT, but it was decided that this would be

The KDC can indicate that PKINIT is required.

> Is such a mechanism required?  Why or why not?

It might be useful for informational purposes, but clients should not
rely upon it, so no.

There is/may be no way to integrity protect a KDC's KRB-ERROR indicating
no support for PKINIT, nor can an indication of support for PKINIT be
integrity protected if the client cannot validate the KDC's
certificate(s).  If client has certs, let it try PKINIT, and if the
client is willing to fallback to non-PKINIT pre-auths, let it do so;
knowing whether the server supports PKINIT does not help the client
decide.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Sep 2004 17:43:34 -0500

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Sep 2004 19:26:29 -0400

I believe such a mechanism is strongly desirable and probably
required.  I'm aware of at least one implementation of pkinit that
cannot function unless it can learn from the KDC whether a principal
requires pkinit.

In attempting to design GUIs that support both pkinit and non-pkinit
operation, MIT has found that we need to know whether a particular
principal supports pkinit at the current time.  Even if a smart card
is available, we may not know that it is required for Kerberos.

I think the simplest way of accomplishing this goal is to require (or
strongly suggest) pkinit KDCs include the pkinit padata type for
PK_AS_REQ in the set of padata in the preauth_required error.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Sep 2004 19:11:07 -0500

> cannot function unless it can learn from the KDC whether a principal

Well, yeah, the KDC needs to be able to indicate that PKINIT is
required, but I thought it was already able to do so...

> is available, we may not know that it is required for Kerberos.

Be careful with downgrade attacks.

> PK_AS_REQ in the set of padata in the preauth_required error.

Yes, but this seems obvious to me from clarifications.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Sep 2004 20:42:27 -0400

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

    >> I think the simplest way of accomplishing this goal is to
    >> require (or strongly suggest) pkinit KDCs include the pkinit
    >> padata type for PK_AS_REQ in the set of padata in the
    >> preauth_required error.

    Nicolas> Yes, but this seems obvious to me from clarifications.

The pkinit draft does not specify this and especially without a
normative reference to the preauth draft I don't think it is implied.

But we seem to be in agreement about what should happen.  

I'm not really worried about downgrade attacks in this instant.  In
one case the user will be asked for a password; in the other they will
either be asked to unlock a cert or to enter a smartcard pin.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Sep 2004 21:44:22 -0500

> But we seem to be in agreement about what should happen.  

Yes, what you said.

> either be asked to unlock a cert or to enter a smartcard pin.

Well, ok, I guess users can choose which to do and, in any case, might
not even have a password they could type in (ha! imagine that...).

Nico
--