[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on CRACK
Hi Dan,
<snip>
>
> 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.
<snip>
It may not be the most optimal way of doing it, but it was the path of less
resistance about a year ago.
It also has some advantages in that it can be used with Main Mode,
Aggressive Mode, and any other new mode (ex. Base Mode, Hybrid).
The state machine is actually pretty simple.
Phase 1
XAUTH [based on authentication method negotiated]
Isakmp-Cfg [optional]
Phase 2
<snip>
>
> 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.
>
<snip>
I beg to differ. XAUTH is not "broke". XAUTH fully accomplishes what it
intended to do.
>From the XAUTH draft...
"The purpose of this draft is not to replace or enhance the existing
authentication mechanisms described in [IKE], but rather to allow them to be
extended using legacy authentication mechanisms."
XAUTH has indeed accomplished this. No one has uncovered any security flaws
with XAUTH itself as a protocol.
There is one point that has been brought up which I would like to debate.
-The use of XAUTH with pre-shared keys only encourages the use of weak
pre-shared keys.
My problem with this is that this seems like a security administrators job
to ensure that the strength of the authentication mechanisms be well chosen
and secure. There's a lot of ways that an administrator could shoot himself
in the foot. I know that doesn't justify giving them one more bullet to
shoot themselves with. However, I would like to hear everyone else's
opinion on this. Should the use of pre-shared keys be restricted in XAUTH
(or whatever other protocol) because it encourages the use of weak
pre-shared keys?
If there is concensus, pre-shared keys can be removed from XAUTH. I don't
think that we have concensus at this point.
As for CRACK...
What is the benefit of the Client's PK?
It seems to me that the Gateway trusts the PK's origin because it is sent
over a secure channel, and because it is authenticated by the CHRE
exchanges. Then, the Client further authenticates himself by using his
private key to sign the exchange.
I don't see the point of this. It's like saying tell me a question and the
answer to that question. Then I'll ask you the question and make sure you
have the right answer.
I know that's oversimplifying it. Am I missing something... what does it
accomplish?
I think what we all want is a secure interoperable way of doing legacy
authentication as a migration path to PKIs. I don't see what advantages
CRACK is presenting over Hybrid/XAUTH (aside from preventing pre-shared
keys). I do see CRACK as a set-back.
People already have working implementations of Hybrid and XAUTH. Some of us
have this in released builds in the field. Some people have already tested
interop. at the bakeoff. So unless someone can state that Hybrid and XAUTH
are truly broken, then I don't see the point in changing it at this point in
the game.
Thanks,
Stephane.
Follow-Ups: