Subject: [kitten] Fwd: New Version Notification for draft-vanrein-dnstxt-krb1-05.txt

From: Rick van Rein <[email-masked]>
Date: Tue, 15 Sep 2015 16:39:33 +0200

Friends,

I have posted a new version of the KREALM record definition,
incorporating the feedback on uses that were not Kerberos-specific.  It
is now very simple and straightforward.

If you guys are happy with this, I will jump back to DNSEXT and propose
it there, and push it forward to get an RRTYPE assigned.

I'm not sure how to proceed re. Kitten with this -- would you guys like
me to continue this document as an Individual Submission, or is it
better as a Kitten WG document?

Cheers,
 -Rick
> *From:* [email-masked]
> *Date:* 15 September 2015 16:36
> *To:* "Rick van Rein" <[email-masked]>, "Rick van Rein"
> <[email-masked]>
> *Subject:* New Version Notification for draft-vanrein-dnstxt-krb1-05.txt
> A new version of I-D, draft-vanrein-dnstxt-krb1-05.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-dnstxt-krb1
> Revision:	05
> Title:		Declaring Kerberos Realm Names in DNS (KREALM)
> Document date:	2015-09-15
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-05
>
> Abstract:
>    This specification defines a method to determine Kerberos realm names
>    for services that are known by their DNS name.  Currently, such
>    information can only be found in static mappings or through educated
>    guesswork.  DNS can make this process more flexible, provided that
>    DNSSEC is used to ensure authenticity of resource records.
>
>                                                                                   
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Sep 2015 22:59:46 -0400 (EDT)

Hi Rick,

> better as a Kitten WG document?

I'm sorry this question didn't get answered sooner.

There seems to be some level of consensus settling around using PTR for
_kerberos.fqdn to point to a realm name, with the concordant implications
for the case of the realm name.  Since that is using a existing DNS record
type and making backward-incompatible changes to the Kerberos standard, it
seems to fit best as a kitten WG document.  (It is not really appropriate
for individual submissions to make changes to Proposed Standards with
still-extant working groups.)  As was noted a couple times, it would be
fine to do an Informational document describing the currently-in-use TXT
records as an individual submission, since there is less of a restriction
on that case.  It could also be done in kitten, if there is energy for it,
but since there hasn't been energy for the past 10 (?) years, it seems
unlikely there will be any now.

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Fri, 18 Sep 2015 08:18:42 +0200

Hello Benjamin,

> I'm sorry this question didn't get answered sooner.

Well timed actually, now we're getting somewhere :)

> for the case of the realm name.

Yes, and I would really like to move forward on that :)

> Since that is using a existing DNS record
> still-extant working groups.)

Yes, anything else would be silly.

> As was noted a couple times, it would be
> on that case.

For TXT, the friction comes with DNS people.  I've been trying that before.

> It could also be done in kitten, if there is energy for it,

Please explain what energy is needed; I am willing to describe the PTR in a new document, and have a student ready to implement it.  Clearly, the list is willing to discuss proposals.  Is there more needed?

The one thing that I would find devastating is when we all want something to be done, but then it doesn't get done.  I currently have some resources to make changes towards broader realm crossover, as long as I understand what needs to be done.

This is assuming that the fact that I'm on the list equals being "in Kitten", which may in fact be another class of thing altogether.   But at the very least I could be the editor of a Kitten document, even if others have more field knowledge about Kerberos than I do.

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Fri, 18 Sep 2015 13:08:56 +0200

Hello,

> type and making backward-incompatible changes to the Kerberos standard,

Or, we could simply say

   "All retrieved _kerberos PTR data MUST be cast to all-uppercase characters
   before processing with Kerberos and/or GSS-API.  This compensates for the
   uncertainty of case mappings in DNS.  Kerberos realms that want to be
   reachable through these PTR records MUST accept requests with the
   realm name in all-uppercase form."

This does not change the semantics of Kerberos AFAIK, and it remains open to
future changes in case handling in the KDC.  The mapping to uppercase is not
a compensation for a temporary condition, but for the permanent uncertainty
around case handling of PTR record data.

> (It is not really appropriate

Shall I formulate the above in an individual submission and leave it to Kitten
whether they want to lift it up the a WG spec?  That way we'd at least be out
of the current impasse on this matter.

Thanks,
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Fri, 18 Sep 2015 09:02:48 -0500

>    realm name in all-uppercase form."

I'm very reluctant to agree to that, but I'd agree to saying that a TGS
client should first try the realm as it appears in the PTR RR and then
as up-cased if the first failed.

> This does not change the semantics of Kerberos AFAIK, and it remains open to

To be clear, there isn't and never has been a requirement that realm
names be upper-case.  Therefore your proposal would be in conflict with
Kerberos semantics, and the only saving grace is that sites with
non-all-upper-case realm names could simply not use PTR RRs this way.

> around case handling of PTR record data.

I realize that asking implementors to support realm aliasing is probably
a lot, but maybe not that much.  KDCs already have a list of realms
served.

The only thing that concerns me is how to canonicalize realm names for
name-based authorization.  This is the case where an AS client used an
alias realm name and now cannot get authorized to access some resources.
A service could canonicalize the client's realm name, but without a hint
from the KDC this won't scale.  The simplest thing to do is to reject
such AS-REQs and require that the client know the user's canonical
realm.  The next simplest thing to do would be to extend the AS protocol
to allow the AS to tell the client its canonical realm.  The next
simplest (and, really, hardest) thing to do would be to include
authz-data in tickets telling services the canonical form of the
client's realm.

> of the current impasse on this matter.

Sure.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Fri, 18 Sep 2015 11:15:42 -0400

> as up-cased if the first failed.

That is a non-starter for me.  The case of the realm as it appears in
the PTR RR is influenced by the case used in the query; it cannot be
treated as canonical.  Fallback KDC queries complicate security and
performance analysis, and I prefer to avoid them whenever possible.

I am provisionally okay with Rick's proposal that the record must either
refer to an uppercase realm or a realm with KDCs that can canonicalize
the uppercase realm to the correct realm.  I am also okay with using TXT.

> alias realm name and now cannot get authorized to access some resources.

I assume that if you use the wrong realm name with an AD KDC, you get
back a WRONG_REALM response, and the client tries again with the correct
case of the realm.  This only works when the client uses the
CANONICALIZE flag, which MIT krb5 clients don't do by default, and the
WRONG_REALM response isn't authenticated.  I am not sure what should
change there, but simply issuing a ticket for the non-canonical realm
seems out of the question.

These DNS records are more likely to be used for service principal names
than client principal names anyway.  I am not really fond of our
aliasing story for service names (I never understood why we chose to lie
to clients instead of correcting them), but it does work by default, up
until the point where application servers can't reliably use the sname
and realm in the Ticket for diagnostic purposes.

> it there, and push it forward to get an RRTYPE assigned.

Rick, in
http://www.ietf.org/mail-archive/web/kitten/current/msg05840.html
it seemed like you agreed to use an existing RR type.  So I am confused
why this draft update still defines a KREALM RR type and why you are
talking about getting an assignment.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 18 Sep 2015 15:32:19 +0000

> as up-cased if the first failed.

What does it mean to "try the realm"?

    * If it is a case variant of the local realm, just use the local realm.

    * If it is a case variant of a realm for which you already have
      cross-realm TGT or a service ticket for the desired service,
      use that.

    * If capaths are configured, for a case-variant of the realm,
      use that.

    * Otherwise, referrals with the KDC locating a suitable next
      realm based on capaths or a direct "trust" relationship.

The only time that determining the canonical form of the remote
realm becomes plausibly difficult, is when trust is constructed on
the fly via public keys in DNSSEC.  When such a protocol is designed,
the canonical realm suffix can be communicated as part of the
authenticated cross-realm key exchange.

So I don't see any need for "guessing" the realm name, rather all
that's required is that KDCs be able to locate cross-realm keys in
a "case-insensitive" manner (more precisely, if two realm names
represent the same valid DNS name, then each matches the other)
and that clients accept KDC responses in which the KDC has
canonicalized the requested realm name.

> alias realm name and now cannot get authorized to access some resources.

I don't expect that AS clients will be getting the realm name for
"kinit" from DNS.  If you want to "kinit" to a realm other than
the realm of the local host, I expect you need to know its name.

In any case the realm is (generally) part of the salt in string-to-key,
so it would seem that AS is not possible with a variant realm.

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 18 Sep 2015 19:30:31 +0200

Hi,
> What does it mean to "try the realm"?

In all but the local-realm case, the client may need its KDC to learn
about the proper case for the service's realm name.  But, as you've
shown, the KDC should now if the client doesn't.
> authenticated cross-realm key exchange.

The ways for doing this that Nico and I are brooding on, are based on
PKINIT, and use certificates that hold the realm name in its proper
case.  DNSSEC/DANE in turn can validate those certificates.  So even in
that case the mapping to a known case is possible.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Sat, 19 Sep 2015 15:13:47 +0200

Hey,

I was trying to steer clear from KDC discussions, but it now seems
helpful to at least look at it when describing the client behaviour.  So
below is a KDC case-mapping description, followed by how I think this
resolves the issues that were raised yesterday.

First, we already have the following rules:

   Though domain names themselves are case
   insensitive, in order for realms to match, the case must match as
   well.  When establishing a new realm name based on an internet domain
   name it is recommended by convention that the characters be converted
   to uppercase.
   [Section 6.1 of RFC 4120]

   Because the realm names "MYREALM",
   "myrealm", and "MyRealm" are all different, but resolve the same in
   the domain name system, it is necessary that only one of the possible
   combinations of upper- and lowercase characters be used in realm
   names.
   [Section 7.2.3.1 of RFC 4120]

The latter is certainly not going to be weakened if we decide to
overrule the former based on case sensitivity.  The last sentence does
make me believe that treating case-modified realm names as aliases is
necessary to avoid under RFC 4120.  But we can still look ahead at what
a future KDC could do in the area.

One possible implementation choice for a KDC is to use an explicit flag
(that'd be setup in default config files as soon as it became
standardised) for the entire KDC or for a single realm:

   # Set this flag to "yes" to indicate that domain-style realm names, if
   # they contain lowercase letters, may be recognised if requests with the
   # canonicalization flag comes in for the same realm name mapped
   # to all-uppercase.  This is useful for any such realm names to be
   # treated correctly when published in DNS PTR records with DNSSEC
   # protection.
  
   domain_realms_have_implicit_uppercase_aliases = yes

This has less impact than stating that case doesn't matter for
domain-style realm names; for configurations that already use
all-uppercase realms, this flag has no impact at all.  For
configurations with lowercase letters in their realm names, this
introduces an alias that should not already be defined explicitly.

I second Greg's suggestion to use canonicalization for changes to the
realm name, by treating the all-uppercase name variant as an automated
alias.  First and most importantly, TGS:

   RFC 4120 permits a KDC to return a closer referral ticket when a
   cross-realm TGT is requested.  This specification extends this
   behavior when the canonicalize flag is set.  When this flag is set, a
   KDC MAY return a TGT for a realm closer to the service for any
   service as discussed in the previous section.  When a client follows
   such a referral, it includes the realm of the referred-to realm in
   the generated request.
   [Section 9 of RFC6806]

This can be used to change a request with a different case that is
considered an alias to one that has the case that we want to.  Clients
would need to treat this as a change to another realm, due to their
case-insensitive treatment of realm names.  Effectively, the case would
be changed to the case as known to the KDC.

Then, let's be sure that AS is also covered if we relied on the PTR info
at the realm's DNS-mapped name:

   If the "canonicalize" KDC option is set, then the KDC MAY change the
   client and server principal names and types in the AS response and
   ticket returned from those in the request.
   [Section 6 of RFC 6806]

   If the "canonicalize" flag in the KDC options is set and the KDC
   doesn't find the principal locally, either as a regular principal or
   as an alias for another local principal, the KDC MAY return a cross-
   realm ticket-granting ticket to the next hop on the trust path
   towards a realm that may be able to resolve the principal name.
   [Section 8 of RFC 6806]

This offers two mechanisms for AS / login to change case, implying that
PTR is good enough for posting a realm name under the DNS-mapped realm
name, and have our future case-mapping KDC setup whatever case it
prefers.  The client would then get hold of a TGT with a realm with
corrected case, regardless of an all-uppercase alias case that may have
made it findable.

Now, returning to yesterday's discussion.

Rick> "All retrieved _kerberos PTR data MUST be cast to all-uppercase characters
Rick> before processing with Kerberos and/or GSS-API.  This compensates for the
Rick> uncertainty of case mappings in DNS.  Kerberos realms that want to be
Rick> reachable through these PTR records MUST accept requests with the
Rick> realm name in all-uppercase form."

This needs an additional MUST on setting the canonicalize flag so we can have a future case-aware KDC treat all-uppercase names as an alias of mixed-case realm names.

The terms "all-uppercase" and "mixed-case" need refinement when it comes to spec time.

The proposed KDC flag "domain_realms_have_implicit_uppercase_aliases" for a realm or the whole KDC could then instruct the KDC to use strncmp() instead of strcmp() when looking for all-uppercase domain-style realm names.  It would also know that the internally held spelling is the canonical one.

To me, this sounds like a really low-profile manner of introducing case mapping?

Nico> I'm very reluctant to agree to that, but I'd agree to saying that a TGS
Nico> client should first try the realm as it appears in the PTR RR and then
Nico> as up-cased if the first failed.
Nico>
Nico> To be clear, there isn't and never has been a requirement that realm
Nico> names be upper-case.  Therefore your proposal would be in conflict with
Nico> Kerberos semantics, and the only saving grace is that sites with
Nico> non-all-upper-case realm names could simply not use PTR RRs this way. 

Your intention seems to be to support other realm forms than all-uppercase.  The proposal to map to the KDC-stored canonical spelling would do that, even if the initial inquiry is all-uppercase.  With that in mind, do you agree that the initial attempt with DNS' case is no longer needed?

Nico> A service could canonicalize the client's realm name, but without a hint
Nico> from the KDC this won't scale.  The simplest thing to do is to reject
Nico> such AS-REQs and require that the client know the user's canonical
Nico> realm.  The next simplest thing to do would be to extend the AS protocol
Nico> to allow the AS to tell the client its canonical realm.

The proposal above includes canonicalization during the AS exchange, so the
client has a canonical name, that is, using KDC-spelling of case rather than
DNS-spelling.  This would provide the service with a representation that is
always the same, and not necessarily just all-uppercase.

Greg> The case of the realm as it appears in
Greg> the PTR RR is influenced by the case used in the query; it cannot be
Greg> treated as canonical.

That was what I had in mind, which I started to chase Nico's intentions in
the KDC.

Greg> Fallback KDC queries complicate security and
Greg> performance analysis, and I prefer to avoid them whenever possible.

Am I correct to assume that the canonicalization tasks stated above are not a concern in that respect?

Greg> I am provisionally okay with Rick's proposal that the record must either
Greg> refer to an uppercase realm or a realm with KDCs that can canonicalize
Greg> the uppercase realm to the correct realm.

As worked out above :) and we can require canonicalization in this case.

Viktor> I don't see any need for "guessing" the realm name, rather all
Viktor> that's required is that KDCs be able to locate cross-realm keys in
Viktor> a "case-insensitive" manner (more precisely, if two realm names
Viktor> represent the same valid DNS name, then each matches the other)
Viktor> and that clients accept KDC responses in which the KDC has
Viktor> canonicalized the requested realm name.

Agreed, and even possible with DNSSEC/DANE as described yesterday.  The
thing I did is even a bit weaker than being case-insensitive; it states
that an all-uppercase alias of a realm name may exist.  I don't mind
which of these two turns it takes, both seem possible and plausible
configurations for KDC.

Viktor> I don't expect that AS clients will be getting the realm name for
Viktor> "kinit" from DNS.  If you want to "kinit" to a realm other than
Viktor> the realm of the local host, I expect you need to know its name.

I can see practical use for the ability to lookup an email address and
rely on canonicalization to complete the mapping, as described in RFC 6806.
In this case too, the PTR record could supply a realm name with a
possibly case-mangled realm name that would be rewritten to all-uppercase.
But, if we assume canonicalization during AS, I do agree that it may make
more sense to such uses to just send an AS-REQ with an NT-SMTP-NAME and
have it translated to any other form.

Viktor> In any case the realm is (generally) part of the salt in string-to-key,
Viktor> so it would seem that AS is not possible with a variant realm.

