Re: ISCSI: Error in 10.3.3 of iscsi-08

["Ofer Biran" <BIRAN@il.ibm.com>]

Paul,

Sorry for the delay,  I was on vacation.  You are right of course, I had
Bernard
(who brought up this issue) review your suggestion and your second
suggested text will be used.

  Thanks,
     Ofer



Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


Paul Koning <pkoning@jlc.net>@ece.cmu.edu on 02/10/2001 19:16:55

Please respond to Paul Koning <pkoning@jlc.net>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  ISCSI: Error in 10.3.3 of iscsi-08



The last paragraph of section 10.3.3 is badly misleading.

10.3.3 says about pre-shared key: "the only practical usage under this
configuration is a group pre-shared key".  That is clearly false.
Standard practice for IPsec is that a pre-shared key is unique to a
given pair of communicating entities.  The only exception is when
dynamic addresses are used, as discussed accurately in the security
draft, section 5.8.2).

As a minimum, 10.3.3 needs to be reworded so it describes the real
world.  The following text would do this:

        IKE main mode with pre-shared key authentication method SHOULD NOT
        be used (while pre-shared keys in many cases offer good
        security, situations where dynamically assigned addresses are
        used force the use of a group pre-shared key which creates
        vulnerability to man-in-the-middle attack).

Preferably, the requirement should be changed so the reasoning for the
restriction matches the restriction.  The following text achieves
this:

        IKE main mode with pre-shared key authentication method SHOULD NOT
        be used when either the initiator or the target uses
        dynamically assigned IP addresses (while pre-shared keys in
        many cases offer good security, situations where dynamically
        assigned addresses are used force the use of a group
        pre-shared key which creates vulnerability to
        man-in-the-middle attack).

If this second solution is adopted, section 2.3 in the security spec
also needs a corresponding change (first two sentences of page 10).

     paul