Skip Menu |

From: "Kevin Wasserman" <>
To: <>
Subject: looping detected in init_creds_step_request()
Date: Wed, 9 Nov 2011 17:54:12 -0500
...when krb5_get_init_creds_password() is invoked for a prinicpal that requires
preauthentication and only supports weak crypto (and allow_weak_crypto
is not specified).  It should fail, clearly, but probably in some speedier
and more comprehensible fashion.
-Kevin Wasserman
Reproduction recipe:

make testrealm
kadmin.local -q 'addprinc -pw pass +requires_preauth -e des-cbc-crc:normal
kinit test
(enter the right or wrong password)
Download (untitled) / with headers
text/plain 2.1KiB
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.
Bug #6430, the underlying cause of the looping, is fixed and marked for
pullup to 1.10. Leaving this issue open to track cleanups for the other
three internal issues.
I just noticed that RFC 4120 defines ETYPE-INFO2 as "SEQUENCE SIZE
(1..MAX) OF ETYPE-INFO2-ENTRY", which means sending an empty etype-info2
violates the encoding rules. This affects the resolution of #1.
The fix for issue #7033 adds a default enctype to be used when no etype-
info processing has been done. That addresses #2 and #3, although
differently from the recommendation I came up earlier (I hadn't been
thinking about optimistic preauth). So that just leaves #1.