RE: iSCSI Security rough consensus

["Bernard Aboba" <aboba@internaut.com>]

>P.S.  Yes, I know that in fact there will need to be some
>specifications written to indicate how to get from the SRP or CHAP
>keying information to the low-level details of ESP, probably using an
>AES cipher suite for speed.  The hope was to keep this part small and
>simple enough that that it wouldn't actually be an explicit key
>management layer ala IKE and KINK, although of course it would have to
>perform at least a little of such functions.

I wouldn't use "CHAP" and "keying information" in the same sentence.
CHAP can't be use to derive credible keys, and it's quite vulnerable
to dictionary attack. So it's one of the least desirable choices.

The "specifications" for SRP keying, while simpler than IKE, 
will probably end up deriving something quite similar to the keying
material needed for Phase 1 and Phase 2 SAs, unless we can 
convince ourselves that we really only need the equivalent of
Phase 1. And re-key is probably required, too.

But before we go down this road, I would *really* like to see
a requirements document, spelling out what is needed and why
in some detail. Not being a SCSI expert, it's sometimes hard
to separate what iSCSI requires from what folks think IPSEC
can deliver. If the requirements and justification were laid
out in detail, I suspect the road ahead would be more obvious.

Note that if the issue is purely password auth, then aggressive
mode may be a potential answer. With SRP the identities are
exposed anyway so one could hardly object to agresive mode on
that score. If the issue is access to code, well
there are open source IKE implementations at this point.
SRP is actually slower than IKE computationally, so speed 
can't be an argument.