gssapi and CCC command

[Marc Horowitz]

glen at montreal.hcl.com ("Glen Matthews") writes:

>>   thanks for your response, marc. actually, i *am* implementing the full
>> spec, all (except for ccc?) of which is working - CCC is just an option
>> (which we will deprecate and warn people about). or at least i think i am -
>> rfc 2228. i don't see any update to that (in fact, it seems to be only a
>> proposed standard - is this correct?)

This is correct.

>>   in response to an encrypted USER command (USER xxx) i get back:
>> 
>> 232 GSSAPI user xxx at REALM is authorized as xxx
>> 
>> my reading of the rfc is that even after a 235 message in response to an
>> ADAT command, you must *still* issue the USER command (to set the home
>> directory?) the state diagram in rfc 2228 indicates this. 

This is alos correct.  After the ADAT exchange completes,
authentication is completed, but the USER command must be issued for
authorization, or else the ftpd will not know which user's privileges
to use. For example, a single GSSAPI name may be authorized to log in
both as a non-privileged user and as root.  It is incorrect to expect
the server to guess the username based on the gssapi name.  Other
applications have tried this, and it always fails when things get
complicated.

>> 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