[16589] in Kerberos_V5_Development
Re: question about krb5_verify_init_creds() and verify_ap_req_nofail
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Jan 11 18:51:23 2011
From: Sam Hartman <hartmans@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Date: Tue, 11 Jan 2011 18:51:18 -0500
In-Reply-To: <20110111223015.GB22291@sun.com> (Will Fiveash's message of "Tue,
11 Jan 2011 16:30:15 -0600")
Message-ID: <tsllj2rf18p.fsf@mit.edu>
MIME-Version: 1.0
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
>>>>> "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.
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.
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.
Given those semantics I don't support actually creating that option.
--Sam
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
