iSCSI Security: Environment and Requirements

[Black_David@emc.com]

As part of some work to get some more concrete proposals
for some of the open portions of iSCSI security (results
will hopefully be visible soon), I generated the following
working note.  It'll probably go into an Internet Draft
next week, but I can't be sure I'll get that done far enough
ahead of the deadline for review and comment.  Hence, I'm
putting this up now for discussion with the intent of putting
an improved version into the draft.

Comment away.  Thanks,
--David

iSCSI and Security: Environment and Requirements
Drafty draft - working note
-- David L. Black, July 2001

-- Conventions and Caveat

Capitalized words are to be read according to RFC 2119.  All descriptions
of current status or the like are to the best of my (WG co-chair)
understanding, and are accordingly subject to change.

-- iSCSI overview

iSCSI is an TCP/IP encapsulation of the SCSI protocols used to
access disk, tape and other devices.  iSCSI is a client-server
protocol in which clients (Initiators) open connections to servers
(Targets).  We use the SCSI terms Initiators and Targets for
clarity and to avoid the common intuition that clients have
considerably less computational and memory resources than servers;
the reverse is often the case for SCSI, as Targets are usually
dedicated devices of some form.

iSCSI Initiators and Targets are layer 5 entities that are independent
of TCP ports and IP addresses.  An Initiator or Target may use multiple
communication endpoints  (<TCP port, IP address> pair), and such
endpoints may be shared by multiple Initiators or Targets, although the
common case for sharing will be that the sharing entities are all of the
same type (i.e., all Initiators or all Targets).

The iSCSI protocol has a text based negotiation mechanism as part of
its initial (Login) procedure.  The mechanism is extensible both in
what can be negotiated (new text keys and values can be defined) and
in the number of negotiation rounds to accommodate functionality such
as authentication based on responding to a challenge.  

-- Security functionality requirements

o Authentication

Bi-directional authentication (Initiator to Target) and vice-versa is
REQUIRED.  This authentication is logically of the iSCSI Initiator to
the iSCSI Target (as opposed to authenticating the communication endpoints).
The intention of the iSCSI design is that Initiator and Target should
represent the systems (e.g., host and disk array) participating in
the communication, as opposed to communication interfaces or endpoints.

The current status is that the Secure Remote Password protocol
(SRP) as specified in RFC 2945 will be REQUIRED of all implementations
based on the text-based multi-round negotiation mechanism defined above.
A number of additional authentication protocols have also been specified.
Negotiation between Initiator and Target is used to determine which
authentication algorithm will be used; the connection closes if either
side requires authentication and no mutually acceptable algorithm can
be agreed upon.

o Data origin authentication (cryptographic communication integrity)

Cryptographic integrity of all iSCSI communications after the login
phase is REQUIRED, and this integrity mechanism must be keyed to an
authentication to provide data origin authentication for all received
data (e.g., this prevents a TCP hijack attack from succeeding because
the hijacker does not know the key required to generate the correct
cryptographic integrity checks).  The current status is that ESP with
NULL encryption has been chosen as the implementation approach to
meet this requirement, but the Authentication Algorithm (MAC, e.g.,
HMAC-SHA1) has not been selected.

o Confidentiality

A confidentiality mechanism will be part of the iSCSI specification,
but the current status is that any such mechanism will be OPTIONAL
to implement and use.  The current status is also that ESP has been
chosen as the implementation approach, but no preferred ESP transform
(i.e., encryption algorithm) has been chosen.  My personal expectation
is that a single algorithm will be RECOMMENDED or REQUIRED of those
implementations that choose to implement encryption.

o Negotiation of Security Functionality

The current status is that the iSCSI negotiation mechanism described above
is expected to be usable to negotiate away security functionality in
environments
where it is not needed (as determined by local policy).  The inband
negotiation
mechanism has no intrinsic security, as it's done in the clear as far as
iSCSI is concerned.  If such a negotiation is conducted over an otherwise
unsecured connection, man-in-the-middle attacks on this negotiation have
to be considered when it is used to negotiate use of security functionality.

o Approach to Specification

Selecting appropriate subsets of existing security specifications is
believed
to be acceptable provided that good engineering judgement is used and the
result is sound from a security standpoint.  An example below is that iSCSI
currently intends to use ESP without AH even though both are REQUIRED by the
basic IPsec RFCs.  Such an approach may also be applicable in areas such as
IKE/ISAKMP and algorithm selection (e.g., believe it or not, DES is still
REQUIRED). 

-- Implementation Classes and Resource

iSCSI will be implemented on a variety of systems ranging from large
servers running general purpose operating systems to embedded host
bus adapters (HBAs).  Host Bus Adapter is a general term for a SCSI
interface to other device(s); it's roughly analogous to the term
Network Interface Card (NIC) for a TCP/IP, except that HBAs are expected
to have on-board SCSI implementations, whereas most NICs do not
implement TCP, UDP, or IP.  In general, a host bus adapter is the
most constrained implementation environment, although an HBA may draw
upon the resources of the system to which it is attached in some cases
(e.g., authentication computations required for system setup).  More
resources tend to be available to implementations for embedded and
general purpose operating systems.  The following general guidelines
indicate the level of resources that authentication, keying, and rekeying
functionality can reasonably expect to draw upon:

- Low power processors with small word size are generally not used,
	as power is usually not a constraining factor for these systems
	(with the possible exception of HBAs, which can draw upon the
	computational resources of the system into which they are inserted).
	Computational horsepower should be available to perform a
	reasonable amount of exponentiation as part of authentication
	and key derivation for connection setup.  The same is true of
	rekeying, although the ability to avoid exponentiation for
	rekeying may be desirable (but NOT REQUIRED).

- RAM and/or flash resources tend to be constrained in embedded
implementations.
	8-10 MB of code and data is clearly excessive, 800-1000 KB is larger
	than desirable, but tolerable if necessary and 80-100 KB should be
fine.
	These numbers are intended as rough order of magnitude guidance, and
	should not be taken as hard targets or limits (e.g., smaller code
sizes
	are always better).  Software implementations in general purpose
operating
	systems may have more leeway, but even in that environment these
guidelines
	are a reasonable approximation.

In summary, the primary concern in looking for a "lightweight"
authentication
and keying mechanism is code size, as the computational horsepower to do
exponentiations (e.g., those required by SRP) is generally expected to be
available.

-- Implementation Scaling

There is no dominant iSCSI usage scenario - such scenarios range from
a single connection constrained only by media bandwidth to connection
fan-out well beyond the current practical limits of Fibre Channel -
hundreds of Initiator connections to a single Target or single
communication endpoint are quite likely in some cases.  SCSI sessions
and hence the connections they use tend to be relatively long lived;
for disk storage, a host typically opens a SCSI connection on boot and
closes it on shutdown.  Tape session length tends to be measured in
significant fractions of an hour or multiple hours (i.e., rapid fire
sharing of the same tape device among different users is unusual),
although tape robot control sessions can be short when the robot is
being shared.  On the other hand, tape will not see a large fan-out
as each drive is dedicated to a single user at a single time, and
a dozen tape drives is a large tape device; add a few robot sessions
to this number to get a total.

Given current networking technology, security solutions must work
well at 1 Gbit/sec; solutions that scale up to 10 Gbits/sec would
be nice to use but are not an absolute requirement as there are
issues with a number of technologies at 10 Gbits/sec.

-- Implementation Environment Q&A

Gathering up a bunch of questions about the 

Q: Will IPsec generally be present on systems supporting iSCSI due to other
	traffic requiring IPsec security?
A: No, especially on Targets which may have no other important
functionality.

Q: What are the persistence requirements for security state across power
	off or loss of TCP connections?
A: Essentially none; most SCSI state does not survive power loss or system
crash
	events with a few exceptions like persistent reservations.  Security
state
	for open TCP connections need not survive the loss of those
connections.
	Any new connection will have to re-authenticate.

Q: What about load-balancing or fail-over middleboxes?
A: Discussions of iSCSI-aware middleboxes have usually assumed that such
	a box serves as an endpoint for the iSCSI sessions on both sides of
it.
	There have not been any major objections voiced in the WG to
	the fashion in which IPsec can interact with such boxes (e.g., TCP
	header is encrypted).

Q: What about NATs?
A: The IP Storage WG charter indicates that the ability to operate across
	NATs is important, but not an absolute requirement.  Work is
underway
	in the ipsec WG to specify transparent operation across NATs via
	UDP encapsulation.

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------