Blog

Uitgelicht

OPENROAMING

openroameduroam is recent lid geworden van de Wireless Broadband Alliance. Hierdoor is het hopelijk binnenkort mogelijk om automatisch te roamen met andere Wi-Fi hotspots wereldwijd. Het idee is dat mobiele apparaten automatisch lid worden van een Wi-Fi-abonnee service wanneer de gebruiker een hotspot 2.0-gebied binnengaat.

Hotspot 2.0 (ook wel passpoint genoemd) is gebaseerd op de IEEE 802.11u-standaard, een verzameling protocollen die in 2011 is gepubliceerd om cellulair-achtige roaming mogelijk te maken. Als het apparaat 802.11u ondersteunt en een abonnement op een Hotspot 2.0-service heeft, maakt het automatisch verbinding.

eduroam heeft de grootste federatieve roaming infrastructuur:

  • 7.200 IdPs
  • 30.000 locaties
  • 106 landen

Roaming is gestandariseerd op basis van een SSID ‘eduroam’ en maakt gebruik van WPA2 enterprise. (eduroam maakt geen gebruik van WPA3, zie ook https://www.eduroam.org/2018/06/26/eduroam-and-wpa3/)

Hotspot 2.0 – HS20 – Passpoint

Openroaming kan gebruik maken van:

  • RCOI : (Roaming Consortium Organisation Identifier)
  • NAIrealm, domain, 3GPP (MNC/MCC, offloading
  • ANQP : (Access Network Query Protocol) voor discovery van netwerken (home, roaming, EAP-types)
  • WPA(2)-Enterprise, EAP

Er zijn meerdere releases met daarbij beperkte support:

R2: Online Sign-UP (OSU)

R3: Veilige ‘AUP/T&C portal

Details in RADIUS voor routering:

OpenRoaming maakt gebruik van veilige authenticatieprotocollen zoals

RadSec, EAP-Transport Layer Security (EAP-TLS), EAP-tunnel TLS (EAP-TTLS) of EAP-verificatie en sleutelovereenkomst (AKA). Al het authenticatieverkeer is TLS-versleuteld (!)

OpenRoaming netwerken zijn beveiligde netwerken en maken gebruik van Wi-Fi Protected Access (WPA) 2-Enterprise of WPA3 over-the-air encryptie, en als zodanig bieden bescherming op ondernemingsniveau, in tegenstelling tot de huidige open draadloze technologie
gastnetwerken

Dynamic peer discovery (RadSec)

eduroam en openroaming kunnen gebruik maken van ‘dynamic peer discovery’ (zie ook RFC7593)

voorbeelden :

Dynamische routering her en der in gebruik voor uitzonderingen, tussen landen:

host -t naptr zone.college
zone.college has NAPTR record 50 50 “s” “x-eduroam:radius.tls” “” _radsec._tcp.surfnet.eduroam.nl.

Delegatie:

% host -t naptr kennisnet.nl
kennisnet.nl has NAPTR record 50 50 “s” “x-eduroam:radius.tls” “” _radsec._tcp.kennisnet.eduroam.nl.

OpenRoaming:

% host -t naptr edu.nl
edu.nl has naptr record 50 50 “s” “x-eduroam:radius.tls” “” _radsec._tcp.edu.nl.
edu.nl has naptr record 50 50 “s” “aaa+auth:radius.tls.tcp” “” _radsec._tcp.openroaming.eduroam.org.

% host -t naptr zone.college
zone.college has NAPTR record 50 50 “s” “x-eduroam:radius.tls” “” _radsec._tcp.surfnet.eduroam.nl.

% host -t srv _radsec._tcp.openroaming.eduroam.org.
_radsec._tcp.openroaming.eduroam.org has SRV record 0 0 2083 openroaming1.eduroam.org.

Provisioning gaat heel belangrijk worden om de juiste configuratie(RCOI) bij de klant te kunnen installeren.

Mocht je hulp nodig hebben om gebruik te willen maken van een hotspot 2.0 netwerk of andere Wi-Fi vraagstuk neem dan contact met mij op. Ik ben op korte termijn beschikbaar en kan het gebruik van je Wi-Fi netwerk een enorme boost geven!

Wat is het verschil tussen de Intel Wi-Fi 6 AX201 en Intel Wi-Fi 6 AX200 driver in Windows?

Intel Wi-Fi AX201 ondersteunt geen UNII-3 kanalen in Windows 10/11 met de laatste drivers

Zowel de Intel® Wi-Fi 6 AX200 als de Intel® Wi-Fi 6 AX201 ondersteunen 2x2 Wi-Fi 6-technologie, inclusief nieuwe functies zoals:
  • Uplink/Downlink OFDMA
  • 1024QAM
  • Data rates up to 2.4 Gbps

Het belangrijkste verschil tussen de twee is dat de Intel® Wi-Fi 6 AX201 een CRF-module is die de eigen Intel-interface gebruikt en dus alleen kan worden gebruikt met bepaalde Intel-chipsets en -platforms.

Tot zover de informatie die je vanuit Intel op de website kan lezen maar nu de praktijk: https://www.intel.com/content/www/us/en/support/articles/000054819/wireless.html

Intel AX201 ondersteunt geen UNII-3 kanalen in Windows 10 / Windows 11 met de laatste Intel Windows drivers 22.160.0.4 De Intel AX200 ondersteunt daarin tegen wel de UNII-3 kanalen in Windows 10/11

De UNII-3 kanalen zijn in Nederland vrijgegeven en kunnen zonder problemen gebruikt worden. Zie ook https://en.wikipedia.org/wiki/List_of_WLAN_channels#5GHz

Hierbij het bewijs dat de Intel AX201 geen ondersteuning heeft voor UNII-3 kanalen in Windows :

(getest met WLAN-PI profiler)

---------------------------------------------
 - Client MAC: 7c:70:db:xx:xx:xx
 - OUI manufacturer lookup: Unknown
 - Capture channel: 60
---------------------------------------------
802.11k              Supported           
802.11r              Not reported*       
802.11v              Supported           
802.11w              Supported           
802.11n              Supported (2ss)     
802.11ac             Supported (2ss), SU BF not supported, MU BF not supported
802.11ax_draft       Supported (Draft)   
Max_Power            15 dBm              
Min_Power            0 dBm               
Supported_Channels   36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,144

* Reported client capabilities are dependent on available features at time of client association.
** Reported channels do not factor local regulatory domain.

Intel Wi-Fi AX201 160 MHz

De volgende HP laptops zijn bij mij bekend dat ze gebruik maken van de Intel Wi-Fi AX201 chipset.

  • HP Probook 630 G8
  • HP Probook 630 G8 Notebook PC
  • HP Probook 640 G8
  • HP Probook 640 G8 Notebook PC
  • HP Probook 650 G8
  • HP Probook 650 G8 Notebook PC

Als je dezelfde Wi-Fi AX201 chipset in Ubuntu 22.04 zou testen met (bijvoorbeeld) WLAN-PI profiler dan ondersteunt Ubuntu wel alle kanalen !:

Volgens Intel WiFi 6 AX201 Test Report zou de AX201 hardware de UNII-3 kanalen wel moeten ondersteunen en dat klopt dus ook maar niet in Windows 10 of Windows 11….

Update Intel Wireless Adapters driver: 27 beveiligings problemen ontdekt

Er zijn 27 beveiligingsproblemen ontdekt in de Intel® PROSet/Wireless Wi-Fi drivers!

De volgende kwetsbaarheden zijn ontdekt:

CVEID:  CVE-2021-0162 : Improper input validation in software – may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access

CVEID:  CVE-2021-0163 : Improper Validation of Consistency within input in software – may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access

CVEID:  CVE-2021-0161 : Improper input validation in firmware – may allow a privileged user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0164 : Improper access control in firmware – may allow an unauthenticated user to potentially enable  escalation of privilege via local access

CVEID:  CVE-2021-0165 : Improper input validation in firmware – may allow an unauthenticated user to potentially enable denial of service via adjacent access

CVEID:  CVE-2021-0066 : Improper input validation in firmware – may allow an unauthenticated user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0166 : Exposure of Sensitive Information to an Unauthorized Actor in firmware – may allow a privileged user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0167 : Improper access control in software – may allow a privileged user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0169 : Uncontrolled Search Path Element in software – may allow a privileged user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0168 : Improper input validation in firmware – may allow a privileged user to potentially enable escalation of privilege via local access

CVEID:  CVE-2021-0170 : Exposure of Sensitive Information to an Unauthorized Actor in firmware – may allow an authenticated user to potentially enable information disclosure via local access.

CVEID:  CVE-2021-0171 : Improper access control in software – may allow an authenticated user to potentially enable information disclosure via local access

CVEID:  CVE-2021-0172 : Improper input validation in firmware – may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVEID:  CVE-2021-0173 : Improper Validation of Consistency within input in firmware – may allow a unauthenticated user to potentially enable denial of service via adjacent access

CVEID:  CVE-2021-0174 : Improper Use of Validation Framework in firmware – may allow a unauthenticated user to potentially enable denial of service via adjacent access.

CVEID:  CVE-2021-0175 : Improper Validation of Specified Index, Position, or Offset in Input in firmware – may allow an unauthenticated user to potentially enable denial of service via adjacent access

CVEID:  CVE-2021-0076 :  Improper Validation of Specified Index, Position, or Offset in Input in firmware – may allow a privileged user to potentially enable denial of service via local access.

CVEID:  CVE-2021-0176 : Improper input validation in firmware – may allow a privileged user to potentially enable denial of service via local access.

CVEID:  CVE-2021-0177 : Improper Validation of Consistency within input in software – may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVEID:  CVE-2021-0178 : Improper input validation in software – may allow an unauthenticated user to potentially enable denial of service via adjacent access

CVEID:  CVE-2021-0179 : Improper Use of Validation Framework in software – may allow an unauthenticated user to potentially enable denial of service via adjacent access

CVEID:  CVE-2021-0183 :  Improper Validation of Specified Index, Position, or Offset in Input in software – may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVEID:  CVE-2021-0072 : Improper input validation in firmware – may allow a privileged user to potentially enable information disclosure via local access

CVEID: CVE-2021-33110 : Improper input validation –  may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVEID:  CVE-2021-33113 : Improper input validation – may allow an unauthenticated user to potentially enable denial of service or information disclosure via adjacent access.

CVEID:  CVE-2021-33115 : Improper input validation – may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access

CVEID:  CVE-2021-33114 : Improper input validation – may allow an authenticated user to potentially enable denial of service via adjacent access

Getroffen producten:
Intel® PROSet/Wireless Wi-Fi-producten:

Intel® Wi-Fi 6E AX210
Intel® Wi-Fi 6 AX201
Intel® Wi-Fi 6 AX200
Intel® Wireless-AC 9560
Intel® Wireless-AC 9462
Intel® Wireless-AC 9461
Intel® Wireless-AC 9260
Intel® Dual Band Wireless-AC 8265
Intel® Dual Band Wireless-AC 8260
Intel® Dual Band Wireless-AC 3168
Intel® Wireless 7265 (Rev D) familie
Intel® Dual Band Wireless-AC 3165
Intel® AMT Wireless-producten:

Intel® Wi-Fi 6 AX210
Intel® Wi-Fi 6 AX201
Intel® Wi-Fi 6 AX200
Intel® Wireless-AC 9560
Intel® Wireless-AC 9260
Intel® Dual Band Wireless-AC 8265
Intel® Dual Band Wireless-AC 8260

Killer™ Wi-Fi-producten:

Killer™ Wi-Fi 6E AX1675
Killer™ Wi-Fi 6 AX1650
Killer™ Wireless-AC 1550

Aanbeveilingen:

Windows:

Intel raadt aan de Intel® PROSet/Wireless Wi-Fi-software bij te werken naar versie 22.80 of hoger.

https://www.intel.com/content/www/us/en/download/19351/windows-10-and-windows-11-wi-fi-drivers-for-intel-wireless-adapters.html

Intel raadt aan om de Killer™ Wi-Fi-software bij te werken naar versie 3.1021.733.0 of hoger.

https://www.intel.com/content/www/us/en/download/19779/intel-killer-performance-suite.html

bronnen :

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00539.html

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00581.html

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00582.html

Original release: 02/08/2022

Optimaliseer je Wi-Fi omgeving!

Optimaliseer je Wi-Fi omgeving!

Rogue access points en tethering clients maken vaak gebruik van dezelfde frequenties en/of kanalen. Niet-802.11-apparaten bezetten de gebruikte kanalen.  Hierdoor kunnen de access-points en clients niet optimaal functioneren.

Rogue access-points zijn niet-geautoriseerde draadloze access-points waarvan aanschaf en installatie buiten de ICT om zijn gegaan en waarvoor geen expliciete toestemming is gegeven door ICT. Je kunt rogue acces-points in je panden identificeren en isoleren indien je alternatieven hebt. Daarnaast is het ook van belang dat er huisregels, reglementen of beleid is om de rogue-access-points in je panden te kunnen ‘elimineren’.

Wi-Fi Tethering is het delen van de mobiele internetverbinding van uw toestel (meestal een smartphone) met andere apparaten, zoals een tablet, laptop of computer. Ook wordt soms gesproken over het gebruik van een ‘hotspot’.

Niet-802.11-apparaten zijn: Bluetooth apparaten, magnetrons, bewegingsdetectie, draadloze camera’s, etc. Wanneer deze apparaten aanwezig zijn, kunnen ze een of meer van uw kanalen bezetten, waardoor de signaal-ruisverhouding (SNR) van de draadloze gebruiker wordt verminderd en daardoor een aanzienlijk verlies van bandbreedte veroorzaken.

Het gebruik van tethering, het plaatsen van niet beheerde access-points of aanwezigheid van genoemde storingsapparaten, heeft een negatief effect op het draadloze netwerk.

Met betrekking tot tethering en rogue access-points treden er twee problemen op:

Aan de hand van een voorbeeld maak ik duidelijk wat Adjacent Channel Congestion is:

Je luistert met je vrienden naar een concert. Achter je zit een drummer die helemaal los gaat en tegelijkertijd praten alle mensen in de zaal met elkaar, ieder in een eigen groep. Er komt zoveel geluid binnen dat het moeilijk is jouw gesprek met je vrienden voort te zetten. Wanneer jij luider begint te praten, moet de persoon naast je ook zijn stem verheffen. Je hoort dat er meerdere gesprekken plaatsvinden en je hoort de muziek van de band, maar het is onmogelijk om nog te communiceren. Dit is precies wat er gebeurt met draadloze apparaten die proberen te communiceren in een drukke omgeving.

Alle access-points horen eigenlijk uitsluitend gebruik te maken van kanaal 1,6 of 11 in de 2.4 GHz. Zodra er een andere kanaal in gebruik en/of aanwezig is anders dan 1,6 en 11 zal er ‘Adjacent Channel Congestion‘ plaatsvinden. Dit is wat het voorbeeld duidelijk maakt.

Aan de hand van een voorbeeld maak ik duidelijk wat Co-channel Interference is:

Om congestie van co-kanalen te kunnen begrijpen moeten we ons een denkbeeldig gesprek voorstellen in een klaslokaal. Denk terug aan je schooltijd – de kans is groot dat je van minstens één klas kunt bedenken dat de ene leerling langzamer praat dan de anderen. Alle anderen moeten dan op hun beurt wachten om een vraag te stellen.

Co-channel congestie werkt op een vergelijkbare manier: de prestaties worden gehinderd door de wachttijden. Elk apparaat krijgt de kans om met de bijbehorende Access-Points te praten als het aan de beurt is.

Om bovenstaande problemen binnen je beheerde Wi-Fi domein op te lossen zul je een aantal zaken moeten inregelen:

Om het rogue-access-point van derde partijen uit je beheerde Wi-Fi-omgeving te kunnen verwijderen heb je een alternatief nodig voor deze partijen.Binnen het onderwijs wordt er gebruik gemaakt van Eduroam. Dit is een besloten community waarvan commerciële partijen  geen gebruik mogen maken. (Er is weliswaar een SURFnet derden regeling maar deze is vaak onvoldoende (Zie https://www.surf.nl/surfinternet-een-snelle-betrouwbare-internetverbinding/derden-aansluiten-op-surfnet.) Je bent daarom verplicht om gebruik te maken van een andere (commerciële) internetkoppeling.

Open Wi-Fi kan een oplossing zijn voor tijdelijk internet, mits je daarnaast ook gebruik maakt van een VPN. Voor bedrijven is dit geen oplossing. Je zult naast Eduroam dan ook nog een andere Wi-Fi-oplossing moeten aanbieden. Zolang je deze oplossingen via je eigen Wi-Fi-infrastructuur kan aanbieden heb je geen last van ‘rogue-access-points’.

De ‘tethering-clients’ blijven daarentegen een behoorlijke uitdaging. Deze onwenselijke WiFi-verbindingen kunnen wel tot een minimum beperkt worden als er gebruik wordt gemaakt van MDM / portals waarin deze mogelijkheden worden afgeraden en/of via policies worden afgedwongen/verboden.

Mocht je hulp nodig hebben om zoveel mogelijk rogue access-points en/of andere storingsbronnen te identificeren en/of processen hiervoor in te willen regelen neem dan contact met mij op. Ik ben op korte termijn beschikbaar en kan je Wi-Fi netwerk een enorme boost geven!

Zie ook https://wifision.nl/mijn-aanbod/

Best practice: Aggregated Probe Response Optimizations

WiFisionAggregated Probe Response Optimizations

For large high density deployments, it is advisable to modify the default aggregate probe interval sent by access points. By default, the APs will update every 500ms about the probes sent by clients, this information is used by load balancing, band select, location and 802.11k features.

If there is a large number of clients and access points, it is advisable to modify the update interval, to prevent control plane performance issues in the WLC(!)

To change:

config advanced probe limit 50 64000

That would set it to 50 aggregated probe responses every 64 seconds.

Restriction:This should be used in most scenarios with very large count of access points and clients.

(wc-wifision) >show advanced probe

Probe request filtering…………………….. Enabled
Probes fwd to controller per client per radio…. 50
Probe request rate-limiting interval…………. 64000 msec
Aggregate Probe request interval…………….. 200 msec
Increased backoff parameters for probe respon…. Disabled

source: Cisco Wireless LAN Controller (WLC) Configuration Best Practices

Advice to eduroam® Identity Providers and Service Providers following the release of Wi-Fi CERTIFIED #WPA3™ Security

Executive Summary

The biggest change in Wi-Fi CERTIFIED WPA3™ Security is about pre-shared key deployments, which are not in scope for eduroam IdPs. There are small but useful benefits for WPA3-Enterprise, and there is a new optional operation mode WPA3-Enterprise with 192-Bit Security with significant interoperability issues on the deployed base of eduroam WPA-Enterprise hotspots.

The only action, which typically does not require monetary investments at all, is to turn on support for Protected Management Frames (PMFs) and to turn off WPA1 in the existing eduroam SP network deployment.

WPA3-Enterprise with 192-Bit Security MUST NOT be configured.

Wi-Fi CERTIFIED WPA3™ is a trademark of Wi-Fi Alliance®.
eduroam® is a registered trademark and servicemark of GEANT Association.

Changes in WPA3-Personal with pre-shared keys

What was formerly a WPA2-PSK network (one passphrase protects the entire SSID) gets modernised. The passphrase remains as-is, but the algorithm to derive the Wi-Fi master session key from the user-supplied WPA passphrase gets changed and is now based on the
“Dragonfly” algorithm. It is called WPA3-SAE (Simultaneous Authentication of Equals). eduroam Identity Providers may know the Dragonfly algorithm for its appearance in the EAP type “EAP-pwd”.

Changes in WPA3-Enterprise
Changes for all WPA3-Enterprise deployment modes, including eduroam’s WPA-EAP

The changes are very small.

  • WPA3-Enterprise includes a roll-up of several late additions to WPA2-Enterprise certification. This ensures that WPA3-Enterprise certified devices are guaranteed to
    o be immune against the KRACK vulnerability
    o support Protected Management Frames (PMF)
    o validate a server certificate to a root CA, if such a root CA is configured. Note:

    • There is still not a requirement to actually have a CA certificate configured.
  • Support for Protected Management Frames (PMFs) is a requirement

There is no explicit “mixed mode”, nor is one required: a WPA3-Enterprise network is identical to a WPA2-Enterprise network which has configured support for Protected Management Frames (PMF). So long as PMFs are only configured as supported, rather than required, older WPA2 devices can continue to connect to the network as if it were a normal WPA2 network.

Only the backwards compatibility to WPA(1) is discontinued, which should not have any significant relevance in the eduroam environment any more. This makes it easy and useful for eduroam Service Providers to activate WPA3-Enterprise by marking Protected Management Frames as “supported, but not required” in their network equipment and by turning off support for WPA1.

Since most equipment supports PMFs since many years, typically, no new investment in Wi-Fi CERTIFIED WPA3™ hardware is required for this.

Considering that a BYOD environment such as eduroam typically has a very diverse set of user devices, including old devices which potentially do not support PMFs, it is considered premature to make PMFs required at this point in time. eduroam operations will revisit this position in due time.

The new operation mode WPA3-Enterprise with 192-Bit security

There is an optional new operation mode in Wi-Fi CERTIFIED WPA3™: WPA3-Enterprise with 192-Bit security. This operation mode is based on EAP just like the normal WPA3-Enterprise mode, but has further constraints regarding the permitted cipher suites; both during the TLS negotiation inside of tunnelling EAP methods [2] and for group ciphers on the wireless medium. The list of cipher suites and key lengths mirrors a regulatory requirement by a committee of various intelligence agencies in the United States of America[1] designed for their local government agencies and military operation (“Commercial National Security
Algorithm Suite”,CNSA). Despite being part of the Wi-Fi CERTIFIED WPA3™ certification, which suggests that it has an immediate effect only between client devices and access points, its security requirements would also induce a stringent required feature set on the RADIUS/EAP server equipment of eduroam Identity Providers[2]. Early studies in the eduroam IdP landscape indicate that the cipher suite and key length requirements are not met by a majority of eduroam IdPs at this point in time. Furthermore, EAP methods not based on TLS – notably EAP-pwd – are not permitted at all on WPA3-Enterprise with 192-Bit Security networks.

Since WPA3-Enterprise with 192-Bit Security is configured on the access point, but needs compatible EAP servers at the Identity Provider side, with no signalling between the Access Point and the eduroam Identity Provider server, there is a significant risk for interoperability issues inside eduroam.

WPA3-Enterprise with 192-Bit Security, if enabled, must be the only key management on a given SSID. In order to continue to serve client devices which are uncapable of 192-Bit Security, there must be two distinct SSIDs: ‘eduroam’ with the classic WPA3-Enterprise, and a new SSID for WPA3-Enterprise with 192-Bit Security

To work around those issues, there are three possibilities:

Option A: step-change upgrade sequence: all IdPs -> then SPs
A global upgrade in eduroam infrastructure would need to be done in two phases:

1) first, all eduroam Identity Providers globally upgrade their RADIUS/EAP servers to meet the IdP-side requirements of WPA3-Enterprise with 192-Bit Security

2) strictly only after that, eduroam Service Providers start to upgrade their Access Point configuration to WPA3-Enterprise with 192-Bit Security at their own pace

Option B: per-IdP regime of client configurations

All eduroam Identity Providers individually need to make sure that all their own users’ client configurations do not allow the respective device to connect to any WPA3-Enterprise with 192-Bit Security eduroam network until the eduroam Identity Provider has upgraded their authentication server to support the TLS cipher suites required by WPA3-Enterprise with 192-Bit Security (at which point in time its users can be signalled to change their configuration at their own pace).

eduroam Identity Providers not enforcing such a configuration restraint would subject their users to the aforementioned interoperability problems. Given the diverse implementation quality of EAP supplicants, the vastly varying richness of expression of configuration formats, and the fact that a significant fraction of users will not follow configuration advice (including connecting without pre-configuration to non-standard SSIDs), realising this modus operandi appears unrealistic. This option also still needs a new SSID, with the same legacy support reasoning as in Option A, above.

Option C: Do not transition to WPA3-Enterprise with 192-Bit Security
eduroam Identity Providers that are interested in the level of security that WPA3-Enterprise with 192-Bit Security brings can upgrade their RADIUS/EAP server to support only the three cipher suites in question at any time, while remaining compatible with the existing eduroam SP setup in WPA2-Enterprise and WPA3-Enterprise.
This will achieve almost the same result as WPA3-Enterrprise with 192-Bit Security by steering and enforcing cipher suite selection from the IdP-side, and without the interoperability problems of the actual change of operation mode. The only minor difference is then the group cipher on the medium.

Advice
Considering that the WPA3-Enterprise with 192-Bit Security operation mode’s primary use case is in one country outside its educational community, combined with the fact that option B above is unrealistic, and the significant deployment complexities of option A above,

eduroam currently pursues option C above, i.e. does not currently have any plans to engage in any transition in any way.

Due to that, until further notice, eduroam Service Providers are advised NOT to configure WPA3-Enterprise with 192-Bit Security. Doing so anyway will lead to hard to debug authentication failures for users of the majority of eduroam Identity Providers.

[1] https://www.cnss.gov – yes, the web site really has a certificate which is not in browser trust stores.
[2] EAP peers and servers need to support TLS1.2 with the cipher suites ECDHE-RSA-AES256-GCM-SHA384,
ECDHE-ECDSA-AES256-GCM-SHA384 and/or DHE_RSA_WITH_AES_256_GCM_SHA384. Further to this, where RSA keys are used, they need to be at least 3072 bit long; where ECDSA keys are used, they need to be based on curve P-384

Source : Download the original advisory notice

Understanding Various AP-IOS Flash Corruption Issues

 Introduction

This document describes flash corruption problems reported on IOS based Cisco Access Points(AP).

Requirements

Cisco recommends that you have basic knowledge of:

  • AireOS WLCs
  • Lightweight APs

 

Components Used

  • Cisco Aironet 1040, 1140, 1250, 1260, 1600, 1700, 2600, 2700, 3500, 3600, 3700, 700, AP801, and AP802 Series indoor access points
  • Cisco Aironet 1520 (1522, 1524), 1530, 1550 (1552), 1570, and Industrial Wireless 3700 Series outdoor and industrial wireless access points

Note: Problem is present AireOS 8.0.x to 8.5.x release trains. There is a much higher prevalence in Wave1 AP models like 1700/2700/3700  and 2600/3600  on this issue vs other AP types due to flash HW type.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Wave 1 APs can report no flash access or file system corruption, especially when upgrading the WLC.

The corruption can cause the following status on the AP

  • AP unable to save the configuration
  • AP unable to perform an upgrade
  • AP lose configuration
  • AP stuck in a booting loop
  • AP in ROMMON status –  console to the AP is need to recover the AP

Note: The issue is prelevant during upgrade scenarios where AP’s get hung/stuck, but not neccesarily is limited to WLC upgrade scenarios. AP’s may be working fine, servicing clients, etc, while on this problem state which is not easily detectable.

Symptoms of the problem

Flash Inaccessible

Command: show file system

The size and free space on flash would show as “-” instead of the actual value

Problem Output:

==============================
       Size(b)       Free(b)      Type  Flags  Prefixes				
*            -             -     flash     rw   flash:	
==============================

Normal output:

================================
       Size(b)       Free(b)      Type    Flags  Prefixes				
*     40900608       25282560     flash     rw     flash:
===============================

Command:  show flash

AP cannot display its files

Directory of flash:/
 %Error opening flash:/ (Invalid argument)

Command: show logging

AP can display de following messages.

*Mar  1 00:01:04.159: %LWAPP-3-CLIENTERRORLOG: Save LWAPP Config: error saving config file

.....


*Mar  1 00:01:04.159: %LWAPP-3-CLIENTERRORLOG: Load nvram:/lwapp_ap.cfg config
failed, trying backup...
*Mar  1 00:01:04.159: %LWAPP-3-CLIENTERRORLOG: Load nvram:/lwapp_ap.cfg.bak
config failed...

Command: fsck flash:

AP cannot verify its file system.

AP# fsck flash:
Fsck operation may take a while. Continue? [confirm]

%Error fscking flash: (Device or resource busy)

Note: This can occur in two scenarios: 1. When flash is inaccessible or 2. When the flash is still accessible, yet a file descriptor is leaked. Refer CSCvf28459 . The only workaround is to reload the AP.

 

Caution: When AP is in flash inaccessible state, the outcome of the reload is not always predictable. The AP may come back just fine or it may end up in the ROMMON or reboot loop at which point a console based recovery would be required. Please be prepared with console access to the site when performing this operation.

 

Corrupted Files

AP stuck in the following loop.

Loading "flash:/ap1g1-k9w8-mx.v153_80mr_esc.201603111020/ap1g1-k9w8-mx.v153_80mr_esc.201603111020"
...###############################################################################################
##################################################################################################
##################################################################################################
##################################################################################################
##################################################################################################
####################bad mzip file, unknown zip method?

Note: If You have a WLC with a different code than AP runs, forcing AP to join that WLC can fix the problem

 

Solution

Upgrade WLC as per the following document TAC Recommended AireOS Builds.

Caution: Before Upgrade, complete reading this document :

 

Before Upgrade

In order to identify affected AP on the network and fix them before an upgrade. Follow the next steps:

  • Download wlanpoller tool. (Python script.)
    • This is the Wireless Escalation tool (made by Federico Lovison @flovison)
  • Install the tool. For instructions look follow “README.md” file downloaded with the tool
  • Run script. For instructions look follow “README.md” file downloaded with the tool.

Tool Description

Every time the script is run it verifies whether an AP’s flash is accessible or not.

If it is accessible, it runs the command fsck flash:

  • If all is OK, move on to the next AP
  • else repeat the command up to 4 times

if it is inaccessible or command fsck flash is not successful after four times.

  • the script will flag AP on its final report in order to recover on the third run.

The script needs to be run three times.

  1. Run
    • The script will build MD5 database looking at MD5 checksum value for every file on the AP. The final MD5 value for a specific file is the one that has the more hits across same AP family on WLC.
  2. Run
    • The script starts comparing MD5 checksum values vs its database. If value matches then files is ok, if not then AP is flaged in order to recover on the third run
  3. Run
    • Enable recover flag on the configuration file.
    • The script triggers command test capwap image capwap only on the APs where the flash is accessible but some errors were found either fsck flash command failed  after 4 times and/or MD5 mismatch

Note: This recovery method causes the AP to reload once the image is downloaded and installed. Make sure you run it in a maintenance window.

 Tool Output

File: <timestamp>_ap_fs.csv – Summary of the checks executed on APs and their results

Columns description

  • ap_name: Name of the AP.
  • ap_type: AP model.
  • ap_uptime: Uptime for the AP (days).
  • ap_ios_ver: IOS version.
  • fs_free_bytes: Number of free bytes in flash file system.
  • flash_issue: True if any flash corruption has been observed.
  • fs_zero_size: True when flash hung has been detected file system showing “-“
  • fsck_fail: True if file system check has failed.
  • fsck_busy: True device or resource busy when doing flash fsck.
  • fsck_recovered: True when an error occurred on fsck but it is fixed in next fsck.
  • fsck_attempts: Number of attemps of fsck to recover the AP (max 4)
  • md5_fail: True when md5 at least one file is different from the stored in database.
  • rcv_trigger: True when AP tried to download image from WLC when issue has been detected and recovery has been enabled.

File: <timestamp>_ap_md5.csv   Details of the MD5 checksum values of all files (on all APs)

Columns description

  • ap_name: Name of the AP.
  • ap_type: AP model.
  • ap_uptime: Uptime for the AP (days).
  • filename: IOS image file name.
  • md5_hash: md5 value for filename.
  • is_good: True md5 value matches with value stored in db. False md5 mismatch observed for this file.
  • is_zero_bytes: True when filename has 0 bytes based on md5checksum so file is incorrect.
  • md5_error: Error message retriving md5 value if it was not possible to get md5 for filename.

Note: There could be scenarios where the WLANPOLLER recovery script is unable to recover certain AP’s and those AP remains flagged as failed in the report. In those scenarios, manual AP recovery by telnet/SSH/console into AP CLI is recommended. Please open TAC SR if you needed assistance on this process.

 

Reference Bug IDs

Bug ID Headline Symptoms Status Fixed releases
CSCuz47559  Error saving configuration file happens on Cisco Wave1 APs Flash hung Fixed 8.0MR5, 8.2MR6, 8.3MR3, 8.4+
CSCvd07423 AP firmware corrupt after power cycle bad mzip file, unknown zip method reboot loop Crash loop Fixed 8.3MR2, 8.5+
CSCvf16302 Flash on lightweight IOS APs gets corrupted AP stuck on rommon Fixed 8.5MR1, 8.3MR3(via CSCvg98786 )
CSCvf28459 Write of the Private File nvram:/lwapp_ap.cfg Failed on compare RCA needed (try = 1) Flash accessible but fsck not working Fixed  8.3MR4,8.2MR7,8.5MR1
CSCvg98786 IOS AP dtls flap issue seen in pre commit sanity Collateral Fixed 8.5MR1, 8.3MR3

 

source : Understanding Various AP-IOS Flash Corruption Issues

Updated:May 9, 2018
Document ID:213317

TAC Recommended AireOS Builds

 Introduction

This website describes the way in which the customers can find the most reliable Wireless LAN Controller software available. The Cisco Wireless TAC (Technical Assistance Center) recommends AireOS builds from each train of released AireOS software. These recommendations may be updated on a weekly basis. (please visit source TAC Recommended AireOS Builds for the latest version)

Contributed by Aaron Leonard, Cisco TAC Engineer.

Escalation Builds/Maintenance Interims

In some cases, the TAC recommended build might be an escalation or maintenance interim/beta build. Such builds are not available on CCO (Cisco.com), but have important bug fixes (beyond what is available in CCO code), and will be operational in production at customer sites for several weeks.

Note that, in some cases, the beta/escalation/interim build will contain support for unreleased features and/or hardware.  TAC does not support unreleased features or hardware – until official release, such support will come from the Business Unit (BU).

For released features and platforms, these builds are fully supported by TAC and the BU.In order to request a TAC recommended escalation/maintenance interim build, open a Cisco TAC case on your Wireless LAN Controller contract.

Caution: If you are planning to upgrade AireOS WLC from an older code train to a recommended release and have IOS AP’s in your deployment, please take a look at this article prior to performing the upgrade.

TAC Recommended Builds

AireOS 7.0

TAC recommends 7.0.252.0 (latest CCO release).  No further 7.0 releases are planned.  The recommended migration path is to AireOS 8.0, if the hardware supports it.

AireOS 7.4

TAC recommends 7.4.150.0 (latest CCO release).  No further 7.4 releases are planned.  The recommended migration path is to AireOS 8.0.

AireOS 7.6

TAC does not recommend any 7.6 CCO release, and Cisco does not plan to release any more 7.6 maintenance releases on CCO. The recommended upgrade path for AireOS 7.6 customers is to 8.0.

AireOS 8.0

For AireOS 8.0 customers, TAC recommends 8.0.152.0.

  • Customers with 1700/2700/3700 access points should run 8.0.152.0, or latest 8.2/8.3, due to CSCus83638 (AP 5Ghz Radio Beaconing but not accepting Client Assoc.)

AireOS 8.1

8.1.131.0 is the final maintenance release of AireOS 8.1, and is deferred. The recommended upgrade path for AireOS 8.1 customers is to 8.2.

AireOS 8.2

For deployments that require features or hardware introduced after 8.0, TAC recommends 8.2MR7 Interim,  due to  CSCve57121 , which causes intermittent traffic loss with AP-COS, and the SNMP TxPowerlevel regression.  Note: if you have AP-COS APs and are using TKIP, open a TAC case in order to get a fix for CSCve66630 .

AireOS 8.3

For deployments requiring features or hardware introduced after 8.2, TAC recommends 8.3.141.0.  Specifically, 8.3.141.0 fixes the following catastrophic regressions which affect 8.3.140.0:

  • CSCvi11287 2800 AP consistently rebooting around 1 second after joining
  • CSCvi14641  AP2802/3802 can’t connect with 100Mbps LAN speed

TAC does not recommend any public 8.3.13x.0 CCO release, due to the catastrophic bug CSCvf76274, which prevents APs from joining.

AireOS 8.4

AireOS 8.4 is a short lived release with no maintenance planned, and is deferred.  Any deployment that requires post-8.3 features or hardware should run 8.5 instead.

AireOS 8.5

For deployments that require support for new features and hardware introduced after 8.3, such as Assurance, and that do not have AP2802s, TAC recommends AireOS 8.5.120.0 or 8.5MR3 interim.  Customers who have AP2802s or AP1562s or SDA Wireless should use 8.5MR3 interim.

AireOS 8.6

AireOS 8.6.101.0 is a BU and TAC supported release.  Customers who require new features that are unavailable in 8.5 will need to run this release.

AireOS 8.7

AireOS 8.7.102.0 is a BU and TAC supported release. Customers who require new features that are unavailable in 8.6 will need to run this release.

Mobility Express

For Mobility Express deployments, TAC recommends using the 8.5.120.0 release, for improved usability and stability.  Mobility Express customers with AP2802s should open a TAC case to get a fix for CSCvi11287.

Note on SNMP TxPowerlevel regression bug

Deployments using SNMP/PI should be aware of the following regression:

CSCve70752  snmp issue: Txpowerlevel returns null causing PI WLC sync to not update AP information

This regression affects 8.2.16x.0, 8.3.12x.0 and above, 8.4 and above.  It is fixed in:

source : Aaron Leonard, Cisco TAC Engineer

Updated: May 9, 2018
Document ID: 200046

TAC Recommended AireOS Builds

De Wi-Fi Alliance heeft de eerste details van #WPA3 bekend gemaakt.

De Wi-Fi Alliance heeft de eerste details van WPA3 bekend gemaakt. De beveiligingstechniek voor Wi-Fi netwerken moet het eenvoudiger maken voor gebruikers om de beveiliging in te stellen op apparaten zonder scherm en standaard bescherming bieden bij gebruik van open netwerken.

WPA3 is standaard beveiligd tegen aanvallen zoals KRACK, biedt een eenvoudigere beveiligingsconfiguratie en voegt ook nieuwe beveiligingsmogelijkheden toe.

https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements

Voor eduroam zal het weinig impact hebben, de EAP-authenticatie blijft hetzelfde. Netwerken waar WPA1 nog aan stond (met mixed mode) zijn vanaf WPA3 verboden, maar die waren toch al uit den boze. We krijgen als extra nieuwe encryptie (192-bit), en bescherming van de management frames (nu kun je iemand zonder authenticatie disassocieren bijvoorbeeld).

(Er blijft overigens ook beperkt ontwikkeling in WPA2, en ook daar zijn opties voor management-frame protectie.)

Simultaneous Authentication of Equals (SAE)
De grootste verandering: netwerken met pre-shared-key worden veiliger (door “Simultaneous Authentication of Equals”, SAE)
SAE is bestand tegen passieve aanvallen, actieve aanvallen en “dictionary attacks”. Het biedt een veilig alternatief voor het gebruik van certificaten of wanneer een gecentraliseerde instantie niet beschikbaar is. Het is een peer-to-peer-protocol, heeft geen asymmetrie en ondersteunt gelijktijdige initiatie.

Opportunistic Wireless Encryption (OWE)
Ongeauthenticeerde netwerken zijn niet meer volledig open maar hebben nu ook encryptie (“Opportunistic Wireless Encryption”, OWE) met individuele sessie-keys. Zo zal OWE (RFC8110) bescherming bieden, ook als gebruikers zwakke wachtwoorden voor hun netwerk kiezen en er wordt dus individuele encryptie toegepast van verbindingen met open netwerken, om de privacy van de gebruiker te beschermen.

Vanaf 2020 moeten alle devices die het label “Wi-Fi Certified” willen WPA3 ondersteunen.

De impact voor eduroam is gering: we kunnen straks netwerken treffen die zowel WPA2 als WPA3 ondersteunen, met betere encryptie en management frame protectie als bonus.

Ik ben benieuwd wanneer we de eerste devices gaan zien met WPA3!

bronnen : SURFnet(eduroam-list) en Wi-Fi Alliance

#Cisco Workaround WPA2 vulnerability #krackattacks

Lezers,

Naar aanleiding van een discussie met Andrew von Nagy (WPA2 KRACK Vulnerability, Getting Information) ben ik samen met Javier Contreras Albesa er achter gekomen dat het mogelijk is om een WPA2 vulnerability workaround te implementeren in een Cisco omgeving:

“All are effectively implementation issues by allowing reuse of keystream material, meaning software patching can fix them! Of the 9 CVE’s related to clients, the most serious of them (7 of the 9, related to the 4-Way Handshake and Group Handshake) can be mitigated with AP / Infrastructure updates as a workaround, but the infrastructure won’t be able to determine if failure is from packet loss issues or attack. A few can’t be mitigated by AP patches (Peer-Key and tunneled direct link setup [TDLS]), which are peer-to-peer related vulnerabilities, but these methods of communication are rare and practically never used in my experience. The long-term fix is definitely client software patching. Patching Wi-Fi drivers can also fix 2 of the 9 client vulnerabilities…. The 1 CVE related to AP / Infrastructure is related to 802.11r Fast Transition – if you have it enabled you should patch ASAP. If not, no big deal. Many, many thanks go to Hemant Chaskar, Mojo Networks, and Pentester Academy!”

AND

“The EAPoL M3 (and M2/M4) include a MIC integrity check as well as a Key Replay Counter (KRC). The attacker cannot simply replay the initial M3 message from the Authenticator (AP) since the KRC will be the same and the client will discard it. The attack relies on the attacker MiTM AP blocking (not forwarding) the M4 frame to the AP, and the AP then retransmitting M3 with an incremented KRC and valid MIC that the client will accept, thus reinstalling the PTK and resetting the Packet Number (PN) used in the keystream generation for individual frame encryption.

So… patched APs can protect clients from these vulnerabilities if they modify their behavior to not retransmit M3.”

Mocht je een Cisco Wlan-controller en Cisco access-points hebben dan kun je dus een WPA2 vulnerability client workaround  implementeren. Waarschijnlijk zal Cisco binnenkort met een Cisco Product Security Incident Response Team (PSIRT) wijziging komen om onderstaande te adviseren:

UPDATE PSIRT is zojuist vrijgegeven:

Official Workarounds WPA2 Vulnerabilities

  • Workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080 and CVE-2017-13081

Cisco Technotes: Wireless KRACK attack client side workaround and detection (Updated:October 27, 2017 Document ID:212390)

Er zijn twee mogelijkheden :

  • Wijziging van een globale instelling in alle WLAN-releases
  • Wijziging van een SSID instelling vanaf software versie 7.6

#1 Global Config:

config advanced eap eapol-key-retries 0

(CLI only option)

De eopol waarde kan worden gevalideerd met:

(5520) >show advanced eap

EAP-Identity-Request Timeout (seconds)……….. 30

EAP-Identity-Request Max Retries…………….. 2

EAP Key-Index for Dynamic WEP……………….. 0

EAP Max-Login Ignore Identity Response……….. enable

EAP-Request Timeout (seconds)……………….. 30

EAP-Request Max Retries…………………….. 2

EAPOL-Key Timeout (milliseconds)…………….. 1000

EAPOL-Key Max Retries………………………. 0

EAP-Broadcast Key Interval………………….. 3600

Je kan de wijziging per WLAN aanpassen waarmee je een meer granulaire controle toepast. Hierbij kun je een onderscheid maken per SSID. Voordeel hiervan is dat je de verandering goed kan testen per type apparaat, vooral als ze op specifieke wlans zijn gegroepeerd.  Deze work-around is beschikbaar vanaf software versie  7.6

#2 Per WLAN Config:

X=WLAN ID

config wlan security eap-params enable X

config wlan security eap-params eapol-key-retries 0 X

De meeste wlan-clients zullen blijven werken maar er zijn twee scenario’s bekend waardoor er een mogelijkheid bestaat dat (oude) clients problemen gaan ervaren:

  • “Clients which are slow or may drop initial processing of EAPoL M1. This is seen on some small/slow clients, which may receive the M1, and not be ready to process it after the dot1x authentication phase, or do slower
  • Scenarios with bad RF, or WAN connections between AP and WLC, that may cause a packet drop at some point on transmission towards client.

In both, the outcome would be that an EAPoL exchange failure will be reported, and client will be deauthenticated, it will have to restart association/authentication processes

To lower probabilities for this issue, a longer timeout should be used (1000 msec), to give time for slow clients to respond. The default is 1000 msec(!), but could have been set lower by customer on some scenarios.