Implicit REALM/DNS Mapping

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Implicit REALM/DNS Mapping

Nathaniel McCallum-5
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?

Nathaniel
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implicit REALM/DNS Mapping

Greg Hudson
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implicit REALM/DNS Mapping

Simo Sorce-3
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implicit REALM/DNS Mapping

Nathaniel McCallum-5
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 <[hidden email]> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implicit REALM/DNS Mapping

Greg Hudson
On 02/09/2017 03:17 PM, Nathaniel McCallum wrote:
> Is MIT willing to merge a patch for this?

Yes.  I think the right place to insert the new logic is at the
beginning of krb5_cc_select().  If server has the referral realm (use
krb5_is_referral_realm() for clarity, although we're just looking for an
empty realm), then call krb5_get_fallback_host_realm() and, if it
succeeds, construct a copy of server using the first fallback realm, to
be passed to the modules.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Implicit REALM/DNS Mapping

Matt Rogers
In reply to this post by Nathaniel McCallum-5
On Thu, Feb 9, 2017 at 3:17 PM, Nathaniel McCallum
<[hidden email]> wrote:
> Is MIT willing to merge a patch for this?
>
> Matt, are you willing to write this patch?
>
Sure, I opened https://github.com/krb5/krb5/pull/606 following Greg's
suggested patch. Please review :)

Matt
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev