FR3 and EAP-TLS session cache

Gerald Vogt vogt at spamcop.net
Tue Jun 16 08:43:04 CEST 2015


You can only use information which is present at the time of the access 
request. If you resume an SSL session there is no client certificate 
presented and thus there is no TLS-Client-Cert-Subject-Alt-Name-Upn 
variable set. You can see all attributes available in the debug log and 
as you can see there, there are no TLS attributes when the session resumes.

If you need the client certificate name for a session you have to save 
it in Cached-Session-Policy and extract it from there when the session 
SSL resumes. I don't think there is any other way to obtain SSL 
information from the original access request.

I'm no expert on this but that's how I understand it...

Cheers,

Gerald



Thus, if you need the client certificate name

On 16/06/15 07:45, Jyri Palis wrote:
> 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.
>
>
>
>
>
>
> 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
>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>


More information about the Freeradius-Users mailing list