Gordon Messmer wrote:> On 02/23/2018 03:22 AM, hw wrote: >> I?m not sure how to imagine it.? It would be nice if every device connecting to >> the network, wirelessly or otherwise, had to be authenticated --- and not only >> the device, but also the user(s) using it. > > https://www.networkworld.com/article/2940463/it-skills-training/machine-authentication-and-user-authentication.html > > 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. It doesn?t apply at all here.>> There are devices that are using PXE-boot and require access to the company LAN. >> If I was to allow PXE-boot for unauthenticated devices, the whole thing would be >> pointless because it would defeat any security advantage that could be gained by >> requiring all devices and users to be authenticated: Anyone could bring a device >> capable of PXE-booting and get network access. > > You don't seem to understand the suggestions you're being given. > > An unauthenticated device should be placed on a VLAN with appropriate access.? If you have devices that need to PXE boot before authenticating, then you should have a VLAN that gives them DHCP service, DNS, and tftp to boot an OS.? That VLAN shouldn't have access to the protected company resources, and it doesn't have to have Internet access either.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. IIUC, when using RADIUS, devices can be denied network access before they get any because the switch or wirless access point the devices use to get network access negotiates access rights for the devices on behalf of the devices with the RADIUS server rather than that the devices are given network access to negotiate thier access rights themselves. That?s supposed to provide better security, and it makes sense to me. Hence allowing unauthorized devices network access (to PXE boot and then to negotiate further access rights --- or whatever) doesn?t make any sense. 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.> Once the system boots, the users can authenticate themselves, which will move the device onto a VLAN with access appropriate for an authenticated user.Like I said in other posts, that?s probably not possible because when you cut the clients off from access to the server they booted from by moving them into a different VLAN, they will simply freeze until the connection is restored.>>> Well, I guess I'm confused because having explained where you'd find the interface in which users will provide their RADIUS username and password, you think this process is unfeasible.? Perhaps you could explain what you're looking for, more precisely? >> >> As a customer visting a store, would you go to the lengths of configuring your >> cell phone (or other wireless device) to authenticate with a RADIUS server in >> order to gain internet access through the wirless network of the store? > > 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.> I'm not sure I understand the use case you're describing.? I'm not sure you do, either.Right --- that?s why I was asking for documentation about how RADIUS can be actually used rather than documentation only saying that it can be used but not how. You can?t very well design a use case for a particular software when you do not know what the software is capable of and if it is applicable at all, and you can not very well design the use case when you don?t even know if what you might want is possible. Yet you need to start somewhere to get somewhere. 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? I?m merely asking how to ride the darn horses. Perhaps I?m better off with a car, but I can?t tell before I know how to ride horses.
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. (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. If your device can communicate with a switch, even for the purpose of authenticating, then it has network access. 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.> 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.>> 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.> 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?
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.