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

Re: Comments on CRACK

On Tue, 26 Oct 1999 14:36:14 EDT you wrote
> > 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 himsel
>f
> > 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 we need to take shared-secret  out of XAUTH, then why not out of IKE
> all together?

I guess it could but in IKE the peers are mutually authenticated. That's
the whole point. And it's peer-to-peer, not peer-to-multipeer. That
changes with XAUTH. XAUTH says:

  "If mutual authentication is not required, then the phase 1
   negotiation MAY use an authentication method of shared-secret and
   have that shared-secret be null."

Which is just insane! You're saying that people can do an unauthenticated
Diffie-Hellman in a security protocol. Since XAUTH does not change that
fact-- i.e. it does not contribute to SKEYID in any way shape or form--
what you end up with unautheticated IPSec SAs. In fact, the above statement
is non-compliant with RFC2408. As was pointed out on the list a few weeks
ago (I can't find the mail though :-( ) ISAKMP says:

  "Strong authentication MUST be provided on ISAKMP exchanges.  Without
   being able to authenticate the entity at the other end, the Security
   Association (SA) and session key established are suspect."

> The point here is that XAUTH merely extends IKE and thus incorporates
> all of its security (or lack of).  Why is shared-secret IKE different
> than shared-secret XAUTH?

No it does not. XAUTH does not contribute any security to IKE; it is
Xtranneous Authentication. Pre-shared secret IKE is different than
pre-shared secret XAUTH for the simple matter that IKE does peer-to-peer
authentication. And the pre-shared key is implied to be bound to the
peer. Now I guess you can be a stickler and say that group pre-shared
keys are not explicitly forbidden (and that can be rectified) but neither
is leaking the secret. You could leak the IPSec keys in some sort of
key recovery scheme and _technically_ still be RFC2409-compliant.

So, IKE can include some text to say "don't use a group pre-shared key"
if you like. But just because IKE doesn't say that doesn't mean that it
encourages it. XAUTH does. In fact XAUTH goes even further to say that
an unauthenticated Diffie-Hellman is allowable.

> BTW: I don't like group-shared-secrets, but I strongly beleive that the
> customer has to choose what level of security they want themselves.  We
> can definately suggest the best security, but in the end it is up to the
> customer's paranoia level to determine their security requirements.

But the hairbrained requirements of unsophisticated customers should not
be a driving force in the standardization process. We're engineering a
security protocol not satisfying our respective marketing departments.

  Dan.
Follow-Ups: References: