[33543] in Kerberos
Re: RFC: Turning off reverse hostname resolution by default in 1.10
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Wed Jul 6 13:50:06 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
Message-ID: <4E14A045.3060009@secure-endpoints.com>
Date: Wed, 06 Jul 2011 13:49:57 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <201107061727.p66HROpE002297@outgoing.mit.edu>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1066682123=="
Errors-To: kerberos-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1066682123==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigCD011B9BE41BF3E4D816BD98"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCD011B9BE41BF3E4D816BD98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Getting rid of the reverse dns lookups for canonical name resolution is
the right thing to do and will finally bring MIT Kerberos into
compliance with RFC 4120. It will impact the help desks of a large
number of sites. I believe that as part of such a change MIT should
change the version number to 2.0 in order to make clear that there is
something major that sites need to pay attention to.
Jeffrey Altman
On 7/6/2011 1:27 PM, ghudson@MIT.EDU wrote:
> When creating service principals from hostnames, MIT krb5 performs two
> canonicalization steps by default:
>=20
> 1. Ask getaddrinfo() for the canonical name of the host, which
> converts non-fully-qualified domain names to fully-qualified ones
> and also resolves CNAME records in DNS.
>=20
> 2. Use getnameinfo() to reverse-canonicalize the address resulting
> from the gaddrinfo call. Typically, this results in a PTR lookup in
> DNS. This step can be suppressed by setting rdns =3D false in
> libdefaults.
>=20
> Neither of these steps is especially secure in most deployments. We
> have long-term plans to address that. But, the second step in
> particular also introduces a usability cost for new deployments
> whenever there are mismatched PTR records.
>=20
> We are considering turning off rdns by default in MIT krb5 1.10. In
> the past we've shied away from changing the default because we've been
> afraid of creating upgrade pain. But after consideration, we're not
> sure there's likely to be much impact.
>=20
> Does anyone on this list intentionally rely on PTR lookups for
> Kerberos hostname canonicalization?
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--------------enigCD011B9BE41BF3E4D816BD98
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBAgAGBQJOFKBIAAoJENxm1CNJffh4TZMIAKYdm5hWtc6xHQdemNpsJXiA
3um7IJsyRk9V+Ikr9eVZ3sTwVnpeI+RdxJidSZn7LG0gdnxdBsNNqANrm+H8yVvX
wpk57fwcPiaiAzXs92QJoskVNi2vfIpYLBsVnNm/rrZy+YQ9wR2JvrHsVkYkHZ3f
pss7StbQj1p6ij3K9BAfcFajx1AS3rJuO1fcsAzVe0DkXqaLLP7XM/Fnq0lGM5hr
1NaG7+KoXzw5DggLzEaDQ8gChcXix/XZTU6Q4tAumKdgqT4kHciEuJL0EvCTwKJr
J1C0Erw2C3SBa8ZcnF0yqsIGjP3BN2q1e8UgMlGtncVeBk85gWAcI4OzoMUOmEs=
=NTZl
-----END PGP SIGNATURE-----
--------------enigCD011B9BE41BF3E4D816BD98--
--===============1066682123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1066682123==--
