Wireless network controller certification authority

Description

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Application No. 60/964,908, filed Aug. 15, 2007 in the name of the same inventor, titled “Wireless Network Controller Certification Authority”.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to implementing public key infrastructure (PKI) in wireless networks, for example but not limited to IEEE 802.11 networks.

2. Related Art

Public key encryption uses a pair of keys, one public and one private, to protect data and information from unauthorized access. Data or information encrypted with the public key can be decrypted only with the corresponding private key. In addition, public key encryption can be used to authenticate devices and/or parties involved in a communication.

One issue in public key encryption is verifying that a public key is authentic, that is it has not been tampered with or replaced by a malicious third party. A public key infrastructure can be used to address this issue. In a public key infrastructure, one or more trusted certification authorities (CAs) certify ownership of key pair (i.e., a public key and its associated private key). Once trusted, encryption and authentication using that key pair can be trusted.

FIG. 2 shows this arrangement in the context of a convention wireless network (e.g., a conventional IEEE 802.11 network): In this arrangement, wireless devices (not shown) communicate with access points (AP1, AP2, . . . APN) 20, 21 and 22, which in turn communicate with controller 24. The controller provides access to another network such as a VPN, Intranet, the Internet, the World Wide Web, or the like (not shown). XYZ certification authority 26 issues certificates 28, 29, 30 and 31 that certify ownership of key pairs, as described above.

One problem with this arrangement is that the controller does not have complete control over the certification process. In particular, XYZ certification authority 26 has control of the certificates used in the process (XYZ denoting a third party who owns/controls the certification authority). Another problem is that an infrastructure must be put in place to support the external certification authority.

SUMMARY OF THE INVENTION

Briefly, the controller in a wireless network acts as a certification authority (CA).

In one embodiment, a controller for a wireless network includes processing elements, an interface for communication with access points for the wireless network, and an interface to another network. The processing elements oversee communication between that other network and the access points, and the controller acts as a certification authority for authenticating access points using public key techniques.

In another embodiment, a public key infrastructure for a communication network includes a controller and access points for wireless communication. The controller acts as a certification authority with respect to the access points.

Yet another embodiment is a certification authority for authentication of access points for a wireless network, with the certification authority implemented by a controller associated with the access points.

Preferably, the wireless network is an IEEE 802.11 network, although this need not be the case.

This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention may be obtained by reference to the following description of the preferred embodiments thereof in connection with the attached drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a system that includes a controller and local certification authority according to an embodiment of the invention.

FIG. 2 shows a system that performs certification according to the prior art.

DESCRIPTION OF THE INVENTION

Architecture

In more detail, in order to have stricter control over what entities a controller should trust, the controller can also assume the role of a certification authority and issue certificates to the access points so that it trusts only the APs that have certificates issued by the controller's “local CA.” This way, the controller can refuse access to any access points that have certificates issued by any other CAs. Alternatively, the controller could allow access to access points that have certificates issued by other CAs.

FIG. 1 shows an example of this arrangement.

Wireless devices (not shown) communicate with access points (AP1, AP2, . . . APN) 1, 2 and 3, which in turn communicate with controller 5. Preferably, the wireless network used by the access points is an IEEE 802.11 network, although this need not be the case.

The controller provides access to another network such as a VPN, Intranet, the Internet, the World Wide Web, or the like (not shown). XYZ certification authority (CA) 7 issues certificate 8 to APN 3. Controller 5 does not honor this certificate, as shown by the X in box 10. In an alternative embodiment, controller 5 could honor the certificate.

Local certification authority (CA) 12 in and/or controlled by controller 5 issues certificates 14 and 15 to access points (AP 1 and AP 2) 1 and 2. Of course, the invention is not limited to issuing two certificates to two access points. These certificates certify ownership of key pairs for communication between the controller and the access points, permitting secure communication as illustrated by checks in boxes 17 and 18.

The invention is not limited to the arrangement shown in FIG. 1.

In some embodiment, the controller can be configured to allow access to APs that have certificates issued only by that controller's local CA. In that case, the controller preferably always verifies the access point's identity by verifying AP's certificate and making sure that it was signed using controller's own local CA. In other words, a strict authentication/authorization policy can be created between the controllers and access points based on the controller's “local CA” setup. Any rogue access points can thus be restricted from doing anything in the network.

There are many possible advantages to this approach:

• • Without having to rely on any external CA, the controllers can use their own CA setup to establish trust relationships with other entities.
  • This process will also eliminate or at least reduce the need to have or manage an extensive PKI setup.
    Setup

In preferred embodiments, a controller's “local CA” will not be a provisioned CA. Instead, it will be created during the initial setup. This process will help to insure that a controller's CA is unique in any network setup. Preferably, the CA information will be preserved when controller upgrades are performed.

Alternatively, a controller's local CA can be a provisioned CA. Other techniques for implementing the local CA can also be used.

Various access points (or other clients, e.g. admin users) preferably can request a Client certificate from a controller. In one embodiment, the controller does the following steps to create a client certificate:

• • Creates a key-pair
  • Creates a Certificate Signing Request (CSR). For example, a certificate under the X.509 v3 standard, including version, serial number, algorithm id, issuer, validity, not valid before, not valid after, subject identification, subject public key information, public key algorithm, subject public key, issuer unique identifier (optional), subject unique identifier (optional), and extensions (optional), where subject is the target ap for the certificate. Other types of PKI certificates can be used.
  • Signs the certificate (signing performed by the local CA)
  • Creates a file to hold the certificate. For example, a PKCS#12 file (Personal Information Exchange Syntax Standard) can be used containing the certificate, corresponding private key, and the local CA public certificate. Alternatively, another file format can be used.
  • Exports the file to be installed on the access point (or any other client).

The invention also encompasses other techniques for setting up a certification authority (CA) in a controller for public-key encrypted communication with access points for a wireless network such as, but not limited to, and IEEE 802.11 network.

A controller's local CA can also certify key pairs for encrypted communication with an access point, with a device through an access point, or for any other communication that involves the controller and an authenticated access point.

Generality of Invention

The invention can be embodied in a method for a controller in a wireless network to act as a certification authority (CA), as well as in software and/or hardware such as a controller that implements the method, and in various other embodiments.

The invention also is applicable to non-wireless networks (e.g., wired or fiber optic networks) in which a controller is associated with access points.

In the preceding description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. However, those skilled in the art would recognize, after perusal of this application, that embodiments of the invention may be implemented using one or more general purpose processors or special purpose processors adapted to particular process steps and data structures operating under program control, that such process steps and data structures can be embodied as information stored in or transmitted to and from memories (e.g., fixed memories such as DRAMs, SRAMs, hard disks, caches, etc., and removable memories such as floppy disks, CD-ROMs, data tapes, etc.) including instructions executable by such processors (e.g., object code that is directly executable, source code that is executable after compilation, code that is executable through interpretation, etc.), and that implementation of the preferred process steps and data structures described herein using such equipment would not require undue experimentation or further invention.

This application should be read in the most general possible form. This includes, without limitation, the following:

• • References to specific techniques include alternative and more general techniques, especially when discussing aspects of the invention, or how the invention might be made or used.
  • References to “preferred” techniques generally mean that the inventor contemplates using those techniques, and thinks they are best for the intended application. This does not exclude other techniques for the invention, and does not mean that those techniques are necessarily essential or would be preferred in all circumstances.
  • References to contemplated causes and effects for some implementations do not preclude other causes or effects that might occur in other implementations.
  • References to reasons for using particular techniques do not preclude other reasons or techniques, even if completely contrary, where circumstances would indicate that the stated reasons or techniques are not as applicable.

Furthermore, the invention is in no way limited to the specifics of any particular embodiments and examples disclosed herein. Many other variations are possible which remain within the content, scope and spirit of the invention, and these variations would become clear to those skilled in the art after perusal of this application.