RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else)

Vipul Gupta <Vipul.Gupta@Eng.Sun.Com> Tue, 20 July 1999 21:22 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14598; Tue, 20 Jul 1999 14:22:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29310 Tue, 20 Jul 1999 15:40:15 -0400 (EDT)
Date: Tue, 20 Jul 1999 10:48:48 -0700
From: Vipul Gupta <Vipul.Gupta@Eng.Sun.Com>
Reply-To: Vipul Gupta <Vipul.Gupta@Eng.Sun.Com>
Subject: RE: KISS for PKIX. (Was: RE:Asymmetric authentication (was ASN.1 vs XML which in turn was something else)
To: kent@bbn.com, Stephen.Waters@cabletron.com
Cc: ietf-pkix@imc.org, ipsec@lists.tislabs.com
Message-ID: <libSDtMail.9907201048.15393.vgupta@hsmpka>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: NdTMbAmTW4dHZWpKUJA3jQ==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

> >>On a related point, since IKE XAUTH is typically one-way (server
> >>authenticating client), secondary authentication does leave the problem of
> >>the server being spoofed with a compromised key!
> 
> >I thought it was one way the other way, i.e., server is authenticated to
> >client via a cert, but client uses only "legacy" auth to server.  If it
> >were the other way around it would be awful, as it would open a variety of
> >attacks against the legacy systems which could diminish their
> >effectiveness.  For example, S/Key is very vulnerable to active server
> >spoofing attacks.
> 
> I think there has been a proposal along those lines (asymmetric
> authentication), but the XAUTH draft does not cover that (I don't think). A
> normal symmetric Phase-1 authentication
> (pre-shared,signature,encrypted-nonce) is followed by a one-way secondary
> authentication via XAUTH.
> 
> Cheers, Steve.

  The "Hybrid Authentication" draft:
  
      draft-ietf-ipsec-isakmp-hybrid-auth-02.txt
      
  discusses asymmetric authentication (server is authenticated via
  a digital signature and the client uses OTP/token card etc). The
  hybrid authentication draft uses a slight modification of Main/Aggressive
  mode in which only the responder (server) is authenticated --
  the initiator sends only a hash rather than a signature. This is 
  immediately followed by an XAUTH exchange in which the client
  authenticates to the server using a "legacy" mechanism. This 
  approach is very similar to how web-based banking works -- the
  bank's server is authenticated via a signature during SSL negotiation
  and the user is authenticated via a password sent over HTTPS.
  
  I don't quite see the motivation behind XAUTH if it is used in
  conjunction with regular Main/Aggressive mode since each of those
  modes provides mutual authentication. If the client has already
  been authenticated in Main/Aggressive mode, what is the additional
  functionality provided by XAUTH? Or is it that the pre-shared key
  used in Main/Aggressive mode common to *all* clients (e.g. all 
  corporate employees) and XAUTH is used to identify a particular
  client?
  
  thanks,
  
  vipul