Behavior change of krb5_rd_req: what error to return
Nicolas.Williams at sun.com
Wed Dec 3 12:03:31 EST 2008
On Wed, Dec 03, 2008 at 05:11:39AM -0500, Sam Hartman wrote:
> We've noticed that code in our tree depends on getting
> WRONG_PRINC--for example libgssrpc uses this to loop through potential
> service principals. It seems likely people outside our tree may do
And krb5_gss_accept_sec_context() maps that to GSS_S_NO_CRED, which
might cause a caller of gss_accept_sec_context() to try a different
credential. So returning WRONG_PRINC in this case could lead to
unnecessary looping, but I think that's OK.
> I think we may also want to update the error message to indicate
> something like "Wrong principal or key in request."
"Wrong principal or key in request, or no keytab entry."
> We could actually do a bit better than that. we could see if the
> principal in the ticket happens to match any of the principals we've
> tried and return BAD_INTEGRITY in that case. Doing so will keep the
> behavior very close to what we expect today. However as people start
> using aliases on the KDC you will get into more and more situations
> where we cannot actually tell whether the principal is correct so
> we'll have to guess WRONG_PRINC instead of BAD_INTEGRITY.
I suppose you could do the BAD_INTEGRITY->WRONG_PRINC mapping only if no
entries matched by kvno&enctype, but that's not likely to help much
either. So, yes, I think you're correct to want to map BAD_INTEGRITY to
> I think that assuming WRONG_PRINC instead of BAD_INTEGRITY is the
> correct way to go. I've run into far more situations where I ended up
> presenting the wrong service ticket (DNS confusion, etc) than where
> the KDC and service were out of sync about what key to use, but had
> the same kvno.
Well, I've run into the latter more often (think of a confused sysadmin
who in a fit of frustration does a delprinc and addprinc without
cleaning out the old keytab entries; kadmin makes that failure mode very
More in a bit.
More information about the krbdev