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 nyc.rr.com> 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.
--Sam
More information about the Kerberos
mailing list