preauth behavior discovered in the BETA

[Sam Hartman]

Looking at beta1 I've discovered a couple of issue I'd really like to see fixed.
I'll write up and commit fixes but wanted to discuss here.

1) As I mentioned before the beta, we currently don't have a PRF for
DES or 3DES.  I think we want to fix that.  The behavior if a client
uses FAST for an enctype the KDC doesn't have a PRF for is not that
good.  You fail to produce an armor key, which fails the request.
That may be the correct thing in the AS case, but it is fairly
annoying in the TGS case.  I'll go implement DES and 3DES PRFs.  3DES
is fairly easy, but I'd really appreciate careful review of the DES
code to make sure it follows the SPEC.

An alternate approach might be to change the error handling in the
FAST TGS path.  I think that would be harder to test and would be
wasted effort in the long run.

Also, our KDC returns KDC_ERR_PREAUTH_FAILED if pre-authentication is
required and an unknown pre-authentication type is used.  I think that
ignoring the unknown pre-authentication type and returning
KDC_ERR_PREAUTH_REQUIRED is better behavior.  That's what Windows
does; that's what the pre-authentication framework says you should do.
Doing so may save a round trip when a 1.8 client talks to a 1.7 KDC
using the negotiation facilities Larry posted to the WG list about
after the interop event.  The 1.7 KDC will not recognize those
facilities and I'm concerned that returning PREAUTH_FAILED may require
the client to do extra work.  In addition, if KDC database updates are
enabled, PREAUTH_FAILED will definitely do the wrong thing.  This is a
simple change.

--Sam