gss_accept_sec_contextand channel binding in ftp

[Markus Moeller]

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" <hartmans at mit.edu> wrote in message
news:tsly8mxn6no.fsf at konishi-polis.mit.edu...
> >>>>> "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
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>