lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <86y222vuuc.fsf@gmail.com> Date: Wed, 23 Feb 2022 09:40:59 +0100 From: Hans Schultz <schultz.hans@...il.com> To: Jakub Kicinski <kuba@...nel.org>, Hans Schultz <schultz.hans@...il.com> Cc: davem@...emloft.net, netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov <nikolay@...dia.com>, Shuah Khan <shuah@...nel.org>, Stephen Suryaputra <ssuryaextr@...il.com>, David Ahern <dsahern@...nel.org>, Ido Schimmel <idosch@...dia.com>, Petr Machata <petrm@...dia.com>, Amit Cohen <amcohen@...dia.com>, Po-Hsu Lin <po-hsu.lin@...onical.com>, Baowen Zheng <baowen.zheng@...igine.com>, linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org, linux-kselftest@...r.kernel.org Subject: Re: [PATCH net-next v4 0/5] Add support for locked bridge ports (for 802.1X) On tis, feb 22, 2022 at 11:15, Jakub Kicinski <kuba@...nel.org> wrote: > On Tue, 22 Feb 2022 14:28:13 +0100 Hans Schultz wrote: >> This series starts by adding support for SA filtering to the bridge, >> which is then allowed to be offloaded to switchdev devices. Furthermore >> an offloading implementation is supplied for the mv88e6xxx driver. >> >> Public Local Area Networks are often deployed such that there is a >> risk of unauthorized or unattended clients getting access to the LAN. >> To prevent such access we introduce SA filtering, such that ports >> designated as secure ports are set in locked mode, so that only >> authorized source MAC addresses are given access by adding them to >> the bridges forwarding database. Incoming packets with source MAC >> addresses that are not in the forwarding database of the bridge are >> discarded. It is then the task of user space daemons to populate the >> bridge's forwarding database with static entries of authorized entities. >> >> The most common approach is to use the IEEE 802.1X protocol to take >> care of the authorization of allowed users to gain access by opening >> for the source address of the authorized host. >> >> With the current use of the bridge parameter in hostapd, there is >> a limitation in using this for IEEE 802.1X port authentication. It >> depends on hostapd attaching the port on which it has a successful >> authentication to the bridge, but that only allows for a single >> authentication per port. This patch set allows for the use of >> IEEE 802.1X port authentication in a more general network context with >> multiple 802.1X aware hosts behind a single port as depicted, which is >> a commonly used commercial use-case, as it is only the number of >> available entries in the forwarding database that limits the number of >> authenticated clients. >> >> +--------------------------------+ >> | | >> | Bridge/Authenticator | >> | | >> +-------------+------------------+ >> 802.1X port | >> | >> | >> +------+-------+ >> | | >> | Hub/Switch | >> | | >> +-+----------+-+ >> | | >> +--+--+ +--+--+ >> | | | | >> Hosts | a | | b | . . . >> | | | | >> +-----+ +-----+ >> >> The 802.1X standard involves three different components, a Supplicant >> (Host), an Authenticator (Network Access Point) and an Authentication >> Server which is typically a Radius server. This patch set thus enables >> the bridge module together with an authenticator application to serve >> as an Authenticator on designated ports. >> >> >> For the bridge to become an IEEE 802.1X Authenticator, a solution using >> hostapd with the bridge driver can be found at >> https://github.com/westermo/hostapd/tree/bridge_driver . >> >> >> The relevant components work transparently in relation to if it is the >> bridge module or the offloaded switchcore case that is in use. > > You still haven't answer my question. Is the data plane clear text in > the deployment you describe? Sorry, I didn't understand your question in the first instance. So as 802.1X is only about authentication/authorization, the port when opened for a host is like any other switch port and thus communication is in the clear. I have not looked much into macsec (but know ipsec), and that is a crypto (key) based connection mechanism, but that is a totally different ballgame, and I think it would for most practical cases require hardware encryption.
Powered by blists - more mailing lists