A couple of notes about the FAST negotiation proposal

[Sam Hartman]

At the working group meeting, I presented a proposal Larry made for
FAST negotiation.

As I've started to design an implementation of this proposal, I've run
into a couple of things that don't work as well as one might hope.

First, some KDCs (including MIT prior to 1.7 among others) will return
KDC_ERR_PREAUTH_FAILED not KDC_ERR_PREAUTH_REQUIRED if you have a
principal requiring pre-authentication and send a request that
includes padata but for which all the padata types are unknown to the
KDC.

The work around is to try again without including the negotiation hint
if you get PREAUTH_FAILED and if you otherwise would accept
PREAUTH_REQUIRED.  Naturally, if the ticket flag is set, you fail the
request because the padata is not unknown.  We should also require
that KDCs implementing this extension completely ignore unknown
padata.  (I think the preauth framework already does this).

The second issue surrounds cross-realm armor tickets.  These can come
up because you have a host key as an armor ticket and because a user
from another realm is logging in.  When Larry and I proposed the
negotiation proposal, I think we assumed it would be an AS-REQ
proposal.  However to handle the TGS-REQ case you end up needing to figure out whether each successive KDC supports FAST.
Note that here, we're talking about getting an armor ticket to be used in AS-REQ processing later, *not* the unrelated question of determining whether FAST can be used to protect a TGS request.

Here's an example.

alice at EXAMPLE.COM logs into a BOSTON.EXAMPLE.COM machine.
Her machine has a BOSTON.EXAMPLE.COM armor ticket.
It can use that to obtain a cross-realm ticket to use for FAST armor with the EXAMPLE.COM KDCS.

I can see a couple of approaches:

* Permit the form of negotiation I discussed last week for both AS and TGS
* Use FAST to protect the negotiation.

If FAST is used, you need to either:
* use krbtgt/EXAMPLE.COM at EXAMPLE.COM not krbtgt/EXAMPLE.COM at BOSTON.EXAMPLE.COM as an armor ticket so you actually talk to the EXAMPLE.COM KDCs and can figure out what they support
* Otherwise talk to the EXAMPLE.COM KDCs.

Thoughts?