This modified proposal is just a specialised form of canonicalization, for
which this does not seem to be a problem, so this concern should not apply
anymore.  I say that from general reasoning though, without having read
RFC 3961.

-Rick

---

From: Greg Hudson <[email-masked]>
Date: Sat, 19 Sep 2015 12:06:30 -0400

> be changed to the case as known to the KDC.

This reasoning isn't correct.  There are two scenarios:

1. The client can't determine the service realm name with confidence (it
doesn't implement PTR lookups, or can't do secure DNS resolution because
of a restrictive network element, or whatever).  In this case, it asks
its local KDC for a service ticket (making a TGS query to
serviceprinc@LOCALREALM) with no conception of what the target realm
should be.  The KDC can issue an RFC 6806 referral to whatever realm it
wants.  Case correction doesn't even enter the picture from the Kerberos
protocol perspective, since the client has no realm name to correct.

2. The client does determine the service realm name with confidence, but
with the wrong case.  In this case its asks its KDC for
krbtgt/wrong-case-realm@LOCALREALM, and RFC 6806 does not apply.  RFC
4120 section 9 allows the local realm KDC to issue a
krbtgt/right-case-realm@LOCALREALM ticket as a "closer TGT", but a
current client will not take that as a case correction; instead, it will
stubbornly ask right-case-realm for a krbtgt/wrong-case-realm Ticket.

We can certainly require that clients which implement PTR realm lookup
also treat krbtgt/case-variant-realm replies as case corrections rather
than referrals.  But that needs to be treated as a protocol extension
and an update to RFC 4120.  In MIT krb5 there are some API and caching
considerations for this new client behavior, though they may be manageable.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 22 Sep 2015 13:09:38 +0200

Hi Greg,

> protocol perspective, since the client has no realm name to correct.
Agreed.  In this case we cannot speak of case correction because the KDC
may be the party that does the PTR lookups with confidence.  I was not
describing this case (and may have been unclear about that).

> krbtgt/wrong-case-realm@LOCALREALM, and RFC 6806 does not apply.
Ah.  My reasoning was that it would ask directly for
imap/imap.example.com@WRONG-CASE-REALM
and that RFC 6806 would then be applied.  I've seen such guessing,
presumably under the hoping that the KDC will know how to link the client
to the requested service; I've seen this behaviour on Mac OS X, which
uses Heimdal.  I haven't checked if MIT krb5 does this too.

> RFC 4120 section 9 allows the local realm KDC to issue a
You mean because it sees wrong-case-realm as different from right-case-realm
and thinks it hasn't reached its destination, right?

The client however, "knows" that the case might be off, because it went
through the (new) activity of pursuing a PTR RR.  That means that it
might also handle the case differently.  Conceptually, I am thinking of the
client as interpreting the PTR as a set of possible realms to ask for, with
all the case variations included.  In theory it might try each in turn, but
in practice it is more efficient to interpret the response as saying "but we
have a direct route for another option you're considering".  What this
means in practice is that the client who does PTR lookups can cut short
the iteration over many cases by requesting a standardised version from
the set and treating the response as a case correction.  And it is the newly
introduced PTR behaviour that would make all the difference -- because
PTR cannot provide reliable character case.

> considerations for this new client behavior, though they may be manageable.
Do you agree that the conceptual model and inefficient theoretic implementation
is in line with what RFC 4120 prescribes, and that the case-correction is
merely a more efficient manner of getting to the right answer?  (That would
need some explaining in the I-D of course.)

Cheers,
 -Rick

---

From: Greg Hudson <[email-masked]>
Date: Tue, 22 Sep 2015 10:58:16 -0400

On 09/22/2015 07:09 AM, Rick van Rein wrote:
> uses Heimdal.

Can you elaborate on the request behavior you have seen?  Specifically,
these fields:

1. The realm of the KDC-REQ-BODY
2. The sname of the Ticket inside the PA-TGS-REQ

In my experience with the Kerberos protocol, when (2) is krbtgt/X, X
always matches (1).  The MIT krb5 KDC implementation requires this, and
will reject the request with a KRB_AP_ERR_NOT_US error if they don't match.

In summary, a client never asks realm X for a service ticket in realm Y.
 If it knows it wants a service ticket in realm Y, it asks realm X for a
krbtgt/Y ticket and then asks realm Y for the service ticket.

> and thinks it hasn't reached its destination, right?

Yes.

> need some explaining in the I-D of course.)

I do not agree.  RFC 4120 says, "Before sending a request to the
ticket-granting service, the client MUST determine in which realm the
application server is believed to be registered."  It doesn't talk about
determining a set of possible realms--certainly not a combinatoric set
of 2^N possible realms where N is the number of case-varying characters.
 What you are talking about is unquestionably an extension to RFC 4120.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 25 Sep 2015 14:43:47 +0200

Hi,

Greg> I do not agree.  RFC 4120 says, "Before sending a request to the
Greg> ticket-granting service, the client MUST determine in which realm the
Greg> application server is believed to be registered."

Yes, this is clear enough.  Although "believed" leaves some room for
wiggling, I agree that this text should not be taken as far as I was
hoping to get.  So then, we cannot handle undeterministic names (such as
potentially case-mangled names) when we "believe" in the realm for the
application server.

