iSCSI Security directions and rationale

[Black_David@emc.com]

The purpose of this message is to state the recommended
security directions for iSCSI from the interim meeting and
describe the rationale for them.  Objections to these
decisions may be made on the list, but they need to have
*good* technical reasons.  I apologize for the length of
this message, but we spent a while on this in the meeting,
and I wanted to get all the considerations into this message.

First, an important piece of procedural context.  In order to
specify a security algorithm (cipher and mode, or integrity MAC),
we need a separate RFC to cite.  For algorithms without RFCs,
the work to create such an RFC occurs in the ipsec WG, not here.
Given the anticipated timetable for iSCSI, any new RFC for such
an algorithm needs to be in ipsec WG Last Call and ideally
submitted to the IESG by early next year, otherwise approval
of the iSCSI RFC gets held up until that algorithm RFC is ready.
The proposed charter revision for the ipsec WG (posted for
comments on August 9) anticipates the following work on
algorithms between now and the end of the year:

3)  New cipher documents to support AES-CBC, AES-MAC, SHA-2, and 
	a fast AES mode suitable for use in hardware encryptors

The "fast AES mode suitable for use in hardware encryptors" is
likely to be counter mode.  In practice, NIST is functioning
as a gateway to the ipsec WG in this area, in that if NIST is not
prepared to recommend a cipher/mode or MAC algorithm, the ipsec
WG is unlikely to work on it seriously in the next few months.
Hence as a practical matter "NIST is not prepared to recommend"
is fatal to the inclusion of an algorithm in the current iSCSI
specification.

There were four major security issues considered at the interim
meeting.  Here's a summary of the issues and recommendations:
(1) Keying - inband (SRP/ESP) or IKE subset
	Recommendation: IKE subset.  No further work to be done
		on inband keying and it will not be specified.
(2) Integrity MAC - many possibilities
	Recommendation: HMAC-SHA1 as "MUST implement", AES CBC MAC
		with XCBC extensions as "SHOULD implement", subject
		to verification that this is consistent with the
		ipsec WG's standardization plans.
(3) Encryption algorithm and operating mode - many possibilities
	Recommendation: 3DES in CBC mode as "MUST implement", AES
		in counter mode or whatever "fast AES mode suitable
		for use in hardware encryptors" is standardized by the
		ipsec WG as "SHOULD implement".  As previously noted
		on the list, NULL encryption is "MUST implement".
(4) Encapsulation mode - transport vs. tunnel
	Recommendation: Unable to reach reasonable consensus.  This
		is wrapped up in external gateway and end-to-end
		security issues as will be explained below.
These recommendations are subject to further comment on the list,
but I would ask that anyone who comments make sure that they
understand the rationale described below.  In the absence of 
serious objections, I intend to call consensus on the first
three items above in the near future.

Let me also note that nothing in this message excludes any
algorithm from implementation  - this is entirely about what
algorithms to REQUIRE (MUST implement) or RECOMMEND (SHOULD
implement).  The one exception is DES, which is sufficiently
weak to justify "SHOULD NOT implement" wording (IMHO).  Usage
is negotiable in all cases.  We may want or need to revisit
these recommendations in the future when the iSCSI specification
is closer to being issued as an RFC in light of developments
between now and then.

- Keying Rationale

Inband keying has negotiation and startup weaknesses.  The best
that can be done with negotiation for the inband keying approach
detects tampering with security negotiation after the fact (at
which point one has to abandon the connection and start over),
whereas IKE can prevent tampering.  There is no good solution for
starting ESP underneath an existing TCP connection.  IKE can be
implemented within memory requirements that are reasonable for
embedded devices (see draft-aboba-ips-iscsi-security-00.txt),
and IKE implementations are readily available in contrast to new
work that would be required for inband keying.  IKE can also be
judiciously subsetted to cut down on the complexity objections
to it (more on this in a separate thread).  In addition, there is
some desire for FCIP and iFCP to follow iSCSI's security direction,
and inband keying is a poor fit to these protocols, especially
FCIP.

- Integrity MAC Rationale

There are three classes of candidate MAC algorithms:
(1) New MACs (e.g., UMAC, PMAC) and new encryption operating
	modes that incorporate MAC functionality.  NIST is not
	prepared to recommend any of these at this time, and hence
	they have to be ruled out for iSCSI.  Unfortunately, all
	of the MAC algorithms likely to have high performance in
	hardware fall into this category.  In addition, with the
	exception of UMAC, all of these sorts of algorithms considered
	at the Modes workshop have serious intellectual property (i.e.,
	patent) issues.  Since UMAC has been of particular interest
	in the past, I should note that the developer of UMAC asked
	NIST not to consider it (and to consider PMAC instead) because
	UMAC is a poor fit to hardware implementations.  NIST will
	be considering algorithms of both sorts (including PMAC)
	for possible future recommendation.  
