[16590] in Kerberos_V5_Development
Re: question about krb5_verify_init_creds() and verify_ap_req_nofail
daemon@ATHENA.MIT.EDU (Will Fiveash)
Tue Jan 11 19:16:03 2011
Date: Tue, 11 Jan 2011 18:15:41 -0600
From: Will Fiveash <will.fiveash@oracle.com>
To: Sam Hartman <hartmans@mit.edu>
Message-ID: <20110112001541.GC22291@sun.com>
Mail-Followup-To: Sam Hartman <hartmans@MIT.EDU>,
Greg Hudson <ghudson@MIT.EDU>,
MIT Kerberos Dev List <krbdev@MIT.EDU>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tsllj2rf18p.fsf@mit.edu>
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, Jan 11, 2011 at 06:51:18PM -0500, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <will.fiveash@oracle.com> writes:
>
> Will> On Tue, Jan 11, 2011 at 04:20:45PM -0500, Sam Hartman wrote:
> >> Really? I't expect krb5_kt_default() to succeed if the keytab
> >> does not exist.
>
> Will> My bad, you are correct that krb5_kt_default() will succeed
> Will> without a keytab existing.
>
> Will> Still, why try checking the keytab if verify_ap_req_nofail is
> Will> set to false?
>
> [I'm not sure why setting nofail to true causes the code to fail; I'd
> expect nofail = true would decrease failures.]
>
>
> This is the designed behavior of the code. The reason that verify_creds
> does not always fail is that some machines are not keyed. To provide a
> secure environment, you want the ability to assert that all your
> machines will be keyed in a configuration file.
I have no problem with a default of verifying a TGT/init_cred.
> However, if a key is present, it provides better security (and defense
> against an important attack) to use it. If the key is bogus, the
> administrator should delete it.
OK, that is what I wanted to confirm (always checking for a service key
in the keytab and using it if found regardless of verify_ap_req_nofail's
setting). I understand your point (and hope that the error message set
when krb5_verify_init_creds() fails because of a bogus service key
provides a good hint to the admin as to the problem).
> We could create a option to ignore the keytab in this case, although I'd
> call that option
> krb5_verify_creds_succeed_even_with_inconsistent_broken_local_config.
verify_ap_req_nofail runs a close second in the awkward option name
contest (which a google search will confirm). 8^)
> Given those semantics I don't support actually creating that option.
--
Will Fiveash
Oracle
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
