(RADIATOR) Problems with TTLS session resume

[Terry Simons]

Hi Roy,

On Sep 3, 2004, at 9:33 AM, Roy Badami wrote:

>
> I'm trying to get TTLS session resumption to work with the Odyssey
> Client.
>
> In particular.  It works when I hit the "reauthenticate" button, but
> in particular I'd like it to work in the following circumstances:
>
>    * Client briefly goes out of coverage, then reassociates with the AP
>    * Client roams from one AP to another.
>
> The problem is that in the first case the NAS Port will change; in the
> second the NAS ID will change too.  As a result EAP.pm is unable to
> retrieve the context (the key has changed).

I would think that the NAS Port shouldn't change... that seems really 
weird.  (None of my equipment does that, and it would make my job 
difficult if it did, since we use that information to determine what 
type of wireless a user came from, 802.11a, b, g etc...).  To give you 
a better example, wired NAS Ports should *NEVER* Change, since it is 
supposed to be the physical port mapping, if possible.  Wireless 
vendors should consider that, and design their equipment 
appropriately... I don't see why you would even bother sending the NAS 
Port if you're just going to change it every time a user authenticates. 
  (It's not a required attribute, as long as the NAS-Port-Type is sent 
in the accounting record...)  Sounds like an issue you should take up 
with the vendor, though I don't see how the NAS Port changing would 
cause session resumption to fail, unless Radiator is using that 
information somehow on the resume?  I would actually be interested in 
hearing the logic behind an ethereal NAS Port.  :-)

The second problem is one that you probably can't solve at all.  When 
you hop APs, the AP will initiate a new connection with you.  Since the 
AP doesn't have any information from your previous authentication, you 
can't "resume" - It's not possible to resume a session that doesn't 
exist.  This is also possibly contrary to the 802.1X standard, but I 
don't know enough about session resumption to say for sure...   You 
might be able to pull this off if your APs are smart enough to share 
information about their 802.1X authentications, but in general this is 
just simply not going to work.


> Changing
>
>     my $key = "eap:$nas_id:$nas_port:$calling_station:$rad_user_name";
>
> to
>
>     my $key = "eap:$calling_station:$rad_user_name";
>
> in EAP.pm allows me to resume a session after straying out of
> coverage.  I assume it will fix the roaming case too -- assuming
> Odyssey Client does the right thing -- though I can't test that since
> my test network only has a single AP.

Why are you concerned with a full re-authentication?

> Is there any reason not to do this?  If not, could this be made an
> option?
>
>       -roy
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.