Force update of TLS cache

Alan DeKok aland at deployingradius.com
Tue Mar 1 15:43:34 CET 2016


On Mar 1, 2016, at 9:15 AM, Jonathan Gazeley <Jonathan.Gazeley at bristol.ac.uk> wrote:
> I'm using this unlang snippet to do the assignment:
> 
> update session-state {
>    TLS-Session-Id := &TLS-Session-Id
> }

  That's a start.

> I've placed it in various places in the outer server, immediately after the eap module has been called in authorize{}, immediately after the eap module has been called in authenciate{}, and inside and outside the Auth-Type eap subsection inside authenticate{}. I would think it should be available immediately after the eap module has done its thing.

  TLS-Session-Id should be available after it's created in packet 4.  You should add the "update" section after the "eap" module in "authenticate".  i.e. when the packet is an Access-Challenge.

> All of these positions cause it to fail with the following error:
> 
> (6)        update request {
> (6)          TLS-Session-Id skipped: No values available
> (6)        } # update request (noop)

  Yes, TLS-Session-Id won't be available in the request in packet 6.  Because TLS-Session-Id will be in session-state.

  What you want is to restore it from session-state if it exists there, otherwise copy it from request to session state if it exists there.

  Again, none of this is magic.  You MUST write down what you have, and what you want.  Then work out how to get there from here.  A random approach of "adding things to configuration sections" WILL NOT WORK.


authorize {
	...

	if (&session-state:TLS-Session-Id) {
		update request {
			TLS-Session-Id := &session-state:TLS-Session-Id
		}
	}

	eap

	...

}


authenticate {
	Auth-Type eap {
		eap
		if (!&session-state:TLS-Session-Id && TLS-Session-Id) {
			update session-state {
				TLS-Session-Id := request:TLS-Session-Id		# just to make it clear
			}
		}

	}

	...
}


More information about the Freeradius-Users mailing list