Behavior change of krb5_rd_req: what error to return

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
> this.

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
WRONG_PRINC.

> 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
likely, unfortunately).

> Comments?