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.

Advies gebruik van Intel Wireless Adapters, bepalen juiste drivers en protocollen.

Lezers,

Op 16 oktober publiceerden Mathy Vanhoef en Frank Piessens van de Universiteit van Leuven een document waarin een reeks kwetsbaarheden wordt beschreven die de Wi-Fi Protected Access (WPA) en de Wi-Fi Protected Access II (WPA2) protocollen beïnvloeden.

Dit zijn kwetsbaarheden op protocolniveau van draadloze leveranciers en draadloze clients(adapters) die de huidige WPA- en WPA2-specificaties volgen. Deze kwetsbaarheden werden ook aangeduid als “KRACK” (Key Reinstallation AttaCK) en de details werden gepubliceerd op: https://www.krackattacks.com

De meeste wlan client adapters moeten worden geupdate om de ‘supplicant‘ te voorzien van een beveiligings update: Er zijn 10 beveiligingslekken ontdekt waarvan Intel er inmiddels twee heeft geidentificeerd en gerepareerd. De overige lekken moeten in het Operating Systeem(bv Windows) en/of door de draadloze leveranciers gerepareerd worden:

 

 

 

Intel adapter-driver fix : CVE-2017-13081 &  CVE-2017-13080

Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) protocols – integrity group key reinstallation during the group key handshake vulnerability : CVE ID: CVE-2017-13081

A vulnerability in the processing of the 802.11i group key handshake messages of the WPA and WPA2 protocols could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used integrity group key.

The vulnerability is due to ambiguities in the processing of associated protocol messages. An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.

Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access II (WPA2) protocols – group key reinstallation during the group key handshake vulnerability : CVE ID: CVE-2017-13080

A vulnerability in the processing of the 802.11i group key handshake messages of the WPA and WPA2 protocols could allow an unauthenticated, adjacent attacker to force a supplicant to reinstall a previously used group key. 

The vulnerability is due to ambiguities in the processing of associated protocol messages. An attacker could exploit this vulnerability by establishing a man-in-the-middle position between supplicant and authenticator and retransmitting previously used message exchanges between supplicant and authenticator.

Intel heeft voor de volgende Intel Wlan-adapters een update uitgebracht:

  • Intel® Dual Band Wireless-AC 3160
  • Intel® Dual Band Wireless-AC 3165
  • Intel® Dual Band Wireless-AC 3168
  • Intel® Dual Band Wireless-AC 7260
  • Intel® Dual Band Wireless-AC 7265
  • Intel® Dual Band Wireless-AC 8260/8265/9260

PROSet/Wireless Software and Driversversion 20.0.2 for Windows 7, Windows 8.1 and Windows 10:

  • WiFi_20.0.2_PROSet32_Win7.exe (32-bit)
  • WiFi_20.0.2_PROSet64_Win7.exe (64-bit)
  • WiFi_20.0.2_PROSet32_Win8.1.exe (32bit)
  • WiFi_20.0.2_PROSet64_Win8.1.exe (64bit)
  • WiFi_20.0.2_PROSet64_Win10.exe
  • WiFi_20.0.2_PROSet32_Win10.exe

Driver version = 19.10.9.2 for Windows 7 for 18265, 8265, 3168, 18260, 8260, 17265 and 3165.
Driver version = 18.33.9.3 for Windows 7 for 7265, 7260, and 3160

Intel® PROSet/Wireless Software and Drivers for Windows 7

Driver version = 19.10.9.2 for Windows 8.1 for 18265, 8265, 3168, 18260, 8260, 17265, and 3165.
Driver version = 18.33.9.3 for Windows 8.1 for 7265, 7260, and 3160.

Intel® PROSet/Wireless Software and Drivers for Windows 8.1

Driver version = 20.0.2.3 for Windows 10 for 18265, 8265, 18260, 8260.
Driver version = 19.51.7.2 for Windows 10 for 3168, 3165, and 17265.
Driver version = 18.33.9.3 for Windows 10 for 7265, 3160, and 7260.

Intel® PROSet/Wireless Software and Drivers for Windows® 10

Er is ook een ‘driver only’ version beschikbaar :

  • Windows 10 32-bit: WiFi_20.0.2_Driver32_Win10.zip
  • Windows 10 64-bit: WiFi_20.0.2_Driver64_Win10.zip
  • Windows 8.1 32-bit: WiFi_20.0.2_Driver32_Win8.1.zip
  • Windows 8.1 64-bit: WiFi_20.0.2_Driver64_Win8.1.zip
  • Windows 7 32-bit: WiFi_20.0.2_Driver32_Win7.zip
  • Windows 7 64-bit: WiFi_20.0.2_Driver64_Win7.zip

Intel® PROSet/Wireless Software and Drivers for IT Admins

 

Bron INTEL-SA-00101 : https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00101&languageid=en-fr 

Daarnaast is het belangrijk om te weten dat de volgende Intel Wlan Adapters niet meer worden ondersteund. Hier komen dus ook geen beveiligingsupdates meer voor beschikbaar(!):

Product Name Effective Date
Intel® My WiFi Dashboard
August 14, 2017
Intel® Centrino® Advanced-N + WiMAX 6250
September 16, 2016
Intel® Centrino® Wireless-N + WiMAX6150
September 16, 2016
Intel® Centrino® Wireless-N 2200
September 16, 2016
Intel® Centrino® Advanced-N 6230
September 16, 2016
Intel® Centrino® Advanced-N 6200
September 16, 2016
Intel® Centrino® Wireless-N 130
September 16, 2016
Intel® Centrino® Wireless-N 100
September 16, 2016
Intel® Centrino® Wireless-N 1030
September 16, 2016
Intel® Centrino® Wireless-N 1000
September 16, 2016
Intel® WiFi Link 5300
June 1, 2016
Intel® WiFi Link 5100
June 1, 2016
Intel® WiMAX/WiFi Link 5350
June 1, 2016
Intel® WiMAX/WiFi Link 5150
June 1, 2016
Intel® Wireless WiFi Link 4965AGN
December 31, 2013
Intel® Pro/Wireless 3945ABG
December 31, 2013
Intel® Pro/Wireless 2915ABG
December 31, 2009
Intel® Pro/Wireless 2200BG
December 31, 2009

Bron Customer Support Options for Discontinued Intel® Wireless Products : https://www.intel.com/content/www/us/en/support/articles/000006507/network-and-i-o/wireless-networking.html

Windows® 10 ondersteunt industriële standaardprotocollen zoals 802.11r, 802.11k en 802.11v.(Apple ondersteunt ook deze standaarden)

Onderstaande tabel toont de Intel® Wireless Adapters en protocollen.

Product 802.11k 802.11v 802.11r
Intel® Tri-Band Wireless-AC 18265 Yes Yes Yes
Intel® Dual Band Wireless-AC 8265 Yes Yes Yes
Intel® Tri-Band Wireless-AC 18260 Yes Yes Yes
Intel® Tri-Band Wireless-AC 17265 Yes Yes Yes
Intel® Dual Band Wireless-AC 8260 Yes Yes Yes
Intel® Dual Band Wireless-AC 3168 Yes Yes Yes
Intel® Dual Band Wireless-AC 3165 Yes Yes Yes
Intel® Dual Band Wireless-AC 7265 Yes Yes Yes
Intel® Dual Band Wireless-N 7265 Yes Yes Yes
Intel® Wireless-N 7265 Yes Yes Yes
Intel® Dual Band Wireless-AC 3160 No No No
Intel® Dual Band Wireless-AC 7260 No No No
Intel® Dual Band Wireless-N 7260 No No No
Intel® Wireless-N 7260 No No No

Bron Windows® 10 and Supported Intel® Wireless Adapter Protocols : https://www.intel.com/content/www/us/en/support/articles/000021562/network-and-i-o/wireless-networking.html 

#SecureW2 has a Wi-Fi workaround for Windows 10 Creators Update

As Windows 10 Creators Update notices to upgrade are being rolled out to devices please be advised of important changes to supporting these devices.
If you’ve deployed (SecureW2) JoinNow MultiOS to Windows devices by default, Wi-Fi settings are installed onto the device using a user profile vs. a system profile. With Windows 10 Build version and higher the ability to input Wi-Fi settings via a user profile will fail and user specific data is not saved. The Microsoft EAP team is aware of this bug but until a fix is made devices will not connect using user profiles. SecureW2 has made timely changes to detect this issue and configure and connect the device by utilizing a system profile until such time Microsoft can fix the issue.
The drawback of system profiles is that changes to security settings in the profile can be edited by others sharing the device. Since the vast majority of BYOD devices are not shared devices this should not impact most customers. The best practice however is still to utilize user profiles whenever possible.
In order to support Windows 10 Creators Update, it is important that customers republish and update their SecureW2 software to release 5.2.0 GA3 or greater. Please contact the SecureW2 support team if you have further questions or need assistance.
bron : SecureW2

Netwerkbeheerder (1,0 fte) – beheerder van de #UvA #HvA draadloze netwerk infrastructuur.

Power-Spectral-DensityDe Hogeschool van Amsterdam (HvA) is voor ICTS op zoek naar een:

Netwerkbeheerder (1,0 fte)

De functie

Binnen ICT Services (ICTS) ben je verantwoordelijk voor een van de grootste draadloze netwerken van Nederland met 3100 access points verdeeld over 6 controllers.(HA) Het draadloos netwerk bedient op het drukste moment van de dag 32.000 gelijktijdige verbindingen. Je primaire verantwoordelijkheid ligt bij het dagelijks beheer, life cycle en vernieuwing van het draadloos netwerk. Het draadloos netwerk is van een hoog niveau en ICTS streeft ernaar het netwerk up-to-date te houden met de nieuwste technieken.

Buiten het dagelijks beheer ben je verantwoordelijk voor de life cycle/vernieuwing van het draadloos netwerk. We verwachten van jou als netwerkbeheerder dat je op de hoogte bent van nieuwe ontwikkelingen op draadloos gebied. Samen met je collega’s ontwikkel je strategieën voor de implementatie van nieuwe technieken. Nieuwe technieken kunnen in pilotvorm worden uitgewerkt samen met de vendor van de apparatuur waarin jij de lead neemt in de uitwerking van de pilot. Dit houdt in dat je contact onderhoudt met de betrokken partijen en het coördineren van de werkzaamheden die uitgevoerd moeten worden.

Vraagstukken vanuit onderzoek en onderwijs behoren tot de werkzaamheden. Hieronder valt het ondersteunen van evenementen met een draadloos netwerk tot draadloze implementaties voor onderwijstoepassingen. Beveiliging op het draadloos netwerk is onderdeel van het beheer. Beveiligingsmaatregelen vanuit het beveiligingsbeleid en de beveiligingsbaseline vertaal je door naar concrete voorstellen. In overleg met de consultant draadloze netwerken plan je de werkzaamheden en doe je de kwaliteit checks op het geleverde werk.

Naast het beheer van de draadloze netwerk infrastructuur ben je ook verantwoordelijk voor het authenticatie mechanisme (802.1x) met Radius. Hier coördineer je de wijzigingen die gedaan moeten worden en voert deze waar nodig uit in het change window.

Wij zoeken

Je beschikt over een afgeronde relevante hbo-opleiding (informatica, SNE, etc.). Je werkt in een team van 19 medewerkers en bent in staat je collega’s te overtuigen van uitgedachte concepten maar staat ook open voor de mening en inzichten van anderen. Tevens ben je een stevige gesprekspartner voor de organisatie. De aanvragen die vanuit de organisatie komen kun je goed beoordelen en vertalen naar een technische oplossing. Zowel schriftelijk als mondeling ben je in staat duidelijke adviezen te geven over mogelijkheden en onmogelijkheden van een oplossing.

Je kunt je goed verplaatsen in het belang van de organisatie. Door de ervaring die je hebt kan de organisatie je niet meer verrassen met complexe vragen.

De afdeling

Binnen ICTS zijn drie divisies: Vernieuwing, Klant en Beheer. Netwerkbeheer is een van de vijf afdelingen binnen de divisie Beheer en bestaat uit 19 medewerkers. Netwerkbeheer beheert 3 datacenters: (draadloos)netwerk infrastructuur voor +/-70 panden, telefonie(VOIP) en de glasvezelverbindingen tussen de panden en de 4 campussen van de HvA en UvA. Binnen het team Netwerkbeheer zijn verschillende disciplines: Vast netwerkbeheer, Draadloos netwerkbeheer, telecom, 2de- en 3de lijnsupport en consultancy.

Wij bieden

Een tijdelijke aanstelling voor de periode van een jaar met de mogelijkheid tot een vaste aanstelling. De werkzaamheden maken deel uit van de functie Beheerder ICT 2. De bij deze functie behorende loonschaal is 10 (cao hbo). Het salaris bedraagt maximaal € 3.994,- bruto per maand bij een volledige aanstelling en is afhankelijk van opleiding en ervaring.

De HvA heeft een uitgebreid pakket secundaire arbeidsvoorwaarden, waaronder een ruime vakantieregeling en een 13e maand. Daarnaast biedt de HvA (via de HvA Academie) uitstekende studie- en ontwikkelingsmogelijkheden en stimuleert medewerkers om zich blijvend te professionaliseren.

Informatie

Nadere informatie: Richard Smit, Afdelingshoofd Netwerkbeheer, e-mail: r.smit@hva.nl, tel. 06-51299223 (niet gebruiken om te solliciteren).

De sollicitatiegesprekken vinden plaats op de Leeuwenburg, Weesperzijde 190 te Amsterdam.

Kijk bij medewerkers aan het woord hoe onze collega’s denken over werken bij de HvA.

Sollicitaties

Klik op de link onderaan deze vacature om online te solliciteren. Sollicitaties die rechtstreeks naar de contactpersoon of op een andere wijze worden verstuurd, worden niet verwerkt.

Deze vacature is gelijktijdig in- en extern gepubliceerd. Bij gelijke geschiktheid hebben interne kandidaten voorrang op externe kandidaten.

Meer informatie over de sollicitatieprocedure is te vinden op onze website WerkenbijdeHvA.

Bij de werving en selectie ter invulling van deze vacature, houden wij de HvA Sollicitatiecode aan.
Acquisitie naar aanleiding van deze vacature wordt niet op prijs gesteld.

Sluitingsdatum: 26-1-2017

Klik hier om te solliciteren

E-SIM: de grootste telecomrevolutie voor het onderwijs!

Nieuwe embedded SIM (E-SIM)

gsmaEen abonnement op 2G/3G/4G communicatiediensten vereist een SIM in telefoon of tablet. Het uitgeven van zo’n SIM is beperkt tot bedrijven die een publieke ICT-dienst aanbieden. Omdat SURFnet haar diensten aan een gesloten doelgroep aanbiedt, was het moeilijk de vaste dienstverlening uit te breiden met mobiele dienstverlening. Mede vanwege de opmars van het internet-of-things, is de SIM veranderd.

De nieuwe embedded SIM, E-SIM kan worden geïntegreerd in een toestel en op afstand worden overschreven. Dit biedt niet alleen de mogelijkheid 2G/3G/4G diensten aan te bieden maar biedt ook tal van andere kansen.

Wisselen tussen mobiele operators

Verander je van operator (bijv. van KPN naar Vodafone) dan moet er nu een andere SIM in het apparaat worden gestopt. Elk apparaat (telefoon/tablet/slimme meter/navigatie/…) moet daarvoor worden opengemaakt en de SIM van de oude mobiele operator moet worden vervangen voor een SIM van een nieuwe operator. Dit is voor een consument niet zo’n probleem maar een omvangrijke operatie voor een (middel)grote instelling die haar medewerkers mobiele abonnementen verleent.

Het nieuwe E-SIM ontwerp werkt met profielen. Als SURFnet eigenaar zou worden van de SIM en de bijbehorende sleutels kan zij de SIM beheren en op afstand de profielen overschrijven. Het resultaat van de overschrijving is dat de telefoon gebruik maakt van het radionetwerk van een andere mobiele operator.

In de zomer van 2016 hebben we hier mee, samen met Aspider en BTG geëxperimenteerd. Het is gelukt om ‘over-the-air’ een ander profiel op de SIM te plaatsen en te activeren waardoor de eigenaar van het toestel migreerde van de ene Nederlandse mobiele operator naar een andere zonder de SIM te verwisselen. De resultaten beperkte zich tot Android toestellen (Android 5 en hoger) want iphones ondersteunen het ‘bearer independent protocol’ niet en dat is nodig om de SIM veilig te beheren.

Toegang tot eduroam via de SIM

Het primaire doel van de SIM is authenticatie bij een communicatienetwerk. Dit beperkt zich momenteel tot 2G/3G/4G maar dat hoeft niet!  Doordat de SIM communiceert met de authenticatieservers die zijn verbonden met SURFnet, kunnen de encryptiesleutels op de SIM worden gebruikt voor authenticatie tot ieder netwerk, inclusief wifi (eduroam). Dit hebben we getest voor eduroam en werkt prima op zowel Android als iphone toestellen. Het is een kwestie van op het toestel EAP-SIM als authenticatiemethode te selecteren en het toestel komt online. Technisch werkt dit omdat de telecomindustrie hiervoor regels heeft ontworpen die goed aansluiten bij eduroam. Bij EAP-SIM ziet een network identifier er als volgt uit:

IMSI@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Op onze ‘core eduroam proxies’ komen er dagelijks zo’n 15000 van dit soort verzoeken binnen. Die negeren we momenteel maar voor de SIMs in onze pilot sturen we ze middels RADIUS door naar dezelfde database als die ebruikt wordt voor het verkrijgen van toegang tot 2G/3G/4G netwerken. De encryptiesleutels op de SIM worden vergeleken met de afgeleide sleutels in die database. Net als nu gebeurt in de RADIUS-server van een instelling als iemand ergens op bezoek is waar eduroam wordt aangeboden. Het voordeel van de SIM als authenticatiemethode is dat de sleutels op de SIM veel veiliger zijn dan een combinatie username/password waardoor password retentie niet nodig is.  Daarbij ontlast het de RADIUS servers van de instellingen.

Nadeel is dat de verzoeken naar een externe server worden gestuurd waar we de beschikbaarheid niet van weten. Daarom willen we een special eduroamprofiel op de SIM maken dat door een RADIUS server binnen SURFnet kan worden geverifieerd en los staat van de mobiele operator die 2G/3G/4G aanbiedt.

Vervolgstappen

Deze pilot was een eerste stap om de mogelijkheden van een eigen ‘SURFsim’ te verkennen. De evaluatie van het wisselen tussen operators toont dat het technisch kan maar toont ook dat het soms mis gaat. We willen inzicht waarom het mis gaat (timing, communicatie, invloed operating system/toestel??). Verder zien we nog veel meer kansen die eigenaarschap van een eigen SIM bieden: bijv. ‘two factor’-authenticatie, eigen certificaat in een secure element op de SIM, indoor communicatie, etc. We gaan die kansen samen met enkele instellingen verder uitdiepen.

Meer informatie

Bron : Innovatieblog – Mobiel en draadvrij : SURFnet, Frans Panken

UvA Wi-Fi netwerkroaming met 802.11k, 802.11r en 802.11v in iOS

ieee802_11_logoiOS biedt nu ook ondersteuning voor optimale clientroaming in wifi-netwerken van Universiteiten. Met de 802.11 Working Group-standaarden k, r en v kunnen clients nog soepeler roamen tussen toegangspunten binnen hetzelfde netwerk.De UvA ondersteunt op dit moment 802.11k, 802.11r en 802.11v alleen op het SSID ‘uva’. Zodra adaptive 802.11r stabiel en betrouwbaar is zullen we de genoemde standaarden ook op het SSID ‘eduroam’ aanbieden.

802.11k

Door het gebruik van de 802.11k-standaard kan iOS sneller toegangspunten in de buurt vinden die beschikbaar zijn als roamingdoel door een geoptimaliseerde lijst van kanalen aan te leggen. Als het signaal van het huidige toegangspunt zwakker wordt, zoekt uw apparaat naar doel-toegangspunten uit die lijst.

802.11r

Wanneer een iOS-apparaat roamt van het ene naar het andere toegangspunt binnen hetzelfde netwerk, gebruikt 802.11r de functie Fast Basic Service Set Transition (FT) om de identiteitscontrole sneller uit te voeren. FT werkt met zowel een vooraf gedeelde sleutel (PSK) als een 802.1X-identiteitscontrole.

iOS 10 ondersteunt adaptive 802.11r op draadloze Cisco-netwerken. Adaptive 802.11r maakt FT mogelijk zonder dat daarvoor 802.11r ingeschakeld hoeft te zijn op het geconfigureerde draadloze Cisco-netwerk.

De UvA ondersteunt op dit moment nog geen adaptive 802.11r

802.11v

iOS ondersteunt het BSS-transitiebeheer (Basic Service Set) van 802.11v op bepaalde apparaten. Met BSS-transitiebeheer kan de controlelaag van het netwerk de clientroaming sturen door informatie door te geven over hoe zwaar de toegangspunten in de buurt worden belast. iOS houdt rekening met deze informatie wanneer tussen de mogelijke roamingdoelen wordt gekozen.

De combinatie van snellere identificatie van het beste doel-toegangspunt door 802.11k en 802.11v en de snellere koppelingsmethode voor toegangspunten van FT zorgt voor beter presterende apps en een betere wifi-ervaring in iOS.

Meer informatie

…In de lijsten hieronder ziet u welke iOS-apparaten ondersteuning bieden voor 802.11k, 802.11r en 802.11v. Voor 802.11k en 802.11r hebt u iOS 6 of hoger nodig. Voor 802.11v hebt u iOS 7 of hoger nodig. Voor adaptive 802.11r hebt u iOS 10 of hoger nodig.

802.11k en r

  • iPhone 4s en nieuwer
  • iPad Pro
  • iPad Air en nieuwer
  • iPad mini en nieuwer
  • iPad (3e generatie) en nieuwer
  • iPod touch (5e generatie) en nieuwer

Adaptive 802.11r

  • iPhone 6s en nieuwer
  • iPad Pro en nieuwer
  • iPad mini (4e generatie) en nieuwer

802.11v

  • iPhone 5c, iPhone 5s en nieuwer
  • iPad Pro
  • iPad Air en nieuwer
  • iPad mini 2 en nieuwer
  • iPod touch (6e generatie)
…..Meer informatie over roamen met iOS 8 of hoger. Meer informatie over deze standaarden vindt u op de IEEE-website:

Bron : https://support.apple.com/nl-nl/HT202628