FR3 and EAP-TLS session cache

[Jyri Palis]

Hi,

I have attached initial TLS session debug log to this message  (114KB) and yes I read debug log and searched the web for days before I turned to this list for additional help.
As I said before, the first TLS session for supplicant proceeds exactly the way I should, debug log states that TLS session is successfully created and that same session is saved in cache.

Mon Jun 15 08:29:23 2015 : Debug:   SSL: adding session 5bb22b52d5ab6b8e0e2c0be1c0054e8d5e3a11198dd85a74ff14d199374706e9 to cache
Mon Jun 15 08:29:23 2015 : Debug: (14)  eap_tls : (other): SSL negotiation finished successfully
Mon Jun 15 08:29:23 2015 : Debug: SSL Connection Established

The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake. Unfortunately this fails because unlang code I have written for virtual server check-eap-tls returns FALSE when verifying TLS session related data %{TLS-Client-Cert-Subject-Alt-Name-Upn} and %{TLS-Client-Cert-Subject-Alt-Name-Dns} and let me remind that the same code woks flawlessly if TLS cache is purged and full TLS handshake is performed.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: radius_host_1st.txt
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150616/7c36f9e8/attachment-0001.txt>
-------------- next part --------------



Regards,
Jyri.
On 15 Jun 2015, at 21:51, Alan DeKok <aland at deployingradius.com> wrote:

> On Jun 15, 2015, at 2:28 PM, Jyri Palis <jyri.palis at gmail.com> wrote:
>> This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again.
> 
>  Your message bounced because it was too long.  And don't send 3 debug messages.  I only asked for one.  The first one, which shows the initial authentication.
> 
>  And it's possible for *you* to read the debug output, too.  Does it show the server writing the session to the cache?  No?  Then that's why the caching doesn't work.
> 
>  Alan DeKok.
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html