IPS: Schedule and Security Update

[Black_David@emc.com]

-- Schedule

New set of milestones will be coming in the near future (this week,
I hope).  We're not going to be able to meet the current milestones (main
protocols finished and submitted to the IESG by the end of September).  A
rough guess is that major technical work on the main protocols should be
basically complete by the end of this year (i.e., the final set of technical
issues should be on the Salt Lake City agenda for closure).  Security is a
visible reason, and then there's the last 10% of the details that will
take the proverbial "other 90%" of the time ...

-- Security

A number of thing have been happening in this area that may not be visible
to everyone.  This section is all about iSCSI, although it also applies to
FCIP and iFCP to the extent that they want to follow iSCSI's direction.  At
the moment, iSCSI has open technical issues in (at least) the following four
areas of security, all of which are potential discussion topics for the
interim meeting (although the first one would be for clarification only -
disputing that set of requirements is not a good use of meeting time).

- Requirements

The question of whether security could be optional for FCIP was brought to
the IESG Plenary in London, and the result was a definitive "NO - security
is a 'MUST implement'".  Between this and my discussion of the saag whyenc
draft (draft-ietf-saag-whyenc-00.txt) with both our ADs and the one security
AD who was in London, we should assume that the IESG will add
confidentiality
(i.e., encryption) to the current requirements that iSCSI, FCIP and iFCP
"MUST implement" authentication and keyed cryptographic data integrity.

- Keying and Rekeying

iSCSI needs an automatic keying and rekeying mechanism (and it will be
"MUST implement").  There are currently a couple of active proposals to
do this:

o Use SRP (or some other inband authentication protocol) to generate ESP
	keying material.  See draft-black-ips-iscsi-security-00.txt, which
	I hope to revise to -01 by the end of the week.  This draft also
	contains a general discussion of security requirements.
o Use IKE.  A draft on this should be coming on this in the next few days
	from Bernard Aboba and a bunch of folks who have been working on
this.

Both of these proposals are headed in the direction of end-to-end security
that would make it difficult to use an off-the-shelf IPsec security gateway
to meet iSCSI's "MUST implement" security requirements.  The SRP approach
generates the keys outside the gateway, and there's no standard protocol to
insert the keys into the gateway, and the IKE draft wants to use transport
mode ESP instead of tunnel mode (gateways generally use tunnel mode).  Based
on discussions with Marcus Leech (security AD) and Steve Bellovin (IAB
member and security expert), this end-to-end security direction is the
preferred approach (vs. saying "just use IPsec gateways").

- Algorithm Selection

We need to select encryption and keyed MAC (keyed cryptographic integrity)
algorithms.  This area is somewhat in flux, because a new generation of
these
algorithms is becoming usable - this is about using AES and UMAC instead of
3DES and HMAC.  More details should be in the forthcoming IKE draft.  The
new draft charter for the IPsec WG indicates that they intend to complete
work on the drafts needed for these algorithms (and a draft to extend the
ESP sequence number for high-speed implementations) in the next few months
(and will take all the help they can get in generating those drafts).

- Authentication

We've been a bit vague on exactly what is being authenticated (e.g.,
machine, user), and authentication requirements beyond the fact that
we need authentication.  The two drafts noted above contain some material
that makes a start in that direction, but some additional thought (and
text) will be needed to ensure that we have the right authentication
mechanisms specified/required.  In the case of IKE, this includes
requirements on the relationship between iSCSI and IKE authentication
if both are performed, fortunately Bernard Aboba worked on l2tp security
which has some analogous issues.

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