[20040] in Kerberos_V5_Development
Re: Current semantics for channel-bindings in GSSAPI
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Feb 28 15:33:34 2020
To: Stefan Metzmacher <metze@samba.org>, Isaac Boukris <iboukris@gmail.com>,
"krbdev@mit.edu Dev List" <krbdev@mit.edu>,
Simo Sorce <simo@redhat.com>, Nico Williams <nico@cryptonector.com>,
<rharwood@redhat.com>, Andrew Bartlett <abartlet@samba.org>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <56d5aa58-e60a-6a3a-d92a-343d2979fb81@mit.edu>
Date: Fri, 28 Feb 2020 15:33:01 -0500
MIME-Version: 1.0
In-Reply-To: <25a3f366-b53b-76ec-24db-4761494f093f@samba.org>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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 krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
