Current semantics for channel-bindings in GSSAPI

Stefan Metzmacher metze at samba.org
Tue Mar 10 11:54:07 EDT 2020


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:
>>
>> Hi Issac,
>>
>>> 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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20200310/816c81cc/attachment-0001.bin


More information about the krbdev mailing list