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

Re: Comments on CRACK



Dan,

Dan Harkins wrote:

<snip>

> > Considering this, anyone who comes up with a new proposal should
> > justify going back a year in the process and starting all over again.
>
> I don't see this as starting the process over again. The process is just
> getting started, hence the IPSRA.

IPRSA is a new title. But the subject is old, and most of the people involved
today in IPRSA where involved last year in IPSEC.

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"

<snip>

> > What I do see, is an overhead of public key operations, including a
> > signing/verifying action on the server and (RSA) key generation +
> > signing/verifying on the client.
> > Any extra work on the server side must be justified.
>
> Security is not free.
>

Indeed security is not free, but you don't gain security from piling up
cryptographic primitives. If you think that the additional operation provides
better security you will have to justify it. It is not clear to me why the
additional public key of the client add to the security of the protocol.

>
> > On the other hand I see several drawbacks, the biggest one is that it is
> > susceptible to a trivial DoS attack (as already mentioned by Yael). In a
> > protocol designed for roaming clients, where no IP address based
> > filtering is possible this is a show stopper.
> >
> > On top of this, a good protocol designed for client use ought to support
> > error messages in human readable format, as well as error codes. CRACK
> > forbids the former and does not specify the latter.
>
> I don't understand. Can you point out where this is forbidden and perhaps
> show where error codes are specified in the "good protocol"?
>

Section 3.2 IKE Challenge/Response Authentication Failures, the notification does
not include a space for a user readable message (in fact the length of the
notification is fixed). On the other the only place to give a specific error code
the status field is specifically set as private.

As an example of a good protocol, look at ftp (or http) which has a numeric error
code designed for machine consumption, and an additional text to be read by
humans.

>
> > The draft is full of minor issues. As Dan said this is only a 00-draft,
> > but why do we need this when we have a mature protocol in hand?
>
> I wish you'd bring up the minor issues then.
>

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.

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

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

Follow-Ups: References: