Subject: RE: iSCSI Security mechanisms

From: [email-masked]
Date: Fri, 1 Jun 2001 18:25:09 -0400

Bernard,

I think this is an instance of brilliant minds
thinking alike (or at least along parallel tracks)
With the exception of your final paragraph, your
comments have reproduced much of the rationale from
the interim meeting for wanting to use SRP for ESP
keying.  I apologize for the lack of detail
in the minutes that lead you to have to reproduce
this - it's hard to take good minutes and
actively participate in the discussion at
the same time.  I guess this is a backhanded
confirmation that using SRP to key ESP is digging in
a useful place :-).  iSCSI already has sufficient
negotiation support to handle selection of
prime/modulus, etc., provided that one is careful
about how it's used (the negotiation is not
authenticated/protected in the fashion that
IKE's is).

There are multiple concerns about IKE.  In addition
to code size, there's a concern that the iSCSI
identities that need to be authenticated (Node
Names) are both foreign to IKE and have a greater
span (i.e., IKE is not end-to-end wrt iSCSI
because the identities of multiple iSCSI nodes
that share a single <IP address, TCP port> pair
can't be distinguished below the iSCSI layer).
There's also a need for SRP by itself to be usable
for inband authentication when/where ESP is not
used (my mechanism summary email was about what
MUST/SHOULD/MAY be implemented -- what MUST/SHOULD/MAY
be used is a separate, but related, issue) - IKE
is not a good fit for this sort of authentication.

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.

I'll correct my usage of "manual" vs. "pre-shared" keys
in the future - thanks for the clarification.

Thanks,
--David

> -----Original Message-----
> From:	Bernard Aboba [SMTP:[email-masked]]
> Sent:	Thursday, May 31, 2001 8:13 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: iSCSI Security mechanisms
> 
> > This leaves open the issue of where the key(s) for
> > ESP come from.  IKE is OPTIONAL, and use of SRP to
> > supply keys for ESP is NOT REQUIRED (not even
> > specified - I need to find the time to work on
> > writing this up).  This leaves pre-shared keys as
> > the minimum mechanism, and hence I believe that
> > a suitably secured administrative interface to
> > supply pre-shared keys to ESP will have to be
> > REQUIRED for interoperability even if a dynamic
> > keying mechanism like IKE is implemented.
> > 
> Let me make sure I understand this:
> 
> a. You use SRP (which derives a key) only for authentication, but then
> throw the derived keying material away. 
> 
> b. You then use IPSEC manual keying, along with an unspecified
> transform, and key distribution mechanism. 
> 
> Note that what is described above is not really pre-shared secrets,
> because those are used to authenticate DH in order to derive keying
> material. Since you're not using derived keying material, we're really
> talking about manual keying. 
> 
> I would suggest that the above manages to combine the computational
> demands of IKE (and then some, since SRP is slower than ordinary DH)
> the administrative headaches of manual keying and the interoperability
> problems of specifying nothing. 
> 
> Ancient proverb: "The first step in removing yourself from a deep hole is
> to stop digging." 
> 
> If you're going to do SRP for authentication, you might as well add in key
> derivation, and negotiation of things like ciphersuites, prime
> modulus/generator groups, etc. so you can use it for IPSEC keying. 
> A rather small spec could accomplish this IF we decide it is necessary.
> 
> If don't want to use the SRP keying material, you might as well use a
> slimmed down version of IKE (say, aggressive mode only) to address the
> code size concern.
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Jun 2001 17:41:26 -0700 (PDT)

> the negotiation is not

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. 

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

---

From: "Joseph Tardo" <[email-masked]>
Date: Fri, 1 Jun 2001 20:44:53 -0700

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Bernard Aboba
Sent: Friday, June 01, 2001 5:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI Security mechanisms

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Jun 2001 23:04:09 -0700 (PDT)

> the IKE phase 2 exchange.

The point I was trying to make was that once you really look at the
requirements, you end up adding back many of the features of IKE one by
one. Now you might be able to make some simplifications in the process, 
but the end result will probably end up looking very much like an "IKE
profile" as you suggest, with SRP substituted for the DH with shared
secret auth under  aggressive mode.

This might satisfy some requirements that aggressive mode doesn't
(such as the ability to avoid cleartext storage of the shared-secret)
but it won't be much simpler (or more mature) than an IKE profile. 
In fact, if you were to compare the two approaches, they'd probably differ
from each other in only one or two payloads. 

> than invent a whole new securiy protocol (and get it past the security

All in all, I do think that an IKE profile would be quicker, assuming that
this meets the (not yet well articulated) requirements.