Ads 468x60px

WiNG How-To Guide Digital Certificates - Overview

Saturday, February 15, 2014 6:53 PM
Security in 802.11 systems relies on digital certificates to provide mutual authentication and encryption. Mutual authentication or trust is provided by leveraging Public Key Infrastructure (PKI) which allows all parties in the security exchange to verify and validate digital certificates on each party. Authentication and encryption is provided using standard public key and private key algorithms to protect credentials exchanged over the air as well as exchange credentials.

Certification Authority:
To verify that a digital certificate is not forged, you need a mechanism to validate it which is provided by a certification authority (CA). The CA is a trusted third party that can be a private secure server deployed in an enterprise data center or a public server from a specialized company offering certificates such as Entrust, Go Daddy or, VeriSign.
The CA is charged with signing all user and server certificates and signs a certificate by running a hash of the certificate contents, encrypting the hash with its Private Key (creating a digital signature), then appending this signature to the end of the certificate. The CA also has a certificate of its own called a CA certificate or root certificate. The root certificate contains the CA’s Public Key and can be freely distributed any party. Anyone that has the CA’s root certificate installed can validate certificates issued from the CA.
Most operating systems include root certificates issued from top public certificate providers allowing secure transactions to be made on-line without having to manually install root certificates.
Using a CA to sign user and server certificates and validate them is the simplest form of Public Key Infrastructure (PKI). A certificate chain includes information about the CA or CA’s involved in issuing certificates and the user or server certificates themselves. There are other PKI functions such as certificate revocation lists, cross-certification and certificate chaining that are used but are beyond the scope of a guide.

Trustpoints:
Server and CA certificates are installed in pairs on the RF Switch into trustpoints which are assigned to the local RADIUS and HTTPS services. Each service on the RF Switch supports a single trustpoint allowing separate server certificates to be used for RADIUS and HTTPS services.
WiNG provides a default trustpoint which includes a self-signed server certificate which is assigned to the local RADIUS and HTTPS services. However as the default server certificate is self-signed, no mutual authentication can be provided as no Certificate Authority (CA) root certificate exists to allow the end users to trust the self-signed certificate.
To provide mutual authentication and trust for management, EAP and Hotspot services a trustpoint needs to be created on the RF Switch and a certificate request generated to a public or enterprise CA. Once the certificate request has been signed by the CA, the server and CA certificate can be installed on the RF Switch. Once installed the RF Switch mutual authentication can occur between all parties with certificates issued from the CA.
Server Certificates:
Server certificates are digital identifications containing information about a server, service or organization. Server certificates contain a public key which is used to create a secure TLS connection between the service and end user device. In WLAN environments server certificates are used to provide secure encrypted HTTPS management connections to RF Switches and Access Points as well as protect credentials over the air for Hotspot and EAP authentication.Server certificates are required for all external RADIUS servers providing EAP authentication as well as the RF Switches providing RADIUS, Hotspot or secure web based management. The RF Switch supports a single server certificate for local RADIUS services and a single server certificate to provide Hotspot and secure web based management.
Root Certificates:
A root certificate is a self-signed certificate or an unsigned public key certificate which forms the foundation of a public key infrastructure (PKI). A root certificate is the top-most certificate in the Certificate Authority (CA) tree, and its private key is used sign all certificates issued from the CA.
Root certificates are installed on end user devices to identify and verify digital certificates issued from CAs. Root certificates for common public CAs such as Entrust and VeriSign are typically pre-installed on most operating systems allowing the end user devices to automatically trust servers and applications using digital certificates issued from these CAs. However in enterprise environments, a private CA is often deployed and CA certificates are automatically or manually distributed to end user devices before certificate verification and trust can occur.It’s not mandatory that a CA root certificate be installed on the end user device for WLAN authentication as web browsers and 802.1X supplicants can establish a secure connection to a peer without a CA certificate being present. However in WLAN deployments it is strongly recommended that a CA root be installed as the CA certificate provides the only mechanism for the end device to verify the identity of the presented digital certificate prior to credentials being exchanged. Without a CA certificate being installed, the device is susceptible to man-in-the-middle (MIN) attacks.

Applications:
Digital certificates are required to enable the following services on the RF Switch:
1)  Secure Web UI Management – Provides secure remote web based management of the RF Switch. When enabled all web management configuration transactions are encrypted using Transactional Layered Services (TLS). In addition PKI allows the remote management station to verify the identity of the RF Switch prior to submitting management credentials.
2)  EAP Authentication – When using the integrated RADIUS server, PKI allows the RF Switch to authenticate users using PEAP, EAP-TLS and EAP-TTLS. These EAP methods provide mutual authentication between the RF Switch and 802.1X supplicant as well as a secure TLS tunnel to exchange credentials over the air.
3)  Hotspot Authentication – Provides web based authentication for users. When users authenticate to the RF Switch by presenting a username and password which is encrypted over the air using TLS. In addition PKI provides the ability to allow the end user to verify the identity of the RF Switch prior to submitting credentials.
1.3  Restrictions:
At this time only a single trustpoint can be assigned to the HTTPS service which is shared for both secure Web-UI management and Hotspot services.
If Hotspot authentication is required, Motorola recommends that the hostname for the CN field in the server certificate be defined to resolve to the IP address assigned to the Hotspot virtual interface. This will ensure compatibility with Mozilla Firefox and Microsoft Internet Explorer which uses the CN field to detect phishing attacks.
Nhãn: ,

0 nhận xét:

Post a Comment

Subscribe to: Post Comments (Atom)