[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: charter question re IKE changes
Steve:
"Most" is the operative word, because there has also been very extensive
discussion and repeated suggestions and pleas to replace Aggressive Mode
with Base Mode. This certainly sounds like an "add" as well as a "remove" to
me.
Be that as it may, to ellaborate on what I take to be John's point, one of
the spectres against which IPsec is fighting is, unlike the SSL community,
the IPsec community decided that everyone needs mutual authentication all
the time, 100% without exception, regardless of any and all other
considerations. My belief, for what it is worth, is experience now shows
that this was a genuinely bad decision, and the creation of IPSRA to solve
the legacy authentication problem simply confirms this. Real deployments
need strong one way authentication of an infrastructure or community to a
newly enrolling participant in order to bootstrap; requiring strong two way
authentication even during enrollment has created the deployment nightmare
that IPSRA has been chartered to fix. Both of the IPSRA proposals on the
table make use of this realization by essentially relying on one-way
authentication to get around the chicken and egg problem that exists at
deployment time. IPSRA words the problem much differently than I've
charaterized it here, but it is the same problem.
It seems to me that the PIC proposal in particular could easily be
incorporated into the larger IKE framework, obviate the need for this IPSRA
legacy authentication task, and result in a much more widely deployable and
usable IPsec.
Just my two cents.
-- Jesse
-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: Wednesday, October 11, 2000 8:08 AM
To: Linn, John
Cc: 'ipsec@lists.tislabs.com'; 'ietf-ipsra@vpnc.org'
Subject: Re: charter question re IKE changes
In message
<F504A8CEE925D411AF4A00508B8BE90A93E26A@exna07.securitydynamics.com>
, "Linn, John" writes:
>I'd like to ask a charter question which relates to both IPsec and IPSRA
>WGs. IPSRA, based on IESG inputs, has been operating under the premise
that
>its work should not impact IKE's syntax or semantics if feasibly avoidable,
>with a strong preference to work instead alongside IKE as currently
defined.
>This premise has constrained the design space for candidate IPSRA
proposals.
>Recent discussion on IPsec has suggested significant changes to IKE,
>potentially removing or replacing authentication modes. Question: If IKE's
>definition is to be reopened within IPsec, should IPSRA's admissible design
>space continue to be constrained by RFC-2409?
Yes.
Most of the talk here has been about removing things, not adding more.
IPSRA would need to add more.
--Steve Bellovin
Follow-Ups: