Re: IPS: Schedule and Security Update

[Sandeep Joshi <[e-mail]>]

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

[e-mail] wrote:
> -- 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
> [phone] x75140     FAX: [phone]
> [e-mail]       Mobile: [phone]
> ---------------------------------------------------