There are now two ways out; one is to continue with PTR and then fixate
one realm casing (presumably uppercase) and live with this forevermore. 
The other is to go back to TXT or KREALM RR, of which TXT is widely
preferred.  Given that it is acceptable to the DNS community, TXT is my
(light) preference too.  The historic use of the _kerberos prefix should
distinguish it well enough from other uses of TXT.  Perhaps we should
give it another try in that form, and fallback to KREALM if that is
rejected by DNS people.

If nobody objects, I will soon update my draft text to the TXT form,
limiting to only one <character-string> in the TXT field, and not
constraining it to be domain-style.  I will continue to be strong in
requiring DNSSEC, of course.

-Rick

---

From: Greg Hudson <[email-masked]>
Date: Fri, 25 Sep 2015 11:04:44 -0400

> Greg> application server is believed to be registered."
[...]
> preferred.

To be clear, I wasn't arguing that we can't do case correction of realm
names.  I was arguing that we would need to extend RFC 4120 to allow
case correction TGT responses, and require that clients implement this
extension if they implement PTR realm lookups.

I have no strong opinion on whether the extra work of extending RFC 4120
is worth it.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 25 Sep 2015 17:49:14 +0200

Hello Greg,

> extension if they implement PTR realm lookups.

Yes, you were clear and quite helpful, in pointing out both a practical solution and explaining where precisely it clashes with current RFC 4120 practice.  Thank you!

> I have no strong opinion on whether the extra work of extending RFC 4120

I have no idea of the extra work involved; or the time delays?  Its only benefit would be that we would use PTR instead of TXT.  I am willing to put some effort in either way, but also feel this relatively simple first step shouldn't drag on for too long; there are others things I would like to put my energy in, such as KRB5-KDH, TLS-KDH and DANE-based realm crossover.

Benjamin said that anything that overrides RFC 4120 ought to be a WG effort, but if it is limited to just this than we could also consider that path, if others prefer that over documenting _kerberos TXT under DNSSEC.  From what I've sampled so far, everyone considers TXT to be a suitable alternative.

Meanwhile, I found in RFC 4846 that the intention of an Independent Submission is to propose alternatives to IETF work, which is okay as long as it is perfectly clear that it is an alternative.  But a WG document, or a solution that doesn't interfere with existing WG documents, is still preferred I think, in light of getting things actually used in software.

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Wed, 30 Sep 2015 15:21:51 +0200

Hi Greg / others,

I'm rereading the canonicalization RFC, and it does seem to already provide the "case correction extension" that we said we'd need.

Greg, does this make you see things differently?  If not, I will continue with TXT instead of PTR.

>  What you are talking about is unquestionably an extension to RFC 4120.

RFC 6806 section 9 adds

The case-corrected realm in the krbtgt reply could be considered
"a realm closer to the service" and it would be followed instead of
the original one.  That is, when canonicalization is requested.  That
could be used for case correction -- if you agree to what I'm reading
in this text.

So we are back to our choice, and it's arbitrary to me which we choose.

We might still decide on TXT on grounds of
 1. it's been implemented, and informally documented
 2. it completely evades case-dependent problems
 3. it's more efficient (for mixed-case realm names)
 4. the _kerberos prefix bypasses overloading of TXT

Whereas PTR has advantages
 1. More akin to the domain-style names
 2. Initial mapping to all-uppercase works for the majority of cases
 3. Case correction by the KDC works for the few other cases
 4. It offers a future path for case-insensitive realm names in KDCs

Opinions, anyone?  To me it feels that everything that works according to the standards is acceptable to this group now?

Cheers,
 -Rick

---

From: Greg Hudson <[email-masked]>
Date: Wed, 30 Sep 2015 11:22:07 -0400

> could be used for case correction -- if you agree to what I'm reading

Please refer back to
http://www.ietf.org/mail-archive/web/kitten/current/msg05852.html
where I responded to almost exactly the same reasoning.  The quoted RFC
6086 text does not change the behavior of requests for krbtgt/X
principals; it applies similar (but not identical) behavior to requests
for other principals.  You could make an argument that "for any service"
means that requests for krbtgt/X principals are also affected, but no
implementor interpreted the text in that way (because it would have
broken many existing multi-hop cross-realm scenarios), so that wouldn't
be helpful.

If the client makes a request for krbtgt/X and the KDC responds with a
ticket for krbtgt/x, the currently expected client behavior is to ask
realm x for krbtgt/X, not to decide it wanted realm x instead.