Jeffrey Altman wrote:
FTP AUTH GSS cannot be implemented with SEQUENCE protection if
the client plans on sending data on the command channel while
there is an active data channel using the GSS context.  This is
a serious problem for GUI FTP implementations which issue
STAT commands for status updates; or for other implementation
wishing to protect against NAT/firewall timeouts.

I have a proposal to fix this but the changes are incompatible
with the current implementation.  Hopefully I will find the
time to work on submitting it to the IETF.

According to my sources, the Globus gridftp uses seperate contexts for the control data channel, and uses SEQUENCE on both. Since FTP is really a three party transfer, this make sense.



Jeffrey Altman



Markus Moeller wrote:


The MIT ftp client uses only the REPLAY flag, which I think should be
changed to the SEQUENCE FLAG to provide the correct protection for the data
channel.

 gss_init_sec_context(&min_stat,
        GSS_C_NO_CREDENTIAL,
        &gcontext,
        target_name,
        (gss_OID_desc *)gss_trials[trial].mech_type,
        GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG |
          (forward ? GSS_C_DELEG_FLAG :
    (unsigned) 0),
        0,
        &chan, /* channel bindings */
        token_ptr,
        NULL, /* ignore mech type */
        &send_tok,
        NULL, /* ignore ret_flags */
        NULL); /* ignore time_rec */


Will I get problems with the SEQUENCE FLAG if I want to send a NOOP on the command channel during a transfer happens on the data channel (.e.g. to keep to command channel open through firewalls ) as the client and server have to process the data in sync which is not necessarily given ?

Thanks
Markus

"Sam Hartman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]


"Markus" == Markus Moeller <[EMAIL PROTECTED]> writes:

Markus> will Sequence protection (GSS_C_SEQUENCE_FLAG)cover replay Markus> protection (GSS_C_REPLAY_FLAG) as well or are there cases Markus> were I need both ?

I'd recommend using both, but I believe sequence is typically a
superset.

________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos





________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos




--

 Douglas E. Engert  <[EMAIL PROTECTED]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444
________________________________________________
Kerberos mailing list           [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to