Subject: iSCSI Security rough consensus

From: [email-masked]
Date: Wed, 2 May 2001 23:53:36 -0400

The rest of the Nashua minutes will be coming, but
this item is important enough to post on the list now.

The rough consensus on "mandatory to implement" iSCSI
security in the Nashua meeting was that the following
two items will be REQUIRED (mandatory to implement):

- ESP (part of IPSec) with NULL encryption.  This provides
	cryptographic integrity, and authentication, depending
	on how its keys are managed.  The rest of
	IPSec (e.g., IKE and AH) will be OPTIONAL.
- SRP for in-band authentication.  The remaining in-band
	authentication algorithms in the current iSCSI draft
	will be OPTIONAL.

There was also rough consensus in the meeting to pursue
a direction of using SRP to generate the keys for ESP,
and I asked whether there were problems
with the fact that such an approach would not permit
solutions that use an IPSec security gateway external
to an iSCSI implementation.

While there were no answers in the meeting,
I've gotten some strong "Yes, there are problems"
responses off line, and between them and the fact that
there are a bunch of details to work out in exactly
how to use SRP to key ESP, I would propose
that the security requirements be just the two
bullets above (i.e., ESP with NULL encryption and
SRP are REQUIRED).  This allows external gateways,
and keying of ESP with IKE or pre-shared keys,
and is consistent with the bulk of the discussion
in the meeting.

Although the approach of using SRP to key ESP has
a lot of promise, making it a requirement in advance
of a draft providing details that can be checked
by other security experts seems premature ... and
now I have to go help get that draft written
in my "copious spare time" ;-).  Once that draft
is in hand, we can make a concrete decision about
requiring that mechanism.

Also, the integrity hash and signature algorithm
that MUST be implemented for ESP w/Null Encryption
still need to be designated -- in consultation with
the security area and security experts (e.g., Ted
Ts'o, ipsec WG co-chair, who was at the Nashua
meeting) the hope is to bring a recommendation to the
WG in the near future.  A complicating factor is that
new hash algorithms are being introduced as a
consequence of the new AES/Rijndael cipher.  Requiring
such a new algorithm (e.g., as opposed to the current
SHA-1 or MD5) was discussed as a desirable direction
in the meeting, but there are a bunch of details
that need to be checked (e.g., state of IETF use
and standardization of those algorithms).

Comments to the list, especially if anyone disagrees
with the proposed requirements stated above.  Specific
input from security-knowledgeable folks on algorithm
selection should probably be sent directly to me, as
the IPS list is not the best forum for that purpose.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 09:06:23 -0700 (PDT)

> requiring that mechanism.

I agree that requiring SRP for use in IPSEC key exchange with iSCSI is
premature. We already have KINK and IKE key exchange methods, and before
creating a new application-specific method, we need to document why the
existing methods are inadequate. Also, RFC 2945 is an abstract protocol,
not a description of what bits flow over the wire. If SRP is going to be
adopted for IPSEC key exchange, then I'd argue that this should be handled
in the security area, not in the IPS WG, and should be available for any
application running over IPSEC, not just iSCSI.  

Also, given that another key exchange method is likely to be used (IKE,
KINK), this implies that another authentication has already taken place to
set up the IPSEC SA. Thus, requiring SRP in addition to IKE/KINK adds *yet
another* authentication and key exchange to the process of setting up an
IPSEC SA. Are we doing this purely in order to circumvent IKE's
limitations with respect to password-based authentication?

If so, then I'd be concerned that many other applications will encounter
the same limitations, and we may be setting ourselves up for the
proliferation of application-specific IPSEC key exchange mechanisms. I
believe that there is evidence that such a profileration is already in
progress. In the end, IPSEC may end up becoming little more than a
"framework" within which application and vendor-specific key exchanges
are developed.

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 4 May 2001 11:34:07 -0700

David,

Apologies for not being able to stay for the entire
meeting. I had a question about integrity.

Does this consensus mean that the iSCSI header and data CRCs
are no longer part of the specification, or are we
still requiring one or the other or both?

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, May 02, 2001 8:54 PM
> To: [email-masked]
> Subject: iSCSI Security rough consensus
> 
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Theodore Tso <[email-masked]>
Date: Fri, 4 May 2001 21:25:12 -0400

> limitations with respect to password-based authentication?

The basic problem here seems to be that people don't want to implement
IKE.  Going into the interim meeting, what a lot of vendors had been
planning on doing was apparently to *not* to include IPSEC in the
basic storage devices, but to depend on outboard IPSEC gateways to
actually do the IPSEC work.  The iSCSI specs was going to have weasel
words which would permit this, but say that only the entire system of
storage devices plus off-the-shelf VPN box would be compliant with
iSCSI.  Of course, the number of sites that would actually deploy full
iSCSI would probably be quite small; most customers would probably
just not purchase the VPN box, and depend on the hard-on-the-outside,
soft-and-chewing-on-the inside security model.  

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.

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.

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.

						- 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: "Bernard Aboba" <[email-masked]>
Date: Sun, 13 May 2001 02:09:54 -0700

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