Gordon Messmer wrote:> On 02/27/2018 08:21 AM, hw wrote: >> Gordon Messmer wrote: >>> I've never seen anyone actually do this, but there's an article discussing it.? It is noteworthy that this requires enforcement in the client OS, as well as the switch. >> >> The article itself says that what it is describing only works within a >> Windoze world. > > That's what I said.Well, it is not applicable here.> (Also, "Windoze"?? Can we at least pretend to be a community of professionals?) > >> I understand that it is suggested that I should give all unauthorized devices >> network access (so that they can PXE boot or whatever), which is what I >> don?t want to do. > > It is illogical to lump all network access together into a single category.That depends on your point of view. When you have access to a network, you have better chances of being able to do something you?re not supposed to than you have when you don?t have any access at all. That doesn?t say anything about how it is logical or makes sense or not to create different categories of network access.> If your device can communicate with a switch, even for the purpose of authenticating, then it has network access.The device has access to the switch which, depending on what answer to an authentication request it gets from a RADIUS server, decides if and how it lets the device access the network. Maybe that?s not how it works; it?s only what I?ve been reading.> A device cannot authenticate if the processor is idle.? The processor needs software in order to authenticate.? If that software resides on an TFTP server, rather than a locally attached storage device, then the device needs limited network access to retrieve the software (after which it runs the software, authenticates the user or the device, and receives greater levels of network access.) > > Providing a VLAN on which there are no private resources, and no Internet access, may be a required component if you have devices that boot via PXE.? Honestly, people are trying to help you, but you are placing logically contradictory requirements on the project.You mean I?m not allowed to say that I don?t want to allow unauthorized devices to access the network and having some that use PXE boot because it makes ppl trying to help think that this is contradictory. I can?t help that because it is the situation I have to deal with. Live is generally full of contradictions, and everyone has to deal with that. I don?t see what the problem is other than ppl trying to decide for me what I am allowed to say or to think or to have to deal with, and that is something I very much dislike. It isn?t helpful, either. If PXE boot is not possible because it would require to allow network access to unauthorized devices, or if it is not reasonably feasible because switching the device to a different VLAN after allowing unauthorized access for booting and then providing credentials to authenticate the device (or the user) will result in the device freezing and thus being useless, then that just is so, and I have to deal with it.>> I also understand that it may be possible that there is a variety of PXE boot >> which addresses this problem by allowing devices to authenticate before they >> boot.? However, some of the devices in question are likely to old to support >> this. > > The device needs to have software adequate to authenticate itself or its user.? It's logically possible to run software from some local storage, authenticate, retrieve a new software image from PXE, and then chainload that.? If you don't have a device that does that, specifically, then you need to provide a VLAN that supports the devices you DO have.Other options would be not to use PXE boot or to allow the devices network access as needed.> >>> Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS? >> >> They might get it from employees of the store or read it from signs >> inside the store, perhaps depending on what kind of access rights they >> are supposed to have. > > If you're sharing passwords, then you don't need RADIUS.? Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal.? Using RADIUS will be no more secure than that.? It's not magic.Right, but what about keeping track of customers? Apparently RADIUS has some accounting features, and it might be an advantage to use those.> >> Imagine you want to ride a horse and don?t know anything about horses. You >> look for documentation about horses, and the only documentations you can find >> are telling you that horses exist, how to get one and that they can be used for >> riding.? How helpful is that? > > Imagine that someone is trying to help you learn to ride horses, and you spend all of your time complaining that you think animals are dirty. How helpful is that?This analogy doesn?t apply. It?s more like I?m wondering if the horse can be fast enough or haul the load I might need to get hauled or if it requires too much upkeep. And when I say "I would need the horse to haul 1/4 ton while I can?t feed it more grain than I have", ppl trying to help are getting pissed because they think it?s somehow illogical having to deal with the given requirements. Yeah, well, logic can be pretty irrelevant in most situations.
This is really nothing to do with CentOS anymore, if it ever was. On Thu, 1 Mar 2018, hw wrote:> If PXE boot is not possible because it would require to allow network access > to unauthorized devices, or if it is not reasonably feasible because > switching the device to a different VLAN after allowing unauthorized access > for booting and then providing credentials to authenticate the device (or > the user) will result in the device freezing and thus being useless, then > that just is so, and I have to deal with it.Why would that *have* to result in the device freezing? You can PXE boot to a kernel and initrd that after it's downloaded runs just fine without any network access at all. There's no requirement for a PXE client to have network access to anything other than a VLAN with a boot server that provides it with a boot image. You can obviously add on frippery that only recognises approved MACs for even this if you feel the need.> Right, but what about keeping track of customers? Apparently RADIUS has > some accounting features, and it might be an advantage to use those.I really don't get why you want WPA2 Enterprise for this setup. There's a reason why almost everyone uses captive portals for providing access to lots of external users. jh
John Hodrien wrote:> This is really nothing to do with CentOS anymore, if it ever was.right> On Thu, 1 Mar 2018, hw wrote: > >> If PXE boot is not possible because it would require to allow network access >> to unauthorized devices, or if it is not reasonably feasible because >> switching the device to a different VLAN after allowing unauthorized access >> for booting and then providing credentials to authenticate the device (or >> the user) will result in the device freezing and thus being useless, then >> that just is so, and I have to deal with it. > > Why would that *have* to result in the device freezing?? You can PXE boot to a > kernel and initrd that after it's downloaded runs just fine without any > network access at all.Like I said, they are x2go clients booting from the x2go server. Switching them to another VLAN from where they can?t reach the server is basically the same as unplugging the network cable, in which case they freeze until the connection is restored, and giving them access to the server so that they can boot before they are authorized is useless when I don?t want to allow network access for unauthorized clients, and it is pointless because they would already have the access they are supposed to have only after they are authorized.> There's no requirement for a PXE client to have network access to anything > other than a VLAN with a boot server that provides it with a boot image.? You > can obviously add on frippery that only recognises approved MACs for even this > if you feel the need.Sure, but how great may the lengths be you can go before it is not reasonably feasible to do what you?re doing?>> Right, but what about keeping track of customers?? Apparently RADIUS has >> some accounting features, and it might be an advantage to use those. > > I really don't get why you want WPA2 Enterprise for this setup.? There's a > reason why almost everyone uses captive portals for providing access to lots > of external users.I didn?t say I want that, and I don?t know yet what I want. A captive portal may be nice, but I haven?t found a way to set one up yet, and I don?t have an access point controller which would provide one, so I can?t tell if that?s the right solution.
On 03/01/2018 03:06 AM, hw wrote:> >> It is illogical to lump all network access together into a single >> category. > ... >> If your device can communicate with a switch, even for the purpose of >> authenticating, then it has network access. > > The device has access to the switch which, depending on what answer to an > authentication request it gets from a RADIUS server, decides if and > how it > lets the device access the network.You're still lumping networks into a single category. Not "the" network, but "a" network. Unauthenticated clients are, by definition connected to A network consisting of the device and the switch.? They might also be connected to a network consisting of the device, a switch, and a TFTP server that provides the boot image to the client.? And since there is nothing else on that network, other than a read-only TFTP server that your devices require in order to boot, it's difficult to understand why you think there is a security risk here. Security is the process of restricting access to a resource to only the devices and persons that require it.? If your devices require a boot image before they can authenticate, then restricting their access to that resource can no longer be described as "security.">>>> Where do your hypothetical customers in a store get the user >>>> credentials that you want to authenticate via RADIUS? >>> >>> They might get it from employees of the store or read it from signs >>> inside the store, perhaps depending on what kind of access rights they >>> are supposed to have. >> >> If you're sharing passwords, then you don't need RADIUS.? Set up >> separate SSIDs that are attached to VLANs with appropriate access >> levels, and continue using WPA2 Personal.? Using RADIUS will be no >> more secure than that.? It's not magic. > > Right, but what about keeping track of customers?? Apparently RADIUS > has some > accounting features, and it might be an advantage to use those.It does, but you will get exactly the same information using WPA2 Personal that you will from WPA2 Enterprise and RADIUS.? "A client connected to the WAP at such and such time.? It disconnected at such and such time." If you're sharing passwords, RADIUS is the most complex way to get the information.? You can get the same info by simply logging WAP events to a log server.
Gordon Messmer wrote:> On 03/01/2018 03:06 AM, hw wrote: >> >>> It is illogical to lump all network access together into a single category. >> ... >>> If your device can communicate with a switch, even for the purpose of authenticating, then it has network access. >> >> The device has access to the switch which, depending on what answer to an >> authentication request it gets from a RADIUS server, decides if and how it >> lets the device access the network. > > You're still lumping networks into a single category. > > Not "the" network, but "a" network.There is only one network here.> Unauthenticated clients are, by definition connected to A network consisting of the device and the switch.? They might also be connected to a network consisting of the device, a switch, and a TFTP server that provides the boot image to the client.? And since there is nothing else on that network, other than a read-only TFTP server that your devices require in order to boot, it's difficult to understand why you think there is a security risk here.Let me quote: "the RADIUS protocol serves three primary functions: ? Authenticates users or devices before allowing them access to a network"[1] Why would I give access to a network consisting of an unauthorized device, a switch and a TFTP server to such device and thereby possibly to an attacker? Can you guarantee that there is no way for an attacker who can have such a network connection will not find a way to proceed with an attack? They can bring a device that does not PXE boot and is equipped with everything they might need to perform their attack. When the only things the devices of attackers can communicate with are switches or wireless access points which do not give them access to a network (other than the devices and the switches or access points themselves), it is likely to be more difficult to perform a sucessful attack than it is when they get access to a wider network, like one that involves a server. [1]: http://networkradius.com/doc/FreeRADIUS%20Technical%20Guide.pdf> > Security is the process of restricting access to a resource to only the devices and persons that require it.? If your devices require a boot image before they can authenticate, then restricting their access to that resource can no longer be described as "security."That?s kinda what I said.> >>>>> Where do your hypothetical customers in a store get the user credentials that you want to authenticate via RADIUS? >>>> >>>> They might get it from employees of the store or read it from signs >>>> inside the store, perhaps depending on what kind of access rights they >>>> are supposed to have. >>> >>> If you're sharing passwords, then you don't need RADIUS.? Set up separate SSIDs that are attached to VLANs with appropriate access levels, and continue using WPA2 Personal.? Using RADIUS will be no more secure than that.? It's not magic. >> >> Right, but what about keeping track of customers?? Apparently RADIUS has some >> accounting features, and it might be an advantage to use those. > > It does, but you will get exactly the same information using WPA2 Personal that you will from WPA2 Enterprise and RADIUS.? "A client connected to the WAP at such and such time.? It disconnected at such and such time."It might be possible to find out how much data was transferred with accounting.> > If you're sharing passwords, RADIUS is the most complex way to get the information.? You can get the same info by simply logging WAP events to a log server.Yes, it?s very simple to use the same password on all phones of employees and no password on the wireless for customers. Logging the events might be enough then. Somehow that doesn?t feel like it is a good solution, but I don?t know.