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

Re: Comments on CRACK

-----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."

> 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.

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.

- -- Will

Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.



-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBOBWcB6y7FkvPc+xMEQKIWACdE3veqzInavV9nO9AdKzE91fakEoAmgJa
Ag73xZzv2mvSL6kSEsS7mi6a
=vpmX
-----END PGP SIGNATURE-----
Follow-Ups: References: