RE: iSCSI Security mechanisms

[Bernard Aboba <aboba@internaut.com>]

> So, you wouldn't have to just add ciphersuite negotiation to SRP, you would
> have to add other stuff like SPI and address values, too, maybe more.
> Interoperable re-keying without dropping packets has proven to be pretty
> tricky to get right, after many bakeoffs, but most implementations now do,
> and the most useful technique involves synchronizing the switch over with
> the IKE phase 2 exchange.

The point I was trying to make was that once you really look at the
requirements, you end up adding back many of the features of IKE one by
one. Now you might be able to make some simplifications in the process, 
but the end result will probably end up looking very much like an "IKE
profile" as you suggest, with SRP substituted for the DH with shared
secret auth under  aggressive mode.

This might satisfy some requirements that aggressive mode doesn't
(such as the ability to avoid cleartext storage of the shared-secret)
but it won't be much simpler (or more mature) than an IKE profile. 
In fact, if you were to compare the two approaches, they'd probably differ
from each other in only one or two payloads. 

> 
> It might really be quicker to define a profile for IKE to use the identities
> you want, even if it means registering a new identity type or providing some
> scheme for using ID_KEY_ID, aggressive mode, and things like that, rather
> than invent a whole new securiy protocol (and get it past the security
> police).

All in all, I do think that an IKE profile would be quicker, assuming that
this meets the (not yet well articulated) requirements.