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

From: Jonathan Trostle <[email-masked]>
Date: Sun, 05 Dec 1999 22:38:37 -0800

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

>
> > -----Original Message----- 
> > From: Ken Raeburn [<mailto:[email-masked]>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 

If secure DNS was widely deployed, it might make sense to use it, but I don't
think that's the case.

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 06 Dec 1999 15:31:06 -0500

> > more secure the system (everything else being equal).

Hm, well, I was going to complain about it not scaling, but then I
went back and re-read the parts about possibly repeated referrals to
other nameservers, I mean, KDCs.

But this still doesn't address why the name-processing must be made
integral to the Kerberos protocol, rather than being a separate
service.

> If secure DNS was widely deployed, it might make sense to use it, but I don't

Neither is draft-ietf-cat-kerberos-refer widely deployed, so maybe we
shouldn't use that either. :-)

So instead we ignore all of DNS(SEC), and the experience and research
behind it, and invent a (partial) solution from scratch?  Why not take
the opportunity to try to push it forward?  Perhaps with a little help
from Kerberos (e.g., using Kerberos to protect a query for the public
keys used in a domain).

Anyways, in the interest of fleshing out the proposal, can we also
take a look at some of the issues with its specifics?

If the local nameserver, I mean, KDC, doesn't get more directly
involved in resolving external names, doesn't that mean all caching
capability other than on the client itself is eliminated?  Since these
lookups involve cryptographic work, it seems to me that reducing load
on the servers is important, just as it is with DNS.

Time-to-live of returned information?

Caching of negative results?

Interaction with domain search paths?

Transition issues: What do you do if you encounter a KDC that doesn't
implement this yet?

What happens if the name in question refers to a host or domain that
doesn't use Kerberos at all?  Especially if "foo.no-kerberos.com"
shows up before "foo.mit.edu" in your domain search path?

In section 3 you refer to a "root realm", which has all the info about
inter-realm relationships.  Does this mean we need a Kerberos server
and realm for the global DNS root domain?  If [email-masked] wants
to authenticate to host raeburn.org, what actually happens?  (There
are no examples in your draft.)

What about names that map to multiple addresses, each of which has a
different "primary" name (PTR record), for implementing server
clusters or distributed services?  Current practice (in the MIT code)
is to use the "primary" name in generating the service principal
names.  This should be done (isn't currently, alas) by connecting to
an address and then figuring out the name for that address.  And then,
in some cases where the administrators won't cooperate, like my own
ISP, overriding the hostname->realm mapping via local config files.

In this last case, we could do the CNAME processing and then use the
canonical name, forcing the server-cluster systems to have multiple
service keys, but there are potential security implications (e.g.,
cracking one may get you into the others) and other possible
administrative issues to consider.

Ken
==========================================================================
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 Hornstein <[email-masked]>
Date: Tue, 07 Dec 1999 15:12:23 -0500

>integral to the Kerberos protocol, rather than being a separate

Something suddenly pops to mind here.  If you put name-processing into
Kerberos, you pretty much aren't doing ticket caching anymore, are you?
Because you won't be able to tell if a particular name canonicalization
is still valid or not (well, you could return DNS TTLs ... ouch).

--Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 07 Dec 1999 18:56:44 -0800

>integral to the Kerberos protocol, rather than being a separate

KDC doesn't do the name processing; it does name lookups to a backend name
service - which could be DNS. The gain of this proposal is that the client
can learn the realm securely.
>from Kerberos (e.g., using Kerberos to protect a query for the public

I'm for DNSSEC. If you have a way to help deploy DNSSEC using Kerberos, I'd
be interested in seeing it. But we should be careful about any circular
security arguments: Kerberos relies on DNSSEC which relies on Kerberos ...

Here is another way to view it. In the near term, there will be many
Kerberos clients that won't have DNSSEC. Without the proposal in this
draft, there isn't a secure method of doing name to realm mappings for
these clients. So these clients need their KDC's to support this extension.
In the longer term, perhaps DNSSEC will be widely deployed. Even then,
there will always be some Kerberos clients that for whatever reason, don't
have DNSSEC. These few clients will still need their KDC's to support this
extension. 
>take a look at some of the issues with its specifics?

Ok.
>on the servers is important, just as it is with DNS.

I don't believe it's as important as reducing load on DNS since the KDC is
replicated and clients can find KDC's in the DNS using SRV RR's. If the
client can't find a DNS server, it's hosed - and this is often hardcoded on
the client and not easy to update. The KDC is not a nameserver. It's doing
name to realm lookups for Kerberos clients. Caching is done in the DNS. 

>Time-to-live of returned information?

Not needed here anymore then it is needed today with the Kerberos ticket
cache. Are you saying that a client would go and grab a new ticket today
because the server's realm might have changed?
>Transition issues: What do you do if you encounter a KDC that doesn't

Such a KDC has clients that all use config files. In other words, it's
mostly visible only within a realm. 

>shows up before "foo.mit.edu" in your domain search path?

If the lookup in the back end name database fails, then the host doesn't
support Kerberos. So the client should deal with that error appropriately -
don't connect, or find some other security mechanism. 

From both a security and a usability perspective, it seems wise to avoid
domain search paths on the client that have relative DNS names in multiple
domains of the search path. 
>are no examples in your draft.)

root realm of an organization's Kerberos realm hierarchy - which is
independent of the DNS domain structure. For [email-masked]
authenticating to raeburn.org, it's possible if there is a trust
relationship between the root realm of foo.com and the root realm of
raeburn.org. In this case, a series of referrals is returned leading
jtrostle up to the foo.com root and then across to the raeburn.org root.
raeburn.org root realm KDC can do a secure lookup and find the realm of
host raeburn.org. Pkcross and pkinit should both be considered for
solutions at this level. 
>administrative issues to consider.

In some cases, it probably makes sense if the servers in the cluster are
one principal. If they are different principals, then one approach is to
use our proposal and have the KDC do the lookup and find out the name maps
to several principals. The KDC then picks one principal name and returns
that in the padata along with the realm.

Jonathan

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 07 Dec 1999 19:06:28 -0800

>is still valid or not (well, you could return DNS TTLs ... ouch).

You should still cache tickets. What does a server do about outstanding
tickets when it changes its name or realm? It should probably try to honor
them if possible. A client should probably retry when getting a
KRB_AP_ERR_MODIFIED error. So I don't see the issue here. 

Jonathan

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 07 Dec 1999 22:17:12 -0500

> tickets when it changes its name or realm? 

When we tackled this problem in DCE, we decided that there were no
realm renames; instead, new aliases were added and then, after some
time (hopefully greater than the max ticket lifetime), the old names
would be deleted.

(You also have to hang on to the original realm and principal name for
string2key salts to keep working after the rename... :-) )

						- Bill

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 07 Dec 1999 23:58:04 -0500

>tickets when it changes its name or realm?

A server changing it's realm?  Well, I think it could simply store the
extra service ticket for the "old" realm.  (Same goes for name change).
Does that actually happen in practice?

>It should probably try to honor

Let's say I'm using the name "host1.bar.com" to access a host with a
service on it.  It's a alias for "host2.bar.com".  So, (as I understand
it), I'm supposed to send "host1.bar.com" off to the KDC, who will perform
a DNS lookup for me.  Okay, fine, I get a service ticket back for
service/host2.bar.com, with the right realm, and everyone's happy.

So what happens the next time I want to use a service on host1.bar.com?
I suppose that locally I can maintain a name cache for name
translations I got from Kerberos ... but what about DNS TTLs?
Without the use of TTLs, I'd have to talk to the KDC every time I
want to access the service on host1.bar.com, because I won't know
if the name has changed or not (and yes, we _do_ use this in
practice, often enough that it would be painful for our site for
this to break, and I don't think we're the only ones).  The client
could simply ignore TTLs and cache names for the ticket lifetime
... but I think everyone would agree that doing _that_ would be
worse in the long run.

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 08 Dec 1999 00:26:23 -0500

> can learn the realm securely.

But "name lookups to a backend name service - which could be DNS" are
covered by what I meant by name processing.  In a sense, it's using
TGS_REQ as a transport for name-lookup queries, but saving one last
exchange by having the rest of the TGS_REQ there every time just in
case the final name and realm info is known.  (But also possibly
adding exchanges because of caching issues.)

> security arguments: Kerberos relies on DNSSEC which relies on Kerberos ...

Unfortunately, I don't know much about the specific problems with
deploying it.  If I did, I'd be happy to try to come up with ideas.

The circular dependencies present an interesting bootstrap problem,
and I need to think it through again, but the user's and host's secret
keys may be sufficient to break the loop.

> Kerberos clients that won't have DNSSEC.

Okay, so we can't rely on DNSSEC.  That still doesn't directly argue
for putting this into the TGS_REQ processing.

>    Without the proposal in this

Well, just to be picky, another scheme could fill the same gap in a
similar fashion, it doesn't have to be this one.  For example, adding
a new type of message separate form AS_REQ and TGS_REQ, called
NAME_REQ, which only does the lookup and returns the name or referral.

> replicated and clients can find KDC's in the DNS using SRV RR's. If the

Well, yes, DNS servers are replicated too.

But any time [email-masked] wants to look up rtl.cygnus.com to
verify that it hasn't changed, I have to talk to the RAEBURN.ORG and
CYGNUS.COM (and intermediate) KDCs?

> because the server's realm might have changed?

Hm, I hadn't thought of it that way, but it could happen.  Rarely, but
it's possible.  I was thinking in terms of CNAME records with very
short lifetimes -- an approach I've seen used for load balancing.  Or
service-oriented CNAME records named "cvs" or "pop" that may get
changed to point to new hosts.  Yes, we need to assume that the data
can change during a session.  Or avoid caching anything.

With the name->addr->name lookup we currently do in the MIT code, if a
name changes to point somewhere else, yes, we do get new credentials.
We don't throw away the old ones; they'll get used if the same service
principal name comes up again (presumably through looking up a
different hostname).

> mostly visible only within a realm. 

So, as a transition mechanism, we go back to distributing host tables?
If not, how else am I going to find out that "athena-dist.mit.edu" is
just an alias for "aeneas.mit.edu"?

> don't connect, or find some other security mechanism. 

Um, wait.  If I ask my KDC about "foo.no-kerberos.com" because
"no-kerberos.com" is first in my domain search path, does its negative
response mean that the hostname doesn't exist, or that it does exist
and doesn't support Kerberos?  In the former case, I should try the
next domain name; in the latter case, I should try another security
mechanism.

I think this proposal also requires that the local KDC have info on
other domains that are in realms that are reachable -- even using
transited-realm stuff -- from the local realm.  So if
[email-masked] wants to access foobar.egcs.com, the RAEBURN.ORG
KDC needs to know that egcs.com uses the CYGNUS.COM realm, and then
also needs to know that CYGNUS.COM is reachable via ATHENA.MIT.EDU but
not directly.  (Actually, egcs.com is broken and unused right now, but
Cygnus does own it.)  I don't think pkinit or pkcross will help there.

Or maybe I'm just getting too tired and should go home... :-)

> domains of the search path. 

The usability aspect doesn't seem to stop all that many people.  And
because of that, I think making the change for security reasons would
be quite unpopular.  That's not a reason to absolutely reject it, but
we do want people to *use* the software. :-)

> independent of the DNS domain structure. For [email-masked]

Okay.  Your use of "the root realm" makes it sound like there's
exactly one, globally.

> that in the padata along with the realm.

That doesn't allow the client to try contacting each address, as many
applications do these days.  It also means that the application must
look up the address for the hostname returned from the KDC, not the
hostname provided by the user.

Ken