[20063] in Kerberos_V5_Development
Re: Current semantics for channel-bindings in GSSAPI
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Thu Mar 19 06:06:19 2020
MIME-Version: 1.0
In-Reply-To: <5a606707-7d91-938c-ba4e-c238643575fb@samba.org>
From: Isaac Boukris <iboukris@gmail.com>
Date: Thu, 19 Mar 2020 11:05:57 +0100
Message-ID: <CAC-fF8QXWGr7vK8+u4YzBrhGX4N=uZMvJjobg4MsjiYTCXBz8Q@mail.gmail.com>
To: Stefan Metzmacher <metze@samba.org>
Cc: "krbdev@mit.edu Dev List" <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>,
Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Hi all,
On Tue, Mar 10, 2020 at 5:25 PM Stefan Metzmacher <metze@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@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@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 think we should be able to accomplish the above requirements with
gss_create_sec_context(), the initiator could create it with
'client_aware_cb' flag (overriding global), and the acceptor could set
'channel_bindings_enforcement_level' to require level=2.
I think that would help making eventual changes to current
applications code, simpler.
btw, do we really need gss_create_sec_context() +
gss_set_sec_context_option(), can't we use just
gss_create_sec_context(flags) ?
> > Honestly I'd say we can start with the krb5.conf option, I think it
> > has value anyway as it allows to protect applications system-wide
> > without the need to update them.
>
> Yes, a global option should be there!
>
> > Then eventually, use cred/context
> > options to override it, as we decide.
> >
> > btw, as mentioned "off-list" Windows seem to skip channel-bindings
> > check if the client omits the checksum altogether, even in level=2. I
> > think it is a bug, and we shouldn't return channel-bound flag it that
> > case.
>
> I think your code is fine as it only sets cb_match = true if we did the
> memcmp and the 16 bytes match exactly.
Yeah, I've also reached out to MS and according to them this will be
fixed in future Windows versions as well.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
