netdev - Re: [PATCH net-next v4 0/5] Add support for locked bridge ports (for 802.1X)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.