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

From: Vipul Gupta <[email-masked]>
Date: Tue, 20 Jul 1999 10:48:48 -0700 (PDT)

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

---

From: Dan Harkins <[email-masked]>
Date: Tue, 20 Jul 1999 13:58:04 -0700

On Tue, 20 Jul 1999 10:48:48 PDT Vipul Gupta wrote
>   corporate employees) and XAUTH is used to identify a particular

  Exactly! I brought this point up back in May. If the IKE SA has been
authenticated properly then XAUTH doesn't buy you anything. You have
the double burden of supporting a PKI and some legacy database and
the user gets yet another dialog box asking for yet another passphrase.
I find it very hard to believe that this is what people are doing when
I hear that "customers want XAUTH".

  For XAUTH to provide anything the IKE SA is authenticated with some
shared key and then the "client" authenticates himself to the "server"
with the legacy method. The problem with this is that the IKE SA and
all the SKEYID state is not authenticated. Therefore all the keys in
the IPSec SAs are not authenticated. Depending on the legacy method
this can be open to a man-in-the-middle attack too.

  draft-ietf-ipsec-internet-key-00.txt is an April Fool's draft but
the security considerations is right on in this respect.

  Dan.