FR3 and EAP-TLS session cache

[Alan DeKok]

On Jun 16, 2015, at 1:45 AM, Jyri Palis <jyri.palis at gmail.com> wrote:
> 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.

  Your first message didn't say that.  Which made me wonder if the data was being put into the cache.  The parts of the debug log you posted showed that the session wasn't being found in the cache.  Which again seems to indicate that the sessions weren't being cached.

  What that means is you need to give a CORRECT and COMPLETE description of the problem.  Changing the description part way through a conversation is annoying.  It means you're not clear on what's going on, and can't describe it, which means it's almost impossible to help you.

> 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

  That's what I asked you to post (or look for).  Which addresses the original problem as stated.  Sessions go into the cache.  If they're not found in the cache, it's because the cache entry was deleted, or the client is asking to resume a session which was never cached.

> The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake.

  Which is NOT what you said in your original message.

  Please keep a *consistent* description of the problem.

> 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.

  Please try the v3.0.x branch from github.  I've pushed some minor fixes and better debug messages.

  Alan DeKok.