krb5-1.12.1 and client keytab file

[squidmobile@fastmail.fm]

30 may 2014

greetings,

again, many thanks to michael.

>>$ export KRB5_CLIENT_KTNAME=<location> # e.g. $HOME/client.keytab
>>$ app-with-gssapi-calls # in my case curl

i ran some tests, and they proved most interesting.

the good news is that
  KRB5_CLIENT_KTNAME=some.key.file app-with-gssapi-calls
worked.

the bad news is that it did not always work quite as expected.

if you do NOT have a tgt, this syntax works and works well.  it
obtains a tgt with the principal specified in the client keytab.
the app (in my case ldapwhoami) worked exactly as expected.

(please note that i cite cyrus-sasl and openldap because that is
the only app i currently have that uses gssapi in quite this
fashion.  i expect any other gssapi app to behave in a similar
manner.)

complications arise if you already have a tgt.  if that tgt is
valid, the cyrus-sasl library will use it and ignore the principal
in the KRB5_CLIENT_KTNAME file.  that current active principal
could be very wrong for the app in question.  if that tgt exists
and is expired, the app fails because of the expired tgt; it does
NOT obtain a new tgt with the specified principal.

if you use the KRB5CCNAME=DIR:... variable setting, things can get
even more interesting.  if you run kdestroy -A and let the app
obtain a tgt, that tgt appears as a random secondary tgt in the
credential cache  directory.  it leaves the primary tgt unchanged.
klist does not show the new tgt, but klist -A shows its existence.
kswitch -p can make it the primary tgt.

considering the potential clash between principals, i tried the
case of
  KRB5CCNAME=MEMORY: KRB5_CLIENT_KTNAME=some.key.file  \
    app-with-gssapi-calls
this worked extemely well.  no clashes occured with any other tgt,
with either the FILE:... or DIR:... syntax.  however, i believe
some dialects of unix make all of memory available via things like
/dev/kmem or /proc/core, which could pose security issues...

i suppose you could run some FILE: games, such as (pick one)
  kdestroy -A
  rm ${KRB5CCNAME}
  KRB5CCNAME=FILE:/tmp/tgt_${RANDOM}  \
with
  KRB5_CLIENT_KTNAME=some.key.file  app1-with-gssapi-calls  &

ditto for
  KRB5_CLIENT_KTNAME=other.key.file app2-with-gssapi-calls  &
to clear the credential cache for the second app.

one other thought:  what happens to app-with-gssapi-calls if it
runs past the time limit for the tgt obtained by this mechanism?
i suspect app-specific behavior.  for example, openssh validates at
the start of the connection and any given connection will run
forever, but openldap validates every transaction.

i wish the krb5 documentation people would include some variant of
some of these observations in the documentation that comes with
krb5.  i think their recommendations would be most helpful.

many thanks for the tip.
frank smith

-- 
http://www.fastmail.fm - The way an email service should be