netdev - Re: [PATCH net-next v2 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] [day] [month] [year] [list]

Date:   Mon, 14 Feb 2022 08:16:54 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Hans Schultz <schultz.hans@...il.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 0/5] Add support for locked bridge ports
 (for 802.1X)

On Mon, 14 Feb 2022 09:58:12 +0100 Hans Schultz wrote:
> On fre, feb 11, 2022 at 14:59, Jakub Kicinski <kuba@...nel.org> wrote:
> > On Wed,  9 Feb 2022 14:05:32 +0100 Hans Schultz wrote:  
> >> 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.  
> >
> > noob question - this is 802.1x without crypto? I'm trying to understand
> > the system you're describing.  
> 
> No, user space will take care of authentication, f.ex. hostapd, so in a
> typical setup the supplicant and the authentication daemon will take
> care of all crypto related stuff in their communication.
> So the authentication daemon will open the port for the authenticated
> supplicant.

To be clear - I'm talking about wire crypto after all the communication
with the control plane and after the connection the port is opened. Not
crypto in whatever authentication method gets used. Does the device get
the keys somehow from user space?

> See the cover letter.

Which part of it?