Subject: IPS: Schedule and Security Update

From: [email-masked]
Date: Sun, 12 Aug 2001 22:17:44 -0400

-- 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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Sandeep Joshi <[email-masked]>
Date: Wed, 15 Aug 2001 11:21:22 -0400

David,

Given the newly being-proposed rekeying solutions, how does 
"mandatory to implement" translate in terms of the iSCSI 
clients (initiators), where the same box might have some
or all of the following :
(a) a host OS with IPSec stack from vendor A
(b) an iSCSI HBA from vendor B
(c) an IPsec accelerator from vendor C

Since the vendors are different, who "must" undertake the 
fun stuff of changing IKE/SRP for rekeying ?   Part of
the answer may be dictated by performance needs & economics, 
but in any case I am eager to hear the official interpretation.

This question may not arise in case of RAID boxes or filers, 
where a single vendor would be responsible for the iSCSI 
solution.

Second question : how would we run iSCSI over NAT if we are
to use transport mode ESP, given all the problems 
pointed out by Aboba in 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt

thanks,
-Sandeep

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Aug 2001 10:18:44 -0700 (PDT)

> (c) an IPsec accelerator from vendor C

How this will work depends on how the iSCSI HBA is configured within the
system. In some cases it may be configured as a disk driver, and therefore
will not act as an interface withint he system. In this case it  will not
be able to utilize the IPsec stack on the host, or the IPsec accelerator
hardware installed on another NIC. Such HBAs would need to have their own
IPsec and IKE implementations. 

However, it is also possible to have a NIC capable of handling TCP & IPsec
offload, as well as iSCSI. Such a NIC could utilize the IKE residing on
the host for keying, while accelerating cryptographic operations and
calculations such as the TCP checksum and iSCSI CRC. This effectively
merges categories b and c above.

> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt

The solution is either the IPsec/NAT functionality (in the general case
where you have more than one initiator behind a NAT), or IPsec tunnel mode
(which can work if there is only one initiator behind the NAT). IPsec/NAT
compatibility is now an IPsec WG work item.

---

From: Sandeep Joshi <[email-masked]>
Date: Wed, 15 Aug 2001 18:47:41 -0400

Bernard,

Ok..so whoever claims compliance with iSCSI must provide the
new rekeying method as part of their iSCSI implementation.
Its possible that more than one such IPsec implementations 
(from different vendors) could co-exist on a given host/client.

As to the 2nd question, it was raised since the new rekeying 
schemes seem to be veering towards using transport mode 
(end-to-end security preferred) rather than tunnel mode.

David's email states:
> 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).
  
So does your answer imply that the iSCSI RFC status will depend 
on the result of the IPSec-NAT work item in the IPSec WG ?

thanks
-Sandeep

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Aug 2001 15:54:54 -0700 (PDT)

> on the result of the IPSec-NAT work item in the IPSec WG ?

The answer depends on whether that work is cited normatively or
non-normatively. I would suggest that it is desirable to have as few
normative references as possible in a document that we hope to have done
ASAP.