Mac OS X EAP-TLS with wrong usename kills freeradius when check_cert_cn is set

[K. Hoercher]

Hi,

while trying to reproduce the segfault and eventually looking into the
diagnostic patch Alan provided I came across something which might be
contributing (also freeradius should not segfault nevertheless).

When feeding a freeradius-1.1.3 (linux) an "forged" Acces-Request with
bogus user name and ask it to check_cert_cn it detects the mismatch,
etc. just like in your example and sends out a fatal tls alert. My
test client wpa_supplicant (also linux) picks that up, recognizes the
failure and essentially stops that run to authenticate and sends an
tls alert ACK inside the next Access-Request. freeradius recognizes it
and only then sends an Access-Reject without much further processing.

After some timeout the supplicant tries anew. That would be the first
Access-Request freeradius sees again from it. As its still wrongly
configured the above repeats...no segfault (see attached debug log, a
bit bloated as I use basically that setup for other tests too)

Whereas I noticed in your debug log that immediately after the tls
alert message from freeradius your client sends (keeping on with
authentication?) an EAP-Message containing a CertificateVerify tls
message (sort of manually decoding)
EAP-Message = 0x0205002f0d800000002515030100207a99997bc8a6c68c3a5c5770c8b46fdd7b8848b6850dc4ea57d1d0e0434ae4c8
for reasons I do not understand. It's that message that leads to the
segfault in cbtls_verify. As said above some strangely (wrongfully?)
behaving client shouldn't be able to crash the authentication server
but it looks curious. Perhaps someone might find that information
helpful.

regards
K. Hoercher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radius_debug.log
Type: application/octet-stream
Size: 31424 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070119/e9f1f4a4/attachment.obj>