On Thu, Jul 31, 2014 at 6:22 PM, Nordgren, Bryce L -FS <[email protected]> wrote: > Revocation schemes must account for situations where parties other than the > authenticated user cannot contact the user's home KDC.
A revocation protocol that propagates revocation notices towards the services accessed by the user will not require connectivity in the opposite direction, and it might not even involve any firewall configuration changes. KDC->KDC revocation notices should be sent on port 88, and KDC->service notices should be sent in realm- or app-specific manner, so no problem there either. A revocation protocol more like OCSP (not stapled, so it'd have the problem you mention) would be silly: you might as well just turn service ticket lifetimes down and be done! 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. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
