Implicit REALM/DNS Mapping

[Nathaniel McCallum]

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Nathaniel McCallum
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

Post by Greg Hudson

Post by Nathaniel McCallum
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 ***@mit.edu
https://mailman.mit.edu/mailman/lis

[Nathaniel McCallum]

Is MIT willing to merge a patch for this?

Matt, are you willing to write this patch?

Post by Simo Sorce

Post by Greg Hudson

Post by Nathaniel McCallum
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Nathaniel McCallum
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Matt Rogers]

On Thu, Feb 9, 2017 at 3:17 PM, Nathaniel McCallum

Post by Nathaniel McCallum
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev