Subject: RE: iSCSI: IKE normative guidelines

From: [email-masked]
Date: Fri, 9 Nov 2001 22:25:39 -0500

Yes, these guidelines differ from those RFCs in a number of
ways, based on things learned since those RFCs were written.
Many of these are things that would go into revised versions
of the IPsec RFCs, but revising the IPsec RFCs turns out to
be intractable to the point of near-impossibility for the
security folks - you'll have to ask them why.  See the IPS
security draft for some further explanation of these changes.

Main mode is not "at least as good" as aggressive mode when
group pre-shared keys are used; see the security draft and
the ipsec WG "improveike" draft for details.  Group pre-
shared keys are often used in practice because they
greatly simplify key management.

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

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 4:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: iSCSI: IKE normative guidelines
> 
> 
> >>>>> "Ofer" == Ofer Biran <[email-masked]> writes:
> 
>  Ofer> In the framework of the effort being done now by the security
>  Ofer> team to sync the normative statements in the security draft
>  Ofer> with the protocol drafts, I suggest to adopt the following IKE
>  Ofer> normative guidelines that already appear in the security draft
>  Ofer> for iSCSI: ...
> 
> Does any of this differ from what's in RFC 2408/2409?  If so, why?  If
> not, why not just refer to that standard and say nothing further?
> 
> If we're going to be different, I'd suggest dropping aggressive mode
> since main mode is at least as good.
> 
>       paul
>

---

From: Paul Koning <[email-masked]>
Date: Mon, 12 Nov 2001 11:46:36 -0500

> security draft for some further explanation of these changes.

That's all well and good, but I see a major process problem with WG
XYZ overriding the requirements created in another protocol that
belongs to WG ABC on the grounds that WG ABC can't get the work done
itself.  

If that's what we want to do, we should be clear about it and not call
the lower layer protocol we're relying on "IPSec" but rather something
like "IPS-sec" to make it clear we're defining an IPS specific variant
forked from the original standard.

Perhaps IKE is less problematic than, say, not yet settled on modes
such as XCBC, but the same principle applies in both places.
 
> greatly simplify key management.

Yes, that's covered by text I supplied a while back.  That case
applies to dynamic IP addresses, which is an obscure corner case at
best for IPS.  With static addresses, group keys are not needed and
are very much not normal practice.

     paul