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



    
    
    Bernard,
    
    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).
    
    Julo
    
    Bernard Aboba <aboba@internaut.com> on 27-05-2001 19:22:47
    
    Please respond to Bernard Aboba <aboba@internaut.com>
    
    To:   Douglas Otis <dotis@sanlight.net>
    cc:   David Robinson <David.Robinson@EBay.Sun.COM>, ips@ece.cmu.edu,
          narten@raleigh.ibm.com
    Subject:  iSCSI and secure boot
    
    
    
    
    > Security is actively being worked on the the DHCP community so that
    > is something that iSCSI can leverage.
    > (draft-ietf-dhc-authentication-16.txt)
    
    Unfortunately, it's not clear to me that
    draft-ietf-dhc-authentication-16.txt is viable for use in securing the
    boot process without some additional work. As written, the draft assumes
    that the adapter has been seeded with a DHCP authentication key
    tied to the DHCP client identifier (e.g. htype/MAC address), computed
    from the master key. As I understand it, PXE/BIS also assumes the ability
    to store a public key validating the boot image. Neither spec really
    provides much insight on how one might obtain proper keying/authentication
    material to secure the iSCSI boot process.
    
    While it might be reasonable to assume that a manufacturer could supply a
    set of machines programmed with the correct public key to validate the
    boot image, it seems somewhat of a stretch that the adapters could be
    programmed on a large scale according to the technique described in
    -16.
    
    Also, in both cases, it would appear that revocation/key change is a huge
    headache. Note that the master secret described in -16 is not be provided
    to the individual stations; this is held in confidence by the DHCP server.
    
    The upshot is that I would not necessarily assume that we in the
    IETF really have a good handle on secure boot at this point.
    
    
    
    
    


Home

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