[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on CRACK
CRACK is designed to allow legacy authentication in the IKE framework,
where a limited amount of Public Key technology is involved i.e. The
server has a public key and the client can verify it.
CRACK is not the first suggestion to provide this functionality, a fact
that probably alluded the authors (otherwise they would have
acknowledged previous suggestions). As a matter of fact, a draft
solving the exact same problems has been around for over a year now.
Considering this, anyone who comes up with a new proposal should
justify going back a year in the process and starting all over again.
Comparing CRACK to the hybrid protocol there is one advantage to CRACK
over the current hybrid protocol.
The authentication is all done during one "phase 1" exchange, thus
avoiding the "limbo" state of the IKE SA, when the IKE SA is created but
can only be used for the XAUTH exchange. Having the whole process done
in one exchange also reduces the number of packets in the negotiation.
Actually, for those of you who have been following the IPSEC mailing
list, this was the situation in the original hybrid proposal.
Comments received on the mailing list made us change this because:
1. People did not like the idea of making the phase 1 open ended.
2. People did not like the idea of making big changes to phase 1.
3. We wanted to make Hybrid co-exist with existing proposed mechanisms
(XAUTH).
Being an co-author of Hybrid, I tend to agree that having this done in a
single exchange is better. But, in my view, this advantage does not
constitute a good enough reason to start all over again.
The CRACK authors also claim to have a better binding between the keying
material and the authentication process. I fail to see why. The fact
that the authentication is signed by the client gives a warm fuzzy
feeling about the process. It even suggests the notion of
non-repudiation. But careful examination reveals that there is no
non-repudiation (If the server can generate the challenge/response
sequence it can generate one allegedly signed by the client).
The way I see it, an adversary can either break the DH exchange or not.
If it can break it, then he has completely broken the IKE protocol.
However, if it cannot break it, I don't see how you are better of with
the client signing
the exchange.
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.
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.
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?
Regards,
Moshe Litvin
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: