Re: Regarding status code in initial SAE confirm message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, 2021-09-08 at 19:44 +0000, RAGHAVENDRA SADARAMACHANDRA
(rsadaram) wrote:
> Hi James,
> 
>    Thanks for the response. 
>    Reg - " If hostapd receives a confirm with non-success status code
> it treats that as the peer rejecting" =====> Peer rejecting of which
> frame? In client and AP case, client is the one which first sends SAE
> confirm. Here there is no previous confirm message for the client to
> reject. Spec mentioned about rejection of previous SAE confirm
> message.

Ah ok I see where you're coming from now. I think this would be more a
question to the spec writers than anything... but yes I agree the spec
does not line out what to do in this case.

Personally I would expect to reject the peers connection all together
like hostapd does.

Also, I wouldn't expect an initial confirm message with a non-success
status code to actually contain a confirm hash. The only context that
makes sense is if the peer is rejecting the connection entirely.

Thanks,
James

> 
> -Raghu
> 
> 
> On 9/8/21, 12:30 PM, "James Prestwood" <prestwoj@xxxxxxxxx> wrote:
> 
>     Hi,
> 
>     On Wed, 2021-09-08 at 19:08 +0000, RAGHAVENDRA SADARAMACHANDRA
>     (rsadaram) wrote:
>     > Any info on below query?
>     > 
>     > On 9/3/21, 11:13 PM, "RAGHAVENDRA SADARAMACHANDRA (rsadaram)"
>     > <rsadaram@xxxxxxxxx> wrote:
>     > 
>     >     Hi All,
>     > 
>     >     What's the importance/use of status code in initial confirm
>     > message from the client. Do we need to check for status code ==
>     > success in confirm message from the client.
>     > 
>     >     Spec does not talk about status code in initial confirm
> message.
> 
>     I don't think the spec cares about "initial confirm" vs any other
>     confirm. Its just a confirm message.
> 
>     > It mentions: An SAE Confirm message, with a status code not
> equal to
>     > SUCCESS, shall indicate that a peer rejects a previously sent
> SAE
>     > Confirm message. An SAE Confirm message that was not
> successfully
>     > verified is indicated with a status code of CHALLENGE_FAILURE. 
> 
>     How does that not describe the intended behavior? If hostapd
> receives a
>     confirm with non-success status code it treats that as the peer
>     rejecting. Seems reasonable to me.
> 
>     > 
>     > 
>     >                } else if (auth_transaction == 2) {
>     >                     hostapd_logger(hapd, sta->addr,
>     > HOSTAPD_MODULE_IEEE80211,
>     >                                    HOSTAPD_LEVEL_DEBUG,
>     >                                    "SAE authentication (RX
> confirm,
>     > status=%u (%s))",
>     >                                    status_code,
>     > status2str(status_code));
>     >                     if (status_code != WLAN_STATUS_SUCCESS)
>     >                             goto remove_sta;
>     > 
>     > 
>     >     -Raghu
>     > 
>     > 
>     > _______________________________________________
>     > Hostap mailing list
>     > Hostap@xxxxxxxxxxxxxxxxxxx
>     > http://lists.infradead.org/mailman/listinfo/hostap
> 
> 
> 



_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux