Re: Current semantics for channel-bindings in GSSAPI

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.
>> * 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.  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.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev