Re: iSCSI: DH-CHAP resolution

["Theodore Ts'o" <tytso@mit.edu>]

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