Cached attributes

[Jonathan Gazeley]

On 25/02/16 15:15, Alan DeKok wrote:
> On Feb 25, 2016, at 9:39 AM, Jonathan Gazeley <Jonathan.Gazeley at bristol.ac.uk> wrote:
>> In inner post-auth we are doing this to populate session-state from the current set of attributes:
>>
>>         update outer.session-state {
>>                 User-Name := &User-Name
>>                 Inner-User-Name := &User-Name
>>         }
>
>    That will update the outer session state.  But I'm wondering why you need to cache the User-Name twice.

Yes, this is an artifact of debugging (I added Inner-User-Name as you 
suggested, and didn't (yet) remove the other User-Name).
>
>> Is this sufficient to ensure Inner-User-Name ends up in the TLS cache? This previous posting from Arran seems to suggest it is:
>>
>> http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.html
>
>    If you're using 3.1...

We are.

>
>> In outer post-auth we are doing this to copy the session-state back before acting upon the information:
>>
>>         update {
>>                 &reply: += &session-state:
>>         }
>
>    That should cause the User-Name in the Access-Accept to be the User-Name from the inner tunnel.
>
>> Here's today debug log: http://pastebin.com/ZD1nmAvC
>
>    Which shows that the cache_tls_session module is caching TLS-Session-Data, and not much else.
>
>    Did you edit raddb/mods-available/cache_tls to cache the attributes you want cached?

I think there is some odd behaviour going on here. Inside cache_tls 
we've tried several configs with different results:

First we tried uncommenting the section that adds the session-state to 
the TLS cache:

update {
   &session-state:TLS-Session-Data := &session-state:TLS-Session-Data
   &session-state: += &session-state:
}

The debug log did not show any mention of the session-state being copied.

We tried a different syntax that Arran had used previously [1]:

update {
   &session-state:TLS-Session-Data := &session-state:TLS-Session-Data
   &session-state: += &session-state:[*]
}

The debug log did not show any mention of the session-state being copied.

We tried explicitly setting Inner-User-Name to a string

update {
   &session-state:TLS-Session-Data := &session-state:TLS-Session-Data
   &session-state:Inner-User-Name := "banana"
}

This worked and we were able to retrieve the string "banana" from the 
TLS cache in a resumed session.

So we tried populating Inner-User-Name from a variable:

update {
   &session-state:TLS-Session-Data := &session-state:TLS-Session-Data
   &session-state:Inner-User-Name := &session-state:Inner-User-Name
}

This didn't work as it seems the cache_tls module is called in packet 4, 
i.e. before the server has started to process the inner tunnel (which is 
where Inner-User-Name is assigned).

How can we place the Inner-User-Name into the TLS cache? Arran's email 
[1] suggests that anything you wish to place in the TLS cache must be 
stored in session-state before the TLS session is frozen. However what 
seems to be happening is the TLS cache entry is created at the beginning 
of the TLS session and then not updated. Please can you shed some light 
on this behaviour, and whether it is possible to add an attribute to an 
existing cache entry in the inner post-auth section?

>
>> I'm looking at line 4576 (a resumed session) where the outer post-auth is supposed to copy attributes to reply from session-state and fails to do so. The session-state list should be being populated in inner post-auth but the server seems to skip this for resumed sessions and the list is empty.
>
>    Again, the session-state list is for the *current* authentication session, and ONLY the current authentication session.  The cache_tls_session module caches attributes across *multiple* TLS sessions.
>
>    The session-state list is NOT cached across multiple TLS sessions.
>
>    Stop looking at session-state.  Go modify  raddb/mods-available/cache_tls, and tell it to cache the attributes you want cached.

Thanks. I understand the differences between the TLS cache and the 
session-state cache. It's hard to use one without the other and I think 
I'm having difficulty explaining myself.

Thanks,
Jonathan

[1] 
http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.html