On Thu, Jul 31, 2014 at 6:49 PM, Nordgren, Bryce L -FS <[email protected]> wrote: >> No, the only way in which a revocation protocol for Kerberos makes any >> sense to me is one that involves propagating notices to those services (TGSes >> included) for which the principal in question got extant tickets. > > Good. :) Do that. > > Seems that the KDC would have to be upgraded with connection info for > services (can't trust that instance name == dns; can't trust that the service > is running on the standard port). > > Oh, and if the service is httpd, slapd, or nfs using principal > "host/example.com", how does one figure out which service to contact?
The KDC would have to know how to contact them, or infer it from the principal name. As for _how_ to communicate the revocation, one possibility would be for their realm's revocation service to connect and authenticate as anonymous (say) with a ticket bearing authz-data listing the revoked principal (or not-before time, if revoking only tickets issued before a password change). (Revoking _many_ principals would be done by revoking an entire realm with a not-before time.) Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
