gss_accept_sec_contextand channel binding in ftp

Sam Hartman hartmans at MIT.EDU
Tue Jun 8 16:20:27 EDT 2004

>>>>> "Jeffrey" == Jeffrey Altman <jaltman2 at> writes:

    Jeffrey> Sam Hartman wrote:
    >>  P It's authenticated.  So if both sides use it then it will be
    >> verified and required to be correct.
    >> As I consider the current behavior more I don't like the MIT
    >> server's tendency to discard client channel bindings though.  I
    >> believe a server should be able to require channel bindings.

    Jeffrey> If I remember the history behind this change in behavior
    Jeffrey> correctly, it went something like this.  NATs were
    Jeffrey> causing connections between otherwise authenticated
    Jeffrey> parties to fail when used with GSS channel bindings.
    Jeffrey> Some GSS implementations (MS SSP) did not even support
    Jeffrey> channel bindings.  This made it impossible for many
    Jeffrey> clients to even establish connections with GSS enabled
    Jeffrey> servers such as FTP.

Up to this point I agree with you.

    Jeffrey> It would be impossible for the Kerberos team to get all
    Jeffrey> server implementations to stop specifying the channel
    Jeffrey> bindings but we could cause the interpretation of them to
    Jeffrey> become optional.  This would allow clients which did not
    Jeffrey> support or specify channel bindings to be able to
    Jeffrey> authenticate to the servers and get work done.

If you replace server with client I agree with you.  I don't believe
it is unreasonable to get server implementers to specify channel
bindings and I believe most have done so by now.  Also, note that the
code will set up the address checks if the server supplies channel
bindings, so the current code will not work with NATs if the server
does supply channel bindings.

Since NATs are the primary reason for this change and since the change
doesn't actually fix the problem for NATs, I propose to back it out.


More information about the Kerberos mailing list