[33390] in Kerberos
Re: Inittab launching K5start too soon
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon May 16 15:08:43 2011
MIME-Version: 1.0
In-Reply-To: <1305289366.2034.173.camel@t410>
Date: Mon, 16 May 2011 14:08:19 -0500
Message-ID: <BANLkTimPr+qi9yo=4f6xSWxRso9PhchfqA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, May 13, 2011 at 7:22 AM, Greg Hudson <ghudson@mit.edu> wrote:> 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.
I don't think the ccache layer is the right place for this. I thinkthis needs to happen in krb5_get_credentials(), or in mech_krb5.
If you had to add env vars (sure, why not) I'd say add via which tospecify a default principal name:
KRB5DEFPRINC=<unparsed-principal-name>
That, together with the existing KRB5_KTNAME and KRB5CCNAME variables,krb5.conf, and any existing ccache (e.g., with expired credentials),would provide enough information for krb5_get_credentials(). And ifKRB5DEFPRINC was not set you'd use <username-of-euid>@<default-realm>,and if there were no keytab entries for that, then the first principalfor which there are keytab entries.
> 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.
Existing credentials which are about to expire should be automaticallyrenewed (if renewable) or replaced with fresh ones (if there's akeytab or a display on which to prompt the user, preferably via atrusted path). This could be done by a daemon (as in Solaris),particularly when there's no keytab, no logged-in smartcard, and nodisplay, in which case a daemon is the only way to ensure thatrenewable credentials are renewed.
Nico--
________________________________________________Kerberos mailing list Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos
