Behavior change of krb5_rd_req: what error to return

Sam Hartman hartmans at painless-security.com
Wed Dec 3 05:11:39 EST 2008


Folks, as part of
http://k5wiki.kerberos.org/wiki/Projects/Unicode_and_case_folding
we're looking at changing the behavior of krb5_rd_req to better
support server principal aliases.

The idea is that we're ignoring the principal in the ticket  and doing one of two things.
If a service principal is supplied to krb5_rd_req, we use that to find keytab entries.
Otherwise, we loop.

Comments on this approach are appreciated now; that project has not
reached review stage, but it would be useful to know about problems
now.  As far as I can tell, the approach works quite well and is going
to make service aliases much easier to deal with.


The obvious implementation of this ends up changing the errors that
are returned in case you can't find the right principal.  You get
KRB5KRB_AP_BAD_INTEGRITY instead of KRB5KRB_AP_WRONG_PRINC.

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.

The best solution I have so far is to map KRB5KRB_AP_BAD_INTEGRITY to
KRB5KRB_AP_WRONG_PRINC in  krb5_rd_req.
I think we may also want to update the error message to  indicate something like "Wrong principal or key in request."

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

Comments?


--Sam



More information about the krbdev mailing list