gss_accept_sec_contextand channel binding in ftp

[Markus Moeller]

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" <donn at u.washington.edu> wrote in message
news:donn-8ADAF4.15275204062004 at nntp2.u.washington.edu...
> In article <loom.20040604T154031-39 at post.gmane.org>,
>  huaraz at btinternet.com (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, donn at u.washington.edu
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>