kerberos keyring ccache

[Luke Howard]

Hi Steve,

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

-- Luke

--