[33382] in Kerberos
Re: Inittab launching K5start too soon
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri May 13 08:22:54 2011
From: Greg Hudson <ghudson@mit.edu>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <BANLkTimPU5WqtTNe+GguT69kUBzo+WEOvg@mail.gmail.com>
Date: Fri, 13 May 2011 08:22:46 -0400
Message-ID: <1305289366.2034.173.camel@t410>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Thu, 2011-05-12 at 13:58 -0400, Nico Williams wrote:
> Really, what should happen is that mech_krb5's gss_init_sec_context()
> automatically gets a TGT using a keytab if there's a keytab available.
> Solaris' implementation does that, though sadly it only does it for
> processes running as root.
I've thought about handling this at the ccache layer, although I was
never comfortable with the kind of syntax required to stuff a keytab
name, a subsidiary ccache name, and some auxiliary parameters into a
ccache specification.
AUTO:kt=FILE:/etc/krb5.keytab;cc=FILE:/tmp/filename;min_life=1h ... it
doesn't seem very friendly.
So, maybe it's simpler to handle it at the GSSAPI layer. Heimdal does
this, storing the acquired credentials in a memory ccache. That
approach could generate a lot of unnecessary AS-REQs, particularly in
combination with SPNEGO. On the plus side, it finesses the issue of
whether to get a new credential with the keytab or use an existing one
which is about to expire.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
