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

[Jeffrey Hutzelman]

On Wednesday, January 04, 2006 05:04:33 PM -0800 Adam Megacz 
<megacz@cs.berkeley.edu> wrote:

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

That's data, not state.  As I said, KDC's are nearly stateless.  They don't 
record things about tickets they've issued, or principals to which they've 
issued tickets, or any such thing.  They do maintain a short-term replay 
cache.

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

Well, you already have potential problems with filling the replay cache or 
auditing log with too large a volume of requests.  There are a variety of 
possible ways to deal with these problems, but none of the problems get 
worse due to the use of PKINIT, whether with pre-registered principals or 
not.  What matters is the volume of requests, not the number of distinct 
principals for which you might issue tickets.

That said, no KDC in its right mind would issue tickets based on 
certificates signed by a CA it didn't trust.  That would be stupid.


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

Actually, it's no different.  Any disk-filling sort of problems still scale 
with the volume and rate of requests, not the number of possible principal 
names.  And I daresay my KDC can process requests more efficiently than you 
can generate new public key pairs.

In any event, I don't see this as a common deployment scenario for 
Kerberos.  I doubt many realm administrators will want to issue tickets to 
any random bozo who comes up to them.  I doubt many applications will care 
to support an authorization model in which Kerberos principals are 
identified to them by public keys rather than by principal names.  Most of 
those that do already support some form of public-key-based authentication 
at the application layer, and would gain little from using Kerberos for 
that.  AFS isn't there yet, but could be within a year, if someone cared 
enough to design and implement a suitable GSSAPI mechanism.  Getting it 
"right" might take a bit longer, depending on how long the GSSAPI identity 
work currently going on in KITTEN takes.

-- Jeff