RE: iSCSI Security rough consensus

[biran@il.ibm.com]

David,

>> 1. Do we need to support negotiation of SRP prime modulus/generator
>> groups from within the standard set?

> Not "negotiation" per se.  I'd pick a small (tasteful)
> number of them, make them all "MUST implement", have
> the Initiator pick one and announce it via iSCSI text
> key(s) and/or value(s) sent as part of the initial message.
> If the Target doesn't like it for some reason (e.g., we
> exercised bad taste [in 20/20 hindsight] and the announced
> one is insufficiently secure), it indicates its dissatisfaction
> by terminating the login, but "SHOULD NOT" do this
> without a very good reason, as a general strategy of
> retrying with a different modulus/generator at the Initiator
> in response to a Target reject of this form opens up
> man-in-the-middle attacks on the negotiation
> to force use of a "weaker" modulus/group (from the
> attacker's perspective).

By the 06 spec for SRP (Appendix A ), the target simply sends the
modulus/generator in the second message of the SRP sequence. This is
very reasonable for password-based scheme where the target keeps
password verifiers DB, already computed by specific modulus/generator.
It's similar to how telnet is using SRP (RFC 2944). Till now I didn't
hear any comment for negotiation-enhancement of the SRP sequence.


>> 2. Do we need to generate keying material for Phase 1 as well as Phase 2
>> SAs?

> Phase 2 only, but see next item for an approach to rekeying
> a Phase 2 SA without using a Phase 1 SA.

The way I see it, SRP_WITH_ESP_KEYING will be performed for each
new iSCSI connection, producing keying material for that (and only
that) TCP connection. So if you want to relate it to the ISAKMP/IKE
notion of phases (is it necessary ?), it indeed might be just for
rekeying aspect.



  Regards,
      Ofer

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