| July 1, 2008 10:09 AM PDT | |
Intel® Active Management Technology (Intel® AMT) has demonstrated the power of built-in manageability in the enterprise and small business desktop environment. Platforms based on Intel® vPro™ technology can be managed remotely as long as the platform is connected to a network and to AC power. But what happens in a mobile environment? The platform does not have a fixed location in the network; the network connection may be wireless; the power source may be a battery. How will Intel AMT perform in such an environment?
Power
Mobile platforms spend much of their time attached to AC power. At those times they are like other desktops. Intel AMT can operate even when the platform is powered down, and it can be configured to operate in a low power state until it is awakened due to an external stimulus from the network. When a mobile platform is operating on batteries (DC power) or even when the platform is asleep on battery power, it is essential to minimize DC power use, which means setting limits to Intel AMT activity on DC power.
Multiple Network Connections
A mobile platform, when docked, may have a wired LAN connection. It may also have a wireless LAN connection. Both of these connections can be active simultaneously or only one of them may be active. Manageability network traffic can be present on both of the network connections simultaneously.
Security in a Wireless Environment
Wireless traffic requires additional protection beyond that used on a standard wired LAN. Unauthorized platforms may attempt access to a wireless network, and wireless traffic is subject to interception by unauthorized platforms. To eliminate these problems:
- A wireless network access point must verify the identity of a device attempting to connect to it and validate that the device is authorized to connect to the network.
- The traffic must be protected from prying by unauthorized targets that can pick up the wireless transmission.
Intel AMT must be able to exchange manageability messages with a remote management console over a protected wireless LAN.
Working Inside and Outside the Enterprise
When a mobile platform is outside of the enterprise network and is connected to a foreign network (for example, at home, in an airport or hotel, or at a customer site), it cannot be managed by a management console inside the enterprise network. Intel AMT can be configured to reject manageability traffic outside of the enterprise network, in order to prevent unauthorized management consoles from attempting to access the device. Intel AMT must be able to detect if the platform is inside or outside the enterprise network. Tunneled manageability messages may still reach the platform, if the platform is configured to receive them.
Intel AMT Release 2.5 adds features to respond to these challenges. It adds the capability to:
- send and receive manageability traffic over a secured wireless LAN.
- apply System Defense filters to wireless traffic.
- support 802.1x authentication.
- support power profiles that are different for AC and DC power.
- detect whether the platform is inside or outside the enterprise network.
Support for Multiple Power Policies
As in Intel AMT Release 2.0/2.1, Release 2.5 supports configuration of the maximum Power State where Intel AMT will operate. The configuration options have been extended to support detection of AC (power cord) operation and DC (battery) operation. Intel AMT can now be configured to operate in Sx states with AC but not with DC. Power states are tied to power packages. The packages available on a particular platform are OEM specific and may vary from one implementation to the next, but certain packages are required on all vPro mobile platforms, as indicated in the table below. The following table lists the power packages included in Intel AMT Release 2.5. The Intel AMT firmware returns the descriptive strings when it is requested to enumerate the available power packages or to return the current active power package. “On in S0” indicates that the Intel® Management Engine (ME) and Intel AMT firmware are active when the host processor is active, even when the platform is on DC (battery) power. This is true for all packages when the platform is in S0. “ON in S0, S3/AC” indicates that the ME and Intel AMT are active when the host processor is in a sleep state (S3), as long as the platform is attached to AC power. Similarly, “ON in S0, S3/AC, S4-5/AC” says that the ME and Intel AMT are active even when the host is powered down, as long as there is AC power to the platform. The “WoL” (Wake on LAN) options indicate that when the host is asleep or off (depending on the package), the ME will “wake up” when the network interface detects and ARP or ICMP packet or a manageability message (a message addressed to one of the Intel AMT IANA ports). The ME will transition to a lower power state after a period of no activity. This period of time is configurable, but should be set to no less than three minutes in Linux environments. The default, and minimum, setting is two minutes.
Intel AMT Release 2.5 Power Packages
| Required/ Optional | Descriptive String |
| Required | Mobile: ON in S0 |
| Required | Mobile: ON in S0, S3/AC |
| Required | Mobile: ON in S0, S3/AC, S4-5/AC |
| Optional | Mobile: ON in S0; ME WoL in S3/AC |
| Optional | Mobile: ON in S0; ME WoL in S3/AC, S4-5/AC |
Wireless Manageability
A wireless connection on a mobile platform operates at two levels: the wireless network interface and the interface driver executing on the platform host. The network interface has to manage the RF communications connection.
If the user turns off the wireless transmitter/receiver using either a hardware or software switch, Intel AMT will not use the wireless interface under any condition until the user turns on the w
ireless transmitter/receiver.
Intel AMT can send and receive management traffic via the wireless LAN only when the platform in the S0 power state. If the power state permits it, a mobile platform can continue to send and receive out-of-band traffic when the platform is in an Sx state, but only via a wired LAN.
When a wireless connection is established on a host platform, it is based on a wireless profile that setup names, passwords and other security elements used to authenticate the platform to the wireless Access Point. The user or the IT organization defines one or more profiles using a tool such as Intel® PROSet/Wireless Software. Intel AMT must have a corresponding wireless profile to receive out-of-band traffic over the same wireless link. The network interface API allows defining one or more wireless profiles using the same parameters as the IntelPROSet/Wireless Software. On power-up of the host, Intel AMT communicates with the wireless LAN driver on the host. When the driver and Intel AMT find matching profiles, the driver will route traffic addressed to the Intel AMT device for manageability processing.
When there is a problem with the wireless driver and the host is still powered up (in an S0 power state only), Intel AMT can continue to receive out-of-band manageability traffic directly from the wireless network interface.
Intel AMT does not receive wireless traffic when the host is asleep or off. The Intel AMT device can still receive manageability traffic if there is a wired connection.
For Intel AMT to work with a wireless LAN, it must share IP addresses with the host. This requires the presence of a DHCP server to allocate IP addresses and Intel AMT configure to use DHCP. Configuring Intel AMT to use static IP address disables its connectivity to the wireless LAN.
Wireless Profile parameters
Wireless profiles include the following parameters:
- Profile name
- Profile priority
- Network Name (SSID)
- Security Settings
- Key Management approach: Wi-Fi Protected Access (WPA) or Robust secure Network (RSN)
- Encryption Algorithm: Temporal Key Integrity Protocol (TKIP) or Counter Mode CBC MAC Protocol (CCMP)
- Authentication: Passphrase or 802.1x profile
Intel AMT has a function that reports on the 802.11 protocol capability currently in use (802.11a, b, g, or n). The Intel AMT WebUI displays the results of this request.
A management console application needs to keep track of the Intel AMT devices under its control. The platform IP addresses (one per interface) and the fully-qualified domain name (FQDN) define the platform to the management console. The console application may perform IP discovery to locate all of the platforms containing Intel AMT. however, when a user takes a notebook computer from place to place within the enterprise, the FQDN remains the same, but the IP addresses may change as the user changes connections from one sub-net to another. The DHCP servers that issue IP addresses will register the platform to a DNS server, but an application looking for that platform using the FQDN may get an old IP address from a DNS cache.
There are two points to consider, then, when designing a m anagement console:
- The FQDN of a platform will remain static even the IP addresses may change. Therefore, it may be a more reliable identifier of the platform than the IP address.
- Cached DNS entries for mobile platforms may not be up-to-date.
Purging the DNS cache or shortening the time-to-live on DNS entries can reduce this problem.
Another approach is to configure Intel AMT to send an alert when the platform comes up. The console can use the source IP to do a reverse DNS look-up to relate the platform IP to its FQDN.
A third approach is to have a local agent inform the management console of any IP changes.
Detection Whether the Platform is Inside or Outside the Enterprise
An Intel AMT device can detect that its mobile platform is operating outside the enterprise network. When the platform is configured using the SetEnvironmentDetection command, a list of domain extensions define what is considered “inside the enterprise”. Depending on its configuration Intel AMT can block or limit network connectivity of the platform or block manageability traffic. The configuration may also support exchanging manageability traffic via a VPN back to the enterprise. When configuring environment detection options for operations outside the enterprise, IT can define a System Defense policy to limit network traffic.
Environment detection maintains a separate state for each network interface, so, for example, the wired LAN interface may be inside the enterprise, while the wireless connection may be outside the enterprise. The platform can still be managed as long as one interface is “inside the enterprise.” IT can apply a separate system Defense policy to each network interface and block traffic to the one outside the enterprise.
VPN Support
A VPN connection tunnels network traffic, encrypting it end-to-end, thus avoiding interception of the traffic anywhere along the path. When a VPN stream reaches the host platform, the platform drivers decrypt the stream and then process the packets within the stream. If the driver detects manageability traffic, defined as being addressed to the Intel AMT IP address and port, the driver channels the packet to the LMS, which listens for such packets, and sends them to the Intel AMT local interface using the Intel Management Engine Interface (MEI) driver. LMS detects that the source IP is not the host and marks the packets as “remote”. Intel AMT treats them as remote based on this marking, as if they were received from a network interface. Intel AMT accepts the VPN packets only if:
- VPN routing is enabled,
- DHCP is enabled,
- environment detection is enabled (see above), and
- Intel AMT detects that the platform is operating outside of the enterprise (i.e., the domain suffix of its current IP is not in the list of “inside the enterprise” domains).
Management consoles will have to detect the VPN IP using DNS.
802.1x Support
Intel AMT supports 802.1x with EAP over the wireless and wired network connections. It supports the following authentication schemes for wired connections:
- TLS
- TTLS MSCHAPv2
- PEAP MSCHAPv2
- EAP GTC
- EAPFAST MSCHAPv2 < li>EAPFAST GTC
Support for System Defense
Two System Defense network policies can be active at the same time, one for the wired network interface and one for the wireless network interface. When 802.1x is active, the number of available System Defense filters is reduced to 29.
User Notification of Intel AMT Events and Condition changes
Intel AMT Release 2.5 includes the User Notification Service (UNS), a Windows service installed on the host that registers with Intel AMT to receive alerts of s specific set of events. The UNS logs the events in the Window Application Event Log. The events include reports of System Defense policies being activated, start and stop of wireless management sessions and start and stop of redirection sessions. The UNS also is used to request posture data from Intel AMT and store it in the registry of the host. The NAC posture plug-in reads the stored value in response to NAC server requests.
Endpoint Access Control
Endpoint Access Control (EAC) is used to enforce security policies on all hosts on a network. Compliance systems such as Cisco’s NAC implement such policies. Intel AMT Release 2.5 complies with Cisco’s implementation by optionally issuing signed postures that report on the state of the platform as detected by the Intel AMT device. Intel AMT responds to posture requests either from the local interface or from the network interface.
Requests from the local interface
The following are the initial conditions for Intel AMT interaction with a Cisco NAC server. The host is configured to use EAP-FAST as an authentication protocol under 802.1x. A Cisco Trusted Agent (CTA) is installed on the host, and the Intel-supplied posture plug-in dll is stored in a directory where the CTA can find it. The UNS is configured to periodically request postures from Intel AMT and Intel AMT is configured to return a posture containing a report of the state of the Intel AMT device.
When the switch implementing the NAC protocol requests the CTA to return a posture, the CTA, via the posture plug-in, retrieves the last posture saved by the UNS. The CTA sends the posture to the Cisco server, which sends it to a posture validation server (PVS) to check that the posture is valid. The Intel AMT SDK contains a sample PVS. If the disposition of the PVS is positive, then platform network traffic will continue to flow through the switch, otherwise it may be limited or blocked.
Requests from the network
When the platform is in an Sx state (asleep or powered down), Intel AMT responds to posture requests directly. The requests and responses are in the framework of the EAP-FAST protocol selected when defining a wired 802.1x connection. The postures go directly to the Cisco server and from there to the PVS.
Certificate store
Because of the extended need for PKI certificates, the certificate store functionality has been extended. Security settings were expanded so that individual settings can be made for keys, certificates and TLS credentials. The following summarizes the capacity of the certificate store:
- CertChainMaxSize: 4100 bytes
- Supported Key Lengths (server side): 1024, 1536, 2048 bits
- Supported Key Lengths (mutually authenticated client): 1024, 1536, 2048 bit s
- TLS Support: Network or Local using Server Certificate or Mutual authentication.
TLS enablement applies to both interfaces - CRL Store Size (Maximum Root Certificate Size): 4100 bytes
- Maximum Root Certificate Size: 1500 bytes
- Maximum Root Certificate Instances: 4
- FqdnSuffixMaxEntries: 4
- FqdnSuffixMaxEntryLength: 50
For more complete information about compiler optimizations, see our Optimization Notice.
Holger Krapp