krb5_rd_req return codes for ticket decryption failures

Simo Sorce simo at
Mon Apr 28 11:54:51 EDT 2014

On Mon, 2014-04-28 at 11:27 -0400, Greg Hudson wrote:
> I am working on some changes to produce better error messages from
> krb5_rd_req, and while I'm there I want to take a look at its return
> codes.
> As of 1.7, we return KRB5KRB_AP_WRONG_PRINC for most ticket decryption
> failures.  Despite the name, this code does not correspond to an RFC
> 4120 error number, so the krb5 mech's gss_accept_sec_context will
> translate it into KRB_ERR_GENERIC (60) in the KRB-ERROR message.  It
> seems like we would be better off returning actual AP-REQ protocol
> errors (especially because of [1]).  My tentative plan is:
> * KRB5KRB_AP_ERR_NOKEY: The keytab is missing or unreadable, or contains
>   no usable entries (i.e. none of the keytab principals match the
>   application server specification), so we can't decrypt any tickets.
> * KRB5KRB_AP_ERR_NOT_US: The keytab does not contain any usable entries
>   for ticket server principal (and we tried all of the usable entries in
>   case the ticket used an alias, but none of them worked).
> * KRB5KRB_AP_ERR_BADKEYVER: The keytab contains a usable entry for the
>   ticket server principal, but it doesn't match the ticket kvno and
>   enctype (and we tried all of the usable entries anyway but none of
>   them worked).
> * KRB5KRB_AP_ERR_INTEGRITY: The keytab contains a key matching the
>   ticket server principal, kvno, and enctype, but it didn't work (nor
>   did any of the other usable entries).
> If the ticket used an alias for a keytab entry we do have, but uses the
> wrong kvno, we can't really tell that it was a kvno mismatch, so we
> return a principal mismatch.  This is a fundamental limitation of RFC
> 6806 server aliases.
> We can distinguish between different sub-cases using the extended error
> message, but that won't be visible to the client.  For the purpose of
> this thread, I'm only discussing the return code.
> >From [2] I'm aware that we have some old GSSRPC code in the tree which
> reacts to KRB5KRB_AP_WRONG_PRINC; it can be changed to react to
> Does this plan seem reasonable?
> [1]
> [2]

I do not see any major issues with it.


Simo Sorce * Red Hat, Inc * New York

More information about the krbdev mailing list