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

Re: New XAUTH draft

To: Dan Harkins <dharkins@network-alchemy.com>
Subject: Re: New XAUTH draft
From: David Jablon <dpj@IntegritySciences.com>
Date: Thu, 30 Sep 1999 13:19:40 -0400
Cc: "Waters, Stephen" <Stephen.Waters@cabletron.com>, ipsec@lists.tislabs.com
In-Reply-To: <199909301612.JAA27379@Potassium.Network-Alchemy.COM>
References: <Your message of "Thu, 30 Sep 1999 14:33:26 BST." <29752A74B6C5D211A4920090273CA3DCCDE3AF@new-exc1.ctron.com>
Sender: owner-ipsec@lists.tislabs.com

Dan,

Your emphatic point about how XAUTH does not increase the
secret IKE state raises an interesting question.

Wouldn't it be nice for IPSEC to provide a way for an
additional authentication scheme to increase the quality of
the session key?

My interest in this problem is to leverage the power of
"legacy" credentials, but not by relying on legacy protocols.
Specifically, I'm thinking about how protocols like SPEKE can
leverage legacy credentials, without the limitations of legacy
protocols.  I know that XAUTH does not provide this, but
neither does IPSEC as it is defined today.

-- David

At 09:12 AM 9/30/99 -0700, Dan Harkins wrote:
>  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.

---------------------------------------------------
David P. Jablon           dpj@IntegritySciences.com
President                 +1 508 898 9024
Integrity Sciences, Inc.  www.IntegritySciences.com

Next by Date: Unspecified Lifetime
Next by thread: Re: New XAUTH draft
Index(es):
- Main
- Thread