Keytab-based initiator creds design

Greg Hudson ghudson at MIT.EDU
Thu Jun 7 00:41:25 EDT 2012


Here's the design outline several of us came up with in verbal
conversation.  It's a bit more complicated than I would like, but
addresses most of the objections people had.

1. We do keytab-based initiation if:

A. We don't have creds in a default ccache, but we do have a keytab and
the KRB5_KEYTAB_PRINCIPAL environment is set to a principal within it.

B. The app passes a desired_name which we don't have creds for but which
is present in the keytab.

C. At init_sec_context time, krb5_cc_select can authoritatively
determine the client principal for the target, and and we don't have
creds for that principal but it's present in the keytab.

We will also do keytab-based initiation to refresh credentials which we
remember (through cc config variables) were intiated from a keytab and
for which it's an appropriate time to refresh.

If we want to do the AS req at acquire_cred time (like Heimdal does),
KRB5_KEYTAB_PRINCIPAL has to take precedence over krb5_cc_select.  If we
defer until init_sec_context time (like Solaris), cc_select could take
precedence.  I think it's reasonable to defer the AS request until
init_sec_context time (we'll be doing that for IAKERB anyway), but it
may be right for KRB5_KEYTAB_PRINCIPAL to take precedence over cc_select
anyway.

Note that in all of these cases, there is administrative or application
information indicating which principal to use from the keytab.  We never
guess.

2. We store the resulting credentials in:

A. The cache collection, if there is one.

B. The default cache if no collection is present and
KRB5_KEYTAB_PRINCIPAL was used.

C. A memory cache (used repeatedly within the same process) if no
collection is present and desired_name or cc_select was used to
determine the principal.

Some of the principles and constraints leading to this design were:

* If an application causes keytab-based initiation to happen without aid
from the administrator, the application should not affect (or be
affected by) the behavior of GSSAPI-enabled applications using the
default cache.  For example, if an LDAP server running as root manages
to use keytab-based initiation to perform replication without the aid of
environment variables, that should not cause an administrator who logs
in as root to start trying to authenticate as ldap/hostname with ssh.
(Conversely, if I log in as root and kinit as myself in order to ssh, I
shouldn't break the LDAP server's replication.)

* But if the process environment causes keytab-based initiation to
happen, we should make sure to cache the result.  If someone is setting
KRB5_KEYTAB_PRINCIPAL, they can also set KRB5CCNAME.

* This design doesn't require gss-krb5 to pierce the ccache abstraction
layer (by defining a separate default ccache location for
keytab-initiated creds, or only using the default cache if KRB55CNAME is
set).

* Getting the initiator name from the application or from cc_select
allows for richer and more robust user interfaces than getting it from
the environment.  So while it would be simpler to just go forward with
KRB5_KEYTAB_PRINCIPAL, it would be a disappointingly narrow design.
Although it's currently rare for an application to provide the initiator
name, it may become more common now that cache collections are available
in Unix krb5 implementations.

I'm still pondering whether it might be workable to implement this stuff
at the krb5_get_credentials/krb5_tkt_creds layer.  That would have
interesting applications for auxiliary use cases like FAST armor
ccaches, but might simply have too many consequences to be reasonable.

Comments are still appreciated.  This will, of course, all go into the
project writeup assuming it remains the likely design.



More information about the krbdev mailing list