On 05/16/2014 02:51 AM, Frederic Van Espen wrote: > Of course! For the sake of completeness, I still cc'ed the list. I > attached a pcap trace of the packets that are exchanged.
I discovered a fencepost error in our code which causes the KDC to time out after 2.5 seconds instead of five seconds. But that's not your primary problem; something is causing the KDC to discard the RADIUS reply. Since the reply packet looks well-formed and has the same ID as the request, the obvious culprit is the response authenticator. Per RFC 2865, this is supposed to be MD5(Code+ID+Length+RequestAuth+Attributes+Secret), or in the case of this packet trace: MD5(02 4d 0014 f9b07553bdb3fcc249900650c0105cf2 <secret>) I don't have your RADIUS secret, so I can't verify that the response authenticator (bdc29c3024044ded5482d102f6628e4a) is correct. If the checksum generated by FreeRADIUS is correct, then something else is wrong; if it is incorrect, then we need to figure out why. We do have automated tests which use the krb5 OTP RADIUS code against pyrad, so it seems odd that we would have an interoperability issue like this against FreeRADIUS. I think if FreeRADIUS and krb5 were using different secrets, we would have trouble sooner (FreeRADIUS wouldn't be able to decrypt the password), so I'm not really sure what's going on. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
