[OpenAFS] "public" pkinit service without database-overflow
Tue, 03 Jan 2006 22:36:24 -0500
On Tuesday, January 03, 2006 05:15:17 PM -0800 Adam Megacz
> "Douglas E. Engert" <email@example.com> 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.