[unisog] Tracking usage of dynamic IP

[Peter John Hill]

Alexander,

This is great stuff here. I have not been to an Internet2 Joint Techs  
in a while and am not sure if there have been any recent presentations  
on 802.1x deployment. The next one is in Honolulu
http://www.hawaii.edu/tip2008

It looks like there was an 802.1x presentation in 2005.
http://events.internet2.edu/2005/JointTechs/SaltLake/sessionDetails.cfm?session=1853&event=228

I love the fact that you prefer EAP-TTLS. It seems that method has  
both decent security and supplicant support. Are you using client  
certificates for authentication?

Can users preregister machines that don't natively support 802.1x all  
by themselves? Congratulations on getting it all to work. I'd be very  
curious on which part of the system needs the most improvement?

Client OS Support
Switch vendor support
Backend Server support
	radius
	cert servers? (if used)
Other

Do you have a good tool for looking through your radius logs to match  
machines to users?

Again, congrats!
Peter


On Nov 13, 2007, at 7:55 AM, Alexander Clouter wrote:

> Hi,
>
> Peter John Hill <pjhill at u.washington.edu> [20071113 07:09:03 -0800]:
>>
>> On Nov 13, 2007, at 2:29 AM, Alexander Clouter wrote:
>>>
>>> Time to use that magical buzzword 802.1x.  To be serious though it  
>>> really
>>> does work and we are using it here.  We are doing the full  
>>> Authentication
>>> (MAC fallback based and user based), Authorisation (which VLAN to  
>>> dump
>>> them in) and the accounting data too.  In your situation you are  
>>> only
>>> interested in the accounting side of things.  I have not tried out  
>>> an
>>> accounting only approach but I cannot see why it would not work.
>>>
>>> It seems pretty difficult to get equipment that is not 802.1x  
>>> enabled and
>>> so I would recommend you use it.  To be honest no MAC<->IP mapping  
>>> will
>>> work unless you have solid anti-spoofing[1] inplace you cannot  
>>> rely on
>>> the data. er gets a new fresh authentication.
>>
>> I like the idea, because it provides a more reliable userid to port
>> and mac association and uses radius for accounting data, which is
>> pretty mature.
>>
>> The one thing I wonder about is that since we are talking about a
>> university setting, how do you deal with things like xboxes, apple
>> tvs, tivos. I think your config specified that each mac addr had to
>> authenticate in order for them pass non-EAPOL frames. Would this
>> encourage users to install home routers instead of home switches in
>> their dorms and offices so that they could have one machine that does
>> the 802.1x and gets the network up for the rest?
>>
> Well the settings I initially gleaned from:
>
> http://www.oneunified.net/blog/2007/04/30/
>
> I was unaware of the fallback MAC authentication approach until I  
> read it,
> it had been recently added to IOS from my understanding.
>
> The client workstations after the link is brought up have about ten  
> seconds
> to respond otherwise the switch goes about waiting for the MAC  
> address to
> appear (usually in a DHCP packet).  This is then used to form a RADIUS
> authentication packet, the MAC address is used for the username and  
> password.
> Our RADIUS server (FreeRADIUS) is primed to notice this as a  
> 'legacy' system
> and deal with it appropriately.  If the MAC address is registered in  
> our LDAP
> tree then it is dumped in a VLAN[1].
>
> If the MAC address is not recognised the RADIUS server decides the  
> client does
> not have an 802.1x supplicant and dumps them in a 'get-a-supplicant'  
> VLAN.
>
> In the case when someone has a supplicant installed (even after lets  
> say the
> MAC based authentication has taken place) an EAP-Start packet is  
> fired off
> which resets the whole 802.1x state machine on the switch and then  
> user (we
> use EAP-TTLS via SecureW2 however PEAP or even TLS could be used)
> authentication helps decide which VLAN they are placed in[2].
>
> Before the *authorisation* kicks in the MAC address is checked if it  
> is
> registered and if not dumps them in a registration VLAN.  If the  
> machine is
> registered then they get dumped straight into the 'users- 
> unmanaged' (our
> users but on laptops/workstations that our university is not  
> responsible for)
> VLAN.  The exception to this are eduroam[3] users; if the realm is  
> not one
> that we handle and the authentication succeeds then the work station  
> is
> dumped straight into the 'eduroam' VLAN as we are not permitted to  
> collect
> details regarding eduroam roaming users[4].
>
>> How about projectors? Most printers probably support 802.1x. Are  
>> these
>> things dealt with as exceptions where somehow the switch config for
>> that device needs to allow that device to not use 802.1x?
>>
> *Pre-registered* as being permitted to use MAC authentication.
>
>> It's an interesting deployment scenario, that's why I am asking.  
>> These
>> are questions that I have wondered about whenever thinking about  
>> 802.1x.
>>
> I can see why you are curious.  There was *nothing* out there for me  
> to work
> on.  All the conslutants had no advice other than "make sure you  
> have a good
> testbed" :-/  It was complete trial and error on my part.  I  
> probably have
> missed other details[5] so do ask and it is probably tucked away in  
> my brain
> somewhere :)
>
> So in conclusion, this is completely new territory.  All those  
> commercial NAC
> solutions actually do *not* support 802.1x and simply over throw the  
> switch
> configuration forcing them kludgly into a 'quarantine' VLAN.  We  
> wanted
> something far more graceful where we change an LDAP object (to  
> 'quarantine'
> for example) and then re-initialise the 802.1x state machine for the  
> port on
> the switch or AP.
>
> Fortunately my employer (a university) was happy for me to write one  
> from
> scratch in Perl</smugness> :)
>
> Cheers
>
> Alex
>
> [1] this is pretty much identical to a VMPS approach but without the  
> need for
> 	OpenVMPS and gives you the perfect 802.1x migration strategy for some
> 	time in the future
> [2] well this home brewed (GPL and still in development) NAC  
> solution of ours
> 	actually lets workstations exist in a number of VLAN's and users can
> 	only exist in a single VLAN.  Where ever there is this overlap that
> 	is the VLAN the machine is placed into
> [3] http://www.eduroam.org/
> [4] if an abuse issue arises we blacklist the MAC address
> [5] such as that a Cisco 440x sucks as you cannot disassociate  
> someone via
> 	SNMP and that Mac OS X machines (and Linux) will not renew their DHCP
> 	lease if you force a re-authentication of the port they are connected
> 	to (so you have to shutdown the port for ten seconds and then
> 	re-enable it)
>
> -- 
> ____________________________________
> / A journey of a thousand miles must \
> | begin with a single step.          |
> |                                    |
> \ -- Lao Tsu                         /
> ------------------------------------
>        \   ^__^
>         \  (oo)\_______
>            (__)\       )\/\
>                ||----w |
>                ||     ||
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog