Difference between revisions of "Release Meeting Minutes/2009-08-04"

Latest revision as of 22:56, 3 January 2011

Sun work on credential management for cron jobs:

• The goal is to maintain credentials to access homedirs for processes that run from cron jobs.
• A utility called ktset uses special service/host/user-specific principals (called "user-derived principals") which have access to the homedir.
• ktset creates a keytab with the derived principal, in cooperation with a back end to allow creation of these principals in the KDC.
• A new module pam_krb5_keytab kinits with the keytab created by ktset.
• There is another piece on the NFS server to provide access to the user-derived principal as if it were the user principal.
• The existing Solaris daemon kticketwarnd (which provides warnings when login tickets are about to expire) will be extended to re-get credentials from the user-derived principal keytab.
• CCAPI (or something similar) is desirable for maintaining credentials for user-derived principals so that gssd can pick the appropriate credentials to use based on the uid and credential process group. This would be also be possible using file credential caches and a naming scheme, but would be less elegant.
• Shawn has encountered some issues with CCAPI:
  • Messaging is not abstracted; Sun would prefer to use XDR over the home-grown message format.
  • It's unnecessarily complex (and large); for instance, the twelve different messages could be narrowed down to three or four by moving more responsibility into the back end.
• Shawn has some interest in exploring KCM as an alternative (but hasn't looked into it yet); Greg doesn't think it will be terribly interesting since it doesn't try to address multiple client credentials.

Luke's work for 1.8:

• Has been implementing S4U2Self and S4U2Proxy.
• Greg notes that S4U2Self tickets could be printed by the AS; the main difference is that an S4U2Self ticket can contain PAC information.
• S4U2Proxy enables a service to get tickets from a user for another service, possibly using tickets obtained using S4U2Self. If enabled, this effectively causes one service to be trusted with respect to another, but the KCD can impose restrictions on what users and target services are allowed for a given intermediary service.
• There was a question on the list about PAC verification. Currently it is not easy for an application to do verification because we don't provide enough information about what key is needed.
• Heimdal now does PAC verification in gss_accept_sec_context. However, the application cannot be sure that PAC verification was done since old versions of Heimdal (as well as current versions of MIT krb5) don't verify. So Luke is thinking that an explicit new GSSAPI extension for PAC verification is better.
• Some repetition of the usual angst over PKINIT--whether we selected the right implementation, what we document and don't document, what versions of the draft protocol we need to support for interoperability, etc.. Some of this may wind up on Luke's plate but we need a better understanding of what work should be done.

Shawn's wish-list for 1.8:

• Sun's Java team has requested Microsoft non-ASCII character set compatibility for principal names and passwords. (This requires IETF work since the krb5 protocol specifies ASCII only.)
• PAC verification, as discussed above.