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

[Adam Megacz]

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

Hrm, I don't think I've been clear here -- in current KDC's, the
"state" I speak of is the list of principals and their associated
secret keys, which may be either static or created on the fly.  


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

Right.  I guess the question I'm asking is can this be made robust
enough that the KDC can issue tickets for certs certified by a CA who
might decide to try to overload the KDC by issuing a bajillion "spam
certificates" and ask for a principal to be allocated for each one of
them, thereby filling up the KDC's disk if it needs to keep an on-disk
record of all principals for whom it has issued tickets.

The other (totally separate) use case I'm thinking of is one
"authorization with only trivial authentication" where you "are" your
public key.  So the KDC issues a ticket saying nothing more than "this
person has been confirmed to posess the private key corresponding to
public key XYZ" (where XYZ actually literally appears in the principal
in some form).  In this case the disk-overload problem is much more
real and serious.

  - a


-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380