[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exchange type 6?





>   Wow, I'm having flashbacks of the 40bit DES arguments. You can provide
> your customers with a proprietary protocol to satisfy their desires. You
> don't need to take valid exchange types from a standard's track protocol
> to do it though.

It was definitely an unfortunate mis-cue on the authors' part to choose an
inapropriate number for the draft.  However, I think it took something like
1 or 2 years before anyone actually commented on it (if anyone is bored
enough, feel free to look through the archives to look up the exact dates),
and by then there were already at least 2-3 shipping products using it.
Maybe the authors should have changed it then... but they didn't.  And now,
there's definitely more than "you count on one hand and still be able to
simultaneously pick your nose and suck your thumb" as you so elegantly put
it.

The moral of the story is... what's done is done (no matter how evil it
was).  What we're left with today is a non-standards track draft implemented
by some people in this group that violates rules set forth by this group.
This draft is no longer being persued on standards track, but will likely at
best become an informational or maybe even historical RFC.

Fortunately, the magic number 6 is currently unassigned, and those of us who
have implemented it are at your mercy.  Sure, we could change that number to
be in the legal range, but that would complicate a lot of our IPsec
deployments, and we'd still have to use #6 for years to come to be
backwards-compatible.

So, which is the lesser of 2 evils?  Mark #6 as
depricated/historical/whatever, or give the implementors of mode-cfg, and
whatever the future#6 protocol is a big headache?

Stephane.



>
>   One of the happy byproducts of this working group is that lots of
> money is being made selling products based on these protocols but let's
> not put the cart in front of the horse. We are here to develop and
> standardize secure protocols not to make life easier for companies that
> chose time-to-market over security.
>
>   Dan.
>
> On Thu, 22 Feb 2001 18:20:14 +0200 you wrote
> > I think this statement "it's our charter to provide secure protocols and
> > standardizing anything less is unacceptable to some of us" is exactly
> > THE PROBLEM.
> >
> > Note that you didn't say that it's anywhere in this working group's
charter
> > to enhance the security of the actual products out there. If this was
the
> > case, this working group would stop actively demanding changes in the
> > way actual products in the field are working. Every change in the
protocol
> > potentially introduces more vulnerabilities in the implementations, many
> > of which need to support several different versions of the protocol.
Actual
> > implementations, and most notably something that customers have spent a
whole
> > lot of money in, change slowly.
> >
> > I couldn't care less if there's been discussion that exchange type 6 is
> > not to be used, or whether any document says exchange type 6 is not to
be
> > used, or any WG chair or security advisor or whatever. Our customers
need
> > to interoperate with others who have products using exchange type 6.
It's
> > as simple as that.
> >
> > I can understand that some of you don't like these protocols. As a
matter
> > of fact, I don't like these protocols either. Just please stop making
our
> > life any more harder than it already is.
> >
> > Ari
> >
> > Derrell Piper wrote:
> > >
> > > Will,
> > >
> > > I just don't agree with allocating a reserved number to Config/XAUTH.
> > > XAUTH was not adopted because it has serious security problems.  We
did
> > > think about this.  The problem is that there's been essentially no
progress
> > > on adopting a viable alternative (e.g. CRACK or Hybrid) so people
continue
> > > to use what they've got.  However, it's our charter to provide secure
> > > protocols and standardizing anything less is unacceptable to some of
us.
> > >
> > > Derrell
> >
> > --
> > Ari Huttunen                   phone: +358 9 2520 0700
> > Software Architect             fax  : +358 9 2520 5001
> >
> > F-Secure Corporation       http://www.F-Secure.com
> >
> > F-Secure products: Integrated Solutions for Enterprise Security



References: