Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Subject: Confusing error message for key version mismatch
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1159

If a client makes an AP request to a server with a stale cached ticket 
(one the server does not have a keytab entry for), the error code from 
krb5_rd_req in krb5 1.2 through 1.6 will be KRB5_KT_KVNONOTFOUND, per 
issue #198.  This makes the situation pretty clear if the administrator 
is able to see the error message.

In krb5 1.7, the error will be KRB5_KRB5KRB_AP_WRONG_PRINC, which fails 
to distinguish stale ticket issues from DNS canonicalization issues.  
This is true whether or not krb5_rd_req is given a server parameter, 
because of the error-mapping switch statement at the end of 
decrypt_ticket().  The acceptor names work in 1.10 did not change this 
behavior.

In the cases where we try just one principal in the keytab, fixing this 
is as simple as not mapping a KRB5_KT_KVNONOTFOUND error.  In the case 
where we iterate over the keytab, we will need to detect when the name 
matches the request service principal (which of course won't trigger in 
alias situations, but those are not the common case) but the kvno 
doesn't match the request kvno, and produce a KRB5_KT_KVNONOTFOUND error  
at the end of the loop if we saw one of those.