RX Kerberos 5 security class requirements of Kerberos library

Nicolas Williams 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
> are:
> 
>  * 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
> machine
>     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
infrastructure, but...

> (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
> contacting
>     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
assumption).

Alternatively go back to credential delegation.

Nico
-- 



More information about the krbdev mailing list