| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks! 938r1 addresses these. I continued to use the SSID of the BSS
language instead of the SSID element in the Beacon frame. While we do
not really support hidden SSIDs in the standard, we might as well
write this in a form that would work for that case as well.
- Jouni
On Thu, May 16, 2024 at 12:14 PM Henry Ptasinski <henry@xxxxxxxxxx> wrote:
>
> > - The RSNXE that the Authenticator sent in its Beacon or Probe Response frame, if this element is present in the Beacon or Probe Response frame that the Authenticator sent.
> > - The SSID of the BSS when both the Authenticator and the Supplicant have indicated support for SSID protection in the RSNXE.
>
> This should specify how the SSID is included, especially since 12.7.6.6 requires the Supplicant to check that "the Key Data field in message 3 contains the SSID element". I would suggest "The SSID element that the Authenticator sent in its Beacon or Probe Response frame ..." (Do we need to deal with APs that null out the SSID in beacons here? Or is that just a problem for implementations to deal with?)
>
> I think this bit of 12.7.6.1 also need updating to include the SSID element:
>
> Message 3: AuthenticatorSupplicant:
> EAPOL-Key(1,1,1,1,P,0,(#1406)RSC,ANonce,MIC,{RSNE [, RSNXE] [, OCI].
> GTK[N]} [, IGTK(M, IPN)] [, BIGTK(Q, BIPN)] [, WIGTK(R, WIPN)]}(#6590)
>
> - Henry
>
> On Thu, May 16, 2024 at 1:23 AM Jouni Malinen <jkmalinen@xxxxxxxxx> wrote:
>>
>> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>>
>> There is a recently published paper that describes issues in how the
>> SSID is not authenticated in all cases and how that can be combined
>> with some upper layer actions, e.g., with VPN being disabled in a
>> trusted network, to expose a security vulnerability. Robust way of
>> mitigating this type of a vulnerability is likely to require a
>> protocol change.
>>
>> Taken into account the recent publication of the paper (or well,
>> formally it is targeting a conference in about a week's time, but the
>> paper is publicly available now), I would like to discuss this in TGme
>> today, if we have time available in the agenda.
>>
>> I posted this contribution that proposed a simple extension to allow
>> the SSID to be protected in 4-way handshake (which is one of the
>> options proposed in the paper for addressing the vulnerability):
>> https://mentor.ieee.org/802.11/dcn/24/11-24-0938-00-000m-protect-ssid-in-4-way-handshake.docx
>>
>> I would appreciate review and comments on the document. If the TG is
>> willing, I might make a motion to approve this document (or an updated
>> version of it based on comments) during the TGme PM2 slot today.
>>
>> - Jouni
>>
>> _______________________________________________________________________________
>>
>> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
>> CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
>>
>> SELF SERVICE OPTION:
>> Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
>> then amend your subscription on the form provided. If you require removal from the reflector
>> press the LEAVE button.
>>
>> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
>> _______________________________________________________________________________
>
>
>
> --
> Henry Ptasinski
> President
> Element78 Communications LLC
> henry@xxxxxxxxxx
> +1-415-608-0637
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1