[11568] in Kerberos-V5-bugs
[krbdev.mit.edu #6738] PKINIT DH exchange occasionally produces
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Mon Jun 7 15:37:40 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6738@krbdev.mit.edu>
Message-ID: <rt-6738-32912.1.84406929906039@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6738'":;"'AdminCc of krbdev.mit.edu Ticket #6738'":;@MIT.EDU
Date: Mon, 7 Jun 2010 15:37:39 -0400 (EDT)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Approximately 1% of the time, a PKINIT Diffie-Hellman exchange (between
a trunk client and a trunk KDC) arrives at a different result on the
client and KDC.
One way of reproducing this bug is with t_anonpkinit.py in tests/. If
you run it with --shell-before=5 and then run the anonymous kinit
command repeatedly in a loop, after roughly 100 iterations it will ask
for a password. (This behavior is a little unfortunate; if get_in_tkt.c
fails to decrypt a response with a reply key determined by preauth, it
silently falls back to gak_fct, due to some enctype issues related to
SAM preauth.)
If you display the value of *client_key and *server_key just after the
calls to DH_compute_key() in pkinit_crypto_openssl.c, in the successful
case they will be identical, while in the failure case they differ in
the last two bytes. To me, this suggests something going wrong inside
OpenSSL's crypto library; if the inputs were bad, the values would be
much more different. The problem has been observed with OpenSSL 0.9.8g-
4ubuntu3.9 and 0.9.8k-7ubuntu8.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
