otp over radius preauthentication

[Greg Hudson]

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.