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

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

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