gssapi and CCC command

[Glen Matthews]

Hi,

  thanks for the previous response, marc.

  ok, here's the sequences. Note that these are re-typed, not captured:

The following occurs when the CCC command is *not* attempted.

220 blah FTP server (Version 5.60) ready
AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
ADAT YII.....
ADAT=YGg.....
ENC YDs....   (being "PBSZ 14000" encrypted)
632 YDs....   (being "200 PBSZ=1400", encrypted)
ENC YDs....   (being "PROT P", encrypted)
632 YGM....   (being "200 Data channel level protection set to private",
encrypted)
ENC YDs....   (being "USER xxx", encrypted)
632 YGs....   (being "232 GSSAPI user xxx at REALM is authorized as xxx",
encrypted)
ENC YDM....   (being "SYST", encrypted)
632 YEM....   (being "215 Unix Type: L8", encrypted)
etc...

The following occurs when I try to enable the CCC command.

220 blah FTP server (Version 5.60) ready
AUTH GSSAPI
334 Using authentication type GSSAPI; ADAT must follow
ADAT YII.....
ADAT=YGg.....
ENC YMD....   (being "CCC" encrypted)
632 YEs....   (being "200 CCC command successful", encrypted)
PBSZ 14000    (not encrypted)
631 YDs....   (being "200 PBSZ=1400", encrypted)
PROT P        (not encrypted)
631 YGM....   (being "200 Data channel level protection set to private",
encrypted)
USER xxx      (not encrypted)
631 YIG....   (being "331 GSSAPI user xxx at REALM is not authorized as XXX;
Password required", encrypted)
PASS yyy      (not encrypted)
631 YEM....   (being "530 Login incorrect", encrypted)

i note that i get a 632 confidential reply as the reponse to CCC, thereafter
i get 631 replys (integrity protected only). moreover, the 331 message
*quotes* the xxx account as XXX - any attempt using unix login is bound to
fail if that is being used. note in the first sequence, in the 232 msg that
the "xxx" account is in lower case in both places that it appears in the
message.

perhaps you can see why i'm confused ... :-)

glen


>> however, you might get back a 200 level message (as above)
>> indicating that you are authorized (or you might get a password
>> request - fine - but when i send the password associated with the
>> xxx account, i get the 500 login incorrect message).
>>
>> i'm basically doing the same thing with CCC enabled as i do with it
>> disabled, except for encrypted the commands, and in fact commands
>> seem to work (PBSZ and PROT, as i said before) - the *user* command
>> seems to fail at the server. responses come back encrypted. what
>> i've noticed is that without the CCC command, a USER command
>> unencrypted results in a 500 level message that says that all
>> commands must be encrypted, so it's having some effect. i can
>> accept that there is a bug in the server code - anyone aware of
>> this? - but what i'm chiefly wondering is if i'm reading the rfc
>> correctly.

I'm a little lost here.  Your two messages seem to have conflicting
descriptions about what you are doing.  If you could say exactly what
commands and responses you are sending and receiving (decrypted :-) in
order, in both the CCC and non-CCC cases, that would help a lot.

A bug in the server code with a non-MIT client is certainly a
possibility.

                Marc
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
http://mailman.mit.edu/mailman/listinfo/kerberos