Re: Current semantics for channel-bindings in GSSAPI
Isaac Boukris <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <CAC-fF8QwN4wPKKW_ZmrW=jwmRz_GQB8ThzmdVVO6zq3y9wvhXA@mail.gmail.com> |
On Thu, Mar 19, 2020 at 1:55 PM Simo Sorce <[email protected]> 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 <[email protected]> wrote: > > > Am 10.03.20 um 17:18 schrieb Isaac Boukris: > > > > On Tue, Mar 10, 2020 at 4:54 PM Stefan Metzmacher <[email protected]> wrote: > > > > > Am 10.03.20 um 16:34 schrieb Isaac Boukris: > > > > > > On Tue, Mar 10, 2020 at 4:23 PM Stefan Metzmacher <[email protected]> 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. _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev