FR3 and EAP-TLS session cache

[Jyri Palis]

Hi,

Hmm, are you sure? When I enabled persistent caching then all needed information was stored in vps file (session id plus all certificate related data like variables I mentioned before) so I assumed that when FR detects that client requested cached TLS session, this data can still be used for additional decision making and identity verification otherwise I do not see any reason to for caching unless check-eap-tls contains means to detect cached session (also means that FR trusts the contents of TLS cache) , which can be then used for over ruling unlang code and still return TRUE  

update config {
	Auth-Type := Accept
}

With this basic configuration, caching works but this renders the whole concept of additional checking of TLS session with unlang useless for this particular setup. Maybe I have missed something, can’t rule that out :)

Regards,
Jyri
On 16 Jun 2015, at 09:43, Gerald Vogt <vogt at spamcop.net> wrote:

> 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
>> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html