[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New XAUTH draft
I mentioned SSL as a choice. It could very well be another IKE exchange.
My question was more related to 'why not use IKE as it exists today
to do legacy authentication instead of extending it'.
Thanks,
-- sankar --
-----Original Message-----
From: Roy Pereira [mailto:rp96@hotmail.com]
Sent: Thursday, September 30, 1999 6:59 PM
To: Sankar@vpnet.com; dharkins@network-alchemy.com;
Stephen.Waters@cabletron.com
Cc: ipsec@lists.tislabs.com
Subject: RE: New XAUTH draft
Why add the burden of supporting SSL to an IPSec device? That's one of the
things XAUTH was trying to accomplish; don't add anything more than you have
to. IKE exists and it works well. Just extend it to support other forms of
authentication.
Of course, we can get into a entire thread of the truelly secure nature of
SSL as compared to IKE.... 8-(
>From: Sankar Ramamoorthi <Sankar@vpnet.com>
>To: "'Dan Harkins'" <dharkins@network-alchemy.com>, "Waters,
>Stephen" <Stephen.Waters@cabletron.com>
>CC: ipsec@lists.tislabs.com
>Subject: RE: New XAUTH draft
>Date: Thu, 30 Sep 1999 12:05:39 -0700
>
> > It's not the distribution of the group pre-shared secrets that's the
> >problem (remember MKMP? That was a marvelously secure, simple (3
>messages),
>
> >and mutually authenticated way to distribute a group secret. I also
> >remember people screaming "but if more than two people know the secret
> >then it isn't a secret anymore."). It's that you lose authentication that
> >way. draft-ietf-ipsec-internet-key-01.txt was an April Fools draft but
> >the security considerations of that were very real. Unfortunately that
> >draft expired so let me quote it:
> >
> > The use of pre-shared keys has known security implications. When used
> > for authentication, the presentation of a shared secret is proof of
> > identity. When used for datagram authentication, the pre-shared key
> > authenticates the content and source of the datagram. Using the
> > Pre-Shared Key for the Internet will, in effect, allow you to
> > authenticate everyone. One drawback is that this will negate the
> > effects of all related security protocols.
> >
> > It might "make no difference to IKE" if you use the pre-shared key for
> >the internet in doing IKE but that is just plain stupid. And, yes, it can
> >restrict it by simple MUST NOT verbage. That's the whole point.
> >
> > Since XAUTH provides _absolutely_ _no_ _additional_ _security_ to the
> >IKE secret state what you're ending up with is unauthenticated IPSec SAs!
> >There's no way that the customer can manage this. It just plain doesn't
> >work.
> >
> > If you want to do things insecurely then make up a simple insecure
> >unauthenticated key exchange and do XAUTH on top of that.
> >
>
>I agree.
>
>If we do something like
>
>1) Use SSL/IKE exchange (with group(weak) key) to authenticate
>the end-user device
>
>2) Do legacy authentication(securid, token card) to authenticate the client
>
>
>3) Create a unique shared secret for the authenticated user
>
>4) Use it do regular IKE exchanges between the client and the server
>
>
>What is the need to extend IKE?
>Isn't all that is needed is a simple protocol on top of IKE (and separate
>from IKE)?
>
>
>Thanks,
>
>-- sankar ramamoorthi (sankar@vpnet.com) --
>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com