canonicalize, as_req, pa_svr_referral, pa_server_referral

[Sam Hartman]

[There are two pa types I'm going to discuss pa_svr_referral is sent
in the encrypted authorization data field (you know, the one that
doesn't actually exist in RFC 4120 but MS sometimes uses) while
pa_server_referral is a padata specified in the referrals draft.  They include roughly the same information.]


This all started because I was reviewing your changes to krb5.hin and
noticed adding enc_padata to the KDC reply structure.  That structure
is exposed in our public ABI and we try to avoid changing structures
in our ABI.  It might be possible to change this structure because it
seems to always be allocated by libkrb5, although we'd need to check
with Sun and Apple, so if we have to make that change it will
complicate the merge significantly.

I also wanted to do a security review of the referrals situation.

As far as I can tell:

* changing the sname or srealm in an as-rep without pa-svr-referral or
  pa-server-referral is problematic.  The client has no way of knowing
  whether the KDC changed the sname or whether the name was changed by
  a man-in-the-middle along the way.
You have this problem somewhat with client names, but it seems far worse with server names.

* It is fine to do w2k3 style aliasing where you give the client the
  sname it requested even if it is an alias without any padata.

* It seems fine to give the client back a TGT instead of a service
  name for cross-realm.

So, my question is to what extent do we need to support service name
aliases in the AS?  If the answer is not much, let's remove that from
the client and server and lose enc_padata.

If the answer is that we need that, then we're going to need to do a number of things.

* Actually implement support for verifying pa_svr_referral  in the client.
*  Have the main body of the KDC generate these whenever a referral happens rather than calling into the DB backend.
I don't see any reason why this is DB specific

* Talk to folks about the ABI change.