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

[Simo Sorce <[e-mail]>]

On Tue, 2015-03-10 at 19:18 -0500, Nico Williams wrote:
> 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.

I tend to agree with you in abstract, however given b) is the actual,
and I would say expected in many cases, behavior, I do not't think we
can retroactively mandate a), but b) should be good enough.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York