Session Resumption fails

[Panagiotis Georgopoulos]

Hello Alexander, all,

	Please see inline.

(snip)
> >> >
> >> Have you considered comparing the difference in the RADIUS packets
> >> going to-and-fro in both cases; the one where authentication works and
the
> >> one where it does not?  What do you see?
> >
> > Yes I did, although I mostly concentrated on the 4-way handshake of the
> > client because this is where it is failing compared to without session
> > resumption. The end-client does not follow up the 1st message of the
4-way
> > handshake of the NAS, but decides to restart the full authentication.
> >
> It's worth always running tcpdump on the RADIUS server and looking at
> what is spat out on the wire; can be easier than trawling the FreeRADIUS
> output when you need to compare two authentication runs.  Handy as a
> initial pass to give you a hint at what is wrong.

I am running wireshark :-)


> 
> > Anyway, so what I thought to do is to go to the post-auth section of my
> > inner-server and add the following to remove the MS-MPPE-Send-Key and
> > MS-MPPE-Recv-Key attributes added by the inner-server and let the
default
> > add its own.
> >
> >        update reply {
> >                MS-MPPE-Recv-Key !* 0x00
> >                MS-MPPE-Send-Key !* 0x00
> >        }
> >
> > Is the logic behind this fine or do you reckon it might break something
else
> > in the future?
> >
> Remote 'eap' from the inner server, I think this is linked to your
> pap/mschap modules noop'ing as the request is already primed for
> passing to the eap module as eap is added additional MS-MPPE keys.

So mschapv2 in the inner tunnel adds keys for the first time (I see an entry
about that on the log) and you are saying that the eap adds additional keys?
Why does it do that without checking if keys already exist as attributes in
the packet?

By the way it seems that the pair of keys added by mschapv2 are shorter than
the eap ones and I am removing the mschav2 with the update reply as above in
a post-auth.

> 
> If you need an inner-eap (say for EAP-GTC, but then we would need Alan
> to apply a patch to make GTC useful</grumble>) then you should place
> that *after* pap/chap/mschap iirc.
> 
> Here is my inner-auth (the ldap bits I left there as you might be
> interested in them, however others might like the
> outer:Cleartext-Password 'override' and want to also palm the error
> handling):
> ----
> server auth {
>         authorize {
>                 if ((outer.request:EAP-Message)) {
>                         update outer.request {
>                                 User-Name := "%{request:User-Name}"
>                         }
>                         update reply {
>                                 User-Name := "%{request:User-Name}"
>                         }
>                 }
> 
>                 validate_username
> 
>                 suffix
> 
>                 if ((outer.request:EAP-Message) && Realm !=
> "%{config:local.MY.realm}") {
>                         update outer.reply {
>                                 Reply-Message := "Realm is '%{Realm}' on
> Inside"
>                         }
>                         reject
>                 }
> 
>                 # if the password is passed to us use it, otherwise yank
it
> from LDAP
>                 if ((outer.request:Cleartext-Password)) {
>                         update control {
>                                 Cleartext-Password :=
> "%{outer.request:Cleartext-Password}"
>                         }
>                 }
>                 else {
>                         ldap-login
> 
>                         # some accounts are glitched and do not have a UP
:(
>                         if (ok && !(control:Cleartext-Password)) {
>                                 update outer.reply {
>                                         Reply-Message := "No eDirectory
UP"
>                                 }
>                                 reject
>                         }
>                 }
> 
>                 pap
>                 chap
>                 mschap
> 
>                 update reply {
>                         Auth-Type := "%{control:Auth-Type}"
>                 }
>         }
> 
>         authenticate {
>                 Auth-Type PAP {
>                         pap
>                 }
>                 Auth-Type CHAP {
>                         chap
>                 }
>                 Auth-Type MSCHAP {
>                         mschap
>                 }
>         }
> }

That is very interesting! I think though from the above, the only thing that
I need is your first if in my authorize section (right?). However the
problem now does not seem to lie in the fact that openssl does not add
entries in the cache, I see the following in every coming request ; 

#Debug:   SSL: adding session
5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to cache

... what I never ever see though is to try and do session resumption (i.e.
see "Skipping Phase2 due to session resumption"). How can I fix/debug that?

	Is anyone using session resumption successfully in 2.1.10?
	
	Thanks a lot,
	Panos