RE: iSCSI Security rough consensus

[Joshua Tseng <jtseng@NishanSystems.com>]

Ted,

See below:

<Some material deleted>
> 
> And of course, the vendors would employ their marketing people to make
> sure that the full "iSCSI complaint" version would be included in the
> product catalog, but to also always make available the option which
> didn't include this 3rd party IPSEC gateway box.  Guess which version
> of the product would actually see deployment in customer sites?
> 
> For this reason, the IPS working group wanted to use a two levels of
> protection; an "outer layer" that would be IPSEC, but which might not
> necessarily be end-to-end (and in fact, in actual real life, probably
> wouldn't be present at all), and then an inner layer which used
> something like SRP.  
> 
> I don't know if something like this would have gotten past the IESG --
> my guess is that if it did, it would be with the Security Area AD's
> hollering and screaming a lot.

I don't know the Security AD's, but if they had this reaction
as you describe, my question to them would be why did they invent
tunnel mode and security gateways in the first place?  If they
wanted all protocols to have end-to-end protection as a REQUIREMENT,
shouldn't they have just stopped with transport mode?  That way, it's
end-to-end IPSec or else use something like TLS.

> 
> 
> So it was given this particular set of constraints, where people
> seemed determined to (a) not use (or at least not require) IPSEC in an
> end-to-end mode, and (b) to use something like SRP, that I suggested
> using the session keying material from SRP to key ESP as an
> improvement.  If this meant that the IPSEC protection could actually
> be end-to-end, and that it would more likely actually end up in
> shipping hardware that customers actually used, as opposed to an
> unwieldy, theoretical hack that was never meant for customer use but
> only to get around the IETF standards process, then using SRP as the
> source of keying information for ESP was a vast improvement from where
> we started on Tuesday morning.

The description of security gateways in RFC 2401 sure doesn't sound
like an "unwieldy, theoretical hack".  In fact, the section 3.3 clearly
says they are an option:

3.3 Where IPsec May Be Implemented

   There are several ways in which IPsec may be implemented in a host or
   in conjunction with a router or firewall (to create a security
   gateway).  Several common examples are provided below:

There are many other places where 2401 talks in great detail about
security gateways and tunnel mode.

> 
> 
> Would it be better if we were actually doing end-to-end IKE, and
> asking the disk drive manufacturers to solve the public key management
> problems that this would entail?  From a security perspective, sure.
> But it's not too clear how realistic such a stance would really be.

From an implementation perspective, the answer is yes.  I see it
far more realistic for implementers to take an existing off-the-shelf
IKE implementation and plug it into their disk drive, than to tweak
their iSCSI and IPSec implementations to get SRP to key IPSec.
The former can be done with few or no modifications, since IKE
is most likely already integrated with IPSec.  Neither IPSec nor
IKE need to be conscious of the application (i.e., iSCSI) that it
is protecting.

Regards,
Josh

> 
> 						- Ted
> 
> 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.
>