[kitten] Removing unnecessary and damaging check from RFC4120 section 3.2.3

[Nico Williams <[e-mail]>]

RFC4120 (Kerberos) requires that services check that the cname/crealm
fields of the decrypted Authenticator match those in the decrypted
Ticket.

Section 3.2.3, page 31, says that "the name and realm of the client from
the ticket are compared [by the service] against the same fields in the
authenticator", and that "[i]f they don't match, the KRB_AP_ERR_BADMATCH
error is returned; normally this is caused by a client error or an
attempted attack."  (This being RFC4120, this has the force of a SHOULD
at least, probably a MUST, even though such terms are not used in the
quoted text.)

I cannot think of a single attack that this foils.  If there were such
an attack, either it would be utterly uninteresting, or it would imply
that the Kerberos cryptosystem and/or cryptographic protocol are broken,
in which case we'd have bigger problems.

In particular, the Authenticator decrypt integrity check should be
sufficient to rule out all interesting attacks.  I'm sure you'll agree.

That leaves only the "client error" case of the given justification.
But this error never happens.

There is a USER error case however, not envisioned by RFC4120, where
this check fails: with Active Directory as the KDC when the client
acquires an INITIAL Ticket for an alias instead of their canonical
principal name.  In this case the AS puts the canonical name in the
cname/crealm fields of the Ticket.  If the client did not use the AS
canonicalization feature, then the client will not put the correct
cname/crealm in subsequent Authenticators, thus AP exchanges with many
services will fail due to this check.  The user error lies in running
"kinit <alias-principal>".

The most likely explanation for why this behavior is required by RFC4120
is that this was carried over from Kerberos IV and earlier, harkening
back to the days when authentication tags were weak or missing
altogether.  But those days are behind us, and this check is redundant
now.  We should remove it.

[ASIDE: Incidentally, there is a simple way to do client principal name
        canonicalization with no new protocols, all on the client side:

        - first, get a TGT for a client principal

        - then get a service ticket for the same principal as the
          service, preferably using user-to-user authentication

        - extract the canonical cname/crealm -and any authorization-data
          of interest!- from the service Ticket

        Of course, this only works if the AS works like Active Directory
        and puts the canonical cname/crealm in the issued Ticket, not
        the requested cname/crealm.  This seems like very helpful
        behavior, actually, and for this reason: that the client can
        perform canonicalization if it wants to (though it shouldn't be
        necessary if the services stop performing the cname/crealm
        Authenticator check).]

Dropping this unnecessary check will allow non-Windows clients to
gracefully recover from user error at sites that have ASes that support
silent aliasing as AD does.

Alternatively, dropping this unnecessary check could allow the
cname/crealm from the Authenticator to be used as a way to indicate that
the real client wishes to impersonate another.  The application,
naturally, would have to decide whether any given impersonation is to be
accepted.  This use would conflict with the existing user-error case, so
I think we can rule out this alternative use of the Authenticator
cname/crealm.

I propose that we update RFC4120 as follows:

 - drop the requirement to perform this unnecessary check;

 - require that the cname/crealm reported to the application be the ones
   from the Ticket, not the ones from the Authenticator;

 - recommend/require that the AS put the canonical cname/crealm in the
   Tickets it issues.

Are there other such checks in RFC4120 that should be modified/removed?
(At a quick glance I could not find any others.)

In the short-term, I'm wondering if implementors shouldn't just go ahead
and remove this check from their implementations.  For Heimdal this
would entail removing 31 lines of text (26 lines of actual code) from
one file; no remaining uses of KRB_AP_ERR_BADMATCH would remain.

Nico

PS: I mention crealm because the crealm too can be aliased, and indeed,
    the Active Directory KDC supports realm aliasing.