more false positive "keytab entry valid" with kvno -k

[Mark Pröhl]

Am 22.02.2013 20:42, schrieb Greg Hudson:
> On 02/22/2013 08:05 AM, Mark Pröhl wrote:
>> Example 1 (Wrong key version number): if test_principal's entry has been
>> created with a wrong KVNO than kvno -k still reports "keytab entry valid".
>>
>> Example 2 (Wrong key): consider a defective keytab file with an entry
>> for test_principal at EXAMPLE.COM that has an incorrect key. If there is
>> another entry for a differently named principal in the same file and if
>> that entry contains test_principal's correct key than kvno -k will
>> report "keytab entry valid".
>
> In both of these cases, the decrypting function used by kvno -k
> (krb5_server_decrypt_ticket_keytab) is mirroring the behavior of rd_req,
> which will try all of the keys in the keytab.  So I think that part is
> working as intended.
>
> Since kvno -k isn't documented, I can see two options:
>
> 1. Decide that the purpose of kvno -k is just to output whether the
> keytab can decrypt the ticket.  In this case, the message should be
> changed to be a little less specific.
>
> 2. Decide that the purpose of kvno -k is to check a keytab entry.  I
> think to do this, we'd have to stop using
> krb5_server_decrypt_ticket_keytab and instead look up the specified
> service name at the ticket kvno and decrypt the ticket with
> krb5_decrypt_tkt_part.  There are some edge cases to consider with
> service aliases.
>
My requirement is to test keytab entries for their validity before the 
service that will use the keytab is configured for Kerberos. I am using 
kvno -k for that purpose. I assume that a kerberized service picks 
exactly that keytab entry that matches the ticket's encryption type, 
version number and service principal name (e.g. like OpenSSH with 
GSSAPIStrictAcceptorCheck=yes).

Therefore I would like to vote for option 2.