aggressive mode & draft-ietf-ipsec-isakmp-gss-auth-04.txt
Sheela Rowles <srowles@cisco.com> Sat, 13 November 1999 01:30 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24173; Fri, 12 Nov 1999 17:30:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09210 Fri, 12 Nov 1999 18:44:36 -0500 (EST)
From: Sheela Rowles <srowles@cisco.com>
Message-Id: <199911122347.PAA12146@sigma.cisco.com>
Subject: aggressive mode & draft-ietf-ipsec-isakmp-gss-auth-04.txt
To: ipsec@lists.tislabs.com
Date: Fri, 12 Nov 1999 15:47:06 -0800
Cc: srowles@cisco.com
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello, I have a question regarding the gssapi spec: draft-ietf-ipsec-isakmp-gss-auth-04.txt. It doesn't seem like aggressive mode can work based on the comments in the draft, yet the draft implies that aggressive mode is possible. The draft comments that aggressive mode works for a single token exchange, and if either side encounters GSS_S_CONTINUE_NEEDED, aggressive mode can't be used: "Aggressive Mode works only for a single token exchange. If either side encounters GSS_S_CONTINUE_NEEDED, Aggressive Mode cannot be used and each side should fall back to Main Mode." And for mutual authentication to occur, the mutual_req_flag should be specified to the GSS_Init_sec_context on the initiating side. Rfc2078, the GSSAPI document, specifies that: "GSS_Init_sec_context() returns an output token to be passed to ther server, and indicates GSS_S_CONTINUE_NEEDED status pending completion of the mutual authentication sequence." So, according to the GSS IKE draft, if GSS_S_CONTINUE_NEEDED is encountered then aggressive mode can't be used, and if mutual authentication is specified, then according to the GSSAPI spec, GSS_S_CONTINUE_NEEDED must be returned from the GSS_Init_sec_context. Am I reading too much into the above comments? Is the implication that if the CONTINUE_NEEDED variable is encountered due to clock skew issues, then aggressive mode is not possible, but it's ok if it's encountered due to needing mutual authentication. So, in the normal aggressive mode case based on the last statement, we would have: Initiator Responder ----------- ----------- GSS_Init_sec_context returning GSS_S_CONTINUE_NEEDED HDR, SA, KE, Ni, IDii, GSSi --> GSS_Accept_sec_context returning GSS_S_COMPLETE <-- HDR, SA, KE, Nr, IDir, GSSr, HASH_R GSS_Init_sec_context returning GSS_S_COMPLETE HDR, HASH_I --> Thanks, Sheela
- aggressive mode & draft-ietf-ipsec-isakmp-gss-aut… Sheela Rowles