SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI and secure boot



    > As iSCSI is transporting SCSI and SCSI has a different boot paradigm than
    > Netboot can you please elaborate on what exactly should be an authenticated
    > boot image in this (SCSI) context.
    > 
    > Please take into consideration that unlike netboot - the SCSI boot is not a
    > clearly bounded process (not even in PXE - an "open" proprietary scheme).
    > 
    I'm no PXE expert, but here is my (admittedly limited) understanding of
    what goes on:
    
    1. Many OEMs ship PXE-enabled PCs, and in most of these PXE cannot be
    turned off, though it can be set lower in the boot order. In some
    percentage of machines PXE will even be higher in the boot order than the
    hard disk (bad idea, for reasons I'll describe). 
    
    2. Machine boots and if it reaches PXE in the boot order, it sends a
    DHCPDISCOVER. If responded to with a DHCPOFFER including Option 60
    ("PXECLIENT") and TFTP server, it will finish obtaining an address via 
    DHCP and then pull a boot image from the TFTP server. This is typically
    startrom.com, a 16-bit executable. Note that this is often *not* a full OS
    image; for example Ghost supports PXE and uses this early load in order to
    reformat the hard disk and start the download of the new "cloned" disk
    image. Other PXE supporting-apps may do other things with this early boot
    image. 
    
    3. If the machine is PXE 2.0 enabled, it will support signed boot images,
    and will check the integrity of the boot image prior to executing it. This
    part of the spec is called BIS -- and requires the public key of the boot
    image signer to be pre-loaded on the PC. My understanding is that PXE 2.0
    and BIS are not widely implemented and as a result, PXE 1.0 systems
    are most widespread and they execute whatever boot image they are 
    fed. This is one reason why putting PXE high in the boot order is a bad
    idea. This would enable a rogue ghost server to reformat your hard
    drive. Ouch! (this happens in real life, unfortunately). 
    
    4. PXE 2.0 does not support authenticated DHCP nor any TFTP security, so
    that it is vulnerable to rogue DHCP servers, offers no support for client
    authentication, and only checks the integrity of the boot image once it
    has completed the download of it. However, since it also requires
    pre-loading the boot image signing cert on the PC, and doesn't support
    revocation of invalidated boot images (which can be endlessly replayed),
    in practice PXE 2.0 is  not widely deployed and doesn't do a good job in
    boot image validation.  
    
    5. The small startrom.com loader is then used to pull down a more complete
    OS image, either installing it on the hard drive, or pulling it into
    memory. At this point, for example, you may have the appropriate drivers
    loaded, be operating in 32-bit mode, etc. 
    
    As far as how iSCSI fits in to all this, I'd hope you would enlighten me
    ;) As has been suggested, the iSCSI target address could be obtained via
    DHCP, and suitable initial iSCSI drivers provided via the initial boot
    load obtained via TFTP. 
    
    Given the security headaches inherent in PXE, I am really interested in
    how all of this could be done in a deployable, secure manner. The picture
    is somewhat confusing today, and the following questions come to mind:
    
    a. What credentials are needed to secure iSCSI boot?
    	1. Kerberos machine credentials?
    	2. Identity/shared keys for IPSEC? 
    b. What credentials are needed to secure DHCP?
    	1. According to -16, you need the authenticated DHCP key
               (unique per htype/MAC address)
            2. According to draft-hornstein-dhc-kerbauth-0x.txt you
               need Kerb credentials.
            3. Do we care? (see below)
    c. What credentials are needed to verify the boot image?
    	1. The boot image signing certificate (BIS)
            2. Something else? (Shared secret, Kerb credentials?)
    
    Storing several identities and credential sets in PC NVRAM is difficult to
    administer and deploy. It makes sense to boil this mess down
    to a small list of items. But how?
    
    Some thoughts:
    
    * Kerberos clients are small, and I am told, romable. Might it not make
      sense to use Kerberos to secure PXE?  Could we kill multiple birds
      (iSCSI security, 802.1X, NFS, TFTP, boot image security) by doing this?
    
    * Do we really need DHCP authentication for secure boot? Interface-specific 
      authentication credentials strike me as painful to maintain, plus it
      requires substantial administration. 
    
    


Home

Last updated: Tue Sep 04 01:04:35 2001
6315 messages in chronological order