GSS-API Authentication Mode for ISAKMP/Oakley

canetti@watson.ibm.com (Ran Canetti) Fri, 05 December 1997 16:44 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00983 for ipsec-outgoing; Fri, 5 Dec 1997 11:44:44 -0500 (EST)
Date: Fri, 05 Dec 1997 12:05:43 -0500
From: canetti@watson.ibm.com
Message-Id: <9712051705.AA17214@ornavella.watson.ibm.com>
To: ddp@network-alchemy.com, ipsec@tis.com
Subject: GSS-API Authentication Mode for ISAKMP/Oakley
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Dear Derrell,

I'm having hard time understanding the GSS-API authentication mode
fo ISAKMP/Oakley (draft-ietf-ipsec-isakmp-gss-auth-00.txt).

First, to put us on a common ground:  I understand that the premise of the
draft is that the GSS-API is acting as a key-distribution center of a
Kerberos-like system. Thus the GSSi and GSSr are tokens that contain
(among other things) a shared key K for the initiator and responder; 
in GSSi the value K is encrypted with the initiator's key, and in GSSr 
the value K is encrypted with the responder's key. The center knows both the
initiator's and responder's keys. Please correct me if I'm wrong here.

My most immediate problem with the draft is that the exchange (in 4.2)
does not seem authenticated at all: it looks as if a straightforward
man-in-the-middle attack would work. This is because the only secret
information in HASH_i and HASH_r is g^xy. Thus, a man in the middle
can successfully pretend to be the other party by choosing its own x,g^x
and playing the exchange in a straightforward way.
What am I missing here?

Another, more basic problem has to do with the approach taken here.
It seems that "the right way" to design this mode would be  to let the 
parties first agree on a shared key K using the kerberos-style exchange via the
GSS-API, and then have the parties do the ISAKMP/Oakley  exchange in 
pre-shared key mode, with key K as the preshared key.
(True, some technical protocol problems arise here, such as that the 
pre-shared key mode does not currently allow for key-id to be transmitted.
But this can be solved in a number of ways, say by adding a GSS-token type
to the ISAKMP ID payload, and using this field to transmit the key id.)
Certainly there seems to be no need to design a new cryptographic exchange
here.


We can discuss it more in DC if you wish.


Ran Canetti



I'd like to thank Pau-Chen Cheng and Hugo Krawczyk for reading and
discussing the draft with me.