Subject: iSCSI Security rough consensus

From: [email-masked]
Date: Thu, 3 May 2001 11:48:01 +0300

Just wanted to add that SRP with usage of its shared key for
ESP will be added as additional authentication method that
can be negotiated in the Login phase (maybe "SRP_WITH_ESP_KEYING").
I.e., SRP is mandatory to implement, SRP_WITH_ESP_KEYING is optional
as the rest of the authentication methods.

A very delicate issue that needs work in this SRP_WITH_ESP_KEYING
'method' is the synchronization of the ESP startup on both sides.
The intention is to keep the same TCP connection on which the Login
(and SRP exchange) occurred, and just turn on ESP to protect it,
from that 'sync point'.

If this works out OK, we can similarly use the shared key generated
by other optional authentication methods (i.e., define
KERB5_WITH_ESP_KEYING, SPKM_WITH_ESP_KEYING). For administrators
who want to use these methods, it may save the overhead of manual ESP
keying (assuming they buy minimal-compliant iSCSI, that is, without
IKE/certs).

  Regards,
    Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

---------------------- Forwarded by Ofer Biran/Haifa/IBM on 05/03/2001
11:01 AM ---------------------------

[email-masked] on 05/03/2001 06:53:36 AM

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  iSCSI Security rough consensus

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: [email-masked]
Date: Fri, 4 May 2001 13:48:16 -0400

> I do not understand what a requirement for SRP to
> generate keys for ESP/IPSec would add to security,
> especially if IPSec and iSCSI are implemented on the
> same box.  Could you summarize why this recommendation
> was made?  (unfortunately, I missed this part of the
> meeting to catch a plane)

By comparison to full IPSec with IKE, using
SRP to key ESP does not improve security.
The underlying issue is IKE complexity (i.e.,
the code and effort required to implement it).

Hence the rationale for using SRP to key
ESP is that it provides dynamic key
generation without implementing IKE -- this
is an improvement over pre-shared keys at
a much lower code and effort cost for a
single-box (i.e., no external security gateway)
implementation.

Thanks,
--David

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 4 May 2001 09:49:17 -0700

David,

Thanks,
Josh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 8:54 PM
> To: [email-masked]

---

From: [email-masked]
Date: Fri, 4 May 2001 15:38:08 -0400

I read this as violent agreement with what
I posted.  Thanks, --David

> From:	Joshua Tseng [SMTP:[email-masked]]
> Sent:	Friday, May 04, 2001 3:30 PM
> To:	[email-masked]'; [email-masked]
> Subject:	RE: iSCSI Security rough consensus
> 
> See below:
> > 
> What I think I'm hearing you say is that you
> are evaluating whether to REQUIRE SRP keying of
> ESP/IPSec because its easier to do than IKE.
> If so, then in the first place, I don't think that
> is an appropriate justification for a requirement.
> In the second place, I'm not sure I even agree with
> that statement--there are many off-the-shelf IKE
> implementations which can be easily leveraged for
> iSCSI with little or no modification.  IKE doesn't
> need to be conscious of the application (i.e., iSCSI)
> being protected by IPSec.
> 
> I also agree with Bernard that this issue is not
> specific to iSCSI, and belongs in the security WG.
> 
> Josh
> > 
> > Thanks,
> > --David
> >

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 4 May 2001 17:07:48 -0700

See below:
> Actually, if the comparison is SRP vs. IKE using shared keys, 
> that's not
> really true. IKE Shared Key auth is susceptible to man-in-the-middle
> attack in that in Main Mode unless the IP addresses of the 
> correspondents
> are fixed, there is no way to tie an IP address to an 
> appropriate shared
> key. In practice this means the shared group keys must be 
> used. Using the
> same shared group key to protect iSCSI for thousands of 
> initiators lacks
> credibility, because anyone with the group key (e.g. anyone 
> in the entire
> org) can impersonate anyone else. Thus for IKE use in iSCSI, 
> it would seem
> that only cert-based auth is tenable. In the most recent 
> survey data I've
> seen, less than 15 percent of enterprises have any plans to deploy
> certificates. So unless you've got a credible transition solution
> (e.g. GetCert, PIC, etc.) it'll be a hard sell.

...perhaps only 15% of enterprises ARE concerned about security.
I don't know...just wondering....

I don't know if this is that hard of a sell, since there
are already many available products that do cert-based
IKE authentication.  The availability of certificate-based
products and infrastructure is NOT a barrier.

> 
> On the other hand, with SRP, it is possible to identify the endpoints
> prior to authentication a la aggressive mode, and thus to maintain
> separate passwords for each initiator-target pair. SRP is resistent to
> dictionary attacks or compromise of the password database. 
> 
> Ease of implementation is *not* the only issue. There is a 
> functionality
> issue as well. If you need shared key authentication for hosts with
> dynamic IP addresses, IKE Main Mode is not a credible solution. 

For authentication of hosts with dynamic IP addresses, I could
use IKE with cert-based FQDN (or iSCSI Name) authentication.
That is just as viable as SRP keying of ESP/IPSec.  Or if security
is that important to me, I wouldn't use dynamic IP addresses.  All
I am saying is that SRP keying of ESP isn't the only choice.  That's
why it shouldn't be REQUIRED.

Josh

---

From: [email-masked]
Date: Tue, 8 May 2001 18:00:59 +0300

Theodore,

That is an excellent summary of the situation.   Only to keep the "history
record" straight keying in ESP
with a key obtained by a Public Key exchange (we did not have SRP then) was
mentioned by both Josh Tseng and myself as a way to get to end-to-end
security while mandating only gateways as a "required to implement".

Julo

Theodore Tso <[email-masked]> on 05-05-2001 04:25:12

Please respond to Theodore Tso <[email-masked]>

To:   Bernard Aboba <[email-masked]>
cc:   [email-masked], [email-masked]
Subject:  Re: iSCSI Security rough consensus

On Fri, May 04, 2001 at 09:06:23AM -0700, Bernard Aboba wrote:
>
> 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?

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: [email-masked]
Date: Tue, 15 May 2001 12:06:37 -0400

Bernard,

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

No argument here.  There may be some hacks to do better here,
but the result will be weak security at best.

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

Actually, I think the target is phase 2 SAs - IIRC, phase 1 is
IKE-only, or am I confused?  For re-key, SRP generates more
material than is needed to key ESP, especially with NULL
encryption, and hence keeping (some of) that keying material
and rehashing it (e.g., the SHA Interleave described in the
SRP RFC (2945) would generate identical key sequences
on both ends of the connection without a new key exchange.
Using a few bits in the SPI to indicate that it's time to advance
to the next key in the sequence (initiated from either side)
seems sufficient.

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

The biggest "requirement" that's lead us into this space is the
fact that iSCSI can multiplex targets and initiators onto a single
IP connection endpoint (i.e., <IP address, TCP port>) but wants
to authenticated them individually.  The result is that any IPsec
authentication is *not* end-to-end as it can't see the
actual iSCSI endpoints, and doesn't understand what it's
authenticating (e.g., if one don't know the identity of the target
that will be connected to, it's impossible to send back the
certificate for that target).  Firewalls are the primary
motivation for this, as unfortunate as that may be.  This
also may help with some problems related to
dynamic authorization by making it possible to
create a new target on the fly and connect to it in case
some OS code has problems with new LUNs appearing
on existing targets (consider a scenario in which a
new user logs onto a host and wants access to
her storage that the host did not previously have access
to).

The upshot is that we need an end-to-end iSCSI
authentication mechanism that authenticates the iSCSI
entities - authenticating the IP endpoints isn't good enough.
Given this, using that end-to-end authentication to key the 
IP security (i.e., ESP) is natural, and significantly simpler
as IKE cannot replace SRP in this context because IKE
is not authenticating the iSCSI entities.  For the initial
version of the draft, just requiring ESP would allow those
who want to use IKE to key it to do so.  What becomes
an RFC when will depend on how much progress gets
made in various areas.

I believe all of this is said or implied in the iSCSI requirements
draft.

--David

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 15 May 2001 11:34:43 -0700

David,

<snip..snip>
> an RFC when will depend on how much progress gets

Just for clarification, SRP is only one of several
"end-to-end iSCSI authentication mechanisms" listed
in the -06 draft. Simple Public Key and Kerberosv5
are others.  These are endpoint authentications can
be conducted independently of IPSec (no keying of
IPSec).  Any of these, negotiated over an IKE-established
IP-endpoint-to-IP-endpoint IPSec SA, would provide the
needed security.  This is especially true if IPSec and
iSCSI are hosted on the same box, and if we discount
the possibility of an attacker opening up the chassis
and getting between IP and iSCSI/TCP in the stack.

I think if SRP were not used to key IPSec, then IKE
would be needed.  On the other hand, if IKE were available,
why would we need SRP to key IPSec?

Josh

---

From: [email-masked]
Date: Tue, 15 May 2001 23:48:46 +0300

Josh,

> why would we need SRP to key IPSec?

Both SRP and SRP_WITH_ESP_KEYING will be defined among the
AuthMethods that can be negotiated in the Login, for now only
SRP mandatory to implement. If one has ESP with IKE (or pre-keying)
he can configure the negotiation not to offer/choose
SRP_WITH_ESP_KEYING.  However, this option might be very
convenient for non-IKE implementations.

   Regards,
     Ofer

Ofer Biran

Joshua Tseng <[email-masked]> on 05/15/2001 09:34:43 PM

Please respond to Joshua Tseng <[email-masked]>

To:   "[email-masked]'" <[email-masked]>, [email-masked],
      [email-masked]
cc:   [email-masked]
Subject:  RE: iSCSI Security rough consensus

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 15 May 2001 14:56:10 -0700

Thanks Ofer,

But I don't have any problem with specifying how
SRP can be used to key ESP.  My question is whether
we should make this a REQUIRED-TO-IMPLEMENT right now
at this moment.  It's obvious there needs to be some
amount of work in this area before we know what we
are getting with SRP_WITH_ESP_KEYING.  In the meantime,
IKE is mature, is integrated with IPSec, and is
interoperable (as far as I know).  I personally have
used IKE/IPSec implementations that have been embedded
in relatively small devices (< 8MB), and they worked
fine as far as I could tell.  I don't understand why
some have asserted that it is inappropriate for embedded
iSCSI devices.  If this is true, then what criteria
was used?  And how sufficiently "simple" and "lightweight"
does the approach have to be in order to be "acceptable"
to iSCSI?

My intuition tells me that leveraging mature, tested
solutions would be the lowest-risk path for iSCSI to
move forward as far as implementation complexity and
future interoperability issues are concerned.  I believe
IKE fits the bill in this regard.  SRP is still TBD. 

The IPS WG has always opted in favor of deployed and
proven technology (such as TCP), and I see no reason
to make an exception in this case.

Regards,
Josh

---

From: [email-masked]
Date: Wed, 16 May 2001 02:44:38 -0400

> in the -06 draft.

It's also the one that the interim meeting proposes to
make MANDATORY to implement.  Based on what we
can put in the iSCSI draft now, using IKE to key ESP
is acceptable.

> would be needed.

I don't believe that to be the case, although I'll defer to
others on exactly how pre-shared keys are used.

> On the other hand, if IKE were available,

I think this has been answered already.  SRP is end-to-end,
ensuring that any SA it keys is end to end.  ESP in tunnel
mode keyed by IKE need not be end-to-end because any
intermediate security gateways will have IKE.

--David

---

From: [email-masked]
Date: Fri, 18 May 2001 17:52:31 -0400

Bernard,

> Do we have a set of guidelines about what this draft is supposed to
> achieve? 

Not yet, but this is a good place to talk about them -
thanks for the prod.  IMHO, I would do the following ...

> For example:
> 
> 1. Do we need to support negotiation of SRP prime modulus/generator
> groups from within the standard set? 

Not "negotiation" per se.  I'd pick a small (tasteful)
number of them, make them all "MUST implement", have
the Initiator pick one and announce it via iSCSI text
key(s) and/or value(s) sent as part of the initial message.
If the Target doesn't like it for some reason (e.g., we
exercised bad taste [in 20/20 hindsight] and the announced
one is insufficiently secure), it indicates its dissatisfaction
by terminating the login, but "SHOULD NOT" do this
without a very good reason, as a general strategy of
retrying with a different modulus/generator at the Initiator
in response to a Target reject of this form opens up
man-in-the-middle attacks on the negotiation
to force use of a "weaker" modulus/group (from the
attacker's perspective).

> 2. Do we need to generate keying material for Phase 1 as well as Phase 2
> SAs? 

Phase 2 only, but see next item for an approach to rekeying
a Phase 2 SA without using a Phase 1 SA.

> 3. Do we need to support rekeys?

Yes, but Ted and I had talked about doing this without
a key exchange.  The idea is to iteratively use a secure
hash on the material generated by SRP (not all of which
is used to key ESP) to generate the same sequence of keys
on both sides.  Either side twiddles a few bits in
the SPI to tell the other to go to the next key (e.g.,
use 2 or 3 bits in the SPI as a counter, bump the
counter to go to the next key, which is used for the
packet that contains the bumped counter).

> 4. Do we need to support ciphersuite negotiations?

Sort of, with the same approach as the SRP prime
modulus/generator group case above, i.e., pick
a few, make them MUST implement, rely on iSCSI
text keys/values as primary negotiation mechanism,
Initiator announces what is to be done, and Target
can accept or terminate the login.  One could
alternatively use a few bits in the SPI to do this.
At the moment, I'd spec 3DES with a SHA-1 HMAC
and AES with an appropriate AES MAC, and look 
for an opportunity to reduce the spec to only
require the latter.

> 5. Is there a need to negotiate filters?

I don't think so.  A simple model of one Initiator
talking to one Target over one SA per TCP connection
makes the filters implicit and obvious.

> 6. Is there a need for concealment of identities?

I would think not because SRP passes the identity
in the clear.

> In other words, how much of IKE are you willing to throw away? 

From the above, I hope an answer of "quite a bit"
is credible.  Implementers who don't like the answers
to questions such as 2-6 above would have the option of
implementing full IKE (or son-of-IKE) to get Blowfish,
Skipjack, MD5, elliptic curve, negotiated filters,
concealed identities, Phase 1 SAs, etc.  This would be
done prior to iSCSI starting up.

> While a lot
> of IKE complexity is due to artifacts of now discarded layering, a lot of
> it is also due to the generality of what it tries to achieve. If you want
> less features, you can get a lighter weight protocol... 

That would be the goal.  This is all IMHO/off the top
of my head and comments are encouraged.

Thanks,
--David

p.s., I saw an earlier comment that 8MB for IKE
was not a big deal for an embedded system.  The HBA
vendors clearly weren't paying attention to that
comment because 8MB is a big deal for an HBA.
It's also a big deal for a disk drive, and I
would suggest that it's also a visible issue
for disk arrays.  Now, before someone quotes the
size of Symmetrix shared disk cache at me (it's
measured in 10s of gigabytes), let me point
out that there is *no* code or local data
in that cache, and the HDS/HP high-end
arrays are similar in that aspect.

---

From: [email-masked]
Date: Sat, 19 May 2001 12:08:16 +0300

David,

> to force use of a "weaker" modulus/group (from the

By the 06 spec for SRP (Appendix A ), the target simply sends the
modulus/generator in the second message of the SRP sequence. This is
very reasonable for password-based scheme where the target keeps
password verifiers DB, already computed by specific modulus/generator.
It's similar to how telnet is using SRP (RFC 2944). Till now I didn't
hear any comment for negotiation-enhancement of the SRP sequence.

> a Phase 2 SA without using a Phase 1 SA.

The way I see it, SRP_WITH_ESP_KEYING will be performed for each
new iSCSI connection, producing keying material for that (and only
that) TCP connection. So if you want to relate it to the ISAKMP/IKE
notion of phases (is it necessary ?), it indeed might be just for
rekeying aspect.

  Regards,
      Ofer

Ofer Biran