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 18:09 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09604 for <pkix-archive@odin.ietf.org>; Tue, 20 Jul 1999 14:09:41 -0400 (EDT)
Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA09800; Tue, 20 Jul 1999 10:56:20 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jul 1999 10:56:18 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09773 for <ietf-pkix@imc.org>; Tue, 20 Jul 1999 10:56:18 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02609; Tue, 20 Jul 1999 10:58:02 -0700 (PDT)
Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.53.47]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA26376; Tue, 20 Jul 1999 10:58:01 -0700 (PDT)
Received: from nobel by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01574; Tue, 20 Jul 1999 10:57:59 -0700
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
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe

> >>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