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

Re: exchange type 6?




As far as 6 goes, the fact is that we have a lot of companies using it now.
Changing it, or having something else get assigned 6 will do exactly what
Ari stated (confusion, interop issues, etc.).  Using 6 or some other
arbitrary large number has nothing to do with security.

If there is something stopping me from requesting and getting 6 from IANA
please let me know.  I saw nothing in 2408 or 2409 that would stop a
non-standards track RFC that has broad industry use and interop from getting
assigned 6.

2408 limits IANA to assign numbers to Standards Track RFCs only WRT:
- DOI and Supported Security Protocols
http://www.isi.edu/in-notes/iana/assignments/isakmp-registry

2409 limits IANA to assign numbers to Standards Track RFCs only WRT:
- Attribute Classes
- Encryption Algorithm Class
- Hash Algorithm
- Group Description and Group Type
- Life Type

If this is incorrect, or I'm missing some other limitations please advise
me.

If anyone wants to discuss/comment on mode-cfg or its implementation feel
free to subscribe/post to:
ietf-mode-cfg@vpnc.org

Darren

----- Original Message -----
From: "Dan Harkins" <dharkins@potassium.cips.nokia.com>
To: "Ari Huttunen" <Ari.Huttunen@F-Secure.com>
Cc: "Derrell Piper" <ddp@electric-loft.org>; <wprice@cyphers.net>;
<ipsec@lists.tislabs.com>
Sent: Thursday, February 22, 2001 12:59 PM
Subject: 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.

  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: