RX Kerberos 5 security class requirements of Kerberos library
Nicolas.Williams at sun.com
Tue Jan 2 13:40:54 EST 2007
On Tue, Jan 02, 2007 at 12:24:29PM -0500, Jeffrey Altman wrote:
> This function is being written explicitly to provide service to service
> authentication when the services share the same key. The two scenarios
> * Service A authenticates as service A to service B where the two
> services share the same key
This shouldn't require crypto if the two services are on the same host
(think getpeerid()/getpeerucred()). If they are on different hosts in
the same cluster then authenticating A to B using shared secrets or
what have you instead of Kerberos V should suffice.
> * Service A authenticates as authenticated user U to service B where
> Service A is trusted to do so.
> (Think Samba or WebDAV export of AFS without credential delegation
> of the client's credentials.)
Same as above.
> Without krb5_generate_creds_with_keytab there are two alternatives that
> AFS can pursue:
> (1) AFS can use the keytab entry to query the KDC for a ticket for itself.
> Doing so removes the ability of multiple AFS services on the same
> to communicate when the network connection goes down unless there is a
> KDC instance on the machine.
You're using Kerberos V already, so you have to accept online
> (2) AFS can use a token format that is independent of the Kerberos 5 ticket
> in which case AFS can print as many tokens as it wants without
> the KDc.
> Do you have any further thoughts on the subject?
... I say use (2) as your model says that B trusts A to impersonate any
user (because you want to avoid credential delegation). But note that
you'll want to forward U's decrypted Ticket to B so B can evaluate any
authorization-data, OR you'll want to forward a description of U that
takes into account all U's Ticket that A cared about (assuming that B
wouldn't care about any other part, which for AFS seems like a safe
Alternatively go back to credential delegation.
More information about the krbdev