[kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred()

[Nico Williams <[e-mail]>]

The subject came up today, and I thought I'd state my opinion here about
permissible and impermissible side-effects of GSS_Acquire_cred().  (And,
indirectly, GSS_Init_sec_context() and GSS_Accept_sec_context().)

It's certainly permissible for GSS_Acquire_cred() to have some kind of
side-effects.

It's clear that GSS_Acquire_cred() was intended to get a "handle" to
credentials that exist.  But side-effects crop up if we want it to bring
credentials into existence that weren't there before -- that's a big
side-effect, but it's also idempotent, and GSS apps in particular can't
really notice such a side-effect as the state transition is from
no-credentials to have-credentials [for some NAME(s) anyways].

For example, there have been implementations that if necessary would
pop-up a modal dialog asking the user for their password in order to
acquire credentials that would otherwise be unavailable.  Such an
implementation has two side-effects: a) the modal interaction with the
user, and b) that credentials become available that had not been there
before.  In some sense (a) is not a side-effect (it's not a modification
of the state of the world).  (b) is a side-effect, but an idempotent
one (see above).

Can we go from examples to principles?  Let's try.

I can see three principles:

a) no side-effects outside caching,
b) idempotent side-effects only,
c) what principles?  anything goes.

The [implementation- and Kerberos-specific] question that came up was
(rephrased by me; others can chime in with additional questions like it):

  Given a keytab[0], can a call to GSS_Acquire_cred() change the
  contents of a session's ccache[1], and if so, can it change the
  default principal name?

Principle (a) would lead to a generic answer like: tickets can be
cached, but notions of default principal cannot be set nor changed.

Principle (b) would lead to a generic answer like; tickets can be
cached, the caches can be created, and the notion of default principal
can be set if not already set, but cannot be changed.

Principle (c) allows any reasonable answer.

In implementation-specific terms, (a) means that GSS_Acquire_cred() can
acquire a new TGT for the same principal(s) for which the default
cccol[2] or default ccache has TGTs, and it can re-initialize such
ccaches, but it cannot change the default principal for a session.  This
leaves a corner case: you have a keytab but no cccol/ccache.  For that
case the answer is that if there's no way make a good selection
of default principal, then the the TGT(s) should be saved somewhere if
possible, but still not be made available as the default credential
(perhaps this means that the TGTs are acquired every time they are
needed, and never cached).

In implementation-specific terms, (b) means the same as (a) except that
if there's no cccol/ccache already, then the implementation can pick any
principal it likes from the keytab, and set it as the default principal.

My preference is for (a), and if I can't get (a) (certainly some
implementations don't adhere to it) then (b); (c) is out.

[0] A file containing long-term secret encryption keys for Kerberos
    principals.

[1] A file containing Kerberos tickets, possibly acquire with use of a
    keytab.  Typically a ccahce has tickets for just one client
    principal.

[2] A collection of ccaches, each for a different client principal.

Nico
--