FAST Negotiation API confirmation

[Sam Hartman]

http://k5wiki.kerberos.org/Projects/FAST_negotiation is mostly ready
for review (although people may ask for more detail during the
review).  I should send out the announcement this week.


I wanted to discuss one thing.  Currently, if a client provides an
armor ticket to the library, then FAST will be required.  That is, a
request will fail if FAST is not available.
However a comment in the header makes it clear that this is not the interface contract: we reserve the right to move from "must fast" to "should fast."

I propose to introduce a new API to require FAST.

I then propose the following logic:

* If an armor ticket is not provided we will not use FAST. [1] \ 
* If an armor ticket is provided  and FAST negotiation indicates that FAST is available then we will use it.
* If FAST negotiation didn't happen  but the KDC offers FAST, we'll use it if we have an armor ticket.

As a consequence of this, a 1.8 client against a 1.7 KDC may provide
an opportunity for an active attacker to force FAST to be unused.

Handling the part where we use FAST if it is offered even if we didn't
negotiate it may make preauth2.c a bit more ugly.  That's kind of
unfortunate, as that code is kind of complex already.  I'll see what I
can do to leave things better than I found them.  However, without
this support, you would have to explicitly require FAST to get FAST
against 1.7.

An alternative is to keep the 1.7 API behavior and add a new mechanism
for requesting FAST if negotiated.  I don't like that option because
it complicates application code for the common case.

[1] Unless of course I end up adding support for anonymous armor
tickets in an automated manner within the library.