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

[Rick van Rein <[e-mail]>]

Hi Greg,

> 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.
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).

> 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.
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
> 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.
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.

> 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.
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