Hi, 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?)
the thing is that the authentication is in fact done via gssapi, and a security exchange with the ftp server via ADAT commands. this does indeed succeed. i get back a 235 message from the server, indicating that the security exchange has completed successfully, and that no additional data is needed. further, when i then pass the returned security data to the kerberos server (because i had previously received GSS_CONTINUE_NEEDED) it too indicates that the security exchange is complete. in response to an encrypted USER command (USER xxx) i get back: 232 GSSAPI user xxx@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. 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. glen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marc Horowitz Sent: Thursday, April 11, 2002 6:48 PM To: [EMAIL PROTECTED] Subject: Re: gssapi and CCC command I haven't looked at the MIT code in a long time, but I just took a quick glance, and it looks like either the username is invalid, or the initial password request fails. If you can look at the kdc logs, find out if the AS-REQ is really succeeding. I also have to mention that using CCC isn't a very good idea. It was defined and implemented at a time when the Internet was a less hostile place, and when US export laws were still very relevant. It's an especially bad idea to transmit the password in the clear, as you seem to be attempting to do. Today, I would recommend implementing the full spec, it's a lot more secure that way. Marc [EMAIL PROTECTED] ("Glen Matthews") writes: >> Hi, >> >> i'm writing an ftp client using the gssapi with kerberos, and am somewhat >> puzzled by the CCC command behaviour. >> >> basically, when i enable clear channel commands using CCC, it is accepted >> with a 200-level message. i can enter various commands (notably PBSZ, PROT - >> these seem to work ok). however, when i try to enter something else (like a >> pwd) i get a 500 level message requiring a login before commands. ok. that >> sort of fits - without enabling CCC, i need to send a login (encrypted) and >> i get back a message stating that i've been authenticated. >> >> when i try to issue a user command, i get this: >> >> 331 GSSAPI user "xxx@REALM" is not authorized as "xxx"; Password required >> >> which is fine - "xxx@REALM" is the kerberos principal logging in, and xxx is >> the userid on the target system. when the pass command is issued (with the >> correct password even), i get 530 login incorrect. >> >> any ideas? is this a config problem with the kerberized ftpd? or a problem >> implementing the security protocol? >> >> glen >> >> >> ________________________________________________ >> Kerberos mailing list [EMAIL PROTECTED] >> http://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
