Re: PCI 802.11b w/NetBSD 1.6

>>>>> "lcdt/" == Luis Carlos de Toledo /yahoo/ <[email protected]> writes:

 lcdt/> SSG "concept" and cisco product was a simples examples to
 lcdt/> explain one autentication way...

Is this that XAuth stuff that all the vendors ramrodded into IKE as
``Phase 2.5''?  I don't know how to do something equivalent to that,
but I haven't set up anything serious with IPsec---i tried it out, but
I didn't use IKE, which makes the exercise pretty pointless.  

AFAIK the big problem to using IPSec for access control is that all
your clients have to have IPSec, and the base IPSec included in MS and
BSD is not really convenient for what MIS regimes want---either
passwords or little SecurID dongles, and streamlined ``installers''
and such.  so the proprietary companies have written all these Windows
drivers upon which their customers are now dependent.  Not only do you
have to buy the drivers for big bucks, but they include deviations
from the IKE/IPSec spec like XAuth that makes them incompatible with
BSD.

I heard about this one cool idea at alt.coffee a few days ago.  My
buddy says there is an IS department at some big megacorpration that
hands out these cigarette-sized boxes that do VPN and tunneling.  They
have an Ethernet jack for your laptop, then a PC Card slot into which
you can stick a modem, a wireless card, or another Ethernet card.
They run some kind of free Unix configured by the IS department, but
they have little or no user interface.  It is a ``bump in the wire''
IPsec implementation.  Obviously the details are pretty hazy, but the
idea is good and I think reasonably priced compared to developing
Windows drivers and installers.

I still don't know what SSG is, but ``authentication,'' okay.

I've seen a lot of public systems that use a ``captive portal'' to
control access.  Unauthenticated users can only browse web pages, not
use the actual Internet, and until their ``session'' is authenticated,
no matter what web page they try to browse they get the captive portal
page instead.

 http://www.personaltelco.net/index.cgi/ActivePortal

This URL is a good starting point to escaping Cisco marketing regimes
and learning the buzzwords that are favoured on BSD right now.

The advantage of the captive portal over proprietary IPsec hacks is
that no special software is required on the client---just a web
browser will do.  And the building blocks for making these captive
portal routers are available for BSD and probably other Unixes too,
unlike the proprietary IPsec hacks which are designed to tie you to
the creating vendor's platform on the server end, and to partner
platforms on the client end.  And lots of people are doing it already,
unlike the much nicer cigarette box bump-in-the-wire.

It's not too difficult to circumvent some captive portal policies by
hijacking another user's session.  If the other user has to enter a
password, an attacker might not be able to read the other user's
password, but it's not necessary for the attacker qto do that because
without IPsec there is no cryptographically secure notion of a
``session'' that can be bound to the password entry or other
authentication event.  It's easy to take over someone else's session
just by using their IP address.  If the captive portal works by MAC
address, the attacker and legitimate user might both use the
``session'' at once without interfering with each other.

The real point of captive portals is the Reverse IDS.  If someone
complains that one of your anonymous community freenet users is
breaking into some system or sending spam over your wireless gateway,
there is no way to save yourself by delivering that anonymous person's
head to the complainer on a silver platter.  And that is probably a
good thing.  However, you CAN save your access point from the
complainer's legal attacks by adding an automated censorship rule to
your RIDS that blocks future anonymous hackers from making similar
attacks, thus you've responded to the ``incident,'' you're not
negligent, or whatever the hell the complainer can reasonably demand.

There's also been an ongoing discussion which seems to have made it
onto the Wiki about giving an inner cabal some kind of faster access
to the Interweb with ``traffic shaping.''  whateva.

In any case, ``traffic shaping'' and access vs. no access is difficult
to enforce with a captive portal because of the session hijaaking
problem, so it may not work well for some corporate application.

Here are three example systems that I've tried which use captive
portals.

 * The NYCwireless Bryant Park Freenet

   Forces anonymous users to click ``I Agree'' before they can access
   the Internet.  and it is Internet access, with a real IP address.

 * Pennsylvania Convention Center in Philadelphia

   People on the convention floor can pay for access codes that give
   them time-based access to the Interweb.  I heard a rumor that it
   uses an old NoCatAuth, hacked so that it times out every so often
   rather than relying on foolish JavaScript nonsense that won't work
   with PDAs.  Browsers are directed to the login page with a
   transparent web proxy.

 * University of Colorado

   Students must login with their PPP / computing lab /
   KerberosV-telnet password befor they can use the campus-wide WLAN.

   I heard this does not use NoCatAuth---instead, the DHCP server
   hands out replies that contain a sabatoged nameserver that returns
   the IP of the authentication web server no matter what name you try
   to resolve.  ``Sessions'' are based on your MAC address, and
   usually you only have to authenticate about once per semester.
   which is good because apparently sometimes it's necessary to reboot
   a Mac or PeeCee to make it forget about the bogus nameserver.  I
   haven't actually used this one recently so it might have changed.

   It's obviously pretty weak, but one of the things CU was always
   great about is keeping security in perspective.  They have nearby
   Ethernet jacks in the engineering center and web kiosks all over
   campus that anyone can use with no password, so it's silly to be
   all fascist about the wireless.  Theirs is the least annoying
   system I've heard about.

but of course none of them prevent the class of attacks that VPNs can
prevent.

-- 
The spanning tree computed in a region appears as a subtree in the CST 
that encompasses the entire switched domain.  The CIST is formed as a 
result of the spanning-tree algorithm running between switches that 
support the 802.1W, 802.1S, and 802.1D protocols.  The CIST inside an 
MST region is the same as the CST outside the region.  Press RETURN to 
get started.
--
*bsd wireless list, a bawug thing <http://www.bawug.org/>
[un]subscribe: http://lists.bawug.org/mailman/listinfo/bsd-wireless/