802.11 WLAN A by linxiaoqin

VIEWS: 3 PAGES: 17

									802.11 WLAN ARCHITECTURE – BEST PRACTICES




               February 16, 2005

          A Whitepaper Prepared by
        3e Technologies International
        9715 Key West Avenue, Fifth Floor
               Rockville, MD 20850




                   Page 1 of 17
         802.11 WLAN ARCHITECTURE – BEST PRACTICES
                                 EXECUTIVE SUMMARY
This whitepaper presents the two major approaches for deploying Wireless Local Area Networks (WLANs)
in the enterprise. Both approaches require Wireless 802.11 based Access Points (APs) and some method for
managing these network elements. However, the two approaches have some basic philosophical
differences which can have a major impact on deployment costs, security and manageability. 3e
Technologies, a company at the forefront of providing secure wireless solutions to the Federal Government,
makes a case for the so-called “Distributed” or “Extension” Architectural approach. This paper points out
the superiority of such an approach over the “Centralized” or “Overlay” approach to WLAN network
deployment.

Some of the major points described in this paper are the complexities and potential security vulnerabilities
of deploying Virtual Private Network or VPN technology. While the authors of this whitepaper agree that
VPN technology is the best choice for Remote Network Access for so-called “road warriors” or personnel
who need to access base resources remotely, VPNs are not the optimal solution for day to day wireless
connectivity on the base. The technical details of a layer 3 VPN Trojan attack are described as well as the
protection offered by Layer 2 encryption approaches such as those offered by 3eTI. Furthermore, this
paper shows that only distributed encryption, that is where each Access Point (AP) has built in
Cryptographic Modules, provides sufficient security. This would preclude the use of so-called layer 2.5
solutions from vendors such as AirFortress which pass encryption through generic APs. This type of
solution is still vulnerable to the Trojan attack described in this paper. 3eTi firmly believes that the
“security edge” should begin as close to the end user as is possible, at the AP, not further into the trusted
network and only true layer 2 encryption provides adequate security for Sensitive But Unclassified (SBU)
data.

In terms of ensuring maximum interoperability between vendors, 3eTI supports the use of industry
standards such as IEEE 802.11i, the newly ratified and improved WLAN security standard which supports
strong Layer 2 AES based encryption. With the Wi-Fi Alliances WPA2 certification that uses 802.11i as
the core, we foresee 802.11i being adopted across the Federal government. However, systems that employ
cryptography MUST still be validated under FIPS 140-2 and in many cases must also be certified under the
Common Criteria. Only those vendors focused on Federal Government requirements will meet these other
rigorous security standards.

The US Army has already mandated that Layer 2 security be used for Wireless Local Area Networks (see
policy document 03-EC-M-0003). The US Air Force has deployed a WLAN system in a test lab using an
older Layer 3 architecture called CITS I. Recently, the Air Force let an RFP for the CITS II Next
Generation WLAN. The Air Force decided to still mandate Layer 3 VPN technology as a Threshold
requirement in the latest RFP. Unfortunately, VPN technologies have many interoperability issues and a
very complex to manage. It is interesting the Air Force is attempting to use a Remote Access Technology
for Local Wireless Network Access. This approach will be more costly and complex than a Layer 2
approach. However, the Air Force has decided that 802.11i, a Layer 2 technology is an Objective
requirement as well for WLANs, thus showing some recognition of the potential importance of Layer 2
security and the need for vendor interoperability.

In order to meet the requirements of the US Army, 3eTI has developed the 3e-525A and 3e-527 Wireless
Access Systems which support many Federal Government and Industry standards such as FIPS 140-2,
802.11i, TIC, DoD PKI and many other requirements. In addition, 3eTI also in the NIAP queue for
Common Criteria Certification. As a Secure Wireless Product provider to the US Government, 3eTI also
has many advanced features such as wireless Mesh Networking, built-in Video Servers for Secure Video
surveillance, RFID technology and other infrastructure products which pass stringent Federal Government
and Military requirements.



                                              Page 2 of 17
     802.11 WLAN ARCHITECTURE – BEST PRACTICES
INTRODUCTION

This paper is intended to:

       (1) Define two major architectural approaches to WLAN Deployment –
           Distributed and Centralized
       (2) Compare and Contrast the two approaches
       (3) Discuss the Use of VPN Technology for Wireless Implementations
       (4) Describe the impact of the 802.11i WLAN Security Standard on existing
           deployments
       (5) Elaborate on the capabilities and features of equipment from 3eTI which
           adheres to industry standard Wi-Fi interoperability standards and meet Federal
           Government requirements such as FIPS 140-2 and Common Criteria.

WLAN DEPLOYMENT ARCHITECTURES

There are two major approaches today for deploying WLAN networks in the enterprise.
Both approaches require Wireless 802.11 based Access Points (APs) and some method
for managing these network elements. However, the two approaches have some basic
philosophical differences which can have a major impact on deployment costs, security
and manageability.

The first architecture to be presented is the so-called “Centralized” WLAN Architecture.
The Centralized Architecture requires one or more servers or special purpose switches to
be deployed in conjunction with Wireless Access Points. In the Centralized approach, all
wireless traffic is sent through the WLAN switch. The WLAN switch is often also a
layer 3 VPN server which sets up end to end tunnels between the WLAN switch and the
wireless client devices. Some vendors offer WLAN switches that provide layer 2
security instead of a layer 3 VPN. In either case, the centralized approach is considered
to be an “Overlay” architecture. That is, it rides on top of the existing Ethernet network.

Another approach is the “Distributed” Access Point WLAN Architecture. The
Distributed Architecture adheres closely to the principles of the IEEE 802.11 standard.
In the Distributed approach, APs have built-in WLAN security, layer 2 bridging, and
access control features. Depending on the number of APs required, Centralized
Management may be required. Distributed AP vendors may provide Centralized
Management tools or the APs may be managed by the existing Network Management
Infrastructure. The AP is connected directly to the trusted wired infrastructure and
“extends” the wired network by providing wireless connections to wireless client devices.
In most cases the WLAN security provided by the AP employs Layer 2 MAC level
encryption as defined by the IEEE. Some vendors also provide APs which provide Layer
3 Wireless VPN connections as well. One of the advantages of the Distributed or



                                       Page 3 of 17
Wireless Extension approach is that the wireless traffic load is literally distributed across
the APs and does not depend on a centralized element to process all of the wireless
traffic. In the Centralized approach, loss of the WLAN Switch results in loss of the
wireless network, whereas with the Distributed architecture, there is no single point of
failure.

From a performance point of view, the Distributed Architecture is superior from a
performance/efficiency point of view. This is because the Centralized approach requires
all wireless packets to be processed by the centralized WLAN Switch whereas in the
Distributed Architecture, the packets are handled by the APs and only management
traffic needs to go to and from a central point. Centralized Architectures tend to be
difficult to scale because each WLAN switch can only handle a limited number of APs.
Once multiple WLAN Switches are introduced, another entire layer of equipment needs
to be managed. One of the goals of the Centralized Architecture was AP independence.
However, in practice, most WLAN switch vendors offer their own APs with proprietary
management protocols built in.

From a manageability point of view, the Distributed Architecture offers several
advantages over the Centralized approach. First of all, Distributed APs generally support
standard management interfaces such as SNMP and therefore are manageable by legacy
systems such as HP OpenView. Since the Distributed Architecture is an extension of the
existing Wired LAN, it fits into the legacy network framework. The Centralized
approach on the other hand introduces a whole new network element, the WLAN switch
which then in turn manages wireless APs. The Centralized approach “overlays” a
Wireless network on top of the existing Wired network, in effect creating two separate
networks. In the Distributed approach wireless clients act as standard Ethernet wired
clients and the operation of the wireless technology is often transparent for the end user
and easy for the IT Administrator to manage. The Centralized approach on the other
hand often requires more complex planning and configuration for the IT administrator in
terms of permissions, access control, roaming etc.

CENTRALIZED VERSUS DISTRIBUTED – A SECURITY PERSPECTIVE


The two network diagrams below illustrate both architectural approaches from the
perspective of where the “security edge” is. In any vulnerability analysis it is important
to identify where the trusted and un-trusted parts of the network are. Traditionally, the
wireless links have been thought of as “un-trusted” because of the invisibility of wireless
and its reach. It is difficult to determine where the signal may leak and who may be
eavesdropping on the signal or utilizing the signal for unauthorized access. In the
Centralize approach, the security edge is at the WLAN switch. The APs often do not have
strong encryption capabilities or authentication technology built in. This architecture is
vulnerable to “rogue communications” between APs.




                                       Page 4 of 17
                                                 Authentication                                                                                                                    DHCP
                                                                                                                                                                                 WLAN Management System
                                                     Server                                                                                                                                                  Server




                                                                                                                                                                                                                                               Encrypted
                                                                                                                                                                                                                                             Communications

                                                                                                                                                                                                                                               Unencrypted
                                                                                             7x      8x        9x       10x    11x        12x        7x    8x    9x       10x    11x       12x
                                                                                                                                                                                                                                              Communications
                               Ethernet Switch




                                                   Ethernet
                                                                         C
                                                                             7 8 9 101112

                                                                         A   12 3456         1x      2x        3x       4x         5x     6x         1x    2x    3x       4x     5x        6x
                                                                                                                    A                                                 B




                                                                                                                                                                                                                                                 Rogue
                                                                                                                                                                                                                                              Communications
                                                                                                                                                                                                                                                     Security
                                Access Controller /                                                                                                                                                                                                   Edge
                                  WLAN Switch

                                                                                                                                                                                                                Attack

                                         Ethernet Switch
                                                                                                          7x        8x        9x        10x    11x   12x        7x    8x        9x       10x     11x   12x

                                                                                 C




                                                              Ethernet
                                                                                      7 8 9 101112

                                                                                 A    1 2 34 5 6          1x        2x        3x        4x      5x    6x        1x    2x        3x       4x      5x    6x
                                                                                                                                   A



                                                                                                                                                          Attack
                                                                                                                                                                                     B




                                                                                                                                                                                                                                                     Attack
         Generic AP        Generic AP                                    Generic AP                                                                                                                                   Generic AP        Generic AP


                                                                                                                                                                                                                              Attack




           Vendor Client      Vendor Client SW
               SW                                                                                                                                                                                                        Rogue Client
                                                                                                                                                                                                                                              Rogue Client
                                                                              Rogue Client




              FIGURE 1 – VULNERABILITY OF A CENTRALIZED APPROACH




On the other hand, the Distributed or Extension Architecture pushes the security edge out
the Access Points and extends layer 2 security to the Client devices. In this case, strong
encryption occurs at both the Access Points and Client devices along with authentication.
Attacks are much more difficult to launch because the security edge is closer to the users
while rogue communications are prevented.




                                                 Page 5 of 17
 3e-030 Security Server / WLAN Management System
   Certificate Authority    DHCP Server
                                                                                                                                                          Dynamic Key Exchange
                                                                                                                                                     (client-security server example)
                                                                                                                                                            Encrypted
                                                                                                                                                          Communications

                                                                                                                                                            Unencrypted
                                                                                                                                                           Communications
                                                                                                                                                              Rogue
                                                                                                                                                           Communications
       Ethernet
        Switch                          7x   8x   9x       10x   11x   12x   7x   8x   9x       10x   11x   12x
          Ethernet




                     C
                         7 8 9 101112

                     A   123456         1x   2x   3x       4x    5x    6x    1x   2x   3x       4x    5x    6x
                                                       A                                    B




                                                                                                                                                                         Security
                                  3e-Wireless AP
                                                                                                                         X3e-Wireless APX       3e-Wireless AP
                                                                                                                                                                          Edge




     3e-010F                                                                                  3e-010F
   Crypto Client                                                                            Crypto Client

                                                                                                                  Rogue Client   Rogue Client



   FIGURE 2 – DISTRIBUTED APPROACH PUSHES SECURITY EDGE TOWARDS USERS


CENTRALIZED VERSUS DISTRIBUTED – SECURITY CONCERNS


Aside from the differences presented above with regard to the location of the “security
edge” there are several other important security related differences between the
Centralized and Distributed approaches to WLAN deployment. For network-based
systems, the Open System Interconnection (OSI) 7-layer model is a standard reference,
which defines a networking framework for implementing protocols in these layers that
make up the networking “stack”. Using this context, one can envision the OSI layers and
compare the security implementations typically found in both the Centralized and
Distributed implementations of WLANs. A centralized approach will typically utilize
Virtual Private Networking (VPN) technology with IPSec. IPSec provides an
Encapsulating Security Payload (ESP), which is a protocol header inserted into an
Internet Protocol (IP) datagram at the (layer 3) network layer. IPSec is intended to
provide confidentiality, data origin authentication, anti-replay, and data integrity services
to IP frames. Virtual Private Networks (VPNs) typically rely on IPSec for implementing
secure tunnels. The drawback to this approach is that for wireless systems, the datalink


                                                                                                                     Page 6 of 17
(layer-2) and physical (layer 1) frames are completely unprotected using IPSec
alone. Spoofing and replay attacks on the MAC (Media Access Control) and physical
layer packets are possible. With IPSec, the contents of the Layer-2 802.11 MAC header
are transmitted in the clear. These “wireless packet headers” are effectively unprotected,
allowing an intruder or rogue device to intercept and freely decode the following
information that is unprotected by IPSec in the 802.11 MAC headers:

       (1)   Frame Control Contents
       (2)   Duration / ID Material
       (3)   Destination & Source Addresses
       (4)   Sequence Control Information




                    FIGURE 3 – OSI MODEL AND HEADER FORMATS

Distributed Architecture implementations typically utilize layer 2 security based on IEEE
802.11 standards. Strong FIPS 140-2 validated Layer 2 AES encryption protects critical
portions of the MAC header, while IPSec and VPNs do nothing to protect these MAC
headers that encapsulate the 802.11 “wireless packets”. This point is illustrated above in
FIGURE 3. Furthermore, layer 3 implementations are vulnerable to “Trojan” software
attacks. For example, if a client device gets “infected” with a Trojan software program,
the user will most likely be unaware of this and data can be transferred into and out of the
device without the knowledge of the user opening the door for several types of attacks
and loss of sensitive data. This scenario is illustrated below in FIGURE 4.




                                       Page 7 of 17
                                  TCP/IP                    TCP/IP          Trojan App.
           TCP/IP
                                VPN shim                VPN Shim           Trojan TCP/IP
        NDIS driver
                               NDIS driver                NDIS driver              Stolen
        WLAN card
                                                                                   Unencrypted
                               WLAN card                  WLAN card
                                                                                   Packets
     Standard Windows       Windows Networking            Windows Networking Stack with
           Stack             Stack with a VPN             a VPN and a Trojan Application


FIGURE 4 – STANDARD IMPLEMENTATION OF VPN AND TROJAN ATTACK PRINCIPLE


 In the above scenario, a standard layer 3 VPN Shim configuration found in a client
 device is compromised by a Trojan TCP/IP stack and an associated malicious
 application. Once the WLAN hacker establishes connections to the Trojan, the
 Ethernet Switch will forward no more traffic to the VPN server. There will
 effectively be a virtual connection between the WLAN client and the WLAN hacker
 that is very difficult to detect. In fact, most IDS/firewall tools that can be run on the
 user's PC will not see this traffic. The WLAN hacker now has complete remote
 control of a system that is properly authenticated via the VPN into a corporate
 network.

 Security at Layer 2 while providing Strong Encryption can also remediate the
 situation illustrated above. As shown in FIGURE 5, a layer 2 solution encrypts all
 packets which wirelessly enter or leave the device at the Driver Level. This prevents
 ANY unencrypted data from being sent out the wireless interface. As can be seen in
 FIGURE 5, the malicious Trojan application with the intention of stealing
 information is thwarted.

                                 Trojan App.
                 TCP/IP         Trojan TCP/IP
                                                                           Clear Text
              NDIS crypto-
                                                    NDIS Driver performs
                driver
                                                    Layer 2 Encryption
               WLAN card                            And data cannot be
                                                    Transmitted in the Clear, even if a Trojan
          Windows Networking Stack with             Is inserted – Trojan Cannot steal information
          a 3eTI Layer 2crypto Client and a
                       Trojan




    FIGURE 5 – LAYER TWO STILL PROTECTS DATA FROM A TROJAN ATTACK



                                     Page 8 of 17
           The 3e Technologies Crypto Client encrypts all packets at layer 2 so even if a Trojan
           TCP/IP stack and Rogue Application is inserted it will be unable to send unencrypted
           packets in the clear, thus defeating the intention of the Trojan application.

           The choice of layer 2 or layer 3 security is actually independent of the choice of
           WLAN Architecture. In fact, there are distributed APs with built in VPNs and
           WLAN switches which have layer 2 security. We have already explored the
           superiority of security at layer 2. Let’s take a deeper look at WLAN Switches which
           implement “layer 2” security.

           Strictly speaking, in order to have true layer security, the encryption must be done at
           the Driver level and there should not be a way to bypass this encryption as there is
           with a layer 3 VPN solution illustrated above. If one looks closely at so-called Access
           Point “independent” solutions offering layer 2 encryption, they will find that in
           actuality although the encryption is implemented in driver, it is actually at a higher
           layer which for the sake of discussion we will call “layer 2.5”. FIGURE 6 below
           illustrates this.

  MicroSoft
                                                                               Trojan Aplication
 TCP/IP Driver                 TCP                  UDP

                                      IP Routing
                                                                              Trojan TCP/IP Stack




NDIS API Used
 by Protocols

                                                          Competitor NDIS        Trojan NDIS
   NDIS API                                                 Intermediate         Intermediate
                                                          Security Solution



3eTI NDIS Miniport
 Driver cannot be                                    NDISWRAPPER
    bypassed


                               3eTI NDIS Miniport                                            Competitor NDIS
                                                      Off-the-Shelf NDIS
                                   AES/3DES                                                    Intermediate
                                                           Miniport
                                  Encryption                                                 Security Solution
                                                                                             can be bypassed




                                      NIC                       NIC




        FIGURE 6 – FLAW WITH “PASS THROUGH” NON-AP BASED LAYER TWO SOLUTIONS




                                                Page 9 of 17
As can be seen above, even though the security solution is “layer 2”, encryption can be
bypassed using techniques similar to the Trojan VPN attack. The 3eTI layer 2 solution
which follows the IEEE principles, replaces the NDIS driver completely and thus cannot
be bypassed as shown above. Therefore, in WLAN security architecture and design, one
should be wary of “Non-AP” based Layer 2 security solutions for the aforementioned
reasons.

With advent of the 802.11i security standard, the IEEE has fully endorsed layer 2 security
with 802.11i. As can be seen, the US Government Departments and Agencies are rapidly
embracing this standard with the caveat that it must be FIPS 140-2 Validated.

VPN TECHNOLOGY – FIT FOR WIRELESS?

A typical implementation of a wireless network is shown below in FIGURE 7:

                                               Link Encryption Key
                                                       Layer 3                    Unencrypt
                                                                                  Layer 3

                                    Network
                                     Router                                      Firewall


                                                                                          Internet
                                                                 Remote
                                                                  VPN
                                         WLAN Switch             Server




                                                                                   AP



                                                                          VPN Client    VPN Client




                                   AP                           AP


                                        VPN Client VPN Client
                      VPN Client                                     VoWLAN
                                                                      Phone
                                                                      w/VPN




  FIGURE 7 – A LAYER 3 CENTRALIZED WLAN SWITCH ARCHITECTURE WITH VPN
           SERVER OUTSIDE OF THE FIREWALL (NOT RECOMMENDED)




                                          Page 10 of 17
VPN technology in the above case is used as a Remote Access method for both wired and
wireless clients as well as a LOCAL Access solution. Utilizing Layer 3 VPN technology
for a local access solution is not the optimal approach for a number of reasons:

(1) Scalability
(2) Manageability
(3) Solution Overhead
(4) Vulnerability to Trojan Attacks
(5) VPN outside of Firewall

A better approach is to use Layer 2 Security for Local Access and VPN Technology for
Remote Access.

                              Link Encryption Key
                                      Layer 3                    Unencrypt
                                      Layer 2                    Layer 3

                Network
                 Router                         Firewall

                                                                      Internet

                        Generic                 Remote
                         LAN                     VPN
                        Switch                  Server




                                                                  AP                Layer 3
                                                                                    Protection
                                                                                    for Remote
                                                                       VPN Client   Access
                                                         VPN Client




               AP                             AP                          Superior Layer 2
                                                                          Protection for Base,
                                                                          Post/Fort and Camp
   802.11i          802.11i         802.11i     VoWLAN Phone
    Client           Client          Client      802.11i Client
   w/FIPS           w/FIPS          w/FIPS       w/FIPS 140-2
    140-2            140-2           140-2
      FIGURE 8 – A DISTRIBUTED WLAN ARCHITECTURE UTILIZING LAYER 2


                                        Page 11 of 17
SECURITY FOR ON BASE AND LAYER 3 FOR REMOTE ACCESS (BETTER APPROACH)

With the centralized approach, loss of a WLAN switch leaves several APs unable to
communicate and a major loss of RF coverage. The distributed approach illustrated
above has several advantages over the centralized approach including performance
efficiency (no central bottleneck), better on base security (immunity to Trojan attack),
better interoperability with 802.11i and easier to maintain and scale than a VPN based
LAN solution. In the distributed approach the loss of a secure AP due to malfunction only
results in a small loss of RF coverage, but no loss in overall security.

Government Security requirements specify FIPS 140-2 for security, but do not explicitly
define the type of technology or specific layer where the encryption resides. The US
Army has published a document 03-EC-M-0003: Issuance date: 22 June 04
 this specifically spells out the layer 2 security requirement for WLAN deployment –
Section C:

“Wireless solutions must protect layer two (link layer OSI model) with an approved FIPS
140-2 level 1 encryption module. Vendors must demonstrate movement to FIPS 140-2, Level 2
certification for continued use”

In terms of remote users or “Road Warriors”, the Army further elaborates on the
requirements in section D which are at Layer 3:

“D. Standards for mobile wireless computing “Road Warrior”
(1) Mobile devices must have a VPN client configured to establish a secure tunnel.
Reason: Layer 2 cannot be protected with current technology unless we own the network. VPN’s
operate at layer 3, helping to mitigate, but not eliminate, layer 2 risks. VPNs must meet encryption
certification requirements, i.e., FIPS 140-2 level 1. Vendors must demonstrate movement to FIPS
140-2 level 2, before authorization to use.
(2) Mobile devices must have an EAL 4 + approved firewall configured to only allow
authorized communications. Firewall must operate at the Network Driver Interface Specification
(NDIS) Layer using stateful packet inspection.”

The US Air Force has deployed WLANs using the CITs I Architecture. This Architecture
has proven to be too expensive and problematic and recently the Air Force has put out a
proposal for the CITS II program. Unfortunately, although the Air Force has asked for
improvements over the CITS I Architecture, they have essentially asked for a similar
Architecture in CITS II. 3eTI has had several meetings with the Air Force and has
explained some of the issues with CITS I – specifically the complexity of managing a
VPN for daily on Base use, inherent performance issues with VPN technology, cost of
VPN technology, the placement of a VPN Server outside a Firewall as a security risk, the
inherent Security risks of Layer 3 solutions and the fact that VPNs are really intended for
Remote Access not daily access not for local LAN users. Furthermore, the Air Force
Requirements ask for layer 2 802.11i technology to protect the wireless links AND layer
3 VPNs. These requirements are somewhat contradictory at worst and redundant at best.



                                          Page 12 of 17
In addition, the Air Force requirements for CITS II specify several outdated products
such as CiscoWorks which is at “End of Life” status.

In order to help the Air Force meet its Software Requirements for CITS II, 3eTI is
proposing a solution which utilizes both Layer 2 and Layer 3 technology plus DoD PKI
compliant authentication. 3eTI strongly believes that solely using layer 3 technology for
on base operation is not a good choice for wireless security. First of all, RF signals are
“invisible” and can leak outside the base perimeter. Hackers and other criminals and
passively monitor stray RF transmissions and can also send signals into areas where the
WLAN receivers will pick up the signals. Daily patterns of military personnel can be
monitored – who goes into the base, when the log in etc. Because of this situation, Layer
2 security such as 802.11i or some other layer 2 driver encryption scheme is highly
recommended as a primary requirement. The 802.11i security must also be FIPS 140-2
validated. 802.11i is the best choice in terms of guaranteeing interoperability between
vendors. The 3eTI proposed solution for CITS II is shown below in FIGURE 9:




                                      Page 13 of 17
                          Link Encryption Key
                                 Layer 2                  Unencrypt
                                 Layer 3                  Layer 3

             Network
              Router
                                                                 Internet


                                               Remote
                                                VPN
                                               Server
                      VPN
                     Server




           3eTI                      3eTI                        3eTI
          Secure                    Secure                      Secure
          Enterpri                     AP                         AP
   3eTI       AP
                    3eTI     3eTI                       3eTI            3eTI
                                          VoWLAN
CryptoClient CryptoClient CryptoClient               CryptoClient    CryptoClient
                                             Phone
  w/VPN            w/VPN    w/VPN          w/VPN and   w/VPN           w/VPN
                                           CryptoClient


FIGURE 9 – HYBRID SOLUTION PROPOSED FOR US AIR FORCE CITS II PROGRAM

  With the above architecture, both layer 2 and layer 3 security runs simultaneously.
  The 3eTI equipment provides 802.11i layer 2 protection. This Architecture meets the
  CITS II specification. Running a VPN on top of WiFi adds overhead to network and
  tasks for administrator and user, however, an IPSEC VPN is required by the Air
  Force. One option in the future is once 802.11i Access Points with FIPS 140-2
  validation are in the network, layer 3 security will be turned off behind the firewall
  since the VPN will be redundant for local wireless security. The VPN will still be
  used for point-to-point over internet, not security over WiFi. 3eti is teaming with
  layer 3 companies to provide a combined security solution (VPN over secure WiFi)
  where customers such as the Air Force require this. The above architecture solves the


                                    Page 14 of 17
   problem of the VPN server location. A VPN server can be place outside the firewall
   for remote users, however, the daily on based wireless infrastructure will reside
   completely within the firewall with a separate VPN server infrastructure.

UNDERSTANDING WI-FI CERTIFICATION AND FIPS 140-2 VALIDATION –
A QUESTION OF INTEROPERABILITY

From the Wi-Fi website (www.weca.net):
“Wi-Fi Certification comes from the Wi-Fi Alliance, a nonprofit international trade
organization that tests 802.11-based wireless equipment to make sure it meets the Wi-Fi
standard and works with all other manufacturers' Wi-Fi equipment. Thanks to the Wi-Fi
Alliance, you don't have to read the fine print or study technical journals: if it says Wi-Fi,
it will work.”

To achieve the goal of interoperability, Wi-Fi certification, and FIPS 140-2 validation,
certain technological tradeoffs must be made. Layer 2 AES encryption protects the
“wireless” packets at the MAC sublayer. Wi-Fi also provides a mechanism to achieve
Layer 2 encryption, called Wi-Fi Protected Access (WPA).

Again, it should be emphasized that the main goal of the Wi-Fi alliance, which is
networking interoperability, has been achieved; however, Wi-Fi is not the guiding
authority or de facto standard when wireless security is at stake, and Wi-Fi cannot replace
FIPS 140-2 or the Common Criteria in specifying security requirements for the DoD,
including the U.S. Navy. It should also be noted that Wi-Fi certification of FIPS 140-2
validated equipment is certainly achievable in a non-(FIPS 140-2) mode, in order to
achieve interoperability with other Wi-Fi certified equipment and vendors. However, it is
important to note that this arrangement can not currently achieve DoD-mandated
accreditation at Layer 2 due to Wi-Fi’s employment of RC4 encryption.

Currently, the Wi-Fi Alliance offers WPA2 certification which uses 802.11i as the built-
in security standard, thus ensuring that next generation WLAN products will interoperate
with the option of using strong AES encryption at layer 2. However, individual vendors
will STILL have to go through the rigorous FIPS 140-2 Validation process. Getting
802.11i/WPA2 certification is NOT equal to getting FIPS 140-2 Validated.
The impact of the new 802.11i ratified IEEE standard and WPA2 will be enormous. The
military has recognized this and has deemed 802.11i as an important standard going
forward. Vendors such as 3eTI who specialize in wireless security are well positioned to
utilize the new standard and take products through the FIPS 140-2 validation. This will
entail the use of special modes to ensure that the non-FIPS approvable modes of 802.11i
are not used in while operating in FIPS 140-2 mode, along with many other security
related modifications.


The FIPS 140-2 certification process is itself a rigorous ordeal that ensures all hardware
and software within a “cryptographic boundary” is correct-by-construction and



                                       Page 15 of 17
cryptographically sound. FIPS 140-2 certification requires a comprehensive design and
verification process, to satisfy eleven chapters of FIPS derived test requirements (DTRs).
These DTRs focus on the cryptographic module specification; cryptographic module
ports and interfaces; roles, services, and authentication; the detailed finite state model;
physical security; operational environment; cryptographic key management; EMI/EMC
requirements; power-up and conditional self-tests; design assurance; and mitigation of
possible attacks. The FIPS 140-2 certification process involves proof-of-design and
proof-of-cryptographic-soundness with one of nine worldwide NIST-approved
independent NVLAP (National Voluntary Laboratory Accreditation Program)
cryptographic module testing facilities. Once the cryptographic module design and
documentation has been demonstrated to the NVLAP testing facility, NIST performs a
final review of the NVLAP findings. 3eTI has a lot of experience designing , building
and successfully bringing secure wireless products through this process.


WI-FI CERTIFICATION OF 3eTI WIRELESS PRODUCTS

In order to be interoperable with a large market share of industry-standard wireless
equipment which are based on the Intersil and Atheros chipsets and drivers, 3e supports a
non-FIPS mode which is fully Wi-Fi compliant. Today, 3e equipment is compatible with
Intersil Prism 2.5 and higher (Linux and Windows drivers) Atheros (Linux and Windows
drivers), and Centrino (Linux driver). 3eTI plans are to work with as many cards as
possible on the market. The primary difference in the 3e solution and others is that we
replace the active NDIS driver from the manufacturer with our 3e driver (Crypto) NDIS.
While this does require us to build drivers for each chipset type, it also offers a greater
level of layer 2 encryption over other solutions which only really achieve layer 2.5 of the
OSI model without directly building a NDIS driver. The Prism2.5 and Prism3 chipsets
are evolution of the PrismII chipset, offering even higher integration, lower cost and
backward compatibility. With respect to the driver, these 3 chipset look the same, and
therefore the 3e driver supporting PrismII hardware will also support Prism2.5 and
Prism3 hardware.

In order to meet FIPS 140-2 validation requirements AES, 3DES, or Skipjack data
encryption is required. Of these three, AES is specified by NIST FIPS-197 and is the
only encryption algorithm that will be compatible with the near-final 802.11i standard. If
interoperability is a higher priority than pure security, 3e equipment can be placed in non-
FIPS mode for Wi-Fi interoperable operation.




                                      Page 16 of 17
.
    3eTI Leads Competition in Meeting DISA/DOD
    Wireless Requirements
        o Common Criteria - 3eTI meets the NSA Sponsored Protection Profile for WLAN
          Access System
        o FIPS 140-2
        o JITC DoD PKI Certification
        o Wireless LAN Technical Guidance (SPAWAR)
        o Wireless DISA Security Technical Information Guide (STIG)
        o DoD Directive 8100.2 Use of Commercial Wireless Devices, Services, and
          Technologies in the DoD Global Information Grid (GIG)
        o NIST 800-60 Special Publication Volume I: Guide for Mapping Types of
          Information Systems to Security Categories; Volume II: Appendices to Guide for
          Mapping Types of Information and Information Systems to Security Categories
        o NIST FIPS 199 Standards for Security Categorization of Federal Information and
          Information Systems
        o DoD JIEO Report 8307 Guide to Selecting Computer-Based Multimedia Standards,
          Technologies, Products and Practices
        o DoD 8510.1-M DITSCAP Department of Defense Information Technology
          Security Certification and Accreditation Process
        o Common criteria EAL 2+ (In-Process)
        o PMW (Program Management Warfare) 165 Afloat Engineering SPAWAR C4I
          Afloat Wireless Guidance
        o US Army NETCOM 9th Army Signal Corps Information Assurance Testing and
          Validation
        o US Army Test & Integration Center (TIC) Testing
        o NIST SP 800-48 Wireless Security Guidance Document
        o NIST FIPS 140-2 Cryptographic Module Certification Program
        o MIL-STD-901D (Grade A & B Shock Mounts) Shock Validation
        o MIL-STD-461E EMI Emissions and Susceptibility
        o MIL-STD-167 Vibration
        o MIL-STD-810F Humidity
        o DD1494 – Circulation of Frequency and attenuation usage to Host Nations
        o SEA/53H – HERO, HERP, HERF Validation
        o FCC Part 15, Subpart B
        o 802.11i /WPA2




                                    Page 17 of 17

								
To top