Message ID | 20180806194643.1328-1-Mathy.Vanhoef@cs.kuleuven.be |
---|---|
Headers | show |
Series | Add support for Operating Channel Validation (OCV) | expand |
On Mon, Aug 06, 2018 at 03:46:18PM -0400, Mathy Vanhoef wrote: > This patchset adds support for Operating Channel Validation (OCV). The > main idea of this feature is to verify the current operating channel > when connecting to a network. This prevent multi-channel > Man-in-the-middle attacks. A detailed description of this feature can be > found here: > https://mentor.ieee.org/802.11/dcn/17/11-17-1807-12-000m-defense-against-multi-channel-mitm-attacks-via-operating-channel-validation.docx Thanks, applied with cleanup and fixes. > - I've included a bunch of automated tests. Some of these currently use > reset_ap, but it seems that function is not always reliable? Sometimes > a test fails, but when running again the test succeeds. reset_ap() sequences seemed to trigger some kernel warnings that made the test cases fail for me all the time. I fixed those by using hapd.disable() followed by adding the AP with new configuration. In addition, the station side needed to be quite a bit more careful to avoid hitting issues with old scan results (i.e., explicitly clear the scan results whenever the AP configuration changes).
Great to see this being included, thanks for cleaning up the patches! On Mon, 17 Dec 2018 17:12:21 +0200 Jouni Malinen <j@w1.fi> wrote: > On Mon, Aug 06, 2018 at 03:46:18PM -0400, Mathy Vanhoef wrote: > > This patchset adds support for Operating Channel Validation (OCV). The > > main idea of this feature is to verify the current operating channel > > when connecting to a network. This prevent multi-channel > > Man-in-the-middle attacks. A detailed description of this feature can be > > found here: > > https://mentor.ieee.org/802.11/dcn/17/11-17-1807-12-000m-defense-against-multi-channel-mitm-attacks-via-operating-channel-validation.docx > > Thanks, applied with cleanup and fixes. > > > - I've included a bunch of automated tests. Some of these currently use > > reset_ap, but it seems that function is not always reliable? Sometimes > > a test fails, but when running again the test succeeds. > > reset_ap() sequences seemed to trigger some kernel warnings that made > the test cases fail for me all the time. I fixed those by using > hapd.disable() followed by adding the AP with new configuration. In > addition, the station side needed to be quite a bit more careful to > avoid hitting issues with old scan results (i.e., explicitly clear the > scan results whenever the AP configuration changes). >