Saturday, December 19, 2015

State wise Public Wi-Fi Deployments in India

Commercial Wi-Fi
  • UP
    • Agra: TajMahal covered by BSNL & Quadgen (source)
    • Varanasi Ghats by BSNL & Quadgen (source)
  • Gujarat
    • Ahmedabad
  • Maharashtra
    • Mumbai
  • Karnataka
    • Bangalore
  • Hyderabad
  • Telgana
    • Hyderabad
      • BSNL & US based Quadgen Wireless Solutions (source)
      • Airtel

Free (Non Commercial) Wi-Fi
  • BSNL 100 hotspots (from Quadgen) funded by facebook (source).
  • Internet.org by facebook.
  • Free Wfi @ 400 Railway stations by Google.

Note: 
  • BSNL to setup 40,000 Wi-Fi hotspots pan-India in 3 years (source)
    • Selected QuadGen Wireless for Southern & Western States;-
      • Telangana, Andhra Pradesh, Kerala, Karnataka, Tamil Nadu
      • Maharashtra, Gujarat, Madhya Pradesh and Chattisgarh
    • Selected Trimax IT Infrastructure & Services for Northern states (source)
      • Jammu & Kashmir, Himachal Pradesh, 
      • Punjab, Rajasthan, Delhi, Haryana, Uttar Pradesh, Uttarakhand and Chandigarh

Tuesday, December 15, 2015

RF Fundamentals

Adjacent Channel Interference vs Co-Channel Congestion

  • In WLAN industry, an adjacent channel is considered to be the next or previous numbered channel. Devices in adjacent channels will corrupt each other packets hence, adjacent channel interference is dangerous.
  • When all devices are in same channel then each device will cooperate using CSMA/CA. This can create congestion but devices will not corrupt each others packet hence, it is much better than adjacent channel interference.

Side Band Emissions

Guard Band

Active Gain vs Passive Gain

  • Amplifiers provide active gain
  • Antennas provide passive gain and is achieved by focusing the RF signal in specific direction.

Free Space Path Loss: 
  • Loss of signal strength (due to broadening of wave) as the signal moves away from the source.
  • It is logarithmic and not linear. Thus loss is lesser as we move away from the source.
  • It depends on "Frequency of operation" & "Distance". Higher the frequency, bigger is the loss. Hence, 5 GHz signal decays faster than 2.4 GHz. 
  • 6 dB rule: Doubling the distance will result in a loss of amplitude of 6dB.
  • For 2.4 GHz signal, this loss is nearly 80 dB at 100 meters (87 dB for 5.8 GHz). For next 100 meters, additional loss will be 6 dB. Hence, if the radiated power is 30 dBm (1W), then received signal at 100 meters will be -50 dBm (10 nW). Therefore, in 100 metres, the RF signal loses  99.9999% of the power.
  • Calculator: http://www.changpuak.ch/electronics/calc_10.php 

Absorption:
  • Loss of signal strength due to the absorption by the propagation medium.
  • It depends on type of medium and length of medium. E.g. 
    • Water bodies absorb a large amount of signal. However, rain, snow, and fog attenuation are very small for frequencies under 10 GHz. Moisture in the propagation medium will increase this loss.
    • Human body which has large water content also absorbs (3 dB for 2.4 GHz and 5 dB for 5.8 GHz). Hence, due to large number of people around (e.g full stadium vs empty stadiums) there will be good amount of absorption.
    • Material of wall (wooden or concrete) will also impact it. 
    • Thickness of wall will directly impact the loss due to absorption.




Receive Sensitivity
  • Indicates the weakest signal the receiver can reliably decode.
  • It depends on modulation and bit rate.

Link Budget Analysis

  • Radiated Power (EIRP) = Radio Transmit Power (dBm) – Cable/Connector/Switch Loss (dB) at Transmitter + Transmit Antenna Gain (dBi)
  • Received Power = Radiated Power/EIRP – Path Loss (free space + absorption + others) + Receiver Gain
  • Receiver Gain = Receive Antenna Gain (dBi) - Cable/Connector/Switch Loss (dB) at Receiver
  • Link Budget = Received Power – Receive Sensitivity
  • Note: Design should take care that link budget for highest bit rate (desired) is at least 0 dB. Leaving a margin of 10 dB for variations is a good practice.
Reflection
  • Every smooth surface reflects some part of the signal falling on it. 
  • Anything made of metal will absolutely cause reflection.
  • Glass is a highly reflective material.
  • Reflection & Multi-path plays a negative role in 802.11 a/b/g radios however, they are constructively used in MIMO.

Scattering
  • When wave strikes an uneven surface (such as tree foliage, rocky terrain) it gets scattered in multiple directions. 
  • It can cause substantial signal downgrade. 

Refraction
  • Change of wave direction when passing through a medium
  • RF refraction mainly occurs as a result of atmospheric conditions (such as water vapors, changes in air temperature & changes in air pressure).
  • Only in long distance outdoor wireless bridge deployments, refraction can be an issue.
Diffraction
  • Diffraction is mainly caused by partial blockage of the RF signal.
  • Wave that encounters the obstruction bend around the object.
  • Analogy: Rock sitting in the middle of the river. 

Friday, December 4, 2015

Ruckus Portfolio

  • Access Points
    • Zoneflex Indoor
    • Zoneflex Outdoor
  • Management Platforms
    • Linux based NMS Solution: 
      • FlexMaster
      • SNMP, TR069, SOAP, HTTP/S based
  • Controllers
    • Access Points with in built controller (upto 25 devices)
      • Ruckus Unleashed
        • R500 Unleashed ($645)
        • R600 Unleashed ($795)
    • In Band Controllers (based on Ruckus Hardware)
      • ZoneDirectors
    • Cloud based WLAN Controller:
      • Virtual SmartZone Platform (mainly for SME market)
      • Runs on Virtualized and Cloud environments such as open source KVM or VMware hyper-visor



  • External Antennas


Saturday, November 28, 2015

Wireless Display Standards

  • Airplay (by Apple)


  • WiDi (by Intel)

  • DLNA [Digital Living Network Alliance]

Source:
http://www.howtogeek.com/177145/wireless-display-standards-explained-airplay-miracast-widi-chromecast-and-dlna/

Friday, November 27, 2015

Important Concepts around Authentication

Multi-Factor Authentication

Systems with higher level of authentication needs multiple credentials to be presented for user validation. Such process of authentication is referred to as multi-factor authentication. Each one of the supplied credential can fall in one of the three categories:

  • Something you know (e.g passwords, pin)
  • Something you are (e.g Bio-metrics such as finger prints, picture, retina)
  • Something you have (e.g. Security token, Mobile number for OTP, Debit Card)
When only two credentials (each from different category) are provided then it is referred to as two-factor authentication.

Different Supplicants

  • One which comes integrated with OS - Works with most hardware
    • Windows XP Wireless Zero Configuration (WZC)
    • Windows 7 Supplicant
    • Apple's Airport Client
  • Chipset Vendor Supplicant
    • Atheros
    • Broadcom
    • Intel's PROSet Client
  • WLAN vendor Supplicant: Works only with vendor radios.
    • Ones which are provided by Netgear, DLink etc
  • Third Party Supplicant - works with different chipsets & OS
    • Commercial Supplicants: 
      • Juniper Networks's OAC
      • Cisco's SSC

Different Authentication Servers

  • Cisco ACS [RADIUS based]
  • Juniper Steel Belted RADIUS  [RADIUS based]
  • Microsoft IAS (Windows Server 2003)  [RADIUS based]
  • Microsoft NAP (Windows Server 2008)  [RADIUS based]
  • Microsoft Active Directory 2003 and higher  [Kerberos and LDAP]
  • FreeRADIUS (open source)  [RADIUS based]


Configuring RADIUS and Access Points

  • Authenticator needs to know RADIUS server's IP address & UDP port along with a shared secret (required to validate & encrypt the communication link between authenticator and authentication server)
  • Normally, authenticator is provided with a prioritized list of authentication servers. Usually, up to three RADIUS servers are configured for redundancy purpose.
  • Authentication server needs to know the authenticator's IP address and shared secret in order to communicate with the authenticator.
  • RADIUS uses UDP port 1812 for authentication and 1813 for accounting. Prior to this official assignment by IANA 1645 & 1646 respectively were used by most vendors.

RADIUS assigned VLAN

Helps to assign VLAN to different users hence, no need to have separate SSIDs for segregation of different users.

RADIUS based MAC ACL

Here both username and password can be filled with MAC address

Realm & NAS Identifier

Username & password can be accompanied by a domain name or realm that might tell the RADIUS server which master database to use.

Options while using Digital Certificates

  • Public Key Infrastructure [PKI]
  • Private PKI
    • You maintain your private PKI
  • Self Signed Certificates
    • Server certificate needs to be deployed to each client
    • Recommended, if distributing server certificate is not a problem then self signed certificates is the best option.

Note: List of "trusted root authorities" s sometimes referred to as a "Certified Trust List". Verisign is one of the trusted root authority.

User Database: Windows Active Directory & LDAP Server





Thursday, November 26, 2015

Authentication Methods for WiFi Networks - Part 2

Strong EAP Methods
  • Non Tunneled Methods
    • EAP-TLS
      • Needs certificate on both Server and Client side. Due to client side certificate requirement it is costly to implement.
      • Needs public key infrastructure(PKI).
      • Normally, it does not create tunnel to pass the client certificate to the server as tunnel is not required for passing the client certificate. However in privacy mode, a tunnel is created.
  • Tunneled Methods: In these methods, a TLS tunnel is established between authentication server and supplicant using server certificate. The purpose of establishing a tunnel is to protect the information provided by the supplicants. 
    • EAP-TTLS (defined in RFC 5281)
    • EAP-PEAPv0 (outer authentication) / EAP-MSCHAPv2 (inner authentication): Microsoft
    • EAP- PEAPv0 (outer authentication) / EAP-TLS (inner authentication): Microsoft
    • EAP-PEAPv1 (outer authentication) / EAP-GTC (inner authentication): Cisco
    • EAP-FAST: Cisco
      • Provides for mutual & tunneled authentication.
      • Instead of using standards based X.509 digital certificates, it uses Protected Access Credentials (PACs).
      • PACs can be automatically provisioned on the clients by the server or can be manually configured by the administrator.
      • PACs contain symmetric keys. Hence, EAP-FAST has advantage of performance when compared to methods using asymmetric keys.
      • In May 2009, Wi-Fi added EAP-FAST to the WPA2 interoperability certification.
Note:
  • These methods supports mutual authentication. i.e. both authentication server and supplicant are validated. 
  • In tunneled methods, supplicant has two identities (outer and inner). The outer identity is effectively a bogus user name and inner one is the true identity. The outer identity is seen is clear text as it is prior to setting encrypted tunnel however, inner identity is sent within the tunnel. 
  • EAP-PEAPv0 / EAP-MSCHAPv2 is most popular among tunneled methods as Microsoft was the dominant player in both server and client operating system.
  • EAP-PEAP cam after EAP-TTLS but size of Microsoft & Cisco enables it to surpass TTLS.
  • PEAP is often referred as "EAP inside EAP"
  • Microsoft OS does not provide support for EAP-PEAPv1. 
  • EAP-TTLS supports just about anything for inner authentication whereas EAP-PEAP is very selective. Methods such as legacy methods PAP, CHAP, MS-CHAP and MS-CHAPv2 and also the EAP-Protocols e.g. EAP-MSCHAPv2 are supported are supported in EAP-TTLS. But support of EAP-TTLS is much smaller than EAP-PEAP.


EAP-PEAPv0/EAP-MSCHAPv2:


Miscellaneous:
  • EAP-SIM
    • Designed for 2G (GSM) networks.
    • It does not offer mutual authentication.
  • EAP-AKA
    • Designed for 3G (UMTS & CDMA2000) networks.
    • Supports mutual authentication.

  • EAP-TLS vs TLS
    • TLS (SSL3.0) secure communication at the transport layer of the OSI model however, EAP-TLS works at L2 layer.

Saturday, November 21, 2015

Authentication Methods for WiFi Networks - Part 1

Legacy Authentication Methods (developed for use with PPP)
  • PAP
    • Provides no protection to user identity.
  • CHAP
    • Slightly more evolved than PAP
    • Password is encrypted with an MD5 hash.
  • MS-CHAPv1
    • Microsoft version of CHAP and later defined in RFC
    • Password is encrypted with an MD5 hash.
  • MS-CHAPv2
    • Uses much stronger hashing algorithm in place of MD5. However, this hashing algorithm has also found to be vulnerable. Using offline dictionary attacks password can be obtained.
    • Supports additionally mutual authentication

Note
  • Password encrypted using MD5 hash can be easily recovered as MD5 is highly susceptible to offline dictionary attacks.
  • Mutual authentication is needed to create dynamic encryption keys.


EAP Methods for Inner Authentication (should be used after establishing a tunnel): 

  • EAP-MD5
    • Offers only One-Way authentication (only client is validated). Since 
    • Mutual authentication is needed to create dynamic encryption keys hence after authentication, messages are not encrypted.
    • Username in clear text: If identity is known, hacker can try to get the password using social engineering techniques.
    • Weak MD5 hash of the password.
  • EAP-OTP
    • Similar to EAP-MD5, except it uses OTP as the response.
  • EAP-GTC
    • Similar to EAP-OTP, except with hardware tokens are used to generate OTP.
  • EAP-MSCHAPv2: Technically same as EAP-MSCHAPv2 but different nomenclature.




Note:
  • Inner authentication (each relevant for specific user credential) should be used only with outer authentication method otherwise insecure.
  • About EAP-LEAP:
    • EAP-LEAP is largely similar to EAP-MSCHAPv2. Hence, suffer from same weaknesses. This method should never be used.
    • EAP-LEAP is not a tunneled authentication method.
    • EAP-LEAP is not an open standard and must be licensed from Cisco.

Thursday, November 12, 2015

PMK Caching & Preauthentication

There are two old (but standard) methods of roaming as described in 802.11i. These are:
  • PMK Caching
  • Pre-authentication
PMK Caching (done only when security is 802.1x /WPA2-Enterprise)
  • This method is also called PMKID Caching or PMKSA Caching or Sticky Key Caching
  • In this method, PMKSA is cached by the AP and by the client. One should note that PMKSA is specific to a combination of AP and client. Hence, each AP will have separate PMKSA cached for each client (same is true for client). This demands for high memory at AP and client and hence a bottleneck for scalable roaming.
  • When a client needs to move to new AP, it first checks its cache for PMKSA for that AP. In case, the cache has PMKSA for that AP it will send re-association request to that AP with PMKID included in RSN information element. However, if there is no matching entry in the cache it will go for either full authentication or pre-authentication if it is enabled.
  • The other issue is that client needs to get authenticated with all access points before it has PMKSA cached for them.
Note: Client provides PMKID only when moving in same ESS i.e. from one BSSID to another inside same ESS. When moving to different ESS (different SSID) it does not include PMKID.

Pre-authentication
  • This method sits on top of PMK caching. i.e. PMKSA caching is enabled.
  • When a client decided to move to new AP and does not have PMKSA cached then its starts pre-authentication with new access point with out breaking association with current access point. In case both AP and client supports OKC then client should calculate PMKID for the new AP (even if was not authenticated with this AP) and send it using RSN IE.  
  • Pre-authentication starts with EAPOL-Start frame to current AP. However, pre-authentication frames have ether type (88-C7) as opposed on standard EAPOL frames (ether type is 88-8E).
  • Pre-authentication frame fields look like:
    • DA: BSSID of target AP
    • BSSID: BSSID of current AP
    • SA: Client source address.
  • Pre-authentication frames are destined to target AP but sent through current AP.
  • Using pre-authentication, client authenticates with target AP. Traget AP then caches PMKSA for this client. 
  • After pre-authentication stage is complete, the client directly send association request (authentication frames are skipped) with PMKID just established. This way the costly authentication process with new AP is complete with breaking existing data connection with current AP.
  • Pre-authentication is indicated by access point by RSN Capabilities in RSN IE.
  • Windows 7 Client supports pre-authentication
Both these methods needs authentication with RADIUS whenever a client moves to new AP which increase load on RADIUS server. Hence, both these methods are not scalable.

Fast BSS Transition (FT) or 802.11r

FT or 802.11r is first WiFi standard which offers standardized & scalable WFi roaming solution. Prior to this Pre-authentication & PMKSA caching (recommended in 802.11i) were based on PMKSA caching rather PMK due to which these methods were not scalable. Another roaming method OKC is scalable as it is based on PMK caching however, OKC is not a standard roaming method. 

Refer to this post for some basics on roaming.


Key Hierarchy:

Even though, FT can be used for Controller-less deployments but it was designed by keeping controller and thin APs architecture in mind. In this architecture, instead of access points, controller act as authenticator and is responsible for keys derivation and distribution to access points. 

In this architecture:


  • Controller is identified by PMKR0KH-ID acts as PMKR0-Key Holder.
  • Access Point is identified by PMKR1KH-ID acts as PMKR1-Key Holder.
  • PMKR0 is identified by its name PMKR0Name. (same as PMKR0ID)
  • PMKR1 is identified by its name PMKR1Name. (same as PMKR1ID)
  • PMKR0 is derived by controller from MSK/PMK using PMKR0KH-ID as input. Hence, PMKR0 is dependent on controller identifier.
  • PMKR1 is derived by controller from PMKR0 using PMKR1KH-ID as input and is responsible for distributing these keys to access points. Hence, PMKR1 can be different for each access point if all access points are configured with different identifier. It is possible to configure each AP with same identifier.


Information Elements [IEs] Changes

  • RSNIE (updated):
    • Holds PMKRxName (PMKRxID to be more precise)
    • AKM suite is updated to include FT.
  • MDIE  (new): Mainly holds Mobility Domain identifier & whether Over-the-DS mode is supported. As it holds mobility domain identifier, it is present in all frames related to 802.11r. However, its presence inside Beacons, Probe Response (from AP) & Association request (from stations) indicates 802.11r support on AP & station respectively. 




  • FTIE (new): This IE holds PMKR0KH-ID, PMKR1KH-ID (always) & additionally PTK Key derivation material such as ANounce, SNounce, MIC & GTK) (in re-association request & response frames).


Important Points: 
  • Over-the-air mode is mandatory but over-the-ds mode is optional. If access point supports both modes then client will attempt over-the-ds mode.
  • When FT is enabled, some non FT stations (which cannot decode updated RSNIE) might not be able to connect.
  • FT is even faster than PSK roaming because 4-Way handshake is eliminated.
  • 4-Way handshake is modified as now key data includes FTIE, RSNIE & MDIE.






Frame Exchanges:

  • Initial Mobility Domain Association:

In controller less environment or when PSK is used then its the responsibility of the initial AP to derives PMKR1-key for other key holders (access points in same mobility domain) and pass message to them so that other APs can build their PMKR1Key cache.
  • Over the Air Transition:



  • Over the DS Transition:

UPDATE:
Why over-the-ds mode can be better when both access points are on different channels? (source)

Over the DS vs Over the Air:
Negotiation with the next AP can happen over the air, or over the DS. With "over the air", the client gets to the edge of the first cell, scans, finds another AP, and negotiates directly with this next AP the next key (and possibly QoS parameters). The advantage of this method is that communication is direct (no delay by going through the DS, not need for AP to AP wired communication protocol). The downside is that the client needs to leave its active channel to negotiate on another channel. Most BYODs send a frame to their current AP, telling them that they "go to sleep" (Null frame with Power Management set to 1, while in fact they go negotiate on another channel), then return to the active channel to "empty their and the AP buffer" (Null frame with Power management set to 0) before jumping out to the next AP.
The over the air process is direct, but may be disrupting in a location where the device is already at the edge of the cell (low data rate, lots of retries). To avoid that the negotiation also forces the device to go off channel for a while, the Over the DS method can be enabled. In this case, the device stays on the current channel (no need to pretend to sleep and leave the channel), and asks the current AP to negotiate with the next AP (your client still has to discover the next AP first, i.e. scan). This process saves time and increases efficiency, provided that both APs have a way to communicate. In a controller-based network, no problem. The unknown is in the efficiency (what is faster: direct negotiation, or going through the current AP, the WLC, then the next AP, with all the switches or routers that may be on the way?). The only answer is to test (or know your network, if APs are on the same switch and the WLC is close, DS is great. Add routers and switches, and the needle switches toward Over the air).



Monday, November 9, 2015

Fast Secure Roaming (Mobility) in WiFi (802.11) Networks

Its wonderful to have voice calls over WiFi Network as it saves a lot of cost (especially for long distance calls). However, there are two big requirements for having good quality voice calls on WiFi network and these are covered under following WiFi alliance certifications:

  • Voice Personal: Relates with QoS requirements for voice on single access point so as voice can have low latency and low jitter.
  • Voice Enterprise: Relates to voice performance on multiple access points especially station movement from one access point to another. 

Key Terms:
  • BSS Transition: Movement of client from one BSS to another under the same ESS. Each BSS can be under same or different sub-net.
  • Mobility Domain: Group of access points across which a station can quickly roam. These access points can be under same or different sub-net.
  • Layer 2 Roaming: When a client moves from one BSS to another (with in the same sub-net).
  • Layer 3 [IP] Roaming: When a client moves from one BSS to another (each in different sub-net). Moving from one sub-net to another normally involves IP change. Hence, layer 3 roaming is trickier than layer 2 roaming. Vendors either implement proprietary tunneling methods or Mobile IP to preserve the IP.
  • Inter AP handover: Roaming often involves data exchange from one access point to another. However, communication between different access points is not defined in 802.11 standard. Vendors are free to implement their own mechanisms. 
    • For layer 2 roaming, this can be simple broadcast message or a layer 2 uni-cast packet.
    • For layer 3 roaming, it has to a uni-cast message from one access point to another.
    • Mobility Domain is the group of access points which knows the IP (or MAC or both) of other access points in that group.
    • Inter access point communication should be secure.


Roaming Objective:
When a VoIP phone moves from one access point during a call there is layer 2 connectivity transfer which leads to frame loss depending on time it takes for connectivity transfer. Large time can lead to call drop. In order to avoid call drop, connectivity transfer (roaming) time should be less than 50 msecs. However, when WPA2-enterprise level security is used then it generally takes 700 msecs for the station to authenticate and connect (that too when authentication server is on LAN). To overcome this large roaming time while using robust security mechanisms becomes the objective of roaming techniques. 

Roaming Techniques:

PMK vs PMKSA vs PMKID
  • PMK: Refer to this post to check how PMK is generated. 
  • PMKSA: Componenets of PMKSA includes the following:
    • PMK
    • PMKID
    • Authenticator MAC: This makes PMKSA specific to a given AP.  Hence, PMKSA cached at one AP cannot be used by other AP.
    • Lifetime
    • AKMP: Authentication & Key management protocol
    • Authorization Parameters: Any parameters specified by the authorization server.
  • PMKID: Each PMKSA has one ID which is used in Re-association request. 

Important Points:

In future posts, we will discuss some more details about specific roaming techniques.

Thursday, November 5, 2015

Extensible Authentication Framework (EAP) for accommodating different Authentication Protocols

Clients can authenticate themselves based on different type of credentials, such as:
  • Username & password
  • Digital Certificate
  • SIM
  • Pre-shared keys (PSK)
  • Bio-metrics
  • Smart Card
  • RFID tags
  • Dynamic security token devices
  • OTP
  • Protected Access Credential (PACs)


Each different credential demands different "Authentication Protocol" (we will defer information about which credential needs which protocol to another post). Hence, to accommodate different authentication protocols an authentication framework was required which can accomodate all present and future authentication protocols. EAP was answer to that question for PPP links. EAP was later extended to authentication in WiFi. 


EAP:





EAPOL

  • EAP was designed for PPP protocol (where PPP provides information aboutdestination and source). Hence, EAP inherently does not have any such information.
  • EAPOL adds source and destination MAC information to EAP frame. 








  • Packet Type: A new field added by EAPOL. Possible values: 
    • EAPOL Packet[0]: Contains an encapsulated EAP frame (the original frame shown above).
    • EAPOL Start[1]: Instead of waiting for a challenge from the authenticator, the supplicant can issue an EAPOL-Start frame. In response, the authenticator sends an EAP-Request/Identity frame.
    • EAPOL Logoff [2]: When a system is done using the network, it can issue an EAPOL-Logoff frame to return the port to an unauthorized state.
    • EAPOL Key[3]: EAPOL can be used to exchange cryptographic keying information. All EAPOL frames exchanged during 4 Way key handshake are EAPOL-Key frame which has the following structure. 








  • EAPOL is limited to L2 network (only MAC addresses) by design as supplicant does not have any IP address before authentication.To talk to authentication server, authenticator needs to have L3 protocol. This protocol can be RADIUS or Diameter. 




RADIUS: 


  • RADIUS is based on UDP and the communication between RADIUS server and client is secured. Frames exchanged between RADIUS server and client along with their direction are:






  • Generic EAP exchange looks like: 





  • RADIUS server checks IP address of RADIUS client and validates shared secret before answering. i.e Data sent by client is encrypted using shared secret. For this to work, server should have mapping between ip address of client and shared secret.
  • Realm: Its define the user account location. Check here
  • RADIUS message contains a set of RADIUS defined attributes (IETF defined and proprietary). Hence, message sent by supplicant needs to fill these attributes. 
  • Supplicant has an identity and some credentials (password, certificate etc) to prove that is is who it claims to be.
  • In the IETF world, authenticator is referred to as Network Access Server (NAS) or RADIUS Client.

Thursday, October 29, 2015

802.11w

802.11w, also termed as Protected Management Frames (PMF) Service, defines encryption for management frames. Unencrypted management frames makes wireless connection vulnerable to DoS Attacks as well as they cannot protect important information exchanged using management frames from eavesdroppers.
For encrypting unicast management frames, AES-CCM encryption protocol is used and the same PTK which is derived during 4 Way Key handshake is used. However, broadcast/multicast management frames uses BIP encryption protocol which uses CMAC instead of CBC-MAC (used by AES-CCM) for computing MIC. For encryption, BIP uses IGTK which is generated similar to GTK and passed to stations during 4 Way Key handshake & Group key handshake. Since, PTK & GTK are not available before 4 Way Key handshake hence all management frames before this handshake (beacons, probe request/response, association request/response, and authentication frame) remain unencrypted. Moreover, PMF can be supported in either WPA2-Personal or Enterprise but not with open security model as there is no encryption in it.
DoS Attacks
Following frames can break the existing wireless connection (without PMF support) and will lead to Denial of Service attack.
  1. Sending Deauth or Disassoc notification to AP
  2. Sending (Re) Association request to AP.
  3. Sending Auth frame to AP.
  4. Sending Deauth or Disassoc notification to Station
  5. Sending Channel switch announcement to Station.
All these attacks can be prevented using protected management frames. Just to reiterate, (Re) Association request & Auth frame remain unprotected in PMF.
PMF Support Indication:
RSN Capabilities field inside RSN IE of the Beacon & Probe Response frames (from AP) & (Re) Association request (from station) indicates whether PMF is Unsupported, Optional or Mandatory.
Other changes in frame structure include new “Group Management Cipher Suite” for BIP protocol inside RSN IE & introduction of MIC IE. Please refer to other sources for detailed changes in the frame structures.
Prevention of Denial of Service Attacks
  • Sending spoofed Deauth or Disassoc frames to AP
As Deauth & Disassoc are protected under PMF, any such spoofed frames will be simply ignored by the AP.
  • Sending spoofed  Auth or (Re) Association frames to AP
AP cannot simply reject these frames from the connected clients as clients on sudden reboot can send new association request. To handle such cases, AP temporarily rejects the association request by requesting station to comeback after certain time (association-comeback time) and triggers SA Query mechanism with the client. In case of client reboot, the client would not respond to SA query (which is also protected) whereas in case of Spoofed Auth or (Re) Association request client will respond to SA query. Based on the result of query mechanism, AP can allow the next Association request from the client.
  • Sending spoofed Deauth or Disassoc frames to Station
Station cannot simply reject as theses frames can be sent by AP if AP has sudden rebooted and is not aware about the old association with the client. In this case, station triggers SA Query mechanism with the AP and based on its result it figures out whether new association with that AP is required or is it simply the case of spoofed Deauth or Disassoc frame.

Clients supporting PMF
Moto X, Samsung Galaxy Note 4 are some of the mobiles supporting 11w.
Generating Attacks:

Friday, September 11, 2015

Channel Acquisition & Transmit Opportunity [TXOP]

Channel Acquisition:
  • DCF: Legacy Data Access
  • EDCA: QoS Data Access

where AIFS[AC] = SIFS + AIFSN[AC] * Slot time



Scenario:
Lets say, a node has packets to transmit in all of the four access categories then four different instances of EDCA access function will be competing. If two (or more) instances of the EDCA access function gains access simultaneously then internal collision is resolved by the highest priority gaining the access of the medium and other AC behaving as if external collision occurred by doubling its contention window.

Points to Note:

  • DIFS = SIFS + 2*slot time
  • Every access category waits different amount of time for which channel is free before kicking of back off timer. Voice, Video & legacy clients waits for DIFS while BE & BK waits for more time (SIFS + 3*slot time & SIFS + 7*slot time respectively).
  • Working of back off timer: 
    • After picking a random slot count from contention window the timer checks every slot time (9us) for the channel to be free. If it is free then the slot count decrements otherwise (if busy) the backoff timer freezes. To unfreeze the timer, the channel needs to be free for AIFS( for that given access category). After unfreeze, the counter resumes. Once counter reaches zero, the medium can be acquired.
  • Next Step after channel acquisition: 
    • TXOP begins with a short frame exchange which could be RTS/CTS or Data/ACK. (refer here)
    • Send RTS/CTS frame declaring the duration [usec] for which the node will be acquiring the channel. Sending RTS/CTS step is very important step.
    • In Block ACK sessions, presence of RTS/CTS indicates channel acquisition by the node.
    • Duration is a 16 bit field but for duration only 15 bits are used which means channel can be acquired for max 32 msec. Noticed, 27 msec time in RTS frame in Block ACK session even for normal/BE packets.

Transmit Opportunity [TXOP]:
Its a duration during which a node has full channel access for sending and receiving frames of a particular TID after acquiring the channel. It means the node can send multiple packets after SIFS gap and all it needs is acquiring channel only once.  A TXOP of zero means that node can send one Management packet or MSDU after acquiring channel. 

Without Aggregation, it promotes resource fairness as it allow BE/BK traffic to send at least one packet while keeping other time for video & voice. If you think through then you will realize if the client with BE/BK traffic is having low data rates then sending one such packet will consume more time than TXOP recommended for video & voice but that is understandable as nodes with BE/BK traffic are sending just one packet.

However, this concept is seriously flawed when applied with AMPDU. Since, every node can send one AMPDU after channel acquisition but number of MPDUs in an AMPDU can be 64 for the BE/BK traffic (which can take upto 27msec time to go out). This will be lethal for voice and video if constrained to use TXOP of 1.5 / 3 msec respectively. (backing).