Current semantics for channel-bindings in GSSAPI

[Stefan Metzmacher]

Am 28.02.20 um 21:33 schrieb Greg Hudson:
> On 2/28/20 12:22 PM, Stefan Metzmacher wrote:
>> As far as I can tell the server enforces them when the client provides
>> them. That means there's a way in the protocol to distinguish between
>> GSS_C_NO_CHANNEL_BINDINGS and struct gss_channel_bindings_struct { 0, }.
>>
>> E.g. for SMB Windows uses 0 zero bytes a valid channel bindings.
>>
>> While KERB_AP_OPTIONS_CBT is needed for that for kerberos.
> 
> RFC 4121 (and 1964) communicate bindings in a 128-bit hash.  Ignoring
> the vanishingly unlikely scenario where all bits of the hash are zero,
> it's possible to distinguish between a client's
> GSS_C_NO_CHANNEL_BINDINGS and any valid channel bindings.
> 
> From Isaac's testing and MS-KILE, it sounds like KERB_AP_OPTIONS_CBT is
> a lever to force applications to supply TLS channel bindings.  It
> enables a weird policy: at server enforcement level 1, client
> applications that don't provide bindings will interoperate if and only
> if they are running on a sufficiently old versions of Windows.  That's
> not a coherent policy in the context of open standards, but it probably
> makes sense for a pure Windows ecosystem.

For SMB windows sends channel bindings of 16 zeros together with
the KERB_AP_OPTIONS_CBT bit set. I would guess the server would reject
the request if the md5sum of gss_channel_bindings_struct { 0, } would be
provided instead.

I guess the bit means that client and server should agree that both
sides use 16 zeros. In that case the AP exchange is protected by
GSS_C_INTEG_FLAG and GSS_C_MUTUAL_FLAG and cannot be reused without
knowing the session key.

>>> * gss_accept_sec_context() has output flags but not input flags.  So
>>> it's easy to add a channel-bound flag indicating that channel bindings
>>> were used; it's significantly harder to add an input flag to indicate
>>> whether channel bindings should be enforced.
>>
>> I think using excplicit acceptor_creds and flag the requested behavior
>> there, it's similar to the ignore transited problem.
>>
>> It would be good to make some generic progress here, as we'll likely
>> need more of these application driven options.
> 
> draft-ietf-kitten-channel-bound-flag does define
> gss_create_sec_context(), and there's an implementation for MIT kicking
> around if we have a need for it.  (The draft as a whole doesn't reflect
> working group consensus as I understand it, but that specific part of it
> could be implemented.)
>
> "Ignore transited policy" would probably be best handled through
> gss_set_sec_context_option(), rather than a GSS request flag.

Using gss_create_sec_context() and
gss_set_sec_context_option(GSS_KRB5_NO_TRANSIT_CHECK_X) instead of
gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) would work for
me from Samba.

But I don't yet understand what it takes to implement that in the
Kerberos libraries as the resulting sec_context is not attached
to the krb5 mech.

> GSS flags are somewhat precious, and the application preference is very
> specifically about tolerating a particular krb5 KDC implementation's
> non-conformance to a specific part of RFC 4120.
>
> Still, for the reasons I laid out, I think channel binding policing is
> best left to the application via an output flag.

I guess it would also be good to export the raw 16 byte value
and also indicate that the client asked for the channel bindings to
match exactly (with KERB_AP_OPTIONS_CBT or by providing MsvChannelBindings).

Maybe using gss_inquire_sec_context_by_oid() would be a good idea
for these cases instead of using ret_flags from gss_accept_sec_context().

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/20200228/ac8f9031/attachment-0001.bin