question about krb5_verify_init_creds() and verify_ap_req_nofail

Will Fiveash will.fiveash at
Tue Jan 11 19:15:41 EST 2011

On Tue, Jan 11, 2011 at 06:51:18PM -0500, Sam Hartman wrote:
> >>>>> "Will" == Will Fiveash <will.fiveash at> 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
Sent using mutt, a sweet, text based e-mail app <>

More information about the krbdev mailing list