If you are concerned about securing communications on your internal network, here are a few items you should know. Be sure to share these insights with those you might not be concerned. This blog provides a few more insights beyond to the statement "Risks of not using TLS" found at http://communities.intel.com/docs/DOC-1989
Two key security risks should be considered in regards to Intel AMT network traffic:
- Risk of data exposure to an eavesdropper
- Risk of machine being hijacked by an eavesdropper
Key points to consider for these risks:
- Intel AMT authentication method used (i.e. Digest or Kerberos)
- Encryption of Intel AMT network traffice (i.e. no-TLS or TLS)
For a greater understanding on adding TLS to Intel AMT configuration in a Symantec\Altiris environment, see http://www.symantec.com/connect/articles/configuring-intel-amt-work-tls-encryption. Similar, for insights on configuring Intel AMT for Kerberos authentication, see http://www.symantec.com/connect/articles/part-1-configuring-ad-integration-and-kerberos-authentication-intel-vpro-technology
Focusing in on the risk of data exposure, if no encryption is used communications to Intel AMT are in the clear on the network. An eavesdropper can see data sent back and forth. The majority of the data will be Intel AMT messages over HTTP or WS-Management traffic. In addition to Intel AMT traffic, the eavesdropper will see other communications between the client and the infrastructure.
Side note: This assumes the eavesdropper has placed a network sniffer between the client and infrastructure connection AND that they know when to capture packets specific to Intel AMT. If the eavesdropper is capturing packets between the server and network infrastructure, they will likely be looking for more than Intel AMT related traffic.
To address the data exposure risk, use TLS with the Intel AMT configuration. The method of authentication (i.e. Digest or Kerberos) will not address the data exposure risk.
Focusing on the risk of hijacking requires a little more understanding of Intel AMT authentication. If Kerberos authentication is used, no username or password are sent on the network. Instead, Intel AMT authentication is handled via a Microsoft Kerberos sequence with the Intel AMT device acting as a network service. If Digest authentication is used, the majority of Intel AMT use cases require an MD5 digest authentication. In this scenarios, the username for authentication is sent in the clear but the password is a hashed nonce (i.e. hashed value calculated based on that specific session using among other items the password value known by server and client). The exception is redirection scenarios (i.e. IDE-Redirect and Serial-over-LAN). In these scenarios, if digest authentication is to be used the username and password are sent in the clear.
To help reinforce the above points, there are 3 images below of various network traces.
The first image shows a network capture of an MD5 Digest authentication to Intel AMT for a power-on event. Note that the username is seen, but the password is a nonce value. (which cannot be repeated\replayed)
The second image shows network capture with digest authentication during an IDE-Redirect session. Note that the username and password are in clear text.
The third image shows network capture with digest authentication and TLS enabled. What you see is the TLS session being established followed by garbled data due to the encryption.
The following chart may be a useful summary:
| Authentication \ Encryption |
TLS |
No TLS |
| Kerberos |
Data cannot be read. Machine cannot be hijacked |
Data can be read. Machine cannot be hijacked |
| Digest (Username/password) |
Data cannot be read. Machine cannot be hijacked |
Data can be read. Username can be captured.
If using redirection, password can also be captured.
|
In general, I take a "keep it simple" approach when testing and deploying technologies. Commonly the more security added, the more complex and latent (i.e. slow) the communications along with raising resource burdens on the server or requesting service.
Here are a few additional points to consider:
- If you are not planning to use Intel AMT redirection and want best performance, a Digest with no-TLS situation may be preferred.
- From a performance standpoint, a simple digest authentication with no-TLS (i.e. no encryption) will be the best situation.
- The longest latency will occur with TLS added to the Intel AMT configuration.
- Both Kerberos and TLS will require the FQDN of the Intel AMT device to be synchronized with the operating system hostname and correctly resolved within the infrastructure.
- Adding TLS configuration to Intel AMT will require an internal Certificate Authority with the root certificate applied to all systems accessing the Intel AMT device
- If you want to ensure that only certain management systems are able to communication with Intel AMT systems, a mutual TLS configuration is recommended (note: Although supported by Symantec\Altiris, this type of configuration is very rare. In addition, it may break some advanced situation such as Fast-Call-for-Help)
The links at the beginning of the article will provide more insights on how to configure Intel AMT with Kerberos and TLS. The data points provided should help guide decisions on what level of security will be needed individual situations.
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries