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

________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to