KDC preauth-required behavior with no applicable keys

[ghudson@MIT.EDU]

Kevin Wasserman reported a preauth looping scenario which is described
here:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7013&user=guest&pass=guest

Briefly, the scenario is that a principal has only a DES key but the
client (and maybe the KDC) doesn't allow DES.  The real issue is in
the client, but I'm also not 100% sure what the KDC should do in a
preauth-required error if it can't find any appropriate keys.  Should
it generate no etype-info2, an empty etype-info2, or a final error?
RFC 4120 could be read to specify returning KDC_ERR_ETYPE_NOSUPP, but
that would preclude using PKINIT in cases where it currently works.

Here's a cut and paste of my analysis from RT:

1. The KDC generates either no etype-info2 (if the KDC doesn't allow
DES) or an empty etype-info2 (if the KDC allows DES but the client
doesn't request it).  Perhaps the KDC should return a final error like
KDC_ERR_ETYPE_NOSUPP in this case, though that would obstruct the use of
PKINIT, so maybe this behavior is okay.

2. The client either doesn't see an etype-info2, or sees one but ignores
it because it's empty.  (The preauth framework has logic to error out if
no etype-info2 entry is valid, but it's all bypassed if etype-info2 is
empty or non-present.)  So the determined preauth enctype remains at 0.

3. In 1.9 and prior, encrypted timestamp (though not encrypted
challenge) has logic to use the first requested enctype if the
determined preauth enctype is 0.  Of course, this isn't useful, but it
causes the client to generate an encrypted timestamp padata which fails
at the KDC.  In 1.10 (or with encrypted challenge), the padata module
will just try to encrypt with enctype 0 and get a client-side error,
generating no preauth.

4. Bug #6430.  The client doesn't generate any useful preauth (it does
generate a cookie) but it tries the request again anyway, so the KDC
sends another preauth-required error, and we keep going around until we
loop.  This needs to be addressed in the client preauth framework,
because only it has enough information to distinguish between
informational and real preauth types.

Because it's possible to preauth without any useful principal keys
(using PKINIT), I think this scenario should fail at #4.  There is room
to clean up the behavior on all points, although it shouldn't affect the
behavior of this scenario:

* The KDC should handle both variants of #1 the same way, probably
generating empty etype-info2.

* The client logic for erroring on unknown etype-info2 enctypes should
probably go away, since it almost never triggers (the KDC won't generate
etype-info for non-requested enctypes; if it does, that's just an oddity
and can be ignored).

* The get_as_key callback should fail explicitly if no enctype has been
chosen, instead of failing accidentally in the crypto layer.