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.
- GSS-API Authentication Mode for ISAKMP/Oakley Ran Canetti