Local TLS Configuration with RPC-Go

Local TLS Configuration using RPC-Go is a Preview Feature

Local TLS Configuration using RPC-Go is a Preview Feature and is subject to change. This means it has not been fully validated and cannot be guaranteed to work. There are still potential bugs and tweaks needed for a production-level feature standard. Interested in this feature and helping us test it? Reach out via GitHub.

The TLS protocol includes the following types of authentication:

• Server Authentication – Only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated. This means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom they are communicating.

• Mutual Authentication – The next level of security in which both ends of the “conversation” are sure with whom they are communicating.

When Intel AMT is configured for mutual authentication, it validates incoming client certificates based on the root of trust configured.

Overview

AMT can be configured to use TLS without the need for a remote server (i.e. RPS). RPC-Go can directly communicate with Enterprise Assistant to perform the configuration.

The following steps highlight how to:

• Configure the connection of EA and RPC-Go
• Run TLS configuration using RPC-Go

Prerequisites

The following are requirements to configure and connect an AMT device using TLS.

• Enterprise Assistant
• RPC-Go

• Management Tool supporting TLS (ex: Meshcommander)

  This is not required for configuration and therefore not needed for this guide. However, a management tool will be needed if you want to manage the device post-configuration.

Services

The following services are assumed to be configured and running in your enterprise environment.

• Microsoft* Certificate Authority (CA)

  • An AMT TLS Certificate template is required. See TLS Certificate Template for additional steps on creating a template.

• Microsoft* Active Directory (AD)

Configure Enterprise Assistant

1. Run the Enterprise Assistant executable.

2. Open the File > Settings menu to configure the RPC-Go connection.

   

   Figure 1: Enterprise Assistant Settings Menu

3. Under RPC Client section, set a Username of your choice.

4. Set a Password of your choice.

5. Set an alpha-numeric Security Key of your choice. This key is used when generating JWT tokens for authentication between RPC-Go and EA communication.

6. The Device Name is the name used to configure the domain controller for each device account. Using Node Identifier is more secure due to the inability to be tampered with but is less friendly to maintain as a user.

7. Security Groups will list all of the security groups of the domain controller that have been created within the Computers group. When Enterprise Assistant creates a new Computer account (like a new AMT device), it will join the selected Security Groups.

8. Provide the Certificate Authority and click the checkmark.

9. It will then list the available Certificate Templates to choose from. This will let you select a template specifically created for AMT. See TLS Certificate Template for additional steps on creating a template.

10. Choose how to issue the certificate. Typically, SAM Account Name is most commonly used as the Common Name.

    Example - Configured Settings

    

    Figure 2: Enterprise Assistant RPC-Go Settings Example

11. Press OK to save the Settings.

    Success - HTTP Server Started

    

    Figure 3: HTTP Server Started Example

Configure the AMT Device

1. Open Command Prompt as Administrator.

2. Navigate to the directory with RPC-Go.

3. Run the rpc configure tls command. Replace the [bracketed] values with your own.

   rpc configure tls -mode [configurationMode] -password [AMTPassword] -eaAddress [IP-Address-or-FQDN] -eaUsername [myUsername] -eaPassword [myPassword]
   

   The toolkit offers four configuration modes to support various usage models:

   CONFIGURATION MODE	DESCRIPTION
   Server	The client authenticates the server request and accepts only those servers with a digital certificate.
   ServerAndNonTLS	Used primarily for testing. The client authenticates the server request and accepts legitimate digital certificates from TLS-enabled servers. However, if the server is not TLS-enabled, the client defaults to a CIRA connection.
   Mutual	Both client and server must have certs. The client cert is signed by the server cert.
   MutualAndNonTLS	Used primarily for testing. Both client and server certs are expected. The client authenticates the server request and accepts legitimate digital certificates from TLS-enabled servers. However, if the server is not TLS-enabled, the client defaults to a CIRA connection.

   Success - TLS Configured

   

   Figure 4: TLS Configured Example

4. Now, the device is manageable via a TLS connection using the management tool of your choice!