[19545] in Kerberos_V5_Development
Re: Implicit REALM/DNS Mapping
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Thu Feb 9 15:17:40 2017
MIME-Version: 1.0
In-Reply-To: <1485949069.6128.5.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
Date: Thu, 9 Feb 2017 15:17:26 -0500
Message-ID: <CAOASepMdYG2sjpnO3M0_pXTyQbw_diH8fJLT1wBBgx1SX6r7vw@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>, Matt Rogers <mrogers@redhat.com>
Cc: krbdev <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Is MIT willing to merge a patch for this?
Matt, are you willing to write this patch?
On Wed, Feb 1, 2017 at 6:37 AM, Simo Sorce <simo@redhat.com> wrote:
> On Tue, 2017-01-31 at 14:45 -0500, Greg Hudson wrote:
>> 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).
>
> This is what we should do, it is the most common case of failure we've
> seen to date.
>
> Simo.
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
