Subject: RE: iSCSI Security rough consensus

From: Joshua Tseng <[email-masked]>
Date: Fri, 4 May 2001 20:05:57 -0700

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

---

From: Theodore Tso <[email-masked]>
Date: Tue, 8 May 2001 14:38:57 -0400

> end-to-end IPSec or else use something like TLS.

The main reason for things like tunnel mode and security gateways are
for legacy protocols and legacy implementations.  

All new protocols are supposed to worry about security in an
end-to-end fashion.  Specifying security gateways doesn't satisfy this
requirement.  The goal here is to provide something better than the
current situation, where most people are using firewalls, and
completely insecure protocols such as NFS.  This is also known as the
"hard crunchy exterior surrounding a soft, chewing interior", and it's
pretty clear this isn't sufficient.  New IETF protocols need to be
secure even if you're not surrounded by a firewall, and are connected
directly to the big, bad, Internet.   

The current situation vis-a-vis security is a really bad one; witness
recent reports about people scanning Silicon Valley for open 802.11
networks, and finding ways of accessing corporate intranets for all
sorts of very embarassed companies.  And then there are the stories
about machines running, PC Anywhere, backdoor modem connections that
the IS department didn't know about, home DSL connections to the
corporate intranet that were cross-connected with the user's cable
modem, etc., etc., etc.

So the answer to your question is that specifying a completely
insecure protocol, and saying it's secure if you put a security
gateway in front of it, isn't going to satisfy the IESG for new
protocol specifications.

						- Ted