On Wed, Nov 21, 2018 at 10:42:03PM +0100, Michal Kazior wrote:
> This has been prompted by the thread on the mailing list
> "dynamically added/removed PSKs without MAC pairing".
> I guess it's a little iffy to expose PMK in cli/logs. I was
> considering using explicit tags/aliases in wpa_psk_file in
> the format of `tag mac psk`, e.g.
>
> tag_1 00:00:00:00:00:00 secretpassword
> tag_2 00:00:00:00:00:00 different111
>
> But asked myself if it's really more secure or is it just
> unnecessarily complex. FWIW The tag could be made optional
> so old wpa_psk_file format would remain working with no
> changes. Thoughts?
I don't think we should be exposing the PSK/PMK/passphrase over the
control interface (or accidentally in any debug log dumping control
interface commands/events). The use case here does not seem to have any
use for the particular PSK value, i.e., it depends on only knowing some
identifier for the particular key. As such, I'd go with a key
identifier. That could be added as an optional part before the MAC
address to maintain backwards compatibility of the file format (with the
old no-identifier versions not getting the new events/exposure through
STA command). E.g., "keyid=foo 02:00:00:00:00:00 password".
> AP: keep track and expose WPA-PSK PMK info of each station
As noted above, I'd like to see changes in this design.
> AP: add wpa_psk_file reloading in runtime
This makes mostly sense, but this could get more complex if the key
identifier is added and it is used for grouping devices. In such a case,
moving a device from one group (keyid) to another could be a dynamic
change that occurs when reloading the file. It might make most sense to
disconnect the station in such a case if the keyid ("group") changes
even though when the PSK/passphrase would still remain in the file.
The use case I'm mostly thinking about here is an extension of this to
allow VLAN binding based on the "keyid", e.g., in the form of VLAN ID or
a netdev ifname.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
