Subject: A couple of discussion items

From: Ken Hornstein <[email-masked]>
Date: Tue, 24 Nov 1998 00:07:18 -0500

Some of you may have been following the recent discussion on
[email-masked] regarding the use of RFC 2052 for KDC location.
Microsoft is planning on using this, and I think it's a damn good
idea.

I propose we use the following records:

_kerberos._udp.your.realm.here
_kerberos._tcp.your.realm.here

Comments?  The _ are from the rfc2052bis document.

Also, could someone remind me what the resolution of the Kerberos focus
group was at the last IETF regarding wording for TCP & UDP Kerberos
transport?  I thought it was, "UDP MUST, TCP SHOULD, may be MUST in
future".  This may have bearing on whether or not to even have a _udp
record.

I'd also like to have a way to determine the realm associated with
a particular host.  I'm not sure if that's possible with RFC 2052,
but it would be nice to use the DNS for this somehow...

--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: [email-masked] (Johan Danielsson)
Date: 24 Nov 1998 13:08:29 +0100

> Comments?  The _ are from the rfc2052bis document.

Go for it.

> I'd also like to have a way to determine the realm associated with a
> particular host. I'm not sure if that's possible with RFC 2052, but
> it would be nice to use the DNS for this somehow...

What we've done in our krb4 dist is something like:

krb4-realm.pdc.kth.se.       TXT NADA.KTH.SE

The client removes components of the hostname until it finds a match.

/Johan

---

From: Clifford Neuman <[email-masked]>
Date: Tue, 24 Nov 1998 06:39:35 -0800 (PST)

From: [email-masked] (Johan Danielsson)
   Date: 24 Nov 1998 13:08:29 +0100

   > Comments?  The _ are from the rfc2052bis document.

This would work.  I know that there are some other implementations
that have done somethig similar for a lon time, but with slightly
different syntax.  IT also provided a means to identify multiple KDCs.
I think it simply used the convention kerberos.<realm> and
kerberos1.<realm>.  I think moving to something that is better
standardized makes sense, but one should find out what different
implementations might be currently using.

This is not as straightforward as finding the KDC given a realm name.
In the first case, if an attacker changes the mappings (recall that
the DNS lookup is not protected), one will detect the problem because
your key, or the key in your cross realm TGT, will not work.

In this case, however, if an attacker causes you to think that the
host is in a different realm, you will happily obtain a ticket for the
wrong principal, which will work.  Thus, an attack against this
mapping can cause the user to think he is talking to someone different
than he really is.

Clifford Neuman

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 24 Nov 1998 10:18:43 -0500

>implementations might be currently using.

AFAIK, only Microsoft is currently doing this, and they're (right now)
using a label of _kdc.  This should change to _kerberos.

>[...]

But right now, the hostname->realm mapping under MIT implementations
isn't exactly protected either (a file that you can override with
an environment variable).

You know, it occurs to me that this attack is possible even with the
current flat file scheme.  If you're doing a Kerberos telnet to host
foo.bar.org, and you get a (bogus) CNAME foo.evil.org as a return
value, you will then attempt to use your current flat file database
to determine the realm that foo.evil.org resides in.  I believe this
would have the same effect as the attack you describe above.

--Ken

---

From: [email-masked] (Johan Danielsson)
Date: 24 Nov 1998 16:20:15 +0100

Clifford Neuman <[email-masked]> writes:

> host is in a different realm, you will happily obtain a ticket for
> the wrong principal, which will work. Thus, an attack against this
> mapping can cause the user to think he is talking to someone
> different than he really is.

ObAnswer: Encrypt!

/Johan

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 24 Nov 1998 13:54:53 -0500

>That won't help, since the traffic will be encrypted in an incorrect key
>which would be known by the attacker.  For example, if I know that
>you're going to be telnet'ing to a particular host at a particular time,
>and I know you like to do credentials forwarding, I spoof DNS so you
>have the incorrect IP address and incorrect Kerberos realm, and if I'm
>a Kerberos administrator of that incorrect realm, I can create a service
>principal matching the one you would be using.  The credentials then get
>forwarded to the wrong machine before you're any the wiser.....

That still requires you to be cross-realming to a realm with an "evil"
system administrator.

While I will fully admit that there are security implications with doing
this, I have in my Kerberos deployment run into serious scalability issues
with the plain old krb5.conf.  If we want Kerberos to succeed, we need
to make this information available over the network one way or the other.
Trying to update 5000 krb5.conf files on machines that you have no
administrative control over is a giant nightmare (I only wish I wasn't
speaking from experience).

--Ken

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Nov 1998 13:42:56 -0500

From: [email-masked] (Johan Danielsson)
   Date: 24 Nov 1998 16:20:15 +0100

   ObAnswer: Encrypt!

						- Ted

---

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Nov 1998 14:33:47 EST

I strongly advise that the people involved in this discussion read RFC
2052 or (better yet) the 2052bis draft.  What Ken is proposing (or
ought to be proposing) is not a simple A record lookup of
_kerberos._udp.your.realm.here, but a SRV record lookup which will
return one or more records containing <Priority, Weight, Port,
Target>.  This allows for the specification of multiple KDCs as well
as both redundancy and load-balancing between servers.  It does,
however, mean writing some DNS-parsing code instead of just calling
gethostbyname().

An A lookup of _kerberos._udp.your.realm.here would be terrible; it
would have nothing to do with RFC 2052 except that it would be
interfering with the chunk of namespace staked out by that RFC.

I am curious whether Microsoft is doing a SRV lookup.  I certainly
hope so.

> it would be nice to use the DNS for this somehow...

I don't think 2052 is helpful here, but I agree that we really ought
to move away from flat files for this translation.  I think Ken
successfully argued that there are no new security implications here,
although it is alarming that we are already subject to some pretty
nasty DNS-spoofing attacks.
==========================================================================
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, 24 Nov 1998 14:39:55 -0500

>as both redundancy and load-balancing between servers.

Uh, yeah, I'm sorry if that wasn't clear.  I _absolutely_ mean a SRV
lookup, as specified in RFC 2052 (and 2052bis).

>It does,

I believe we can get away with the existing res_* interface which almost
everybody supports.

>interfering with the chunk of namespace staked out by that RFC.

I agree completely.

>I am curious whether Microsoft is doing a SRV lookup.  I certainly

It's my understanding that they are.

>nasty DNS-spoofing attacks.

It still requires some cooperation with a foreign realm administrator,
which I guess makes it even more crucial who you should cross-realm
with.  (Which reminds me; I guess that section of the Kerberos FAQ
should be updated :-) ).

--Ken

---

From: [email-masked] (Johan Danielsson)
Date: 24 Nov 1998 21:09:59 +0100

"Theodore Y. Ts'o" <[email-masked]> writes:

> That won't help, since the traffic will be encrypted in an incorrect
> key which would be known by the attacker.

Let's assume that the client has successfully obtained initial
credentials.

When connecting to some host S (belonging to realm R1), there are a
number of things that may go wrong.

1) the S -> R1 mapping is wrong, pointing to R2 instead
2) the R1 -> KDC mapping is wrong, pointing to a fake KDC
3) the address of S is faked

In case 1) you will get a cross-realm ticket for R2, which you might
argue is a bad thing to start with, and then a ticket for S in realm
R2. If S is not part of the conspiracy, this is not a problem, since
it will not be able to decrypt this fake ticket. If it is, then you
have a serious problem anyway (I might just aswell read your forwarded
tickets from local disk).

You can combine this with 3), so you actually connect to S' pretending
to be S. Everything is looks fine if you don't actually check who you
connected to. But this attack can be done without faking the
host->realm lookup, just send a fake reply when the client looks up S
(like a CNAME pointing to S').

Case 2) is not very interesting, since the fake KDC doesn't know the
keys used by the other entities.

The combined 1+3 attack might be a problem, but doesn't necessarily
affect whether to include host->realm lookup in a fashion less dumb
than static files. Or do you suggest that we should start using
host-files too?

/Johan

---

From: Mike Eisler <[email-masked]>
Date: Tue, 24 Nov 1998 12:06:47 -0800 (PST)

> From: "Theodore Y. Ts'o" <[email-masked]>

> principal matching the one you would be using.  The credentials 

I agree, and so would recommend that an implementation not rebind on every
Kerberos ticket request, but instead much less often, such as once per
system boot. While that might be quite frequently for some desktops, it
is very infrequent for others.

In any case, doesn't dnssec solve the issues?

The concern I had is that the RFC in question appears to listed as
"experimental", and so is it appropriate for a non-experimental RFC to refer
to it?

	-mre

---

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Nov 1998 17:04:21 EST

> "experimental", and so is it appropriate for a non-experimental RFC
> to refer to it?

RFC2052bis is being advanced as a proposed standard.

There is a precedence issue; a Kerberos RFC which referred to 2052bis
could not advance until 2052bis does.  But I think 2052bis is much
further ahead at this point than anything we're likely to do on this
front.
==========================================================================
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: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Nov 1998 19:02:29 -0500

Date: Tue, 24 Nov 1998 13:54:53 -0500
   From: Ken Hornstein <[email-masked]>

I agree; I'm just pointing out some of the risks.

Probably the thing to do from an implementation point of view is to
always look in krb5.conf first, and have a switch in krb5.conf which
controls whether or not the DNS lookup should be enabled.  That way
sites which don't want to use this feature have a way to opt out, and
"sensitive" realms (which will be whichever ones a particular user or
site administrator might care about) can be hard-coded in krb5.conf.

							- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Nov 1998 19:09:13 -0500

From: [email-masked] (Johan Danielsson)
   Date: 24 Nov 1998 21:09:59 +0100

Mike Swift and I have had some discussions about securing host->realm
lookup by involving the KDC (this is the NAME_CANONICALIZATION
proposal).  Basically, if the bit in the options field is set, this
gives the KDC permission to return a ticket for a service other than the
one originally requested by the client.  This allows the KDC to do the
name canonicalization, instead of depending on the DNS.  The proposal
also had some additional ways of passing realm referrals back to the
client, which would then know which realm to use if that particular host
wasn't supported by the home KDC.  

Mike and I should really write that up that proposal and get it out....

						- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Nov 1998 19:14:41 -0500

Date: Tue, 24 Nov 1998 12:06:47 -0800 (PST)
   From: Mike Eisler <[email-masked]>

That assumes you have a place to cache the results from the DNS lookups,
which might not be the case for some implementations.  For security
reasons, that cache would probably have to be per-user, unless the
Kerberos library was within the TCB.  So yes, there are something you
might be able to do, but they start to get complicated.

... as soon as DNSSEC gets deployed....

That's a very good point.  What I'd probably suggest is placing  the SRV
record stuff in a separate RFC, since it really can stand alone from the
kerberos-revisions document anyway.  That way it can be experimental as
well, if necessary.

						- Ted

---

From: Frank Cusack <[email-masked]>
Date: Tue, 24 Nov 1998 20:05:10 -0500

In message <[email-masked]>, 
> site administrator might care about) can be hard-coded in krb5.conf.

I would prefer to see this enabled at the system level; a switch
in Solaris'/Linux's nsswitch.conf or the BIND IRS. I don't know that
you can add arbitrary switches though.

~frank

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Nov 1998 20:44:54 -0500

Date: Tue, 24 Nov 1998 20:05:10 -0500
   From: Frank Cusack <[email-masked]>

/etc/krb5.conf is at the system level.

						- Ted

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 25 Nov 1998 01:45:07 -0500

>site administrator might care about) can be hard-coded in krb5.conf.

Seems reasonable.

If I write some code, is there a chance it will appear in the next MIT
release? :-/

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 25 Nov 1998 01:46:41 -0500

>kerberos-revisions document anyway.  That way it can be experimental as

Well, how about I firm it up at IETF, then write a draft when I get back?
I'd also be willing to write up stuff about NAME_CANONICALIZATION, if
you don't have a chance.

--Ken

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 25 Nov 1998 15:18:56 -0500

Date: Wed, 25 Nov 1998 01:45:07 -0500
   From: Ken Hornstein <[email-masked]>

   Seems reasonable.

For SRV record support?  Almost certainly....  (and thank you for
volunteering.  :-)

						- Ted