hostapd/wpa_supplicant - new development release v0.3.4

[Leonardo Maccari]

On Wed, Jan 12, 2005 at 04:38:59PM -0800, Jouni Malinen wrote:
> The current version has only WPA-None and that "None" is indeed the
> missing key management part.


I'm trying with 3 machines in ad-hoc mode and it doesn't work, I guess
this needs some per-machine code, like IV management, right? So I guess
next big step should be having a per-machine configuration and then
move authenticator SM into supplicant.

something like: add a list of known stations to struct wpa_supplicant

wpa_supplicant_sta_info * 	sta_list

add a list of "associated" stations to struct wpa_supplicant

wpa_supplicant_sta_info * 	rsn_associated_sta_list


when a new station is encountered, after receiving a probe reply it should
be added
to the sta_list. the sta_list is to be refreshed every time a probe
request is sent and probe replies are received (is this compliant?
standard doesn't specify this kind of behaviuor to my memory).
then with a selected criteria (all, less then #, powerful ones?) some of
the stations could be used to create RSNA. 

so there must be a wpa_supplicant_sta_info structure defined in
wpa_supplicant_i.h which could be something similar to sta_info in hostapd
code (stripped down of some pieces?).

when beacons, probe requests, probe responses are received, there sta_list
is updated.

when a new station is selected for RSNA, in the function
wpa_supplicant_associate() there should be something like:

struct wpa_supplicant_sta_info * sta;
[...]
	if(ssid->mode == 1)
	{
		sta = wpa_supplicant_rsna_start(new_station);
      if(!sta){
         	wpa_printf(MSG_ERROR, "some error");
            return -1;
      }
	}

it's unclear to me how to decide when to end such an rsna. apart from
clear events, like deassociation or deauthentication, the standard doesn't
seem to dictate when a station should consider a neighbour unreachable.
it just says:

8.4.10 RSNA security association termination
When an SME receives or invokes of any of the MLME association,
reassociation, disassociation, authentication, or deauthentication
request or indication primitives, or if it believes that it has drifted
out of radio range of another STA, it will delete some security
associations.[...]
In the case of an IBSS, the STA's SME shall delete the PTKSA and the
receive GTKSA. Once the security associations have been deleted, the SME
then invokes MLME-DELETEKEYS.request primitive to delete all temporal keys
associated with the deleted security associations. The IEEE 802.1X
Controlled Port returns to being blocked. As a result, all data frames are
unauthorized before invocation of an MLME- DELETEKEYS.request
 
my 2 cents.

ciao,
leonardo.


-- 
   Key fingerprint = 3129 C583 F03B 2E73 0115  C040 3489 0185 B592 19FE
 Obviously -thisaintpartofmyaddress- is not part of my real email address