On Tuesday, January 03, 2006 05:15:17 PM -0800 Adam Megacz
<[EMAIL PROTECTED]> wrote:
"Douglas E. Engert" <[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
