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.