I agree as far that the server should be able to enforce channel binding or not. If the server uses NO_C_CHANNEL_BINDINGS, the server should accept clients sending channel bindings and clients who don't. In this case NAT should work. But if the server requires channel bindings the client has to send the correct bindings. If the client send NO_C_CHANNEL_BINDINGS the server should reject the connection.
Regards Markus "Sam Hartman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >>>>> "Jeffrey" == Jeffrey Altman <[EMAIL PROTECTED]> 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 > > ________________________________________________ > Kerberos mailing list [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
