diff mbox series

passphrase/psk in wps cred handling in hostapd and wpa_supplicant

Message ID CANQpynh-YKBuuw_OVC8LusN90FfVHww54CBogY0DLbVKc9z+CA@mail.gmail.com
State RFC
Headers show
Series passphrase/psk in wps cred handling in hostapd and wpa_supplicant | expand

Commit Message

viktor babrian June 26, 2019, 10:42 a.m. UTC
Hi there,

when performing a wps pbc session, credential either contains the psk
or the passphrase. I case of hostapd, this depends only on the config
(whether wpa_passphrase or wpa_psk is specified (later)). This
behavior correlates with comments found in the code, e.g. in wps.h,
near the definition of network_key.

However if AP is set up using wpa_supplicant, wps cred is always
passed containing the generated or specified psk. To my understanding,
this is caused by that the wpa_supplicant always passes psk if it is
set in wpa_supplicant_conf_ap() in ap.c. In wpa_supplicant psk is
generated every time passphrase is set/changed, so psk is always set.
I changed wpa_supplicant_conf_ap() so that passphrase gets passed if
set (see below). Can anybody confirm ? I have just read the code, I do
not know anything of the original intentions etc.


Regards,
Viktor

Comments

Jouni Malinen June 26, 2019, 5:08 p.m. UTC | #1
On Wed, Jun 26, 2019 at 12:42:06PM +0200, viktor babrian wrote:
> when performing a wps pbc session, credential either contains the psk
> or the passphrase. I case of hostapd, this depends only on the config
> (whether wpa_passphrase or wpa_psk is specified (later)). This
> behavior correlates with comments found in the code, e.g. in wps.h,
> near the definition of network_key.
> 
> However if AP is set up using wpa_supplicant, wps cred is always
> passed containing the generated or specified psk. To my understanding,
> this is caused by that the wpa_supplicant always passes psk if it is
> set in wpa_supplicant_conf_ap() in ap.c. In wpa_supplicant psk is
> generated every time passphrase is set/changed, so psk is always set.
> I changed wpa_supplicant_conf_ap() so that passphrase gets passed if
> set (see below). Can anybody confirm ? I have just read the code, I do
> not know anything of the original intentions etc.

Providing PSK to the Enrollees is the preferred option if the Enrollee
is known not to have use for the passphrase (e.g., share it with another
device) since use of PSK instead of passphrase saves CPU. The original
reason for this design was to use the device capabilities (whether the
Enrollee indicates it has a display), but the main current use is in
preferring to use PSK for all the P2P cases since the passphrase is
likely to be a random temporary value for the group. The changes here
would seem to break that design.
viktor babrian June 26, 2019, 6:53 p.m. UTC | #2
HIi,

thanks for the prompt reply.

> Providing PSK to the Enrollees is the preferred option if the Enrollee
> is known not to have use for the passphrase (e.g., share it with another
> device) since use of PSK instead of passphrase saves CPU. The original
> reason for this design was to use the device capabilities (whether the
> Enrollee indicates it has a display), but the main current use is in
> preferring to use PSK for all the P2P cases since the passphrase is
> likely to be a random temporary value for the group. The changes here
> would seem to break that design.
I see. Eventually I need to pass the passphrase in my case :|. I guess
I will need to use hostapd then.
In P2P cases, is there an ASCII passphrase specified? Temporary values
aren't always psks?

Regards,
Viktor
Jouni Malinen June 26, 2019, 7:13 p.m. UTC | #3
On Wed, Jun 26, 2019 at 08:53:16PM +0200, viktor babrian wrote:
> I see. Eventually I need to pass the passphrase in my case :|. I guess
> I will need to use hostapd then.

It would be fine for the core wpa_supplicant code to pass in both the
passphrase and PSK (if available) to the WPS module and then potentially
change the WPS implementation to have different rules on when to provide
the passphrase. Since I do not know what your use case is here for
needing the passphrase, I cannot recommend any specific rules for doing
such selection, though.

> In P2P cases, is there an ASCII passphrase specified? Temporary values
> aren't always psks?

Yes, the P2P GO is required to generate a passphrase and that passphrase
is required to be available from the GO for manual configuration of
non-P2P clients. However, there is no expectation of the passphrase
being exposed by the P2P clients in the group. Furthermore, the PSKs for
each P2P client in the group could be different (i.e., the passphrase
would be used only with non-P2P clients).
diff mbox series

Patch

--- ap_orig.c   2019-06-26 12:09:49.778442128 +0200
+++ ap.c        2019-06-26 12:10:57.051258094 +0200
@@ -370,7 +370,10 @@ 
        else
                bss->wpa_key_mgmt = ssid->key_mgmt;
        bss->wpa_pairwise = ssid->pairwise_cipher;
-       if (ssid->psk_set) {
+       if (ssid->passphrase) {
+               bss->ssid.wpa_passphrase = os_strdup(ssid->passphrase);
+       }
+       else if (ssid->psk_set) {
                bin_clear_free(bss->ssid.wpa_psk, sizeof(*bss->ssid.wpa_psk));
                bss->ssid.wpa_psk = os_zalloc(sizeof(struct hostapd_wpa_psk));
                if (bss->ssid.wpa_psk == NULL)
@@ -378,8 +381,6 @@ 
                os_memcpy(bss->ssid.wpa_psk->psk, ssid->psk, PMK_LEN);
                bss->ssid.wpa_psk->group = 1;
                bss->ssid.wpa_psk_set = 1;
-       } else if (ssid->passphrase) {
-               bss->ssid.wpa_passphrase = os_strdup(ssid->passphrase);
        } else if (ssid->wep_key_len[0] || ssid->wep_key_len[1] ||
                   ssid->wep_key_len[2] || ssid->wep_key_len[3]) {
                struct hostapd_wep_keys *wep = &bss->ssid.wep;