Re: User-level Authentication Mechanisms for IPsec

[Moshe Litvin <moshe@xxxxxxxxxxxxxx>]

"Scott G. Kelly" wrote:


> > Let's face it; we are all competitors here.  But we shouldn't confuse
> > competitive reasons for technical ones.
>
> This is precisely my point, but I think your characterization is
> misleading. You guys have released this "protocol" to your customers for
> competitive reasons.

Well, most of us does not work for charity organization. But doing thing for
profit is not the same doing it from competitive reasons. No one here
implemented a product secretly to get a competitive edge, and then published the
protocol. The protocol was released to any one of the competitors to use in it's
own product.

The fact, that some "People have been far too busy to give this matter the
attention it has now finally drawn" as you put it, does not changed the fact
that everything was done in the open, giving any one of the competitors a chance
to participate.

> All of us could have done the same at any time, but
> many of us have chosen not to, pending a more thorough technical
> evaluation (technical reasons).

There are no serious technincal issues with the hybrid+XAUTH combination. Nor
are there any major bennefits from the other proposals. There is currently no
reason to start from scratch, some of us have been there already. At this point
in the process we need a REALLY good reason to go back a year.

> That evaluation is now occurring, and

> there are a number of strong technical reasons for not standardizing
> these mechanisms.

There are none. There are some aesthetic issues (one draft, one phase), some red
herrings (knows plaintext) and some irrelevant ones (let's drop hybrid becuse it
give justification to XAUTH, which when used without hybrid can be not secure).

> Don't try to paint this as though you have some
> technical edge, of which some of us are jealous; many of our products
> accomplish these same feats in other perhaps better ways. This is not
> about competition, it's about sound engineering practice.

Don't try to pain it as you have a techniaclly superiour solution. You have a
direction of thought, CRACK is an inferior protocol (DoS). Your direction can be
completed, CRACK can be fixed but the big question is Why?

Until now no one has shown that if and when this effort will be done, we will
get something that is significantly better then hybrid.

Moshe

begin:vcard 
n:Litvin;Moshe
tel;fax:+972 3 5759256
tel;work:+972 3 7534601
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:moshe@xxxxxxxxxxxxxx
fn:Moshe Litvin
end:vcard