Subject: Re: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sniffer and cracker for Windows 2000/XP]

From: Jeffrey Altman <[email-masked]>
Date: Mon, 2 Dec 2002 9:29:11 EST

> > > If we still do not want Microsoft to begin using TLS to protect TGT
> > > requests we need to come to an agreement quickly.  Probably within
> > > days.
> > 
> > Okay, how about smb's suggestion to use anonymous Diffie-Hellman?
> 
> How about the suggestion to use DCE RFC 26.0?
> 
> 

DCE RFC 26.0
<http://www.opengroup.org/tech/rfc/mirror-rfc/rfc26.0.txt> is not
sufficient in that it assumes that the client machine is managed.
This is not the case for the vast majority of client machines.
Therefore, there would be no shared key to use to request the data.

The DCE approach also has limitations in a managed environment.  When
a host key is available it is only good for a specific KDC.  That
means that if I am logged into a machine in REALM BAR1.COM and need a
TGT for REALM BAR2.COM and there is no cross realm, my TGT request
would again be vulnerable.

The ADH approach allows us to provide protection against passive
attacks although it does leave open a MITM attack.

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 08:13:26 -0800

> Therefore, there would be no shared key to use to request the data.

It is the case for most Solaris (SEAM) and Windows 2000/XP deployments
that clients are "managed" and that is one of the main cases we must
cater to.  It is easy enough to provide this solution.  I see no reason
why we shouldn't.  As for key-less kiosks, I agree that we need a
solution that works for them, but I disagree that we need one solution
that works for both.

That said, I very much like the EKE/SRP approaches.

> would again be vulnerable.

I don't see this. A) the client can use its key to get x-realm TGTs for
the purpose of doubly-encrypting pa-enc-timestamp and B) we need only
protect the AS exchanges (principals with password-based longterm keys
should not be allowed to act as services without user-to-user
authentication).

> attacks although it does leave open a MITM attack.

Using a host's keys (its TGTs' serssion keys, rather) to protect
vulnerable password-based pre-auth data is not open to a MITM attack.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 17:32:25 +0100 (MET)

> should not be allowed to act as services without user-to-user

You're probably not aware how W2K services get their passwords...

While W2K was still in Beta I asking Microsoft for support of strong
random keys for services (preferably in a fashion that allowed one to
even use MIT Kerberos-style keytabs for services), but it wasn't
added to W2K final.

My primary concern about the password-based keys for services
was that they were susceptible to dictionary attacks (not only
the TGTs acquired by the services, but all the service tickets
for the services themselves, and the average admin would probably
create service accounts with weak passwords at least every once
in a while...

The reason why services use password-based weak keys in W2K is
because of the API Microsoft is using for starting services
under their own user accounts: Open the Service Manager on W2K
(Control Panel->Administrative Tools->Services) select a service,
open the Properties of the Service (right mouse button) and look
at the contents of the Log on tabstrip...

It might be good if Microsoft had an API (plus Admin user interface)
that allowed to use strong random keys for services instead of
admin-chosen passwords...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 08:45:21 -0800

> You're probably not aware how W2K services get their passwords...

Irrelevant.  The host key generation process can be  made stronger if it
isn't strong enough already.  The details of how some MS products
generate Kerberos host keys are of far less interest to me than the fact
that those products support or even require the use of Kerberos host
keys.

In other words, the weakness of the W2k host key generation that you
claim can be fixed, if it's real and if it hasn't been fixed yet, and so
does not preclude the use of host keys to provide additional protection
to AS pre-auth mechs that could use it.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 18:56:26 +0100 (MET)

> that those products support or even require the use of Kerberos host

I didn't say anything about how W2K machines get or generate their host keys. 

>>> should not be allowed to act as services without user-to-user

I was just pointing out that an assumption that services would always
use strong random keys (or could be required to do so) is fundamentally
flawed because it would ignore an awfully large installed base.

> to AS pre-auth mechs that could use it.

Actually the W2K Kerberos host keys are probably randomized and the
only service keys that are somewhat stronger since no service ever
needs to use the host key to logon -- for "run as LocalSystem" you
don't need to (can not) supply a password, for any other service
account you have to supply a printable password.

What this means is that Microsoft may actually have two problems,
one of which (weak service keys) is not normally present in traditional
Kerberos.

With Microsoft Kerberos, not only the AS exchange might be susceptible
to dictionary attacks, but the TGS reply and the AP request may also
be susceptible to a dictionary attack on the key of the service.
This may not apply to those situations where a service based hostname
is aliased to the host principal in the Active Directory instead of
being aliased to the service principal the service is using.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 10:05:17 -0800

> I didn't say anything about how W2K machines get or generate their host keys. 

So far as I know (and pls correct me if I'm wrong), the generic W2k/
ActiveDirectory setup results in one host key per host and all other
host-based principal names for any one host are treated as aliases of
the canonical host principal for the same host.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 21:53:24 +0100 (MET)

> the canonical host principal for the same host.

Here you go.  :)

Lacking time I haven't researched the W2K-internal procedure when
a W2K Server/Workstation joins a domain and the host principal is
created, however I vaguely remember that there was some randomness
involved in creating the key (and I hope it was binary randomness
and not printable randomness).

Anyway, if you want to validate the following or find out more details
for yourself, go to www.microsoft.com, search for "ksetup.exe" and
read the Document "Step-by-step-Guide for Kerberos 5 interoperability"
(the search returns several other documents as well.

Normally there are no (read ZERO) hostbased service names and you
cannot even add one, because Microsoft's Active Directory doesn't
support them at all.

Instead, Microsoft invented this special "name canonicalization"
that came up on the list discussions several times, and they use
it to map "hostbased service names" to regular W2K accounts.
(Remember from the NT4 area where there also was a "<pcname>$"
account for each PC that joined a domain?)

Basically they seem to do the same for W2K Kerberos: when a machine
joins a domain, they create a machine account and the host principal
for that machine "host/f.q.d.n" is aliased to the machine account "<pcname>$".

If you need additional mappings (hostbased service names), you can
use the "ktpass.exe" tool to add the aliases into the Active Directory
and they will be used during canonicalization.  However there is absolutely
no requirement that these be aliased to the "<pcname>$" account.

But reading that interop document again, I'm pointed once again to
the serious W2K problem of non-random password for service accounts!

It looks like when you want to add a W2K workstation to an non-Microsoft
Kerberos realm (i.e. create a host/f.q.d.n principal for that Realm),
that your're once again limited to an admin-chosen printable password
and don't have a choice for an keytab-based strong random key.

OUCH!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 12:58:48 -0800

> > the canonical host principal for the same host.
...
> cannot even add one, because Microsoft's Active Directory doesn't

I understand this.  But the host's AD-specific canonical principal still
reflects the hostname.

> account for each PC that joined a domain?)

*nod*

As long as the mapping happens in this way then all of those services
share the same key as the host's canonical principal name (<hostname>$)
and there is no weak password-derived key.

> for that machine "host/f.q.d.n" is aliased to the machine account "<pcname>$".

Right.

> no requirement that these be aliased to the "<pcname>$" account.

Ok, so if you don't alias those additional service princ names you end
up creating new accounts with their own [password-derived] key.  But
this is not the default case then, is it?

...
> and don't have a choice for an keytab-based strong random key.

This is more serious, yes.

Nico
--