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



    > It would be impossible to make a stable boot image that depended on revision
    > 1 of a protocol about to hit the market.  As such, it is misguided to
    > consider using DHCP options to allow direct booting of iSCSI.  Once security
    > is considered, it becomes even more obvious that a two step process is
    > required to allow needed flexibility and manageability.  Once a management
    > scheme is selected that is suitable for an enterprise deployment, LDAP or
    > commercial equivalents are a good candidate.  Attempting to place this
    > management function on the iSCSI server complicates iSCSI and ensures no
    > common method of promulgating management.  In this respect, I differ from
    > the opinion of David Black.  David likes to construe an LDAP server as too
    > difficult and wishes to fulfill this management need with various other
    > inventions.
    
    While we have been using DHCP as the example of how hard it is to
    securely boot over a network, switching to LDAP does nothing to
    make it easier.  Every initiator still needs to have a key stored
    securely in nonvolitile memory and mechanisms to initially
    create the key as well as update or revoke it. LDAP doesn't
    solve this problem.
    
    > This second step could depend fully on TFTP and a DUA for LDAP.  This second
    > layer should divorce itself from iSCSI other than to establish an
    > environment suitable for individualized booting using iSCSI.  This seems
    > quite possible to implement and to promote as a reference implementation
    > once a schema is defined for LDAP.  It would not require changes to existing
    > system efforts but instead build upon them.  The goal would be to provide a
    > single simple boot that would *not* require change and yet allow the passing
    > of variables and images required for the evolution of iSCSI.  Just this
    > initial boot would be accommodated by the DHCP, TFTP, and booting system.
    > DHCP already provides a significant amount of flexibility.
    
    Regardless of if you used TFTP, DHCP, or LDAP as the secondary boot
    platform, it must be one that can be trusted and the trust must
    come from the physical hardware and not over a network.  They]
    same key management issues still exist.
    
    > > b. Whether *per-interface* credentials are needed (e.g. authenticated DHCP
    > > draft -16), or *per-machine*. Per-interface credentials require the
    > > machine to be touched every time an interface is added or removed, not
    > > just when the machine is shipped by the OEM.
    > 
    > LDAP could provide the needed database required to provide the correct
    > images in a highly flexible manner.  As this type of server is often a
    > critical server in an enterprise environment, it seems like a very safe
    > choice.  Julian's concern about not understanding this environment should
    > encourage the use of existing schemes rather than reinventing new ones.
    > Think of booting as a minimum of a two step process.  A simple secure image
    > coupled with information from a secure LDAP server to then obtain then next
    > step.  The only code that would need to be learned would be the DUA, and
    > TFTP.
    
    But the problem is that no matter how secure the LDAP server is,
    the client must be secure or all bets are off.  The only way to make
    the client secure is to have some form of credential on the client
    before any network traffic is initiated.  Bernard was simply describing
    that having a per-machine credential won't scale and the proposal
    to have a per-interface credential will have orders of magnitude
    worse scaling.  Again LDAP can't be used to manage this as the
    credential
    must be on the client *before* it issues any requests.
    
    	-David
    


Home

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