RE: iSCSI Security mechanisms

["Joseph Tardo" <jtardo@broadcom.com>]

David:

Let me mention a few other things to bear in mind while considering tossing
out IKE and replacing it with some as yet unbaked SRP-based keying scheme.
I've been trying to follow the exchanges and have not seen these points
raised, but please excuse the posting if I missed a couple.

It is very awkward to manage replay sequence number detection with manually
keyed IPsec associations. Basically, you have to manually assign the SPI's
that go with them as well. IKE provides an exchange of SPI and address
values along with establishing keys. Hence it makes it fairly easy to create
and re-create security multiple associations, all with replay sequences
starting from zero and dynamically assigned SPI's.

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.

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

--Joe

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Bernard Aboba
Sent: Friday, June 01, 2001 5:41 PM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI Security mechanisms


> the negotiation is not
> authenticated/protected in the fashion that
> IKE's is).

This is easy to fix. Just include the chosen
groups/ciphersuites, etc. in the authentication hash. Also remember to
generate sufficient keying material (auth & encryption keys,
different in each direction). One other thing to think about is whether
you will have multiple associations between two endpoints; if so, then you
probably want something akin to IKE phase 1/phase 2; if not, you can live
with only a phase 1 equivalent. In either case, re-key support is probably
needed to avoid staleness in keying material.

> iSCSI does have to specify the ESP authentication/integrity
> transform - as things currently stand, a SHA-1 HMAC
> (RFC 2404 specifies HMAC-SHA-1-96) would be a likely
> choice, but an alternate could be an AES-related MAC if
> it's specification will be available in a suitable timeframe.

Before making a choice, you probably want to examine the performance
data. There has been some concern about auth/integrity performance at 10
Gbps, and so some newer integrity mechanisms (e.g. UMAC, as little as
2 cycles/octet) may be appropriate. In general, it's pretty simple to add
ciphersuite negotiation to SRP, so you won't be stuck with fixed
transforms.