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

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2015 19:18:17 -0500

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

---

From: Simo Sorce <[email-masked]>
Date: Thu, 19 Mar 2015 09:32:14 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Mar 2015 10:17:19 -0500

> can retroactively mandate a), but b) should be good enough.

ISTR hearing someone (you?) say (a couple of weeks ago on a krbdev call)
that creating a default ccache with one of N > 1 principals' keytab
creds is sometimes surprising to users, and I can see why it would be!
This is a form of (b).  The problem here is setting the default
principal name when none had already been set -- a non-trivial side-effect.

I'm inclined to consider (b) a bug.  A low-priority bug perhaps, but a bug.

Implementations could do something else.  E.g., not cache (thus increasing
load on clients and KDCs), or cache in a "shadow default ccache", or
switch to DIR ccache.  Those are details.  The main thing is that (b) is
surprising.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Thu, 19 Mar 2015 11:20:09 -0400

> switch to DIR ccache.  Those are details.  The main thing is that (b) is

I guess it may be surprising in some cases, and expected in others,
unfortunately.
If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you
expect a default ccache to be created with whatever is in the keytab for
example. But you'd be surprised otherwise.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Mar 2015 11:28:49 -0500

> example. But you'd be surprised otherwise.

Since it's both, sometimes surprising and sometimes expected, you get to
pick what to end up with.  Perhaps one behavior will cause more customer
calls than the other.

But I think there are compromises that get you (a) without breaking
anyone.  Again:

 - have a shadow default ccache for the case of acquiring a credential
   from a keytab when there is no default ccache

 - use the DIR ccache (does it have the option of not setting a default
   ccache in the collection?)

 - don't cache tickets when the default ccache does not exist

 - if there are keys for only one principal in the keytab, then set
   the default principal, else don't (and use one of the above fixes)

And you could always add yet another environment variable, and/or
krb5.conf parameter.

To me it seems clear that GSS applications that do simple things like
GSS_Init/Accept_sec_context() with the GSS_C_NO_CREDENTIAL, or which
call GSS_Acquire/Add_cred(), do not cause other processes in the system
to "break".  Actually, this should be true for all GSS apps that do not
call GSS_Store_cred() (whose entire purpose is to have side-effects).

Even if you change nothing, I'm inclined to say that (a) is preferred
and note that (b) is what one sometimes gets, therefore one must read
the implementation's docs.  I'd like to see this fixed (see above).

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Thu, 19 Mar 2015 13:04:46 -0400

> the implementation's docs.  I'd like to see this fixed (see above).

Would you consider an explicitly set KRB5CCNAME env variable as an
indication the admin is ok with acquired credentials ending up there ?
Ie a) but using KRB5CCNAME presence as an indication a ccache can be
used ?

Simo.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Mar 2015 12:33:06 -0500

> Ie a) but using KRB5CCNAME presence as an indication a ccache can be

That helps, though there can still be non-determinism when the ccache
does not exist yet.  (But if the admin/user set it, why wouldn't they
also kinit -k to remove all doubt?)

---

From: Simo Sorce <[email-masked]>
Date: Thu, 19 Mar 2015 13:44:01 -0400

> also kinit -k to remove all doubt?)

Because, at least with the current implementation of the Keytab
initiation feature in MIT, if you kinit explicitly then
gss_init_sec_context will not take over and keep initiating when
credentials expires etc...

I understand this may be simply an implementation issue/bug and it can
be decided differently, but in general keytab initiation is used to
allow unattended systems work on their own, so the admin will start a
service with all the evn var set right and let it to it's own thing,
requiring to script a manual kinit would defeat the purpose.

So I am trying to see if you think a) is compatible with something
priming an empty initial ccache provided that both KRB5CCNAME and
KRB5_CLIENT_KTNAME have been set in the environment (both required).

Simo.

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 28 Mar 2015 14:40:44 -0400

> KRB5_CLIENT_KTNAME have been set in the environment (both required).

Simo,

I would be more comfortable with an environment variable or krb5.conf
option that explicitly states to perform X behavior.  The existence of
environment variables that are useful on their own in combination should
not should trigger an unexpected behavior.  Especially when those
environment variables are interpreted different by different Kerberos
distributions.

Just my two cents ...

Jeffrey Altman

---

From: Simo Sorce <[email-masked]>
Date: Sat, 28 Mar 2015 16:43:55 -0400

> environment variables are interpreted different by different Kerberos

I think KRB5_CLIENT_KTNAME fits the description, its only use is to
indicate which credentials to use for keytab initiation. I think it fair
to assume that if an admin has explicitly set it that he wants to allow
keytab initiation.

Simo.