Behavior change of krb5_rd_req: what error to return

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On Wed, 2008-12-03 at 05:11 -0500, Sam Hartman wrote:
    >> The best solution I have so far is to map
    >> KRB5KRB_AP_BAD_INTEGRITY to KRB5KRB_AP_WRONG_PRINC in
    >> krb5_rd_req.

    Greg> That's not exactly how I'd think about it; I'd say
    Greg> KRB5KRB_AP_BAD_INTEGRITY is a caught exception which just
    Greg> indicates that the loop should continue, and
    Greg> KRB5KRB_AP_WRONG_PRINC indicates that the loop finished
    Greg> without finding a match.

This is roughly what I was thinking in my head.  The problem though is
that WRONG_PRINC today can only be caused by the principal in the
ticket failing to match a principal in the keytab.

If we return WRONG_PRINC as the error when we fail to find a match,
then we create new conditions that cause WRONG_PRINC to be returned,
namely that the ticket principal matches but the key used to encrypt
the ticket is not the one in the keytab.  In the trunk code a caller
can distinguish these to conditions: one returns WRONG_PRINC and one
returns BAD_INTEGRITY.  With the proposed change a caller can no
longer distinguish these conditions.

Personally I think that's acceptable.


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

    Greg> Agreed, if we accept the assumption that servers do not know
    Greg> how to compare client-provided principal names against
    Greg> keytab principals in the general case.

I think this is a good assumption: we have been looking for mechanisms
to reliably make this work in the case of KDC aliases for years and
not come up with ideas that seem likely to be implemented in a good
fraction of environments.  So, I think dropping the assumption that
servers can make this comparison is desirable.  We might be able to
handle the case insensitive and Unicode issues, but dealing with DNS
and other forms of aliases will be quite challenging.