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

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 Apr 2000 8:52:28 EDT

Ken Raeburn wrote:
> 
> Doing away with all canonicalization of FQDNs means that either (a) a
> service would have to be aware of and have keys for every convenience
> alias the host has, even in other domains outside the control of the
> maintainers of the host or service, (b) we have to change names
> somewhere else, such as through canonicalizing principal names or
> using secure DNS, or (c) the user of such aliases just loses.

Isn't (a) what Win2000 requires now?

Isn't (b) what the Microsoft folk are proposing be done by the KDC?

Now I am beginning to understand and appreciate why Microsoft would
like these translations to be done by the KDC.

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

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 18 Apr 2000 10:36:50 -0400

> like these translations to be done by the KDC.

I understood their argument from the get go, but it doesn't seem like
the KDC is in a good position to canonicalize service names either.
What Microsoft's proposal lets you do is effectively centralize static
configuration within a Kerberos site; that's somewhat orthogonal to
taking advantage of the nice, federated (but insecure) DNS namespace
for service canonicalization and realm mappings.

Even if we accept the general idea of Microsoft's proposal, it's not
clear to me why service name canonicalization should be a KDC function
rather than a potentially separate Kerberos service.

> maintainers of the host or service,

I'm not unhappy with (a) for service name canonicalization.  (Well, in
combination with (c): the user of an alias loses if the service
doesn't have a key for a given alias.)  But it doesn't help much at
all for realm mapping.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Apr 2000 17:46:15 +0200 (METDST)

> Isn't (a) what Win2000 requires now?

I have the impression that Microsoft implemented the reverse of (a),
at least for w2k beta 3.  I haven't checked recently.

The service will retrieve the cleartext realm and sname from
the ticket inside the AP_REQ and use the password of the service
to create a key which will then be used to unwrap the ticket.

This means that every w2k service will "brute force" all tickets
that are sent to him with his own password.  I don't know whether
it at least verifies the realm to match it's own.

What lead me to this assumtion:
I created *two* user accounts:  test1 and test2 and entered the same
password for both.  Then I requested context establishment with test1,
but exchanged the tokens with a server running under user test2.
The server successfully established the security context and passed
the name-based authentication.  I didn't try whether "impersonation"
and "delegation" also work.

Since you can not supply a "random" password to a service in w2k,
and human admins are bad random password generators, the probability
of the same password for independent services is much higher than what
it could be -- does this permit session replay on a different target?).

> like these translations to be done by the KDC.

A translation on the KDC would probably be a good secure solution for
the majority of the users.  However roaming users or visitors may
not want to blindly trust a foreign KDCs translation and realm mapping
for all hosts.

I also think that using Secure DNS will not ultimately solve our problem.
In the IETF we need to specify solutions that scale to the whole internet.

Maybe you are sure about the ownership of your own domain, but as I
mentioned in previous Emails, DNS domain allocation is done on a
first-come first-served basis and domains are sold or transfered
over trademark disputes, so won't be anything like a "secure domain
allocation".  And the big companies have a clear advantage over
all the small businesses.  I really think it would be a bad idea to
algorithmically derive trust from the DNS namespace.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: 18 Apr 2000 19:20:35 -0400

> rather than a potentially separate Kerberos service.

That's my main argument against it.  I don't see a need for
introducing "principal name aliases" into the Kerberos world, and I
think that's basically what they're proposing.

> doesn't have a key for a given alias.)  But it doesn't help much at

My guess is lots of people would disagree with you.

For one thing, cross-domain convenience aliases would be useless.
("Hi, could you please add this Kerberos host key to machine foo,
we've got a DNS alias we'd like to use to reach it.")

For another, what used to be a minor tweak to the zone file that the
host wouldn't care about would instead involve KDC updates and
sysadmin work on the host itself.  In an environment like MIT's where
for paranoia's sake we keep the KDC separate from everything else and
limit admin access to it, that would make adding an alias an even
bigger pain.

But that's just my opinion, I could be wrong.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 18 Apr 2000 20:15:36 -0400

> For one thing, cross-domain convenience aliases would be useless.

Granted.  (Although cross-domain aliases would also be of limited use
in a world with Kerberos-based hostname canonicalization, since people
will be dependent on their local Kerberos realm for mappings.)

> sysadmin work on the host itself.  In an environment like MIT's
> where for paranoia's sake we keep the KDC separate from everything
> else and limit admin access to it, that would make adding an alias
> an even bigger pain.

This argument is partially overblown.  MIT is fooling itself it it
thinks it can be paranoid about the KDC and not paranoid about the
naming of host-based services.  The security of a system is only as
strong as its weakest aspect, and the security of host-based services
at MIT will not be any stronger than the security of whatever system
maps hostnames to keys.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 19 Apr 2000 16:43:20 -0400

> will be dependent on their local Kerberos realm for mappings.)

Normally I'd expect the cross-domain aliases to be used by people at
the place where the admins have defined those aliases.  For example,
prep.cygnus.com is there for the convenience of Cygnus employees.  So
if they have authenticated access to cygnus.com domain info, they can
securely find out that the CNAME record refers to prep.ai.mit.edu.

> >[...host alias changes would require kdc & system admin changes...]

Agreed, and this isn't the only way DNS introduces vulnerabilities
into our environment, but I don't think that's an argument for tighter
integration of Kerberos and (a subset of) name service.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]