On Wednesday, January 04, 2006 05:04:33 PM -0800 Adam Megacz
<[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
