Pete Biggs wrote:> >> >>> https://www.eduroam.org/ >>> >>> I configure wireless once on my device (phone/tablet/laptop) and then can >>> travel to institutions all round the world and use their networks seamlessly. >>> How useless and infeasible indeed. >> >> Well, this country > > "this country"?Germany>> is almost the worst of all countries around the world when >> it comes to internet access. Though they list a few locations here where you >> supposedly could use their service, I wouldn?t expect anything. Then there?s >> the question of protecting your privacy. For example, how much do they pay you >> for allowing them to keep track of your travels? > > I think you've got the wrong idea about eduroam. John Hodrien was just > using it as a real world example of WPA2-enterprise in action. It's a > private network for academic institutions - it allows members of > Universities around the world to gain access to the wifi at a local > University they are visiting. It's not a public wifi service.It isn?t really private, either.> It's a convenience - a very, very convenient convenience. If you don't > want someone tracking where you are, then don't use it. But TBH if you > are visiting another university, then in general your location is > known!Without wireless, your general location may be known as in "visiting university X"; with wireless, your location is known as in "is currently in room X of building Z". That is quite a difference, and in either case, what about your privacy?>> In any case, it wouldn?t do our customers any good because there aren?t places >> all over the world where they could use our network. > > Your customers wouldn't be able to use it anywayIf there were places all over the world where they could use our network, they could.>>> A client that can't authenticate gets the network it's provided with by being >>> unauthenticated. If an unauthenticated client can't have any network access, >>> that's what they get. Presumably you could drop an unauthenticated machine >>> into a different VLAN. >> >> That would be a problem because clients using PXE-boot require network access, >> and it wouldn?t contribute to security if unauthorized clients were allwed to >> PXE-boot. >> > So restrict based on MAC address at the PXE boot stage.MAC addresses could be faked.> The PXE protocol, as far as I can see, has no concept of authorisation > - although its certainly possible to introduce it after PXE has done > its bit (but before imaging or whatever). > > You may be better off with authenticating the DHCP using RADIUS, but > it's a complex process which, by its very nature, requires some form of > non-authenticated network access.So the solution might have to be not to use PXE-boot anymore. That would be a pity because it?s so convenient.
> MAC addresses could be faked. > > > The PXE protocol, as far as I can see, has no concept of authorisation > > - although its certainly possible to introduce it after PXE has done > > its bit (but before imaging or whatever). > > > > You may be better off with authenticating the DHCP using RADIUS, but > > it's a complex process which, by its very nature, requires some form of > > non-authenticated network access. > > So the solution might have to be not to use PXE-boot anymore. That would > be a pity because it?s so convenient. >PXE booting is nothing to do with installing or imaging machines. That process is done *after* PXE booting. All the PXE does is to tell the ethernet chip where to retrieve the PXE information from and what to retrieve, which is then downloaded by TFTP. A prerequisite for PXE is DHCP - by the time your device does anything with PXE it's already accessed the network and got an IP address and so on. There is absolutely no way to prohibit access to your network without first allowing the device some access to your network in order to authenticate. The normal way around this is to use VLANs to segregate "dirty" unauthenticated machines - once it's authenticated it is moved onto a different VLAN and a new DHCP request initiated. There's lots of information on this on the net - Google for something like 'PXE RADIUS' or 'PXE 802.1x' (hint: everyone uses VLANs). P.
Pete Biggs wrote:> >> MAC addresses could be faked. >> >>> The PXE protocol, as far as I can see, has no concept of authorisation >>> - although its certainly possible to introduce it after PXE has done >>> its bit (but before imaging or whatever). >>> >>> You may be better off with authenticating the DHCP using RADIUS, but >>> it's a complex process which, by its very nature, requires some form of >>> non-authenticated network access. >> >> So the solution might have to be not to use PXE-boot anymore. That would >> be a pity because it?s so convenient. >> > > PXE booting is nothing to do with installing or imaging machines. That > process is done *after* PXE booting. All the PXE does is to tell the > ethernet chip where to retrieve the PXE information from and what to > retrieve, which is then downloaded by TFTP.I know, and it?s still convenient.> A prerequisite for PXE is DHCP - by the time your device does anything > with PXE it's already accessed the network and got an IP address and so > on. There is absolutely no way to prohibit access to your network > without first allowing the device some access to your network in order > to authenticate. The normal way around this is to use VLANs to > segregate "dirty" unauthenticated machines - once it's authenticated it > is moved onto a different VLAN and a new DHCP request initiated.Suddenly moving the client to a different VLAN would have the same effect as unplugging the network cable: it would freeze until the connection is restored. Otherwise, the server would have to be reachable via several VLANs, which would make it pointless to use these VLANs.> There's lots of information on this on the net - Google for something > like 'PXE RADIUS' or 'PXE 802.1x' (hint: everyone uses VLANs).Ok.