[20091] in Kerberos_V5_Development
Re: NegoEx broke GSSAPI in BIND 9
daemon@ATHENA.MIT.EDU (=?utf-8?B?T25kxZllaiBTdXLDvQ==?=)
Wed May 20 10:30:18 2020
From: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
Message-ID: <FCF36998-7762-444D-B748-0F1CF9BFA754@isc.org>
MIME-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 20 May 2020 16:29:09 +0200
In-Reply-To: <d1cb897c6b1efd82a1a90dd6f5937d1274b2ba02.camel@redhat.com>
To: Simo Sorce <simo@redhat.com>
Cc: krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============3300782919443865506=="
Errors-To: krbdev-bounces@mit.edu
--===============3300782919443865506==
Content-Type: multipart/signed;
boundary="Apple-Mail=_23265449-C5D6-41F5-A4A2-6B95D2E5930B";
protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_23265449-C5D6-41F5-A4A2-6B95D2E5930B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
The gssapictx.c is dated 2000 :-), so I am not sure if anybody remembers
what we want :-) apart from implementing RFC 3645 which says:
=E2=80=94 cut here =E2=80=94
The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
choose the underlying security mechanisms that enables security
context negotiation. GSS API using SPNEGO [RFC2478] enables client
and server to negotiate and choose such underlying security
mechanisms on the fly. To support such flexibility, DNS clients and
servers SHOULD specify SPNEGO mech_type in their GSS API calls. At
the same time, in order to guarantee interoperability between DNS
clients and servers that support GSS-TSIG it is required that
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
Kerberos v5.
In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.
=E2=80=94 cut here =E2=80=94
So, what you are saying makes actually vague sense to me. What I =
actually
think is that we just want to use SPNEGO and don=E2=80=99t limit the =
mechanisms.
At the same time, I am still puzzled why it stopped working when NegoEx
was added to krb5.
Thank you very much,
Ondrej
--
Ond=C5=99ej Sur=C3=BD
ondrej@isc.org
> On 20 May 2020, at 16:05, Simo Sorce <simo@redhat.com> wrote:
>=20
>=20
> The mechanism list you create for gss_acquire_cred looks somewhat =
wrong
> to me.
>=20
> If you want to perform SPNEGO authentication but limit SPNEGO to allow
> only the krb5 mechanism you should acquire creds specifying only the
> SPNEGO oid.
>=20
> Then you should use the gss_set_neg_mechs() call on the credentials
> obtained and specify the krb5 mech oid only.
>=20
> This means:
> - 1) obtain credentials for any mechanism that SPNEGO can handle.
> - 2) make sure only krb5 is used by SPNEGO
>=20
> What you are doing now is to get a set of credentials for raw krb5 as
> well as all other mechanisms under SPNEGO. I am not sure this is what
> you want.
>=20
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>=20
>=20
>=20
>=20
> On Wed, 2020-05-20 at 11:34 +0200, Ond=C5=99ej Sur=C3=BD wrote:
>> Hi,
>>=20
>> there=E2=80=99s a regression in krb5 1.18.x that broke SPNEGO usage =
in BIND 9.
>>=20
>> There=E2=80=99s a little bit of history there - historically BIND 9 =
used internal implementation
>> of SPNEGO and that still works. But in the development version, I =
did drop the
>> internal implementation in favor of using KRB5 SPNEGO mechanism =
implementation.
>>=20
>> We don=E2=80=99t do anything fancy, the code is basically:
>>=20
>> #ifndef GSS_KRB5_MECHANISM
>> static unsigned char krb5_mech_oid_bytes[] =3D { 0x2a, 0x86, 0x48, =
0x86, 0xf7,
>> 0x12, 0x01, 0x02, 0x02 =
};
>> static gss_OID_desc __gss_krb5_mechanism_oid_desc =3D {
>> sizeof(krb5_mech_oid_bytes), krb5_mech_oid_bytes
>> };
>> #define GSS_KRB5_MECHANISM (&__gss_krb5_mechanism_oid_desc)
>> #endif /* ifndef GSS_KRB5_MECHANISM */
>>=20
>> #ifndef GSS_SPNEGO_MECHANISM
>> static unsigned char spnego_mech_oid_bytes[] =3D { 0x2b, 0x06, 0x01,
>> 0x05, 0x05, 0x02 };
>> static gss_OID_desc __gss_spnego_mechanism_oid_desc =3D {
>> sizeof(spnego_mech_oid_bytes), spnego_mech_oid_bytes
>> };
>> #define GSS_SPNEGO_MECHANISM (&__gss_spnego_mechanism_oid_desc)
>> #endif /* ifndef GSS_SPNEGO_MECHANISM */
>>=20
>> [=E2=80=A6]
>>=20
>> static OM_uint32
>> mech_oid_set_create(OM_uint32 *minor, gss_OID_set *mech_oid_set) {
>> OM_uint32 gret;
>>=20
>> gret =3D gss_create_empty_oid_set(minor, mech_oid_set);
>> if (gret !=3D GSS_S_COMPLETE) {
>> return (gret);
>> }
>>=20
>> gret =3D gss_add_oid_set_member(minor, GSS_KRB5_MECHANISM, =
mech_oid_set);
>> if (gret !=3D GSS_S_COMPLETE) {
>> goto release;
>> }
>>=20
>> gret =3D gss_add_oid_set_member(minor, GSS_SPNEGO_MECHANISM,
>> mech_oid_set);
>> if (gret !=3D GSS_S_COMPLETE) {
>> goto release;
>> }
>>=20
>> release:
>> REQUIRE(gss_release_oid_set(minor, mech_oid_set) =3D=3D =
GSS_S_COMPLETE);
>>=20
>> return (gret);
>> }
>>=20
>> static void
>> mech_oid_set_release(gss_OID_set *mech_oid_set) {
>> OM_uint32 minor;
>>=20
>> REQUIRE(gss_release_oid_set(&minor, mech_oid_set) =3D=3D =
GSS_S_COMPLETE);
>> }
>>=20
>> and then it=E2=80=99s used like this:
>>=20
>> gss_OID_set mech_oid_set;
>>=20
>> [=E2=80=A6]
>>=20
>> gret =3D mech_oid_set_create(&minor, &mech_oid_set);
>> if (gret !=3D GSS_S_COMPLETE) {
>> gss_log(3, "failed to create OID_set: %s",
>> gss_error_tostring(gret, minor, buf, =
sizeof(buf)));
>> return (ISC_R_FAILURE);
>> }
>>=20
>> gret =3D gss_acquire_cred(&minor, gname, GSS_C_INDEFINITE, =
mech_oid_set,
>> usage, cred, NULL, &lifetime);
>>=20
>>=20
>> Unfortunately, this stopped working since 1.18.1, but perhaps we were =
doing something
>> wrong from the beginning. Honestly, looking at the GSSAPI is like =
reading tea leaves :-),
>> so I would appreciate if I can get some pointers where to start with =
the debugging.
>>=20
>> The code is working in 1.17.1 and it=E2=80=99s neither working in =
1.18.1 nor master branch (I saw
>> some fixes in there, so I tried).
>>=20
>> Thanks,
>> Ondrej
>> --
>> Ond=C5=99ej Sur=C3=BD
>> ondrej@isc.org
>>=20
>> _______________________________________________
>> krbdev mailing list krbdev@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>=20
--Apple-Mail=_23265449-C5D6-41F5-A4A2-6B95D2E5930B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl7FPrVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIXzw//XMLeqYCd5IgoLgEQGn2QGJtnubl9cyb6aufIIqTiNNumETtUpwb4gn5f
gmje9ej3RDssTBk2YdZ93ZQVHkuWcVUMHBnxfBcfY3IbyhpgaDm1d/l2pqgudKfX
YFB9k8WllR5+QSLL1RBsX3OU3dTjbC3m4wsbkTtRyVYwyCVvseB8+a0/ztUAXL6c
iC6l5H3tNheybQBRrMsJQwwjUdRIfE6+LGsS2V9gPMXxCNkA0h7I2r67ANr62Wes
9X97970zt1q15EupjGAAbLotVaucwgfzDgMXo7l70mNmuI69KcwtyFIdnHQpB/y9
UC0qwxj0l18nWyGjRrV5lwSB2kYa6d1Z457X7A2qd5tcGYFeEbf1jl+dhdb2NRUL
BoDP9s9tYbCdEhuvRlK9T9r0B/pyf+W+2+hfqLcSvklb5Lfum7mHHLwmaxkEgymr
DkBZUI4xbQjNcPvfCpXEMP2BDH9nYjXS0tQWtAizkaJlHQ9z85WeZRFlzVa97pEJ
axiMri50898wXkbsiIhVPxnjwlFFhElNuGqdniSa8EL+JBGSGXEa775wixJNPPr3
f9vagNqutrpSYRSDE34hk3KW4WwbMkzan2GdS5fKv8P/L9NINEasFvBM9vxku7kC
BNefhbHT9hoyTVyHLLAjAZzFPXG0bqszAWt6zFWu0+Pa+huXiHo=
=WQT1
-----END PGP SIGNATURE-----
--Apple-Mail=_23265449-C5D6-41F5-A4A2-6B95D2E5930B--
--===============3300782919443865506==
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
--===============3300782919443865506==--
