Subject: RE: comments on krb-dns-locate draft

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 3 Dec 1999 22:23:27 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 6:28 PM
> To: Jonathan Trostle; [email-masked]; Mike Swift (NT)
> (Exchange)
> Subject: Re: comments on krb-dns-locate draft
> 
> I see it differently: Can we do something about the insecurity of DNS,
> so that Kerberos (and other security-critical functions) *can* rely on
> it?  Consequently, I don't view it as a Kerberos protocol issue.
> There are already proposals in the works for secure DNS.  Can we make
> use of none of this work?

It is possible to not rely on DNS, so good security practice would suggest
that that is the best way to go: the fewer things you have to rely on, the
more secure the system (everything else being equal).

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 8 Dec 1999 13:12:23 -0800

> From: Ken Hornstein [mailto:[email-masked]]
> Sent: Wednesday, December 08, 1999 12:22 PM
> 
> >In the case above, the client should ask for a ticket for
> >"host/name.foo.com". The clients wants the KDCs assurance 
> that they are
> >talking to the name they uttered.
> 
> So I guess the fundamental problem is that naming was always 
> considered
> "external" to Kerberos.  Now the proposal we're debating is that this
> model should be changed and naming should be placed inside of
> Kerberos.  Is this the right thing to do?  I honestly don't know.

If you want service authentication, then kerberos has to say _something_
about service names. It needn't be able to resolve them, but it needs a
secure association betweens names and keys.
> 
> >(One can also use trustworty local information to map what 
> the user types
> >into the service name.)
> 
> mmmmm, hosts.txt.

Right; or the local DNS suffix search list. (Handles the case where the user
just types "name". The client app knows how to add "host/" on to the front
(or whatever the right service type constant is), and the client DNS
resolver will, without recourse to untrusted databases, be able to expand
"name" to "name.foo.com"; putting both those together, "host/name.foo.com"
can be constructed in a trustworthy way.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 9 Dec 1999 10:34:11 -0800

> Sent: Wednesday, December 08, 1999 9:32 PM

> Jeffrey Altman <[email-masked]> writes:
> [quoting Paul here, I think]
> > > This is a slight oversimplification, but if one wants service
> > > authentication, then what needs to be authenticated is 
> "what the user types"
> > > (or picks via a UI), not something looked up in an 
> insecure database. 
> 
> Using an insecure database is bad.  But so is requiring the user to
> type the canonical FQDN all the time, especially considering
> service-oriented and convenience aliases.

Using local, secure, info to change short convenient names into precise,
long, names is OK.
However, it must be said that the best way to make sure one is connected to
exactly the service one really wants is to provide exactly the full name of
the service.

> 
> If my default domain raeburn.org has a CNAME record
> cygftp->ftp.cygnus.com, should that ftp server have to have a
> "ftp/[email-masked]" key in order for me to access it
> using that alias?

Yes. The whole idea is that the KDC is like a notary or a witness -- a
reliable, mutually trusted third party who attests that a service is the
legitimate owner of a certain name. That's how service authentication _has_
to work.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 9 Dec 99 13:45:53 EST

> > > Assuming that all seven servers are in the same realm, the 
> > client doesn't
> > > care which of the seven it talks to, one solution which 
> > fits in well with
> > > our proposal and results in minimal changes to your code 
> > here is to use a
> > > multi component principal name (mentioned by Paul Leach) of 
> > the form:
> > > host/sawasdee.cc.columbia.edu/cunix.cc.columbia.edu
> > > The KDC can lookup up this name in the name database and 
> > return the correct
> > > realm. 
> > > Jonathan
> > 
> > And how is application supposed to know to request that name?
> 
> Because it found an SRV record for the name "cunix.cc.columbia.edu". Or
> multiple CNAMEs.

So if the user decides to telnet to sawasdee.cc.columbia.edu the
client software is supposed to magicly figure out that sawasdee is
just one of a cluster called cunix.cc.columbia.edu?

> > How is the service supposed to know to accept it?
> 
> Because it is configured to know it is one of a set of replicas.

There is no mechanism in place for a service to know that it is
installed on a machine which is part of a cluster sharing a common
alias.  Nor is there any reason why the service should be aware of
this information.

Before providing one line answers it is necessary for you to provide
the list of assumptions that you are making about the environment
because it is obvious from the direction that all of these threads
have taken that there is a huge gap in the assumptions being made
about the environment.

In all of my answers I am assuming a heterogeneous environment with
minimal configuration information available to both the client and the
services.  I make no assumptions about which vendor's KDC is being
used and backwards compatibility is of primary importance.  My goal is
make Kerberos as easy to use as the broken authentication provided by
SSH.

Kerberos for its entire existence depends on the DNS infrastructure.
While I appreciate the desire to close potential attacks it seems
absurd to me to be spending time on working to avoid an attack that
will be will closed by the deployment of DNSSEC.  Any protocol change
will take X number of years to agreed to, implemented and then
deployed.  How does that time frame compare to the deployment time for
DNSSEC?  Are they on the same curve?  If so, we should drop this
discussion entirely.

We might as well decide to build a secure time service into the
Kerberos protocol and duplicate all of the work being done in the
Secure Time Working Group.

    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: Jeffrey Altman <[email-masked]>
Date: Thu, 9 Dec 99 14:38:09 EST

> Well, an implementation that does not depend on DNS security is already in
> fairly wide use -- a 100's of thousands of copies. Soon to be millions.
> 
> And it depends on nothing not in the 1510bis draft.

I find it hard to believe that Win2000's Kerberos 5 implementation can
interoperate with anything but itself if we were to remove all DNS
functionality from it.

It doesn't interoperate now because of the problems with its
implementation of the resolver functions.  Windows 2000 insists on
knowing itself by its own local names and without regards for the
names assigned to it by the ISP.  This makes it impossible to host a
non-Microsoft Kerberos service on Win2000 since the client and service
never agree on the name of machine.

Windows insists on believing its name is 

  Host Name . . . . . . . . . . . . : TP770Z-WIN2K
  Primary DNS Suffix  . . . . . . . : KRB5.COLUMBIA.EDU

regardless of whether its real name.  There is also an assumption made
by Microsoft regarding REALM names.  It is assumed that a REALM name
is a valid DNS suffix.  The name KRB5.COLUMBIA.EDU is a valid REALM 
but it is absolutely not a valid DNS Suffix.  Performing a DNS SRV
query on 

  _kerberos.TP770Z-WIN2K.KRB5.COLUMBIA.EDU IN TXT 

fails.  

  _kerberos.KRB5.COLUMBIA.EDU IN TXT

fails.

  _kerberos.COLUMBIA IN TXT   

returns "CC.COLUMBIA.EDU" BUT that is not the realm for this machine
which is KRB5.COLUMBIA.EDU.  That is because this machine has multiple
names depending on where it is located.  The DNS TXT records for
the names in the DNS are linked to the correct values.  For instance
nslookup on 63.71.143.65 reports the DNS name as 

  RED-63-71-143-75.man.nyc.redconnect.net

and a query on 

  _kerberos.RED-63-71-143-75.man.nyc.redconnect.net IN TXT

will return "KRB5.COLUMBIA.EDU" (the proper realm).

But this query cannot be made on a Windows 2000 system because Windows
2000 won't trust the DNS.  It decides to evaluate the names of its
local adapters via its own methods and determines the wrong realm
name.  Hence, Kerberos authentication fails.

It is not appropriate for you to describe Windows 2000 has being an
implementation of Kerberos based on the 1510bis draft which has no
reliance on DNS.  The only way it could have no reliance on DNS would
be if the implementation never used a DNS name to refer to a host OR
if it did not itself rely on the use of DNS SRV and DNS TXT records to
find out information about the KDC.  (Which btw is not part of the
1510bis draft and was not documented my Microsoft and might never have
been if it were not for Ken Horenstein and myself.)

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 9 Dec 1999 10:26:40 -0800

> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Wednesday, December 08, 1999 6:54 PM
> To: Jonathan Trostle
> Cc: Paul Leach (Exchange); 'Ken Hornstein'; Derek Atkins; Jonathan
> Trostle; Ken Raeburn; [email-masked]; Mike Swift (NT)
> (Exchange)
> Subject: RE: comments on krb-dns-locate draft
> 
> 

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Dec 99 19:00:18 EST

> I do not know that any shipping MIT KDC implements the needed piece of the
> 1510bis draft -- but that's a statement made in complete ignorance. 
> 
> I can say that there is nothing that precludes an MIT KDC from doing so --
> the spec is complete enough to permit an implementation.
> I in fact suggested an implementation -- use the mechanism that clients
> currently use: use the krb5.conf file and look up the name and get the
> associated realm.
> 
> If it did so, then indeed you "can take [your] Windows 2000 client and plunk
> it down in [your]
> network where [you're] running a MIT KDC, and it will work fine without
> any of the security problems we've been discussing to death."

Why do I feel like we are going around in circles.

Looking up a host name in a krb5.conf file does not provide protection
from a DNS attack.  The name that is looked up in the krb5.conf file
is the name that the application retrieves from a reverse DNS call.

Again, the user wants to contact a service.  The user says 

  telnet cunix

telnet resolves the name cunix by calling gethostbyname().
gethostbyname() then proceeds to look for 

  cunix
  cunix.dns-searchlist-1
  ...
  cunix.dns-searchlist-n

At this point telnet has a list of possible IP addresses.  It choose
A.B.C.D.  At this point we do not know the name of the host that is
represented by A.B.C.D.  So we call gethostbyaddr().

At this point we can now look in the local krb5.conf file (if we have
one).  I am traveling around the country and walk into a cyber cafe.
Do I have my krb5.conf in my pocket?  Does the cyber cafe?  

No.  So I must query someone.  Again, the DNS is used.

Now, you are stating that the Win2000 client does not use DNS
queries.  However, the attack is not taking place within the Kerberos
implementation.  The attack is taking place in the application prior
to Kerberos being called.

So you can't avoid the attack unless you remove the use of DNS
completely.  All you can do by pushing off the Realm lookup to the
user's KDC is change who determines that the attacked name belongs to
the realm of the attacker.

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Dec 99 19:41:38 EST

> Applications shouldn't do that (reverse DNS lookups). The KDC shouldn't do
> that either. Nothing in the nature of the krb5.conf file says that they have
> to.

Applications do it because it has been shown to be necessary to deal
with multi-homed machines; with aliases; and to find the hostname that
is stored with X.509 certificates.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 16:30:06 -0800

> Sent: Friday, December 10, 1999 4:00 PM
> To: Paul Leach (Exchange)
> Cc: 'Ken Hornstein'; Paul Leach (Exchange);
> [email-masked]

> Do I have my krb5.conf in my pocket?  Does the cyber cafe?

Exactly why I suggest having it in the KDC.
  
> to Kerberos being called.

Applications shouldn't do that. Ours don't.

> completely.

They can look up A records without fear of anything except DOS attack.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Dec 99 20:21:42 EST

> I.e., they do it because being secure is less important than ease of
> use/admin.
> 
> That doesn't make it good security practice, or one we have to maintain.
> 
> I disagree that it is actually necessary.

The whole reason that this topic even came up a year (or more ago) is
because the ease of use is a significant factor in convincing users to
use security software.  If ease of use was not as important as being
secure we would all have been using Kerberos years ago.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 17:14:57 -0800

> Sent: Friday, December 10, 1999 4:42 PM
> Cc: 'Ken Hornstein'; [email-masked]

 
Paul

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 10 Dec 1999 18:56:58 -0800

At 02:34 PM 12/10/99 -0800, Paul Leach (Exchange) wrote: 

> > From: Ken Hornstein
> [<mailto:[email-masked]>mailto:[email-masked]] 
> > Sent: Friday, December 10, 1999 2:14 PM 
>
> > Ah, I was going by Jonathan's example, where he said: 
> > 
> > >It does the DNS lookup, finds out that it's an alias. On the reverse 
> > >lookup, it picks up the primary name. So it knows how to 
> > construct the name. 
>
> I disagree with Johnathan's example. 

I was explaining how our proposal can securely handle the multiple CNAME RR
scenario that Jeffrey Altman described, if one wants to build a client in this
way. There are probably other ways to solve the same problem.

Jonathan

>
> The client does a DNS lookup, say of "foo.bar.com", and gets back CNAME
> "waz.bar.com" which has an A record for (say) 10.0.0.13. It constructs
> "host/foo.bar.com" because that's what the user specified (and wants
> authentication of) and sets the "name canonicalization" flag. The KDC looks
> up "foo.bar.com" in it's krb5.conf file and sees that it is in the "bar.com"
> realm, so completes the the name as "host/[email-masked]", and does the
> regular TGS processing. When the client gets back the service ticket, it
> opens a socket to (say) the telnet port on 10.0.0.13 and does the usual
> kerberized telnet thing, including sending the service ticket.
>
> Other than the possible denial of service attack, there was no dependence on
> the DNS lookup being correct. 
>
> Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 19:23:26 -0800

-----Original Message-----
> From: Jonathan Trostle [mailto:[email-masked]]
> Sent: Friday, December 10, 1999 6:57 PM

> I was explaining how our proposal can securely handle the multiple CNAME
RR scenario that Jeffrey Altman described, if one wants to
> build a client in this way. There are probably other ways to solve the
same problem.

Right -- I don't think it is necessary to to an invernse DNS lookup.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 10 Dec 1999 19:28:11 -0800

> Sent: Friday, December 10, 1999 5:22 PM

> secure we would all have been using Kerberos years ago.

The "ease of use" issue in this case is that if a service wants to have
multiple aliases, then it needs multiple entries in the KDCs database in
order to support serive authentication and avoid dependence on DNS.

That hardly poses any sort of insurmountable barrier. Are you seriously
proposing that we continue to rely on spoofable DNS? Or that we do so until
DNSSEC is deployed? Rather than (e.g.) create multiple entries in the KDC
database for a service so that we can totally avoid dependence on DNS?

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 15 Dec 99 11:49:43 EST

> database for a service so that we can totally avoid dependence on DNS?

sorry, it has taken so long to get back to this thread but I have been
attempting to get some work done.

The answer to your questions is "yes, I am recommmending that we do so
until DNSSEC is deployed."  

The reasons are very simple:

 . backward compatibility

 . scaling

 . its wrong to re-invent the wheel

As I mentioned in a previous note that was ignored, even if there are
no compatibility issues from a security perspective it only makes
sense to implement this new protocol if the deployment time for the
new protocol is significantly faster than the deployment time for
Secure DNS.  

In this case, old applications will continue to perform their own
lookups in order to handle the input from the user in the form of
incomplete DNS names or as IP addresses.  They won't use the new 
protocol.   New applications will use the new service but have to be
able to deal with KDCs that do not support it and still work for the
end user. 

What happens if a new client contacts an old KDC?  The old KDC ignores
the service name translation bit and either fails to return a service
ticket that exists.  Is there any way for the client to know why they
are unable to access the service from the machine the new client is on
but not the machine the old one is on?  Or why after an upgrade of
their vendor's client software everything suddenly stopped working?
There isn't.  I don't know about you, but I worry about the support
costs involved when making changes between software revisions.  

If the KDC is going to provide service name translations and host to
realm mappings then it needs to be able to scale.  Remember a previous
note in which I mentioned that a REALM != DOMAIN?  In fact, one DOMAIN
may contain hosts in any number of REALMs.  This is particularly true
as we start to have people working from home over the Internet via DSL
and cable lines.  People are going to have their home machines secured
as part of the company's REALM.  

Now in my situation my ISP exports a TXT record

  _kerberos.RED-63-71-143-75.man.nyc.redconnect.net  

which maps to 

  KRB5.COLUMBIA.EDU

Does the hostmaster for columbia.edu know or care about it?  No.

Does the Kerberos admin for KRB5.COLUMBIA.EDU know about it?  Yes.

Do the Kerberos admins for all of the other realms in the world care
about it?  Not now.  But in your model they will have to.  Since in
order for their KDCs to perform the proper service name to realm
mapping they will have to know about this entry.  How are they going
to get this information?  Are we going to setup a Root KDC in order to
transmit this information?  Or are we simply going to let the KDC make
a DNS request on the assumption that we trust the DNS closer to the
KDC than we do the DNS the user is using?

What about when DNSSEC is widely deployed?  Do we really want to carry
around this extra baggage of a protocol?

Its not like this vulnerability between trusted realms has not been
known about.  You made a statement last week similar to "if this is
the way that Kerberos works then it has always been broken."  Yes. It
has been broken.  This attack has been documented for a very long
time.  It is documented in 1510bis.  This is not a surprise to
people.  But the reality is that security is not perfect.  This is a
weakness that requires a cross realm trust and a violation of that
trust.  If the trust is violated I believe that a DNS is the least of
our worries.  And it is this reason that people are as careful as they
are about setting up cross realm trusts.  In the end we are more
likely to issue separate sets of credentials to the user for both
realms than we are to configure a cross realm trust unless we control
both realms.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 16 Dec 1999 09:36:38 -0800

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Monday, December 13, 1999 7:07 AM
> Cc: 'Ken Hornstein'; Jonathan Trostle; [email-masked]
> Ok, what happens if the client types "foo," which implies DNS lookups
> of:
> 	foo
> 	foo.dns-search-1
> 	...
> 	foo.dns-search-n
> 
> Obviously there is no 'host/[email-masked]' which would verify what the
> user typed.  The other problem is that the dns-search{1-n} on the
> client may not match the dns-search{1-n} on the KDC, so you can't just
> pass 'foo' and always get the same implied host.
> 
> How do you deal with this situation?

The client sends "host/foo.dns-search-n" for the chosen "n".

The choice of names to look up (via the search suffixes) is under the
control of the user. Since all they typed is "foo", all they can expect is
that the KDC will guarantee that they got a server with "foo" as a prefix.
They will get that guarantee, regardless of what DNS returns.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 17 Dec 99 1:06:52 EST

> > 
> > So the KDC must be sent N queries?
> 
> What made you think that? It gets sent the "host/foo.dns-search-n" for the
> _chosen_ "n". I.e., if the DNS lookup that hit was "foo.dns-search-3" then
> what gets sent to the KDC in the TGS request is "host/foo.dns-search-3".

Because according to you, any use of the DNS is insecure, therefore we
must only use the KDC.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 10:18:39 -0800

> From: Paul Leach (Exchange) 
> Sent: Friday, December 17, 1999 10:12 AM
> To: [email-masked]'
> Cc: 'Derek Atkins'; 'Ken Hornstein'; Jonathan Trostle;
> > Sent: Thursday, December 16, 1999 10:07 PM
> >
> > > > 
> I didn't say that. I said that you can't depend on DNS being 
> correct for security. This doesn't.
> 
> I explained the security property that gets guaranteed when a 
> non-FQDN is used -- the user gets assurance that they are 
> talking with a server whose left-most labels are the name 
> supplied by the user. That property does not depend on the 
> DNS being correct.

Actually, a more precise/correct statement of the security property is that,
when a non-FQDN is used, the user gets assurance from a trusted authority or
authorities that they are talking with a server known by a DNS name that has
as its left-most labels the name supplied by the user and the remainder one
of the names in the DNS search list.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 10:11:36 -0800

> Because according to you, any use of the DNS is insecure, therefore we

I didn't say that. I said that you can't depend on DNS being correct for
security. This doesn't.

I explained the security property that gets guaranteed when a non-FQDN is
used -- the user gets assurance that they are talking with a server whose
left-most labels are the name supplied by the user. That property does not
depend on the DNS being correct.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 17:24:31 -0800

> Sent: Friday, December 10, 1999 2:42 PM
> Cc: [email-masked]
> Okay, I looked at draft-ietf-cat-kerberos-revisions-04, and the only
> thing I could find on naming was the following footnote:
> 
> [15]This can be accomplished in several ways. It might be 
> known beforehand
> (since the realm is part of the principal identifier), it 
> might be stored in
> a nameserver, or it might be obtained from a configura- tion 
> file. If the
> realm to be used is obtained from a nameserver, there is a 
> danger of being
> spoofed if the nameservice providing the realm name is not 
> authenti- cated.
> This might result in the use of a realm which has been 
> compromised, and
> would result in an attacker's ability to compromise the 
> authentication of
> the application server to the client.
> 
> Which really doesn't say anything about a protocol extension.
> 

No extension is needed. The question is: what does a KDC do when a TGS
request arrives with no realm specified for the server, and the server isn't
in the KDC's realm.

For the MIT, Cybersafe, and MS KDCs, they all have various ways of figuring
out what the next hop in the authentication path is -- some use a database
("see  the [capaths] section in the krb5.conf file), some use the structure
of the realm names.

If you look at appendix A.6:

        server := lookup(req.sname,realm);

        if (!server) then
                if (is_foreign_tgt_name(req.sname)) then
                        server := best_intermediate_tgs(req.sname);
                else
                        /* no server in Database */
                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
                endif
        endif

As I read it, this means that if the server principal ID is not in the KDB,
then instead of generating a ticket to the server, generate a ticket to the
TGS service of the next realm on the authentication path.

Also, note that section 1.1 on "Cross-realm" says:

"Realms are typically organized hierarchically. Each realm shares a key with
its parent and a different key with each child. If an inter-realm key is not
directly shared by two realms, the hierarchical organization allows an
authentication path to be easily constructed. If a hierarchical organization
is not used, it may be necessary to consult a database in order to construct
an authentication path between realms."

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 17:36:41 -0800

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Friday, December 17, 1999 5:18 PM
> Cc: 'Derek Atkins'; [email-masked]'; 'Ken Hornstein'; Jonathan
> Trostle; [email-masked]
> Right...  And gethostbyname() just returns the (insecure) information
> returned from the DNS Server, which you claim not to trust. 

Totally wrong. Not all the info is from the DNS server.

 The
> hostent structure does not get filled with any client data.  In my
> example, the hostent returned would be:
> 
> struct hostent {
>     char FAR *       h_name;		"foo.tim.org"
>     char FAR * FAR * h_aliases;		NULL

Wrong again, h_aliases[0] will be "foo.bar.com", which is filled in by the
client side DNS resolver, based on the fact that the lookup for
"foo.bar.com" returned a CNAME. Hence, "foo.bar.com" is what the client will
use to construct "host/foo.bar.com".

>     short            h_addrtype;	AF_INET?
>     short            h_length;		4
>     char FAR * FAR * h_addr_list;	10.2.3.4, NULL
> };
> 
> This is what I'm saying, the telnet application has no way to know
> that the resolver tried "foo.bar.com", because the hostent will get
> the (forged) hostname of "foo.tim.org", and that's what get's
> returned.

Wrong.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 17 Dec 99 20:39:15 EST

> >returned from the DNS Server, which you claim not to trust.  The
> In this case the search list must contain only one completion element,
> until the client has an API that will also return the foo.bar.com name.
> 
> Jonathan
> >
> >-derek

Jonathan:

How does having only one completion element reduce the ability to
perform the attack?  

The only way to not trust DNS is to not use it.  PERIOD.

If I as an application makes even a single call it can be spoofed.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 18:11:47 -0800

> Sent: Friday, December 17, 1999 5:39 PM
> 

Wrong. One can use it to look up an IP addr, and then the worst that can
happen is a DOS if the answer is spoofed.

Paul

---

From: Tony Andrea <[email-masked]>
Date: Fri, 17 Dec 1999 17:56:34 -0800

this is the crux of the whole issue.  the statement that the
only way to trust dns is to not use it is completetly and
utterly false.

the way you do this is exactly what paul has been trying to explain.
you use a trustworthy and very reliable source (kdc) to validate
the information coming from the untrustworthy source (in this
case dns).  the way our clients do that is to generate a
tgs-req with the untrustworthy information and present it
to the TGS for validation.  if you get a valid ticket back,
you now may trust the information from the untrustworthy
source because the trustworthy source says it's good.

in other words, it doesn't matter where you collect data
from, it only matters that you eventually validate that data
before you use it.

later,
tony.

--

Tony Andrea | Product Architecture | CyberSafe Corporation 
1605 NW Sammamish Road Issaquah, WA 98027 425-391-6000 
mailto:[email-masked] | http://www.cybersafe.com 

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]]
Sent: Friday, December 17, 1999 5:39 PM
To: Jonathan Trostle
Cc: Derek Atkins; Paul Leach (Exchange); 'Derek Atkins'; 'Ken
Hornstein'; Jonathan Trostle; [email-masked]
Subject: Re: comments on krb-dns-locate draft

Jonathan:

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 18 Dec 99 1:40:55 EST

> from, it only matters that you eventually validate that data

I am at the point where I refuse to respond to anymore of these
circular arguments.   Remember, the reason we do not want to use a DNS
query by the client is because the DNS query from the client might be
spoofed so that it presents an alternative name which is still a valid
service to the KDC.  Hence, even if the KDC was to validate the name
it would pass the validation test.

Only by not performing the DNS query at the client does the spoofing
attack not present itself.

At this point I am going to stop responding to these messages because
we are getting absolutely nowhere.

Have a good holiday.

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 18 Dec 99 2:00:15 EST

Just one more comment:

all of the statements are making the assumption that the application
knows before it makes the connection that it is going to use Kerberos
for authentication.

In the case of Telnet, TLS, SSH, GSS-API, ... the application does not
necessarily know that it is going to be using Kerberos to authenticate
to the host until after the host is connected to AND the host requests
that the application authenticate the user with a particular type of
authentication (or cipher suite.)

In these environments where multiple authentication methods are
supported DNS must be used by the application to determine who it is
going to connect to.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Sat, 18 Dec 1999 16:51:47 -0800

> Sent: Friday, December 17, 1999 10:41 PM
> To: Tony Andrea
> Cc: Jonathan Trostle; Derek Atkins; Paul Leach (Exchange); 'Ken
> Hornstein'; [email-masked]
> circular arguments.
> Remember, the reason we do not want to use a DNS
> service to the KDC.

Which DNS query are we talking about? That may be the problem here. I'm
saying that spoofing the A record lookup for the host name doesn't cause a
problem; that spoofing CNAMES doesn't cause a problem (because the result
isn't used in the pricipal name); that looking up the realm in DNS is wrong
(for the reason you say); and that all uses of inverse IP address lookups
that I have heard are wrong.

So, what we have are two cases where using DNS is OK, and two where it
isn't.

The way I read Tony's message is that the thing that is being validated by
the KDC is that the IP address obtained from DNS was good. This is validated
because only if the IP address is good will the service at that IP address
be the one that knows the key associated with the principal name supplied by
the client, said principal name being derived from what the user supplied
and local configuration information.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 19 Dec 99 15:53:31 EST

> Not to mention a reverse look up is not reliable, or secure. The
> reverse zones are woefully incomplete and PTR RRs inconsistent with
> As. For example, it is common for find the same A RR for foo.com and
> www.foo.com but to which will the PTR point if it exists? Sometimes I
> see foo.com, sometimes www.foo.com, and sometimes
> someotherhost.foo.com. Which should I believe? What defines an
> authoritative FQDN? The PTR or the A?
> 
> As a case example I have complete control over a forward zone. I have
> no control over the reverse zone, which is operated by an ISP.
> Consequently, I cannot assure what will be returned via a reverse look
> up or whether it will succeed. In fact, for a two year period a
> previous ISP refused to correct a PTR RR error. 
> 
> BTW, Solaris, once upon a time, did the reverse look up as a security
> thing. Most people disabled it because of the issues I mention in my
> first paragraph.

And yet most users of tcp wrappers use PARANOID mode which refuses to
allows a connection to succeed if the PTR and A records do not match.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 99 11:15:52 EST

> TLS does not depend on DNS security to do server authentication. Neither
> does it depend on its A records to be correct for anything but preventing
> DOS attacks. It does require that an FQDN be produced to compare against the
> one in the certificate supplied by the server.

Exactly.  The FQDN must be compared and there is only one FQDN allowed
in the certificate.  So if you have a host with a series of aliases it
is necessary to perform a Reverse lookup to find the name of the host
in order to compare it to the FQDN in the certificate.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 99 11:27:09 EST

> > It is only after the reverse lookup that the client has a fully
> > qualified domain name with which to determine the realm.  As an
> > application writer I do not have the luxary of only implementing my
> > programs on operating system code that is less than a year old.
> > Please keep backward compatibility in mind when you are making your
> > suggestions. 
> 
> Well, backwards compatibility for those platforms lets out DNSSEC as a
> solution, too. So, I guess unless the Kerb for them does its own DNS
> resolver, those platforms just won't get service authentication.

But they get service authentication now.  So you are saying that these
platforms just won't be able to make connections?  

As for DNSSEC, DNSSEC is supposed to export its data to non-DNSSEC 
systems.  If the client is non-DNSSEC it still retrieves the
information.

> > But then you still haven't answered the question about the KDC and
> > where it is going to get trusted data for the realm.  There is not a
> > KDC in the world other than mine that is going to know that the realm
> > for 63.71.143.75 is KRB5.COLUMBIA.EDU unless it uses a DNS TXT query
> > since the domain is used to provide DSL connections to homes and
> > businesses.  Every single ip address is likely to belong to a separate
> > REALM.  My ISP (redconnect.net) is very likely to not even be running
> > a KDC.  So where are you going to get the authoritative response from?
> 
> Why does it have to know about 63.71.143.75? What do ISPs have to do with
> anything? The client is configured to know its KDC, so your KDC is the only
> one that has to know. The client will supply "host/foo.bar.com" as the
> principal ID, and the KDC can either
> a) find that in its local KDB
> b) find an exact match for "foo.bar.com" in the FQDN->realm DB
> c) find a wildcarded match in the FQDN->realm DB
> d) assume that its parent is the right realm.

It better know about 63.71.143.75 because this host exports services
which are protected by Kerberos.  

And it is incorrect to assume that my laptop knows its own REALM.  My
laptops REALM changes depending on which organization I am at.  So I
do not have a hard coded REALM.  My realm is determined by a DNS TXT
query. 

> > 
> > You clearly are not expecting every KDC to keep a local file which
> > contains the ip address to realm mappings.  So how is this information
> > supposed to be distributed?
> 
> No, I expect it to keep FQDN to realm mappings. Just like clients have to
> today. If necessary, it gets configured by hand. Just like clients have to
> today, only much better, because only KDCs need to be configured.
> 
> In many cases, where an organization only has one KDC, there might be
> exactly one entry, e.g.,
> *.COLUMBIA.EDU -> KBB5.COLUMBIA.EDU 

And what I am telling you is that this model does not scale.  

It does not scale in an organization with multiple realms sharing a
common domain name.  Whether that be an organization such as a
University or an ISP.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 01:57:07 -0800

> Sent: Sunday, December 19, 1999 12:12 AM
> Cc: Tony Andrea; Jonathan Trostle; Derek Atkins; 'Ken Hornstein';
> The problem is that your assumptions about the implementations of
> gethostbyname() are wrong.  You are assuming that all implementations
> of gethostbyname() return fully qualified domain names.  They do not.
> 
> Microsoft Windows 95/98, SunOS, and Solaris are for examples that come
> to mind that do not return fully qualified domain names in response to
> a gethostbyname("foo") request.

Then those platforms can't get mutual authentication if the user supplies a
non-FQDN. Unless the Kerb implementation on them includes its own DNS
resolver that can return the FQDN that sucessfully resolved.

> 
> In order to get the fully qualified domain name on these platforms it
> is necessary to perform a reverse dns lookup via gethostbyaddr() using
> the address returned by the gethostbyname() query.

Or do their own DNS resolver.

> ---

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 99 14:19:50 EST

> 
> And your implementation isn't secure. If it is going to insist on being
> insecure, and as a result doesn't interop with ours, I find it hard to care.
> 
> Paul

I am trying to provide the strongest form of authentication available
to client and servers using heterogeneous operating systems.  If you
are attempting to say that operating systems that cannot be secure
should not be used (and by that I mean should not be sold) then you
better go talk to Bill and have Windows 98 and NT4 pulled from the
shelves.  

You also better have NTLM removed from Win2000.

So please do not try to take the stance that if the security is not
perfect then it is not acceptable.  I have to support clients using
insecure operating systems including those sold by your company.

---

From: "John Brezak (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 10:57:49 -0800

Given the torrent of email on this subject, it really is time to try and
summarize this thread and move on. In further discussion it is important to
separate the debate on krb-dns-locate and krb-referrals - they deal with
slightly different things.
A. The important points in the krb-referrals I-D are:

1) The Microsoft KDC implements "aliases" for principal names (SPNs and
UPNs). For services we register the SPNs to handle the long (DNS) and short
(NetBIOS) names of the service. Because we have the short names, our clients
do not ask DNS to canonicalize the name. The name that the user types is the
name that is used for authentication. For clients the registered alias (UPN)
is generally the user's email name. This name is the same no matter what
realm the user's principal is associated with. This allows the user to logon
(or identify themself) with this name and not have to know which realm they
are in this week.

2) The canonicalization flag basically tells the KDC that the Kerberos
client can handle a returned service name that is different from the
requested name. It may even do something with that information.

3) The Microsoft Kerberos client expects to get referrals when the KDC
doesn't know about the requested principal. The Microsoft Kerberos
implementation does not have an equivalent of a domain_to_realm mapping
configuration, so it depends on the referrals to locate services. The
Microsoft Kerberos client will always send a TGS-REQ to the realm of the
user making the request first.

4) It documents how the Microsoft KDC will hand out referrals when the KDC
doesn't know about the requested principal. rfc1510 is sufficiently vague on
this point and leaves it to the implementation.

The next revision of the krb-referals I-D will clarify these points and
correct some errors.

B. With regard to the krb-dns-locate I-D.

1) Microsoft does not have an equivalent of "DNS domain to realm" mappings
on the client.

2) Microsoft does not use the DNS to produce domain to realm mappings
either.

3) The Microsoft KDC keeps the principal names (and associated SPNs and UPN)
in the equivalent of the KDB (directory service). As such Microsoft uses the
krb-referral mechanisms to allow the KDC to resolve the name that the client
is requesting.

4) The only role of the DNS in our implementation is to locate the KDCs for
a given realm (realm = DNS domain in windows 2000).

If these the krb-referral and krb-dns-locate I-Ds are to be merged (and that
does make some sense). The parts to keep are:

1) Locate KDCs, kpasswd and kadmain services based on the DNS. (need to
explain how this works with REALM != DNS domain).

2) Define how server based referrals are performed and how they interact
with the defined namespace. Where a namespace is a hierarchical tree or a
configured authentication path. The configured authentication path is the
construction of a hierarchical name space from a disjoint name space.

3) Introduce the concept of principal aliases. This allows the client to
just make a request for a user specified name. This is the mechanism that is
used to protect the user from a suspect DNS. The client doesn't use the DNS
to canonicalize the name that the user requested. That name is just sent to
the KDC. If that name is a registered alias for a principal, then the
correct service ticket is returned to the client. If the canonicalization
flag is set, the returned ticket will reflect the true name of the
principal.

4) Explain how user principal aliases can be used to locate a realm for the
user to logon.

-----Original Message-----
From: Paul Leach (Exchange) 
Sent: Saturday, December 18, 1999 4:52 PM
To: [email-masked]'; Tony Andrea
Cc: Jonathan Trostle; Derek Atkins; 'Ken Hornstein';
[email-masked]
Subject: RE: comments on krb-dns-locate draft

> From: Jeffrey Altman [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 11:03:51 -0800

> Sent: Monday, December 20, 1999 8:27 AM
> But they get service authentication now.

No they don't. They get _bogus_ service authentication -- service
authentication that can be spoofed by spoofing the DNS.

  So you are saying that these
> platforms just won't be able to make connections?

No -- they will make connections, and may think that they get service auth,
but won't.

> systems.  If the client is non-DNSSEC it still retrieves the

But it can't rely on it; if it does it won't be secure.

> which are protected by Kerberos.

Huh? Maybe you need to be specific about the scenario you have in mind. We
have no services whose principal IDs contain IP addresses.
  
> do not have a hard coded REALM.  My realm is determined by a DNS TXT

Then your implementation is insecure.
 
> And what I am telling you is that this model does not scale.

It's scalability is entirely dependent on the mechanism used to distribute
the information. Said mechanism is outside the scope of the Kerberos
protocol. Implementations that do scale are possible.

> common domain name.

How many realms? 2? 5? 10? A hand maintained table can easily scale to that
level. The old "hosts.txt" file for the ArpaNet scaled to 1000's, and was
distributed via FTP. (For use in this context, it would have to be
distributed via a secure FTP...)

What do you mean "share a common domain name" -- share a common suffix?
Realm names have to be unique.

> Whether that be an organization such as a
> University or an ISP.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 11:43:45 -0800

> Sent: Sunday, December 19, 1999 12:54 PM
> > 

Which is not necessary and not sufficient.

I.e., if DNS is being spoofed, it won't save you. And there may be nothing
wrong at all even if they don't match.

Best to just trust your KDC for this. You have to anyway for more important
things (your key).

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 14:02:01 -0800

> Sent: Monday, December 20, 1999 11:20 AM
> to client and servers using heterogeneous operating systems.

The mechanism I am talking about is implementable on heterogenous operating
systems. 

> If you

A total non-sequitor.
  
> You also better have NTLM removed from Win2000.

Cheap shot. And wrong. A lot of work went into Windows 2000 to make sure
that existence of NTLM could not lead to downgrade attacks, so that
applications that wanted to take advantage of better security (Kerberos)
could.

> perfect then it is not acceptable.

I'm not.

> I have to support clients using

And what I'm trying to do is allow the OSes that can do better to do better,
by defining a secure protocol (one that permits a secure implementation). On
some OSes, including some of our legacy ones, it may not be convenient to
implement it fully. On others it will. However, I beleive there is no reason
in principle that any of those OSes can't provide a secure implementation.

You are trying to insist on an protocol that no one can implement securely
(at present), and which in addition requires more components be trusted than
the alternative.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 18:20:06 -0800

> Sent: Monday, December 20, 1999 7:06 AM
> Cc: [email-masked]'; Jonathan Trostle; Derek Atkins; 'Ken
> "Paul Leach (Exchange)" <[email-masked]> writes:
> 
> TLS, as it is used today, can also assume a hostname of www.FOO.com.
> If I type 'foo' into my browser, it will try a local machine of 'foo'
> and then, if that fails, try the hostname 'www.foo.com'.  Indeed, I
> just tried typing 'https://ted-williams', which for me resolves to
> 'ted-williams.mit.edu', and SSL accepted it.  I got connected without
> an error.

First, one shouldn't confuse TLS/SSL implementations with TLS/SSL. Early
versions of SSL in some people's browsers, for example, didn't even examine
the server name in the server's certificate.

To say any more about your example above, I'd have to know what the Subject
DN is in "ted-williams"'s certificate.

>  As a ghedhanken experiment, what would happen if I had a

[side note: "gedanken" is the German word for "thought"]

> 'ted-williams.foo.com' and had both foo.com and mit.edu in my search
> path?  Would this still be considered a DOS attack?

Yes and no. The name is ambiguous. So, in the sense that there is an order
to the search path, and an attacker spoofing DNS could stop you from using
the first server in the ordered list, that's a DOS attack. But in the sense
that the security subsystem can guarantee that, if you get any server, it is
one of the ambiguous ones, and not "ted-williams.badguys.com", it isn't a
DOS attack.

> What about if
> only mit.edu was in the search path, but the DNS request pointed to a
> machine that identified itself as 'ted-williams.foo.com'?  What would
> happen then?

A correct TLS implementationon the client, if it were told that it was being
asked to connect to "ted-williams.mit.edu",  would fail to authenticate a
server that (presented a certificate that) identified itself as
'ted-williams.foo.com'.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 99 21:27:24 EST

> Well, the server can have many certificates, one for each FQDN. I also
> believe that the Subject DN can contain multiple DNS names, but my X.509
> expert isn't around for me to double-check that.
> 
> So I don't think your conclusion follows.
> 
> Paul

The host can have one certificate per virtual IP address.  There is
not a correspondence between certificates and DNS entries.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 18:22:31 -0800

> Sent: Monday, December 20, 1999 8:16 AM
>

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Dec 99 21:33:37 EST

> the server name in the server's certificate.

I believe that SSL did not require the server name to be checked.
This requirement is new to TLSv1.

> DN is in "ted-williams"'s certificate.

  Certificate[0] subject=/C=US/ST=Massachusetts
                         /O=Massachusetts Institute of Technology
                         /OU=NetworkOperations
                         /CN=ted-williams.mit.edu
                         /Email=[email-masked]

  Certificate[0] issuer =/C=US/ST=Massachusetts
                         /O=Massachusetts Institute of Technology
                         /OU=MIT Certification Authority

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 23:24:11 -0800

My X.509/SSL guru says:
1. A certificate can contain multiple "CN=www.foo.com" components in the
SubjectName DN for multiple server names.
2. SSL does not require checking of the server name, but if one didn't, then
one didn't get server authentication. I.e, server authentication just wasn't
required. The "anonymous cipher" feature isn't in use on the server side, so
it's just a red herring.
 
NetNet: clients that want server authentication can demand it and get it in
SSL without relying on the validity of DNS information, even when the server
has many DNS names.
 
Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 21 Dec 1999 10:13:12 -0800

> Sent: Tuesday, December 21, 1999 8:48 AM
> To: Derek Atkins
> Cc: Paul Leach (Exchange); 'Derek Atkins'; Jonathan Trostle; 'Ken
> > > IE 5.0 will refuse to accept this certificate if the 
> specified URL is
> > > 
> > >   https://18.86.0.96/ 
> > > 
> > > where the IP address is used instead of the FQDN.
> > 
> > Netscape will fail to accept the above url, too.  But what happens
> > if you add 'mit.edu' to your DNS search list and then you try:
> > 
> > 	https://ted-williams
> > 
> > ???
> > 
> > -derek
> 
> Netscape puts up a dialog asking me to accept the unknown CA.
> 
> The IE behavior (win2000) is a little stranger.  It appears to accept
> the certificate and reports that the host wants be to transmit a
> certificate to authenticate myself.  When I fail to specify a local
> cert it responds with
> 
>   Cannot find server or DNS error
> 
> Which appears to indicate that it is continuing to look down the DNS
> Search List for additional servers to try.

Or it might be trying to check a certificate revocation list?

This is not really the mainstream case -- because it is the MIT CA, the
browsers don't trust the CA yet. The mainstream case would be where the CA
is one of the builtin trusted roots (or after adding the MIT CA to the set
of trusted roots).

Paul

---

From: "John Brezak (Exchange)" <[email-masked]>
Date: Tue, 21 Dec 1999 10:02:44 -0800

3) The Microsoft Kerberos client implementation does not have an equivalent
of a domain_to_realm mapping configuration, so it depends on the referrals
to locate services. The Microsoft Kerberos client will always send a TGS-REQ
to the realm of the user making the request first.

5) Explain how the existing MIT Kerberos KDC handles referrals for
hierarchical realms and how "capaths" can be used to setup hierarcical name
spaces. Does Heimdal do anything like this?

-----Original Message-----
From: Paul Leach (Exchange) 
Sent: Saturday, December 18, 1999 4:52 PM
To: [email-masked]'; Tony Andrea
Cc: Jonathan Trostle; Derek Atkins; 'Ken Hornstein';

Paul

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 21 Dec 1999 14:12:33 -0500

Hi,

At 02:27 PM 12/20/1999 -0800, Paul Leach (Exchange) wrote:
>I guess some people don't realize that the MIT KDC already has this stuff 
>implemented. Check out [capaths] in the krb5.conf file, for example, and 
>the behavior where a KDC generates a referral to its parent if the server 
>principal ID isn't found in its KDB.
>
>I guess some people didn't look at appendex section A.6 when I referred 
>them to it, to see that it's already in the spec.

I think that Microsoft has misinterpreted the intent of the capaths support.

Since the Microsoft clients tend to avoid performing a name lookup, or some 
other name cannonicalization,  prior to forming a ticket request, the 
client creates a ticket request that many people would consider 
under-qualified. E.g HOST/FOO instead of HOST/FOO.EXAMPLE.COM.

 From the Kerberos FAQ: "The [capaths] section defines a series of 
authentication paths to use when doing transitive cross-realm. This is used 
by the clients to determine the correct path for doing transitive 
cross-realm, and by the application servers to determine that a cross-realm 
authentication path is actually valid. "

(capath is not mentioned in RFC 1510 or draft-cat-kerberos-revisions-04.txt)

Since the Microsoft Kerberos library does not support capath configuration 
information, Microsoft is relying on an MIT style KDC to put the capath 
configuration information within the krb5.conf file that resides on the MIT 
KDC. But, because the Microsoft client does not necessarily form a request 
with a fully qualified domain name for the service host, the krb5.conf file 
can't contain a realm or domain mapping. It really needs to contain a 
one-to-one host mapping.

Even worse, the user must now resort to typing in fully qualified host 
names to get the desired effect.

For example suppose that a user wants to get a directory listing of a 
Microsoft network share "test" on server "foo". The user will not be able 
to type "dir \\foo\test" instead the user will have to type "dir 
\\foo.w2k.example.com\test" and the capaths information on the MIT KDC will 
have to include a _host_ specific line that resembles:

MIT.EXAMPLE.COM={
  foo.mit.example.com = mit.example.com
}

I admit that I may have a few of the details wrong at the moment, but not 
much. The developers at MIT have not tested the capaths support on the KDC. 
We'd always tended to test this on the client configuration. As far as I 
know, John Brezak at Microsoft is the only person that has really tested 
the capaths configuration on the KDC.

My opinion is that the combination of the current Microsoft implementation 
and the MIT implementation has real problems if hierarchical realm names 
are not used. I suspect that many sites that are interested in this 
combination have an existing Kerberos realm and may not be able to deploy a 
new realm that fits into a suitable hierarchy. Sites that need support 
Microsoft's implementation probably want to do this without resorting to 
the current  use of capaths.

By now you may feel like you've been embraced, extended, and deformed. But 
what should the drafts cover, and how do we make sure there is maintainable 
interoperability?

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 21 Dec 1999 15:18:21 -0800

> From: Paul B. Hill [mailto:[email-masked]]
> Sent: Tuesday, December 21, 1999 11:13 AM
> To: Paul Leach (Exchange); [email-masked]

I believe that 1510bis is silent on this subject.

I think you are conflating two issues.
Issue 1: given a host name, what realm is it in?
Issue 2: given a realm name (by definition an FQDN, right?), how is the
authentication path determined.

In addition, one of the issues being addressed by this thread is whether the
Kerberos _protocol_ needs changing in order to handle our proposed solution
to these issues.

My note about capaths was addressed to the second issue, and I have claimed
that no protocol changes are necessary. Your comment above shows you are
concerned with the first. I think this confuses things.

> KDC.

Yup. It's too hard to configure all the clients.

> But, because the Microsoft client does not necessarily 
> form a request 

Well, in this case, there would need to be an entry for each host (that one
wants to be able to refer to by non-FQDN) saying what realm it is in.

> names to get the desired effect.

Not if the above mapping were present.

>   foo.mit.example.com = mit.example.com

And why not a host specific line that says:
MIT.EXAMPLE.COM={
   foo = mit.example.com
}

I have no idea whether the current code would work given this line, but
there doesn't seem to be any reason why in principle it couldn't.

> what should the drafts cover, and how do we make sure there 

IMO, we need three drafts.
Draft 1: given a realm name, how to find a KDC for that realm.
I suggest the use of SRV records. The DNS does not need to be trusted,
because the KDC can cryptographically prove its identity.

Draft 2: how a KDC should determine the authentication path, given a realm
name other than its own.
I suggest:
If the KDC only has one inter-realm key, it generate a ticket to the KDC of
that realm using that key. 
If there is more than one inter-realm key, that for each inter-realm key it
should have a list of FQDN suffixes of realms that are associated with that
key and when given a realm name, it finds the right inter-realm key, and
generates a ticket to a KDC using that inter-realm key.

Draft 3: how a KDC should behave when given a principal name that it doesn't
have in its KDB.
I suggest that it should look in a database mapping the principal name to a
realm. (The database can have wildcards for the principal names.) If no
mapping is found, then it should assume that the realm is created by
dropping the leftmost component of the FQDN. Then generate a ticket to the
next KDC along the authentication path as per draft 2, and return it to the
client.

How should clients behave: as they do today (to get the same degree of
security they do today). If they really want service authentication, then
some clients may have to be more careful in how they construct the service
principal name w.r.t. to trusting the DNS; CNAMES and inverse IP address
lookups can't be trusted.

What changes are needed to the Kerberos protocol to do the above: none.

In addition, we will create a 4th draft on the use of the name
canonicalization flag, which really doesn't have anything to do with any of
the above. (Although it might seem that way from the existing drafts....)

Paul

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 21 Dec 1999 19:06:01 -0500

At 03:18 PM 12/21/1999 -0800, Paul Leach (Exchange) wrote:
>...If there is more than one inter-realm key, that for each inter-realm 
>key it should have a list of FQDN suffixes of realms that are associated 
>with that key and when given a realm name, it finds the right inter-realm 
>key, and generates a ticket to a KDC using that inter-realm key.
 >
>Draft 3: how a KDC should behave when given a principal name that it 
>doesn't have in its KDB.
 >I suggest that it should look in a database mapping the principal name to 
a realm. (The database can have >wildcards for the principal names.) If no 
mapping is found, then it should assume that the realm is >created by 
dropping the leftmost component of the FQDN. Then generate a ticket to the 
next KDC along the >authentication path as per draft 2, and return it to 
the client. ...

But my testing indicates the Microsoft clients do not always generate a 
request that includes a realm name, or FQDN that can be used to derive a 
realm name.

Scenario:
DNS domain: example.com
UNIX hosted Kerberos realm: MIT.EXAMPLE.COM
W2K Domain: NT.EXAMPLE.COM
W2K DC: foo.nt.example.com
W2k share available on DC: test
W2k client workstation in the NT.EXAMPLE.COM domain: bar.example.com

Alice logs into bar, authenticating against the MIT.EXAMPLE.COM realm. The 
NT domain has a user named [email-masked] which has an 
alt-security-id of [email-masked]. The initial login works OK 
assuming the trust relationship has been done, along with other 
configuration steps that Microsoft has publicly documented.

Now Alice types "dir \\foo\test" examination of traffic indicates that 
eventually the Windows 2000 client will generate a KRB_TGS_REQ to 
MIT.EXAMPLE.COM with the specified realm name of MIT.EXAMPLE.COM and server 
name of HOST/foo. (And, it won't have bit 15 set, but that's a different 
discussion.)

At this point let's revisit your suggestions. The KDC that has been 
contacted doesn't have the principal in its KDB. "If no mapping is found, 
then it should assume that the realm is created by dropping the leftmost 
component of the FQDN." The client didn't present a request for a fully 
qualified host name. If we drop the leftmost component, in this case "foo", 
we're not left with a lot to work with.

What about your other case, "I suggest that it should look in a database 
mapping the principal name to a realm. (The database can have wildcards for 
the principal names.)" We have "foo" to work with. Because the Microsoft 
client provides so little information in the request, it feels like the KDC 
has to have either a mapping for all principals, or can only support a 
mapping to one other realm, or would have to provide the client with a list 
of all the realms that it has a trust relationship with. All of these leave 
a very bad taste in the mouth. I'm hoping I'm just being stupid and someone 
sees a much better solution to this.

I suppose that the KDC could also look at the realm that was presented in 
the request. We already know it is the wrong realm. But if we take part of 
Paul's suggestion and drop the leftmost portion we get EXAMPLE.COM. We can 
then see if we have trust relationships with another realm that contains 
EXAMPLE.COM. Hmm, this actually resembles the way things already work, but 
doesn't buy us a solution for the scenario that was described above, if we 
also have other Kerberos realms with the example.com namespace.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 21 Dec 1999 18:41:44 -0800

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Tuesday, December 21, 1999 5:29 PM
> Cc: 'Paul B. Hill'; [email-masked]
>    Please don't forget, in the example given, "foo" usually 
> isn't even a DNS
>    name -- it is a NetBIOS name, and resolved via WINS, not 
> DNS. This was a
>    legacy we had to deal with.
> 
> DNS is clearly evolving to be an adequate alternative to WINS; I don't
> think we should start complicating kerberos now to adapt to a protocol
> which can be straightforwardly replaced by a standard ietf protocol.

We aren't proposing any change to the _protocol_ to accomodate it. The 1510
spec allows flat host names in service principal names. 

In the case where there's only one realm, there isn't even a need to change
any implementation.

In more complex cases, the "complication" is to do a hostname to realmname
mapping on the KDC, of the kind that already is done on the _client_, where
the configuration is much harder to manage. And the mapping isn't even
needed in the case where all the NT realms trust one another (the common
case).

Paul