(2) AES CBC MAC.  NIST was initially prepared to recommend this,
	but it was modified at the Modes workshop to include the XCBC
	extension to improve security for variable size messages.
	NIST is prepared to recommend the result, but we need to check
	that the ipsec WG will proceed to standardize AES CBC MAC as
	modified in this fashion.  Between this and the newness of
	the modification, AES CBC MAC is most appropriate as a
	backup (in case a serious security flaw is discovered in our
	primary algorithm) and hence is recommended as "SHOULD
	implement" subject to verification with the ipsec WG
	(Howard Herbert is working on that verification).
(3) HMAC-SHA1 and HMAC-MD5.  This is what's left.  They're stable,
	well-known, widely implemented, but not exactly fast.  Of the
	two, HMAC-SHA1 is the better choice, as a security issue has
	been discovered with MD5 (as pointed out in the meeting, the
	issue doesn't compromise HMAC-MD5, but the "where there's smoke"
	principle suggests that HMAC-SHA1 is the better choice).  SHA2
	was felt to be more of a performance improvement for SHA1 and
	not sufficiently different from SHA1 to provide meaningful
	protection if a security flaw is found in SHA1, motivating
	the choice of AES CBC MAC as modified by XCBC as the second
	MAC algorithm.
 
- Encryption Algorithm and Mode Rationale

After the WG chair exercised his prerogative to exclude DES from
consideration, four algorithm/mode possibilities were considered:
	- AES in Counter and CBC Modes
	- 3DES in Counter and CBC Modes
3DES Counter Mode is a new mode for 3DES; the ipsec WG does
not appear to have any current plans to standardize it, and
that eliminates 3DES in Counter Mode from consideration.
The point of choosing AES would be to get an algorithm/mode
combination with high performance in hardware and software.
There's unlikely to be a significant difference between CBC
Mode and Counter Mode in software, but Counter Mode can be 
much faster than CBC in hardware, hence Counter Mode makes
a lot more sense for AES than CBC Mode.

Between 3DES in CBC Mode and AES in Counter Mode (or possibly
some other fast mode for hardware encryptors selected by the
ipsec WG), 3DES/CBC is specified, stable, and deployed (and
implementations are available).  Counter Mode for AES is not
completely specified yet, and AES implementations are not
currently widely available.  Hence 3DES in CBC Mode was
recommended as "MUST implement" and AES in Counter Mode or
whatever fast mode for hardware encryptors the ipsec WG
selects as "SHOULD implement" (e.g., inability to get
high performance hardware can be part of a valid reason
to ignore a "SHOULD").  NULL encryption needs to be "MUST
implement" in order to allow ESP to be used for keyed
cryptographic integrity without encryptions.  
 
- Encapsulation Mode

Given the decision to use IKE, a decision to use tunnel mode
encapsulation would result in iSCSI security *exactly matching*
the functionality of an IPsec security gateway (Bump In The
Wire).  Security gateways can be deployed anywhere, and as a
result, it's quite easy for the security obtained from gateways
to be other than end-to-end.  Based on discussions with ADs and
other knowledgeable folks in London, I believe that the IETF
Security Area and the IESG have a preference for end-to-end
security solutions.

Since most security gateways do not support transport mode
(there are a few that do, but they are the exception, not
the rule), REQUIRING transport mode would bias the iSCSI
specification towards end-to-end security in a fashion that
should make it easier to gain IESG approval.  OTOH,
REQUIRING transport mode would make it considerably more
difficult to use external security gateways to provide the
mandatory to implement iSCSI security, which seems to be of
interest to a significant portion of the WG.  On the third
hand, as was made clear at the IESG Open Plenary in London,
the IESG has little sympathy for a desire to use external
security gateways when the result leads to standardization
of other than the "best security available" (see Section 6 of
draft-ietf-saag-whyenc-00.txt).  On the fourth hand, there
may be ways to specify/recommend/require usage of IKE
authentication in a fashion that creates a bias towards
end-to-end security of similar strength to requiring transport
mode.

And that's about where things stand.  I apologize for being
unable to provide clearer guidance, but the situation is what
it is.  From a purely specification and process viewpoint,
REQUIRING transport mode will hasten completion of the iSCSI
spec and its approval by the IESG, but process should not
take precedence over making the proverbial "right" or "best"
technical and engineering decisions.

Please do not quote this entire message when responding.

Thanks,
--David

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