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

Re: Comments on CRACK

Will Price wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Moshe Litvin wrote:
> > I don't know of any product out there that implements hybrid, but
> > there are some on the way. What are the developers supposed to say
> > to their sales and marketing staff, who are pressuring them as they
> > did to you? Are they supposed to say "The IETF workgroup changed
> > title and now there is a very similar (but incompatible) draft, in
> > a few month it will be stable enough to start implement it. In the
> > mean time forget about the product, but if anything goes well, and
> > the work group won't change title again we would have a product by
> > 2001"
>
> Marketing decisions are totally irrelevant to this group.  The goal
> of this group is to do the right thing for the infrastructure.  I
> think the correct thing to say is "Our engineering group made a
> mistake and promised to ship a protocol hack which just wasn't ready.
>  That protocol hack has now been effectively shelved in the IETF in
> favor of a much better proposal.  If we try to ship the old stuff, we
> will not be compatible with anybody else now or in the future.  We
> will now modify our goals to implement the better proposal and after
> we test it at bakeoffs and things settle down, we'll tell you when it
> can ship."

You would have been right if CRACK had any significant advantage over
hybrid.
But it doesn't. Therefor starting from scratch will only make the
workgroup give a very similar protocol with a year (or more) delay.

Changing a draft because a better proposal arrive is one thing. But
throwing away a draft after one year because a slightly different one
arrive is another.

> > The minor issues are not my point. My point is that CRACK should be
> > rejected not because it is a bad protocol (it is not bad, though it
> > must be improved). CRACK should be rejected because it does not
> > provide enough benefits to the existing protocol.
>
> I think you're underestimating the problems of the mode-cfg/xauth
> flaws which have been extensively discussed here and in the new
> drafts.
>
> > > And I don't think we have a mature protocol in hand. Last week I
> > > talked to a representative of another company who claimed "full
> > > compliance" with the "draft standard RFC". It turns out he only
> > > does radius, does not do Hybrid, and I know he's not
> > > interoperable with another vendor who also does the same thing.
> > >
> > > Part of the problem with the ISAKMP-Config+XAUTH+Hybrid approach
> > > is that it leaves XAUTH as a separate entity. This protocol by
> > > itself is fundamentally broke. The problems are addressed with
> > > the addition of Hybrid but it is not required to do Hybrid. As a
> > > result people do an unauthenticated Diffie- Hellman and a radius
> > > exchange on top of that and claim compliance to a "draft standard
> > > RFC". All the time excusing it away with the remark that their
> > > customers don't really want strong security. I must've missed it
> > > when the requirements from a company's marketing department
> > > became part of a WG charter.
> > >
> > > If XAUTH and Hybrid were combined into a single draft which,
> > > basically, forbade the common XAUTH practice it would be another
> > > story. It would be the "Extended Hybrid Authentication" solution
> > > vs. CRACK and I would be hardpressed to say which one is the
> > > "best". But then again, we're back to square one.
> > >
> > >   Dan.
> >
> > Until now there where two point in favor of CRACK:
> > 1. One phase negotiation
> > 2. One document.
> >
> > As for the one document argument, as you noted, can be solved by an
> > editorial act of combining the two draft together. We have no
> > objection to this, and if the working group and the authors of
> > XAUTH would want to, we can do this, and sill have the protocol
> > intact.
> >
> > The first argument is real, but it is mainly aesthetic, and does
> > not constitutes a good enough reason to throw all the work done so
> > far.
>
> I don't think we're throwing out work.  All work done so far was
> experimental with the goal of reaching a good solution.  This
> experimentation has led to the discovery of various serious flaws in
> the mode-cfg/xauth solution.  These flaws are now being corrected in
> a solution which builds on what has been learned.
>

Aside from the two stated flows, which others are you referring to?

I belive that most of the objection is for XAUTH. That is some people are
against hybrid because hybrid give justification for XAUTH, which when
used without hybrid is bad.
I don't consider it as a valid argument for replacing hybrid.

> My feeling is that those who are complaining now are doing so for
> marketing reasons rather than doing the Right Thing for security and
> the protocol.

You are implying that CRACK is more secure hybrid. A fact that needs a
proof. Supplying such proof will be hard considering that CRACK is more
susceptible to DoS attack.

As for the accusation of complaining about CRACK for marketing reasons,
the opposite can also be made about companies who noticed lately that
they don't have a solution and now try to artificially delay everyone
else to their pace.

I suggest that we will avoid such accusations, and concentrate on the
goal, which is to provide a good protocol (and just to be clear - I am
NOT accusing anybody, in fact I am pretty sure that this was not the
intent of CRACK authors).

Hybrid is not only more mature, it is also more secure, flexible and
efficient.

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@CheckPoint.com
fn:Moshe Litvin
end:vcard
References: