[OpenAFS] "public" pkinit service without database-overflow risk?

[Jeffrey Hutzelman]

On Tuesday, January 03, 2006 05:15:17 PM -0800 Adam Megacz 
<megacz@cs.berkeley.edu> wrote:

>
> "Douglas E. Engert" <deengert@anl.gov> writes:
>> And this is where PKINIT may play a much bigger roll. The "cross trust"
>> is done at the PKI level, and certificates are enrolled in the local
>> realm as needed.
>
> Is it feasible for a PKINIT-aware KDC to issue session keys to
> KRB_NT_X500_PRINCIPAL's without having to retain any record of the
> transaction (ie not keeping a copy of the certificate or session key)?
>
> I'm not aware of any existing KDC implementations that will issue
> tickets to an entity that isn't already in the database -- or for
> which there is not already an explicit "mapping" entry of some sort.
> The pkinit patch for Heimdal requires a "pki-allowed-principals"
> explicit mapping section in the KDC config.
>
> In theory this should be possible, although to prevent denial of
> service attacks, it would have to be done as I mention in the first
> paragraph -- it would have to be "stateless".
>
> From RFC4120 and the PKINIT draft 16 I don't immediately see any
> problems with this.  Could somebody with more knowledge of Kerberos
> than I comment on potential obstacles to this?

For starters, you should look at more recent versions of PKINIT than that.
The current version is draft-ietf-cat-kerberos-pk-init-31.txt, available 
from your favorite I-D repository mirror.

There is nothing which would prevent a KDC from issuing tickets to a client 
based solely on the certificate it presents, without any prior record of 
the client's existence.  However, that's not the same as issuing a ticket 
for any random cert presented by a client -- the KDC would have to be able 
to validate the certificate based on some existing trust anchor.

Note that KDC's are already stateless.  Every KDC implementation I know of 
logs the requests it handles for debugging and auditing purposes, but none 
actually maintain any "state" other than a short-term replay cache.

-- Jeff