Session Resumption fails

[Alexander Clouter]

Panagiotis Georgopoulos <panos at comp.lancs.ac.uk> wrote:
> 
> Hmm, yes I think I do. So the server keeps the reply of an authentication
> and therefore if a client has authenticated successfully before, there
> should be a valid entry of his identity in the cache so that Phase 2 of TTLS
> in my case would be skipped.
>
FreeRADIUS asks the OpenSSL library to store some 'opaque' data so that 
if a session can be resumed, then OpenSSL will make this data available 
to FreeRADIUS which will convert it back into RADIUS attributes (for the 
inner 'reply' message).

When FreeRADIUS grumblesthere is nothing in the cache session, it 
usually means "inner auth succeeded but you have no idea who the user 
is"; as typically all you want OpenSSL to return (from the *opaque* 
string of bytes) to FreeRADIUS is the 'User-Name'.

Remember your inner User-Name does not match your outer one (which 
should be '@example.com'); if you do VLAN assignment based on inner 
username (rather than MAC address) then you need this data.
 
> Residing in the cache, seems reasonable since it is a feature of SSL/TLS.
> What I don't get is that since this is a standard EAP-TTLS authentication,
> shouldn't resumption be working out of the box? 
>
Well for it to work you really need to ask OpenSSL to store something 
like the User-Name otherwise you will find for the first 
(non-resumption) authentication things work, but for the second one 
authentication succeeds but the *authorisation* fails as your 
unlang/users policy has no idea what VLAN to assign as you need to know 
the inner User-Name attribute.
 
> In my tests thought I get "Info: [ttls] WARNING: No information in cached
> session!". 
> 
As if you read what I said, you are *not* telling the inner virtual 
server to return in the reply packet the inner username.

>> I also recommend that you also do:
>> ----
>> update outer.request {
>>       User-Name := "%{request:User-Name}"
>> }
>> ----
>> 
>> This means that when the authentication fails (as a quirk of the inner
>> session, post-auth{} and the whole reply packet is no available when an
>> inner request Reject's) you have access to the username that was used.
> 
> Oh.. wait a minute, unless you mean that there is no way for the inner
> session, post-auth{} to know the contents of the server's reply in a
> previous authentication, which seems like a design flow.
> 
*sigh*

Think about what is going on and that RADIUS is a *stateless* system.  
If you want state, put that state into a persistant database.

> Would adding the outer.request part that you suggested add an entry in the
> cache for a successful auth of the inner session?
> 
Reading what I wrote would probably help more....  Just do as I 
suggested in my previous email and look at the output of 'freeradius 
-X'.

Cheers

-- 
Alexander Clouter
.sigmonster says: Alex Haley was adopted!