It is useful, but is it correct ? I could understand that if the server uses GSS_C_NO_CHANNEL_BINDINGS in gss_accept_sec_context it accepts a context with or without bindings, but if the server requires channel binding the client shouldn't be able to switch it off by using GSS_C_NO_CHANNEL_BINDINGS.
Markus "Donn Cave" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Markus Moeller) wrote: > > > I noticed that from MIT version 1.2.4 to 1.3.1 the gss_accept_sec_context > > call > > has changed in ftpd.c. It is now set to use always GSS_C_NO_CHANNEL_BINDINGS. > > I also noticed that changing the channel bindings in gss_init_sec_context on > > the client doesn't create an error I would expect. > > > > I also see a different behaviour in my proftpd mod_gss module. If the client > > uses gss_init_sec_context with GSS_C_NO_CHANNEL_BINDINGS, the channel > > bindings > > settings in gss_accept_sec_context on the server are ignored (e.g if the > > server uses channel bindings with application data set and the client used > > GSS_C_NO_CHANNEL_BINDINGS the client can login) > > > > Is this intention ?? > > I can't speak for the MIT Kerberos developers, but I feel > fairly confident that it was not an accident. Moreover, > it is quite useful for GSS Fetch users behind NATs, for > example. > > Donn Cave, [EMAIL PROTECTED] > ________________________________________________ > Kerberos mailing list [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
