kerberos keyring ccache
lukeh at padl.com
Mon Jan 23 22:22:36 GMT 2006
>1) identify whether current (perhaps current->fsuid) already has a krb5
>service ticket for a particular server/service
>2) if no service ticket, request a service ticket for current
For user-space, these are done by the ccache library. For kernel-space,
one nice approach is to have another keyring type for GSS security
contexts, and have /sbin/request-key (in user space) initialize the
security context (like gssd does now). The fact that the keyring ccache
type may be used is completely orthogonal in this case.
>3) if ticket is expired, refresh the service ticket
We discussed using /sbin/request-key to do this but given the keyring
ccache type is a "user" keyring, I think the consensus is to do this
in a (ccache-type agnostic) daemon.
cf. ktkt_warnd in Solaris 10, where pam_krb5/kinit registers the
principal and ticket expiry time with the warn daemon, and the warn
daemon renews tickets.
>4) upcall to samba tooling (similar to Samba's ntlm_auth used by some
>apache modules etc.) to SPNEGO authenticate with that ticket if SMB/CIFS
>session is not authenticated
Worth looking at what NFSv4 does today with gssd, and what it might do
tomorrow with a GSS context keyring type.
More information about the samba-technical