> * All of the random session key generation inside the PKINIT plugin is > done using the regular MIT Kerberos random key functions, *not* the > OpenSSL random number generator, and hence sessions created via PKINIT > are not subject to this vulnerability.
It looks like this may not be the case. Upstream thought my statement above was correct, but I just got a correction from someone else who believes that the DH session key is used for the Kerberos session key, which means that PKINIT sessions would be subject to a brute force attack on the weak session key. I'm not sure exactly what the implications of that would be, since the PKINIT session key would not normally have been used directly to encrypt regular network traffic for, say, GSSAPI. I'm trying to get further clarification from upstream. It remains the case that once libssl has been upgraded to a fixed version, there should be no vulnerabilities remaining in a MIT Kerberos installation going forward; there is no persistant bad key material involved. The only question is whether past sessions created using a vulnerable libssl should be treated as suspect. Sorry about the reversal here. (It continues to be the case that any issue would only be an issue for lenny, not etch.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
