[19531] in Kerberos_V5_Development
Re: Implicit REALM/DNS Mapping
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jan 31 14:45:58 2017
To: Nathaniel McCallum <npmccallum@redhat.com>, krbdev <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <61d7d9fa-5253-b239-3d78-be43cbe427eb@mit.edu>
Date: Tue, 31 Jan 2017 14:45:47 -0500
MIME-Version: 1.0
In-Reply-To: <CAOASepOm1EaGqH3SxX7guReb+bkdgxjK9yz_7LXK8PEWWtGrfw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 01/31/2017 05:36 AM, Nathaniel McCallum wrote:
> Currently, GSSAPI will select a non-default ccache if a realm/domain
> mapping exists in krb5.conf. However, this doesn't work if the KDC was
> found via discovery. Does MIT have any thoughts about implying an
> implicit mapping in this case?
I think I understand the problem to be solved, but I'm not sure how an
implicit mapping would work. KDC discovery doesn't help us to know what
realm a server host is in; it only tells us how to contact the KDCs for
a realm once we know its name.
Rick van Rein's proposed discovery solution to this problem is
DNSSEC-secured TXT records. There are some difficulties inherent to
implementing that, so while there is an open PR for it (
https://github.com/krb5/krb5/pull/560 ) it has not been merged.
Another possible solution to this specific problem is to use the
fallback realm for the purpose of GSSAPI ccache selection when no
authoritative realm, since referrals cannot be performed before a ccache
is chosen. The most commonly applicable fallback is "chop off the first
component and convert to uppercase," (foo.bar.baz -> BAR.BAZ).
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
