[27872] in Kerberos
Re: pam-krb5 3.5 released
daemon@ATHENA.MIT.EDU (Russ Allbery)
Sun Jun 3 12:44:09 2007
From: Russ Allbery <rra@stanford.edu>
To: kerberos@mit.edu
In-Reply-To: <f3ucd1$mrl$1@sea.gmane.org> (Markus Moeller's message of "Sun, 3
Jun 2007 13:32:27 +0100")
Date: Sun, 03 Jun 2007 09:43:38 -0700
Message-ID: <871wgtaszp.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Markus Moeller <huaraz@moeller.plus.com> writes:
> "Russ Allbery" <rra@stanford.edu> wrote:
>> Oh, bleh. Yeah, I misread that code; I thought it was doing something
>> smarter. Okay, added to the to-do list. It shouldn't be too
>> difficult.
> The ideal would be to use something similar to GSS_C_NO_NAME (as you I
> think intended). so that any keytab entry could be used.
Yes. Unless I'm missing something, it seems like krb5_verify_init_creds
could use any key in the keytab (well, provided that there isn't another
key for the same principal with a later kvno) if no particular principal
is specified. This would fail in cases where people have old keys in the
keytab that no longer work, and it might fail in some interesting
cross-realm cases with keys for other realms in the keytab, but I'd think
those cases would be the ones where people could specify what principal to
use for verification. And one could do something like iterating through
the keytab and trying each key, I suppose.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
