Re: I-D ACTION:draft-ietf-ips-iscsi-boot-09.txt

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Still a few glitches in this:

----------------------------------------------------------------
Rationale:

It is not appropriate for an iSCSI boot document to be specifying
address assignment behavior for IPv6.

Change

"An iSCSI boot client which does not know its IP address at power-on
may acquire its IP address via DHCP.  An iSCSI boot client which is
capable of using both DHCPv6 and DHCPv4 should first attempt to use
DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event
of failure."

To:

"An iSCSI boot client which does not know its IP address at power-on
may acquire its IPv4 address via DHCPv4; an IPv6 address may be
acquired via DHCPv6 or stateless autoconfiguration."

-------------------------------------------------------------------
Rationale:

Use of IPsec to protect DHCP address assignment is not possible, since
IPsec requires assignment of an IP address. That's why DHCP
authentication was created. In addition, the text recommends against
both pre-shared key and cert-based authentication -- which doesn't
leave much left :)

Change:

"In the case where the DHCP stage is necessary, the iSCSI boot client
must contact the DHCP server using IPSEC. Since DHCP server software
is freely available and can be deployed easily, care must be taken to
make sure that the communication is secure. Consequently, pre-shared
keys MUST be avoided in authenticating the IPSEC communication
channel.  As public key techniques are not recommended for
authenticating the IPSEC communication channel in the Boot stage, an
implementation SHOULD avoid these techniques to avoid two different
authentication mechanisms."

To:

"In the case where the DHCP stage is necessary, the iSCSI boot client
MUST use DHCP authentication [DHCPAuth] for either IPV4 or IPV6.
While DHCP server software supporting DHCP authentication is not yet
widely available, care must be taken to make sure that the
communication is secure."

---------------------------------------------------------------------
Rationale:

The iSCSI security document contains no prohibition against pre-shared
key usage -- only that Aggressive Mode be used with pre-shared keys
and dynamic IP addresses. It's best for the iSCSI boot
document to just reference the existing recommendations.

Change:

"The final communication between the iSCSI boot client and the boot
server in the Boot stage is secured with the help of IPSEC. The
communication must adhere to the recommendations in the main iSCSI
draft [Satran02] for the choice of certification, authentication and
encryption algorithms.  However, since the iSCSI boot client is
likely to have a dynamic IP address, pre-shared keys MUST be avoided
in authenticating the IPSEC communication channel."

To:

"The final communication between the iSCSI boot client and the boot
server in the Boot stage is secured with the help of IPsec, as
specified in the main iSCSI drat [Satran02] and [IPSSec]. SLPv2
security is specified in [IPSSec]."
-----------------------------------------------------------------------
Rationale:

The default configuration below is insecure so that at least SOME
mention of the potential vulnerabilities would be nice.

Change:

"The mechanism for securing the iSCSI boot process SHOULD not be
enabled by default so as to avoid the configuration, deployment and
provisioning requirements of the secure boot process."

To:

"The mechanism for securing the iSCSI boot process SHOULD NOT be
enabled by default so as to avoid the configuration, deployment and
provisioning requirements of the secure boot process. Of course, without 
security the iSCSI boot process is vulnerable to attack, such as 
provisioning of rogue boot images."

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail