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

Re: Comments on CRACK

  Moshe,

On Mon, 25 Oct 1999 17:23:29 +0200 you wrote
> 
> 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.

I'm sorry for leaving out reference of Hybrid. It was not meant as a
slap-in-the-face and I'll see it gets rectified in -01.txt.

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

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

It also solves the problem with one single draft. There was much moaning
and groaning (rightfully so) about having 3 separate standards track RFCs
and an Informational RFC just to do a single key management protocol. I've
heard lots of griping about jumping from paper to paper. So instead of
having ISAKMP-Config plus XAUTH plus Hybrid just to allow for remote 
client authentication we can have CRACK.

But you're right. The phase 1.5 "limbo" state of the IKE SA is a hack. It
screws up the state machine for no reason. Some SAs transition to phase 2
immediately and some have to wait around for more stuff to happen.

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

This was at a time when we were trying to get the first set of mutually-
referencing drafts out the door. Changing the protocol to support this
was not viewed positively at that time. Times have changed.

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

If the server maintains the secret database itself and knows what a valid
client response looks like then yes this is possible. Practically though the 
server will pass an opaque blob off to an authentication server who will 
say yea or nea and log it. If this authentication server is generating bogus 
challenge/responses then all bets are off anyway. 

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

Security is not free. 

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

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

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.
Follow-Ups: References: