Current semantics for channel-bindings in GSSAPI

Isaac Boukris iboukris at gmail.com
Fri Mar 20 17:19:02 EDT 2020


On Thu, Mar 19, 2020 at 1:55 PM Simo Sorce <simo at redhat.com> wrote:
>
> On Thu, 2020-03-19 at 11:05 +0100, Isaac Boukris wrote:
> > Hi all,
> >
> > On Tue, Mar 10, 2020 at 5:25 PM Stefan Metzmacher <metze at samba.org> wrote:
> > > Am 10.03.20 um 17:18 schrieb Isaac Boukris:
> > > > On Tue, Mar 10, 2020 at 4:54 PM Stefan Metzmacher <metze at samba.org> wrote:
> > > > > Am 10.03.20 um 16:34 schrieb Isaac Boukris:
> > > > > > On Tue, Mar 10, 2020 at 4:23 PM Stefan Metzmacher <metze at samba.org> wrote:
> > > > > > > > As discussed last week, we want the following changes.
> > > > > > > >
> > > > > > > > - MIT should match Heimdal behavior and only error if client bindings
> > > > > > > > are not all zeros.
> > > > > > > > - Both Heimdal/MIT should return channel-bound flag if the bindings did match.
> > > > > > > > - Both Heimdal/MIT should take advantage of KERB_AP_OPTIONS_CBT if
> > > > > > > > present if authenticator, in which case if the server passed bindings
> > > > > > > > they must match.
> > > > > > > > - Both Heimdal/MIT should provide a conf option to asset the client
> > > > > > > > system supports channel-bindings, causing KERB_AP_OPTIONS_CBT to be
> > > > > > > > sent in any ap-req.
> > > > > > > >
> > > > > > > > I submitted wip PR #1047 upstream MIT based on the above.
> > > > > > > >
> > > > > > > > @metze, would that satisfy samba's requirements?
> > > > > > >
> > > > > > > I looked briefly and the core changes look good,
> > > > > > > but (as always :-) I think krb5.conf option alone are unflexible
> > > > > > > and I'd really like to get rid of autogenerated krb5.conf files and
> > > > > > > global exporting "KRB5_CONFIG". So APIs to turn this on from the
> > > > > > > application would be great.
> > > > > >
> > > > > > Ok, so we'd need a new cred-option to override it by the application.
> > > > >
> > > > > If we can agree on a way to implement that:-)
> > > > >
> > > > > Using gss_set_cred_option() would be the simplest solution,
> > > > > but it got rejected for GSS_KRB5_CRED_NO_TRANSIT_CHECK_X.
> > > > > Passing cred_store to gss_acquire_cred_from() would also work
> > > > > and I'm not sure if/how gss_create_sec_context() +
> > > > > gss_set_sec_context_option() would work.
> > > > >
> > > > > gss_set_sec_context_option() would be the most flexible way
> > > > > and may be useful for more things I plan to implement.
> >
> > Looking more at PR 685 code, I can't help but thinking:
> > If we are ok with gss_create_sec_context(), maybe it would be better
> > to bring that forward instead of GSS_C_CHANNEL_BOUND_FLAG return flag.
>
> I strongly believe we should proceed with the plan we drafted as it
> minimized the need to change applications.

Agreed.

BTW, it looks like both Heimdal/MIT do not handle the bindings in the
DCE style case, so we'd just not return channel-bound in that case.


More information about the krbdev mailing list