Session Resumption fails
Alexander Clouter
alex at digriz.org.uk
Tue Sep 28 21:54:02 CEST 2010
Panagiotis Georgopoulos <panos at comp.lancs.ac.uk> wrote:
>
>> > State: ASSOCIATED -> 4WAY_HANDSHAKE
>> > [snipped unread log]
>> > EAPOL: Received EAP-Packet frame
>> >
>> > It seems that the Access Point realizes that the identity in FR's
>> > reply has changed (from the outer identity to the inner one) and
>> > somehow the client doesn't like this and doesn't reply to the 1st
>> > message of the 4th way handshake. Instead it sends an EAPOL start
>> > message and a full authentication restarts with the same outcome..
>> and then again and again.
>> >
>> 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.
> 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.
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
}
}
}
----
Cheers
--
Alexander Clouter
.sigmonster says: The road to Hades is easy to travel.
-- Bion
More information about the Freeradius-Users
mailing list