[20041] in Kerberos_V5_Development
Re: Current semantics for channel-bindings in GSSAPI
daemon@ATHENA.MIT.EDU (Stefan Metzmacher)
Fri Feb 28 18:47:13 2020
To: Greg Hudson <ghudson@mit.edu>, 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: Stefan Metzmacher <metze@samba.org>
Message-ID: <d3e0e4ae-c4d8-1618-0bb9-8b4d86e67330@samba.org>
Date: Sat, 29 Feb 2020 00:46:54 +0100
MIME-Version: 1.0
In-Reply-To: <56d5aa58-e60a-6a3a-d92a-343d2979fb81@mit.edu>
Content-Type: multipart/mixed; boundary="===============2491506045387208116=="
Errors-To: krbdev-bounces@mit.edu
--===============2491506045387208116==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="U8lvXgA2yWbCjSu2T9FwTX1vSTHg6j43N"
--U8lvXgA2yWbCjSu2T9FwTX1vSTHg6j43N
Content-Type: multipart/mixed; boundary="tl2VYHQCKkAd5Kq1LI0acqSHcJzmRJIXW";
protected-headers="v1"
From: Stefan Metzmacher <metze@samba.org>
To: Greg Hudson <ghudson@mit.edu>, 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>
Message-ID: <d3e0e4ae-c4d8-1618-0bb9-8b4d86e67330@samba.org>
Subject: Re: Current semantics for channel-bindings in GSSAPI
References: <CAC-fF8QdP9vRMMfxsxHL-APvsTRwdktbeiR0HrqjxYAE_To4Xg@mail.gmail.com>
<18cdd00f-f939-3d4b-1ef8-588af3a097fe@mit.edu>
<25a3f366-b53b-76ec-24db-4761494f093f@samba.org>
<56d5aa58-e60a-6a3a-d92a-343d2979fb81@mit.edu>
In-Reply-To: <56d5aa58-e60a-6a3a-d92a-343d2979fb81@mit.edu>
--tl2VYHQCKkAd5Kq1LI0acqSHcJzmRJIXW
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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.
>=20
> 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 binding=
s
>>> 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.
>=20
> 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 i=
t
> 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 MsvChannelBinding=
s).
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
--tl2VYHQCKkAd5Kq1LI0acqSHcJzmRJIXW--
--U8lvXgA2yWbCjSu2T9FwTX1vSTHg6j43N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfFbGo3YXpfgryIw9DbX1YShpvVYFAl5Zpm4ACgkQDbX1YShp
vVaA9w/9GUVcav79cYTO8O6+CNKFgdkNlm0JDYloBf2btY6LHc2NLnHEN5iD8eDW
Vb9iVFzivAGb8D9s4tybJR1lhGGafxmTDsdDF9hK0gkfT67A4/wTaoDpQQyklath
aBz475t+iOxcqjXvfo+zIYrrJDe51V/lTiiF7AMPl7em95K7JPChwLjSKr2Qu/QW
XZ43nIHuvY3OoKGaLF14LguMcqER9zLADww2fTzAAlg9MUgfNPqNSRUBHv+5iIWB
VD2pBcucvEQToI5PjF3lgl/Xc+zxcNsXLUe4kPs5YoZ8H5/JQGIyqEvNQMYoLwzN
GgrIsOeaNoZOwLZmqmUPhK9TvZin4oIDIgsFaa+5j07wKxSihxB6j5TM7K/jftDz
w3L+6PjHjI3jIzq0q20Op+oH0636nqyc8CkwT+HmprPVYtevrBh7VIb+HW+XTVhn
KSNt3+cLgg0GhMAfOgCtcjgmbQhEXurWbuCxhqeXqaco1tImtd2RjoHoxUPSOF1g
oYqTuMCg8xFOJwCS2HsBEBs7jaHbugdC74iPCEjJh2Vr75AQ5s9EEoCMsRbgIpZA
qzwf/3kdScaNZN7PokR9zjH5uVHp1X1UY3xY15MHyPEfHSzEf9cMApklPvaec3Kz
zGuBi54w25IUNISU5YBKVZCcrLHY0KeT67SJVe4s3X2mGKDOjv0=
=b5Tl
-----END PGP SIGNATURE-----
--U8lvXgA2yWbCjSu2T9FwTX1vSTHg6j43N--
--===============2491506045387208116==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============2491506045387208116==--
