[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on CRACK
Hi Roy,
Roy Pereira wrote:
>
> 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?
Really, Roy - you surprise me sometimes. You know the answer to this as
well as anyone, but I'll spell it out for expediency. It's different due
to context - xauth is specifically for remote access. Remote access
users typically do not have fixed IP addresses, so we have no way to
identify the preshared key in main mode. Hence, all remote access users
with preshared keys are often configured to use the same key. This is
bad.
Preshared keys are not necessarily bad. I'll bet some very secure
organizations rely almost exclusively upon them. However, increasing the
pool with access to these secrets decreases their security
proportionally.
Comparing psk's in xauth to psk's in IKE is apples vs. oranges.
> Let me ask everyone who is interested; How do we support existing
> legacy user authentication within IKE without using a PKI ?
>
> 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.
Many customers don't understand security, and if they did and were still
willing to use such mechanisms, then they might be better off with a
ppp-based vpn mechanism. Selling them a box which claims to implement
security protocols has implications which are not borne out by this
particular application. Customers may have reasonable security
expectations based upon other representations providers of these
products have made. Think about it.
Scott
Follow-Ups:
References: