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. >
If I remember the history behind this change in behavior correctly, it went something like this. NATs were causing connections between otherwise authenticated parties to fail when used with GSS channel bindings. Some GSS implementations (MS SSP) did not even support channel bindings. This made it impossible for many clients to even establish connections with GSS enabled servers such as FTP. It would be impossible for the Kerberos team to get all server implementations to stop specifying the channel bindings but we could cause the interpretation of them to become optional. This would allow clients which did not support or specify channel bindings to be able to authenticate to the servers and get work done. Channel bindings would still be required to be correct if both the client and server specified them. I agree that there does need to be some mechanism by which channel bindings can be specified and they can be considered to be mandatory. This appears to currently be outside the bounds of the current GSSAPIv2 specification and is something that should be discussed on the [EMAIL PROTECTED] mailing list in conjunction with the upcoming Kitten work. Jeffrey Altman -- ----------------- This e-mail account is not read on a regular basis. Please send private responses to jaltman at mit dot edu ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
