Subject: iSCSI: DH-CHAP resolution

From: "Elizabeth G. Rodriguez" <[email-masked]>
Date: Tue, 7 May 2002 12:30:28 -0600

All,

As mentioned previously, the consensus call for DH-CHAP was very close.
As a result, Allision Mankin requested security expertise be consulted
further prior to declaring consensus on the issue.

The result is that security experts believe that DH-CHAP, while from the
reading, DH-CHAP seems to be a worthy solution but, as many have stated
both to me and the ADs privately as well as on the mailing list,

it is unproven.  As such, the decision has been made to NOT include
DH-CHAP as an authentication mechanism for iSCSI.

Now, the next question will be how will this effect the mandatory to
implement authentication mechanism decision.  The Transport ADs still
have significant concerns about IPR issues as they relate to SRP as the
mandatory to implement mechanism.  They also feel that (as has been
expressed on the mailing list) we do not have concrete requirements
listed for the authentication mechanism.  As such, Allison is in the
process of calling a meeting between the Security and Transport ADs.
This will likely occur some time late this week.

I realize that everyone is anxious to close on this issue.  I assure you
it is being worked, and that the delay is related to making sure that
iSCSI has the best chance of success, both in the IETF review process as
well as the corporate environment.

Thanks,

Elizabeth Rodriguez

IPS co-chair

---

From: Philip MacKenzie <[email-masked]>
Date: Thu, 09 May 2002 09:32:38 -0400

Well, it looks like everything is going to CHAP.

Before these last messages came out, I had already
basically written up a document describing what I see
are the main issues in authentication in iSCSI, along
with the alternative approaches and their advantages and
disadvantages.  For anyone who's interested, you can find
it at:

http://cm.bell-labs.com/who/philmac/research/iscsi-authentication

The last paragraph of that document desribes another
approach that may be appropriate for iSCSI:
Use CHAP with long keys, and if someone wants
password authentication with high security, use
another protocol *completely separate from iSCSI*
to download user credentials (i.e., the long key for use
with CHAP in iSCSI).  Hopefully this protocol would
be secured with PAK, or some other strong password
authentication key exchange protocol, but that does not
affect iSCSI.

This type of approach is used in Plan 9.  It is also similar
to an approach currently being considered in the ipsra
working group.

-Phil

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 9 May 2002 12:08:09 -0400

There's one other potential, very simple change we could make to
DH-CHAP, which may mollify the people who are so worried about the
lack of mutual authentication in CHAP.  (I'll claim that the
succeptibility to active attackers being able to carry out a
dictionary attack on the password as far over-rated, since the data
stream after the initial authentication is completely unprotected,
which means the attacker and read *and* modify the data being
transferred via iSCSI --- this could mean modifying executables so
that trojan-horse code is executed, or modifying sensitive data
records --- in other words, if you're worried about active attackers,
the potential for a dictionary attack is the LEAST of your concerns,
and you should be using IPSEC to protect your entire transaction, at
which point the issue about active attackers is solved completely.)

With respect to lack of mutual authentication, there is a very simple
modification we can make to the DH-CHAP protocol that can solve this
problem.  It merely involves using a sufficiently large D-H modulos
that the storage device can use a fixed (a,A) pair, ala the old Secure
SunRPC protocol (which was always fine except for the fact that Sun
stupidly used a way-too-small D-H moduolos, probably for export
control reasons), and then adding a server-generated nonce to the
exchange to guarantee freshness, since the server's D-H key is no
longer ephemeral.

This allows the client to cache the D-H key for a particular storage
device, and if the D-H key is ever different from the one that the
client has cached, it knows that it's being subject to a
man-in-the-middle attack or the device has been substituted without
its knowledge, so it can complain and refuse to mount the disk.  (Note
that the client doesn't *have* to do this check; if it doesn't, it is
essentially identical to the current DH-CHAP scheme, and it simply
doesn't have any mutual authentication guarantees.)

This provides us with mutual authentication for everything except for
the initial authentication exchange.  However, in reality, it turns
out that for almost all schemes, including SRP, this is actually all
you get, because most systems cheat in order to solve the initial
authentication problems.  For example, in the case of SRP, how do you
load the first user's verification data into the device?  The hard
drive will almost certainly used a fixed password which is constant
across all of a vendor's devices and which is embedded in the install
program.  This means an active attacker who is active on the network
during the initial setup can spoof the transaction.  The right fix
would be to use a randomly chosen password which is different for
every single device ---- say, a long hex string which is printed on
the device and which the system administrator must type in when the
device is first being initialized.  However, most implementations
neglect to do this because users find it too inconvenient (by the time
they figure out they need the hex string, they've already installed
the device, and pulling out the device in order to read out the hex
string becomes a major pain in the ass).  As a result, most
implementation cheat on the initial authentication problem, and hence
their product is vulnerable to an active attack during the first
exchange.

(For example, this is true for Windows XP using Kerberos; when a newly
installed Windows client first joins a domain, there is no initial
secret to authenticate it to the domain controller, or that the domain
controller can use to authenticate the initially installed Windows
client.  So, there is a hard coded secret buried deep within the
Windows code, and if you know that "secret" --- which is constant
across all copies of Windows, so it's hardly a secret --- you can
attack the initial authentication exchange when a host first talks to
the domain controller.

It's not true for the MIT version of Kerberos, since we don't provide
this shortcut, but the resulting loss in usability in the requirement
to manually set up a srvtab file causes a huge number of complaints,
and if MIT Kerberos were a commercial product that needed to be
responsive to customer complaints, I suspect it would almost certainly
make the same security shortcut/compromise --- so I'm not blaming
Microsoft for making the decision which they made.  This is by the way
also the same compromise which SSH using public key authentication
makes; it's a very common tradeoff.)

So to the extent that we have protection from all but the initial
exchange, I would claim that this should be good enough for most
purposes, and no different from what SRP could provide in real life
anyway.  And, if we really want to assuage our consciences, we can
require that the devices have printed on them a MD5 hash of the fixed
Diffie-Helman public key, and we can pretend that the system
administrator will type in the MD5 hash when setting up a new storage
device (at which point the mutual authentication guarantees are just
as strong as SRP or any other scheme) --- even though we know that
less than .0005% of the system administrators will actually do so in
real life.

Is it worth making this change?  Well, it depends on how important you
think Mutual Authentication is for people who will be using iSCSI
without IPSEC.  For people who have critical security requirements,
it's pretty clear that IPSEC will be a requirement.  However, for
people who don't need IPSEC, do we need to provide a greater level of
security protection?  The advantage of the scheme which I've outlined
is that it's a relatively small change to the DH-CHAP protocol, so the
cost of adding this protection is fairly cheap.

							- Ted