iSCSI Boot in a Zero Trust Environment

ID 659770
Updated 5/6/2020
Version Latest



Network boot is commonly used for everything from booting thin clients to using IT automation for bare-metal provisioning. Unfortunately, most network boot infrastructure is based on outdated standards encryption or authentication. This presents an issue when implementing a Zero Trust architecture, where security principles need to be implemented within the network perimeter. In the case of iSCSI Boot, Intel recommends migrating iSCSI Boot to HTTP(S) included with Unified Extensible Firmware Interface (UEFI). 

Some network boot deployments are based on the iSCSI protocol, originally defined by RFC 3720 in 2004. iSCSI Boot (RFC 4173) allows a client to boot from a disk image exposed on a LAN network using iSCSI TCP connections. The iSCSI boot architecture is based on the 16-bit Basic Input/Output System (BIOS), and requires either a 16-bit legacy iSCSI boot Option ROM, or a Universal Network Device Interface (UNDI) format Option ROM. iSCSI Boot works around limitations of 16-bit BIOS architecture by relying on simple TCP network connections to emulate a locally attached disk to the host via legacy Int13h BIOS calls. 

As network technology has improved, the security limitations of the iSCSI ecosystem are more apparent. iSCSI RFC 7146 and RFC 3720 provides several methods for enhanced encryption or authentication using IPSec, However, the restricted 16-bit execution environment generally prevented implementation of IPSec protocol stacks. Furthermore, iSCSI Boot relies handing off established TCP sessions to the booted host operating system. However, no method exists to hand off established IPSec sessions established from a BIOS to the host OS, nor methods to pass sensitive iSCSI credentials in a protected manner. 

The UEFI Specification introduced HTTP(S) Boot in version 2.5. HTTP Boot combines the Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Hypertext Transfer Protocol (HTTP) to provide system deployment and configuration capabilities over the network. These capabilities build upon the existing UEFI TCP/IP network stack. Along with support for signed bootloaders with UEFI Secure Boot, Intel recommends migrating iSCSI boot to HTTP(S) included with UEFI. Using HTTP(S) as a transport addresses the security limitations of iSCSI boot, and deployable on today’s platforms using open source solutions.  

TianoCore, the open-source UEFI implementation, features a network stack with HTTP(S) Boot support that is integrated in most commercial platform firmware. Linux distributions like SUSE SLES 15 and openSUSE 42.3 can install from a host server via HTTP(S). These implementations leverage UNDI drivers already provided by network device manufacturers.  

Intel technologies may require enabled hardware, software or service activation.
No product or component can be absolutely secure.
Your costs and results may vary.