Subject: Re: comments on kerberos-revisions-05.txt

From: Jeffrey Altman <[email-masked]>
Date: Mon, 17 Apr 2000 19:53:43 EDT

> Wrong.
> 
> The client passes either "[email-masked]" or "[email-masked]"
> as a "hostbased service name to Kerberos (via or without GSS-API",
> and the transformation into a Kerberos principal name canonicalizes
> the hostname via DNS.  That's what rfc2743, Section 4.1 specifies
> and what MIT Kerberos 5 has been doing all the time.
> 
> Therefore your client is going to acquire a service ticket to
> 
>    host/attackers.host.of.choice@ANY-TRUSTED-REALM
> 
> and perform a successful mutual authentication with the attackers
> host of choice.
> 

Question:  

This makes no sense.  What you are telling me is that my providing
a fully qualified domain name to Kerberos 5 is meaningless because not
only is Kerberos 5 going to perform a Forward DNS lookup (which will
not cause a name change) but that it is also going to perform a
Reverse DNS lookup which will cause a name change?

I find this very hard to believe.  When I get some time later tonight
or tomorrow I will setup my Network Monitor and debugger and trace all
of the DNS calls being made by MIT Kerberos 5 during the acquisition
of a service ticket. 

If this is what is being done it is absurd.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Tue, 18 Apr 2000 00:14:54 -0400

>> the hostname via DNS.

> This makes no sense.  What you are telling me is that my providing a
> fully qualified domain name to Kerberos 5 is meaningless because not

It only takes a forward lookup to canonicalize a hostname, at least in
the sense of "follow cnames to the domain they point to".  (If there
are multiple A records with the same IP address, then it will take a
PTR lookup to fine out which name(s) have PTR records, which I suppose
someone might think of as "canonicalizing.")  For instance, if I do a
recursive query for hodge.mit.edu in a, I get answers like:

	hodge.mit.edu.          6H IN CNAME     HODGE-PODGE.MIT.EDU.
	HODGE-PODGE.MIT.EDU.    6H IN A         18.187.1.128

And the resolver will store the name HODGE-PODGE.MIT.EDU into h_name.

Kerberos implementations have sometimes performed an additional PTR
lookup, I think to work around broken (or at least Different) Sun
resolvers.  But it's certainly not necessary from a protocol point of
view.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 18 Apr 2000 01:23:05 -0400

> > and what MIT Kerberos 5 has been doing all the time.

The RFC says:

   When a reference to a name of this type is resolved, the "hostname"
   may (as an example implementation strategy) be canonicalized by
   attempting a DNS lookup and using the fully-qualified domain name
   which is returned, or by using the "hostname" as provided if the DNS
   lookup fails.  The canonicalization operation also maps the host's
   name into lower-case characters.

What the MIT code does is a little different, because we've found that
Certain Vendors didn't give us any easy way to get the canonical name
without doing the reverse lookup.  Now, though, we've got code that
calls the resolver directly (for SRV records), so maybe it wouldn't be
so hideous to add a little more, to look up CNAME records and skip the
PTR records.

As I read this, though, it is not *required* that the canonicalization
be done at all.  In fact, the appendix "CHANGES RELATIVE TO RFC-2078"
says in part:

   Name-related:

      Downgraded reference to name canonicalization via DNS lookup to an
      example.

> Reverse DNS lookup which will cause a name change?

Merely getting an FQDN doesn't ensure that it's the canonical name.
For example, "kermit.columbia.edu" is an FQDN, but the name that we
use for Kerberos is watsun.cc.columbia.edu.

Similarly, the convenience alias "prep.cygnus.com" is not the
canonical name, "prep.ai.mit.edu" is.  Actually, prep.cygnus.com has a
CNAME record, pointing to prep.ai.mit.edu which has an A record, but
the PTR record for the address points back to gnudist.gnu.org.  So in
one sense prep.ai.mit.edu is the canonical name, but gnudist.gnu.org
might also be considered the "real" name.  (This gets us into issues
regarding multihomed hosts with different "primary" names for
different interfaces; people with personal domains listing A records
for home systems where the ISP rigidly controls the PTR records with
no customization options; server clusters with a common name mapping
to multiple IP addresses, each of which has a different PTR record;
etc.)

Doing away with all canonicalization of FQDNs means that either (a) a
service would have to be aware of and have keys for every convenience
alias the host has, even in other domains outside the control of the
maintainers of the host or service, (b) we have to change names
somewhere else, such as through canonicalizing principal names or
using secure DNS, or (c) the user of such aliases just loses.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Apr 2000 12:05:31 +0200 (METDST)

> Reverse DNS lookup which will cause a name change?

Kerberos 5 is going to do a forward DNS lookup, whether or not the
name that you supply is fully qualified or lacking the domain name.
The spec requires that if DNS claims the supplied name to be a CNAME then
it must be replaced by the canonical name that the CNAME record points
to.  This is what the spec means by "canonicalization", and it will
happen with regular forward DNS lookup.  Now if you spoof the Kerberos
DNS lookup and give it a CNAME when it canonicalizes the hostbased
service name, you can have this name replaced.

Am I really so bad at explaining the issue?  :-(

-Martin