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