[20038] in Kerberos_V5_Development
Re: Current semantics for channel-bindings in GSSAPI
daemon@ATHENA.MIT.EDU (Stefan Metzmacher)
Fri Feb 28 12:23:02 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: <25a3f366-b53b-76ec-24db-4761494f093f@samba.org>
Date: Fri, 28 Feb 2020 18:22:33 +0100
MIME-Version: 1.0
In-Reply-To: <18cdd00f-f939-3d4b-1ef8-588af3a097fe@mit.edu>
Content-Type: multipart/mixed; boundary="===============3609606152318346766=="
Errors-To: krbdev-bounces@mit.edu
--===============3609606152318346766==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature";
boundary="8FM33wgz3meDTWwB1JWcE57z3pJ0uf1YE"
--8FM33wgz3meDTWwB1JWcE57z3pJ0uf1YE
Content-Type: multipart/mixed; boundary="bqDjMTVQPiTdk3emVym4EmHDZaMaoi6gu";
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: <25a3f366-b53b-76ec-24db-4761494f093f@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>
In-Reply-To: <18cdd00f-f939-3d4b-1ef8-588af3a097fe@mit.edu>
--bqDjMTVQPiTdk3emVym4EmHDZaMaoi6gu
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Am 28.02.20 um 18:00 schrieb Greg Hudson:
> On 2/27/20 8:27 PM, Isaac Boukris wrote:
>> Following the discussion on IRC, there is currently a difference in
>> between Heimdal and MIT, when the client does not send bindings, and
>> the server does pass bindings to accept(), in MIT it fails, in Heimdal=
>> it succeeds.
>=20
> There are a few reasons why I think Heimdal's behavior is better:
>=20
> * It's symmetric with the initiator.
>=20
> * It's symmetric with other mechanisms like Moonshot. (More research
> may be required here; in particular, does NTLM enforce channel bindings=
> when one party doesn't pass them?)
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.
> * GSS generally does not fail a security context if it can't fulfill a
> requested option; instead, the caller can find out which options
> succeeded. For instance, if you ask for confidentiality and the mech
> can't provide that, you get a security context without the
> confidentiality flag set.
>=20
> * 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.
> * Even without any other changes, Heimdal's behavior allows channel
> bindings to be introduced into an application protocol gradually,
> whereas MIT's behavior requires upgrading all of the clients before any=
> of the servers. Neither party polices the other, but when both parties=
> supply channel bindings the negotiation will fail if an attacker replay=
s
> it within a different channel.
>=20
> For historical context, there is a lot of conversation about
> draft-ietf-kitten-channel-bound-flag in the kitten archives, although
> this specific point is only touched on at the end (after Sam's review).=
>=20
>> To follow up on the KERB_AP_OPTIONS_CBT ad-element, (partly)
>> documented in MS-KILE, 3.2.5.8 AP Exchange, and 3.4.5.
>> I was able to confirm that Windows would enforce channel-bindings (not=
>> allow all zeroes)
>=20
> I am a little confused about the need for this flag. The GSS client
> code knows whether the application supplied channel bindings, so it
> seems like it can fail locally if channel bindings are expected. I
> guess it doesn't know whether the server is level 0 or level >=3D1, but=
> I'm still not sure what security guarantees level 1 is trying to provid=
e.
The problem is kerberos or NTLMSSP without GSS_C_CONF_FLAG and without
GSS_C_INTEG_FLAG. If this is used within TLS the server receiving the
AP-REQ could just replay that to another server. A client knowning about
the correct channel bindings can prevent such attacks, but the server
needs level=3D1 (or higher) to detect that.
metze
--bqDjMTVQPiTdk3emVym4EmHDZaMaoi6gu--
--8FM33wgz3meDTWwB1JWcE57z3pJ0uf1YE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfFbGo3YXpfgryIw9DbX1YShpvVYFAl5ZTFkACgkQDbX1YShp
vVYQUxAAqzEsA2eOiil5qpeDiIgJYqQPvJcRcwz+PHuVIHvp5etW9qXxPeyZ+WdH
DIncx0nx0L+T29uWqCqWaGU4jEJttFnB2AdHsbHlurS4UGTCAlydJ/2wVc0EWW8g
VXQ0Qc78aiilefvOXYbHW/B1h3w3kFyoP6TljCjDL4r+b6sEtjpWE8PWL3+aZRmH
RblXGWnNGIAeA+FhG1xTawZY8SrKKD3sVq6N9Jb+fUb40r5tI2vzaXDi0jQBCmFp
aPvnHHA11TnmlimLTWXogvNDRDo/tvmh4/ZO7JtJP6BF7hIw/w51TsVTCmq34A1d
LV9aZBEOXYF/Cxm7MflvfEcA7hPUKfTHxzB3ST4gPFxAtTKbNXnf8H7PbEuDf44j
C3vCEdiEG5fGY8/QYEbKkUMmRzIUXQNb6znkAGtfr76W1cStiW/gy5MjfZMYfiFI
C/pQix5F4I3uCAM1DouHPytXwyBmX6cdquVfc0Wpcz15fNCFeZCQqOVol4zslPX3
0mt9NZ1UnUcqCDWe25tUmM/AhEP9HC/EtnJFabAv5aCZ6RuqCFd2z1t0RkIrlsu9
/16A1Ze7j6QbLxT7I6Iebnd0NYHmk8CH8RLpJmf6TbKKgFxZX1DCjkBJkJjLi+gq
8xbqOz4CH7kfxItfzDAxv812ij/EL/JfSmKFRQUet9uBZ+Kg8+4=
=2g1L
-----END PGP SIGNATURE-----
--8FM33wgz3meDTWwB1JWcE57z3pJ0uf1YE--
--===============3609606152318346766==
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
--===============3609606152318346766==--
