[krbdev.mit.edu #7013] looping detected in init_creds_step_request()

[Greg Hudson via RT]

There are numerous things going on here:

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.