Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.9.3p2) with ESMTP id BAA03442; Fri, 12 Dec 2003 01:27:59 -0500 (EST)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id hBC6RbAw026054; Fri, 12 Dec 2003 01:27:37 -0500 (EST)
Received: from mit.edu ([18.101.0.226]) (authenticated bits=56) (User authenticated as raeburn@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hBC6RYRw022350 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 12 Dec 2003 01:27:36 -0500 (EST)
Date: Fri, 12 Dec 2003 01:27:33 -0500
Subject: gssapi ftpd bugs with CONTINUE_NEEDED
Content-Type: text/plain; charset=US-ASCII; format=flowed
MIME-Version: 1.0 (Apple Message framework v553)
Cc: Ken Raeburn <raeburn@mit.edu>
To: krb5-bugs@mit.edu
From: Ken Raeburn <raeburn@MIT.EDU>
Content-Transfer-Encoding: 7bit
Message-Id: <45663275-2C6C-11D8-8259-000A95909EE2@mit.edu>
X-Mailer: Apple Mail (2.553)
X-RT-Original-Encoding: us-ascii
Content-Length: 605

Our ftpd code doesn't cope with a CONTINUE_NEEDED status from 
gss_accept_sec_context.  The wrong variable is checked in at least one 
case.  One message gets sent to the client with the token to be 
returned, and then another message with a different status code is also 
sent.  Probably other things are going wrong too.  I don't think we've 
tested this path before.

The CONTINUE_NEEDED status can be returned under the new CFX support if 
a context establishment token is received with an unrecognized TOK_ID 
value.  The test code I've set up for CFX can exercise this path when 
compiled in.

Ken