revocation feature in Kerberos

[Nordgren, Bryce L -FS]

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

Knowing how to contact services sounds like valuable information usable by more than the KDC (conversely, it doesn't sound like a new task that the KDC should take on.) DNS SRV records can map host and port to service name. How to map service name to service principal?  The service name<->service principal mapping involves centralizing/standardizing configuration which is typically decentralized in the application's config file (either for the KDC alone, or for the benefit of all). This seems a necessary prerequisite for revocation to work. How? and Who? seem to be relevant questions.

What about services on mobile client workstations, such as an NFS client connecting from employee's home or a partner's institution? Trust that the server will revoke, or try and figure out how to traverse the home/other-organization's router+firewall? It seems that this a the use-case which would introduce a requirement for symmetric connectivity. It may not be important that revocation work for this case, tho.

Bryce




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.