Subject: Re: [Emu] EAP and authorization

From: David Mitton <[email-masked]>
Date: Fri, 14 Aug 2009 15:13:26 +0000 (GMT)

On Aug 14, 2009, Alan DeKok <[email-masked]> wrote: 
...
>  I can propose EAP-IP: carrying IP packets in EAP. It's crazy, but
>  possible. 

In many ways that's what PANA is about, but that's not what spurred me to respond.....

> The main limitation on bulk data transfer is that most EAP to
> RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50
> packets.

This kind of thing drives me crazy.  Why are their such policies?
I develop/maintain a user interactive time-based EAP authentication that, unfortunately, 
has to jump through all sorts of real-time hoops for Access Points and 802.1x clients
that have these ad-hoc rules about what constitutes a "valid" EAP session time and packet wise.

It's one thing when many EAP methods deal with cached non-interactive credentials.
They can wham, bam, thank you ma'am in less than 10 seconds. 

It's another when a user and an authentication device is in the loop.
My user may wait for a new OTP value to come around, fumble finger it in, and possibly have
to do it twice if he got it wrong or is out of the sync window.
It can take several minutes.

Please do not build EAP session breaking assumptions into AAA implementations.

Sorry for the rant, but I still need to write up my EAP implementation experiences 
from doing my SecurID Vista client.   The pain still hasn't completely subsided completely yet.

Dave.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 16 Aug 2009 10:30:07 +0200

> This kind of thing drives me crazy.  Why are their such policies?

  To prevent bulk transfer of data over EAP, among others.

> Please do not build EAP session breaking assumptions into AAA implementations.

  It would be useful to codify these experiences into an EAP "best
practices" document.

  Alan DeKok.

---

From: David Mitton <[email-masked]>
Date: Mon, 17 Aug 2009 00:42:20 -0400

>   To prevent bulk transfer of data over EAP, among others.

This would seem like a highly unlikely scenario, as in most system, 
someone privileged would have
to install this rogue EAP module in the AAA system.

>   It would be useful to codify these experiences into an EAP "best

I've done it before... (I'll find the proceedings reference)
An update is coming....

Dave.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 17 Aug 2009 08:47:54 +0200

Hi,

> to install this rogue EAP module in the AAA system.

Which might make sense in a roaming system if you want your users to get
around being billed.

Provider A and B operate WLAN hotspots, say with realm-based routing. A
wants all his users to get access to B's hotspots, but without being
billed for it :-)

A sets up an EAP server with "EAP-Fraud" method which merely tunnels IP
in EAP, installs supplicant with EAP-Fraud support on his clients. A's
clients travel to a B-hotspot, and start a LONG authentication session
to their A realm which is in fact normal IP communication via an IP
proxy on their home EAP server. After an hour or so of merrily speaking
IP, client indicates a wish to disconnect to home and the EAP server
sends an Access-Reject. No bill, since "the authentication failed". Just
took a while.

Greetings,

Stefan Winter

>
> Dave.
>
>
>>   Alan DeKok.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 17 Aug 2009 08:34:19 +0100

> A sets up an EAP server with "EAP-Fraud" method which merely 
> tunnels IP in EAP, installs supplicant with EAP-Fraud support 
> on his clients.

This approach has some precedent, albeit in a slightly different
context.

http://thomer.com/howtos/nstx.html

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG