VPN CLIENT PROTECTION PROFILE

Transcription

1 VPN CLIENT PROTECTION PROFILE Target of Evaluation: Aruba Remote Access Point, ArubaOS FIPS Version 1.4 June, 2017 INTRODUCTION This document serves as a supplement to the official Aruba user guidance (documentation), consolidating configuration information specific to the Common Criteria VPN Client Protection Profile (VPNC-PP). Most RAP configuration is performed through an Aruba Mobility Controller running ArubaOS, which acts as the VPN headend/concentrator. This document contains configuration "snippets" from an ArubaOS configuration file. For the sake of simplicity, only command-line interface (CLI) commands are included. When configuring an Aruba controller, a graphical user interface (WebUI) is also available; this document does not include screenshots from the WebUI. Refer to the official ArubaOS User Guide for WebUI instructions, if needed. Configuration of the RAP which is not performed by the Mobility Controller includes: 1. Specification of the Mobility Controller s IP address/hostname 2. Loading/generation of customer-provided certificates and private keys 3. Selection of client credentials to be used for VPN connections VERSION INFORMATION This document covers the Aruba Remote Access Point (RAP) running ArubaOS FIPS, which was evaluated under version 1.4 of the Protection Profile for IPsec Virtual Private Network Clients. Customers are advised to use the newest available software release in order to take advantage of defect fixes, which may include fixes for security vulnerabilities.

2 CONFIGURATION FMT_SMF.1 RAPs ship from the factory with the Aruba Instant AP (IAP) software load pre-installed. Before they can be used as a RAP, they must be converted to RAP mode by providing them with the IP address of an Aruba Mobility Controller. The conversion process will overwrite the IAP software on one partition of the RAP s flash memory, and replace it with the same version of ArubaOS that has been installed on the mobility controller (ArubaOS FIPS for this evaluation.) IAP software remains on the second partition; resetting the RAP to factory defaults (by holding down the reset button for ten seconds while connecting the RAP to power) will restore the IAP software. Once converted to RAP mode, specification of the VPN gateway and all other settings used for connections will be pushed to the RAP client from an Aruba Mobility Controller, through an IPsec tunnel. The initial tunnel need not be made to the actual gateway that the RAP will later connect to in operation, although they are normally the same system. The end user or administrator is responsible for entering the initial IP address or hostname of the mobility controller where the rest of the configuration data may be downloaded. See Appendix A of this document for instructions on converting the unit to RAP mode and establishing the initial connection to the mobility controller. The RAP will authenticate itself to the mobility controller over IKEv2 using a factory-installed X.509v3 certificate the certificate s Common Name field will contain the MAC address of the RAP. The MAC address of the RAP must be configured in the controller s whitelist before it will be allowed to connect. Instructions for configuring the controller whitelist are found in the ArubaOS 6.5 User Guide, Chapter 2, under the Managing AP Whitelists section. The following CLI command shows the minimum configuration required to add a RAP to the controller s whitelist: #whitelist-db rap add mac-address <mac-address> ap-group <ap-group> After the initial connection, an administrator-generated X.509v3 certificate may be installed for use in future authentication requests. If an ECDSA-based certificate is installed, this will signal the RAP to establish a Suite B compliant IPsec connection. See Appendix B of this document for instructions on loading an administrator-generated X.509v3 certificate. One an administrator-generated certificate is installed, this credential will always be used for authentication. A RAP may contain only a single administrator-generated certification. If the administrator-generated certificate is later deleted, the RAP will again use the factory-installed certificate. The factory-installed certificate may not be deleted. Note: The private key for the factory-installed certificate is secured within a Trusted Platform Module (TPM) and is protected against tampering. The version of TPM used will only support RSA keys, and is not programmable outside of the factory. Administrator-generated certificates and private keys are not protected by the TPM; they are stored in flash memory. When using administrator-generated custom certificates, ensure that an adversary cannot gain physical control of the RAP. Alternatively, the certificate and private key may be stored on a removable USB flash drive. See Appendix C of this document for instructions on using a USB flash drive for key storage. Once the RAP establishes an initial connection to a mobility controller, all further configuration data is downloaded automatically by the RAP. The administrator configures the mobility controller, and this 2

3 information is then pushed to the RAP. Chapter 32 ( Remote Access Points ) of the ArubaOS User Guide contains full details of how to configure RAPs there are numerous configuration and connectivity options shown in the user guide that are outside the scope of a Common Criteria evaluation. Once a RAP has been initially provisioned, it will always attempt to establish an IPsec connection with the mobility controller. In the event an IPsec connection is broken, the RAP will continuously attempt to reestablish the connection. The RAP continues this behavior until a connection is established or until power is switched off. FCS_CKM.1, FCS_CKM.2 Placing the RAP into FIPS mode will ensure that all cryptographic services are compliant with these requirements. In the following configuration (and all other profile configurations in this document), the default profile is used. If you have configured a different profile, be sure to use the correct name. An explanation of profiles may be found in the ArubaOS User Guide. To place a RAP into FIPS mode: (config) #ap system-profile default (AP system profile "default") # fips-enable The RAP, and the mobility controller, contain no other cryptographic engines. There is a single engine, which may be operating in FIPS mode or in non-fips mode according to configuration. Thus, no other cryptographic engines were tested during the Common Criteria evaluation. FCS_CKM_EXT.2 RAPs contain a RSA2048-based certificate that is installed at the time of manufacturing. The private key for this certificate is protected by a Trusted Platform Module (TPM). The use of this certificate must be authorized, individually, by configuring a whitelist on the mobility controller. Users who do not wish to use the Aruba manufacturing certificate, or who wish to use Suite B IPsec, must install a new certificate through a local administrative interface (see Appendix B). FCS_CKM_EXT.4 No configuration is needed to meet this requirement. FCS_COP.1 No configuration is needed to meet this requirement, other than placing the RAP into FIPS mode as described above. FCS_IPSEC_EXT.1.1 RAPs contain both Wi-Fi and wired interfaces. The forwarding behavior of the RAP can be configured for each wired port, and also for the Wi-Fi interface. Forwarding modes are: 3

4 Tunnel: All traffic is tunneled to the mobility controller through the VPN tunnel. The RAP is completely transparent to user traffic. This is equivalent to the PROTECT action specified in the Protection Profile, and also satisfies the requirement for FDP_IFC_EXT.1.1 (not claimed in this evaluation.) Bridge: All traffic is processed locally by the RAP, and forwarded to the next-hop gateway. Although an IPsec tunnel to the mobility controller will be present, the tunnel will only be used for management traffic. User traffic cannot make use of the IPsec tunnel. This mode cannot be used in the evaluated configuration. Split-tunnel: The RAP processes traffic locally, but can forward some traffic to the mobility controller over the IPsec tunnel. Firewall rules are used to control which traffic is sent over the VPN tunnel, which traffic is forwarded locally, and which traffic is dropped. Split tunnel mode, in combination with firewall rules, are used to implement an IPsec Security Policy Database (SPD) and to process packets to satisfy the behavior of DISCARD, BYPASS, and PROTECT packet processing. Specifically, keywords in the firewall rule definition directly control behavior: deny corresponds to DISCARD. This traffic will be dropped by the RAP. permit corresponds to PROTECT. This traffic will be forwarded over the IPsec tunnel to the mobility controller. route and src-nat correspond to BYPASS. This traffic will be forwarded to the RAP s local defaultgateway. If the user s IP address is not routable by the RAP s local default gateway, the src-nat keyword will achieve equivalent behavior to route, but a source NAT action will be performed first. Typically, IP address space used by RAP clients will be an internal address that is routable through the IPsec tunnel, so src-nat is most often the directive used. The full configuration of a RAP is beyond the scope of this document, but is described in the ArubaOS User Guide in the Understanding Split Tunneling section. The following sample firewall policy, when applied to a RAP s user traffic, could be used to show how the RAP can deny SSH traffic, protect FTP traffic, and bypass HTTP traffic. All other traffic will be dropped. Adjust this policy for your own needs. (config) #ip access-list session rap-policy (config-sess-rap-policy)#any any svc-ssh deny (config-sess-rap-policy)#any any svc-ftp permit (config-sess-rap-policy)#any any svc-http src-nat (config-sess-rap-policy)#any any any deny The following sample configuration shows how to place a RAP into split-tunnel mode for wired traffic coming into a RAP through one of the local Ethernet ports, and apply the firewall rule above: (config) #user-role RAP_SPD (config-role) #session-acl rap-policy (config) #aaa profile AAA_RAP_wired (AAA Profile "AAA_RAP_wired") #initial-role RAP_SPD (config) #ap wired-ap-profile RAP_Wired_AP (Wired AP profile "RAP_Wired_AP") #forward-mode split-tunnel 4

5 (config) #ap wired-port-profile Wired_Port_RAP (AP wired port profile "Wired_Port_RAP") #wired-ap-profile RAP_Wired_AP (AP wired port profile "Wired_Port_RAP") #aaa-profile AAA_RAP_wired To place a RAP into split-tunnel mode for Wi-Fi traffic, configure the forwarding mode for the Virtual AP. Then apply the appropriate firewall rule to Wi-Fi userss. (config) #user-role RAP_SPD (config-role) #session-acl rap-policy (config) #wlan virtual-ap <profile_name> (Virtual AP <profile name> ) #forward-mode split-tunnel (config) #aaa profile AAA_RAP_WiFi (AAA Profile "AAA_RAP_WiFi") #dot1x-default-role RAP_SPD FCS_IPSEC_EXT.1.2 Only tunnel mode is supported. No configuration is required to enable tunnel mode. FCS_IPSEC_EXT.1.3 No additional configuration required. The firewall policy above includes an explicit any any any deny statement at the end, but the effect would be the same if this final rule were omitted. FCS_IPSEC_EXT.1.4 The selection of IPsec cryptographic algorithms is pre-programmed according to the following rules. 1. The default ESP algorithm is AES-CBC-256 with HMAC-SHA1. This corresponds to the controller s configuration where crypto ipsec transform-set default-rap-transform esp-aes256 esp-sha-hmac is found in the configuration file. This statement configures the gateway side of the connection so that it can establish connections with the RAP. Do not change this configuration; the RAP does not support AES-CBC If an ECDSA p256 certificate has been loaded on the RAP, it will use AES-GCM-128. See Appendix B for instructions on certificate loading. 3. If an ECDSA p384 certificate has been loaded on the RAP, it will use AES-GCM-256. See Appendix B for instructions on certificate loading. FCS_IPSEC_EXT.1.5 Only IKEv2 will be included in the Common Criteria evaluated configuration. IKEv1 is only enabled when pre-shared keys are configured for authentication. Because this functionality is not part of the evaluated configuration, do not configure the RAP to use pre-shared keys. As an additional measure of protection, all IKEv1 policies may be disabled on the mobility controller. To disable IKEv1 policies, identify each policy to be disabled using show crypto isakmp policy. Then use the following pattern: (config) #crypto isakmp policy <number> 5

6 (config-isakmp)# disable NAT-T is supported by default; no additional configuration is required to enable. FCS_IPSEC_EXT.1.6 Similar to FCS_IPSEC_EXT.1.4, the IKE ciphersuites are not directly configurable. Instead, they operate according to the following rules: 1. The default IKE ciphersuite uses AES-CBC If the factory-default RAP IKE policy (10004) has been disabled and the RAP s connection attempt is rejected, it will retry the connection using AES-CBC-128. To disable IKE policy 1004: (config) #crypto isakmp policy (config-isakmp)# disable Note that if IKE policy has been disabled, another suitable policy should be created. The ArubaOS User Guide, or the Common Criteria Configuration Guidance for the VPN Gateway Extended Package, provides details on configuring IKE policies. FCS_IPSEC_EXT.1.7 IKEv1 is not included in the evaluated configuration. FCS_IPSEC_EXT.1.8 All SA lifetime values are hardcoded on the RAP. To change default values, configure the mobility controller s lifetime values. Between the RAP and the mobility controller, whichever lifetime value is shorter will be the lifetime value that takes effect. FCS_IPSEC_EXT.1.9, FCS_IPSEC_EXT.1.10 No additional configuration required. FCS_IPSEC_EXT_1.11 When operating in FIPS mode, the default DH group is group 14. This cannot be configured directly. If an ECDSA p256 certificate is loaded on the RAP, however, it will use DH group 19. If an ECDSA p384 certificate is loaded on the RAP, it will use DH group 20. FCS_IPSEC_EXT.1.12 When using the factory-installed certificate for authentication, RSA with a key size of 2048 bits will be used. If an ECDSA certificate is loaded on the RAP, ECDSA will be used for authentication. See Appendix B for instructions on loading administrator-generated certificates. The RAP will use an 6

7 administrator-generated certificate if one has been loaded otherwise, the factory-installed certificate will be used. Only a single administrator-generated certificate may be loaded at one time. Pre-shared keys are only supported using IKEv1; IKEv1 was not included in the evaluated configuration. The Protection Profile requires that the operational guidance specify how to configure the TOE to connect to a trusted CA. The distributed nature of PKI is such that no connection to a trusted CA need be established; indeed, the trusted CA may be completely offline and unavailable. Administratorgenerated certificates are not downloaded to the RAP from the CA they must be loaded by an administrator according to Appendix B, or placed on removable USB storage according to Appendix C. The trusted CA certificate itself is loaded at the same time an administrator-generated certificate is loaded (as described in Appendix B). If no trusted CA certificate is loaded, only the Aruba factory CA will be trusted. Once a trusted CA certificate is loaded, the Aruba factory CA is no longer trusted. The RAP supports OCSP for certificate revocation checking. Revocation checking is automatic and needs no configuration. If an AIA field appears in the server certificate and contains an OCSP URL, the RAP will check revocation status using that URL. If the server certificate does not contain an AIA field with an OCSP URL, the RAP will not check revocation status for the server certificate. Because revocation checking is mandatory in the evaluated configuration, certificates that contain an AIA field with an OCSP URL *must* be used. Static CRLs are not supported for revocation checking. See the guidance for FIA_X509_EXT.2.2 for configuration required to instruct the RAP how to handle an OCSP revocation request for which no response is received. FCS_IPSEC_EXT.1.13 To configure the peer DN, provision the value to the RAP: (config) #provision-ap (AP provisioning) #cert-dn CN= The appropriate AP or group of APs must then be selected and the provisioning values pushed by using the reprovision command. This is not a complete provisioning profile; see the ArubaOS User Guide for full information on how to use provision-ap, or use the WebUI by navigating to Configuration->AP Installation. FCS_IPSEC_EXT.1.14 No additional configuration required. Follow guidance in the VPN Gateway Extension Profile configuration guidance to ensure an error condition does not result. FCS_RBG_EXT No additional configuration required beyond putting the RAP into FIPS mode. FDP_RIP.2 No configuration required. 7

8 FIA_X509_EXT.1.1 The RAP performs OCSP checking by first inspecting the AIA field of each certificate in a chain to learn the OCSP responder URL. The RAP expects the OCSP responder to be reachable outside the VPN tunnel, since the server certificate must be validated prior to an IPsec connection being established. No configuration is required to enable OCSP it is enabled by default and will be performed if the AIA field contains an OCSP responder URL. If the server certificate does not contain an AIA field with an OCSP responder URL, the RAP will not perform revocation checking. Because the protection profile requires checking of certificate revocation, the server certificate must contain an AIA field with an OCSP URL. Static CRLs are not supported for revocation checking. No configuration is required to enable a protected communication path with the OCSP responder digitally signed responses are built into the OCSP protocol. No configuration is required for the RAP to check the basicconstraints extension or the CA flag in a certificate. This is default behavior. FIA_X509_EXT.1.2 No configuration required. FIA_X509_EXT.2.1 No configuration required. FIA_X509_EXT.2.2 If the RAP fails to obtain a response from an OCSP responder, the administrator may choose whether to treat the certificate as valid or revoked. This action will be provisioned on the AP from the mobility controller. During testing of ArubaOS FIPS, it was noted that this setting had no effect and that certificates would always be treated as though they were revoked ( deny behavior) when an OCSP response was not received. This is a defect and will be addressed in a future software release. To configure the behavior: (config) #provision-ap (AP provisioning) #ocsp-default? <ocsp-default> ocsp_default is [0:OCSP_ACCEPT 1:OCSP_DENY] (3200-fips) (AP provisioning) #ocsp-default 0 The appropriate AP or group of APs must then be selected and the provisioning values pushed by using the reprovision command. This is not a complete provisioning profile; see the ArubaOS User Guide for full information on how to use provision-ap, or use the WebUI by navigating to Configuration->AP Installation. FIA_X509_EXT.2.3 No configuration required. 8

9 FPT_TST_EXT.1 No configuration is required beyond placing the RAP into FIPS mode. FPT_TUD_EXT.1 To query the current version of software running on the RAP, issue the show version command on the mobility controller. RAPs cannot run a different version of software than that running on the mobility controller they must always be identical or the RAP will not provide end-user services. If a RAP establishes an IPsec tunnel with a mobility controller and determines that it is running a different version of software, a software update will immediately be forced. Once the software update is downloaded, the RAP will reboot automatically and then re-establish the connection. To verify the version of software running on the RAP, issue the command show ap image version ap-name <name> on the mobility controller this will query the AP s software version. If a user has access to the RAP Console interface (described in Appendix B), the Local Debugging tab will also display the software version. To initiate a software update to the RAP, update the software on the mobility controller using the copy command (see the ArubaOS User Guide for full details) to copy software from a TFTP or FTP server. The software image is obtained from by an administrator, and then copied to the mobility controller. The mobility controller will verify the digital signature of the software image before writing it to flash. The ArubaOS software image is signed using a certificate installed on one of Aruba s code signing servers. The certificate is included in the software image. The root CA certificate, used to verify the code signing certificate, is built into the ArubaOS image already running on the mobility controller, and is also stored in the mobility controller s CPU in read-only memory. The same root CA certificate is stored in the RAP s boot flash. The software image loaded to the mobility controller contains images for all supported RAP models, and the mobility controller will store these internally. After rebooting the mobility controller, RAPs will reconnect to the mobility controller and download a new software image automatically. A new software image may be pushed proactively to the RAP using the ap image-preload command from the mobility controller, but that software version will not become active until the mobility controller is rebooted. The RAP verifies the digital signature of all software updates automatically, and will refuse to store or boot a software image that fails this check. The digital signature check is made by the RAP upon downloading of a new software image from the mobility controller, and is based on RSA 2048 and SHA- 256 FTP_ITC.1 No configuration required. 9

10 APPENDIX A: CONVERT IAP TO RAP To convert an Instant AP (IAP) to a Remote AP (RAP), perform the following steps: 1. Apply power to the RAP and wait for the WLAN LEDs to be lit. 2. Connect to the Instant SSID. 3. Bring up a browser and enter the following URL: 4. Log in with the default username/password: admin/admin 5. On the right hand corner, click on Maintenance Convert 6. Select Remote APs managed by a Mobility Controller and enter the IP address of the Controller. (Note that the RAP must have connectivity to the Controller). 7. Click on Convert Now button. 8. The AP may take some time to establish a connection, depending on whether or not a software upgrade is required. The browser may display a message about the AP being unreachable it is safe to close the browser at this point. The conversion process will overwrite the IAP software on one partition of the RAP s flash memory, and replace it with the same version of ArubaOS that has been installed on the mobility controller (ArubaOS FIPS for this evaluation.) IAP software remains on the second partition; resetting the RAP to factory defaults (by holding down the reset button for ten seconds while connecting the RAP to power) will restore the IAP software. Once the software update is downloaded, the RAP will reboot automatically and then re-establish the connection. To verify the version of software running on the RAP, issue the command show ap image version ap-name <name> on the mobility controller this will query the AP s software version. If a user has access to the RAP Console interface (described in Appendix B), the Local Debugging tab will also display the software version. 10

11 APPENDIX B: RAP CERTIFICATE LOADING PROCEDURE PURPOSE This Appendix describes how to provision Remote APs (RAPs) with custom, administrator-generated X.509 certificates, to be used instead of factory-installed certificates. Custom certificates are loaded through a local Ethernet port on the RAP, by connecting to an embedded web server using a standard browser. This web-based interface is known as RAP Console. The RAP must be specially configured to enable access to the RAP Console this is done by configuring one of the RAP Ethernet ports into bridge mode, which allows the RAP itself to process IP packets rather than forwarding them to the mobility controller. Aruba recommends doing this by creating a special AP group used only for RAP provisioning. After a RAP has been provisioned with administrator-generated certificates, move the RAP back to the standard AP group to prevent end users from accessing the RAP Console. The examples in this section show a custom ECDSA certificate being loaded. Custom RSA2048 certificates may also be loaded. INITIAL CONTROLLER SETUP The procedures in this section should be run once, and will prepare the mobility controller to connect RAPs for certificate provisioning. 1. Load trusted CA and server certificates into the mobility controller. The trusted CA certificate will be used to validate certificates presented by RAPs and other VPN clients. The server certificate will be presented to RAPs and other VPN clients during IKEv2 authentication. Note that even if EAP-TLS over IKEv2 will ultimately be used for IKE authentication, the mobility controller must still have a valid server certificate. Note: The source of many IKE authentication problems can be traced to loading of a certificate from a multi-level PKI without including the full certificate chain. Aruba devices will not build a certificate chain from installed intermediate CA certificates a certificate file, when loaded, must contain the leaf certificate and all intermediate certificates needed to reach the trusted root CA. The certificate file can be in PEM format with multiple BEGIN CERTIFICATE entries, or it can be a PKCS#7/.p7b bundle. PKCS#12/PFX files, password protected and with an included private key, are also supported and may contain a complete certificate chain. Certificates are loaded into a mobility controller through the WebUI by navigating to Configuration- >Certificates->Upload. 11

12 2. Configure basic mobility controller settings for RAP support: Address Pools, IKE Server Certificate, and CA Certificate. This step configures the controller to use the certificates loaded in step 1 for IKE. Note: The Inner IP need not be routable address space. These IP addresses will be assigned to RAP s IPsec tunnel interface. (config) #ip local pool "pool" (config) #crypto-local isakmp ca-certificate "root-ca" (config) #crypto-local isakmp server-certificate server-cert 3. Define a firewall policy named RAP_Custom_Cert_Provision to use when provisioning RAPs. (config) #ip access-list session RAP_Custom_Cert_Provision (config-sess-rap_custom_cert_provision)#any any any permit This policy, when applied to a RAP s local interface, will permit a locally-attached client to communicate with the RAP (and any other destination). Note that this policy is only used for RAP provisioning. 3. Create a new user role called RAP_Custom_Role to use when provisioning RAPs. Add the RAP_Custom_Cert_Provision firewall policy created above to this role. There will be two other policies called global-sacl and apprf-rap_custom_role-sacl that are automatically applied to this role, as part of the global policy. These will cause no problem. (config) #user-role RAP_Cert_Provisioning_Role (config-role) #session-acl RAP_Custom_Cert_Provision 4. Create an authentication profile for RAP provisioning called AAA_RAP_Custom_Cert. Select the RAP_Custom_Role role defined above for the Initial Role. (config) #aaa profile AAA_RAP_Cert_Provision (AAA Profile "AAA_RAP_Cert_Provision") #initial-role RAP_Cert_Provisioning_Role 5. Define and enable a Wired AP profile for RAPs named WiredAP_RAP_Provision. Set the forwarding mode to bridge. (config) #ap wired-ap-profile WiredAP_RAP_Provision (Wired AP profile "WiredAP_RAP_Provision") #forward-mode bridge (Wired AP profile "WiredAP_RAP_Provision") #wired-ap-enable Verify that the profile is created correctly: #show ap wired-ap-profile WiredAP_RAP_Provision Wired AP profile "WiredAP_RAP_Provision" Parameter Value Wired AP enable Enabled Trusted Not Trusted 12

13 Forward mode Switchport mode Access mode VLAN 1 Trunk mode native VLAN 1 bridge access Trunk mode allowed VLANs Broadcast Broadcast 6. Define an AP wired port profile, to map the wired AP profile and the AAA profile to a port profile: (config) #ap wired-port-profile Wired_Port_RAP_Provision (AP wired port profile "Wired_Port_RAP_Provision") #wired-ap-profile WiredAP_RAP_Provision (AP wired port profile "Wired_Port_RAP_Provision") #aaa-profile AAA_RAP_Cert_Provision Verify that the profile is created correctly: #show ap wired-port-profile Wired_Port_RAP_Provision AP wired port profile "Wired_Port_RAP_Provision" Parameter Value Wired AP profile WiredAP_RAP_Provision Ethernet interface link profile default AP LLDP profile default Shut down No Remote-AP Backup Enabled AAA Profile AAA_RAP_Cert_Provision Bridge Role N/A Time to wait for authentication to succeed 20 sec Spanning Tree Disabled 7. Finally, apply the wired port profile to a physical Ethernet port within a new AP group. Port enet0 is normally used as the uplink on a RAP (to connect back to the controller) so these instructions will use port enet1 as the provisioning port. First, create the new AP group. Then, apply the profile created in the previous step to port enet1. (config) #ap-group RAP_Provision (AP group "RAP_Provision") #enet1-port-profile Wired_Port_RAP_Provision RAP PROVISIONING Repeat this procedure for each RAP to be provisioned. 1. Ensure the RAP is listed in the AP whitelist, by issuing the command show whitelist-db rap. If the MAC address of the RAP is not in the whitelist, add it: #whitelist-db rap add mac-address <mac-address> ap-group RAP_Provision 2. Connect the RAP s E0 port to a network that a) contains a DHCP server, and b) has IP connectivity to the mobility controller through a router or NAT device (connecting the RAP to a network that is L2-connected 13

14 to a mobility controller will cause it to boot up as a campus AP, which would change the instructions given in this document.) Establish initial connection by converting the AP to RAP mode as shown in Appendix A. Once the AP has come up, verify it by running show ap active. It may take some time for a RAP to establish connectivity, depending on whether it needs to perform a software update. 3. The RAP may already be in the RAP_Provision group if so, it will be indicated in the output of show ap active. If the RAP is already in this group, skip this step. If the RAP is not in the RAP_Provision group already, the next step is to move the RAP temporarily into that group. This is most easily done through the WebUI, by navigating to Configuration AP Installation. Select the correct RAP and click the Provision button. Change the AP Group as shown in the screenshot below, then scroll to the bottom of the screen and click Apply and Reboot. The RAP will reboot, reconnect to the controller, and upon establishing a new connection will receive the configuration parameters created above. Verify by running show ap active. 4. Once the RAP has established a connection to the controller, connect a standard browser-equipped workstation to port E1 on the RAP. The workstation will receive an IP address on the same network where the RAP s E0 port is connected this is because port E1 was configured in bridge mode in the previous section. Additionally, the any any any permit firewall rule that has been applied will permit all traffic to flow from the workstation, through the RAP, to the external network. 5. Bring up a browser and type into the browser bar: The RAP is preprogrammed to intercept DNS requests for this hostname and return its own IP address. Click on the Certificates tab to perform all certificate management operations. 14

15 6. Upload a trusted CA certificate by clicking Choose file and selecting the trusted CA certificate file (PEM format is recommended although DER format is supported). Select the file type as CA certificate, then click Upload. The Custom CA Certificate display will indicate that a CA certificate has been successfully uploaded. 15

16 7. The next step depends on how the RAP s local certificate is to be created: a. If you have generated a certificate and private key external to the RAP, and have that certificate/key combination in a PKCS#12/PFX file, import it by selecting the file type as PKCS12 bundle and supplying the PKCS#12 password. The RAP will import both the certificate and the private key, and the Custom RAP Certificate field will turn green to indicate that a certificate and private key have been found. b. If the RAP will generate a CSR for fulfillment by a certificate authority, fill out the information at the bottom of the screen beginning with Country Code, and then click on Generate CSR. Only the parameters prompted on the screen can be populated into the CSR. You cannot specify the Common Name field the RAP will supply its own MAC address for this field. Your CA *cannot* alter the Common Name field in the resulting certificate, or the RAP will be unable to use the certificate. Note that the CSR may be saved to local flash (in which case a Save CSR link will become available allowing you to download the CSR to your workstation) or it may be saved to a USB flash drive if one has been inserted into the RAP s USB port. 16

17 c. If you have previously generated a CSR and are now coming back to install the issued certificate, use the Choose file button to select the file. Set the File Type drop-down to RAP Certificate and click Upload. The Custom RAP Certificate field will turn green to indicate that the RAP has installed the uploaded certificate and matched it to an existing private key that it previously stored. Note: If the certificate comes from a multi-level PKI (i.e. is issued by an intermediate CA), the entire certificate chain needed to get from the leaf certificate up to the trusted root CA must be loaded into the RAP. At the time of this writing (6.5.1 software), the RAP (unlike the controller) cannot import a leaf certificate plus multiple intermediate certificates from a single PEM file. There are three workarounds: 1. Generate the entire certificate+private key combination externally using OpenSSL, save as a password-protected PKCS#12 file with all intermediate certificates included, and upload this file to the RAP. Intermediate certificates will be properly imported this way. 2. As in option 1, create a PKCS#12 file but store it on a USB flash drive as explained in Appendix C. 3. Load the intermediate CA that issues the RAP leaf certificate onto the controller as a trusted CA, and add it to the list of trusted CAs for IKE/IPsec. With this configuration, the RAP need only transmit its own leaf certificate, rather than an entire certificate chain. 8. The Certificates tab contains two other parameters ServerCert CN and OCSP Config: These are described earlier in this document under FCS_IPSEC_EXT.1.13 and FIA_X509_EXT.2.2, respectively. The RAP Console interface provides an alternate way to configure these parameters. 9. Reboot the RAP (under Connectivity tab or unplug the power) and it should now reconnect to the controller using the custom certificate that has been installed. Verify that the RAP is connected to the controller and authenticating with a custom certificate by issuing the show ap active command and examining the Flags column. A RAP using a custom certificate will indicate the u flag. 17

18 (Aruba7010) #show ap active Active AP Table Name Group IP Address 11g Clients 11g Ch/EIRP/MaxEIRP 11a Clients 11a Ch/EIRP/MaxEIRP AP Type Flags Uptime Outer IP RAP-155:84:78 Enterprise-WLAN AP:HT:11/12/ AP:HT:157+/23/23 RAP-155P RE2ua 10m:29s Flags: 1 = 802.1x authenticated AP; 2 = Using IKE version 2; A = Enet1 in active/standby mode; B = Battery Boost On; C = Cellular; D = Disconn. Extra Calls On; E = Wired AP enabled; F = AP failed 802.1x authentication; H = Hotspot Enabled; K = K Enabled; L = Client Balancing Enabled; M = Mesh; N = b protection disabled; P = PPPOE; R = Remote AP; S = AP connected as standby; X = Maintenance Mode; a = Reduce ARP packets in the air; d = Drop Mcast/Bcast On; u = Custom-Cert RAP; r = r Enabled REPROVISION RAP TO FINAL AP GROUP Now that the RAP has been provisioned with a custom certificate, it should be moved back to the correct AP group so that the local Ethernet port is no longer in bridge mode. It is easiest to do this through the WebUI by navigating to Configuration AP Installation. Select the correct RAP and click the Provision button. Change the AP Group from RAP_Provision to the correct operational AP group, then scroll to the bottom of the screen and click Apply and Reboot. The RAP will reboot and reconnect to the controller. Verify that the RAP is now in the correct group by running show ap active. 18

19 APPENDIX C: CREDENTIALS ON REMOVABLE USB STORAGE The procedure described in Appendix B will store a certificate and private key within the flash memory of the RAP. However, this means that the RAP must be protected against an adversary gaining physical control of the device, and thus having the ability to extract and copy the private key. As an alternative option, the certificate and private key may be stored on removable USB storage. The following rules apply: 1. A trusted CA certificate must still be installed on the RAP, as documented in Appendix B. This certificate allows the RAP to validate the certificate presented by the mobility controller. 2. The certificate and private key must be stored in a PFX/PKCS#12 file, and protected with a password. At the time of this writing, certificates generated through OpenSSL and related technologies have been found to function the best; problems have been found with certificate bundles created by Microsoft ADCS (tracked by ArubaOS bug ). 3. The PKCS#12 file must be named according to the MAC address of the RAP, and is casesensitive. For example, if the MAC address of the RAP is 00:0B:86:66:04:A2, the filename should be 000B866604A2.p12 (MAC address in capital letters, extension in lowercase.) 4. Some users have reported difficulties with different filesystems on the USB flash drives. FAT32 format is supported, but some users have reported that certain USB flash drives would only work with the RAP when formatted as NTFS. This issue is still under investigation. 5. If the RAP has an active IPsec tunnel to the controller and the USB flash drive is removed, the RAP will drop the IPsec tunnel. 6. The RAP must be provisioned to read its certificate and key from USB. To do this, navigate to Configuration->AP Installation in the controller WebUI. Select the correct RAP and click the Provision button. Provide the PKCS#12 password in the PKCS12 Passphrase field. Then, under the USB Settings group, set the Device Type to storage. Scroll to the bottom of the screen and click Apply and Reboot. The RAP will reboot and reconnect to the controller after finding its certificate and private key on a USB drive. 19

20 1344 CROSSMAN AVE SUNNYVALE, CA ARUBA T: FAX: